Ada*_*ama 8 linux performance tcp congestion-control iperf
我iperf在两台服务器之间运行测量,通过10Gbit链路连接.我试图将我观察到的最大窗口大小与系统配置参数相关联.
特别是,我观察到最大窗口大小为3 MiB.但是,我在系统文件中找不到相应的值.
通过运行sysctl -a我得到以下值:
net.ipv4.tcp_rmem = 4096 87380 6291456
net.core.rmem_max = 212992
Run Code Online (Sandbox Code Playgroud)
第一个值告诉我们最大接收器窗口大小为6 MiB.但是,TCP倾向于分配两倍的请求大小,因此最大接收器窗口大小应为3 MiB,正如我测量的那样.来自man tcp:
请注意,TCP实际上分配的次数是setsockopt(2)调用中请求的缓冲区大小的两倍,因此后续的getsockopt(2)调用将不会返回与setsockopt(2)调用中请求的缓冲区大小相同的缓冲区.TCP使用额外空间用于管理目的和内部内核结构,并且/ proc文件值反映了与实际TCP窗口相比更大的大小.
但是,第二个值net.core.rmem_max表示最大接收器窗口大小不能超过208 KiB.根据以下情况,这应该是硬限制man tcp:
tcp_rmem max:每个TCP套接字使用的接收缓冲区的最大大小.该值不会覆盖全局值
net.core.rmem_max.这不用于限制在套接字上使用SO_RCVBUF声明的接收缓冲区的大小.
那么,为什么我会观察到最大窗口大小大于指定的窗口大小net.core.rmem_max?
注意:我还计算了带宽 - 延迟产品:window_size = Bandwidth x RTT大约3 MiB(10 Gbps @ 2毫秒RTT),从而验证我的流量捕获.
mvd*_*vds 10
出现了快速搜索:
在 void tcp_select_initial_window()
if (wscale_ok) {
/* Set window scaling on max possible window
* See RFC1323 for an explanation of the limit to 14
*/
space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max);
space = min_t(u32, space, *window_clamp);
while (space > 65535 && (*rcv_wscale) < 14) {
space >>= 1;
(*rcv_wscale)++;
}
}
Run Code Online (Sandbox Code Playgroud)
max_t获取参数的较高值.所以更大的价值优先于此.
另一个引用sysctl_rmem_max是在用于将参数限制为SO_RCVBUF(在net/core/sock.c中)的地方.
所有其他tcp代码仅指sysctl_tcp_rmem.
因此,如果不深入研究代码,您可以得出结论,除了设置(可以绕过其检查)之外,所有情况下net.ipv4.tcp_rmem都会覆盖更大的代码.net.core.rmem_maxSO_RCVBUFSO_RCVBUFFORCE
net.ipv4.tcp_rmemnet.core.rmem_max根据https://serverfault.com/questions/734920/difference- Between -net-core-rmem-max-and-net-ipv4-tcp-rmem 优先:
看来 tcp 设置将优先于常见的最大设置
但我同意你的说法,这似乎与 中所写的内容相冲突man tcp,我可以重现你的发现。也许文档是错误的?请了解并评论!
| 归档时间: |
|
| 查看次数: |
4682 次 |
| 最近记录: |