面试实战问题三十 HTTP协议中TCP三次握手与四次挥手详解

HTTP协议中TCP三次握手与四次挥手详解

在HTTP协议中，连接建立和断开依赖于底层的TCP协议。虽然HTTP本身不定义握手过程，但所有HTTP通信都通过TCP三次握手建立连接，通过四次挥手断开连接。以下是详细解析：

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

第一次握手（SYN）
- 客户端发送SYN=1标志的TCP包，携带随机初始序列号seq=x
- 客户端进入SYN_SENT状态
- 目的：检测客户端的发送能力
第二次握手（SYN+ACK）
- 服务器返回SYN=1和ACK=1标志的包
- 携带自己的序列号seq=y和确认号ack=x+1
- 服务器进入SYN_RCVD状态
- 目的：检测服务器的收发能力
第三次握手（ACK）
- 客户端发送ACK=1标志的包
- 携带seq=x+1和ack=y+1
- 双方进入ESTABLISHED状态
- 目的：确认客户端接收能力正常

为什么需要三次握手？

防止历史连接干扰（两次握手时失效请求可能建立无效连接）
最小化握手次数保证可靠性（四次握手会降低效率）
避免资源浪费：$ \text{可靠性} \propto \frac{1}{\text{握手次数}} $（三次是最优解）

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

第一次挥手（FIN）
- 主动关闭方（如客户端）发送FIN=1标志的包，序列号seq=u
- 进入FIN_WAIT_1状态
第二次挥手（ACK）
- 被动关闭方（如服务器）返回ACK=1标志的包
- 携带确认号ack=u+1和自身序列号seq=v
- 服务器进入CLOSE_WAIT状态，客户端进入FIN_WAIT_2状态
第三次挥手（FIN）
- 服务器处理完剩余数据后发送FIN=1和ACK=1标志的包
- 携带新序列号seq=w和确认号ack=u+1
- 服务器进入LAST_ACK状态
第四次挥手（ACK）
- 客户端发送ACK=1标志的包（确认号ack=w+1）
- 客户端进入TIME_WAIT状态（等待2MSL时间）
- 服务器收到后立即关闭连接

关键设计解析

四次挥手的必要性：TCP连接是全双工的，需独立关闭两个方向的数据流
TIME_WAIT状态的作用：
确保最后一个ACK到达服务器（未到达时会重传FIN）
防止旧连接数据包干扰新连接
等待时间：$ 2 \times \text{MSL} $（默认60秒，MSL=30秒）

服务器CLOSE_WAIT状态：处理遗留数据的关键阶段

三、HTTP协议与TCP的关系

阶段	HTTP行为	TCP状态变化
请求发起	浏览器发送HTTP请求	触发三次握手
数据传输	通过已建立的TCP连接传输HTTP报文	ESTABLISHED状态
连接关闭	短连接：每次请求后关闭长连接：复用	触发四次挥手
错误处理	连接超时/重置	TCP重传机制激活

HTTP/1.0：默认短连接（每次请求完成即四次挥手）
HTTP/1.1+：默认长连接（复用TCP连接，减少握手挥手开销）

四、Java网络编程验证

触发三次握手

try (Socket socket = new Socket("www.example.com", 80)) {// 连接建立时自动完成三次握手
}  // 退出try-block时自动触发四次挥手

观察TCP状态（Linux）

netstat -nat | grep ESTABLISHED
netstat -nat | grep TIME_WAIT

模拟连接重置

// 设置SO_LINGER强制关闭连接
socket.setSoLinger(true, 0);  // 发送RST而非FIN

五、面试高频问题

为什么连接建立是三次握手，断开却要四次挥手？
- 建立连接时服务器可将SYN+ACK合并发送
- 断开连接时服务器需等待数据处理完毕才能发FIN
TIME_WAIT状态过多会导致什么问题？如何解决？
- 问题：耗尽端口资源（Linux默认端口范围：net.ipv4.ip_local_port_range）
- 解决方案：
```
// Java中启用端口复用
socket.setReuseAddress(true);
```
TCP握手能保证100%可靠吗？
- 不能！三次握手比两次更可靠，但网络本质不可靠（如握手成功后断网）
Wireshark抓包如何识别握手过程？
- SYN包：Flags [S]
- SYN+ACK包：Flags [S.]
- FIN包：Flags [F]

总结

过程	关键特征	设计目的
三次握手	SYN → SYN+ACK → ACK	最小代价验证双向通信能力
四次挥手	FIN → ACK → FIN → ACK	安全关闭双向数据流
TIME_WAIT	等待2MSL（60秒）	容错处理+防止旧数据干扰