Sockets TCP套接字传输

不久前，我有一个问题，为什么我的套接字在发送1024个八位字节时，有时只接收653个八位字节（例如），多亏了Rakis，我明白了：操作系统允许以任意大小的块进行接收

这一次我需要确认：）

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

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

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

即使X>MTU，它也将不得不发送多个数据包，它是否会等到每个数据包都被发送并被套接字的端点确认后再发送Y？好的，这让我相信答案是肯定的，这是有保证的，这正是在阻塞模式下设置套接字的目的，但我想确定：D

提前感谢,，

---

Nolhian

如果是流套接字，则可以保证在Y之前接收X（在应用程序级别）。如果是数据报套接字，则不保证

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

即使在阻塞模式下，socket.send（Y）也可以在X“连接到线路”之前执行，因为操作系统将缓冲网络流量

不，你不能

您只知道客户机将按顺序接收数据，假设它确实接收到所有数据。如果在应用程序级协议中没有某种形式的“确认”，就无法知道（在应用程序级）客户端是否已接收到所有数据

在我执行另一个socket.send（任何字符串）之前，我是否绝对保证X将在套接字的另一端被完全接收（不管接收操作系统将其划分成什么块）

否。通常，在某些限制范围内，无需等待接收方即可发送更多数据：

• 在发送端，您将拥有最大数量的数据，您可以排队等待传输，直到客户端确认某些接收（但通常客户端的操作系统会在拒绝进一步的数据之前确认并缓冲大量数据，直到应用程序处理完一些数据），之后发送套接字可能会开始阻塞
  强制应用程序设计考虑如何对数据量进行排队和缓冲，而不是使用大量的操作系统提供的缓冲存储器。
  • 当接收端数据过快而无法处理时，可降低重传率
  • 避免在网络连接丢失的情况下发送大量数据

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

无论需要什么样的重传和缓冲，您可以确定的是，在接收端开始接收随后发送的数据“Y”之前，接收端必须读取所有的“X”（除非它特别要求接收，例如带外数据）。

根据您使用的数据类型，在某些情况下，您可以，保证将收到数据，但不保证在实际收到数据时收到反馈或确认

---

回到你的问题：

在发送Y之前，它是否等待套接字的端点发送每个数据包并确认每个数据包

所以，你可以说：

• 是的，它会一直等到发送，并且
• 不，它不等待确认

---

建议：

---

由于没有收到您的数据的自动魔法/内置确认，因此您可以相当轻松地实现自己的逻辑，确认收到了包，这基本上取决于您的自定义通信协议。

谢谢，这是我需要知道的，我的应用程序将始终在Y之前接收X，无论使用TCP套接字执行什么操作。如果我理解正确，即使操作系统在X之前接收到Y（由于丢失/重新发送），它也会对其进行缓冲并等待接收X，以便最终以正确的顺序将X和Y转发给应用程序？我猜这是TCP协议的一部分？不，不。它不等待它被发送，也不等待确认。你好，首先感谢你的回答，但我很困惑。TCP协议应该保证所有的数据都被接收并且顺序正确，那么为什么斜体风格会这样呢？正如你所说，在应用程序级别上，不可能知道，但实际上，即使应用程序不知道，TCP的工作就是确保它确实接收到所有数据，还是我在某个地方错了？@Nolhian：如果网络在所有数据真正到达另一端之前就消失了，TCP对此无能为力。连接超时后，发送将失败。。。但在那之前，它不会。事实上，我不认为你的意思是中断连接！在我的情况下，这并不是那么重要，因为唯一重要的是客户端从未以错误的顺序接收数据，但感谢您指出这一点！最重要的是，正如您所确认的，无论发生什么情况，客户都会按顺序接收数据。感谢您的技术性解释和最后一段中的想法！也是最后一个