链路
链路的属性
既然我们已经了解了互联网各层的构建方式，接下来让我们聚焦于数据包如何通过链路传输。
我们可以用三个属性来衡量链路的性能。
链路的带宽表示单位时间内可以在链路上发送的比特数。直观地说，这就是链路的速度。如果把链路想象成一根输水的管道，带宽就相当于管道的宽度。管道越宽，每秒能输送的水就越多。我们通常用比特每秒来衡量带宽（例如，5 Gbps = 50 亿比特每秒）。
链路的传播延迟表示一个比特沿链路传输所需的时间。在管道的类比中，这相当于链路的长度。管道越短，水在到达另一端之前在管道中的时间就越少。传播延迟以时间为单位（例如，纳秒、毫秒）。
如果我们将带宽和传播延迟相乘，就得到了带宽 - 延迟积（BDP）。直观地说，这是链路的容量，或者说在任何给定时刻链路上存在的比特数。在管道类比中，如果我们把管道装满水然后冻结时间，此时管道中的水量就是管道的容量。
注意：你可能偶尔会看到延迟（latency） 这个术语。在链路的语境中，延迟指的是传播延迟，但这个词也可以用于其他语境（例如，从一个终端主机到另一个终端主机跨越多个链路的延迟）。延迟本身没有正式的定义，具体含义取决于上下文。
时序图
假设有一条链路，带宽为 1 Mbps = 1 百万比特每秒，传播延迟为 1 ms = 0.001 秒。
我们要通过这条链路发送一个 100 字节（即 800 比特）的数据包。从第一个比特发送开始，到最后一个比特被接收，总共需要多长时间？
为了回答这个问题，我们可以画一个时序图。左边的竖线代表发送方，右边的竖线代表接收方。时间从 0 开始，向下逐渐增加。
让我们关注第一个比特。链路上每秒可以传输 1,000,000 比特（带宽），所以将一个比特放到链路上需要 1/1,000,000 = 0.000001 秒。在 0.000001 秒时，链路上有一个比特，位于发送方一端。
这个比特沿链路传输需要 0.001 秒（传播延迟），所以在 0.000001 + 0.001 秒时，第一个比特到达接收方。
现在让我们考虑最后一个比特。如前所述，放置一个比特到链路上需要 0.000001 秒。我们要发送 800 个比特，所以最后一个比特被放到链路上的时间是 800×0.000001 = 0.0008 秒。
这个最后一个比特沿链路传输需要 0.001 秒，所以在 0.0008 + 0.001 秒时，最后一个比特到达接收方。此时我们可以说数据包已经到达接收方。
数据包延迟
更一般地说，数据包延迟是指整个数据包从第一个比特被放到线路上开始，到最后一个比特在另一端被接收所花费的时间。这个延迟是传输延迟和传播延迟的总和。
传输延迟表示将所有比特放到线路上所需的时间。在上述例子中，传输延迟是 800×(1/1,000,000)。一般来说，传输延迟等于数据包大小除以链路带宽。
由于传输延迟是带宽的函数，我们可以用链路的两个属性（带宽和传播延迟）来计算数据包延迟。
带宽和传播延迟的权衡
考虑两条链路：
链路 1 的带宽为 10 Mbps，传播延迟为 10 ms。
链路 2 的带宽为 1 Mbps，传播延迟为 1 ms。
哪条链路更好？这取决于你要发送的数据包。
假设我们要发送一个 10 字节的数据包。对于这两条链路来说，将一个数据包放到线路上的时间可以忽略不计，传播延迟是主要的延迟来源。链路 2 的传播延迟更短，所以它是更好的选择。
假设我们要发送一个 10,000 字节的数据包。这时，传输延迟是主要的延迟来源，我们会更倾向于选择链路 1，因为它能更快地将字节放到线路上（更高的带宽）。你可以通过正式的数据包延迟计算来验证这个直觉：链路 1 发送这个数据包大约需要 18 ms，而链路 2 大约需要 81 ms。
举一个现实世界的例子，考虑视频通话。如果视频质量很差，可能是带宽不足（缩短传播延迟也无济于事）。相反，如果你说话到对方回应之间有延迟，可能是传播延迟太长（增加带宽也没用）。
管道图
到目前为止，我们一直在用时序图来表示网络事件的发生时间（例如，接收方收到数据包的时间）。
另一种查看数据包在网络中传输的方式是绘制某一冻结时刻链路上的比特。这两种视图传达的信息相同，但在不同的语境下，一种视图可能比另一种更有用。
为了绘制链路，我们可以把链路想象成一根管道（类似于前面的水管道类比），并将管道画成一个矩形，其中宽度代表传播延迟，高度代表带宽。管道的面积就是链路的容量。
假设我们要通过链路发送一个 50 字节的数据包。在管道视图中，我们可以展示一个冻结时刻，数据包正在沿链路发送。
数据包被排列成一个矩形，矩形的高度表示在一个时间步长内放到线路上的字节数。在每个时间步长，数据包在管道中向右移动。最终，数据包开始离开管道，并且在每个时间步长，矩形的一列会离开管道。
一个不明显的事实：时序图中的数据包传输延迟对应于矩形的宽度。
为了理解这一点，假设我们有一条链路，每秒可以发送 5 比特，我们有一个 20 比特的数据包。在时序图中，第一个比特和最后一个比特被发送的时间间隔是 4 秒。
在管道图中，每秒有一列 5 比特进入管道。我们需要 4 列进入管道，这需要 4 秒。这意味着管道中数据包的宽度是 4 列，即 4 秒。
管道图让我们能够在与传播延迟相同的轴上查看数据包传输时间，并对这两个术语进行比较。
管道图有助于比较不同的链路。让我们看看完全相同的数据包通过三条不同链路的情况。
如果缩短传播延迟，管道的宽度会变窄。管道的高度保持不变，每个矩形数据包的形状也不变。（记住，你可以把数据包的高度看作每个时间步长进入管道的比特数，把数据包的宽度看作将所有比特送入管道所需的时间。）
这里还有其他观察结果：数据包宽度不变意味着传输延迟没有变化。此外，链路的面积减小，这表明链路的容量变小。
当我们增加带宽时，管道的高度会变高，这表明我们每单位时间可以将更多的比特送入管道。
注意，数据包的形状也发生了变化。现在的数据包更高，因为我们每单位时间可以将更多的比特送入管道。因此，我们能更快地将整个数据包送入管道，所以数据包的宽度（传输延迟）减小了。
过载链路
考虑这张数据包到达交换机的图片。交换机需要将所有数据包沿输出链路转发。在这种情况下，没有问题，因为交换机有足够的容量处理每个到达的数据包。
那张图片的情况呢？
从长期来看，我们有足够的容量发送所有输出数据包，但在这个瞬间，有两个数据包同时到达，而我们只能发送一个。这被称为瞬时过载，在互联网的交换机中极为常见。
为了应对瞬时过载，交换机维护一个数据包队列。如果两个数据包同时到达，交换机将其中一个排队，然后发送另一个。
在任何给定时间，交换机可以选择从一条输入链路发送数据包，或者从队列中发送数据包。这个选择由分组调度算法决定，我们将在后面看到许多不同的设计。
当没有输入数据包时，交换机可以清空队列，发送所有排队的数据包。
这使得队列能够帮助我们吸收瞬时突发流量。
如果输入链路是这样的呢？
现在我们遇到了持续过载。输出链路的容量不足以支撑输入流量的水平。
我们可以把队列填满，但这仍然不足以支撑输入负载。无论如何，交换机都会丢弃数据包。
如何解决持续过载？运营商需要合理配置他们的链路和交换机。如果他们发现某个交换机经常过载，可能会决定升级链路（这可能需要人工操作）。
解决过载的一个可能方案是让路由器告诉发送方减速。（我们将在后面学习拥塞控制时详细研究这一点。）不过，最终我们对解决过载问题能做的有限，这就是为什么互联网被设计为只提供尽力而为的服务。
既然我们已经了解了排队的概念，我们需要回过头来更新数据包延迟公式。现在，数据包延迟是传输延迟、传播延迟和排队延迟的总和。
（注：文档部分内容可能由 AI 生成）