关于TCP连接建立与终止那点事

  最近在处理公司遗留项目的时候发现自己对TCP协议一点都不懂,所以补了点关于TCP连接的建立和终止的内容,这里简单写下自己了解的部分,省略了报文序号确认序号这些无关的字段,主要讨论TCP状态的转换以及Linux下的一些问题。

  对于这篇文章来说,主要是记录自己遇到的一些问题以及学习到的一些东西。

  关于TCP/IP协议,这里推荐一本书:《TCP/IP协议详解:卷1》

1. TCP连接的建立

  学过计算机网络的都知道TCP连接的建立需要三次握手,当时在大学也这么听着,但是具体怎么三次还是最近补了才知道这么回事。

  对于客户端/服务器模型来说:

  1. 首先客户端发起连接(发送SYN报文,进入SYN_SENT状态)

  2. 服务器接收到SYN,然后响应(发送SYN ACK,进入SYN_RCVD状态,注意这个时候连接并没有建立)

  3. 客户端接受到后,发送确认报文(发送ACK,进入Established状态)

  4. 服务器收到后才进入链路建立(Established)状态。

如下图(图为百度搜出来的)

关于TCP连接建立与终止那点事

2. TCP连接的终止

  对于TCP连接的终止来说,却需要四次挥手来完成,这里以客户/服务器模型,客户端主动发起关闭来说明(这里服务器也可以发起主动发起关闭)。

  1. 客户端发送FIN(进入FIN_WAIT_1状态)

  2. 服务器接收到FIN后对发送ACK确认(此时服务器进入CLOSE_WAIT状态,客户端接受到该ACK后由FIN_WAIT_1 转为FIN_WAIT_2状态)

  3. 服务器调用close发送FIN(进入LASK_ACK状态)

  4. 客户端接收到服务器发送的FIN后发送ACK(进入TIME_WAIT状态)

  5. 服务器接收到后结束(LASK_ACK状态转为虚拟的CLOSED,即已经没有状态了)

如下图所示:

关于TCP连接建立与终止那点事

3. TCP状态转换

  其实如果看懂了上面连接的建立以及终止的话,很容易就可以看懂下面的状态转换图,上面两个就可以看做由它拆解出来的。

关于TCP连接建立与终止那点事

4. 遇到CLOSE_WAIT状态的一些情况

  前面说了,最近在维护一些历史遗留的项目,那代码简直是叼炸天了,直接使用两个进程共用一个select,在accept前加上文件锁,select只监听服务器端fd,其它fd不监听....(此处省略一千字),然后现在出现了大量的CLOSE_WAIT状态,我在想难道以前就没出现过?奇葩。不过被DDoS攻击有些也会出现这种现象。最后讨论了一下午说怎么样才能少改动原来的代码....最后老大拍板,重写select部分~^~,使用epoll实现。

  上面的状态图可以看出,服务器由于接收到客户端发来的FIN,会进入CLOSE_WAIT,如果此时没有监听该客户端fd并且没有调用close,那么这时会导致占用的FD没有被释放,资源就这么被泄漏掉了,这样也会导致存在大量的CLOSE_WAIT状态,以至于后续FD消耗完了的时候(一般系统默认1024),accept就会失败。(注:这里CLOSE_WAIT状态是由于应用程序没有调用close导致的,系统不会释放该资源,即会一直存在)

  (注:即使accept失败,但是对于链路来说,还是能建立成功的,因为对于Linux TCP底层实现来说,存在两个队列,一个为半链路队列,另一个为三次握手成功但是没有被服务器accept取走的链接的队列。)

  后续对于Linux下的服务器来说一般都是使用epoll来处理,效率比select高。

5. 补充

  这里看到一些博客说通过设置系统参数来改变CLOSE_WAIT的维持等待时间,我查阅了一下,并且也尝试过(其实不用试)。不能够通过设置系统参数来更改的,因为这时应用程序内部导致的,,而且根本就不存在说CLOSE_WAIT维持时间一说,该状态只有应用程序调用close才会转为其它状态(或者关闭应用程序),这里说通过修改系统参数一般指的时TIME_WAIT状态的维持时间。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/f4cfe62289b4c7a9b5c625435da6c471.html