在《Computer Networks: A Top Down Approach by Kurose》一书中写道，当流量强度接近 1 时，平均队列长度会越来越大。交通强度是 La/R 其中
L= no of bits in a packet
a= Average arrival rate of packets
R= Transmission rate of the link
Java 小程序也显示了这一点。 https://computerscience.unicam.it/marcantoni/reti/applet/QueuingAndLossInteractive/1.html
根本不应该排队吗？
我没有那本书，但我怀疑他的意思是，虽然平均到达率可能等于最大传输率，但到达率可能会有波动。当到达率波动高于传输率时，队列会填满（假设它不丢弃数据包）。当到达率波动低于最大传输率时......好吧，如果队列中有东西，它可以做一点追赶，但如果没有，它永远不会领先。
结果，队列大小会波动，并且（由于落后与领先之间的不对称性）事实证明，随着时间的推移，平均大小将无限增长。
换一种说法：实际传输速率将比最大传输速率低一个与队列空置的时间比例成比例的量。这可以等于平均到达率的唯一方法是如果队列花费 0% 的时间是空的（好吧，忽略到达率根本不会波动的可能性）。发生这种情况的唯一方法是平均队列大小是无限的。随着时间的推移，它将接近这种情况。
很明显，当入口速率超过出口速率（即“流量强度”超过1）时，您有两个选择：
这两种方法都不是永远正确的解决方案。
诀窍是排队，但要调整队列缓冲区的大小，以便几乎不影响延迟和拥塞检测，同时将数据丢失和重新传输保持在最低限度（浅缓冲）。
编辑- 因为您的问题似乎真的是关于排队/缓冲以实现相等的入口/出口率和最终的缓冲区溢出：
我想，Kurose 试图指出内部处理开销会侵蚀出口容量，这反过来会导致入口和出口之间的轻微不平衡。对于（大多数）基于软件的转发来说，情况确实如此。
然而，大多数现代设备使用基于硬件的转发，可以真正同时接收、处理和传输。因此，处理可以与排队（或者更确切地说是缓冲）重叠，并且所描述的缓冲区增长不再真正发生。
队列填充是数据传输协议的自然效果，例如 TCP（基于连接），它在客户端上有一个数据发送缓冲区，这些数据被填充然后释放到网络上。
在可以发送更多数据之前，发送方需要等待接收方对数据的确认，导致使用带宽的高/低流量波动。