tcp_timestamps tcp_tw_recycle引起的服务器连接不上问题

2024-03-16 01:18

本文主要是介绍tcp_timestamps tcp_tw_recycle引起的服务器连接不上问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

最近一个非常奇怪的问题,多台手机客户端利用公司wifi连接一台服务器,但是频繁出现连接不上情况,而且一台能连接上,另一台就会断开。断开的时候再尝试连接,但是没有apache跟tomcat的任何访问记录,但是3G连接不会出现这个问题。

最近发现一个PHP脚本时常出现连不上服务器的现象,调试了一下,发现是TIME_WAIT状态过多造成的,本文简要介绍一下解决问题的过程。

遇到这类问题,我习惯于先用strace命令跟踪了一下看看:

shell> strace php /path/to/file
EADDRNOTAVAIL (Cannot assign requested address)
从字面结果看似乎是网络资源相关问题。这里顺便介绍一点小技巧:在调试的时候一般是从后往前看strace命令的结果,这样更容易找到有价值的信息。

查看一下当前的网络连接情况,结果发现TIME_WAIT数非常大:

shell> netstat -nt | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'
TIME_WAIT 28233
重复了几次测试,结果每次出问题的时候,TIME_WAIT都等于28233,这真是一个魔法数字!实际原因很简单,它取决于一个内核参数net.ipv4.ip_local_port_range:

shell> sysctl -a | grep port
net.ipv4.ip_local_port_range = 32768 61000
因为端口范围是一个闭区间,所以实际可用的端口数量是:

shell> echo $((61000-32768+1))
28233
问题分析到这里基本就清晰了,解决方向也明确了,内容所限,这里就不说如何优化程序代码了,只是从系统方面来阐述如何解决问题,无非就是以下两个方面:

首先是增加本地可用端口数量。这点可以用以下命令来实现:

shell> echo "net.ipv4.ip_local_port_range = 10240 61000" >> /etc/sysctl.conf
shell> sysctl -p
其次是减少TIME_WAIT连接状态。网络上已经有不少相关的介绍,大多是建议:

shell> sysctl net.ipv4.tcp_tw_reuse=1
shell> sysctl net.ipv4.tcp_tw_recycle=1
注:通过sysctl命令修改内核参数,重启后会还原,要想持久化可以参考前面的方法。

这两个选项在降低TIME_WAIT数量方面可以说是立竿见影,不过如果你觉得问题已经完美搞定那就错了,实际上这样可能会引入一个更复杂的网络故障。

关于内核参数的详细介绍,可以参考官方文档。我们这里简要说明一下tcp_tw_recycle参数。它用来快速回收TIME_WAIT连接,不过如果在NAT环境下会引发问题。

RFC1323中有如下一段描述:

An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender’s timestamp clock. Such an extension is not part of the proposal of this RFC.

大概意思是说TCP有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。

Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle,因为tcp_timestamps缺省就是开启的,所以当tcp_tw_recycle被开启后,实际上这种行为就被激活了。

现在很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,以NAT方式构建,当请求到达LVS后,它修改地址数据后便转发给 后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上端口会复用,所以从后端服务器的角度看,原本不同客户端的请 求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的 表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,还可以通过下面命令来确认数据包不断被丢弃的现象:

shell> netstat -s | grep timestamp
... packets rejects in established connections because of timestamp
如果服务器身处NAT环境,安全起见,通常要禁止tcp_tw_recycle,至于TIME_WAIT连接过多的问题,可以通过激活tcp_tw_reuse来缓解。

进一步思考,既然必须同时激活tcp_timestamps和tcp_tw_recycle才会触发这种现象,那只要禁止 tcp_timestamps,同时激活tcp_tw_recycle,就可以既避免NAT丢包问题,又降低TIME_WAIT连接数量。如果服务器并不 依赖于RFC1323,那么这种方法应该也是可行的,不过最好多做测试,以防有其他的副作用。

shell> sysctl net.ipv4.tcp_timestamps=0
shell> sysctl net.ipv4.tcp_tw_recycle=1

总体来说,这次网络故障本身并没什么高深之处,本不想罗罗嗦嗦写这么多,不过拔出萝卜带出泥,在过程中牵扯的方方面面还是值得大家品味的,于是便有了这篇文字。

转自

http://huoding.com/2012/01/19/142

 

类似的:

tcp 内核参数对NAT 用户的影响

tcp_tw_recycle和tcp_timestamps导致connect失败问题

底层通讯协议问题排查案例

 

update 20120913

我遇到的问题,看过上边的四篇文章后我们就知道问题的原因了。

故障描述:

client (windows/linux) < -- > linux nat 服务器 < -- > web server(linux)

这里500 多台client 同过linux nat 服务器上网,一直运行正常,直到最近上有同事反应,linux client 用户无法访问某网站频道,而windows client用户则没有问题,真像上面说的一样人民问题吗?

 

故障解决:

echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle
sysctl -p
//tcp_tw_recycle默认是关闭的,有不少服务器,为了提高性能,开启了该选项

 

故障分析:

linux client 用户无法访问某网站频道,而其他网站这正常!问题在web server 上!

抓包
windows(xp)

tcpdump -vvn dst 211.x.x.x 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:49:05.600205 IP (tos 0x0, ttl 64, id 4280, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.4.157.1244 > 211.x.x.x.80: Flags [S], cksum 0x9f8d (correct), seq 4210943732, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
10:49:05.607071 IP (tos 0x0, ttl 64, id 4281, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.4.157.1244 > 211.x.x.x.80: Flags [.], cksum 0x2c80 (correct), seq 4210943733, ack 2368349854, win 64240, length 0
10:49:55.618477 IP (tos 0x0, ttl 64, id 4337, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.4.157.1244 > 211.x.x.x.80: Flags [.], cksum 0x2c7f (correct), seq 0, ack 214, win 64028, length 0
10:49:55.637271 IP (tos 0x0, ttl 64, id 4338, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.4.157.1244 > 211.x.x.x.80: Flags [F.], cksum 0x2c7e (correct), seq 0, ack 214, win 64028, length 0

linux(ub12.04)

tcpdump -i eth1 -vvn host 192.168.4.35 and  211.x.x.x 
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:57:08.197353 IP (tos 0x10, ttl  62, id 8687, offset 0, flags [DF], proto: TCP (6), length: 60)192.168.4.35.57699 > 211.x.x.x.http: S, cksum 0x78d4 (correct), 50589925:50589925(0) win 14600 <mss 1460,sackOK,timestamp 41668874 0,nop,wscale 7>
11:57:09.193852 IP (tos 0x10, ttl  62, id 8688, offset 0, flags [DF], proto: TCP (6), length: 60)192.168.4.35.57699 > 211.x.x.x.http: S, cksum 0x77da (correct), 50589925:50589925(0) win 14600 <mss 1460,sackOK,timestamp 41669124 0,nop,wscale 7>
11:57:11.197844 IP (tos 0x10, ttl  62, id 8689, offset 0, flags [DF], proto: TCP (6), length: 60)192.168.4.35.57699 > 211.x.x.x.http: S, cksum 0x75e5 (correct), 50589925:50589925(0) win 14600 <mss 1460,sackOK,timestamp 41669625 0,nop,wscale 7>
.....略
 

结论:windows 发出的tcp 包中没有timestamp,固能够完成tcp 的三次握手,而linux 发出的tcp 包中包含timestamp,webserver 拒绝发送syn/ack包,你能看到包的标志全部是S,所以不能完成tcp 的三次握手,也就不能访问web server 了。

 

这里简单解释下tcpdump 数据包意义

TCP包的输出信息
用TCPDUMP捕获的TCP包的一般输出信息是:
src > dst: flags data-seqno ack window urgent options
src > dst:表明从源地址到目的地址, flags是TCP包中的标志信息,S 是SYN标志, F (FIN), P (PUSH) , R (RST) "." (没有标记); 
data-seqno是数据包中的数据的顺序号, ack是下次期望的顺序号, window是接收缓存的窗口大小, 
urgent表明数据包中是否有紧急指针. Options是选项.

每一行中间都有这个包所携带的标志:
S=SYN,发起连接标志
P=PUSH,传送数据标志
F=FIN,关闭连接标志
ack    表示确认包
RST= RESET,异常关闭连接
. 表示没有任何标志
--------------------- 
作者:江湖邗孜 
来源:CSDN 
原文:https://blog.csdn.net/fanyun7654/article/details/20725783?utm_source=copy 
版权声明:本文为博主原创文章,转载请附上博文链接!

这篇关于tcp_timestamps tcp_tw_recycle引起的服务器连接不上问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/813859

相关文章

IntelliJ IDEA 中配置 Spring MVC 环境的详细步骤及问题解决

《IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决》:本文主要介绍IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决,本文分步骤结合实例给大... 目录步骤 1:创建 Maven Web 项目步骤 2:添加 Spring MVC 依赖1、保存后执行2、将新的依赖

Spring 中的循环引用问题解决方法

《Spring中的循环引用问题解决方法》:本文主要介绍Spring中的循环引用问题解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录什么是循环引用?循环依赖三级缓存解决循环依赖二级缓存三级缓存本章来聊聊Spring 中的循环引用问题该如何解决。这里聊

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

Go语言开发实现查询IP信息的MCP服务器

《Go语言开发实现查询IP信息的MCP服务器》随着MCP的快速普及和广泛应用,MCP服务器也层出不穷,本文将详细介绍如何在Go语言中使用go-mcp库来开发一个查询IP信息的MCP... 目录前言mcp-ip-geo 服务器目录结构说明查询 IP 信息功能实现工具实现工具管理查询单个 IP 信息工具的实现服

关于MongoDB图片URL存储异常问题以及解决

《关于MongoDB图片URL存储异常问题以及解决》:本文主要介绍关于MongoDB图片URL存储异常问题以及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐... 目录MongoDB图片URL存储异常问题项目场景问题描述原因分析解决方案预防措施js总结MongoDB图

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

解决Maven项目idea找不到本地仓库jar包问题以及使用mvn install:install-file

《解决Maven项目idea找不到本地仓库jar包问题以及使用mvninstall:install-file》:本文主要介绍解决Maven项目idea找不到本地仓库jar包问题以及使用mvnin... 目录Maven项目idea找不到本地仓库jar包以及使用mvn install:install-file基

usb接口驱动异常问题常用解决方案

《usb接口驱动异常问题常用解决方案》当遇到USB接口驱动异常时,可以通过多种方法来解决,其中主要就包括重装USB控制器、禁用USB选择性暂停设置、更新或安装新的主板驱动等... usb接口驱动异常怎么办,USB接口驱动异常是常见问题,通常由驱动损坏、系统更新冲突、硬件故障或电源管理设置导致。以下是常用解决

Mysql如何解决死锁问题

《Mysql如何解决死锁问题》:本文主要介绍Mysql如何解决死锁问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录【一】mysql中锁分类和加锁情况【1】按锁的粒度分类全局锁表级锁行级锁【2】按锁的模式分类【二】加锁方式的影响因素【三】Mysql的死锁情况【1

SpringBoot内嵌Tomcat临时目录问题及解决

《SpringBoot内嵌Tomcat临时目录问题及解决》:本文主要介绍SpringBoot内嵌Tomcat临时目录问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,... 目录SprinjavascriptgBoot内嵌Tomcat临时目录问题1.背景2.方案3.代码中配置t