关于Titm_Wait优化，必须要知道的……
发布时间：2022-06-21 14:43:17 所属栏目：系统 来源：互联网
导读：TIME-WAIT是服务器优化必然会谈到的一个话题，而我们常见的问题就是TIME-WAIT过多怎么处理? 常见的解决方法就是： 1、快速回收 2、链接复用 而这里有个误区就是到底TIME-WAIT要优化到什么程度，有的童鞋甚至看到TIME-WAIT就觉得需要优化，今天就是想聊一下这
|
TIME-WAIT是服务器优化必然会谈到的一个话题，而我们常见的问题就是TIME-WAIT过多怎么处理? 常见的解决方法就是： 1、快速回收 2、链接复用 而这里有个误区就是到底TIME-WAIT要优化到什么程度，有的童鞋甚至看到TIME-WAIT就觉得需要优化，今天就是想聊一下这个话题 要聊明白，还是要从原理来说起 解决什么问题呢?看下面两个场景 四次挥手中，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分段可以存在于互联网系统中的最大时间，由TCP实现，超出这个寿命的分段都会被丢弃，RFC 1122建议是2分钟，但在不同的unix实现上，这个值并不确定 尽管CentOS系统中，MSL可以通过修改参数tcp_fin_timeout来设置MSL的时间，默认是30s，这样的话，一个四元组(local_ip, local_port, remote_ip,remote_port)会被冻结60s的时间，系统默认可分配端口约30000个，可通一下文件查看过 复制 /proc/sys/net/ipv4/ip_local_port_range 1. 那么从同一个客户端发起请求，并发只能到500QPS左右 所以提出了快速回收的方法，即TCP连接状态在TIME_WAIT状态的时候，立即回收连接，不等待2MSL，以快速回收资源用于新的连接 而快速回收的弊端，相信都有了解，就是关于快速回收引发的SYN无法得到ACK的问题，具体如下： reuse的前提是收到最后一个包后超过1s，所以正常的情况下开启reuse是可以达到快速复用TIME_WAIT状态的socket链接的，而且也不会有像recycle那样的“副作用” 除了以上两种解决TIME_WAIT的方式，还有一个参数是必须要关注的，就是tw_buckets，可以通过 复制 cat /proc/sys/net/ipv4/tcp_max_tw_buckets 1. 查看该参数值，这个值是TIME_WAIT可以达到的最大数量，当TIME_WAIT存在的数量和tcp_max_tw_buckets相同时，会处于tw_buckets溢出状态，默认是4096 所以应该保持tw_buckets至少在local_port之上，虽然长时间大量TIME_WAIT会消耗一定的内存资源，但是对于现在的服务器，TIME_WAIT所占用的内存是可以容忍的 总结： 结合上面的分析，recycle在内核4.1以后就被弃用了，所以它并不是TIME_WAIT优化的最好方案，最好的方式就是通过reuse进行复用，复用的前提是开启tcp_timestamps，并且要关注tw_buckets溢出的情况，适当增加tw_buckets，以应对并发量  （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号