让我们假设 1 Gbit/s 的站 A 想要将数据包发送到 100 Mbit/s 的站 B。共有三个路由器，分别为 10 Mbit/s、1 Gbit/s 和 10 Mbit/s。数据包交付是如何进行的？
简而言之，您将获得 10 Mbit/s 的吞吐量。
天真地，人们可能会认为 TCP 流量控制会像 LawrenceC 所说的那样启动，这通常是正确的答案。
但是，在您的具体示例中，事实并非如此。
连接到 1GbE 卡的 10 Mbit/s 路由器将协商 10 Mbit/s。中间 GbE 路由器和 B 侧的 10 Mbit/s 路由器也是如此。故事结局。
因此，网络适配器只会以该速率发送和接收，永远不会超过该速率。确实，从你的角度来看，整个网络是 10 Mbit/s。
中间 GbE 路由器可能会以 1 Gbit/s 的速度与世界其他地方接收和转发数据包，但在您的特定路由上只能以 10 Mbit/s 的速度进行。
假设网络拓扑是有点更复杂（互联网！），并有一些千兆路由器的数量，以及一个或几个10 Mbit / s的路由器某处之间。那个案子比较有意思。
在这种情况下，您的计算机 A 将以 1 Gbit/s 的速度发送数据包，但我们知道只有 10 Mbit/s 可以通过（好吧，不是真的，有其他路由，但让我们忘记这一点）。这怎么能行？
在这种情况下，确实，TCP 流量控制将启动。B 站将以 100 Mbit/s 的速度接收数据包，但它们只是偶尔进来。您将以 1 Gbit/s 的速度发送数据包，但您必须定期暂停。这在您不知情的情况下适用于 TCP 层。
TCP 将尽可能快地发送一些数据包（并保持一个“窗口”），网卡将尽可能快地将它们放在线路上并允许，然后 TCP 将等待确认进来. 如果他们真的进来了，一切都很好，更多的东西可以尽快发送。如果 ACK没有进来，要么有错误（不太可能），要么数据包发送得太快。因此，窗口大小减小。一旦 ACK 再次进来，窗口就会再次逐渐扩大。有不同的算法，它们相当复杂，但原则上就是这样。
现在......路由器接受有限数量的数据包，并根据它们的能力尽可能快地转发它们。然而，最终，他们将不得不丢弃数据包。这不是错误，而是正常情况。
具有讽刺意味的是，大概是旧的 10 Mbit/s 路由器可能会排队很多数据包（从前，人们认为“越多越好”，现在知道情况恰恰相反，现代路由器有很多短队）。
更多并不总是更好的见解来自这样一个事实：如果路由器将大量数据包排队然后转发它们，发送方可能会假设数据包丢失（因为没有 ACK 进来）并重新发送。这会导致接收器收到必须丢弃的重复数据包，并导致路由器变得更加拥塞，将油倒入火中。因此，现代路由器丢弃很快。
现在，在中间某处的旧 10 Mbit/s 路由器的示例中（并且速度未协商），因此很可能您获得的吞吐量远低于 10 Mbit/s。您会收到重新发送和双重交付。应用程序对这些都不可见，只是由于某些奇怪的原因而变慢了。