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

一、网络的七层模型和四层模型

1.七层模型

概念：

网络的七层模型也称作 OSI(Open Systems Interconnection) 模型，是由国际标准化组织 (ISO) 提出的，分为七层。七层协议的设计目的则是为了实现理论标准化，为不同厂商的网络设备提供统一的通信标准；OSI 模型是理论性框架，适合学习网络原理。

分层：

• 物理层（Physical Layer）：传输原始比特流（如电缆、光纤等）；
• 数据链路层（Data Link Layer）：数据帧的封装与本地网络传输（如MAC地址）；
• 网络层（Network Layer）：路由选择与逻辑寻址（如IP地址）；
• 传输层（Transport Layer）：端到端可靠传输（如TCP、UDP）；
• 会话层（Session Layer）：管理会话（如建立、维护、终止连接）；
• 表示层（Presentation Layer）：数据格式转换、加密/解密（如ASCII、JPEG）；
• 应用层（Application Layer）：用户接口（如HTTP、HTTS、FTP）。

2.四层模型

概念：

四层模型也是我们常说的 TCP/IP 模型，其是基于互联网早期协议（TCP/IP）发展而来，注重实用性，由实际应用驱动，分层更灵活，合并了功能相近的层，降低复杂性；TCP/IP 模型是实践标准，支撑现代互联网。

分层：

• 网络接口层（Network Interface Layer）：对应OSI的物理层+数据链路层；
• 网际层（Internet Layer）：对应OSI的网络层（如IP协议）；
• 传输层（Transport Layer）：与OSI传输层一致（如TCP、UDP）；
• 应用层（Application Layer）：合并了OSI的应用层、表示层、会话层（如HTTP、DNS）。

二、浏览器输入 URL 发生了什么

1.HTTP 请求

• 首先网络进程在收到 url 请求后，会检查本地缓存中是否存在该请求的资源，有的话直接返回，没有的话网络进程会对 Web 服务器发起 HTTP 请求（网络请求）。

2.DNS 解析

• 网络请求前，我们要获取请求域名的IP地址，因此就需要进行DNS解析，在了解 DNS 解析之前，首先了解一下 DNS 域名的层级关系（图片来源：小林coding），其中包含根 DNS 服务器（.）、顶级域 DNS 服务器（.com）、 权威 DNS 服务器（server.com）。
  
• DNS 解析时候首先会按照本地 DNS 缓存-操作系统的 DNS 缓存表-本地 host 文件的优先级查看缓存，如果有的话会直接返回请求域名的 IP 地址；
• 如果没查到缓存，DNS 就会到根作用域中查询，根作用域识别到后缀是 .com 就会给本地 DNS 提供顶级作用域的地址，以相同的方式会通过权威 DNS 服务器得知 IP 地址。
  下图为整个 DNS 解析的过程（图片来源：小林coding）。
  

3.协议栈

解析到对应的IP地址之后，会根据操作系统中的协议栈一步步进行操作（图片来源：小林coding）。

• TCP：首先到传输层，选择对应的传输协议 TCP/UDP，在 TCP 传输数据之前会进行三次握手进行客户端与服务器的连接，TCP 在执行链接、收发、断开等各阶段操作时，都需要委托IP模块将数据封装成网络包发送给通信对象，因此就需要网络层的支持；
• IP：到网络层后，通过对应的 IP 地址进行连接，但是我们的客户端到服务器还有很长的路要走，其中就需要路由器的支持；
• MAC：定位到 Web 服务器之后，信息还不能在以太网中传输，所以还需要数据链路层将信息封装成 MAC帧，再转换成电信号进行传输。

4.服务器处理请求

• 连接成功后服务器会收到请求信息，根据请求生成响应数据，浏览器会解析响应头，如果状态码为 301、302的话就会进行重定向到新地址；
• 若状态码为 200 的话，响应数据类型是字节流类型，一般会请求交给下载管理器，若是 HTML 类型会进行下一步渲染流程，浏览器会解析 HTML 文件，创建 DOM 树，解析 CSS 进行样式计算，然后将 DOM 树和 CSS 合并，构建渲染树，最后布局和绘制渲染树，完成页面展示。

三、HTTP 状态码

1.2xx

• 200：成功，一切正常；
• 204：和 200 基本相同，响应头没有 body 数据；
• 206：表示返回的 body 数据并不是资源的全部，而是其中的一部分。

2.3xx

• 301：表示永久重定向，资源已经不存在了，需要访问别的url；
• 302：表示临时重定向，资源还存在，但是暂时需要访问别的url；
• 304：协商缓存，表示资源未修改，可以走缓存。

3.4xx

• 400：表示客户端请求报文的错误，是一个笼统的错误表示；
• 403：表示服务器禁止访问，不是客户端的问题；
• 404：客户端的问题，请求的资源不存在。

4.5xx

• 500：和400一样，笼统的错误码；
• 501：表示请求的功能还不支持，类似于即将开业的意思；
• 502：表示服务器自身正常，访问后端的时候出错了；
• 503：服务器正忙，暂时无法响应客户，类似于网络繁忙，稍后重试的意思。

四、HTTP 的特点

1.简单、跨平台

• 基本报文格式是 header+body，header 也是 key-value 格式，易于理解。

2.易于扩展

• 在 OSI 模型的最上层（第七层），它下面的部分是可以变化的，比如 HTTPS 在 HTTP 和 TCP 之间加了 SSL/TSL 安全传输层。

3.无状态

• 有好有坏，节约资源、减轻服务器的负担，但是由于是无状态，所以完成关联性操作会很麻烦，比如加入购物车-下单-支付，每一个流程都要确认信息，所以就引入了人 Cookie 和 Session 来解决。

4.明文传输

• 也是有好有坏，好理解但是不安全，HTTPS 可以解决。

五、HTTP 缓存

HTTP 缓存可以减少不必要的网络传输，节约带宽，更快的加载页面，减少服务器负载，避免服务过载的情况出现。

1.强制缓存

强制缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边，无需与服务器做任何通讯；
强制缓存是利用两个 HTTP 响应头部字段实现的 Cache-Control（是一个相对时间）、Expires（是一个绝对时间），都用来表示资源在客户端缓存的有效期，如果 HTTP 响应头同时存在这两个字段的话，Cache-Control 的优先级高于 Expires；

• 当浏览器第一次请求访问服务器的时候，服务器会在返回这个资源的同时，在 response 头部加上Cache-Control，其中设置了过期时间大小；
• 浏览器再次请求访问该服务器的资源的时候，会通过请求资源的时间与 Cache-Control 中设置过的过期时间大小，来计算是否过期，如果没有过期就会用缓存，如果过期就会重新请求服务器，服务器返回的时候又会更新 Cache-Control；

2.协商缓存

如果请求的响应码是 304，这个是告诉浏览器可以使用本地缓存，通常这种通过服务端告诉客户端是否可以使用缓存的方式被称为协商缓存，协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存；
协商缓存可以基于两种头部来实现，协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未命中强制缓存的情况下，才能发起带有协商缓存的请求字段；

2.1第一种

请求头部中的 IF-Modified-Since 字段与响应头部中的 Last-Modified 字段实现。

• Last-Modified 表示这个响应资源的最后修改时间；
• 当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 IF-Modified-Since 则与被请求资源的最后修改时间进行对比，如果最后修改时间较新，说明资源被修改过，返回最新资源 HTTP 200 ok，如果最后修改时间较旧，说明资源没有修改，响应 HTTP 304 走缓存。

第二种

请求头部中的 IF-None-Match 字段与响应头部中的 ETag 字段。

• ETag 表示唯一标识响应资源；
• 当资源过期的时候，浏览器发现响应头里面的 ETag 字段，则再次向服务器发起请时，会将请求头 IF-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有发生变化就返回 304，如果变化了就返回 200；

2.3两种协商缓存的区别

第一种方式是基于时间实现的，第二种方式是基于一个唯一标识实现的，相对来说，后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。
如果在第一次请求资源的时候，服务端返回的 HTTP 响应头部同时有 ETag 和 Last-Modified 字段，那么客户端在下一次请求的时候，如果带上了 ETag 和 Last-Modified 字段信息给服务端，这时 ETag 的优先级更高，服务端会先判断 ETag 有没有变化，有的话直接返回 200，没有的话再去判断 Last-Modified。

2.3.1为什么 ETag 的优先级会更高呢

因为 ETag 解决了 Last-Modified 比较难解决的问题：

• 在没有修改文件内容的情况下，修改时间可能也会变，会导致客户端认为资源发生变动，从而重新请求；
• 可能有些资源是在秒级别内修改的，而 IF-Modified-Since 能检查到的粒度是秒级别的，使用 ETag 就能保证在秒级别内刷新多次；
• 有些服务器可能不能精确获取资源的最后修改时间。

2.3.2ETag 字段实现协商缓存的过程

• 首先浏览器第一次发起请求的时候，服务器响应会加上 ETag 字段，这个唯一标识是由当前请求资源生成的；
• 当浏览器再一次发起请求的时候，首先会检查强制缓存有没有过期，没有过期直接使用缓存，过期的话会在request 头部上加上 IF-None-Match 字段，该字段的值就是 Etag 唯一标识；
• 服务器收到请求之后会对 ETag 唯一标识进行对比，如果相等就返回 304 Not Modified，不相等的话返回200 状态码和资源，并在 response 头部加上新的 ETag 唯一标识；
• 浏览器收到响应后，如果是 304 就使用缓存，不是的话就更新资源。

2.3.3ETag有什么缺点

• 服务端计算开销很大，如果资源过大就会影响服务器性能；
• ETag 有强验证和弱验证，强验证就是根据每个字节来计算哈希码，有一个字节变了都会引起 ETag 的变化，弱验证就是提取文件的部分属性来计算哈希码，这种方式速度快，但准确率会有所降低，会降低协商缓存的有效性；

六、HTTP 各版本的区别

1.HTTP/1.1

1.1改进：

• HTTP/1.1 相对于HTTP/1.0 来说，HTTP/1.1 引入了长连接（默认启用 Connection: keep-alive，该字段是 HTTP 头部字段，用于指示客户端和服务器在完成一次请求和响应后保持 TCP 连接打开，以便后续请求复用该连接，从而减少频繁建立和关闭连接的开销），允许在同一个连接上发送多个请求和响应，减少了连接建立和关闭的开销，提升了性能；
• 支持管道网络传输，只要一个请求出去了不必等其回来，就可以发送第二个请求，可以减少整体响应时间。

1.2缺点：

• 对头阻塞：HTTP/1.1 使用串行请求-响应模型，即在一个连接上，请求必须按顺序发送和接收。如果前一个请求的响应未完成，后续请求会被阻塞；在高延迟或资源加载较多的场景（如网页加载），队头阻塞会导致性能下降；
• 冗余头部信息：HTTP/1.1 的请求和响应头部是纯文本形式，未经压缩就发送，首部信息越多延迟越大，且每次请求都会重复发送相同的头部信息（如 User-Agent、Cookie 等）；增加了网络传输的开销，尤其在移动网络或高延迟环境下，性能影响显著；
• 不支持服务器推送：HTTP/1.1 是纯粹的请求-响应模型，服务器无法主动向客户端推送数据，客户端长时间得不到请求的话也就相当于对头阻塞了；对于需要实时更新的应用（如聊天、实时通知），必须依赖轮询或长轮询，增加了额外开销；
• 缺乏优先级机制：HTTP/1.1 无法为请求设置优先级，所有请求被视为同等重要；在加载网页时，关键资源（如 CSS、JavaScript）可能被非关键资源（如图片）阻塞，影响用户体验。

2.HTTP/2

2.1改进：

• 二进制协议：HTTP/2 不再像 HTTP/1.1 里的纯文本形式报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧：头信息帧和数据帧，增加了传输的效率；
• 多路复用：在同一个 TCP 连接上，可以同时传输多个请求和响应，而无需按顺序等待；解决了 HTTP/1.1 的队头阻塞问题；提高了连接利用率，减少了延迟；
• 头部压缩：使用 HPACK 算法对 HTTP 头部进行压缩，减少了重复头部信息的传输（如 Cookie、User-Agent），降低了带宽开销，尤其对移动设备更友好； HPACK算法就是在客户端和服务器同时维护一张头信息表，所有字段都会存到这个表，生成一个索引号，以后就不发送同样的字段了，只发送索引号，这样就提高了速度；
• 并发传输：HTTP/2 引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接，针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同的Stream 的帧可以乱序发送，因此可以并发不同的 Stream，也就是 HTTP/2 可以并行交错地发送请求和响应；
• 服务器主动推送资源：客户端和服务器都可以建立 Stream，客户端建立的 Stream ID 是奇数、服务器建立的 Stream ID 是偶数；减少了客户端发现资源并请求的延迟；提升了页面加载速度（例如提前推送 CSS、JavaScript 文件）；
• 优先级控制：允许客户端为请求设置优先级，服务器可以根据优先级调整资源传输顺序；确保关键资源（如 HTML、CSS）优先加载，提升用户体验；优化了资源分配，避免非关键资源阻塞关键资源；
• 流量控制：HTTP/2 支持基于流的流量控制，可以更精细地管理数据传输；防止单个流占用过多带宽，确保公平性，提升了连接的稳定性和效率。

2.2缺点：

• 队头阻塞：HTTP/2 解决了 HTTP/1.1 中存在的 HTTP 层的队头阻塞问题，但依旧存在 TCP 层的队头阻塞问题。 HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区的数据返回给 HTTP 应用，那么当前一个字节数据没有到达，后收到的字节数据只能存放在内核缓冲区里，只有等这一个字节数据到达的时候，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 对头阻塞问题；

3.HTTP/3

3.1改进：

• 基于 UDP：HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP，避免了 TCP 的队头阻塞问题，连接建立更快，减少了握手延迟；虽然 UDP 是不可靠的传输协议，但是基于UDP的QUIC协议可以实现类似TCP的可靠性传输。 QUIC 有自己的一套机制可以保证传输的可靠性。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。HTTP/2 中只要某个流中的数据包丢失了，其他流也会受到影响，所以 QUIC 链接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响；
• 内置加密：QUIC 协议默认集成了 TLS 1.3，所有 HTTP/3 通信都是加密的；
• 改进的链接迁移：QUIC 使用连接 ID 而不是 IP 地址和端口来标识连接，当客户端 IP 地址发生变化（如从 Wi-Fi 切换到移动网络）时，连接可以无缝迁移，无需重新建立，对移动设备很友好；
• 更简单的协议栈：HTTP/3 将传输层和加密层合并到 QUIC 协议中，减少了协议栈的复杂性，降低了实现和部署的难度，减少了协议之间的交互开销，可以将 QUIC 理解为一个在 UDP 之上的TCP+TLS+HTTP/2 的多路复用协议；

3.2缺点：

• HTTP/3 在性能、安全性和可靠性方面有非常显著的改进，如果谈缺点，可能就是部署的复杂性、网络中间件兼容性问题、CPU 的内存开销、协议成熟度等；

七、HTTP 和 HTTPS 的区别

1.端口

• HTTP的默认端口号是80，而HTTPS是443；

2.安全性

• HTTP是没有加密的超文本传输协议，无论是 POST 还是 GET 请求，请求头和请求体的信息都是明文传输，存在安全风险问题；
• HTTPS则是为了解决HTTP不安全的问题，在 TCP 和 HTTP 之间加入了 SSL/TLS 协议，使得报文能够加密传输；

3.建立连接的方式

• HTTP 连接建立相对简单，比 HTTPS 快， TCP 三次握手之后便可进行 HTTP 的报文传输；
• HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输；

4.耗费资源

• HTTPS 协议需要向 **CA（证书权威机构）**申请数字证书，来保证服务器的身份是可信的，因此需要一定的费用；
• 由于 HTTPS 除了有更多的握手之外还涉及在发送方加密和接收方解密的过程，该过程涉及复杂的数学运算，因此会在服务器和客户端上消耗更多的 CPU 资源；
• HTTPS 加密后的数据是要比明文数据更大的，因此在传输的过程中会占用更多的带宽和网络资源；
• 由于 HTTPS 数据加密的特性，代理服务器和 CDN 是无法有效地缓存 HTTPS 的内容信息，因此会有更多服务器请求，服务器需要频繁的为每个请求生成和提供内容，一定程度上增加了服务器的消耗。

5.使用场景

• HTTP 适用于不涉及敏感信息的场景（如静态网站、内部测试环境）,HTTPS 适用于涉及敏感信息的场景（如登录、支付、数据传输）。

八、HTTPS 的原理

HTTPS 的原理是通过在 HTTP 和 TCP 之间加入 TLS/SSL 加密层，实现数据的加密传输和服务器身份验证。

1.TLS/SSL 加密层

• HTTPS 的核心是 TLS/SSL 协议，其主要负责加密数据（确保传输的数据无法被窃听或篡改）、身份验证（验证服务器的身份，防止中间人攻击）、数据完整性（确保数据在传输过程中未被篡改）。

2.HTTPS 的工作流程

2.1客户端发起请求：

• 客户端（如浏览器）向服务器发送一个 HTTPS 请求（例如https://blog.youkuaiyun.com/ccccccking）；
• 客户端会检查服务器的域名是否与证书中的域名匹配。

2.2服务器返回证书：

• 服务器将自己的 SSL/TLS 证书发送给客户端；
• 证书中包含服务器的公钥、证书颁发机构（CA）的信息以及证书的有效期等。

2.3客户端验证证书：

• 客户端使用内置的受信任的 CA 根证书验证服务器证书的有效性：检查证书是否由受信任的 CA 签发、检查证书是否在有效期内、检查证书中的域名是否与请求的域名一致；
• 如果验证失败，客户端会显示警告（如“此连接不安全”）。

2.4密钥交换：

• 客户端生成一个随机的对称密钥（称为会话密钥），用于后续的加密通信；
• 客户端使用服务器的公钥加密会话密钥，并发送给服务器；
• 服务器使用自己的私钥解密，获取会话密钥。

2.5加密通信：

• 客户端和服务器使用会话密钥进行对称加密通信；
• 对称加密比非对称加密效率更高，适合大量数据传输。

2.6数据传输：

• 客户端和服务器之间的所有数据都通过对称加密算法（如 AES）加密传输，即使数据被截获，攻击者也无法解密。

3.TLS/SSL 的加密机制

• 非对称加密（用于密钥交换）：使用公钥加密，私钥解密，常见的算法有RSA、ECC；
• 对称加密（用于数据传输）：使用相同的密钥进行加密和解密，常见算法有 AES。

4.TLS/SSL 握手过程

• Client Hello：客户端向服务器发送支持的 TLS 版本、加密算法列表和一个随机数（Client Random）；
• Server Hello：服务器选择一个 TLS 版本和加密算法，并返回一个随机数（Server Random）和服务器证书；
• 证书验证：客户端验证服务器证书的有效性；
• 密钥交换:客户端生成一个预主密钥（Pre-Master Secret），用服务器的公钥加密后发送给服务器，服务器使用私钥解密，获取预主密钥；
• 生成会话密钥：客户端和服务器使用 Client Random、Server Random 和预主密钥生成相同的会话密钥；
• 客户端完成：使用会话密钥加密的完成消息（Finished Message）；
• 服务器完成：使用会话密钥加密的完成消息（Finished Message）；
• 握手完成：客户端和服务器验证对方的完成消息。

九、GET 和 POST 的区别

1.作用不同

• GET用来获取资源、POST用来向服务器提交数据。

2.参数传递方式不同

• GET一般在URL中,POST一般放在请求体中，对数据类型没要求。

3.参数长度不同

• GET传输的数据要求不大于2KB，POST一般不做限制。

4.缓存机制不同

• GET请求会被浏览器主动缓存，POST不会；
• GET请求的参数会被完全保留在历史记录里面，POST不会；
• GET请求的内容我们一般可以保存为书签。

5.消耗时间

• GET 浏览器会把 header 和数据一起发送出去，而 POST 浏览器先响应 100 continue 之后，再发送数据。

6.安全性

• 从参数传递角度来看 GET 不安全，因为都在 URL 里面，但是从对数据篡改的安全性考虑，GET 是安全的，因为不会对资源作出修改；
• 无论是 GET 还是 POST，如果使用 HTTP 协议，数据都是以明文传输，都是不安全的。

7.幂等性

• GET是幂等的，因为是只读操作，每次结果都一样；
• POST新增或提交数据，会修改服务器的资源，多次提交就会创建多个资源，所以不幂等。

8.使用场景

• Post：传输敏感信息（如密码、支付信息）、提交表单数据、上传文件或大量数据；
• Get：请求不敏感的数据（如搜索查询、分页参数）、幂等操作（如获取资源）。

十、Session、Cookie、Token 的理解

1.Session

1.1Session 定义：

• Session 是服务器端存储的用户状态信息，通常与客户端的 Cookie 配合使用；
• 服务器会为每个用户创建一个唯一的 Session ID，并通过 Cookie 发送给客户端。

1.2Session 特点：

• 数据存储在服务器端（如内存、数据库）；
• 客户端只存储 Session ID（通常通过 Cookie），服务器根据 Session ID 查找对应的用户数据。

1.3用途：

• 管理用户登录状态，存储用户会话数据（如购物车信息）。

1.4安全性：

• 比 Cookie 更安全，因为敏感数据存储在服务器端。

2.Cookie

2.1定义：

• Cookie 是服务器发送到客户端（通常是浏览器）的一小段数据，客户端会存储并在后续请求中自动发送回服务器；

2.2特点：

• 存储在客户端（浏览器）；
• 每次请求时会自动附加到 HTTP 头部（Cookie 字段）；
• 可以设置过期时间（会话 Cookie 或持久 Cookie）。

2.3用途：

• 跟踪用户会话（如 Session ID）、保存用户偏好设置；
• 实现简单的身份验证。

2.4安全性：

• 容易被窃取（如 XSS 攻击），可以通过 HttpOnly 和 Secure 标志提升安全性。

3.Token

3.1定义：

• Token 是一种用于身份验证和授权的令牌，通常采用 JWT（JSON Web Token） 格式；
• Token 包含用户信息和签名，由服务器生成并发送给客户端。

3.2特点：

• 存储在客户端（如 Cookie）；
• 客户端需要在每次请求时手动附加 Token（通常在 Authorization 头部）；
• Token 是自包含的，服务器无需存储会话信息。

3.3用途：

• 无状态身份验证（如 RESTful API）、跨域身份验证（如单点登录）。

3.4安全性：

• 需要防范 XSS 和 CSRF 攻击，可以通过 HTTPS 和短期 Token 提升安全性。

4总结

十一、TCP 三次握手和四次挥手

1.TCP 三次握手

1.1三次握手过程

• 第一次握手，客户端发送 SYN：客户端首先会初始化序列号 Seq（随机生成），把序列号置于 TCP 首部的序号字段中，并把 TCP 首部中的 SYN 字段置于 1，接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用数据，然后客户端处于 SYN-SENT 状态；
• 第二次握手，服务器发送 SYN-ACK：服务端收到客户端的 SYN 报文后，也会初始化序列号 Seq，将序列号填入 TCP 首部的序号字段中，然后把首部中的确认应答号填入客户端序列号 +1，然后把 SYN 和 ACK 字段都置于 1，然后把该报文发送给客户端，该报文也不包含应用数据，之后服务端处于 SYN-RECEIVED 状态；
• 第三次握手，客户端发送ACK：客户端收到服务端的报文之后，还需要给服务端回应一个报文，确认应答号填入服务端序列号 + 1，SYN 和 ACK 标志位置于 1，最后把报文发给服务端，这次是可以携带客户端到服务端的数据的，之后客户端处于 ESTABLISHED状态，服务端收到确认应答报文后也进入 ESTABLISHED 状态；
  （图片来源：小林coding）
  

1.2为什么一定是三次握手，而不是两次或者四次

• 确保双向通信：第一次握手客户端确认自己可以发送数据、第二次握手服务器确认自己可以接收和发送数据、第三次握手客户端确认自己可以接收数据；
• 避免资源浪费；
• 防止历史的连接初始化：避免因网络延迟导致的旧连接请求被误认为是新连接，具体场景如：客户端先发送了 SYN1 报文，表示请求连接，然后这个报文被网络阻塞了，同时客户端崩了，客户端重启后又发送了新的 SYN2 表示请求连接（新的和重传不一样，重传序列号是一样的，新的就是全新的），然后此时旧的 SYN1 先到了，然后服务器发送 SYN+ACK 给客户端，结果客户端发现并不是自己预期的确认应答号，因此就会给服务器回一个 RST 报文，服务端收到后就会释放连接，等新的 SYN2 到了又会重新开始建立连接；

1.3握手过程中丢失了会发生什么

• 第一次握手丢失：如果客户端收不到第二次握手的报文，就会超时重传，这个时间是在操作系统内核定死的，有 1 秒也有 3 秒的，如果过了这个时间没收的话就会重传 SYN，序列号一样，重发次数的默认值是 5，是可以通过参数控制重传次数的，下一次重传的时间间隔是上一次的两倍，最后一次重传后会再等两倍的时间，还没收到的话就会断开连接了；
• 第二次握手丢失：客户端和服务端都会超时重传，客户端收不到第二次握手的报文，就会觉得是自己丢失了，也会重传，而服务端收不到第三次握手的报文，也会觉得自己丢失，也会超时重传；
• 第三次握手丢失：由于 ACK 报文是不会有重传的，所以由对方重传，就会由服务端进行重传，达到次数后等待上次两倍的时间要是还没有收到三次握手的报文，就会断开连接；

2.四次挥手

2.1四次挥手的过程

• 第一次挥手，客户端发送 FIN：客户端想要断开连接的时候首先会给服务端发送 FIN 报文，FIN 标志位置为 1，并随机生成序列号，然后进入 FIN_WAIT_1 状态，等待服务器的确认；
• 第二次挥手，服务器发送 ACK：服务器收到客户端的 FIN 报文后，会将 ACK 标志位置为 1，并将确认应答号置为客户端序列号 + 1，随后服务端进入 CLOSE_WAIT 状态，表示服务器已准备好关闭连接；客户端收到 ACK 报文之后，进入 FIN_WAIT_2 状态，等待服务器的 FIN 报文；
• 第三次挥手，服务器发送 FIN：服务器完成数据发送之后，也会给客户端发送 FIN 报文，将 FIN 标志位置为 1，并随机生成序列号，然后服务器进入LAST_ACK 状态，等待客户端的确认；
• 第四次挥手，客户端发送 ACK：客户端收到服务器的 FIN 报文后，会将 ACK 标志位置为 1，并将确认应答号置为服务器序列号 + 1，随后客户端会进入 TIME_WAIT 状态，等待一段时间（通常为 2MSL，Maximum Segment Lifetime）后关闭连接；服务器收到 ACK 报文之后，会立即关闭连接；
  （图片来源：小林coding）
  

2.2为什么需要四次挥手

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送了，但是还能接收数据；
• 服务端收到 FIN 时，先发送一个 ACK 应答报文给客户端，服务端可能还要先处理数据，等到没有数据要发送了，再发送给客户端 FIN 报文表示现在断开连接；
• 服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 需要分开发送；

2.3挥手过程丢失会发生什么

• 第一次挥手丢失：客户端没有收到 ACK 的话就会触发重传机制重发 FIN，到重传次数之后还没收到就会直接断开连接；
• 第二次挥手丢失：由于 ACK 是不会重传的，所以只能由客户端重传 FIN 报文，直到收到 ACK 确认应答；
• 第三次挥手丢失：如果服务器没有收到客户端的 ACK 应答报文，就会重传，直到次数耗尽，服务端就会关闭连接；客户端的 FIN_WAIT_2 状态是有时间限制的，如果超过时间限制就会由 close 函数关闭连接；
• 第四次挥手丢失：如果服务器没有收到 ACK 确认应答，就会重传 FIN，达到最大次数，再等待上次时间的两倍，就会关闭连接了；客户端收到第三次挥手之后就会发送 ACK 进入 TIME_WAIT 状态，开启时长为 2MSL （报文最大生存时间）的定时器，如果途中收到第三次挥手的 FIN 报文后，就会重置定时器，时间耗尽就会关闭连接；

十二、TCP 和 UDP

1.TCP 和 UDP 的区别

• 连接方式：TCP 是面向连接的，通信前需要通过三次握手建立连接，通信结束后通过四次挥手关闭连接；UDP 是无连接的协议，无需建立连接，直接发送数据；
• 可靠性：TCP 提供可靠的数据传输，UDP 不保证可靠性；
• 数据传输方式：TCP 是基于字节流传输，数据被分割成多个 TCP 段（Segment）发送；UDP 基于数据报传输，每个数据包独立发送；
• 应用场景：TCP 适合网页浏览、文件传输、电子邮件等；UDP 适合视频流媒体、在线游戏、语音通话等；

2.TCP 为什么是可靠的

2.1确认机制：

• 接收方收到数据后，会向发送方发送一个确认报文（ACK），表示已成功接收数据，发送方根据 ACK 确认数据已到达，否则会重传数据，这样就可以确保数据不丢失；

2.2重传机制：

• 如果发送方在一定时间内未收到 ACK，会认为数据丢失，并重传该数据，重传时间根据网络状况动态调整，这样会确保数据最终到达接收方；

2.3序列号和确认号：

• 每个 TCP 报文都包含一个序列号（Seq），用于标识数据的顺序，这样可以确保数据按序到达，检测丢失或重复的数据；

2.4流量控制：

• 流量控制就是为了保证发送数据的速率和接收方的处理能力匹配，从而避免接收方缓冲区溢出。TCP 连接的每一方都有固定大小的缓存区间，TCP 接收端只允许发送端发送接收端缓冲区能接纳的数据，能提示发送方降低发送速率，防止包丢失，TCP 流量控制是通过滑动窗口实现的；

2.5拥塞控制：

• 慢启动：在连接刚开始的时候，发送方会逐渐增加发送窗口大小，从而以指数增长的速度增加发送的数据；
• 拥塞避免：一旦慢启动阶段过去，发送方进入拥塞避免阶段，在这个阶段，发送方逐渐增加发送窗口大小，但增加速率比较慢，为了避免过快增加导致的网络拥塞；
• 超时重传：如果发送方在超时重传的时间内没有收到确认，它认为数据包会丢失，并重传这些数据包，用于检测网络中的丢包和拥塞情况；
• 快速重传和快速回复：当发送方发送的数据包丢失或网络拥塞时，接收方会发送重复确认通知发送方有数据丢失，当收到的确认通知到一定数量后，就会立即重传，而不是等待超时，这样可以减少网络拥塞的情况；
• 拥塞窗口调整：发送方根据网络的情况动态的调整发送窗口大小，通过检测网络延迟和丢包情况来确定合适的发送速率，避免网络拥塞；