近日遇到一个线上服务 socket 资源被不断打满的状况。经过各类工具分析线上问题,定位到问题代码。这里对该问题发现、修复过程进行一下复盘总结。

先看两张图。一张图是服务正常时监控到的 socket 状态，另外一张固然就是异常啦！

从图中的表现状况来看，就是从 04:00 开始，socket 资源不断上涨，每一个谷底时重启后恢复到正常值，而后继续不断上涨不释放，并且每次达到峰值的间隔时间愈来愈短。

重启后，排查了日志，没有看到 panic ，此时也就没有进一步检查，真的觉得重启大法好。

状况说明

该服务使用Golang开发，已经上线正常运行将近一年，提供给其它服务调用，主要底层资源有DB/Redis/MQ。

问题出如今早上 08:20 左右开始的，报警收到该服务出现 504，此时第一反应是该服务长时间没有重启（快两个月了），可能存在一些内存泄漏，没有多想直接进行了重启。也就是在图二第一个谷底的时候，通过重启服务恢复到正常水平（重启真好用，开心）。

将近 14:00 的时候，再次被告警出现了 504 ，当时心中略感不对劲，但因为当天刚好有一场大型促销活动，所以先立马再次重启服务。直到后续大概过了1小时后又开始告警，连续几回重启后，发现须要重启的时间间隔愈来愈短。此时发现问题毫不简单。这一次重启真的解决不了问题老，所以立马申请机器权限、开始排查问题。下面的截图所有来源个人重现demo，与线上无关。

发现问题

出现问题后，首先要进行分析推断、而后验证、最后定位修改。根据当时的表现是分别进行了如下猜测。

推断一

通过查看实时 qps 后，放弃该想法，虽然量有增长，但依然在服务器承受范围（远远未达到压测的基准值）。

推断二

有了上面的的依据，推出的结果是确定是该服务依赖的底层资源除了问题，要否则不可能独立集群的服务同时出问题。

因为监控显示是 socket 问题，所以经过 netstat 命令查看了当前tcp连接的状况（本地测试，线上实际值大的多）

发现绝大部份的连接处于 CLOSE_WAIT 状态，这是很是难以想象状况。而后用 netstat -an 命令进行了检查。

而后开始重点思考为何会出现大量的mysql链接是 CLOSE_WAIT 呢？为了说清楚，咱们来插播一点TCP的四次挥手知识。

TCP四次挥手

Client: 服务端大哥，我事情都干完了，准备撤了，这里对应的就是客户端发了一个FIN

Server：知道了，可是你等等我，我还要收收尾，这里对应的就是服务端收到 FIN 后回应的 ACK

通过上面两步以后，服务端就会处于 CLOSE_WAIT 状态。过了一段时间 Server 收尾完了

到此服务端就能够跑路了，可是客户端还不行。为何呢？客户端还必须等待 2MSL 个时间，这里为何客户端还不能直接跑路呢？主要是为了防止发送出去的 ACK 服务端没有收到，服务端重发 FIN 再次来询问，若是客户端发完就跑路了，那么服务端重发的时候就没人理他了。这个等待的时间长度也很讲究。

这里必定不要被图里的 client／server 和项目里的客户端服务器端混淆，你只要记住：主动关闭的一方发出 FIN 包（Client），被动关闭（Server）的一方响应 ACK 包，此时，被动关闭的一方就进入了 CLOSE_WAIT 状态。若是一切正常，稍后被动关闭的一方也会发出 FIN 包，而后迁移到 LAST_ACK 状态。

结合上面的信息，我用文字说明下：MySQL负载均衡器给个人服务发送 FIN 包，我进行了响应，此时我进入了 CLOSE_WAIR 状态，可是后续做为被动关闭方的我，并无发送 FIN，致使我服务端一直处于 CLOSE_WAIR 状态，没法最终进入 CLOSED 状态。

查找错误缘由

因为代码的业务逻辑并非我写的，我担忧一时半会看不出来问题，因此直接使用 perf 把全部的调用关系使用火焰图给绘制出来。既然上面咱们推断代码中没有释放mysql链接。无非就是：

因为火焰图包含的内容太多，为了让你们看清楚，我把一些没必要要的信息进行了折叠。

火焰图很明显看到了开启了事务，可是在余下的部分，并无看到 Commit 或者是Rollback 操做。这确定会操做问题。而后也清楚看到出现问题的是：

MainController.update 方法内部，话很少说，直接到 update 方法中去检查。发现了以下代码：

至此，所有分析结束。通过查看 getMapNil 返回了nil，可是下面的判断条件没有进行回滚。

总结

整个分析过程仍是废了很多时间。最主要的是主观意识太强，以为运行了一年没有出问题的为何会忽然出问题？所以一开始是质疑 SRE、DBA、各类基础设施出了问题（人老是先怀疑别人）。致使在这上面费了很多时间。

那么本次究竟是为何会出现 CLOSE_WAIR 呢？大部分同窗应该已经明白了，我这里再简单说明一下：

因为那一行代码没有对事务进行回滚，致使服务端没有主动发起close。所以 MySQL负载均衡器 在达到 60s 的时候主动触发了close操做，可是经过tcp抓包发现，服务端并无进行回应，这是由于代码中的事务没有处理，所以从而致使大量的端口、链接资源被占用。在贴一下挥手时的抓包数据：

但愿此文对你们排查线上问题有所帮助。为了便于帮助你们理解，下面附上正确状况下的火焰图与错误状况下的火焰图。你们能够自行对比。

我参考的一篇文章对这种状况提出了两个思考题，我以为很是有意义，你们本身思考下：

统计在一台前端机上高峰时间TCP链接的状况，统计命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

除了ESTABLISHED，能够看到链接数比较多的几个状态是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK；下面的文章就这几个状态的产生条件、对系统的影响以及处理方式进行简单描述。

发现存在大量TIME_WAIT状态的链接
tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT

经过调整内核参数解决
vi /etc/sysctl.conf

编辑文件，加入如下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

而后执行/sbin/sysctl -p让参数生效。

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时间

修改以后，再用命令查看TIME_WAIT链接数
netstat -ae|grep “TIME_WAIT” |wc –l

发现大量的TIME_WAIT 已不存在，mysql进程的占用率很快就降下来的，网站访问正常。
不过不少时候，出现大量的TIME_WAIT状态的链接，每每是由于网站程序代码中没有使用mysql.colse()，才致使大量的mysql TIME_WAIT.

根据TCP协议定义的3次握手断开链接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短链接的服务器,若是是由服务器主动关闭客户端的链接,将致使服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,中止服务. TIME_WAIT是TCP协议用以保证被从新分配的socket不会受到以前残留的延迟重发报文影响的机制,是必要的逻辑保证.
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的
DWORD键,设置为60,以缩短TIME_WAIT的等待时间

若是你的服务器是Windows平台，能够修改下面的注册表键值：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

此值是TIME_WAIT状态的最长时间。缺省为240秒，最低为30秒，最高为300秒。建议为30秒。

注释：
（
1，TCP结束的过程以下:

Server Client

-------------- FIN --------------> server: fin_wait_1

<------------- ACK --------------- client: close_wait server:fin_wait_2

<------------- FIN --------------- client发出fin以后就关闭

-------------- ACK -------------> server发出ack后进入time_wait状态

Time_Wait的默认时间是2倍的MLS，就是240秒钟。MLS是TCP片在网上的最长存活时间。
TIME_Wait的主要做用是保证关闭的TCP端口不当即被使用。由于当网络存在延迟时，可能当某个端口被关闭后，网络中还有一些重传的TCP片在发向这个端口，若是这个端口当即创建新的TCP链接，则可能会有影响。因此使用2倍的MSL时间来限制这个端口当即被使用。

如今的问题在于，4分钟的时间有点长。
所以，Time_wait的影响，我想，首先每一个TCP链接都各自有个数据结构，叫TCP Control Block.Time_wait的时候这个数据结构没有被释放。因此当有太多的TCP链接时，内存可能会被占用不少。

2，To ValorZ：TIME_WAIT状态也称为2MSL等待状态，而不是2MLS，笔误吧！
每一个TCP报文在网络内的最长时间，就称为MSL（Maximum Segment Lifetime），它的做用和IP数据包的TTL相似。
RFC793指出，MSL的值是2分钟，可是在实际的实现中，经常使用的值有如下三种：30秒，1分钟，2分钟。
注意一个问题，进入TIME_WAIT状态的通常状况下是客户端，大多数服务器端通常执行被动关闭，不会进入TIME_WAIT状态，当在服务器端关闭某个服务再从新启动时，它是会进入TIME_WAIT状态的。

举例：
1.客户端链接服务器的80服务，这时客户端会启用一个本地的端口访问服务器的80，访问完成后关闭此链接，马上再次访问服务器的80，这时客户端会启用另外一个本地的端口，而不是刚才使用的那个本地端口。缘由就是刚才的那个链接还处于TIME_WAIT状态。

2.客户端链接服务器的80服务，这时服务器关闭80端口，当即再次重启80端口的服务，这时可能不会成功启动，缘由也是服务器的链接还处于TIME_WAIT状态。

1. 实际问题
初步查看发现，没法对外新建TCP链接时，线上服务器存在大量处于TIME_WAIT状态的TCP链接（最多的一次为单机10w+，其中引发报警的那个模块产生的TIME_WAIT约2w），致使其没法跟下游模块创建新TCP链接。
TIME_WAIT涉及到TCP释放链接过程当中的状态迁移，也涉及到具体的socket api对TCP状态的影响，下面开始逐步介绍这些概念。

2. TCP状态迁移
面向链接的TCP协议要求每次peer间通讯前创建一条TCP链接，该链接可抽象为一个4元组（four-tuple，有时也称socket pair）：（local_ip, local_port, remote_ip,remote_port），这4个元素惟一地表明一条TCP链接。
1）TCP Connection Establishment
TCP创建链接的过程，一般又叫“三次握手”（three-way handshake），可用下图来示意：

可对上图作以下解释：
a. client向server发送SYN并约定初始包序号（sequence number）为J；
b. server发送本身的SYN并代表初始包序号为K，同时，针对client的SYNJ返回ACKJ+1（注：J+1表示server指望的来自该client的下一个包序为J+1）；
c. client收到来自server的SYN+ACK后，发送ACKK+1，至此，TCP创建成功。
其实，在TCP创建时的3次握手过程当中，还要经过SYN包商定各自的MSS，timestamp等参数，这涉及到协议的细节，本文旨在抛砖引玉，再也不展开。

2）TCPConnection Termination
与创建链接的3次握手相对应，释放一条TCP链接时，须要通过四步交互（又称“四次挥手”），以下图所示：

可对上图作以下解释：
a. 链接的某一方先调用close()发起主动关闭（active close），该api会促使TCP传输层向remotepeer发送FIN包，该包代表发起active close的application再也不发送数据（特别注意：这里“再也不发送数据”的承诺是从应用层角度来看的，在TCP传输层，仍是要将该application对应的内核tcp send buffer中当前还没有发出的数据发到链路上）。
remote peer收到FIN后，须要完成被动关闭（passive close），具体分为两步：
b. 首先，在TCP传输层，先针对对方的FIN包发出ACK包（主要ACK的包序是在对方FIN包序基础上加1）；
c. 接着，应用层的application收到对方的EOF（end-of-file，对方的FIN包做为EOF传给应用层的application）后，得知这条链接不会再有来自对方的数据，因而也调用close()关闭链接，该close会促使TCP传输层发送FIN。
d. 发起主动关闭的peer收到remote peer的FIN后，发送ACK包，至此，TCP链接关闭。
注意1：TCP链接的任一方都可以首先调用close()以发起主动关闭，上图以client主动发起关闭作说明，而不是说只能client发起主动关闭。
注意2：上面给出的TCP创建/释放链接的过程描述中，未考虑因为各类缘由引发的重传、拥塞控制等协议细节，感兴趣的同窗能够查看各类TCP RFC Documents ，好比TCP RFC793。

3）TCP StateTransition Diagram
上面介绍了TCP创建、释放链接的过程，此处对TCP状态机的迁移过程作整体说明。将TCP RFC793中描述的TCP状态机迁移图摘出以下（下图引用自这里）：

TCP状态机共含11个状态，状态间在各类socket apis的驱动下进行迁移，虽然此图看起来错综复杂，但对于有必定TCP网络编程经验的同窗来讲，理解起来仍是比较容易的。限于篇幅，本文不许备展开详述，想了解具体迁移过程的新手同窗，建议阅读《Linux Network Programming Volume1》第2.6节。

3. TIME_WAIT状态
通过前面的铺垫，终于要讲到与本文主题相关的内容了。 ^_^
从TCP状态迁移图可知，只有首先调用close()发起主动关闭的一方才会进入TIME_WAIT状态，并且是必须进入（图中左下角所示的3条状态迁移线最终均要进入该状态才能回到初始的CLOSED状态）。
从图中还可看到，进入TIME_WAIT状态的TCP链接须要通过2MSL才能回到初始状态，其中，MSL是指Max
Segment Lifetime，即数据包在网络中的最大生存时间。每种TCP协议的实现方法均要指定一个合适的MSL值，如RFC1122给出的建议值为2分钟，又如Berkeley体系的TCP实现一般选择30秒做为MSL值。这意味着TIME_WAIT的典型持续时间为1-4分钟。
TIME_WAIT状态存在的缘由主要有两点：
1）为实现TCP这种全双工（full-duplex）链接的可靠释放
参考本文前面给出的TCP释放链接4次挥手示意图，假设发起active close的一方（图中为client）发送的ACK（4次交互的最后一个包）在网络中丢失，那么因为TCP的重传机制，执行passiveclose的一方（图中为server）须要重发其FIN，在该FIN到达client（client是active close发起方）以前，client必须维护这条链接的状态（尽管它已调用过close），具体而言，就是这条TCP链接对应的（local_ip, local_port）资源不能被当即释放或从新分配。直到romete peer重发的FIN达到，client也重发ACK后，该TCP链接才能恢复初始的CLOSED状态。若是activeclose方不进入TIME_WAIT以维护其链接状态，则当passive close方重发的FIN达到时，active close方的TCP传输层会以RST包响应对方，这会被对方认为有错误发生（而事实上，这是正常的关闭链接过程，并不是异常）。
2）为使旧的数据包在网络因过时而消失
为说明这个问题，咱们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP链接：(local_ip, local_port, remote_ip,remote_port)，因某些缘由，咱们先关闭，接着很快以相同的四元组创建一条新链接。本文前面介绍过，TCP链接由四元组惟一标识，所以，在咱们假设的状况中，TCP协议栈是没法区分先后两条TCP链接的不一样的，在它看来，这根本就是同一条链接，中间先释放再创建的过程对其来讲是“感知”不到的。这样就可能发生这样的状况：前一条TCP链接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当作当前TCP链接的正常数据接收并向上传递至应用层（而事实上，在咱们假设的场景下，这些旧数据到达remote peer前，旧链接已断开且一条由相同四元组构成的新TCP链接已创建，所以，这些旧数据是不该该被向上传递至应用层的），从而引发数据错乱进而致使各类没法预知的诡异现象。做为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种状况的发生，这正是TIME_WAIT状态存在的第2个缘由。
具体而言，local peer主动调用close后，此时的TCP链接进入TIME_WAIT状态，处于该状态下的TCP链接不能当即以一样的四元组创建新链接，即发起active close的那方占用的local port在TIME_WAIT期间不能再被从新分配。因为TIME_WAIT状态持续时间为2MSL，这样保证了旧TCP链接双工链路中的旧数据包均因过时（超过MSL）而消失，此后，就能够用相同的四元组创建一条新链接而不会发生先后两次链接数据错乱的状况。

TIME_WAIT状态的存在有两个理由：（1）让4次握手关闭流程更加可靠；4次握手的最后一个ACK是是由主动关闭方发送出去的，若这个ACK丢失，被动关闭方会再次发一个FIN过来。若主动关闭方可以保持一个2MSL的TIME_WAIT状态，则有更大的机会让丢失的ACK被再次发送出去。（2）防止lost duplicate对后续新建正常连接的传输形成破坏。lost duplicate在实际的网络中很是常见，常常是因为路由器产生故障，路径没法收敛，致使一个packet在路由器A，B，C之间作相似死循环的跳转。IP头部有个TTL，限制了一个包在网络中的最大跳数，所以这个包有两种命运，要么最后TTL变为0，在网络中消失；要么TTL在变为0以前路由器路径收敛，它凭借剩余的TTL跳数终于到达目的地。但很是惋惜的是TCP经过超时重传机制在早些时候发送了一个跟它如出一辙的包，并先于它达到了目的地，所以它的命运也就注定被TCP协议栈抛弃。另一个概念叫作incarnation connection，指跟上次的socket pair一摸同样的新链接，叫作incarnation of previous connection。lost duplicate加上incarnation connection，则会对咱们的传输形成致命的错误。你们都知道TCP是流式的，全部包到达的顺序是不一致的，依靠序列号由TCP协议栈作顺序的拼接；假设一个incarnation connection这时收到的seq=1000, 来了一个lost duplicate为seq=1000, len=1000, 则tcp认为这个lost duplicate合法，并存放入了receive buffer，致使传输出现错误。经过一个2MSL TIME_WAIT状态，确保全部的lost duplicate都会消失掉，避免对新链接形成错误。

A: 这个套接字选项通知内核，若是端口忙，但TCP状态位于 TIME_WAIT ，能够重用

端口。若是端口忙，而TCP状态位于其余状态，重用端口时依旧获得一个错误信息，

指明"地址已经使用中"。若是你的服务程序中止后想当即重启，而新套接字依旧

使用同一端口，此时 SO_REUSEADDR 选项很是有用。必须意识到，此时任何非期

望数据到达，均可能致使服务程序反应混乱，不过这只是一种可能，事实上很不

TIME_WAIT

这个是高并发服务端常见的一个问题，通常的作法是修改sysctl的参数来解决。可是，作为一个有追求的程序猿，你须要多问几个为何，为何会出现TIME_WAIT？出现这个合理吗？

咱们须要先回顾下tcp的知识，请看下面的状态转换图（图片来自「The TCP/IP Guide」）：

由于TCP链接是双向的，因此在关闭链接的时候，两个方向各自都须要关闭。先发FIN包的一方执行的是主动关闭；后发FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，而且在此状态停留两倍的MSL时长。

修改sysctl的参数，只是控制TIME_WAIT的数量。你须要很明确的知道，在你的应用场景里面，你预期是服务端仍是客户端来主动关闭链接的。通常来讲，都是客户端来主动关闭的。

nginx在某些状况下，会主动关闭客户端的请求，这个时候，返回值的connection为close。咱们看两个例子：

http 1.0协议

请求包：

GET /hello HTTP/1.0 User-Agent: curl/7.37.1 Host: 127.0.0.1 Accept: */* Accept-Encoding: deflate, gzip

应答包：

HTTP/1.1 200 OK Date: Wed, 08 Jul 2015 02:53:54 GMT Content-Type: text/plain Connection: close Server: 360 web server hello world

对于http 1.0协议，若是请求头里面没有包含connection，那么应答默认是返回Connection: close，也就是说nginx会主动关闭链接。

user agent

请求包：

POST /api/heartbeat.json HTTP/1.1 Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) Accept-Encoding: gzip, deflate Accept: */* Connection: Keep-Alive Content-Length: 0

应答包：

HTTP/1.1 200 OK Date: Mon, 06 Jul 2015 09:35:34 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: close Server: 360 web server Content-Encoding: gzip

这个请求包是http1.1的协议，也声明了Connection: Keep-Alive，为何还会被nginx主动关闭呢？问题出在User-Agent，nginx认为终端的浏览器版本过低，不支持keep alive，因此直接close了。

在咱们应用的场景下，终端不是经过浏览器而是后台请求的，而咱们也无法控制终端的User-Agent，那有什么方法不让nginx主动去关闭链接呢？能够用keepalive_disable这个参数来解决。这个参数并非字面的意思，用来关闭keepalive，而是用来定义哪些古代的浏览器不支持keepalive的，默认值是MSIE6。

keepalive_disable none;

修改成none，就是认为再也不经过User-Agent中的浏览器信息，来决定是否keepalive。

一、 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。

为何咱们要关注这个高并发短链接呢？有两个方面须要注意：
1. 高并发可让服务器在短期范围内同时占用大量端口，而端口有个0~65535的范围，并非不少，刨除系统和其余服务要用的，剩下的就更少了。
2. 在这个场景中，短链接表示“业务处理+传输数据的时间远远小于 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

状态描述：

View Code

命令解释：

View Code

如何尽可能处理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套接字拖死。

CLOSE_WAIT、CLOSE_WAIT缘由，危害，如何避免

time_wait状态产生的缘由，危害，如何避免

解答：

状况说明

发现问题

推断一

推断二

TCP四次挥手

查找错误缘由

总结

TIME_WAIT问题

TIME_WAIT

http 1.0协议

user agent