Rob*_*nes 3 network-programming
我在很多地方都读到过关于发送大量小数据包会导致网络拥塞的建议。我什至在最近编写的多线程 tcp 应用程序中也遇到过这种情况。但是，我不知道我是否了解发生这种情况的确切机制。
我最初的猜测是，如果物理传输介质的 MTU 是固定的，并且您发送一堆小数据包，那么每个数据包可能会占用物理介质上的整个传输帧。
例如，我的理解是，尽管以太网支持可变帧，但大多数设备使用 1500 字节的固定以太网帧。在 100 Mbit 时，一个 1500 字节的帧每 0.12 毫秒在线路上“经过”一次。如果我每 0.12 毫秒传输一个 1 字节的消息（加上 tcp 和 ip 标头），我将用 8333 字节的用户数据有效地使 100Mb 以太网连接饱和。
这是对 tinygrams 如何导致网络拥塞的正确理解吗？
我的所有术语都正确吗？
至少在有线以太网中，没有“同步时钟”来计时每一帧的开始。有是最小帧大小，但它更象64字节，而不是1500也有帧之间的最小间隙，但是，很可能只适用于共享接入网络（ATM和以太网现代被切换，而不是共享访问）。它是几乎所有以太网设备上限制为 1500 字节的最大大小。
但是您的数据包越小，帧头与数据的比率就越高。最终，您会为单个字节花费 40-50 字节的开销。以及更多的认可。
如果您能保持片刻并收集另一个字节以在该数据包中发送，您的网络效率就翻了一番。（这就是Nagle 算法的原因）
在有错误的通道上有一个权衡，因为你发送的帧越长，它就越有可能遇到错误并且必须重新传输。较新的无线标准使用前向纠错位加载帧以避免重传。
“tinygrams”的经典示例是 10,000 名用户都坐在校园网络上，在他们的终端会话中输入内容。每次击键都会产生一个数据包（和确认）......以每秒 4 次击键的打字速率，每秒移动 40 KB 就等于每秒 80,000 个数据包。在“经典”的 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%