发送小图如何导致网络拥塞？

Question

我在很多地方都读到了一些建议，即发送大量小数据包会导致网络拥塞。我甚至用我最近编写的多线程tcp应用程序来体验这一点。但是，我不知道我是否理解这种情况发生的确切机制。

我最初的猜测是，如果物理传输媒体的MTU是固定的，并且你发送了一堆小数据包，那么每个数据包可能会占用物理媒体上的整个传输帧。

例如，我的理解是，即使以太网支持可变帧，大多数设备也使用1500字节的固定以太网帧。在100 Mbit时，每隔0.12毫秒就会在线上“经过”一个1500字节的帧。如果我每0.12毫秒发送一个1字节的消息（加上tcp＆amp; ip报头），我将用8333字节的用户数据有效地使100Mb以太网连接饱和。

这是否正确理解了小图如何导致网络拥塞？

我的所有术语是否正确？

Answer 1

至少在有线以太网中，没有“同步时钟”占用每帧的开头。 是最小帧大小，但它更像是64字节而不是1500.帧之间也存在最小间隙，但这可能仅适用于共享访问网络（ATM和现代以太网被切换，不共享访问）。几乎所有以太网设备上的最大大小限制为1500字节。

但是数据包越小，framing headers与数据的比率就越高。最终，您将为单个字节花费40-50个字节的开销。更多的是它的承认。

如果你可以暂时停留并收集另一个字节来发送该数据包，那么可以加倍您的网络效率。 （这是Nagle's Algorithm）

的原因

在有错误的频道上存在权衡，因为您发送的帧越长，遇到错误的可能性越大，并且必须重新传输。较新的无线标准使用forward error correction位加载帧以避免重传。

“tinygrams”的典型例子是10,000个用户都坐在校园网络上，输入他们的终端会话。每次击键都会产生一个数据包（和确认）....按每秒4次击键的打字速度，这是每秒80,000个数据包，每秒移动40千字节。在“经典”10mbit共享中等以太网上，这是不可能的，因为你只能在一秒内发送27k最小大小的数据包 - 不包括冲突的影响：

   96 bits inter-frame gap 
+  64 bits preamble 
+ 112 bits ethernet header 
+  32 bits trailer 
-----------------------------
= 304 bits overhead per ethernet frame.
+   8 bits of data (this doesn't even include IP or TCP headers!!!)
----------------------------
= 368 bits per tinygram

10000000 bits/s ÷ 368 bits/packet = 27172 Packets/second.

或许更好的方式来说明一个最大化移动微小图的以太网只能在10mbit / s介质上移动216kbits / s，效率为2.16％

Answer 2

通过链路传输的TCP数据包将具有40字节的头信息。因此，如果将传输中断为100个1字节数据包，则每个发送的数据包将具有40个字节，因此用于传输的大约98％的资源是开销。相反，如果将其作为一个100字节的数据包发送，则传输的总数据仅为140字节，因此只有28％的开销。在这两种情况下，您通过网络传输了100字节的有效负载，但在一种情况下，您使用了140字节的网络资源来完成它，而在另一种情况下，您使用了4000字节。此外，中间路由器需要更多资源来正确路由100个41字节有效载荷，而不是1个40字节有效载荷。路由1字节数据包几乎是路由器性能最差的情况，因此在这种情况下它们通常会表现出最差的性能。

此外，特别是对于TCP，由于小数据包导致性能下降，机器可以尝试做一些事情来补偿（如重新传输），实际上会使事情变得更糟，因此使用Nagles算法试图避免这种情况。

Answer 3

BDK约有一半答案（+1为他）。问题的很大一部分是每条消息都带有40字节的开销。它实际上有点更糟。

另一个问题是，IP实际上存在最小数据包大小。 （这是不 MTU。在开始分段之前MTU是 M 最大值。完全不同的问题）最小值非常小（我认为46字节，包括你的24字节TCP标题），但是如果你不使用那么多，它仍会发送那么多。

另一个问题是协议开销。 TCP发送的每个数据包都会导致ACK数据包作为协议的一部分由接收方发回。

结果就是你做了一些愚蠢的事情，比如每次用户点击一个密钥时发送一个TCP数据包，你很容易就会浪费大量浪费的开销数据。