TCP连接中TIME_WAIT连接过多 - 推酷
TCP连接中TIME_WAIT连接过多
TIMEWAIT状态本身
和应用层的客户端或者服务器是没有关系的。仅仅是主动关闭的一方，在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候
会出现这个TIMEWAIT。服务器在处理客户端请求的时候，如果你的程序设计为服务器主动关闭，那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭，那么你首先要关注的是CLOSE_WAIT。
TIMEWAIT并不是多余的
在TCP协议被创造，
经历了大量的实际场景实践之后
出现了，因为TCP主
动关闭连接的一方需要TIMEWAIT状态，它是我们的朋友。这是
UNIX网络编程
》的作者----Steven对TIMEWAIT的态度。
TIMEWAIT是友好的
要保证在所有可能的情况下使得所有的数据都能够被正确送达。当你关闭一个
时，主动关闭一端的
状态，而被动关闭一方则转入CLOSED状态，这的确能够保证所有的数据都被传输。当一个socket关闭的时候，是通过两端四次握手完成的，当一端调用close()时，就说明本端没有数据要发送了。这好似看来在握手完成以后，socket就都可以处于初始的CLOSED状态了，其实不然。原因是这样安排状态有两个问题， 首先，我们没有任何机制保证最后的一个ACK能够正常传输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必须能够正常处理。
TIMEWAIT就是为了解决这两个问题而生的。
1.假设最后一个
丢失了，被动关闭一方会重发它的
主动关闭一方必须维持一个有效状态信息（TIMEWAIT状态下维持），以便能够重发
如果主动关闭的socket不维持这种状态而进入CLOSED状态，那么主动关闭的socket在处于CLOSED状态时，
接收到FIN后将会响应一个RST。被动关闭一方接收到RST后会认为出错了。如果TCP协议想要正常完成必要的操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个节，不能有任何的丢失。这就是为什么socket在关闭后，仍然处于TIME_WAIT状态的第一个原因，因为他要等待以便重发ACK。
目前连接的通信双方都已经调用了
，双方同时进入
CLOSED的终结
状态，而没有走
状态。会出现如下问题，现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后建立的连接是原先连接的一个完全复用。还假定原先的连接中有数据报残存于网络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点，TCP不允许新连接复用TIME_WAIT状态下的socket。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL），将会转变为CLOSED状态。这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。
大量TIMEWAIT在某些场景中导致的令人头疼的业务
大量TIMEWAIT出现，并且需要解决
在高并发短连接的TCP服务器上，当服务器处理完
请求后立刻按照主动正常
关闭连接。。。这个场景下，
会出现大量socket处于
状态。如果客户端的并发量持续很高，
此时部分客户端就会显示
连接不上。
我来解释下这个场景。
主动正常关闭TCP连接，都会出
现TIMEWAIT。为什么我们要关注这个高并发短连接呢？有两个方面需要注意
1. 高并发可以让服务器在短时间范围内同时
占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了
2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短
的概念，比如，取一个web页面，1秒钟的http
短连接处理完业务，
在关闭连接之后，这个业务用过的端口
会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的
。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）
被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，
长连接业务的服务
就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，
一般长连接对应的业务的并发量并不会很高
综合这两个方面，持续的到达一定量的
高并发短连接，会使服务器因端口资源不足而拒绝为一
部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_
ADDR选项解决这个问题:(
TIMEWAIT既友好，又令人头疼。
但是我们还是要抱着一个友好的态度来看待它，因为它尽它的能力保证了服务器的健壮性。
可行而且必须存在，
但是不符合原则的解决方式
1. linux没有在sysctl或者proc文件系统暴露修改
这个TIMEWAIT超时时间的接口
，可以修改内核协议栈代码中关于这个TIMEWAIT的超时时间参数，重编内核，让它缩短超时时间，加快回收；
2. 利用SO_LINGER选项的强制关闭方式，发RST而不是FIN，来越过TIMEWAIT状态，直接进入CLOSED状态。详见我的博
我如何看待这个问题
为什么说上述两种解决方式我觉得可行，但是不符合原则？
我首先认为，我要依靠TIMEWAIT状态来保证我的服务器程序健壮，网络上发生的乱七八糟的问题太多了，我先要服务功能正常。
那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是
处理，而不是跟TIMEWAIT干上，非先除之而后快：）如果
处理了，还是解决不了问题，仍然拒绝服务
，那我会采取分机器的方法
，让多台机器来抗
请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到需要关注这个问题的访问量。
真正地必须使用
上述我认为不合理的方式
来解决这个问题的场景有没有呢？答案是有。
像淘宝、百度、
新浪、京东商城这样的站点，由于有很多静态小图片业务，如果过度分服会导致需要上线大量机器，多买机器多花钱，得多配机房，多配备运维工程师来守护这些机器，成本增长非常严重。。。这个时候就要尽一切可能去优化。
题外话，服务器上的技术问题没有绝对，一切都是为业务需求服务的。
处理TIMEWAIT过多
sysctl改两个内核参数就行了，如下：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
简单来说，就是打开系统的TIMEWAIT重用和快速回收，至于怎么重用和快速回收，这个问题
我没有深究，实际场景中这么做确实有效果。
用netstat或者ss观察就能得出结论。
还有些朋友同时也会打开syncookies这个功能，如下：
net.ipv4.tcp_syncookies = 1
打开这个syncookies
目的实际上是：
“在服务器资源（并非单指端口资源，拒绝服务有很多种资源不足的情况
情况下，尽量不要拒绝TCP的
）请求，尽量把syn请求缓存起来，留着过会儿有能力的时候
处理这些TCP的连接请求
如果并发量真的非常非常高，打开这个其实用处不大。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
白手起家, 积分 47, 距离下一级还需 153 积分
论坛徽章:0
本帖最后由 YunThanatos 于
22:36 编辑
TIME-WAIT一般设60s左右或者以上 原因:
1.确保可靠地回复被动关闭方最后一个FIN（这个正确）
2.允许老的重复分节在网络中消逝 如果这个数据包”迟到“了 不会影响到新的TCP连接（这个我认为不合理 论据如下）
就算新的连接五元组{tcp,dip,dport,sip,sport}与刚被关闭的TCP连接完全相同 但是：
&&命题一：两端的tcp-seq肯定会更新的 这样的话 迟到的老数据包只会被当成非法包丢弃掉
&&推论：上述第二个原因不成立 这样的话 只考虑原因1 TIME-WAIT设成10-20s都已经足够了
不知道各位怎么看待这个问题的？
IMAG0033.JPG (175 KB, 下载次数: 1)
22:11 上传
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbspTCP连接状态详解及TIME_WAIT过多的解决方法
[root@vps ~]#netstat -n|awk '/^tcp/{++S[$NF]}END{for (key in S) print key,S[key]}'
TIME_WAIT 286
FIN_WAIT1 5
FIN_WAIT2 6
ESTABLISHED 269
SYN_RECV 5
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。