使用 TCP 的应用程序的抽象模型是字节流。字节将按照发送应用程序发送的相同顺序传送到接收应用程序，但通常不会以相同大小的块发送。如果应用程序想要通过 TCP 连接发送消息，它需要提供它自己的消息帧。

如果数据包丢失并需要重新传输，或者如果网络对数据包重新排序，则接收 TCP 实现将需要在间隙后保留数据，直到它可以按顺序将数据传送到接收应用程序。

您应该转到源文档RFC 793, TRANSMISSION CONTROL PROTOCOL。第 3.8 节，接口描述了这一点：

收到

格式：RECEIVE（本地连接名称、缓冲区地址、字节数）->字节数、紧急标志、推送标志

此命令分配与指定连接关联的接收缓冲区。如果此命令之前没有 OPEN 或调用进程无权使用此连接，则返回错误。

在最简单的实现中，控制不会返回到调用程序，直到缓冲区被填满，或者发生了一些错误，但这种方案很容易出现死锁。更复杂的实现将允许多个 RECEIVE 一次未完成。这些将在段到达时填充。此策略允许以更复杂的方案（可能是异步的）为代价来增加吞吐量，以通知调用程序已看到 PUSH 或缓冲区已填充。

如果在看到 PUSH 之前有足够的数据到达填充缓冲区，则不会在对 RECEIVE 的响应中设置 PUSH 标志。缓冲区将填充尽可能多的数据。如果在缓冲区填充之前看到 PUSH，则缓冲区将返回部分填充并指示 PUSH。

如果有紧急数据，用户将通过 TCP 到用户的信号一到达就得到通知。因此，接收用户应该处于“紧急模式”。如果 URGENT 标志打开，则额外的紧急数据会保留。如果 URGENT 标志关闭，则此对 RECEIVE 的调用已返回所有紧急数据，用户现在可以离开“紧急模式”。请注意，紧急指针之后的数据（非紧急数据）不能与前面的紧急数据在同一缓冲区中传递给用户，除非为用户清楚地标记了边界。

为了区分几个未完成的接收并处理缓冲区未完全填充的情况，返回码伴随着缓冲区指针和字节计数，指示接收到的数据的实际长度。

RECEIVE 的替代实现可能让 TCP 分配缓冲区存储，或者 TCP 可能与用户共享一个环形缓冲区。