【面试】计算机网络

网络协议

计算机网络体系结构划分：

各体系中的协议分布：

每一层的体系如下：

• 物理层：RJ45、CLOCK、IEEE802.3（中继器、集线器）
• 数据链路层：PPP、FR、HDLC、VLAN、MAC（网桥、交换机）
• 网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（交换机）
• 传输层：TCP、UDP、SPX
• 会话层：NFS、SQL、NETBIOS、RPC
• 表示层：JPEG、MPEG、ASII
• 应用层：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

TCP中的三握四挥

TCP连接

• 建立TCP连接，三次握手：第一次握手是客户端向服务器发送一个报文；第二次握手是服务器收到请求报文之后发送一个应答报文给客户端；第三次握手是客户端收到应答报文之后再发送一个报文给服务器，三次握手就算成功。

• 为什么是三次握手？两次握手不行吗？【需要双方都确认各自的发送接收正常】
  • 要想建立一个TCP连接，需要共同确认客户端服务端的发送、接收功能正常。
  • 第一次握手：客户端向服务端发送请求，服务器收到。服务器得知：服务器接收正常、客户端发送正常
  • 第二次握手：服务端发送应答给客户端，客户端收到。客户端得知：客户端发送接收正常、服务器发送接受正常
  • 第三次握手：客户端发送请求给服务端，服务端收到。服务端得知：服务器发送接受正常，客户端发送接收正常
  • 因此，至少三次握手双方才能确认对方和己方的发送接收均正常。其中，第三次握手可以携带数据，前两次不可以。

TCP释放

• TCP连接释放，四次挥手。【全双工通信，需要双方都关闭各自的发送和接收】
• 第一次挥手，客户端发出连接释放报文段，停止发送数据，主动关闭TCP连接，进入终止状态1【客户端关闭发送】
• 第二次挥手，服务端收到连接释放报文段之后即刻向客户端发送确认报文段，服务器进入关闭等待状态。此时客户端到服务器端的连接释放，客户端收到服务器发的确认之后进入终止状态2【服务端关闭接收】
• 第三次挥手，服务端发出连接释放报文段，进入最后确认状态，等待客户端的确认。【服务端关闭发送】
• 第四次挥手，客户端收到连接释放报文段，发出确认报文段。客户端进入时间等待状态，TCP未释放，经过2倍最大生存时间MSL，客户端关闭。【客户端关闭接收】

为什么要等待2MSL才关闭客户端？

• MSL，Maximum Segment Lifetime，最大报文段存活时间。
• ①保证客户端发送的最后一个ACK报文段能够到达服务端：最后一个ACK有可能丢失，在超时重传机制下，服务端会重传至客户端的FIN+ACK报文段。客户端再次接收到该报文段，重启2MSL计时器。这个过程可以保证连接的正常释放。这个过程中，超时和重传至客户端最大可能各自都需要花费2MSL时间，所以应该是2MSL而不是1MSL。
• ②防止“已失效的连接请求报文段”出现在下次连接中：经过了2倍的最大存活时间，所有报文都会消失。

输入网址到网站加载的过程

DNS：获取域名对应IP，DNS解析过程
TCP（传输控制协议）：与服务器建立连接
IP协议：建立TCP连接时，使用IP协议在网络层发送数据
OPSF（开放式最短路径优先）：IP数据包在路由器之间进行路由选择
ARP（地址解析协议）：路由器在与服务器通信时，将IP地址转换为MAC地址
HTTP（超文本传输协议）：TCP建立完成后，使用HTTP协议访问网页

• DNS解析
  • DNS解析的过程就是寻找哪台机器上有需要的资源的过程。寻找过程：①寻找浏览器缓存中是否存在对应域名的IP地址；②寻找本机系统缓存中是否存在域名对应的IP；③向本地域名解析服务器发起域名解析请求；④本地域名解析服务器向根域名解析服务器发起域名解析请求，返回请求的顶级域名地址（gTLD）；⑤本地域名解析服务器向gTLD域名解析服务器发起请求，找到对应的域名服务器；⑥ Name Server服务器返回IP地址给本地服务器；⑦本地域名服务器缓存解析结果；⑧返回结果给主机
• TCP连接
  • 建立TCP连接，三次握手：第一次握手是客户端向服务器发送一个报文；第二次握手是服务器收到请求报文之后发送一个应答报文给客户端；第三次握手是客户端收到应答报文之后再发送一个报文给服务器，三次握手就算成功。
  • 为什么是三次握手？两次握手不行吗？
    • 要想建立一个TCP连接，需要共同确认客户端服务端的发送、接收功能正常。
    • 第一次握手：客户端向服务端发送请求，服务器收到。服务器得知：服务器接收正常、客户端发送正常
    • 第二次握手：服务端发送应答给客户端，客户端收到。客户端得知：客户端发送接收正常、服务器发送接受正常
    • 第三次握手：客户端发送请求给服务端，服务端收到。服务端得知：服务器发送接受正常，客户端发送接收正常
    • 因此，至少三次握手双方才能确认对方和己方的发送接收均正常。其中，第三次握手可以携带数据，前两次不可以。
• 发送HTTP请求
  • 发送HTTP请求的过程就是构建HTTP请求报文
• 服务器处理请求并返回返回HTTP报文
  • 简单来说就是后端传来服务器请求的数据
• 浏览器解析渲染页面
  • Webkit渲染页面并显示，构建DOM树
• 连接结束
  • TCP连接释放，四次挥手
  • 第一次挥手，客户端发出连接释放报文段，停止发送数据，主动关闭TCP连接，进入终止状态1
  • 第二次挥手，服务端收到连接释放报文段之后即刻向客户端发送确认报文段，服务器进入关闭等待状态。此时客户端到服务器端的连接释放，客户端收到服务器发的确认之后进入终止状态2
  • 第三次挥手，服务端发出连接释放报文段，进入最后确认状态，等待客户端的确认。
  • 第四次挥手，客户端收到连接释放报文段，发出确认报文段。客户端进入时间等待状态，TCP未释放，经过2倍最大生存时间MSL，客户端关闭。

DNS寻址的递归查询和迭代查询

DNS，Domain Name System，域名系统。就是根据域名（网址/URL）获得对应IP地址，查找哪个服务器上存在对应的资源。

DNS查询的步骤：（任何一个步骤中查到映射，直接返回，否则进入下一个步骤）

• ①首先查找浏览器缓存、本地hosts文件中是否有域名映射，如果存在，则返回IP地址映射，完成解析。
• ②查找本地DNS解析器缓存是否有这个网址的映射
• ③查找本地DNS服务器：如果查询的域名包含在本地配置区域资源，表示是由本地DNS服务器解析，具有权威性；如果查询的域名不由本地DNS服务器区域解析，但是服务器缓存有这个域名的映射，这个结果不具有权威性。但两者都会返回解析结果。
  • 这个过程好比于：我要查找员工属于哪个部门，刚好找到他的所属部门，直接得知结果，很权威；但是我要是找的部门不是他所属部门，这个部门负责人告诉我他属于哪个部门，我得知结果，不权威。
• ④如果本地DNS服务器失效，则使用递归查询或者迭代查询来寻址：
  • 如果未采用转发模式，使用迭代查询。本地DNS服务器向13台根域名服务器发起DNS请求，返回一个负责该顶级域名的服务器IP，之后向权限域名系统发起请求，获取到IP映射就返回。整个查询过程类比于DFS，有回退。
  • 如果采用转发模式，则使用递归查询。本地DNS服务器会把请求转发至上一级DNS服务器，直到查询到IP映射返回为止。整个查询过程类比于BFS，没有回退。
  • 

TCP保证安全传输

• 三次握手

  • 三次握手保证了连接的正常，可以得知双方的发送和接收是正常的。

• 超时重传

  • 发送一个数据包之后没有收到ACK，等待一段时间，超时之后将会重新发送。这个等待的时间被称为RTO。检测丢失报文的方法其实就是预设定时器。当一个TCP Segment发送出去之后，启动定时器，当定时器的时间走完，默认这个报文丢失。定时器的时间一开始是预设的（Linux为1s），当不断尝试超时重传之后，会不断叠加定时器的时间。
  • 当一个Segment发送之后，会存放在一个窗口中，等待相应的ACK确认。如果没有收到ACK确认，那么将会一直存在窗口中。一个计时器未结束时，每个Segment在窗口中的位置不变。
  • 对于重传时间是如何计算的问题，在RFC2988中也提供了一种至今Linux使用的方案。

• 快速重传

  • 超时重传中，只有当定时器结束了才会重新发送。这样的设定在延迟要求高的环境中不符合需求。
  • 快速重传机制，实现了另外的一种丢包评定标准，即如果接收端连续收到3次dup ACK，发送方就认为这个seq的包丢失了，立刻进行重传。这样的丢包评定标准下，只要接收方回复及时，就能快速开启重传，减少了时间消耗。
  • 在快速重传中，会发生out-of-order的现象，但是在滑动窗口中会有严格的顺序控制。如果收到乱序片段，那么将会需要重复发送ACK。假设发送报文段依次为1、2、3、4，现在接收方收到2、3、4，并没有收到1，那么按照协议将需要重新发送1的ACK（但是现在没有收到1就发不了1的ACK），而现在的2、3、4属于乱序片段，所以可以判断可以开始快速重传。

• 拥塞控制

  • 某段时间内，对网络中的某一资源的请求超过了网络所能提供的可用部分，将会给网络带来高负担，导致网络性能下降，网络的吞吐量将会随着负荷的增大而下降，这就是网络拥塞。发生了拥塞，那么就要避免。类比于“堵车”，同一时刻大量车辆通过单一车道，导致这条路拥塞。
  • TCP拥塞控制有四种实现算法：慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）、快恢复（fast recovery）
  • 慢开始和拥塞避免：（两者一般一起使用）

  

  • 慢开始和拥塞避免：这个过程中，发送方维护一个叫做拥塞窗口cwnd（congestion window）的状态变量，拥塞窗口的大小取决于网络的拥塞程度。刚开始的时候，并不清楚网络的拥塞程度，所以最好的方法就是先试探一下，由小到大逐渐增大发送窗口，参考上图就是发送方逐渐增大cwnd值。实际上，TCP使用字节数作为窗口大小。每经过一个传输轮次，拥塞窗口就加倍。一个传输轮次经过的时间就是RTT。
  • 类比于限流路段，我不知道路况是否拥堵，我每次按照一定的规则开放车道。如果不堵车，我就一直增大开放的数量，最大限度地利用道路。但是这个过程中，我不可能一直按照加倍的规则开放下去，这样迟早会一下子造成严重堵车。所以在实际操作中，我们还要维护一个满开始门限ssthresh，防止一次开放过多的窗口造成拥塞。
  • 当cwnd < ssthresh，使用慢开始；当 cwnd > ssthresh，使用拥塞避免；当 cwnd = ssthresh，两者皆可使用。拥塞避免改用每次探测之后窗口值加1的机制，避免了一次开放过多的拥塞窗口。每经过一个往返时间RTT就把发送方的拥塞窗口cwnd+1。
    
  • 快重传和快恢复：快重传可以快速知道个别报文段的丢失。按照下面的这种情况，快重传机制下，接收方应该快速发送连续的三个ACK，发送方收到连续的三个ACK立即开始快重传丢失的报文段。按照上图的显示，在收到三个重复的ACK之后，并不进行慢开始，而是调整慢开始门限值为 ssthresh = cwnd / 2 ，同时设置 cwnd 为1，进入慢开始阶段。
  • 

• 滑动窗口

  • 滑动窗口实现的是流量控制，目的就是让发送方发送数据不要过快，接收方要来得及接收。
  • 
  • 这个阶段中，发送方发送窗口的值不应该超过接收方给出的接收窗口的值。TCP窗口单位是字节，不是报文段。
  • 

• 检验和

  • 发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。利用CRC循环冗余校验，可以检测或校验数据传输或者保存后可能出现的错误。

UDP协议

• UDP（User Datagram Protocol）：用户数据报协议。
• UDP是一种不可靠的、无连接的、尽最大努力交付的运输层协议。它仅仅包含运输层必备的功能：多路复用/多路分解，差错检测。
• 在UDP中，发送数据之后仅仅通过接收方是否回复信息来判断传输是否成功，并不会像TCP一样收到来自接收方的反馈。所以这一点上并不可靠（UDP类比于微信聊天信息你已读不回复，但是我并不知道你看没看到信息；TCP类比于淘宝聊天信息，我发出去了你收到并查看，我可以看到已读来得知你看到消息），为了解决这个问题，加入一个UDP延时。如果规定时间内收不到回复，就重新发送。DNS中就是用的UDP来发送域名查询报文。
• UDP提供差错检验，利用UDP检验和来实现，但是并不会进行错误修复。要么丢掉错误信息，要么上报应用程序。
• UDP的特点：①反应迅速（无需连接）；②节省性能资源（无连接状态）；③节省数据段空间（分组首部小）。通常可以用来传输媒体文件等安全性要求不高的数据。

GET和POST的区别

• GET产生一个TCP数据包；POST产生两个TCP数据包。
• GET请求会被浏览器主动cache，而POST不会，除非手动设置
• GET请求只能进行URL编码，而POST支持多种编码方式
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
• GET请求在URL中传送的参数是有长度限制的，而POST没有
• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息

Cookie和Session

• Cookie，曲奇，指的是浏览器发给服务器的一种文件；Session，会话。
• Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。HTTP协议是无状态的协议，不能对之前的请求和响应状态做出管理，所以为了保证无状态又要进行管理，就提出了Cookie和Session的方案来解决这个问题。常用的场景比如用户登录，如果要进行安全性高的验证登录，HTTP本身并不知道用户是否进行了登录，所以为了避免每次跳转页面都要进行登录，那么就得让HTTP请求携带一个信息，告诉服务器已经登录（管理登录状态）。
• Cookie从客户端理解：Cookie就是附加在HTTP请求和应答中的一个附加信息。服务器在向客户端发送应答消息的时候，会附带一个Set-Cookie的首部字段信息，告诉客户端浏览器保存Cookie，然后在客户端下次发送请求时携带Cookie信息，这样就保证了服务器对于客户端的状态的管理。如果浏览器禁用了Cookie，那么会使用URL重写来实现，在URL请求参数中添加一个类似于sid=xx的参数以达到相同效果。使用场景：标识用户登录状态、保存用户名和密码等。
• 
• Session从服务端理解：Session可以理解为会话。实际中一台服务器不可能只服务于一个用户，那么服务端要得知各种操作归属于哪一用户。为了达到这一目的，服务端会创建一个Session，标识用户并且跟踪用户操作。服务端保存Session的方法一般有文件、数据库、内存。使用场景：用户登录之后加购操作等。

HTTP协议

• HTTP协议，Hyper Text Transfer Protocol，超文本传输协议，是一种应用层的协议。
• HTTP使用统一资源标识符（Uniform Resource Identifiers，URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息URL。

参考文档：HTTP协议简单解释_一个菜鸟的博客-CSDN博客_http协议
https://mp.weixin.qq.com/s/1Z8ieE_HKTzEBVQ54v0hqA

• HTTP的特点主要为：①简单快速；②灵活；③无状态（现在一般可以使用Cookie保持Session，实现了状态追踪）；④无连接（服务器一般对Keep-Alive功能提供支持，可以实现长连接）
• HTTP协议主要分为请求和应答过程。这两个过程又分为：Http Request 和 Http Response
  
  • Http Request：Http请求一般分为请求行（标识请求的方法）、请求头部（请求目的地、User-Agent等）、空行（分隔请求头部和请求正文）、请求正文（请求的数据）
    
  • Http Response：Http应答一般分为状态行（响应消息的状态码存放处）、消息报头（客户端要使用的附加信息）、空行（分隔作用）、响应正文（对应请求应该发送的数据）
    
• HTTP协议中常用的请求报文方法主要为GET和POSt，但是还包含一些其他方法。
  

URI和URL

• URI，uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。
• URL，uniform resource locator，统一资源定位器，相当于一个具体的URI，不仅可以标志资源，还指示了如何定位这个资源。

HTTP各版本

• HTTP 0.9版本

  • HTTP协议的第一个版本，功能简单，已弃用
  • 仅支持纯文本数据的传输，虽然支持HTML，但是不支持图片插入
  • 仅支持GET请求方式，且不支持请求头
  • 无状态，短连接。没有对用户状态的管理；每次请求建立一个TCP连接，响应之后关闭TCP连接。

• HTTP 1.0版本

  • 支持POST、GET、HEAD三种方法
  • 支持长连接keep-alive（但默认还是使用短连接：浏览器每一次请求建立一次TCP连接，请求处理完毕之后断开）。
  • 服务器不跟踪用户的行为也不记录用户过往请求。

• HTTP 1.1版本

  • 新增PUT、DELETE、CONNECT、TRACE、OPTIONS方法，是现今使用最多的版本。
  • 支持长连接，在一次TCP连接中可以发送多个请求或响应，且默认使用长连接。
  • 支持宽带优化、断点续传。请求的对象部分数据，可以不必发送整个对象；文件上传下载支持续传。
  • 因为长连接产生的问题：队头阻塞。长连接中，发送请求和响应都是串行化的，前面的消息会造成后面的消息也阻塞。解决方法是创建多个TCP连接，这样就可以基本保证了可用性，浏览器默认的最大TCP连接数是6个。

• HTTP 2.0版本

  • 二进制分帧，所有帧都是用二进制编码，节省了空间
  • 多路复用：HTTP 2.0中所有的连接都是持久化的。相比1.1版本可以不用维护更多的TCP连接，在处理并发请求的时候，可以将多个数据流中互不依赖的帧可以乱序发送，同时还支持优先级。接收方接收之后可以根据帧头部信息将帧组合起来。（解决了1.1版本中的队头阻塞问题）
  • 头部压缩：1.1版本每次传输都需要传输一份首部，2.0让双方各自缓存一份首部字段表，达到更快传输的目标。

• HTTP 3.0版本

  • 基于UDP的QUIC多路复用：在一个QUIC中可以并发发送多个HTTP请求Stream，且如果各个Stream互不依赖，那么就不会造成使用TCP带来的队头阻塞问题。这个问题源头上是因为TCP连接，TCP连接的性质决定了重传会影响队后的数据发送，所以干脆选用UDP来解决这个方案。
  • 0RRT建链：RRT表示Round-Trip Time，3.0可以实现0RRT建链。一般来说HTTPS协议要建立完整链接包括TCP握手和TLS握手，总计需要至少2-3个RTT，普通的HTTP协议也需要至少1个RTT才可以完成握手。基于UDP的QUIC协议可以在第一次发送包的时候直接发送业务数据。但是由于首次连接需要发送公钥数据，所以首次连接并不使用这一方法。

  

  参考文档：图解 | 为什么HTTP3.0要弃用TCP协议，而改用UDP协议？_涛哥聊Python-CSDN博客

HTTP断点续传

HTTP的断点续传，保证了在传输文件的时候因意外中断的传输能够在恢复的时候继续传输。主要原理是是HTTP1.1（RFC2616）中header定义的Range和contentRange字段，记分别记录了文件的大小以及传输节点。

支持断点续传的思路是：客户端（通常是浏览器）向服务器端上传某个文件，服务器端不断记录上传的进度，如果一旦掉线或发生其它异常，客户端可以向服务器查询某个文件已经上传的状态，从上次上传的文件位置接着上传。

实现思路：①记录当前文件；②规定文件的切片粒度；③记录文件的传输进度；④记录传输中断点；⑤中断点续传

• 记录当前文件：不能单依靠文件名来进行设计，一般也不根据文件内容来标识（太复杂）。采用的方案是：文件名+文件修改时间+文件大小+浏览器ID的组合值来进行Hash计算，这样基本能满足所有需求。
• 规定文件切片粒度：HTML5中的File.slice(start,end)可以对文件进行切片处理。
• 记录文件传输进度：通过HTML可以计算文件上传的进度，已传输的文件可以不必再进行上传。
• 记录传输中断点：一旦发生故障，这个切片内文件未传输完，那么记录该切片的位置，下次重传的位置。
• 中断点续传：记录重传点，之后开始对文件未上传完的部分继续上传。

HTTPS保证安全

HTTP协议在使用的时候是进行一个明文传输的，这样不可避免的会出现三大问题：

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。
（2） 篡改风险（tampering）：第三方可以修改通信内容。
（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

HTTPS即HTTP+SSL协议，SSL，Secure Sockets Layer，安全套接字协议，现在实际使用中SSL已经被TLS替代。TLS，Transport Layer Security，安全传输层协议。使用这两个协议可以一定程度加强安全性。

• 证书加密：服务器在使用证书加密之前，需要向证书颁发机构CA申请证书。在HTTPS的连接过程中，服务器会把证书发送给客户端，客户端验证证书是否过期、合法等，以此来判定服务器的身份。虽然证书很多，但是CA机构是有限的，一般的操作系统都会将CA写到系统中，所以验证合法性其实很简单。
  • 验证合法性的操作：①首先根据证书层级关系找到上级证书；②服务器证书中存在一个证书指纹，利用上级证书的公钥解密证书指纹得到签名sign1；③通过签名算法算得服务器证书的签名sign2；④如果sign1==sign2则代表证书不是伪造的也没被篡改。

HTTPS的连接分为七个步骤：

1. Client Hello
2. Server Hello
3. 服务器发送证书
4. 客户端验证证书
5. 客户端生成随机数，通过证书中的公钥进行非对称加密，发送到服务器
6. 服务器使用私钥解密，获取到该随机数，将该随机数设置为密钥，使用对称加密加密需要发送的数据
7. 客户端解密数据，SSL通信开始

HTTPS在加密的过程中使用的是非对称加密，使用公钥对要进行传输的信息进行加密，再使用私钥可以对加密过后的信息进行解密（逆向也行）。不同于对称加密中加密解密使用的是相同的密钥，非对称加密即便公钥泄露也无法用公钥解密加密的信息。

不使用对称加密进行加密的原因：要对信息进行加密，那么客户端必须要接收到来自服务器的密钥，密钥的传输不加密等于没加密，密钥的传输加密也需要一个密钥，这样嵌套下去最终不是解决问题的办法。

事实上，非对称加密（公钥加密算法）通常用于首次连接的建立中，之后的数据加密考虑到速度问题一般使用到的是对称加密。解决方案：使用公钥加密算法加密以后要使用的公钥，之后使用公钥进行加密传输的数据。

实际上即便采用公钥加密的方式进行传输，还是可能会出现问题。在实际的网络使用中，BS双方都需要发送数据，所以双方各自都需要生成公钥和密钥，首次连接时需要交换各自的公钥。然后双方使用对方提供的公钥加密传输信息传输之后的数据。

考虑首次交换密钥的安全性，一旦首次交换密钥就发生中间人攻击，同时又无法确定密钥真伪性，就不能保证后续通讯安全了。

• 常用的对称加密算法：DES、AES、3DES、RC2、RC4
• 常用的非对称加密算法：RSA（最著名的公钥加密算法）、DSA、ECC
• 单向散列函数的加密算法：MD5、SHA

RSA加密算法

对于非对称加密，难点在于找到一对公钥私钥。利用公钥不可以推算出私钥，或者使用私钥不可以推算出公钥。这就要求找到一种不可逆的算法，加减乘除这样的计算是可逆的，知道其中的两个数（可以类比于加密信息、公钥或私钥的一个）可以推算出另外一个数。不可逆的计算最典型的就是取模计算。例如 10 % 3 = 1，知道1和3两个数字并不能知道目标数字就是10，所以是不可逆的。

要算出这个x的值，唯一方法就是遍历，小的数字范围是可行的，但是如果是这种：

这样的情况下基本不可能通过遍历的方法求结果。所以就称模运算是单向函数，不可逆计算。

如果要加密的内容是m，加密使用的密钥是e，加密之后的密文是c。要求出这个m只需要将c用解密的密钥d进行幂运算，再对N取模即可。

再将上面的两个公式合并，可以得到：

如何对e和d进行取值，需要用到欧拉定理：

欧拉函数：对于一个正整数n，小于n且和n互质的正整数（包括1）的个数，记作φ(n) 。

简单来说，φ(n) 就是算**[1,n)**范围的内的质因数个数。

将等式进行变换之后，可以得到下面的形式：

这个时候对比上面的加密解密过程，可以得到d和e的关系：

根据欧拉函数的性质，可以得到质数的欧拉函数结果等于本身-1，且两个质数的乘积的欧拉函数的值等于各自的欧拉函数结果乘积。根据这两个性质，一般计算欧拉函数的方法就是质因数分解（利用递归计算）。可以得到：

在这里e和n就作为加密的公钥，d就作为解密的私钥。例如：对字符a的加密解密过程

参考文档：对称加密与非对称加密，以及RSA的原理_LeeLu的博客-CSDN博客_rsa对称加密还是非对称
参考资料：探秘公钥加密算法 RSA_哔哩哔哩_bilibili

对称加密和非对称加密

• 对称加密，加密和解密使用的是同一把密钥。常用的对称加密算法：DES，AES，3DES
• 非对称加密，加密和解密使用的是不同的密钥，一把作为公开分享给加密方的叫做公钥，另一把不分享作为解密的私钥。公钥加密的密文只有私钥能进行解密；私钥加密的密文也只有公钥能进行解密。常见的非对称加密算法：RSA，ECC
• 在效率上来说，对称加密的效率显然更高，但是非对称加密的安全性更高。所以一般在实际的HTTPS加密过程中，首次连接使用的是公钥加密算法（非对称加密）来传输数据加密所要使用的对称加密的密钥，之后传输中使用的都是对称加密算法。

HTTP常见状态码

状态码	类别表	原因短语
1xx	Informational（信息性状态码）	接受的请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向）	需要进行附加操作以完成请求
4xx	Client error（客户端错误）	客户端请求出错，服务器无法处理请求
5xx	Server Error（服务器错误）	服务器处理请求出错

ARP协议和RARP协议

• ARP协议，Address Resolution Protocol，地址解析协议。根据IP地址找到设备的物理地址，ARP协议归属于网络层，因为IP协议中使用了ARP协议。

• RARP协议，Reverse Address Resolution Protocol，反向地址转换协议。根据MAC地址找到IP地址，现在一般使用DHCP协议，这个协议实现了RARP协议的功能。
• 每一台主机都设有一个ARP高速缓存（ARP cache），里面有本局域网上的各主机和路由器的IP地址到硬件地址的映射表，这些都是该主机目前知道的一些地址。
• ARP运行之时，使用协议在ARP映射表中查找目标IP的硬件地址。如果存在，则返回目标IP的MAC地址；反之：①向当前局域网广播目的IP发送ARP请求分组；②其他主机收到ARP请求分组；③目的主机收到ARP请求分组并响应；④请求主机将目的主机响应信息写入ARP映射表。