TCP接收窗口大小高于net.core.rmem_max

Question

TCP接收窗口大小高于net.core.rmem_max

linuxperformancetcpiperfcongestion-control

13

我正在通过10Gbit连接将两台服务器之间运行iperf测量。我试图将我观察到的最大窗口大小与系统配置参数进行关联。

特别地，我观察到最大窗口大小为3 MiB。然而，在系统文件中我找不到相应的值。

通过运行sysctl -a，我得到以下值：

net.ipv4.tcp_rmem = 4096        87380   6291456
net.core.rmem_max = 212992

第一个值告诉我们最大接收窗口大小为6 MiB。但是，TCP倾向于分配请求大小的两倍，因此最大接收窗口大小应该是3 MiB，正如我所测量的一样。来自man tcp:

请注意，TCP实际上会为setsockopt(2)调用中请求的缓冲区大小分配两倍的空间，因此succeeding 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中指定的窗口大小要大呢？

NB: 我还计算了带宽延迟乘积： window_size = Bandwidth x RTT，约为3 MiB（10 Gbps @ 2毫秒RTT），从而验证了我的流量捕获。

- Adama

2个回答

1

net.ipv4.tcp_rmem 优先于 net.core.rmem_max，根据https://serverfault.com/questions/734920/difference-between-net-core-rmem-max-and-net-ipv4-tcp-rmem：

看起来 TCP 设置将优先于常规最大设置。

但我同意你所说的，这似乎与 man tcp 中所写的相矛盾，而且我可以重现你的发现。也许文档有误？请查明并评论！

- nh2

2

我已经开始了一个悬赏，以找出“man tcp”是否真的有错。 - nh2

在@mvds的出色回答之后，我已经在这里报告了显然的手册页错误：https://bugzilla.kernel.org/show_bug.cgi?id=209327 - nh2

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mvds · Accepted Answer

快速搜索结果如下：

https://github.com/torvalds/linux/blob/4e5448a31d73d0e944b7adb9049438a09bc332cb/net/ipv4/tcp_output.c

在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)++;
    }
}

max_t函数比较参数并返回较大的值。所以在这里，较大的值优先。

另一个提到sysctl_rmem_max的参考是它被用于限制SO_RCVBUF的参数（在net/core/sock.c中）。

所有其他TCP代码仅涉及sysctl_tcp_rmem。

因此，不用深入了解代码，您可以得出结论：更大的net.ipv4.tcp_rmem将在除设置SO_RCVBUF（其检查可以使用SO_RCVBUFFORCE绕过）外的所有情况下覆盖net.core.rmem_max。