TCP套接字传输

Question

不久前，我有一个问题，为什么当我发送1024个八位字节时，我的套接字有时只接收653个八位字节(例如)，多亏了Rakis，我明白了:操作系统允许接收任意大小的块。

这一次我需要确认:)

在任何操作系统(至少是GNU/Linux和Windows )上，在任何语言(我这里使用Python语言)中，如果我发送一个随机数个字节的包，可以是2个字节，可以是12000个字节，比方说X，当我写socket.send(X)时，我是否绝对保证在我执行另一个socket.send(任何字符串)之前，套接字的另一端将完全接收到X(无论接收OS将其分成多少块)？

或者换句话说，如果我有代码的话：

socket.send(X)
socket.send(Y)

即使X> MTU，因此它将被迫发送多个数据包，它是否等到每个数据包都已发送并被套接字的端点确认后，才发送Y？好吧，这让我相信答案是肯定的，它是有保证的，这正是将套接字设置为阻塞模式的目的，但我想要确定:D

提前谢谢你，诺希安

Answer 1

如果X是一个流套接字，那么您可以保证X将在Y之前被接收(在应用程序级别)。如果它是一个数据报套接字，就不能保证。

根据网络实现的不同，可能会在较低级别上发送X，在传输中丢失，然后发送Y，然后重新发送X，因为没有收到确认。

即使在阻塞模式下，socket.send(Y)甚至可以在X“上线”之前执行，因为操作系统将缓冲网络流量。

Answer 2

不，你不能。

您所知道的就是客户端将按顺序接收数据，假设它确实接收了所有数据。在应用层协议没有某种"ACK“的情况下，无法知道(在应用层)客户端是否已接收到所有数据。

Answer 3

我是否绝对保证在执行另一个socket.send(任何字符串)之前，套接字的另一端将完全接收到X(不管接收OS将其分成的任何块)？

不是的。一般来说，在一定的限制范围内，可以在不等待接收方的情况下发送更多的数据：

• 在发送端，在客户端确认某些接收之前，您可以排队传输的数据量是最大的(但通常客户端的操作系统在拒绝进一步的数据之前会进行大量的确认和缓冲，直到应用程序处理了一些数据)，在此之后，发送套接字可能会开始阻塞

- forces the application design to consider how to enqueue and buffer excessive amounts of data, rather than having naively written applications utilise excessive amounts of Operating System-provided buffer memory
- reduces retransmission rates when the receiving side is flooded with data too fast to process it
- avoids sending huge amounts of data despite the network connection having been lost

​

因此，严格地说，对于大型传输，发送器应该被设计为处理阻止进一步发送的套接字(或者知道阻塞尝试是可以的(可能是由于专用的发送线程)，或者等待直到可以通过非阻塞套接字或选择/轮询发送更多的套接字)。

无论需要什么重新传输和缓冲，您可以确定的是，在接收端开始接收随后发送的数据"Y“之前，它必须读取所有的"X”(除非它特别要求使用其他方式，例如带外数据)。