time_wait的作用
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造成的影响：
在高并发短连接的tcp服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于time_wait状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭tcp连接，都会出现timewait。
为什么我们要关注这个高并发短连接呢？有两个方面需要注意：
- 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
-
在这个场景中，短连接表示“业务处理 传输数据的时间 远远小于 timewait超时的时间”的连接。
这里有个相对长短的概念，比如取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在timewait状态几分钟，而这几分钟，其他http请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑timewait状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。
综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用so_reuseaddr选项解决这个问题。
关于time_wait的反思：
- 存在即是合理的，既然tcp协议能盛行四十多年，就证明他的设计合理性。所以我们尽可能的使用其原本功能。
- 依靠time_wait状态来保证我的服务器程序健壮，服务功能正常。
- 那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个timewait状态过多的问题的时候，我的原则是尽量处理，而不是跟timewait干上，非先除之而后快。
- 如果尽量处理了，还是解决不了问题，仍然拒绝服务部分请求，那我会采取负载均衡来抗这些高并发的短请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到时才需要关注这个问题的访问量。
小知识点：
tcp协议发表：1974年12月，卡恩、瑟夫的第一份tcp协议详细说明正式发表。当时美国国防部与三个科学家小组签定了完成tcp/ip的协议，结果由瑟夫领衔的小组捷足先登，首先制定出了通过详细定义的tcp/ip协议标准。当时作了一个试验，将信息包通过点对点的卫星网络，再通过陆地电缆，再通过卫星网络，再由地面传输，贯串欧洲和美国，经过各种电脑系统，全程9.4万公里竟然没有丢失一个数据位，远距离的可靠数据传输证明了tcp/ip协议的成功。
案列分析
首先，根据一个查询tcp连接数，来说明这个问题。
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过多问题?简单来说，就是打开系统的timewait重用和快速回收