0. 前言

　　最近在处理公司遗留项目的时候发现自己对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）状态。

如下图（图为百度搜出来的）

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

如下图所示：

3. 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状态的维持时间。