中商外贸网站合肥工程建设信息网站
TCP三次握手，四次挥手，再次总结
- TCP和UDP协议基础
- 三次握手
- 为什么需要三次握手？
- 数据传输阶段
- 四次挥手
- 为什么需要超时等待？
- 为什么四次挥手不能减少到三次？
TCP和UDP协议基础
- 协议位置：TCP和UDP协议都属于传输层。
- 数据类型：数据可以是文件、视频、图片等多种形式。
- TCP传输过程：包括三次握手、数据传输确认、四次挥手。
三次握手
-
第一次握手：客户端发送一个SYN包，询问是否建立连接。
-
第二次握手：服务端同意连接，回复一个SYN+ACK包。
-
第三次握手：客户端收到之后，回复服务端一个ACK包，连接建立。
为什么需要三次握手？
-
目的：防止失效的请求报文，重新传输到服务端，造成错误。
-
风险：如果仅有两次握手，滞留的SYN可能恢复连接，导致：
- 服务端又发送一个SYN+ACK包，再次进入传输状态。
- 这时，客户端认为是一条连接。
- 服务端认为是两条连接。
- 双方状态不一致。
-
三次握手优势：通过序号机制判断SYN+ACK是否有效或过期，确保连接一致。
数据传输阶段
-
可靠性：TCP协议能解决丢包问题和乱序问题。
-
过程：
- TCP会建立缓冲区，复制数据并分割，头部拼接序列号和长度。
- ACK包用于确认接收的数据，并告知发送端下一段数据的序列号。
- 发送端可以一次发送多个数据包，接收端只需回复一次ACK。
- ACK包通常不携带实际的传输内容。它仅用于确认已接收到的内容。
-
丢包处理：
第一步 - 检测丢失的300-399数据：
- 接收端收到部分数据后，发现序列号300-399的数据未完整，于是发送ACK=300。
- 发送端收到ACK=300后，会重传序列号为300-399的数据。
第二步 - 检测丢失的600-699数据：
- 接收端成功接收并确认了300-399数据后，对后续数据进行检查。
- 接收端发现序列号600-699的数据丢失，因此发送ACK=600。
- 发送端收到ACK=600后，重新发送600-699的数据。
逐步确认：
- TCP协议中，接收端每次确认都是基于当前成功接收的数据，并通过ACK通知发送端下一段需要的数据。
- 这种累积确认机制确保了丢失数据的准确定位和可靠重传。
四次挥手
- 第一次挥手：客户端发送FIN包，表示关闭连接，进入终止等待1状态。
- 第二次挥手：服务端收到FIN后发送ACK包，进入等待关闭状态；客户端进入终止等待2状态。
- 服务端此时还可以发送未发送的数据
- 客户端还可以接受数据
- 第三次挥手：服务端传输完数据后发送FIN包，进入最后确认状态。
- 第四次挥手：客户端收到FIN包后回复ACK包，进入超时等待状态，确保对方已收到ACK。超时后关闭连接。
为什么需要超时等待？
- 防止ACK包丢失。
- 若ACK包丢失，服务端会再次发送FIN包，客户端重发ACK，确保连接关闭。
为什么四次挥手不能减少到三次？
若合并为三次（如服务器收到FIN后立即发FIN+ACK）：
■ 服务器可能仍有数据未发送完，导致数据丢失。
■ 客户端无法区分FIN和ACK的合并响应，可能误判连接状态。