TCP是一种面向流的协议。不是面向消息/记录/块的。也就是说，可以保证的是，如果您发送一个流，字节将按照您发送的顺序到达另一端。RFC 793或任何其它文档没有规定所涉及的段/分组的数量。
这与UDP形成了鲜明的对比。作为@R..正确地说，在UDP中，整个消息在一个操作中发送(请注意术语message的更改)。尝试使用TCP发送巨型消息(比MTU大几倍)？没关系，它会帮你平分的。
当在本地网络或本地主机上运行时，您肯定会注意到(通常) one send == one recv。不要这样假设。有一些因素会极大地改变这一点。其中包括
NagleUnderlying MTUMemory usage (possibly)TimersMany others
当然，在send和recv之间没有通信是一件麻烦的事情，您不能依赖UDP。这是SCTP的原因之一。message-oriented.是一个非常有趣的协议，名为SCTP
回到TCP，这是一个常见的麻烦。一种同样常见的解决方案是：
确定所有数据包都以固定长度的序列(例如32字节)开头，并且这些32 字节包含(可能还有其他内容)<>H136>后面的消息的大小当您从套接字读取任意数量的数据时，请将数据添加到特定于该连接的缓冲区中。当达到32 字节的时，读取您仍然需要读取的长度，直到收到消息为止。
值得注意的是，网络上实际上没有消息，只有字节。一旦你理解了这一点，你就向编写网络应用程序迈出了一大步。