TCP 数据包大小的实际（与理论）最大限制

Question

我是一名网络开发人员，对该行业还很陌生。我在一次求职面试中遇到了编码挑战，我需要设计一个消息传递系统并构建一个系统来处理消息、格式错误的消息、不同的消息类型、状态日志记录等......

我的问题是关于 TCP 上的数据包大小。

传入消息的速率为 10,000 条消息/秒，每条消息的大小为 2KB。我一直在尝试找到最大、最大安全或最大实用数据包大小限制。我在几个未经验证的地方（即不在技术文档中）看到最大理论大小是 64KB。那是对的吗？在这种情况下，我发送 2KB 消息的示例可以轻松放入单个数据包中，并降低该系统的复杂性。

如果 64KB 是一个错误的数字，那么正确的数字是多少？此外，我不仅仅是想了解最大理论尺寸，而是最大实际尺寸。我想涵盖消息可能略大于目标 2KB 的边缘情况，并为 TCP 所需的各种标头留出空间。

Answer 1

以太网一直对 TCP/IP 数据包大小有影响。以太网具有 1500 字节的标准 MTU，在典型的 20 字节的 IPv4 标头开销和 32 字节的典型现代 TCP 标头开销（过去是 20 字节，但现在我们添加了 12 字节的时间戳选项）之后，会产生 TCP最大段大小为1448 字节。

PPPoE 在基于 DSL 的 ISP 中很流行，它又增加了 8 字节的开销，因此穿过 PPPoE 链路的 TCP 连接最终会得到1440 字节的 TCP MSS 。其他技术可能会增加更多开销。

大多数现代 TCP/IP 堆栈执行“路径 MTU 发现”(PMTUD)，因此它们永远不必依赖 IP 分段。不幸的是，一些站点阻止了 PMTUD 工作所需的 ICMP 消息，从而意外地创建了 PMTUD 无法工作的“PMTUD 黑洞”。为了让 PMTUD 黑洞背后的人们仍然能够连接到他们的服务，Google 站点选择协商一个非常保守的1380 字节的 TCP MSS （我上次检查时）。

因此，我想说，如果您想定制应用程序的写入方式，以确保它们在大多数情况下只填充单个数据包，则可以提出一个很好的论点，使您的写入不大于 1448 字节，也许不大于 1380 字节。

IPv4 数据报可大至 64 KibiByte，但 Internet 上极少有路径具有 64 KiB MTU，因此该数字与大多数数据包大小规划无关。您理论上的消息传递协议服务器可能连接到类似以太网的网络，该网络可能使用标准 1500 字节帧，因此您自己的服务器的 IP 堆栈必须将 64KiB 写入分段为 46 个左右的单独数据包，然后才能开始传输它们在第一跳。即使是设置为使用非标准“巨型帧”的以太网，通常也会达到 9000 字节 MTU 的最大值。我什至无法说出允许 64KiB MTU 的物理/数据链路（第 1/2 层）网络技术的名称。也许是基于 Thunderbolt 的 IP。