（高频面试题）计算机网络

---

参考链接：

1. 程序员大彬-计算机网络面试题总结
2. 计算机网络常见知识点&面试题（补充）
3. 面试/笔试第一弹 —— 计算机网络面试问题集锦
4. 两张动图-彻底明白TCP的三次握手与四次挥手
5. 深入理解HTTP协议
6. HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

---

1、网络分层结构

网络分层结构主要有两种，一种是OSI模型，分为七层，分别是物理层、数据链路层、网络层、会话层 、传输层、表示层 、应用层。但是七层模型复杂且不实用，目前我们所用的模型大部分都是第二种。

（注）向下传输为逐步封装的过程，向上为逐步拆封的过程。

TCP/IP五层模型：应用层、传输层、网络层、数据链路层、物理层。

应用层： 为应用程序提供交互服务。在互联网中的应用层协议很多，比如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等。
传输层： 负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
网络层： 为分组交换网上的不同主机提供通信服务，选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
数据链路层： 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，包含必要的差错控制信息等，在两个相邻节点间的链路上传送帧。
物理层： 实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。

2、三次握手（TCP建立连接）

2.1 什么是三次握手？

TCP三次握手：客户端（发送端）—> 服务端（接收端）
第一次握手： 客户端-发送带有 SYN 标志的数据包，表示客户端要和服务端建立连接，服务端知道了客户端的发送功能是正常的，自己的接收功能是正常的。
第二次握手： 接收端-发送带有 SYN/ACK 标志的数据包，表示服务端接收到了客户端的连接请求了，客户端知道服务端和自己的收发功能都正常，服务端只知道客户端发送功能正常，自己的接收功能正常。
第三次握手： 客户端-发送带有 ACK 标志的数据包，表示我知道你收到了我的连接请求了，第三次握手之后，客户端知道服务端和自己收发功能正常，服务端也知道了客户端和自己的收发功能正常，表示可以开始进行数据传输了。

2.2 为什么要进行三次握手？两次行不行？

从上面三次握手干的事情，才能让双方都知道彼此的收发功能是正常的，所以三次握手缺一不可。
两次握手是不可以的，为了防止 已失效的连接请求报文突然又传送到了服务端，因而产生错误。

• 比如客户端A发出连接请求，可能因为网络阻塞原因，A没有收到确认报文，于是A再重传一次连接请求。
• 连接成功，等待数据传输完毕后，就释放了连接。
• 然后A发出的第一个连接请求等到连接释放以后的某个时间才到达服务端B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段。
• 如果不采用三次握手，只要B发出确认，就建立新的连接了，此时A不会响应B的确认且不发送数据，则B一直等待A发送数据，浪费资源。

2.3 第 2 次握手传回了 ACK，为什么还要传回 SYN？

• 接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。
• 而回传 SYN 则是为了建立并确认从服务端到客户端的通信，表示服务端说我也要和你建立连接。

3、四次挥手（TCP断开连接）

3.1 什么是四次挥手？

第一次挥手： 客户端-发送一个带有 FIN 标志的数据包，用来关闭客户端到服务器的数据传送，表示我要和你断开连接了。
第二次挥手： 服务器-收到这个 FIN 数据包之后，它发回一个带有 ACK 标志的数据包，表示服务端收到了客户端的断开连接请求。
第三次挥手： 服务器-发送一个带有 FIN 标志的数据包给客户端，关闭与客户端的连接，表示服务端也要断开连接了。
第四次挥手： 客户端-发回 ACK 报文确认，表示客户端收到了服务端也要断开连接的请求了。第四次挥手之后客户端还要再等待 2 * MSL（报文最大生存时长）时间之后才变成 closed 状态。

3.2 为什么建立连接是三次握手，关闭连接是四次挥手呢？

因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送SYN+ACK 报文。

• 当 Server 端收到 Client 端发出的连接释放报文时，服务端可能还有数据没有发送完成，很可能并不会立即关闭SOCKET，所以 Server 端先回复一个 ACK 报文，告诉 Client 端我收到你的连接释放报文了。
• 只有等到 Server 端所有的报文都发送完了，这时 Server 端才能发送连接释放报文，之后两边才会真正的断开连接。
• 故需要四次挥手。即服务端的 ACK 和 FIN 分开发送，所以多了一次挥手。

3.3 第四次挥手为什么要等待2MSL？

• 保证客户端发送的最后一个 ACK 报文段能够到达服务端。因为客户端最后发出的这个 ACK 报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出 ACK 回应报文，并且会重启2MSL计时器。
• 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

4、TCP 和 UDP 协议（传输层）

4.1 区别

1. TCP面向连接；UDP是无连接的，即发送数据之前不需要建立连接。
2. TCP可靠；UDP不可靠。
3. TCP面向字节流；UDP是面向报文的。
4. TCP有拥塞控制；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如实时视频会议等）。
5. TCP只能是点对点的通信；UDP支持一对一、一对多、多对一和多对多的通信方式。
6. TCP首部开销20字节；UDP的首部开销小，只有8个字节。

4.2 TCP 协议流量控制（滑动窗口机制）

• 流量控制是为了控制发送方发送速率，保证接收方来得及接收。
• 接收方发送的确认报文中的 windows 字段可以用来控制发送方窗口大小，发送方的发送窗口不可以大于接收方发回的窗口大小，从而影响发送方的发送速率。
• 将窗口字段设置为 0，则发送方不能发送数据。
• 考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。
• 解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

4.3 TCP 协议拥塞控制

• 拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。
• 为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。
• 发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一个。

4.3.1 四种拥塞控制方法

慢开始( slow-start )：

• 不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小；
• 初始时候的拥塞窗口设置为1，每经过一个传输轮次，拥塞窗口就加倍。

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当 cwnd < ssthresh时，使用慢开始算法。

当cwnd > ssthresh时，改用拥塞避免算法。

当cwnd = ssthresh时，慢开始与拥塞避免算法任意。

拥塞避免( congestion avoidance )：

• 当拥塞窗口大于慢开始门限的时候，使用拥塞避免算法；
• 拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加1，而不是加倍，保证拥塞窗口按线性规律缓慢增长；
• 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。
• 这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传( fast retransmit )：

• 快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。
• 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复( fast recovery )：

• 当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半；
• 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。接着把拥塞窗口 cwnd 值设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

慢开始算法只是在TCP连接建立时和网络出现超时时才使用。快恢复方法使得TCP的性能有明显的改进。
当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

5、ARP协议（网络层）

ARP解决了同一个局域网上的主机和路由器IP和MAC地址的解析。

• 每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
• 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
• 网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址。
• 源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。
• 如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

6、HTTP 协议（应用层）

超文本传输协议（HTTP，HyperText Transfer Protocol) 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示。

6.1 HTTP协议的特点

1. 支持客户端/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径，每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。早期这么做的原因是请求资源少，追求快。后来通过Connection: Keep-Alive实现长连接
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。对于客户端每次发送的请求，服务器都认为是一个新的请求，上一次会话和下一次会话之间没有联系。

6.2 HTTP报文格式

6.2.1 请求报文格式

HTTP请求由请求行、请求头部、空行和请求体四个部分组成。

请求行：包括请求方法，访问的资源URL，使用的HTTP版本。常用的有 get 和 post 方法。
请求头：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
空行：最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。
请求体：用户的请求数据如用户名，密码等。

请求报文示例：

POST /xxx HTTP/1.1 		请求行
Accept:image/gif.image/jpeg, 	请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 		请求体

6.2.2 响应报文格式

HTTP响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

状态行：协议版本，状态码及状态描述。
响应头：类似于请求头，响应头字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified、Cache-Control、Expires。
响应体：服务器返回给客户端的内容。

响应报文示例：

HTTP/1.1 200 OK 	状态行
Server:Apache Tomcat/5.0.12 	响应头
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>响应体</body>
</html>

6.3 HTTP状态码有哪些（常用五大类）

• 1xx：提示信息，表示服务器已接收了客户端请求，可以继续发送请求;
• 2xx：成功，表示服务器已成功接收到请求并进行处理;
• 3xx：重定向，表示服务器要求客户端重定向;
• 4xx：客户端错误，表示客户端的请求有非法内容;
• 5xx：服务器错误，表示服务器未能正常处理客户端的请求而出现意外错误，一段时间后可能会恢复正常。

6.4 POST和GET的区别（HTTP 请求方法）

• GET一般用于从服务器获取资源，而POST有可能改变服务器上的资源；
• GET是幂等的，即读取同一个资源，总是得到相同的数据，POST不是幂等的，可能会修改服务器的资源；
• 请求形式不同：GET请求参数通过URL传递，POST的参数放在请求体中。
• 数据包发送个数：GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把请求头和请求体一并发送出去；而对于POST，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体。
• 编码格式：GET请求只能进行 url 编码，而POST支持多种编码方式。
• 安全性：GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留，安全性相对较高。
• 数据大小：GET的长度有限制（操作系统或者浏览器），而POST数据大小无限制。

6.5 HTTP长连接和短连接

• HTTP1.0 默认使用的是短连接。浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
• HTTP/1.1 起，默认使用长连接。要使用长连接，客户端和服务器的HTTP首部的 Connection 都要设置为 keep-alive，才能支持长连接。HTTP长连接，指的是复用 TCP 连接。多个HTTP请求可以复用同一个TCP连接，这就节省了 TCP 连接建立和断开的消耗。

6.6 HTTP1.1 和 HTTP2.0 的区别

HTTP2.0相比HTTP1.1支持的特性：

• 新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
• 多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
• 头部压缩：HTTP1.1 的 header 带有大量信息，而且每次都要重复发送；HTTP2.0 把header从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求a发送了所有的头信息字段，请求b则只需要发送差异数据，这样可以减少冗余数据，降低开销。
• 服务端推送：HTTP2.0 允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

6.7 什么是cookie和session？

由于HTTP协议是无状态的协议，需要用某种机制来识具体的用户身份，用来跟踪用户的整个会话。常用的会话跟踪技术是cookie与session。

cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。

Session 的主要作用就是通过服务端记录用户的状态。浏览器端每次请求时，都会带着一个 sessionid，服务器根据这个 sessionid 就可以找得到对应的session，以此来达到共享数据的目的。 这里需要注意的是，session不会随着浏览器的关闭而死亡，而是等待超时时间。

6.8 Cookie和Session的区别？

1. 作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
2. 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
3. 隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
4. 存储大小不同， 单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

7、HTTPS协议（应用层）

7.1 HTTPS原理

首先是TCP三次握手，然后客户端发起一个HTTPS连接建立请求，客户端先发一个Client Hello的包，然后服务端响应Server Hello，接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加解密数据。

1. 协商加密算法 。在Client Hello里面客户端会告知服务端自己当前的一些信息，包括客户端要使用的 TLS 版本，支持的加密算法，要访问的域名，给服务端生成的一个随机数（Nonce）等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来。
2. 服务端响应Server Hello，告诉客户端服务端选中的加密算法。
3. 接着服务端给客户端发来了2个证书。第二个证书是第一个证书的签发机构（CA）的证书。
4. 客户端使用证书的认证机构CA公开发布的RSA公钥对该证书进行验证。
5. 验证通过之后，浏览器和服务器通过密钥交换算法产生共享的对称密钥。
6. 开始传输数据，使用同一个对称密钥来加解密。

7.2 什么是数字证书

服务端可以向证书颁发机构CA申请证书，以避免中间人攻击（防止证书被篡改）。证书包含三部分内容：证书内容、证书签名算法和签名，签名是为了验证身份。

服务端把证书传输给浏览器，浏览器从证书里取公钥。证书可以证明该公钥对应本网站。

数字签名的制作过程：

1. CA使用证书签名算法对证书内容进行hash运算。
2. 对hash后的值用CA的私钥加密，得到数字签名。

浏览器验证过程：

1. 获取证书，得到证书内容、证书签名算法和数字签名。
2. 用CA机构的公钥对数字签名解密（由于是浏览器信任的机构，所以浏览器会保存它的公钥）。
3. 用证书里的签名算法对证书内容进行hash运算。
4. 比较解密后的摘要和对证书内容做hash运算后得到的摘要，相等则表明证书可信。

7.3 什么是对称加密和非对称加密？

对称加密： 通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有AES和DES算法。

非对称加密：它需要生成两个密钥，公钥和私钥。公钥是公开的，任何人都可以获得，而私钥是私人保管的。公钥负责加密，私钥负责解密；或者私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA和DSA。

8、HTTPs 与 HTTP 的区别

1. HTTP 是超文本传输协议，信息是明文传输；HTTPS则是具有安全性的ssl 加密传输协议。
2. HTTP 和 HTTPS用的端口不一样，HTTP端口是 80，HTTPS是 443。
3. HTTPS协议需要到 CA 机构申请证书，一般需要一定的费用。
4. HTTPS由于加密解密会带来更大的CPU和内存开销。

9、DNS 的解析过程（传输层）

1. 浏览器搜索自己的 DNS 缓存
2. 若没有，则搜索操作系统中的 DNS 缓存和 hosts 文件
3. 若没有，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的 DNS 缓存，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回 IP 地址给本地域名服务器
4. 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己也将 IP 地址缓存起来
5. 操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来
6. 浏览器得到域名对应的 IP 地址

10、浏览器中输入URL返回页面过程？

1. DNS解析：解析域名，找到主机 IP。
2. TCP连接：浏览器利用 IP 直接与网站主机通信，三次握手，建立 TCP 连接。浏览器会以一个随机端口向服务端的 web 程序 80 端口发起 TCP 的连接。
3. 发送HTTP请求：建立 TCP 连接后，浏览器向主机发起一个HTTP请求。
4. 服务器处理请求并返回HTTP报文：服务器响应请求，返回响应数据。
5. 浏览器解析渲染页面：浏览器解析响应内容，进行渲染，呈现给用户。
6. 连接结束