linux内核协议栈TCP time_wait原理、配置、副作用
0. 手把手教你做中间件、高性能服务器、分布式存储技术交流群
手把手教你做中间件、高性能服务器、分布式存储等(redis、memcache、nginx、大容量redis pika、rocksdb、mongodb、wiredtiger存储引擎、高性能代理中间件),git地址如下:
git地址:https://github.com/y123456yz/middleware_development_learning
1. time_wait状态产生条件
只有在正常四次挥手关闭连接的情况下,在主动关闭连接的一方会出现一段时间的time_wait。如果启用了快速回收功能,回收时间和网络延迟状况有关,正常情况下小于1s,如果没有开启time_wait快速回收功能,则time_wait回收时间默认60s。
三次挥手过程(FIN+ACK, FIN+ACK,ACK)的情况,例如杀掉一段进程,第一个发送FIN+ACK的一端也会产生time_wait。
2. Time_wait状态相关参数说明
TCP中有和time_wait状态相关的参数有以下四个:
tcp_tw_recycle | 表示开启TCP连接中time_wait的快速回收功能,默认为0,表示关闭;生效前提是必须启用本端和对端tcp_timestamps配置。 |
tcp_timestamps | 时间戳选项,只有在该选项置1的时候tcp_tw_recycle才会生效。 |
tcp_max_tw_buckets | 表示系统同时保持time_wait的最大数量,如果超过这个量,time_wait将打印警告信息。超限的时候后面产生的time_wait直接不处理,释放资源。注意:是新的连接直接释放资源,老的连接还是处于time_wait状态。 |
Tcp_tw_reuse | 客户端大量time_wait状态存在时,端口被占用,当有新的连接,如果没有可用端口,则会连接失败。启用该功能后,可以复用time_wait状态的连接。客户端tcp_tw_reuse生效前提是启用本端和对端tcp_timestamp。
Tcp_tw_reuse端口重用功能一般只针对客户端,因为服务端一般都是监听固定端口,端口数是固定的,端口不会用完。而客户端每次连接端口一般都是由协议栈自动分配。 |
3. Time_wait快速回收
3.1 快速回收功能失效前提
Time_wait快速回收功能生效前提:启用tcp_tw_recycle,并启动本端和对端tcp_timestamps配置。启用timestamps功能时,报文中会携带时间戳选项信息,抓包如下:
3.2 启用time_wait快速回收功能副作用
如果启用了tcp_tw_recycle和tcp_timestamps,如果接收报文四层选项字段带有时间戳信息,则会对时间戳进行检查,对不满足条件的包会直接丢弃,可能会造成客户端连接建立不成功。例如网络路由信息反复变化,移动cmwap网络发来的包的时间戳乱跳,同一局域网通过路由器做NAT访问服务器(因为做NAT后,源IP就变为路由器的IP了,如果局域网内各个电脑系统时间不一致,则会出现)等情况有可能会出现部分连接异常。原因是tcp_tw_recycle/tcp_timestamps以及对端tcp_timestamps都开启的条件下,60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。不同主机经过路由器做NAT后,报文的源IP地址就变为路由器的IP地址了。
3.3内核协议栈相关主要源码
Time_wait状态生成及快速回收相关代码:
开启timestamps引起的丢包相关源码如下:
4. 客户端端口重用
4.1 客户端大量time_wait,端口重用前提
启用tcp_tw_reuse,并启动本端和对端tcp_timestamps配置。
4.2 内核协议栈相关主要源码
5. 大量timewait对客户端、服务端影响
5.1 客户端大量time_wait影响
- 大量time_wait会造成连接资源不释放,内存无法回收。
- 由于客户端端口一般采用协议栈随机分配的方式,协议栈会给每个客户端连接分配一个未使用的端口,因此如果客户端同一IP对应的time_wait数量超过ip_local_port_range设置的最大值(也就是65000),端口将被用完,连接会无法建立。
5.2 服务端大量time_wait影响
由于服务端只占用监听端口,因此不存在端口用完的现象。服务端大量time_wait唯一影响是:资源不释放,内存无法回收。
6. 测试验证
本次测试结果采用sysbench.short来压测cobar来验证,客户端物理设备和服务端物理设备的ip_local_port_range(1024~65000)和tcp_max_tw_buckets(81920)参数都是默认值,测试结果如下:
- 当cobar服务端time_wait数达到81920的时候,任然可以继续接收客户端连接,能够正常提供连接服务。
- 当客户端测试工具sysbench.short服务器上的time_wait数达到60000多的时候,客户端连接失败,无法连接,因为端口用完。打印:Cannot assign requested address; Cobar服务器time_wait超限时打印:
Cobar服务器time_wait超限的情况下,客户端sysbench压测结果基本不受影响,如下:
从上面测试可以看出,服务端time_wait不会影响客户端建链,只是占用内存。如果是客户端出现大量time_wait状态,此时端口用完,则无法建立连接。以上测试结论符合理论、代码分析。
7. 三种解决time_wait方法总结
| Time_wait快速回收 | 端口重用 | 限制Tcp_max_tw_buckets |
配置方法 | 在需要进行time_wait快速回收的一端进行一下配置: tcp_tw_recycle:1 本端tcp_timestamps:1 对端tcp_timestamps:1 | 在需要进行time_wait快速回收的一端进行一下配置: tcp_tw_reuse:1 本端tcp_timestamps:1 对端tcp_timestamps:1 | 配置Tcp_max_tw_buckets 的值在60000以下。例如配置为30000 |
副作用 | 在某些情况下可能引起用户建连接失败(例如需要直接返回给用户信息的服务器) 比较暴力,不符合TCP协议规范 | 在某些情况下可能引起用户建连接失败(例如需要直接返回给用户信息的服务器) 部署复杂,需要同时改服务端,而服务端比较多。 服务器时间戳会带出IDC,经过中间各种网络设备,尤其是运营商的无线设备等,如果某个设备对时戳有校验,则会产生丢包问题。 | 比较暴力,不符合TCP协议规范 应急的处理,立竿见影。 建议这种。 |

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Redis从入门到放弃系列(三) List
Redis从入门到放弃系列(三) List 本文例子基于:5.0.4 List是Redis中一种比较常见的数据结构,其实现为quicklist,quicklist是一个ziplist的双向链表 Redis从入门到放弃系列(一) String Redis从入门到放弃系列(二) Hash 首先让我们来看一下该如何在redis里面使用List类型 //设置key的列表为value lpush key value [value...] 代码示例: //栈的用法,rpush rpop一样~ 通过rpush,lpop相当于堆的用法 > lpush books java python c (integer) 3 > lpop books "c" > lpop books "python" > lpop books "java" ---------------------------------- //返回列表key指定区间的元素,区间偏移量start跟stop指定 //start跟stop的下表都是以0为底 > lrange books ...
- 下一篇
GIL 已经被杀死了么?
本文原创并首发于公众号【Python猫】,未经授权,请勿转载。 原文地址:https://mp.weixin.qq.com/s/8KvQemz0SWq2hw-2aBPv2Q 花下猫语: Python 中最广为人诟病的一点,大概就是它的 GIL 了。由于 GIL 的存在,Python 无法实现真正的多线程编程,因此很多人都把这视作 Python 最大的软肋。 PEP-554 提出后(2017年9月),大伙似乎看到了一线改善的曙光。然而,GIL 真的可以被彻底杀死么,如果可以的话,它会怎么实现呢,为什么等了一年多还没实现,仍需要我们等待多长时间呢? 英文 | Has the Python GIL been slain?【1】 作者 | Anthony Shaw 译者 | 豌豆花下猫 声明 :本文获得原作者授权翻译,转载请保留原文出处,请勿用于商业或非法用途。 2003 年初,Intel 公司推出了全新的奔腾 4 “HT” 处理器,该处理器的主频(译注:CPU 内核工作的时钟频率)为 3 GHz,采用了“超线程”技术。 在接下来的几年中,Intel 和 AMD 激烈竞争,通过提高总线速度、L...
相关文章
文章评论
共有0条评论来说两句吧...