TCP FIN_WAIT2由来

TCP 为什么要有FIN_WAIT2， 主要是为了维护一个全双工的通道，
要弄懂这个问题， 必须要弄清楚， TCP断开链接时的四次挥手。如图所示

tcp四次挥手，由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动（关闭读端，写端还不会关闭），一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
1.当一方主动断开链接， 给对端发送（FIN = 1， seq)。
2.自己进入FIN_WAIT1状态， 等待对端回复（ACK, seq）
3.对端收到(FIN = 1, seq) 后，向它的对端回复ACK。
发送FIN一方，收到ACK后。 就进入FIN_WAIT2 状态。 直到收到对端发送过来的FIN.
这就是FIN_WAT2的由来。
在实际生产项目中。服务器程序上，经常出现很多FIN_WAIT2, 由netstat -ant
可以查看连接。如果出现过多的FIN_WAIT2。会大量耗费服务器资源， 因为这些连接并没有销毁。它们等待对端发过来的的FIN， 如果对端已不在， 或已断线，它们会一直占用系统资源。
SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。
那么问题来了， 怎么解决这个问题呢？
解决方案：
修改/etc/sysctl.conf文件：
net.ipv4.tcp_syncookies = 1
表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
net.ipv4.tcp_fin_timeout = 30
表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_max_syn_backlog = 8192
表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000
表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。
这是修改操作系统配置方法。
另外在NODEJS下， 当服务器关闭SOCKET 不要用半关闭 socket.end(); 需应该用销毁连接方法。socket.destroy(); 自测可行。
END