c++ - 增加 TCP 窗口大小

Question

我对在应用程序中增加 TCP 窗口大小有一些疑问。在我的 C++ 软件应用程序中，我们使用 TCP/IP 阻塞套接字从客户端向服务器发送大小约为 1k 的数据包。最近我遇到了这个概念 TCP Window Size。所以我尝试使用 和setsockopt()将值增加到 64K 。增加此值后，WAN 连接的性能得到了一些改进，但 LAN 连接没有。SO_SNDBUFSO_RCVBUF

根据我对 TCP Window Size 的理解，

客户端将数据包发送到服务器。达到此 TCP 窗口大小后，它将等待确保从服务器接收到窗口大小中第一个数据包的 ACK。在 WAN 连接的情况下，由于 RTT 中大约 100 毫秒的延迟，ACK 会从服务器延迟到客户端。因此在这种情况下，增加 TCP 窗口大小可以补偿 ACK 等待时间，从而提高性能。

我想了解我的应用程序的性能如何提高。

在我的应用程序中，即使setsockopt在套接字级别使用 TCP 窗口大小（发送和接收缓冲区）增加了，我们仍然保持 1k 的相同数据包大小（即，我们在单个套接字发送中从客户端发送到服务器的字节）。我们还禁用了 Nagle 算法（将小数据包合并为大数据包的内置选项，从而避免频繁的套接字调用）。

我的疑惑如下：

1. 由于我使用的是阻塞套接字，对于每个 1k 的数据包发送，如果 ACK 不是来自服务器，它应该阻塞。那么仅在 WAN 连接中提高 TCP 窗口大小后性能如何提高呢？如果我误解了 TCP Window Size 的概念，请纠正我。

2. 为了发送 64K 的数据，我相信我仍然需要调用套接字发送函数 64 次（因为我通过阻塞套接字每次发送 1k），即使我将 TCP 窗口大小增加到 64K。请确认。

3. 使用 RFC 1323 算法启用窗口缩放的 TCP 窗口大小的最大限制是多少？

我的英语不太好。如果您无法理解以上任何内容，请告诉我。

Answer 1

首先，从您的问题中可以看出一个很大的误解：TCP 窗口大小是由SO_SNDBUFand控制的SO_RCVBUF。这不是真的。

TCP 窗口大小是多少？

简而言之，TCP 窗口大小决定了您的网络堆栈在接收尚未确认的最早数据包的确认之前愿意将多少后续数据（数据包）放在网络上。

TCP 堆栈必须忍受并考虑这样一个事实，即一旦确定数据包在传输过程中丢失或损坏，从该数据包开始发送的每个数据包都必须重新发送，因为数据包只能按顺序确认由接收器。因此，允许同时存在太多未确认的数据包会推测性地消耗连接的带宽：不能保证所使用的带宽实际上会产生任何有用的东西。

另一方面，不允许同时存在多个未确认的数据包只会扼杀具有高带宽延迟积的连接的带宽。因此，TCP 堆栈必须在无益地耗尽带宽和没有足够积极地驱动管道（从而允许其部分容量未被使用）之间取得平衡。

TCP 窗口大小决定了达到这种平衡的位置。

做什么SO_SNDBUF和SO_RCVBUF做什么？

它们控制网络堆栈为服务套接字而保留的缓冲区空间量。这些缓冲区用于累积堆栈尚未能够放在线路上的传出数据和已从线路接收但尚未被您的应用程序分别读取的数据。

如果其中一个缓冲区已满，则在释放一些空间之前，您将无法发送或接收更多数据。请注意，这些缓冲区仅影响网络堆栈如何处理网络接口“近”端的数据（在发送之前或到达之后），而 TCP 窗口影响堆栈如何管理“远”端的数据接口的一侧（即在电线上）。

回答您的问题

1. 不。如果是这种情况，那么每个发送的数据包都会产生往返延迟，这将完全破坏具有高延迟的连接的带宽。

2. 是的，但这与 TCP 窗口大小或分配给该套接字的缓冲区大小无关。

3. 根据我能够找到的所有来源（示例），缩放允许窗口达到 1GB 的最大大小。

Answer 2

1. 由于我使用的是阻塞套接字，对于每个 1k 的数据包发送，如果 ACK 不是来自服务器，它应该阻塞。

错误的。在 TCP 中发送是异步的。send() 只是将数据传输到套接字发送缓冲区并返回。它仅在套接字发送缓冲区已满时阻塞。

那么仅在 WAN 连接中提高 TCP 窗口大小后性能如何提升呢？

因为你在它得到 ACK 之前阻塞是错误的。

1. 对于发送 64K 的数据，我相信我仍然需要调用 socket 发送函数 64 次

为什么？您可以使用 64k 数据缓冲区调用一次。

（因为我通过阻塞套接字每次发送 1k）

为什么？或者这是您在（1）下的误解的重复？

即使我将 TCP 窗口大小增加到 64K。请确认。

不，您可以一次全部发送。不需要循环。

使用 RFC 1323 算法启用窗口缩放的 TCP 窗口大小的最大限制是多少？

比你需要的要大得多。