在讲述TCP四次挥手,即断开TCP连接的过程之前,需要先介绍一下TCP协议的包结构。TCP协议包结构

这里只对涉及到四次挥手过程的字段做解释

(1) 序号(Sequence number) 我们通过 TCP 协议将数据发送给对方,就比如 hellotcp,这一串字节流,假设被拆分成了三个 TCP 报文段,第一个报文段携带了 hel,第二个报文段携带了 lot,第三个报文段携带了 cp,这三个报文段不一定是按照顺序送到对端的,那么对端收到这三个段是如何确定他们的顺序的呢?此时序号的意义就体现在这里。

TCP 连接中,为传送的字节流(数据)中的每一个字节按顺序编号。也就是说,在一次 TCP 连接建立的开始,到 TCP 连接的断开,你要传输的所有数据的每一个字节都要编号。这个序号称为字节序号。

举个例子:如果一个 TCP 报文段的序号为 101,它携带了 50 字节的数据,就表示这 50个字节的数据的字节序号范围是 [101, 150],该报文段携带的第一个字节序号是 101,最后一个字节序号是 150。

(2) 确认号(Acknowledge number) TCP传输的对端通过回复一个确认号,来表示确认已经接收到了某个 TCP 段。

举个例子:比如之前发送方发送的序号为 101 的 TCP 段,这个段携带了 50 字节数据,则接收方应当回复的确认号是 151,它表示接收方已经收到了字节序号为150之前的数据,现在期望你发送字节序号为 151 以及以后的数据。

(3)ACK 是一个TCP协议报文中的标志比特位,如果置1表示这个报文段是一个回复确认报文。

注意:为了防止混淆确认号与ACK,一般确认号写作ack,而ACK就写为ACK。

(4)FIN 同样是一个TCP协议报文中的标志比特位,如果置1表示该报文段用来断开TCP连接。

介绍完TCP协议报文的一些基本字段,我们可以来叙述TCP四次挥手的过程了。

TCP四次挥手流程图

数据传输结束后,通信的双方都可以释放连接。现在A和B都处于ESTABLISHED状态。

(1)第一次挥手

A的应用程序先向其TCP发出连接释放报文段,并停止发送数据,主动关闭TCP连接。A把连接释放报文段首部的FIN置1,其序号seq=x。这时A进入FIN-WAIT-1(终止等待1)状态,等待B的确认(请注意:TCP规定,FIN报文段即使不携带数据,它也要消耗一个序号)。

(2)第二次挥手

B收到连接释放报文段后即发出确认,确认号是ack=x+1,序号为seq=y。然后B就进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭状态,即A已经没有数据要发送了,但B若发送数据,A仍要接收。也就是说,从B到A这个方向的连接并未关闭。这个状态可能会持续一些时间。

A收到来自B的确认后,就进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。

(3)第三次挥手

若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接。这时B发出的连接释放报文段需要置FIN=1。现假定B的序号为z(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack=x+1。这时B就进入了LAST-ACK(最后确认)状态,等待A的确认。

(4)第四次挥手

A在收到B的连接释放报文段后,必须对此发出确认。在确认报文段中把ACK置1确认号ack=z+1,而自己的序号是seq=u+1(根据TCP标准,前面发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT(时间等待)状态(请注意:现在TCP连接还没有释放掉。必须经过时间等待计时器设置的时间2MSL(MSL:最长报文段寿命)后,A才进入到CLOSED状态)。

常见面试问题一:为什么是四次握手,不能是三次握手吗?

答:与之前需要三次握手的原因类似,如果只是三次挥手,那就相当于服务器端发送完第三次挥手的报文后直接进入CLOSED(关闭)状态,假如此时网络出现问题,丢失了第三次挥手的报文,相当于客户端没有收到,那他依旧认为连接没有结束,在一段时间没有收到第二次ACK应答报文后,他会重新发送请求断开连接的报文,但是服务器端已经关闭,不会再接收报文,又形成了类似死锁的情况。

常见面试题二:为什么有CLOSE-WAIT状态?

答:因为服务器端收到断开TCP连接请求时,有可能还有数据没有向客户端发送完毕,需要一段时间来把所有信息传输完毕。

常见面试题三:为什么有TIME-WAIT状态?

答:假设客户端发送完第四次挥手的报文后,直接进入CLOSED(关闭)状态。那么假设此时网络出现问题,报文丢失,那么因为服务器端收不到第四次挥手的ACK报文段,所以认为此时TCP连接还没有断开。然后重发ACK+FIN报文段,但此时客户端已经关闭与其的TCP连接,肯定不会再接收该报文,这样会浪费大量资源。

答:在高并发且短连接的通信情况下,服务器会出现大量TIME-WAIT状态,这占用了大量的socket,会影响服务器的正常通信服务。

解决方法

  • (1)降低time_wait的时限。
  • (2)设置中允许重用time_wait的socket。
  • (3)设置快速回收time_wait的socket
作者:|投三分的金闪闪|,原文链接: https://www.cnblogs.com/ranger30/p/16318867.html

文章推荐

记录:yum Could not resolve host: mirr

算法链与管道(上):建立管道

Vben Admin 源码学习:项目初始化

java的容器支持cpu

SpringBoot+Mybatis-Plus整合Sharding-JDBC5.1.1实现单库分...

为什么我写了路由懒加载但代码却没有分割?

程序员做外包,真的没地位没出路吗?

如何在 30 分钟完成表格增删改查的前后端框架搭建

HarmonyOS初探07——使用DevEco Studio预览器

Electron+Vue3+TypeScript+Vite桌面应用To

人最重要的能力是什么?

Blazor和Vue对比学习(基础1.9):表单输入绑定和验证,VeeV...