记一次因tcp_tw_recycle误设置为1导致服务器无法正常建立TCP连接的问题排查

最新推荐文章于 2024-07-23 20:12:34 发布
原创 最新推荐文章于 2024-07-23 20:12:34 发布 · 1.4k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#TCP #tcp_tw_recycle #服务器 #网络

本文记录了一次排查服务器接口响应超时问题的过程。从远端服务器、公司防火墙、公司服务器、容器到应用程序逐一排除，最终发现是由于`tcp_tw_recycle`参数设置不当导致。修改`/etc/sysctl.conf`文件中`net.ipv4.tcp_tw_recycle`的值为0后，问题得到解决。提醒开发者避免不必要的系统参数调整，特别是已被移除的参数，以免引发类似问题。

背景

为某SaaS平台的数据推送服务写的接口无法及时响应数据推送请求，导致频繁出现因请求超时而导致的数据推送失败，进而严重影响业务使用。接口部署在公司的阿里云上。
在这里插入图片描述

故障点梳理

最低0.47元/天 解锁文章
net.ipv4.tcp_tw_reuse = 1 重用time_wait
zhaoyangjian724的专栏
07-01 1498
net.ipv4.tcp_tw_reuse = 1 开启tcp_tw_reuse net.ipv4.ip_local_port_range = 50001 50001 node2:/root/test#python connect1.py response:15 node2:/root/test#python connect1.py response:15 node2:/root/test#python connect1.py response:15 node2:/root/test#pyth.
不要在linux上启用net.ipv4.tcp_tw_recycle参数
weixin_34358092的博客
03-20 2331
不要在linux上启用net.ipv4.tcp_tw_recycle参数发布于 2015/07/27莿鸟栖草堂本文为翻译英文BLOG《Coping with the TCP TIME-WAIT state on busy Linux servers》，但并非完整的翻译，译者CFC4N对原文理解后，进行了调整，增加了相关论点论据，跟原文稍有不同。翻译的目的，是为了...
【经验总结】tcp_tw_recycle参数引发的故障
热门推荐
【 无线技术运营 】 (本专栏是http://wireless.qzone.qq.com的镜像)
05-09 4万+
<br /><br />tcp_tw_recycle参数引发的故障<br />By Eric <br />故障描述：<br />　　　　2010年9月7日，新上线的手机游戏论坛有部分地区用户反应登陆游戏时出现不能登陆或登陆超时等情况，观察用户同时在线数量开始下降情况。<br /><br />排错过程：<br />　　　　一、初步检查是否有变更导致的故障：  <br />　　　　　　　　1、联系同事检查网络是否有问题或有对该机房网络是否有进行过调整，反回结果是没有变更操作。<br />　　　　　　　　2、检查
net.ipv4.tcp_tw_recycle 参数的影响
weixin_34352005的博客
06-23 320
2019独角兽企业重金招聘Python工程师标准>>> ...
记录一次net.ipv4.tcp_tw_recycl快速回收机制导致的tcp连接失败问题
weixin_54851134的博客
11-19 2083
记录一次net.ipv4.tcp_tw_recycl快速回收机制导致的tcp连接失败问题
net.ipv4.tcp_tw_recycle参数造成的连接不稳定
很青的青蛙专栏
03-17 6765
net.ipv4.tcp_tw_recycle参数造成的连接不稳定，NAT设备后面的用户上网，发出的TPC/IP时间戳不连续，造成服务端丢弃连接。 那该不该设置呢？ 我认为这样： 1. 如果是服务企业客户，或者是一个企业互联网就用，那就设置为0，企业客户投诉和抱怨影响是非常大的，只能其它方面来优化。 2. 如果是一个互联网普通用户使用的网站，设置为1，那也影响不大。
tcp_tw_recycle慎用，记一次故障引发的教训(lesson)
纵歌的博客
05-21 1336
tcp_tw_recycle慎用，记一次故障引发的教训
记一次现网k8s中pod连接数据库异常的问题分析及解决实践（tcp_tw_recycle与tcp_tw_reuse内核参数修改）
弱水提沧的博客
04-26 5153
在k8s环境中，node节点上的pod网络互联互通是采用网络插件结合etcd实现的。 默认情况下pod访问集群外部的网络走的是对应node节点的NAT规则。在这次连接中，由于在pod内连接数据库经过了一次NAT转换，客户端TCP请求到达数据库，修改目的地址（IP+端口号）后便转发给数据库服务器，而客户端时间戳数据没有变化。对于数据库来说，请求的源地址是node节点IP，所以在数据库看来，原先不同的客户端请求经过NAT的转发，会被认为是同一个连接，加上不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象。
Linux同时开启tcp_tw_recycle和tcp_timestamps导致TCP syn有时不响应故障排查
yscisco的博客
11-22 2176
问题描述 前几天，同事反馈从公司连接线上一台服务器有时候会失败，经过抓包发现，TCP握手过程失败。查了相关资料，发现是跟net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps两个参数有关，将net.ipv4.tcp_tw_recycle改为0，问题解决。 排查过程 在PC上通过wireshark抓包发现，失败的时候，TCP syn包是一直在重传的。在server端通过tcpdump抓包发现，PC侧发的syn包是已经到达，所以基本排除网络问题。tcpdump抓包中确实看
tcp_tw_recycle+tcp_timestamp+NAT问题
貓的博客
10-12 4951
在排查一个超时问题的时候，又再一次遇到了 tcp_tw_recycle 在遇到 NAT 的场景下，可能导致丢包的问题， 掉进同一个坑两次，因此做一次记录；特别是手抽改过系统tcp参数的应用，需要注意   现象 不同主机C1,C2上的相同模块（开启timestamp），通过NAT网关（1个出口ip）访问同一服务S，主机C1 connect成功，而主机C2 connect失败   故障模型 ...
TCP网络常见调优参数之一：tcp_tw_recycle
Jian Sun_的博客
07-23 1251
判断第二个包是重复报文，丢弃之反映出来的情况就是在云存储上抓包，发现有SYN包，但就是不回ACK包，因为SYN包已经被丢弃了。在一些高并发的 TCP Server上，为了能够快速回收time_wait的状态socket，打开了 tcp_tw_reccycle ，内核就会检查tcp包时间戳，但无法保证客户端是否NAT后面过来的请求，发来的包的时间戳是可能乱跳的，所以服务器端就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。
tcp_tw_recycle参数引发的故障
weixin_34221775的博客
05-12 202
tcp_tw_recycle参数引发的故障By Eric故障描述：　　　　2010年9月7日，新上线的手机游戏论坛有部分地区用户反应登陆游戏时出现不能登陆或登陆超时等情况，观察用户同时在线数量开始下降情况。排错过程：　　　　一、初步检查是否有变更导致的故障：　　　　　　　　1、联系同事检查网络是否有问题或有对该机房网络是否有进行过调整，反回结果是没有变更操作。　　　　　...
linux net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle设置多大比较合适
Emerson的博客
08-07 3023
对于这两个参数的设置，建议在进行更改之前先进行测试，并根据实际情况和性能监控结果进行调整。另外，还应该注意遵守操作系统和网络设备的最佳实践，并确保系统的网络配置和性能监控是合理的。但需要注意，如果网络环境不稳定，或者应用程序依赖于唯一的本地端口绑定，可能会导致连接的混乱或错误。然而，需要注意的是，快速回收机制对于某些网络环境可能不适用，因此在启用之前需要进行测试和评估。：该参数启用了快速回收（Fast Recovery）机制，用于加速TIME_WAIT状态连接的回收。默认情况下，该参数的值为0。
应用连接数据库偶发性连接拒绝——Linux内核参数net.ipv4.tcp_tw_recycle 导致的异常记录
djp304的博客
01-10 1535
新上线的应用连接数据库总是偶发性连接拒绝，开始以为是数据库连接池（使用的Druid）空闲连接配置有误导致，经调整后依然没有解决问题。 后偶然发现，使用Telnet 探测连接，也存在类似问题，后开始在调用链路各节点开始抓包，根据抓包结果，多方在网络上查看各位大神的帖子和咨询资深同事，终于确认问题原因并解决。现记录该问题如下，以便后续类似问题参考。（文章中的知识点来源于与网上各种资料，记录该文章为自己记录以及有相同问题的朋友多个思路，如有侵权，可联系删除） 先来说一下此次问题的系统调用链路：...
net.ipv4.tcp_tw_recycle 与 网络连接失败
new_shop的博客
10-11 1263
最近从公司内网使用线上应用，很多同事都反映时断时连的，抓包看不时会有连接失败的情况（奇怪的是总是卡住约11秒），但其实最终是会成功的，但由于客户端的超时都是10秒，所以表现出来的就是总是服务不可用，出了公司用4G之类的，就没有这个问题了。 在此之前为了解决HA服务器曾有大量TIME_WAIT的总是，我曾改过一些内核参数，不过在发现上述总是后，我都用注释或修改回原值的方式将改过的值恢复了，但总是依
/proc/sys/net/ipv4 目录下的配置调优看法
沧海一声笑的专栏
08-15 2074
參數設置
优化内核时的坑，切记不要启用net.ipv4.tcp_tw_recycle
weixin_33881753的博客
04-08 1325
1. tw_reuse，tw_recycle 必须在客户端和服务端timestamps 开启时才管用（默认打开）2. tw_reuse 只对客户端起作用，开启后客户端在1s内回收3. tw_recycle 对客户端和服务器同时起作用，开启后在 3.5*RTO 内回收，RTO 200ms~ 120s 具体时间视网络状况。内网状况比tw_reuse 稍快，公网尤其移动网络大多要比...
net.ipv4.tcp_tw_recycle配置问题
chengyi5512的博客
08-19 1339
本来这个是不想写的，理应当是一个运维的问题，结果发现近期又出现了这样的问题，有的机器配置了 net.ipv4.tcp_tw_recycle=1 ， 表示开启TCP连接中TIME-WAIT sockets的快速回收。 这种配置会导致一个问题，当服务是一个网关类的应用的时候且访问量很大的时候容易...
STDERR: sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file
最新发布
11-04
<think>嗯，用户遇到了一个关于Linux网络配置的具体错误：执行sysctl命令时提示找不到/proc/sys/net/ipv4/tcp_tw_recycle文件。结合之前的引用资料，这个问题显然和Linux内核的演化有关。 用户提供的三篇引用都指向同一个关键点：tcp_tw_recycle这个参数在现代Linux内核中已被废弃。特别是引用[3]明确提到它"已被废弃"，还举了NAT环境下问题的例子。看来用户可能是在老教程里看到这个参数配置建议，但实际在新系统上操作时发现路径不存在。 现在需要帮用户解决这个"文件不存在"的错误。本质上这不是真正的错误，而是功能废弃的体现。解决方案的核心应该是： 1. 明确告知用户该参数已从内核移除（从4.12版本开始） 2. 提供替代方案——比如开启tcp_tw_reuse（但要注意它只影响客户端端口） 3. 建议调整TIME_WAIT超时时间作为补充方案 4. 提醒用户NAT环境下的特殊注意事项 考虑到用户正在调试网络问题，还需要注意： - 避免让用户浪费时间寻找根本不存在的文件 - 解释清楚新旧方案的差异 - 区分客户端和服务端的优化场景 - 补充说明为什么这个参数会被废弃（时间戳回绕问题） 用户应该是个运维人员或开发者，对Linux有一定了解但可能没跟上内核变更。ta的提问很精准，直接给出了错误信息，说明已经做过基础排查。回复时需要保持技术严谨性，同时注意不要引入新混淆——比如要强调tcp_tw_reuse和原先tcp_tw_recycle的本质区别。 最后生成的相关问题要覆盖可能的延伸需求：如何验证当前内核参数？是否有其他优化手段？怎么确认TIME_WAIT状态连接数？这些都是实际调试中必然会遇到的后续问题。 </think>根据您的错误信息和引用内容，解决 `sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file` 的方法如下： ### 原因分析 1. **内核版本升级** `net.ipv4.tcp_tw_recycle` 参数在 Linux 内核 4.12 版本中**已被永久移除**（引用[3]）。若您的内核版本 ≥4.12，该参数对应的文件 `/proc/sys/net/ipv4/tcp_tw_recycle` 将不复存在。 2. **参数废弃原因** 该参数在 NAT 网络下会导致 TCP 连接建立错误（引用[1][3]），引发间歇性连接失败（如内网访问异常）。Linux 社区最终选择彻底废弃该参数以确保网络稳定性。 --- ### 解决方案 #### ✅ 推荐操作 1. **忽略该参数** 直接删除配置文件（如 `/etc/sysctl.conf`）中所有 `net.ipv4.tcp_tw_recycle = 1` 的配置项，无需替代方案。 2. **启用安全替代参数** 可改用 `net.ipv4.tcp_tw_reuse`（需同时开启时间戳）优化端口复用： ```bash # 检查时间戳是否开启（默认通常为1） cat /proc/sys/net/ipv4/tcp_timestamps # 启用 tcp_tw_reuse (仅影响客户端端口) echo 1 | sudo tee /proc/sys/net/ipv4/tcp_tw_reuse ``` > 📌 注意：`tcp_tw_reuse` 仅适用于**主动发起连接**的客户端（如 Web 服务器连接数据库），不影响服务端监听端口。 3. **调整 TIME_WAIT 超时** 减少 `net.ipv4.tcp_fin_timeout`（默认 60 秒）可加速连接释放： ```bash echo 30 | sudo tee /proc/sys/net/ipv4/tcp_fin_timeout ``` #### ⚠️ 错误操作 - **勿尝试恢复文件**：该参数在内核源码中已删除，手动创建文件无效。 - **勿降级内核**：为兼容旧参数降级内核会引入安全风险。 --- ### 验证步骤 1. **检查内核版本** ```bash uname -r # 若输出 ≥4.12，则参数已废弃 ``` 2. **清理配置文件** 删除 `/etc/sysctl.conf` 中 `net.ipv4.tcp_tw_recycle` 相关行，执行： ```bash sudo sysctl -p # 重新加载配置 ``` > 💡 **延伸建议**：对于高并发服务，可考虑： > - 增大端口范围 `net.ipv4.ip_local_port_range` > - 启用 `net.ipv4.tcp_max_tw_buckets` 限制 TIME_WAIT 总量 > - 使用 `SO_REUSEPORT` 套接字选项（需应用程序支持） --- ### 根本原因总结 | 参数 | 状态 | 风险 | 替代方案 | |---------------------|--------|-------------------------------|------------------------------| | `tcp_tw_recycle` | 已废弃 | NAT 环境 TCP 连接故障（引用[1][3]） | `tcp_tw_reuse` + `tcp_fin_timeout` | | `tcp_tw_reuse` | 可用 | 仅客户端有效 | 需配合 `tcp_timestamps=1` | ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值