TCP结构
- 源端口和目标端口：标识通信的应用程序。
- 序列号：标记发送的数据段的顺序序号。
- 确认号 ( ACK)：确认接收到的数据序号。
- 标志位：控制连接状态，包括 SYN（同步）、ACK（确认）、FIN（结束）、RST（重置）等。
- 窗口大小：表示接收方的缓冲区大小。
TCP三次握手
- 第一次握手：客户端发送 SYN
- TCP头部变化：
- 源端口 12345，目标端口 80
- 序列号：随机初始为 1000
- ACK：0，未确认对方数据
- 标志位：SYN=1，其余为0，申请连接
- 窗口大小：65535，本地缓冲区大小
- 第二次握手：服务器响应 SYN+ACK
- TCP头部变化：
- 源端口 80，目标端口 12345
- 序列号：随机初始为 2000
- ACK：1001，告诉对方下次希望接受的序列号
- 标志位：SYN=1，ACK=1
- 窗口大小：65535，本地缓冲区大小
- 第三次握手：客户端发送 ACK
- TCP头部变化：
- 源端口 12345，目标端口 80
- 序列号：1001
- ACK：2001，告诉对方下次希望接受的序列号
- 标志位：ACK=1
- 窗口大小：65535，本地缓冲区大小
- 此时如果有数据可以发送数据
bash
客户端 服务器
| ---- SYN (SEQ=1000) ----> |
| <--- SYN+ACK (SEQ=2000, ACK=1001) --- |
| ---- ACK (SEQ=1001, ACK=2001) ----> |为什么是三次握手
三次握手的核心目的是：客户端和服务器都确认对方的发送能力和自己的接收能力。
为什么两次不行？
bash
1.客户端发送 SYN。
2.服务器发送 SYN+ACK，连接建立。- 如果第二次报文丢失，服务器认为连接已建立，但客户端仍在等待，导致连接不可用。
- 如果网络中有延迟的旧 SYN 包到达服务器，服务器回复 SYN+ACK，但客户端没有第三次 ACK（因为不是新连接），服务器不会误建连接。
为什么不需要四次？
bash
1.客户端 SYN。
2.服务器 ACK。
3.服务器 SYN。
4.客户端 ACK。第二步和第三步可以合并为 SYN+ACK，没必要分开。
TCP四次挥手
- 第一次挥手：客户端发送 FIN
- TCP 头部变化：
- 源端口：12345，目标端口：80
- 序列号：5000（假设当前序列号）
- 确认号 (ACK)：3000（假设已确认服务器的序列号）
- 标志位：FIN=1, ACK=1
- 窗口大小：0（不再接收数据）
- 第二次挥手：服务器发送 ACK
- TCP 头部变化：
- 源端口：80，目标端口：12345
- 序列号 (SEQ)：3000
- 确认号 (ACK)：5001（客户端 SEQ + 1）
- 标志位：ACK=1
- 窗口大小：65535
- 第三次挥手：服务器发送 FIN
- TCP 头部变化：
- 源端口：80，目标端口：12345
- 序列号 (SEQ)：3000
- 确认号 (ACK)：5001
- 标志位：FIN=1, ACK=1
- 窗口大小：0
- 第四次挥手：客户端发送 ACK
- TCP 头部变化：
- 源端口：12345，目标端口：80
- 序列号 (SEQ)：5001
- 确认号 (ACK)：3001（服务器 SEQ + 1）
- 标志位：ACK=1
- 窗口大小：65535
bash
客户端 服务器
| ---- FIN (SEQ=5000) ----> |
| <--- ACK (ACK=5001) ------ |
| <--- FIN (SEQ=3000) ------ |
| ---- ACK (ACK=3001) ----> |为什么四次挥手
TCP 是全双工协议，连接关闭时需要双方都确认：
- 自己不再发送数据。
- 已接收对方所有数据。
为什么三次不行？
bash
1.客户端 FIN。
2.服务器 FIN+ACK（合并确认和关闭）。
3.客户端 ACK。
如果服务器还有数据未发完，合并 FIN+ACK 会导致数据丢失。为什么四次挥手之后要等2MSL?
在四次挥手中，客户端发送的最后一次 ACK（第四次挥手）可能在网络中丢失。服务器重传 FIN，1MSL 覆盖重传 FIN 的时间，1MSL 覆盖 ACK 的传输时间
TCP传输可靠性保证
- 前提：三次握手和四次挥手建立 可靠连接
- 序列号和确认ACK保证有序不丢包
- 超时重传：重新传送丢失的包
- 流量控制和拥塞控制：一个保障接收端处理正常；一个控制网络当中的流量
拥塞控制-拥塞发送
拥塞控制-快恢复
