之前自己学习的网络都是浅尝辄止，最近被人反复问起 TCP 相关的挥手问题的相关问题，有必要整理下自身所学，以提供自己和别人查阅。
下图是 TCP 挥手的一个完整流程，这里引用了 tcpipguide 的流程图，更加直观的了解下挥手过程。
首先不要被这里的图给迷惑了，因为连接的主动断开是可以发生在客户端，也同样可以发生在服务端。
FIN_WAIT1
由图可知，当一方接受到来自应用断开连接的信号时候，就发送 FIN 数据报来进行主动断开，并且该连接进入 FIN_WAIT1 状态，连接处于半段开状态(可以接受、应答数据，当不能发送数据)，并将连接的控制权托管给 Kernel，程序就不再进行处理。一般情况下，连接处理 FIN_WAIT1 的状态只是持续很短的一段时间。
我这里通过对数据包的拦截（不对 FIN 请求进行应答）来实现 FIN_WAIT1 状态，下图是主动断开一遍的 FIN 数据发送抓包记录。
在 18:12.43 的时间点，这台机器主动断开连接，并发送 FIN 请求，并且达到 RTO 后未收到响应后，一共重试了9次，每次重试时间是上一次的2倍，这条连接额外占用了 54 秒的时间。如果在服务中，这类连接数据一多就会消耗大量的服务器资源，我这里简单的提供 2 个参数来处理这个问题。
tcp_orphan_retries ：Integer，这里系统参数默认为 9（文档里面默认值为7，和系统配置有关），就是近端丢弃 TCP 连接的时候，重试次数，在我的系统中。在刚刚那种情况，如果将该参数调整为 3 次，这类连接在系统中存活的时间就会大大减少，从而缓解这个问题。如果你的系统负载很大，有发现是因为 FIN_WAIT1 引起的，也可以适当的调整这个参数。
tcp_max_orphans：Integer，默认值 8096。系统所能处理不属于任何进程的 TCP sockets 最大数量。当超过这个值所有不属于任何进程的 TCP 连接(孤儿连接)都会被重置。这个参数仅仅是为了防御简单的 Dos ，不能依赖这个参数。
FIN_WAIT2
当主动断开一端的 FIN 请求发送出去后，并且成功够接受到相应的 ACK 请求后，就进入了 FIN_WAIT2 状态。其实 FIN_WAIT1 和 FIN_WAIT2 状态都是在等待对方的 FIN 数据报。当 TCP 一直保持这个状态的时候，对方就有可能永远都不断开连接，导致该连接一直保持着。
tcp_fin_timeout ：Integer，默认 60，单位秒，不属于任何应用的孤儿连接保持 FIN_WAIT2 状态的最长时间，一当超过这个时间，就会被本地直接关闭，不会进入 TIME_WAIT 状态。
但是总体上来将处于 FIN_WAIT2 状态的 TCP 连接，威胁要比 FIN_WAIT1 的小，占用的资源也很小，通常不会有什么问题。
TIME_WAIT
当前面的步骤都顺利完成了，并且接受到了 被动关闭端 发送过来的 FIN 数据报后，系统做出 ACK 应答后，该连接就进入了尾声，也就是 TIME_WAIT 状态。内核会设定一个时间长度为 2MSL 的定时器，当定时器在到时间点后，内核就会将该连接关闭。反之，当连接尚未关闭的时候，又收到了对方发送过来的 FIN 请求（可能是我们发送出去的请求对方并未收到），或者收到 ICMP 请求（比如 ACK 数据报，在网络传输中出现了错误），该连接就会重新发送 ACK 请求，并重置定时器。
为什么要设置时间为 2MSL？
MSL 是Maximum Segment Lifetime,译为“报文最大生存时间”，任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
等待 2MSL 时间主要目的是怕最后一个 ACK 对方没收到，那么对方在超时后将重发第三次握手的 FIN ，主动关闭端接到重发的 FIN 包后，系统收到该分组后，可以再发一个 ACK 应答包。还有就是等来该连接在网络上的所有报文都传输完毕，所以处于 TIME_WAIT 状态时候，两端的端口都是不可用的，迟到的报文都会被废弃。
如果我们设置的时间少于 2MSL ，旧的连接刚刚关闭，这个时候有同样五元组的新连接进来了，而之前的连接还有残留报文在网络上，就会干扰新的连接的使用。
反之，如果连接处于 TIME_WAIT 过长，造成新 socket 无法复用这个端口，即使这个连接完全废弃（通常来说一个端口释放后会等待两分钟之后才能再被使用）。就像拉完屎还占着茅坑，可以尝试使用下SO_REUSEADDR（socket 参数）,比如在服务停止后立即重启，这个时候可能会遇到原先的连接还处于 TIME_WAIT 状态，导致无法绑定原先的端口，就可以使用 SO_REUSEADDR。
tcp_timestamps: Boolean，默认1，表示tcp通讯的时候是否是否使用时间戳。如下图，在 TCP 头部信息的扩展头部字段中就附带了时间戳，数据长度为两个4字节。TSval是该数据报发送出来的时间，TSecr是回显时间戳（即该ack对应的data或者该data对应的上次 ack 中的 TSval 值）
tcp_tw_reuse:Boolean，默认0，只在客户端有效，就是 TCP TIME_WAIT 链路复用。比如，当客户端不断向服务端建立连接获取数据，当每次都是客户端自己关闭连接，导致服务端进入 TIME_WAIT，之后客户端又要不断重连对方继续拉取数据，这个时候就可以复用 TIME_WAIT 的连接。当连接复用后势必会有旧连接残留在网络上的数据报，那么这些数据报要怎么处理，才能不影响新的连接的使用呢。可以使用上面的参数，时间戳来判断，建立建立后将缓存的时间戳更新到现在，当早于这个时间戳的数据报进来就表明是老连接的数据，内核会直接废弃掉。
tcp_tw_recycle:Boolean，默认0，启动后能够更快地回收 TIME_WAIT 套接字。不再是2MSL，而是几个 RTO 内进行回收。所以在网络上同样会残存旧连接的数据报，内核同样可以通过时间戳的方式来判断、丢弃过时数据报。
在早期的网络通信中，开启这个参数会导致一个问题。当多个客户端通过NAT方式联网同时与服务端通信，对于服务端只收到一个IP就好像是一台客户端进行与其进行通讯，但是客户端之间会有时间戳差异，就会导致服务端会将认为过期的数据报丢弃。导致只允许一个客户端与其进行通讯。现在的 NAT 服务器已经将协议升级成了NAPT，可以采用多端口与服务端通讯就可以避免这件事情。
CLOSE_WAIT
当被动关闭端，也就是图中的服务端，接受到了对方发送过来的 FIN 请求，并且对请求做出应答后，该连接就进入了 CLOSE_WAIT ，当连接处于这个状态的时候，该连接可能有数据需要发送，或者一些其他事情要做，当这类连接过多的时候，就会导致网络性能下降，耗尽连接数，无法建立新的连接。
比如连接一直没得到释放，相应的资源一直被占用，一但达到句柄数的上限（ linux 可以通过 ulimit -a 查看 open files 数值，默认1024 ）后，新的请求就无法继续处理，就会返回大量的 Too Many Open Files 错误。
常见错误原因
1.代码层面上未对连接进行关闭，比如关闭代码未写在 finally 块关闭，如果程序中发生异常就会跳过关闭代码，自然未发出指令关闭，连接一直由程序托管，内核也无权处理，自然不会发出 FIN 请求，导致连接一直在 CLOSE_WAIT 。
2.程序响应过慢，比如双方进行通讯，当客户端请求服务端迟迟得不到响应，就断开连接，重新发起请求，导致服务端一直忙于业务处理，没空去关闭连接。这种情况也会导致这个问题。
缓解方案
1.修改 /etc/security/limits.conf 配置文件中参数，提高句柄数上限
2.修改 tcp 参数
参数名 默认值 优化值 说明
net.ipv4.tcp_keepalive_time 7200 1800 单位秒，默认为7200s，就是说一个异常的CLOSE_WAIT连接至少会维持2个小时
net.ipv4.tcp_keepalive_probes 9 3 在认定TCP连接失效之前，最多发送多少个keepalive探测消息。
tcp_keepalive_intvl 75 15 探测消息未获得响应时，重发该消息的间隔时间（秒）。
3.检查自己的代码，修改连接不规范的地方。
LAST_ACK
当被动关闭一段，发送出去了 FIN 数据报后，套接字就进入了 LAST_ACK 状态，并且等待对方进行发送 ACK 数据报。
1.收到了响应的ACK数据报后，连接进入CLOSED 状态，并释放相关资源
2.如果超时未收到响应，就触发了TCP的重传机制。
到此整个挥手流程就结束了。
相关文档
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
补充
服务器保持了大量的close_wait状态
time_wait问题可以通过调整内核参数和适当的设置web服务器的keep-Alive值来解决。因为time_wait是自己可控的，要么就是对方连接的异常，要么就是自己没有快速的回收资源，总之不是由于自己程序错误引起的。但是close_wait就不一样了，从上图中我们可以看到服务器保持大量的close_wait只有一种情况，那就是对方发送一个FIN后，程序自己这边没有进一步发送ACK以确认。换句话说就是在对方关闭连接后，程序里没有检测到，或者程序里本身就已经忘了这个时候需要关闭连接，于是这个资源就一直被程序占用着。这个时候快速的解决方法是：
关闭正在运行的程序，这个需要视业务情况而定
尽快的修改程序里的bug，然后测试提交到线上服务器
rd写了爬虫运行在采集服务器A上，程序去B服务器上采集资源，但是A服务器很快就发现出现了大量的close_wait状态的连接。后来检查才发现这些处于close_wait状态的请求结果都是404，那就说明B服务器上没有要请求的资源。
服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务B获取文件资源，正常情况下，如果请求成功，那么在抓取完 资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设 请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了
可能的原因如下：
关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放
CLOSE_WAIT问题排查
程序Bug，接收到FIN信号后没有及时关闭socket，这可能是netty的bug，也可能是业务层bug
关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义task比例过高，导致I/O操作处理不及时，链路不能被及时释放