各位老铁们，大家好，今天由我来为大家分享彻底掌握 Titm_Wait 优化技巧！，以及的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
[[404167]]
大家好，大家好，今天我要讲的话题是关于TCP的TIME-WAIT状态。
TIME-WAIT是服务器优化中必须讨论的一个话题，而我们常见的问题是如何处理太多的TIME-WAIT？
常见的解决方案有：
1. 快速回收
2. 链接复用
这里对于TIME-WAIT应该优化到什么程度存在一个误解。有的孩子甚至看到TIME-WAIT就觉得需要优化。今天我只想谈谈这个话题。
要理解，我们必须从原理开始
TIME-WAIT是TCP链接的一种状态。之前写过一篇文章介绍TCP的11种链路状态。如果您有兴趣，可以再读一遍。
这张图展示了整个状态转换过程，分为三个部分。上半部分是建立连接的过程，下半部分分为主动关闭和被动关闭过程。
可以看到TIME_WAIT只出现在主动关闭过程中。其实TIME_WAIT是TCP为了解决复杂网络问题而提出的一种方案。
正在解决什么问题？看下面两个场景
四次挥手中，A发送FIN，B响应ACK，B再次发送FIN，A响应ACK关闭连接。而如果A响应的ACK包丢失，B会认为A还没有收到它的关闭请求，然后会再次重试向A发送FIN包。如果没有TIME_WAIT状态，A将不再保存连接信息，如果收到不存在连接的数据包，A会回复RST数据包，导致B响应异常。
此时TIME_WAIT是为了保证全双工TCP连接正常终止。
我们也知道TCP下的IP层协议无法保证数据包传输的顺序。如果双方挥手后，回收了一个网络四元组（src/dst ip/port），而此时网络中有一个迟到的数据包还没有被B收到，A应用立即使用同一个四元组。新连接创建后，迟到的数据包到达B。那么这个数据包会让B认为是A刚刚发送的。此时TIME_WAIT的存在是为了保证网络中丢失的数据包正常过期。
第一种场景，TIME_WAIT是为了保证被动关闭方收到ACK后，连接正常关闭，并且下次连接不受被动关闭方重传FIN的影响。
第二种场景，TIME_WAIT保留2个MSL，保证数据不会丢失
注：MSL（Maximum Segment Lifetime）是最大报文段寿命，表示TCP报文段可以在Internet系统中存在的最长时间。它是通过TCP实现的。超过此寿命的段将被丢弃。 RFC 1122 建议2 分钟。但在不同的unix实现上，这个值是不确定的
由于以上两种场景，TCP引入了TIME_WAIT状态来解决。可见，以TIME_WAIT完全存在或者消除TIME_WAIT作为优化目标是不合理的。
那么具体如何优化TIME_WAIT，什么样的状态才是合理的状态呢？
我们来看看两种常用的优化方法。首先我们来说说不推荐的：快速回收。
从上面可以看出，TIME_WAIT的持续时间为2MSL。按照RFC建议的2分钟，实际是4分钟。对于高并发服务器来说，local_port本身是有固定数量的。如果回收TIME_WAIT需要4分钟，那么端口很快就会被耗尽
虽然在CentOS系统中，MSL可以通过修改参数tcp_fin_timeout来设置MSL时间，默认是30s。在这种情况下，一个四元组（local_ip，local_port，remote_ip，remote_port）将被冻结60s。系统默认可以分配的端口大约有3万个，可以通过文件查看
/proc/sys/net/ipv4/ip_local_port_range 那么当同一个客户端发起请求时，并发只能是500QPS左右。
因此，提出了一种快速回收方法，即当TCP连接状态处于TIME_WAIT状态时，立即回收该连接，无需等待2MSL，为新连接快速回收资源。
相信大家都知道快速回收的缺点，就是快速回收导致的SYN无法得到ACK的问题。详情如下：
TCP 具有缓存每个连接的最新时间戳的行为。如果后续请求中的时间戳小于缓存的时间戳，则认为无效，相应的数据包将被丢弃。 Linux是否启用该行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps默认是启用的，所以当tcp_tw_recycle启用时，实际上就激活了该行为。在NAT环境下，时间戳可能会混乱，后续的数据包会被丢弃。具体表现通常是客户端明明发送了SYN，但服务器却没有回应ACK。由于NAT设备将数据包的源IP地址更改为一个地址（或少量IP地址），但基本上不修改TCP数据包的时间戳，因此会导致时间戳混乱。
建议：如果前端部署了三/四层NAT设备，尽量关闭快速回收，避免NAT后面的真机时间戳混乱导致SYN拒绝问题。
另一种优化方式是推荐方式：复用
从上面的分析可以看出，并发度无法提升是因为四元组被冻结了2MSL，导致没有新的资源可用，并且在冻结时间内四元组无法使用，因此提出了复用的方法。但复用是有前提条件的。需要同时开启tcp_timestamps。看一下关于这部分的内核代码。
复用的前提是收到最后一个数据包后需要1s以上的时间，所以一般情况下，开启复用可以快速复用处于TIME_WAIT状态的socket链接，并且不会出现recycle之类的“副作用”。
除了以上两种方式解决TIME_WAIT之外，还有一个参数必须注意，就是tw_buckets，可以通过
cat /proc/sys/net/ipv4/tcp_max_tw_buckets 查看参数值。该值是TIME_WAIT可以达到的最大数量。当TIME_WAIT的数量与tcp_max_tw_buckets相同时，就会处于tw_buckets溢出状态。默认为4096
当放弃重用时，在高并发服务器上，TIME_WAIT不会很快被回收，而是会重用之前的链接。这种情况下TIME_WAIT必然会维持一定的数量，那么tw_buckets就非常关键了。如果根据local_port在3w左右，那么如果tw_buckets默认是4096，TIME_WAIT很快就会达到瓶颈，无法再增加。
因此，tw_buckets 至少应保持在local_port 之上。虽然长时间大量的TIME_WAIT会消耗一定的内存资源，但对于目前的服务器来说，TIME_WAIT占用的内存是可以忍受的。
总结：
根据上面的分析，recycle在内核4.1之后就被弃用了，所以它不是TIME_WAIT优化的最佳解决方案。最好的办法就是通过重用来重用。复用的前提是开启tcp_timestamps，并注意tw_buckets的溢出，适当增大tw_buckets来应对并发量。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7991.html
用户评论
TITM_WAIT 这个优化我之前听别人提过，感觉很重要啊！
有15位网友表示赞同！
一直以来都没太明白 TITM_WAIT是什么，这篇文章来科普一下就太好了！
有6位网友表示赞同！
看标题感觉可以学习到很多关于数据库优化的知识，期待赶紧去看文章！
有9位网友表示赞同！
做DBA 的 肯定要关注这些优化技巧啊，提高性能很重要!
有10位网友表示赞同！
51CTO 文章质量很高，这篇文章肯定很专业很详细。
有17位网友表示赞同！
希望能多分享一些关于TITM_WAIT的实际案例，更能理解和应用。
有20位网友表示赞同！
最近遇到数据库性能瓶颈，这个优化应该可以尝试一下!
有7位网友表示赞同！
感觉数据库优化是一个很难掌握的技术，需要不断的学习积累。
有12位网友表示赞同！
我平时很少关注数据库优化，但以后也要重视起来，提高自身的专业技能！
有9位网友表示赞同！
这篇文章应该是很详细的介绍了，包括原理和操作方法吧？
有6位网友表示赞同！
对于 DBA 的来说，这个标题简直是太棒了！学习起来才不是问题!
有18位网友表示赞同！
TITM_WAIT优化能提升多大的性能呢？期待文章给出答案！
有12位网友表示赞同！
很多数据库知识我都不熟悉，希望这篇文章能给我带来一些新的启发。
有15位网友表示赞同！
TITM_WAIT 的英文缩写是什么？有人知道吗？
有14位网友表示赞同！
学习新知识总是一件很乐趣的事情，期待沉浸在这篇文章中！
有6位网友表示赞同！
这个文章标题很有吸引力，忍不住想去阅读一下!
有7位网友表示赞同！
数据库优化是一个很重要的课题，这篇文章应该能提供很多有价值的见解！ <
有14位网友表示赞同！
TITM_WAIT 和其他的数据库优化方法相比有什么优劣势？期待了解更多！
有10位网友表示赞同！