你的位置:首页 > 操作系统

[操作系统]关于TCP连接建立与终止那点事


0. 前言

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

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

1. TCP连接的建立

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

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

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

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

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

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

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

 

2. TCP连接的终止

  对于TCP连接的终止来说,却需要四次挥手来完成。

  就客户端首先发起调用close关闭来说:  

  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,即已经没有状态了)

如下图所示:

 

3. TCP状态转换

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

 

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

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

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

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

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