当发送大于SendBufferSize的数据时，如何接收数据? [英] When sending data larger than the SendBufferSize, how will the data be received?

问题描述

我只是问了一个有关如何发送大于SendBufferSize的数据的问题，答案是将分两部分发送.

I just asked a question on how to send data larger than the SendBufferSize and the answer was that is would be send in a couple of parts.

我的第二个问题是如何接收这些数据?它是在网络流中完成还是将其拆分?

My second question is how will this data be received? Will it be complete in the network stream or will it get it divided.

第一个问题:可以您通过TcpClient发送的文件比SendBufferSize大吗?

推荐答案

TCP并非仅消息协议.这是一个基于流的协议，并负责为我们拆分数据.Lemme带您进入核心部分.对于TCP，分为两部分-分段和分段.

TCP is not a message only protocol. It is a stream based protocol and takes care of splitting the data for us. Lemme take you to the core section. There are two parts in the case of TCP - Segmentation and Fragmentation.

分段发生在TCP(传输层)上.这取决于两个参数-MSS和窗口大小".MSS确定设备可以接收的段的最大大小.通过TCP选项在初始连接建立期间传送MSS.数据流的每个方向都可以使用不同的MSS，由操作系统确定.但是，窗口大小由接收方在TCP报头中发送，以便在等待接收主机的确认和窗口更新之前，一次在连接的接收方传达它可以缓冲的最大数据量.也就是说，主机可以在耗尽接收器的窗口大小之前发送多个段(MSS因子).

Segmentation happens at TCP (Transport Layer). This is dependent on two parameters - MSS and Window Size. MSS determines the maximum size of segment that a device can receive. The MSS is communicated during the intial connection establishment via TCP options. Each direction of data flow can use a different MSS and the operating system determines it. However, the Window size is sent in TCP header by the receiver to communicate the maximum of data it can buffer at one time on the receiving side of a connection before waiting an acknowlegement and window update from the receiving host. That is, a host can send a number of segments(factor of MSS) before exhausting the receiver's window size.

碎片在IP(网络层)上以两种方式发生.如果在发送方和接收方之间的通信路径上没有任何MTU受限的设备，则碎片会碰巧满足以太网(1500字节)的MTU.但是，如果在发送方和接收方之间存在MTU限制的中间设备，则IP层(Internet协议)会进行数据报分段，以便可以形成数据包，使它们可以通过具有较小最大传输单元的链路(MTU)比原始数据报的大小大.如果中间设备具有MTU限制，则发送方还应部署路径MTU发现，以确定通往接收方的网络路径中的最小MTU，并动态调整MSS以避免网络内的IP分段.通过在传出数据包的IP标头中设置DF(不分片)选项，可以完成路径MTU发现.发送方和接收方之间的通信路径中任何MTU小于数据包的设备都将丢弃此类数据包，并使用包含该设备MTU的ICMP目标不可达(数据报太大)"消息答复发送方.此信息使发送方可以适当地减少其假定的路径MTU.

Fragmentation happens at IP(Network Layer) in two ways. If there are no devices with MTU limitation on the path of communication between the sender and receiver, fragmentation will happen to meet the MTU of ethernet(1500 bytes) alone. However, incase of presence of an intermediate device with a MTU limitation between the sender and receiver, IP layer(Internet protocol) does datagram fragmentation, so that packets may be formed such that they can pass through a link with a smaller maximum transmission unit (MTU) than the original datagram size. In case of intermediate device with MTU limitations, the sender shall also deploy path MTU discovery to determine the the minimum MTU in the network path towards the receiver and dynamically adjust the MSS to avoid IP fragmentation within network. Path MTU discovery is done by setting the DF (Don't Fragment) option in the IP headers of outgoing packets. Any device in the path of communication between the sender and receiver, whose MTU is smaller than the packet will drop such packets and reply the sender with ICMP "Destination Unreachable (Datagram Too Big)" message containing the device's MTU. This information allows the sender to reduce its assumed path MTU appropriately.

因此，这导致了MSS与MTU之间的关系.RFC 791指出所有主机必须准备好接受最多576个八位字节的数据报(无论它们是完整到达还是以碎片到达)".因此，IP网络的最小MTU为576.对于TCP，减去20个字节的TCP标头和20个字节的IP标头，我们将获得536个字节作为TCP的标准MSS.

So, this leads to the point of relation between the MSS and MTU. The RFC 791 states that "All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments)". So, the minimum MTU for IP networks is 576. In case of TCP, deduction of 20 bytes for the TCP header and 20 bytes for the IP header we will give us 536 bytes as standard MSS for TCP.

现在，让我们进入重新组装部分.碎片可能基于中间设备上的MTU发生，但是重组只能在目标设备上发生.TCP负责分段，但是在目标设备上，TCP应当负责排序，但是应用程序应注意分段的重新组装.

Now, lets get into the re-assembly part. Fragmentation can happen based on MTU on the intermediate devices, but the re-assembly shall happen only at the destination device. TCP takes care of segmentation, however on the destination device, TCP shall take care of ordering, but the re-assembly of the segments should be taken care by the application.

因此，如果您只需要基于整个消息的通信并且不考虑可靠性，那么UDP将是您的选择.但是，请注意，如果您可以通过拆分发送大量数据，则UDP将无法确保数据包的排序，并且由于它没有像重新传输这样的错误纠正机制，因此也将无法处理数据包丢弃

So, If you need only whole message based communication and reliability is not a concern, then UDP shall be your choice. However, note that if you can send a large data by splitting, UDP will not be able to ensure the ordering of the packets and also it will not be able to deal with packet drops as it does not have error correction mechanism like re-transmission.

如果您希望像UDP一样进行基于消息的通信，但又要加上TCP功能，例如可靠的按顺序传送，拥塞控制以及基于它的其他改进/功能，例如多流，多归属，内置MTU发现，然后应选择SCTP.但是，如果您的网络中有旧版NAT系统，则可能需要将SCTP封装在UDP中.

If you would want to have a message based communication just as in UDP but coupled with TCP features like reliable in-order delivery, congestion control and also additional improvements/features on top of it, like multi-streaming, multi-homing, in-built MTU discovery, then SCTP should be your choice. However, if you have legacy NAT systems in your network, then you may need to go for encapsulating SCTP in UDP.

这篇关于当发送大于SendBufferSize的数据时，如何接收数据?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！