代码之家 › 专栏 › 技术社区 › Robert S. Barnes Antoni

发送耳鸣如何导致网络拥塞?

network-programming

Robert S. Barnes Antoni · 技术社区 · 14 年前

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

我最初的猜测是,如果物理传输介质的mtu是固定的,并且你发送一堆小数据包,那么每个数据包可能占用物理介质上的整个传输帧。

例如,我的理解是,尽管以太网支持可变帧,但大多数设备使用1500字节的固定以太网帧。在100mbit时,1500字节的帧每0.12毫秒在线路上“通过”。如果我每0.12毫秒发送一个1字节的消息(加上TCP&IP头),我将有效地用8333字节的用户数据使100MB以太网连接饱和。

这是否正确理解了耳鸣是如何导致网络拥塞的?

我所有的术语都正确吗?

3 回复 | 直到 14 年前

Joe Koberg 14 年前

至少在有线以太网中,没有一个“同步时钟”会对每一帧的开始进行计时。那里是最小帧大小,但更像是64字节而不是1500字节。帧之间也有最小的间隔,但这可能只适用于共享访问网络(ATM和现代以太网是交换的,而不是共享访问)。它是 最大限度 在几乎所有以太网设备上限制为1500字节的大小。

但是你的数据包越小, framing headers 数据。最终,您要为一个字节花费40-50字节的开销。更重要的是它的认可。

如果您能稍等片刻,再收集一个字节来发送该数据包,您就可以加倍你的网络效率。(这就是为什么 Nagle's Algorithm )

在有错误的信道上有一个折衷方案,因为发送的帧越长,就越可能遇到错误,并且必须重新传输。较新的无线标准在帧中加载 forward error correction 避免重传的位。

“Tinygrams”的典型例子是10000个用户都坐在校园网络上,输入他们的终端会话。每一次按键都会产生一个数据包(和确认信息)……以每秒4次击键的速度,即每秒80000个数据包,每秒移动40kbytes。在“经典”的10兆位共享介质以太网上,这是不可能实现的,因为您在一秒钟内只能发送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.

也许一个更好的方式来说明这一点,就是一个以太网络,如果它的传输速度超过了10兆位/秒,那么它的传输效率只有2.16%。

bdk 14 年前

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

此外,特别是对于tcp,由于小数据包导致性能下降,机器可以尝试做一些补偿(如重传)的事情,这实际上会使事情变得更糟,因此使用nagles算法试图避免这种情况。

T.E.D. 14 年前

bdk有一半的答案(+1个给他)。问题的很大一部分在于,每条消息都有40字节的开销。其实有点 更糟的 不过,比这更重要。

另一个问题是 最低限度 IP指定的数据包大小。(这是不 MTU。MTU是米在它开始分裂之前的最大值。完全不同的问题)最小值非常小(我想是46字节,包括24字节的tcp头),但是如果不使用那么多,它仍然会发送那么多。

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

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