gpt4 book ai didi

tcp - 在更高流量的 ubuntu 12 nginx 服务器上忽略 SYN 数据包

转载 作者:可可西里 更新时间:2023-11-01 02:34:32 26 4
gpt4 key购买 nike

我有一个 ubuntu 12.04 服务器,nginx 在 80 端口

只有一条防火墙规则,涉及端口映射端口26到25

nginx 设置为监听端口 80,最初以相当默认的方式但现在以

listen x.x.x.x:80 backlog=5000;

nginx 没有那么加载,每秒大约 50 个请求说 nginx_status

Active connections: 480 
server accepts handled requests
84618 84618 143733
Reading: 0 Writing: 4 Waiting: 474

一些(极少数)用户提示他们的一台计算机(例如“它只发生在家里”)似乎忽略了它的 SYN 数据包。他们可以毫无损失地 ping 通。 有时他们会收到一些对 tcp 请求的响应。他们可以在安静的端口上获得响应,例如 pop 服务器。然而,一般来说,他们会经历长时间的超时。我有他们的数据包转储显示了这一点。

在我这边,我还可以看到一些 IP 地址被忽略了。

例如,从2010端口到80端口的多个SYN数据包没有得到回复,而服务器正在2031端口上完成先前的连接

02:21:46.950979 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:21:49.887320 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:21:55.923151 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:22:24.950448 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [S], seq 4138069869, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:22:24.950488 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [S.], seq 248034551, ack 4138069870, win 14480, options [mss 1460,sackOK,TS val 240617577 ecr 0,nop,wscale 7], length 0
02:22:24.982809 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 1, win 50112, options [nop,nop,TS val 372774 ecr 240617577], length 0
02:22:24.982852 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [P.], seq 1:526, ack 1, win 50112, options [nop,nop,TS val 372774 ecr 240617577], length 525
02:22:24.982869 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [.], ack 526, win 122, options [nop,nop,TS val 240617585 ecr 372774], length 0
02:22:25.016783 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [P.], seq 1:265, ack 526, win 122, options [nop,nop,TS val 240617594 ecr 372774], length 264
02:22:25.190570 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 265, win 50079, options [nop,nop,TS val 372777 ecr 240617594], length 0
02:22:45.017288 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [F.], seq 265, ack 526, win 122, options [nop,nop,TS val 240622594 ecr 372777], length 0
02:22:45.049437 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 266, win 50079, options [nop,nop,TS val 372976 ecr 240622594], length 0
02:22:49.998299 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [R.], seq 526, ack 266, win 0, length 0
02:23:18.883263 IP 72.38.0.37.2059 > 64.91.255.98.80: Flags [S], seq 2419025537, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:23:21.890861 IP 72.38.0.37.2059 > 64.91.255.98.80: Flags [S], seq 2419025537, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0

更简单地说,在 20 秒周期开始时,这是一个来自一个 IP 的单独数据包,它没有与任何其他数据包配对(到该主机):

2:48:05.141703 IP 96.48.197.237.1275 > 64.91.255.98.80: Flags [S], seq 2682822499, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0

我写了一个 perl 脚本来观察 tcpdump 并查找/报告悬空 SYN 的数量,它每隔几秒就会发现几个(随着我们的进行,从未回复的 TCP SYN 数据包的累积计数稳步上升)。明显未回复的 SYN 的比率约为 2500 分之一。当我 ping 这些 IP 时,假设它们是可 ping 通的,没有数据包丢失,与它们通信没有问题。

内核日志中没有任何有用的内容(例如“发送 syncookies”)。

nginx 有

worker_processes 8
worker_connections 4096

keepalive 已打开,open_file_cache 模块正在使用中,但我正在努力查看哪些其他变量可以默默地忽略 SYN 数据包,但仅针对特定 IP 且可重复。

除了默认的 ubuntu 设置,sysctl.conf 有

# increased
net.ipv4.tcp_fin_timeout = 10
net.ipv4.ip_local_port_range = 1024 65535
net.core.somaxconn = 1024
# default
net.ipv4.tcp_tw_reuse = 0
# default
net.netfilter.nf_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
# reduced
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.ipv4.tcp_ecn = 0

我以前没有遇到过这个问题,同样的观众,更早的内核 nginx,不同的硬件(这是一个虚拟服务器)。不同的数据中心。

我的“煤矿中的金丝雀”报告说,从他们的角度来看,他们看到了他们的 XP 机器上的超时和缺乏回复,但如果它通过 linux 机器设置作为代理,则不会。所以他们正在对此进行调查。但是,无论他们得出什么结论,我都不确定为什么我可以嗅探到端口 80 的传入 SYN 数据包,而没有在同一接口(interface)上发送后续回复数据包。

最佳答案

根据这里的信息

https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet

关闭服务器上的 TCP 时间戳可以阻止 Windows XP 客户端丢弃 SYN,这些客户端发送 SYN 数据包时将 tsval 设置为零,并且服务器上未回复的 SYN 数量变为零并保持不变。

sysctl -w net.ipv4.tcp_timestamps = 0

我的理解是,当启用时间戳时 XP 堆栈的行为是众所周知的,因为它已经在 linux 列表上讨论过与 ipv4 有关,并且在某个时间点启用 tcp_timestamps 的 linux 简单地切换到非时间戳 session XP(或其他有问题的客户端)。似乎这种行为已经改变,现在至少在繁忙的端口上,如果 tcp_timestamps 为 1,则 tsval 为 0 的 SYN 数据包将被丢弃

关于tcp - 在更高流量的 ubuntu 12 nginx 服务器上忽略 SYN 数据包,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17769790/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com