最近发现一个PHP脚本时常出现连不上服务器的现象，调试了一下，发现是TIME_WAIT状态过多造成的，本文简要介绍一下解决问题的过程。
遇到这类问题，我习惯于先用strace命令跟踪了一下看看：
shell> strace php /path/to/file EADDRNOTAVAIL (Cannot assign requested address)
从字面结果看似乎是网络资源相关问题。这里顺便介绍一点小技巧：在调试的时候一般是从后往前看strace命令的结果，这样更容易找到有价值的信息。
查看一下当前的网络连接情况，结果发现TIME_WAIT数非常大：
shell> netstat -ant | awk '
{++s[$NF]} END {for(k in s) print k,s[k]}
'
补充一下，同netstat相比，ss要快很多：
shell> ss -ant | awk '
{++s[$1]} END {for(k in s) print k,s[k]}
'
重复了几次测试，结果每次出问题的时候，TIME_WAIT都等于28233，这真是一个魔法数字！实际原因很简单，它取决于一个内核参数net.ipv4.ip_local_port_range：
shell> sysctl -a | grep port net.ipv4.ip_local_port_range = 32768 61000
因为端口范围是一个闭区间，所以实际可用的端口数量是：
shell> echo $((61000-32768+1)) 28233
问题分析到这里基本就清晰了，解决方向也明确了，内容所限，这里就不说如何优化程序代码了，只是从系统方面来阐述如何解决问题，无非就是以下两个方面：
首先是增加本地可用端口数量。这点可以用以下命令来实现：
shell> sysctl net.ipv4.ip_local_port_range="10240 61000"
其次是减少TIME_WAIT连接状态。网络上已经有不少相关的介绍，大多是建议：
shell> sysctl net.ipv4.tcp_tw_reuse=1 shell> sysctl net.ipv4.tcp_tw_recycle=1
注：通过sysctl命令修改内核参数，重启后会还原，要想持久化可以参考前面的方法。
这两个选项在降低TIME_WAIT数量方面可以说是立竿见影，不过如果你觉得问题已经完美搞定那就错了，实际上这样可能会引入一个更复杂的网络故障。
关于内核参数的详细介绍，可以参考官方文档。我们这里简要说明一下tcp_tw_recycle参数。它用来快速回收TIME_WAIT连接，不过如果在NAT环境下会引发问题。
RFC1323中有如下一段描述：
An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender’s timestamp clock. Such an extension is not part of the proposal of this RFC.
大概意思是说TCP有一种行为，可以缓存每个主机最新的时间戳，后续请求中如果时间戳小于缓存的时间戳，即视为无效，相应的数据包会被丢弃。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了，当客户端或服务端以NAT方式构建的时候就可能出现问题，下面以客户端NAT为例来说明：
当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，可惜由于这些客户端的时间戳可能存在差异，于是乎从服务端的视角看，便可能出现时间戳错乱的现象，进而直接导致时间戳小的数据包被丢弃。如果发生了此类问题，具体的表现通常是是客户端明明发送的SYN，但服务端就是不响应ACK，我们可以通过下面命令来确认数据包不断被丢弃的现象：
shell> netstat -s | grep timestamp ... packets rejects in established connections because of timestamp
安全起见，通常要禁止tcp_tw_recycle。说到这里，大家可能会想到另一种解决方案：把tcp_timestamps设置为0，tcp_tw_recycle设置为1，这样不就可以鱼与熊掌兼得了么？可惜一旦关闭了tcp_timestamps，那么即便打开了tcp_tw_recycle，也没有效果。
好在我们还有另一个内核参数tcp_max_tw_buckets（一般缺省是180000）可用：
shell> sysctl net.ipv4.tcp_max_tw_buckets=100000
通过设置它，系统会将多余的TIME_WAIT删除掉，此时系统日志里可能会显示：「TCP: time wait bucket table overflow」，不过除非不得已，否则不要轻易使用。
…
总体来说，这次网络故障本身并没什么高深之处，本不想罗罗嗦嗦写这么多，不过拔出萝卜带出泥，在过程中牵扯的方方面面还是值得大家品味的，于是便有了这篇文字。
此条目由老王发表在Technical分类目录，并贴了Linux、TCP标签。将固定链接加入收藏夹。
hi，楼主
我认为文章上有几处错误：
1.文章提到”对于后端服务器来说，请求的源地址就是LVS的地址，加上端口会复用，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接” ， 这里对LVS的原理理解有误。
在 LVS下， 对于后端RealServer来说，他看到的请求报文IP地址都是公网的客户端IP，而不是Load Balancer的。比如LVS-TUN模式就是将客户端的ip包重新用IPIP协议打包后，转发到RealServer，RealServer解包后处理后，就可以直接将回复返回给公网的客户端（此时RealServer和LoadBalancer会共享同一个公网IP，因此可以直接回包），实际上就LVS相当于将客户端与Load Balancer之间的TCP链接迁移到了LB选择的RealServer 。具体可以参考：http://www.linuxvirtualserver.org/zh/lvs3.html
如果是使用nginx这种应用层负载均衡的话，后端的处理server看到的报文的请求IP就是Nginx本身的IP
2. 时间戳错乱的原因搞错了。
限于实际的网络情况，很多用户的客户端没有公网IP，只能依赖于NAT分享同一个公网IP， 这样由于同一NAT下的不同机器的时间戳不一定保证同步，所以就导致同一个NAT过来的数据包的时间戳不能保证单调递增。这样就打破了RFC1323中PAWS方法依赖于对端时间戳单调递增的要求。所以就表现为时间戳错乱，导致丢弃时间戳较小的数据包，表现为packets rejects in established connections because of timestamp的数据不断增加。所以，在LVS中的机器需要关闭tcp_tw_recycle 。