- TCP标志位
- TCP序列号、确认号
- 三次握手
- 三次握手过程
- 为什么不是两次握手？
- 为什么不是四次握手？
- 为什么超时重传？如何处理丢包
- 为什么需要超时重传?
- 如何处理丢包？
- 四次挥手
- 四次挥手过程
- 为什么需要四次挥手
- 为什么四次挥手，客户端的TIME-WAIT状态必须等待2MSL的时间，才能返回到CLOSED状态
- 如果已经建立了连接，但是客户端出现故障了怎么办？
- 使用tcpdump抓包分析
- 操作
TCP标志位
TCP标志位代表当前请求的目的，一共有6种
1、SYN（synchronous）：发送/同步标志，用来建立连接，和ACK标志位搭配使用。A请求与B建立连接时，SYN = 1, ACK = 0;B确认与A建立连接时，SYN=1，ACK=1
2、ACK（acknowledgement）：确认标志，表示确认收到请求
3、PSH（push）：推送操作，就是指数据包到达接收端以后，不对其进行队列处理，而是尽可能的将数据交给应用程序处理
4、FIN（finish）：结束标志，表示关闭一个TCP连接
5、RST（reset）：重制复位标志，用于复位对应的TCP连接
6、URG（urgent）：紧急标志位，用于保证TCP连接不被中断，并且督促中间层设备尽快处理
TCP序列号、确认号
- 作用：TCP 使用序列号来记录发送数据包的顺序。TCP 传送一个数据包后，只有在指定时间里收到这个包的确认信息，才会将其从队列中删除，否则会重新发送该数据包。对接收方而言，通过数据分段中的序列号可以保证数据能够按照正常的顺序进行重组。
三次握手
三次握手过程
图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe
- 第一次握手（SYN）：
- 客户端向服务端发送一个同步报文（SYN），表示请求建立连接，并告知自己的初始序列号（Seq）
- 第一次握手主要是为了：服务端确认“自己收、客户端发”报文功能正常
- 第二次握手（SYN + ACK）：
- 服务端收到客户端的SYN报文后，回复同步确认报文（SYN + ACK），同时指定自己的初始序列号（Seq），并对客户端的序列号进行ACK确认（确认号=客户端的序列号 + 1）
- 第二次握手主要是为了：客户端确认“自己发、自己收、服务端收、服务端发”报文功能正常，因此客户端认为连接已建立
- 第三次握手（ACK）：
- 客户端收到服务器的 SYN + ACK 之后，回复一个 ACK 报文，表示自己确认了服务器的 SYN，并对服务器的序列号进行 ACK 确认（确认号 = 服务器的序列号 + 1）。
- 第三次握手主要是为了：服务端确认“自己发、客户端收”报文功能正常，此时双方都认为连接已建立，TCP 连接正式建立
三次握手可以解决的问题：
1、防止历史连接误触发： 旧的 SYN 可能会因网络问题延迟到达服务器，导致服务器误以为是新的连接，三次握手确保客户端仍在等待通信。
2、确保双方的收发能力都正常： 三次握手能确保双方的 发送能力 和 接收能力 都正常，不会出现服务器单方面认为连接成功的情况。
为什么不是两次握手？
两次握手无法确保客户端和服务器的发送、接收能力都正常，可能会导致旧连接被误认为是新的连接，进而影响数据的可靠性。
假设采用两次握手：
1、客户端发送 SYN（请求建立连接）。
2、服务器收到后，直接返回 SYN + ACK，认为连接建立成功。
3、服务器直接开始发送数据。
4、问题：如果客户端因网络延迟或其他原因没有收到服务器的 SYN + ACK，或者客户端已经关闭，服务器仍然认为连接有效，会导致无效连接或错误数据传输。
为什么不是四次握手？
如果使用四次握手，就会多出一步额外的 ACK 确认报文，但这在建立连接时是不必要的，因为：
- 在第三次握手中，客户端发送的 ACK 已经明确表示它收到了服务器的 SYN + ACK，并准备好通信。
- 服务器只需要确认这个 ACK 是否到达即可，而不需要再发送一个额外的确认报文。
但是，在 TCP 断开连接时，为什么是四次挥手？
断开连接涉及双方数据传输的结束，需要确保双方都不再发送数据，因此需要四次挥手来确保数据彻底传输完毕。
为什么超时重传？如何处理丢包
为什么需要超时重传?
在TCP传输过程中，网络环境肯能会导致数据包丢失或ACK（确认）丢失。为了确保数据能够可靠地传输，TCP采用超时重传机制
1、发送方发送数据后，会开启一个定时器，等待接收方的ACK确认。
2、如果在超时时间内没有收到ACK，发送方会重新发送该数据包。
3、如果仍然没有收到确认，TCP可能会指数退避地延长超时时间，并继续重传（如：RTO值递增）。
4、当达到一定的重传上限后，TCP会认为连接中断，并向应用层报告失败。
超时重传机制保证了即使网络环境不稳定，TCP仍然能够提供可靠的数据传输。
如何处理丢包？
TCP采用超时重传和快速重传两种机制来处理丢包。
1、超时重传
应用场景：适用于网络不稳定、长时间丢包
触发条件：在RTO内未收到ACK
处理方式：重新发送数据包
- 发送方在发送数据时，启动一个定时器（RTO）
- 如果在RTO时间内没有收到ACK，TCP认为数据包丢失，重新发送该数据包
- TCP会指数退避地调整RTO，比如1s、2s、4s…直到达到最大重传次数。
缺点：
- 如果RTO设置过长，丢包恢复慢，影响性能。
- 如果RTO设置过短，可能导致不必要的重传，加重网络负担。
2、快速重传
应用场景：适用于部分丢包、轻微网络抖动
触发条件：收到3个相同的ACK
处理方式：立即重传丢失的数据包
当TCP发送方收到连续3个相同的ACK（即3次确认同一个数据包）时，认为该数据包可能已经丢失，会立即重传，而不等待超时。
示例：
1、发送方发送 Seq=1, 2, 3, 4。
2、Seq=2 丢失，但 Seq=3、4 仍然到达 接收方。
3、接收方发现 Seq=2 缺失，于是对 Seq=1 发送 3 次 ACK（ACK=2）。
4、发送方收到 3 次相同的 ACK=2，认为 Seq=2 丢失，立即重传 Seq=2。
优点：
- 比超时重传更快恢复丢包，提高 TCP 传输效率。
四次挥手
四次挥手过程
图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe
- 第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认
- 序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1
- 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1
- 第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1
这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。
- 第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 ACK 的确认
- 序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。如果半关闭状态，服务端没有发送数据，那么 w == k
- 确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据
- 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1
此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。
TCP 规定，[FIN/ACK] 包即使没有传送数据，也会消耗掉一个序列号。[FIN/ACK] 包是第一、三次挥手：
- 第一次挥手时，客户端的序列号 seq = u，消耗一个序列号。因此：
- 第二次挥手时，服务端的确认号 ack = u + 1
- 第四次挥手时，客户端的序列号 seq = u + 1
- 第三次挥手时，服务端的序列号 seq = w，消耗一个序列号。因此：
- 第四次挥手时，客户端的确认号 ack = w + 1
为什么需要四次挥手
因为 TCP 是全双工的，一方关闭连接后，另一方还可以继续发送数据。所以四次挥手，将断开连接分成两个独立的过程
为什么四次挥手，客户端的TIME-WAIT状态必须等待2MSL的时间，才能返回到CLOSED状态
主要有两个原因：
(1) 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。
MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。
那如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，会怎样？服务端会继续超时重试直到断开连接，见下文。
(2) 防止已失效的连接请求报文段出现在之后的连接中。
TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。
如果已经建立了连接，但是客户端出现故障了怎么办？
或者说，如果三次握手阶段、四次挥手阶段的包丢失了怎么办？比如上面描述的“服务端重发 FIN”的问题。
简而言之，通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接。
具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 秒发送一个探测报文段，若一连发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。
使用tcpdump抓包分析
操作
tcpdump是一个命令行工具，可以打印网络接口上传输的 TCP 报文。
在一个终端窗口执行以下命令，监听与www.baidu.com传输的数据包
tcpdump -n host www.baidu.com # 可能需要 sudo 权限
参数说明：
- -n：不要将 host.port 转成域名
- host：监听发到特定主机与端口的流量
如图，开始成功监听：
随后再开启一个终端窗口，执行以下命令，访问www.baidu.com
curl www.baidu.com：
可以看到 tcpdump 打印了信息
其中一定包含三次握手建立连接、发送数据包、四次挥手断开连接这几个过程。接下来一一分析。约定：客户端就是本机，服务端就是百度的服务器。
