发送数据大于SendBufferSize时如何接收数据？我刚刚问了一个关于如何发送大于SendBufferSize的数据的问题，答案是它会分几部分发送。我的第二个问题是如何接收这些数据？是在网络流中完成还是拆分。第一个问题：你能发送一个比TcpClient更大的SendBufferSize的文件吗？TCP不是仅消息协议。这是一个基于流的协议，负责为我们拆分数据。Lemme带您进入核心。在TCP的情况下，有两个部分-分段和分段。分段发生在TCP（传输层）。它取决于两个参数——MSS和窗口大小。MSS确定设备可以接收的段的最大大小。MSS在初始连接建立期间通过TCP选项传送。数据流的每个方向都可以使用不同的MSS，这是由操作系统决定的。但是，窗口大小由接收方在TCP标头中发送，以便在等待接收主机的确认和窗口更新之前，在连接的接收端缓冲一次可以缓冲的最大数据量。也就是说，主机可以在耗尽接收方的窗口大小之前发送多个段（MSS因子）。分片以两种方式发生在IP（网络层）。如果发送方和接收方之间的通信路径上没有MTU限制的设备，则会发生分片以满足以太网的MTU（1500字节）。但是，由于发送方和接收方之间存在具有MTU限制的中间设备，IP层（Internet协议）会进行数据报分片，以便可以形成数据包，使它们可以通过具有较小最大传输单元（MTU）的链路)比原始数据报大小。在中间设备有MTU约束的情况下，发送方还应部署路径MTU发现以确定到接收方的网络路径中的最小MTU，并动态调整MSS以避免网络内的IP分片。路径MTU发现是通过在传出数据包的IP标头中设置DF（不分片）选项来完成的。发送方和接收方之间通信路径中的任何设备（其MTU小于数据包）将丢弃此类数据包，并使用包含设备MTU的ICMP“目标无法到达（数据报太大）”消息回复发送方。此信息允许发送方适当地减少其假设的路径MTU。因此，这导致了MSS和MTU之间的关系点。RFC791声明“所有主机必须准备好接受最多576个八位字节的数据报（无论它们是完整的还是分段的）”。因此，IP网络的最小MTU为576。在TCP的情况下，减去20字节的TCP标头和20字节的IP标头，我们将有536字节的TCP作为标准MSS。现在，让我们进入重新组装部分。分段可能会根据中间设备上的MTU发生，但重组只会发生在目标设备上。TCP负责分段，但在目标设备上TCP应该负责排序，但应该由应用程序重新组合分段。因此，如果您只需要基于整个消息的通信并且可靠性不是问题，那么UDP将是您的选择。但是，请注意，如果您可以使用拆分发送大数据，UDP无法确保数据包顺序，也无法处理数据包丢失，因为它没有像重传这样的纠错机制。如果您想要像UDP中那样的基于消息的通信，但需要TCP功能，例如可靠的有序交付、拥塞控制和其他改进/功能，例如多流、多宿主和建立MTU发现，那么SCTP应该是你的选择。但是，如果您的网络中有遗留NAT系统，您可能需要将SCTP封装在UDP中。与例如相反UDP、TCP不是允许发送单个“消息”的协议，该消息以相同的形式传递给接收方。您宁愿发送和接收字节流。在引擎盖下，你的数据被分成IP数据包，不管SendBufferSize，顺便说一句，默认是8192，这比单个IP数据包高得多（IP数据包的最大大小与MTU有关，但大多小于1500词节）。示例：Socket.Send（2000字节）IP数据包#1（1460字节）IP数据包#2（540字节）另外：来自多个Socket.Send()的数据可能会合并（Nagle算法）。示例：Socket.Send(1000bytes)Socket.Send(1000bytes)IPpacket#1(1460bytes)IPpacket#2(540bytes)接收方无法区分这两种情况。更重要的是，在接收端，出于效率原因，数据可能会以不同大小的缓冲区传递给您。底线：使用TCP，您不能依赖于接收与您发送的相同数量和相同大小的数据包。如果您需要它，请按照StephenCleary的建议添加大小信息，或者使用像UDP这样的协议，或者如果您需要可靠性：SCTP。但是，除非您对SCTP相对于TCP的其他改进感兴趣，否则这似乎有些矫枉过正。.Net为您处理拆分数据。您可以写入和接收大于SendBufferSize的数据包而不会注意到它（如果您不太关心性能）。您需要在协议中使用称为消息帧的东西。有趣的事实：即使发送小于SendBufferSize的消息，您也需要SendBufferSize。？您的数据很可能会在接收时被拆分，因此您需要在收到所有数据后重建它。以上就是C#学习教程：发送数据大于SendBufferSize时如何接收数据？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
