三路握手后 TCP 窗口大小如何影响设置 SO_RCVBUF（使用 setsockopt）？

Posted 2023-02-22

【中文标题】三路握手后 TCP 窗口大小如何影响设置 SO_RCVBUF（使用 setsockopt）？

【英文标题】：How TCP window size is impacted on setting SO_RCVBUF (using setsockopt) after three way handshake?

【发布时间】：2013-07-26 05:00:47

【问题描述】：

我接受具有默认值的 TCP 连接，我观察到 SYN、ACK 以 64K 的窗口大小和 7 的窗口比例因子发送。

3 次握手完成并为我的应用交换一些控制数据包后，我使用 setsockopt() 将 SO_RCVBUF 设置为 20K。我的问题是，在这种情况下，广告窗口何时会更新？ 由于 sb_hiwat 已修改为较小的值，我不应该立即看到窗口更新数据包吗？我看到的是广告窗口逐渐减少，大约需要 4 秒才能从 ~7MB 达到 20K。

【参考方案1】：

我不知道你为什么要减少接收缓冲区。

一旦开始传输，您甚至可能无法做到这一点，但无论如何，如果接收缓冲区中有数据，您当然不能指望它立即设置为小于该值。否则数据将不得不被丢弃，而 TCP 不允许这样做。

我建议你别管它。

【讨论】：

EPJ，我同意减少接收缓冲区不是一个好主意，但我正在处理一个遗留设计，不理会它不是一个选择。我正在查看内核代码，所有 setsockopt() 所做的就是更改 sb_hiwat。我需要在 tcp 代码中挖掘更多内容，以找出在 sb_hiwat 更改后窗口没有立即缩小的原因。顺便说一句，我正在研究 FreeBsd 堆栈。

为什么？为什么传统对等方会关心 TCP 窗口大小是多少？为什么你不能在接受或连接之前设置你想要的，而根本不必改变它？我什么都不懂。

为什么的部分答案是统计数据。服务器端总是在默认的较大窗口上接受连接，尽管客户端在连接之前设置了选项。一旦三次握手完成并交换了一些会话级消息后，客户端发送会话层数据包以在服务器上为会话设置窗口大小。

刚刚意识到我在与您联系时输入了 EPJ 而不是 EJP，对此感到抱歉。