TCP/IP 最小尺寸

TCP/IP 最小尺寸

我在 PC 上使用高级语言通过 TCP/IP 向远程设备(嵌入式设备)发送消息。
我发送的消息相对较小(< 255 字节)。
我必须假设我的 PC 和目标设备之间会有几个防火墙、代理和网关。
我还必须假设消息在到达目标设备之前可以通过无线电(GPRS、UMTS)传输。

假设目标设备的硬件和软件缓冲区足够大(1000 字节),消息必须有多小才能确保它在目标设备的应用程序级别始终被完整地接收?

换句话说,我是否应该在应用程序协议中包含消息的大小,或者由于消息很小所以它没有用?

答案1

正如 akira 的回答所述,主机必须接受的 IPv4 的最小消息大小为 576 字节,因此 255 字节的数据包不应被分段。

然而,如今大多数主机都实现了Nagle 算法,它会等待 200ms 后再发送数据包,尝试对消息进行分组。这意味着,如果您快速发送消息,它们可能会被分组,然后被碎片化。TCP 不适用于数据报,而是适用于流。网络中的盒子也可能正在做一些奇怪的事情(您永远不知道)。

我建议你在应用程序协议中包含消息的大小。这样可以确保你不会遇到 TCP 以你意想不到的方式分割消息的问题,并且,正如 akira 的回答中所述,将来你可以通过其他媒体进行传输。

答案2

您正在尝试将 TCP/IP 数据包大小调整为所谓的最大传输单元(最大传输单元)。你可以这样做。或者你可以忽略它,因为你使用的是 TCP/IP,所以只需发送数据包:它将通过网络传输,然后被切成碎片,然后自动粘合在一起,然后数据包就会到达。

如果你的消息非常小并且低于“最小数据报大小”,那么这句话会让你高兴:

不要将 MTU 与所有主机必须准备接受的最小数据报大小相混淆,IPv4[2] 中 MTU 为 576 字节,IPv6 中 MTU 为 1280 字节

因此,如果您的消息小于 556 字节(576 字节 - 20 字节 ipv4 标头),它应该作为一个数据包到达。

但即使有碎片:只有当所有(可能的)碎片都到达时,接收方才能获得完整的数据包。这使得“关心”消息大小以避免碎片变得毫无意义。

除了传输大小之外,在消息中包含消息大小也是一个好主意(您可能希望有一天通过不同的媒体传输消息)

相关内容