tcp_timestamps,tcp_tw_reuse,tcp_tw_recycle,tcp_fin

解决这类问题,方法很重要,最好的做法其实是阅读官方的RFC,源码,然后进行实际测试验证。

tcp_timestamps,tcp_tw_reuse,tcp_tw_recycle

几篇比较好的解释这三个参数的文章:

https://serverfault.com/questions/502305/linux-networking-port-exhaustion
http://perthcharles.github.io/2015/08/27/timestamp-intro/
http://perthcharles.github.io/2015/08/27/timestamp-NAT/
https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux

RFC: https://tools.ietf.org/html/rfc1323

其中描述的部分可以很容易的验证,还有几个问题没搞清楚。

  1. 既然是per-host,那么同一个client的多个连接的请求过来,也可能受到timestamps的影响,不只是隐藏在NAT后的多个client会有这个问题。

    测试:上面一篇文章中指出当开启timestamps时,处于last_ack状态的连接在收到syn请求后并不会返回rst,而是重发一次fin。
    测试条件:将ip_local_port_range范围设为只有一个port;开启tcp_tw_reuse

通过在断开telnet连接时设置IPtables规则模拟ack包丢失,可以看到当重新telnet时,client向server发了syn包,server回了ack,client又发了rst,并再次syn包,server这次发来了syn+ack包,由于有iptables规则,server收不到client回的ack包,因此发了多次syn+ack,当取消iptables规则后,server成功收到ack,连接建立完成。

规则:
iptables -A OUTPUT -p tcp --tcp-flags ALL ACK --source 127.0.0.1 --sport 10240 -j DROP



tcp_fin_timeout不是msl值。https://huoding.com/2016/09/05/542



学到的一些概念:
paws,rrt,rto

原文地址:http://blog.51cto.com/zxdlife/2293798

时间: 2024-10-13 23:35:30

tcp_timestamps,tcp_tw_reuse,tcp_tw_recycle,tcp_fin的相关文章

linux开启tcp_timestamps和tcp_tw_recycle引发的问题研究

环境:centos7.4 内核版本3.10 最近看内核参数tcp_tw_recycle(该参数在内核 4.12 之后被移除),它用于快速回收处理TIME_WAIT状态的socket.搜索该参数相关的资料,发现同时启用该参数和tcp_timestamps后有可能在NAT环境下导致客户端始连接失败,抓包表现为:客户端一直发送SYN报文,但服务端不响应.但这些文章中只给出了如何解决问题,并没有给出如何复现问题.特别怪异的是,服务端是被动关闭的,并不会进入TIME_WAIT状态,到底怎么产生的呢? 先使

TIME_WAIT与tcp_tw_reuse /tcp_tw_recycle, 开还是不开?

对于这个问题找到的一些资料, 仅供参考: ------------------------------------------------------ 关于TIME_WAIT数量太多.从上面的描述我们可以知道,TIME_WAIT是个很重要的状态,但是如果在大并发的短链接下,TIME_WAIT 就会太多,这也会消耗很多系统资源.只要搜一下,你就会发现,十有八九的处理方式都是教你设置两个参数,一个叫tcp_tw_reuse,另一个叫tcp_tw_recycle的参数,这两个参数默认值都是被关闭的,后

tcp_tw_recycle和tcp_timestamps的文章汇总

临近年关,人会变得浮躁,期间写的代码可谓乱七八糟.不过出来混始终是要还的,这不最近就发现一个PHP脚本时常连不上服务器. 遇到这类问题,我习惯于先用strace命令跟踪了一下看看: shell> strace php /path/to/file EADDRNOTAVAIL (Cannot assign requested address) 从字面结果看似乎是网络资源相关问题.这里顺便介绍一点小技巧:在调试的时候一般是从后往前看strace命令的结果,这样更容易找到有价值的信息. 查看一下当前的网

一场由tcp_timestamps 引发的无解追击案

案例描述:我们的合作客户(国内知名电子支付企业)反应有四台机器调用我们的接口服务,但是奇怪的是四台中有两台是通的,有两台是不通的,不通的机器也是偶尔通偶尔不通,这个问题一直断断续续困扰了他们很久,刚开始我们认为是他们系统那里参数配置不对,就没有给予太多关注,毕竟我们还有好多合作客户,却没有问题:这个问题直到有一天,他们实在扛不住,实在找不出原因了,要求我们技术人员现场去帮他们排查,才开始了一场无解破解案. 那天接手了这个问题后,开始一对一让对方网络技术人员配合联合排查,分别从正常机器,不正常机器

记一次由tcp_tw_recycle参数引发的血案

一,故障描述: 从昨天开始,在值班群中陆续值班人员反映系统后台存在卡顿问题,如下图:而且在卡顿的同时登陆服务器也会卡好久.此现象只在一台服务器有出现. 二,故障分析: 1,登陆服务器查看资源使用top,vmstat等命令查看了一番发现服务器各项指标都没有异常.于是将问题转向了网络层.2,客户端端值班人员反映只有在访问系统后台的时候才会出现卡顿,访问其他网站正常.3,本地使用ping服务器外网ip正常返回,无丢包,延迟也正常.4,使用http-ping工具时,问题出现了,会经常性的出现连接失败:(

TIME-WAIT和CLOSE-WAIT

系统调优,你所不知道的TIME_WAIT和CLOSE_WAIT 2016-03-11 运维帮 来源微信订阅号:大房说 作者:大房 你遇到过TIME_WAIT的问题吗?   我相信很多都遇到过这个问题.一旦有用户在喊:网络变慢了.第一件事情就是,netstat -a | grep TIME_WAIT | wc -l 一下,哎呀妈呀,几千个TIME_WAIT. 然后,做的第一件事情就是:打开Google或者Bing,输入关键词:too many time wait.一定能找到解决方案,而排在最前面或

高性能网络 | 你所不知道的TIME_WAIT和CLOSE_WAIT

你遇到过TIME_WAIT的问题吗?   我相信很多都遇到过这个问题.一旦有用户在喊:网络变慢了.第一件事情就是,netstat -a | grep TIME_WAIT | wc -l 一下.哎呀妈呀,几千个TIME_WAIT. 然后,做的第一件事情就是:打开Google或者Bing,输入关键词:too many time wait.一定能找到解决方案,而排在最前面或者被很多人到处转载的解决方案一定是: 打开 sysctl.conf 文件,修改以下几个参数: net.ipv4.tcp_tw_re

减少TIME_WAIT连接状态

减少TIME_WAIT连接状态.网络上已经有不少相关的介绍,大多是建议: shell> sysctl net.ipv4.tcp_tw_reuse=1 shell> sysctl net.ipv4.tcp_tw_recycle=1 注:通过sysctl命令修改内核参数,重启后会还原,要想持久化可以参考前面的方法. 这两个选项在降低TIME_WAIT数量方面可以说是立竿见影,不过如果你觉得问题已经完美搞定那就错了,实际上这样可能会引入一个更复杂的网络故障. 关于内核参数的详细介绍,可以参考官方文档

TIME_WAIT 优化注意事项

不同时开启tcp_timestamps和tcp_tw_recycle的场景描述 FULL NAT下 FULL NAT  在client请求VIP 时,不仅替换了package 的dst ip,还替换了package的 src ip:但VIP 返回给client时也替换了src ip lvs后端为web服务器. 假如web服务器开启了tcp的tcp_timestamps和tcp_tw_recycle这两个参数.那么存在下面这种情况 RFC1323中有如下一段描述: An additional me