一、 time_wait的做用：java
TIME_WAIT状态存在的理由： 1）可靠地实现TCP全双工链接的终止 在进行关闭链接四次挥手协议时，最后的ACK是由主动关闭端发出的，若是这个最终的ACK丢失，服务器将重发最终的FIN， 所以客户端必须维护状态信息容许它重发最终的ACK。若是不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。 于是，要实现TCP全双工链接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失状况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。 2）容许老的重复分节在网络中消逝 TCP分节可能因为路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。 在关闭一个TCP链接后，立刻又从新创建起一个相同的IP地址和端口之间的TCP链接，后一个链接被称为前一个链接的化身（incarnation)，那么有可能出现这种状况，前一个链接的迷途重复分组在前一个链接终止后出现，从而被误解成从属于新的化身。 为了不这个状况，TCP不容许处于TIME_WAIT状态的链接启动一个新的化身，由于TIME_WAIT状态持续2MSL，就能够保证当成功创建一个TCP链接的时候，来自链接先前化身的重复分组已经在网络中消逝。
二、大量TIME_WAIT形成的影响：web
在高并发短链接的TCP服务器上，当服务器处理完请求后马上主动正常关闭链接。这个场景下会出现大量socket处于TIME_WAIT状态。若是客户端的并发量持续很高，此时部分客户端就会显示链接不上。
我来解释下这个场景。主动正常关闭TCP链接，都会出现TIMEWAIT。数组
为何咱们要关注这个高并发短链接呢？有两个方面须要注意：
1. 高并发可让服务器在短期范围内同时占用大量端口，而端口有个0~65535的范围，并非不少，刨除系统和其余服务要用的，剩下的就更少了。
2. 在这个场景中，短链接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的链接。服务器
这里有个相对长短的概念，好比取一个web页面，1秒钟的http短链接处理完业务，在关闭链接以后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其余HTTP请求来临的时候是没法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着没法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长链接业务的服务就不须要考虑TIMEWAIT状态。同时，假如你对服务器业务场景很是熟悉，你会发现，在实际业务场景中，通常长链接对应的业务的并发量并不会很高。
综合这两个方面，持续的到达必定量的高并发短链接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，没法用SO_REUSEADDR选项解决这个问题。cookie
关于time_wait的反思：网络
存在便是合理的，既然TCP协议能盛行四十多年，就证实他的设计合理性。因此咱们尽量的使用其本来功能。 依靠TIME_WAIT状态来保证个人服务器程序健壮，服务功能正常。 那是否是就不要性能了呢？并非。若是服务器上跑的短链接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，个人原则是尽可能处理，而不是跟TIMEWAIT干上，非先除之然后快。 若是尽可能处理了，仍是解决不了问题，仍然拒绝服务部分请求，那我会采起负载均衡来抗这些高并发的短请求。持续十万并发的短链接请求，两台机器，每台5万个，应该够用了吧。通常的业务量以及国内大部分网站其实并不须要关注这个问题，一句话，达不到时才须要关注这个问题的访问量。
小知识点：并发
TCP协议发表：1974年12月，卡恩、瑟夫的第一份TCP协议详细说明正式发表。当时美国国防部与三个科学家小组签订了完成TCP/IP的协议，结果由瑟夫领衔的小组捷足先登，首先制定出了经过详细定义的TCP/IP协议标准。当时做了一个试验，将信息包经过点对点的卫星网络，再经过陆地电缆
，再经过卫星网络，再由地面传输，贯串欧洲和美国，通过各类电脑系统，全程9.4万千米居然没有丢失一个数据位，远距离的可靠数据传输证实了TCP/IP协议的成功。
三、案列分析：负载均衡
首先，根据一个查询TCP链接数，来讲明这个问题。socket
netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122
状态描述：
CLOSED：无链接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个链接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个链接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另外一边已赞成释放 ITMED_WAIT：等待全部分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另外一边已初始化一个释放 LAST_ACK：等待全部分组死掉
命令解释：
先来看看netstat： netstat -n Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT 你实际执行这条命令的时候，可能会获得成千上万条相似上面的记录，不过咱们就拿其中的一条就足够了。 再来看看awk： /^tcp/ 滤出tcp开头的记录，屏蔽udp, socket等无关记录。 state[]至关于定义了一个名叫state的数组 NF 表示记录的字段数，如上所示的记录，NF等于6 $NF 表示某个字段的值，如上所示的记录，$NF也就是$6，表示第6个字段的值，也就是TIME_WAIT state[$NF]表示数组元素的值，如上所示的记录，就是state[TIME_WAIT]状态的链接数 ++state[$NF]表示把某个数加一，如上所示的记录，就是把state[TIME_WAIT]状态的链接数加一 END 表示在最后阶段要执行的命令 for(key in state) 遍历数组
如何尽可能处理TIMEWAIT过多?
编辑内核文件/etc/sysctl.conf，加入如下内容：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少许SYN攻击，默认为0，表示关闭； net.ipv4.tcp_tw_reuse = 1 表示开启重用。容许将TIME-WAIT sockets从新用于新的TCP链接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP链接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。 net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间
而后执行 /sbin/sysctl -p 让参数生效.
/etc/sysctl.conf是一个容许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。
简单来讲，就是打开系统的TIMEWAIT重用和快速回收。
若是以上配置调优后性能还不理想，可继续修改一下配置：
vi /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200 #表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改成20分钟。 net.ipv4.ip_local_port_range = 1024 65000 #表示用于向外链接的端口范围。缺省状况下很小：32768到61000，改成1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN队列的长度，默认为1024，加大队列长度为8192，能够容纳更多等待链接的网络链接数。 net.ipv4.tcp_max_tw_buckets = 5000 #表示系统同时保持TIME_WAIT套接字的最大数量，若是超过这个数字，TIME_WAIT套接字将马上被清除并打印警告信息。 默认为180000，改成5000。对于Apache、Nginx等服务器，上几行的参数能够很好地减小TIME_WAIT套接字数量，可是对于 Squid，效果却不大。此项参数能够控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。