TCP四次挥手

1. 四次挥手过程

一开始客户端和服务端都是处于“ESTABLISHED”状态

第一次挥手:客户端主动向服务端发送连接释放请求,FIN标志位设置为1,客户端进入”FIN_WAIT1“状态。
第二次挥手:服务端向客户端发送确认请求,ACK标志位设置为1,此时TCP处于半关闭状态,服务端进入“CLOSE_WAIT"状态。客户端收到服务端端ACK报文后,进入”FIN_WAIT2“状态。此时还可以收到来自服务端的数据。
第三次挥手:服务器端的数据发送完毕,主动向客户端发送连接释放请求,FIN标志为设置为1,服务端进入“LAST_ACK“状态,表示等待客户端发送的确认请求。
第四次挥手:客户端收到服务端的连接释放请求后,向服务端发送确认请求,ACK位置1。客户端进入“TIME_WAIT"状态。等待2个最大报文存活时间。若无特殊情况,客户端会进入“CLOSE”状态。服务器端收到ACK请求后,随后进入“CLOSE”状态。

在这里插入图片描述

2. 为什么不能三次挥手?

因为无论是客户端还是服务器端,从请求释放连接到确认释放需要两次,这样才确保客户端和服务端两个都正常关闭。当然特殊情况下也能优化为三次握手,就是服务端发送ACK确认报文时它的数据恰好已经发送完毕,第二、三次握手可以合并成一次。

3. 为什么需要TIME_WAIT状态

  • 确保服务端的请求释放连接正确关闭
  • 防止服务端被网络延迟的数据被客户端错误接收导致数据错乱问题。

4. 为什么要等待2MSL才进入CLOSE状态?

这是因为一个报文在网络中从发送开始到收到确认为止的最大存活时间就是2MSL,等待2ML时间可以容忍客户端发送给服务端的ACK丢一次。如果在这个时间内又收到了服务端的FIN报文,则重新等待2MSL。

相关推荐

  1. tcp挥手

    2024-04-29 06:36:08       35 阅读
  2. TCP挥手

    2024-04-29 06:36:08       16 阅读
  3. TCP握手挥手

    2024-04-29 06:36:08       20 阅读
  4. tcp握手挥手

    2024-04-29 06:36:08       22 阅读

最近更新

  1. TCP协议是安全的吗?

    2024-04-29 06:36:08       18 阅读
  2. 阿里云服务器执行yum,一直下载docker-ce-stable失败

    2024-04-29 06:36:08       19 阅读
  3. 【Python教程】压缩PDF文件大小

    2024-04-29 06:36:08       19 阅读
  4. 通过文章id递归查询所有评论(xml)

    2024-04-29 06:36:08       20 阅读

热门阅读

  1. 商城数据库88章表68~71

    2024-04-29 06:36:08       11 阅读
  2. SpringMvc中的异常处理器(在SpringBoot中也可使用)

    2024-04-29 06:36:08       10 阅读
  3. am62x Ti官方资源一览

    2024-04-29 06:36:08       11 阅读
  4. 等保测评常见安全风险

    2024-04-29 06:36:08       10 阅读
  5. Ubuntu系统重装

    2024-04-29 06:36:08       10 阅读