c++ - 增加 TCP 窗口大小

Question

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

根据我对 TCP 窗口大小的理解，

客户端将数据包发送到服务器。达到此 TCP 窗口大小后，它将等待确保从服务器接收到窗口大小中第一个数据包的 ACK。在 WAN 连接的情况下，由于 RTT 中大约 100 毫秒的延迟，ACK 会从服务器延迟到客户端。所以在这种情况下，增加 TCP Window Size 可以补偿 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_SNDBUF 和 SO_RCVBUF 控制的。这不是真的。

TCP 窗口大小是多少？

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

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

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

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

SO_SNDBUF 和 SO_RCVBUF 有什么作用？

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

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

回答您的问题

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

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

3. 根据我能找到的所有来源 (example)，缩放允许窗口达到 1GB 的最大大小。