TCP/UDP和以太网MTU碎片 [英] TCP/UDP and ethernet MTU Fragmentation

问题描述

我已经在线阅读了各种站点和教程，但仍然感到困惑.如果消息大于IP MTU，则send()返回发送的字节.其余消息会怎样?我是否要再次呼叫send()并尝试发送其余消息?还是IP层应该自动处理?

I've read various sites and tutorials online but I am still confused. If the message is bigger than IP MTU, then send() returns the byte sent. What happens to the rest of the message? Am I to call send() again and attempt to send rest of the message? Or is that something IP layer should take care of automatically?

推荐答案

如果您使用的是TCP，那么提供给您的接口就是字节流.您无需担心字节流如何从连接的一端到达另一端.您可以忽略IP层的MTU.实际上，您可以完全忽略IP层.

If you are using TCP then the interface presented to you is that of a stream of bytes. You don't need to worry about how the stream of bytes gets from one end of the connection to the other. You can ignore the IP layer's MTU. In fact you can ignore the IP layer entirely.

当您调用send()时，计算机上的TCP堆栈将处理所有必要的详细信息，以便将要推送到发送调用中的字节流从连接另一端的recv()调用中显示出来.

When you call send() the TCP stack on your machine will deal with all the details necessary for the stream of bytes that you are pushing into your send calls to appear from recv() calls at the other end of the connection.

要记住的一件事是，使用TCP处理的是流，这意味着一个send()可能导致数据到达多个recv()调用，而多个send()调用可能导致数据到达一个流.单个recv()调用.您对此无能为力.您正在处理字节流，每次对recv()的调用都可以返回从1到当前未完成的任何数量的字节(允许足够的缓冲区传递给recv()调用).

The one thing to remember is that with TCP you are dealing with a stream and that means that one send() may result in data arriving in multiple recv() calls and multiple send() calls may result in data arriving in a single recv() call. You have no control over this. You are dealing with a stream of bytes and each call to recv() can return any number of bytes from 1 to the number currently outstanding (allowing for adequate buffers passed to the recv() call).

由于评论者要求；)

在大多数TCP堆栈上，send()最有可能无法发送所有内容，因为TCP堆栈的缓冲区已满，并且(可能)TCP窗口也已满，并且流控制处于运行状态，这意味着堆栈无法发送直到远端确认了一些数据并且不准备再代您缓冲任何更多数据为止.我没有遇到仅出于MTU考虑而拒绝send()的TCP堆栈，但我想某些精简的嵌入式系统可能会以这种方式运行...

On most TCP stacks send() is most likely to fail to send everything because the TCP stack's buffers are full and (probably) the TCP window is also full and flow control is in operation which means that the stack can't send any more data until the remote end ACKs some data and it's not prepared to buffer any more on your behalf. I've not come across a TCP stack that will refuse a send() due to MTU considerations alone but I guess some slimmed down embedded systems might behave that way...

无论如何，如果send()返回的字节数少于您提供的字节数，则应在某个时候重新发送剩余的数据. send()通常会阻塞并等待，直到它可以发送所有数据为止；如果将套接字设置为非阻塞模式，那么如果它无法发送所有内容，您可能不希望立即重试发送可能会陷入一个死循环...

Anyway, if send() returns less than the number of bytes that you supplied it then you should resend the remaining data at some point. Often send() will block and wait until it can send all of the data, and if you've set the socket into non blocking mode then you probably do NOT want to immediately retry the send if it fails to send everything as you'll likely end up in a tight loop...

更详细地说明您所使用的操作系统可能对您很有用.

It would probably be useful for you to be more specific about the operating system that you're using.

这篇关于TCP/UDP和以太网MTU碎片的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！