的TCP窗口大小是通常独立于的最大段大小取决于所述上最大传输单元而这又取决于该最大帧大小。

让我们从低开始。

的最大帧大小是最大的帧的网络（段）可以传输。对于以太网，根据定义，这是 1518 字节。

该帧封装了一个IP 数据包，因此最大的数据包 -最大传输单元MTU - 是最大帧大小减去帧开销。对于以太网，即 1518 - 18 = 1500 字节。

IP 数据包封装了一个TCP 段，因此最大段大小MSS 是 MTU 减去 IP 开销减去 TCP 开销（MSS 不包括 TCP 标头）。对于没有选项的以太网和 TCP over IPv4，这是 1500 - 20（IPv4 开销）- 20（TCP 开销））= 1460 字节。

现在，TCP 是一种传输协议，它将自身呈现为应用程序的流套接字。这意味着应用程序可以通过该套接字传输任意大小的数据量 - 在单个流或任意数量的块中。为此，TCP 将数据流拆分为所述段（0 到 MSS 字节长 {1}），通过 IP 传输每个段，然后在目的地将它们重新组合在一起。在应用程序级别，数据流在源和目标上看起来完全相同。所有分段、打包、分片等都是完全透明的。

TCP 段由目的地确认以保证交付。现在想象源节点只会发送一个分段，等待确认，然后发送下一个分段（发送窗口 = MSS）。无论实际带宽如何，此 TCP 连接的吞吐量将被限制为每个往返时间（RTT，数据包从源传输到目的地并返回所需的时间）一个数据包。

因此，如果您在两个节点之间建立了 1 Gbit/s 连接且 RTT 为 10 毫秒，则您可以每 10 毫秒有效发送 1460 个字节，即 146 kB/s。这不是很令人满意。

因此，TCP 使用一个发送窗口——多个段可以同时“在飞行中”，被发送出去并等待确认。它也被称为滑动窗口，因为它每次在窗口开始处的段被确认时前进，触发窗口前进到的下一个段的发送。这样，段大小无关紧要，只有发送窗口大小才重要。使用传统的 64 KiB 窗口，我们可以在飞行中获得该数量，因此，每 10 毫秒传输 64 KiB = 6.5 MB/s。更好，但仍然不能真正满足千兆连接。

现代 TCP 使用窗口缩放选项，可以将发送窗口以指数方式增加到 64 KiB * 2 ¹⁴ = 1 GiB，为未来的增长做准备。

但是为什么不是一次性发送所有数据，为什么我们需要这个发送窗口？

如果您尽可能快地发送所有内容 - 在本地 - 可以并且（很可能）沿着到达目的地的路径某处有一个较慢的链接，则需要对大量数据进行排队。没有交换机或路由器能够缓冲超过几 MB（如果有的话），因此需要丢弃多余的流量。如果确认失败，则需要重新发送，多余的将再次丢弃。这将是非常低效的，并且会严重拥塞网络。TCP 用它的拥塞控制来处理这个问题，在一个复杂的算法中根据（估计！）有效带宽和当前往返时间调整窗口大小。

{1} 空段可用于使用keepalive选项防止连接超时。Thx 重复数据删除器