Linux 慢启动:更改 ip 路由对初始窗口没有任何影响

Qui*_*Par 10 networking linux optimization tcp tcp-slow-start

我将机器中的tcp初始窗口更改为10,如下所示

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 
Run Code Online (Sandbox Code Playgroud)

并更改tcp_slow_start_after_idle为如下所示

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0
Run Code Online (Sandbox Code Playgroud)

下面给出了一个 ip 路由显示确认

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19
Run Code Online (Sandbox Code Playgroud)

现在,当我在网站上执行 tcpdump 时,我似乎没有看到初始窗口中的更改,WIN/MSS 仍为默认值45840/1460=4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0
Run Code Online (Sandbox Code Playgroud)

我对网页所做的卷曲命中请求了大约30 KB的数据。

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k
Run Code Online (Sandbox Code Playgroud)

我的方法可能有什么问题?

核心

[user~]$ uname -r
3.0.4x86_64-linode21
Run Code Online (Sandbox Code Playgroud)

作为更新,这是我尝试google.com时的结果

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0
Run Code Online (Sandbox Code Playgroud)

如您所见,在这种情况下,WIN/MSS 为 14600/1460=10

我尝试通过 curl 从服务器机器本身访问我的站点,结果如下:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0
Run Code Online (Sandbox Code Playgroud)

在这种情况下,WIN/MSS 为 32792/16396=2

Sam*_*ron 9

我认为您误解了 TCP 的工作原理。

发送的每个数据包将始终通告一个接收器窗口(又名 RWIN)和一个可选的缩放因子,请参阅RFC 1323

未经确认,发送方不得发送超过RWIN 中指定的数据量。根据拥塞窗口,发送方可以决定是否填充 RWIN。

因此,TCP 数据包中有两位公开的信息。服务器上的 RWIN 和客户端上的 RWIN。这两个数字都规定了两端的拥塞窗口的最大大小。

当我们尝试优化文件上传的性能时,服务器上的 RWIN 很有趣。

当我们试图确定下载速度时,客户端上的 RWIN 很有趣。

这些数字都没有公开另一端的拥塞窗口

因此,如果我的 RWIN 为 64k,则服务器上的拥塞窗口可以是低于 64k 的任何数字。

确定实际拥塞窗口的唯一方法是对数据包进行计数。

如果我知道:

  1. 我的往返时间 (RTT) 约为 200 毫秒。
  2. 我刚刚请求了一个 100k 的资源。
  3. 我的 RWIN 为 64k。

如果我在大约 200 毫秒内从服务器收到 2 个长度为 1452 字节的数据包,则服务器上的拥塞窗口可能小于 4356,因为如果它更大,则会发送 3 个数据包。如果 IW 设置为 10,我会在 200 毫秒标记附近看到 10 个数据包的突发。

如果您更改了 IW 并希望确认更改有效,您需要对数据包进行计数以估计服务器上的拥塞窗口大小。

请记住,您可能希望在 SYN、SYN-ACK、ACK 之后直接查看对话,以确保您没有查看对话的中间(拥塞窗口可能已经增长)。


Man*_*iur 7

窗口大小将是较小的:服务器初始化窗口大小或客户端 RWIN。由于 5840 是 Linux 2.6 的默认 RWIN,因此您的客户端似乎是这里的限制因素。

从 Windows 框中尝试。Windows XP 的 RWIN 为 64k,较新的版本为 8k。

来源:http : //www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/(有趣的部分在视频下方)

编辑:扩展答案以使其更清楚:

  • 在 TCP 握手中,客户端向服务器发送一个 SYN 数据包,发送其最大允许的窗口大小。(如您的 tcpdump 输出所示,这些是 5840 字节)
  • 服务器现在响应 SYN ACK 和它想要同意的窗口大小。这个窗口大小只能比客户建议的小,不能大。无论服务器如何配置,它的窗口大小都不能超过该客户端的 5840 字节。
  • 客户端返回 ACK,然后他们愉快地交换数据。

Edit2:添加到问题中的 tcpdumps 显示服务器打开与 google 的连接,并且它本身充当客户端。