关于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连接的终止来说，却需要四次挥手来完成，这里以客户/服务器模型，客户端主动发起关闭来说明(这里服务器也可以发起主动发起关闭)。
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高。
- 3楼岁月漫步
- 有插图的才是好文章
- 2楼crazyacking
- 写得不错，言简意赅
- 1楼just coding
- TCP四次挥手断开连接，，图里标注的是 “主动方” 和 “被动放”。，说明主动提出FIN申请的可以是客户端，也可以是服务器吧。，你下面描述的 ：都是用 “客户端”作为主动方，是不是会对四次挥手断开连接整体理解造成影响？，，TCP 三次握手建立连接：，图里画的是 “客户机” 和 “服务器”。，所以一般情况下 客户机 都是主动邀请建立链接的那一方。
- Re: Jabnih
- @just coding，仔细看了下，是应该补充上以服务端主动断开的部分，图片我会绘制另一张。晚上的时候我会补充完整，谢谢你的建议。