目录
除了上篇提到的RTT与丢包率，大多数人更关心的也许是网络的带宽（Bandwidth，Bw），毕竟电信、联通等公司广告主打的就是一个百兆、千兆带宽，听着嘎嘎猛。
很自然的一个认知是，带宽好的链路在同样的数据源与流控策略的前提下，相对RTT也丢包率也会更好。但深究一下原因又会觉得模糊，本文便从带宽的概念开始详细解释下上面问题的原因。
带宽
此带宽非彼带宽，作为信电系出身的我，之前常用的带宽表示无线信号对应的频带宽度，而在网络传输的数字信号中，带宽是指单位时间内链路能够通过的数据量。即发端到收端单位时间内能够交付的最大数据量（最大吞吐量）。
对于一个固定的发送端和接收端而言（暂时不考虑中间路由器交换机等设备的中转，当做一个非共享介质的单个数据链路传输），Bw主要受限于客观物理因素，即具体传输链路能够实现的最大传输速率，这一最大传输速率又受限于发送端和接收端的最大交付/接受能力。举个例子，假设发端能够将数字信号转换为模拟信号交付到数据链路中的最快速度为\(v_{send}\)，单位是Bytes/s，收端能够从数据链路中将模拟信号转换为数字信号反馈给上层的速率为\(v_{recv}\)，如果\(v_{send} \ge v_{recv}\)，那么收端的接收速率为\(v_{recv}\)，因为有处理不完的数据源源不断到达，收端可以以最大的速率处理并向上交付数据，反之，如果\(v_{send} < v_{recv}\)，那么收端的接收速率为\(v_{send}\)，因为收端的处理能力超过的数据到达的速度，发端发送的速度决定了整个链路的传输上限。因此可以认为：
\[Bw = \min(v_{send},v_{recv}) \]在将两个固定IP之间的传输路径中所有中转节点考虑进来后，带宽即变为了发端、收端以及路径中所有节点加在一起，交付速率最慢的一个，就像一根长长的水管，有的地方粗，有的地方细，水管流出的最大速率受限于最细的那个地方。所以当你开通了千兆带宽又访问网页很慢的时候，先别着急喷垃圾电信（手动狗头）。
上面的场景只考虑了一个发送端-接收端的场景，实际上很多网络链路中都是有多个用户在同时传输的。以家庭最常见的WiFi场景为例，当你家人开始刷抖音的时候，你的游戏很可能就会出现卡顿了，假设你独享WiFi的带宽为\(Bw_{along}\)，在另一个使用相同传输策略的终端接入后，你就很难有\(Bw_{along}\)甚至\(Bw_{along}/2\)的传输体验了，WiFi的监听退避机制以及拥塞控制的策略能够尽量避免链路的丢包和拥塞，但也会导致你损失一部分传输体验。这时，能让你稳定以接近\(Bw_{along}/2\)的速率进行传输已经成为了传输流控策略的优化目标。
带宽和延时、丢包的关系
开头提到“带宽好的链路在同样的数据源与流控策略的前提下，相对RTT也丢包率也会更好”，结合上一篇中RTT和丢包率的定义，就可以知道在带宽较低的链路中，如果发送策略过于激进，或者是有其他的用户加入传输，导致数据进入链路的速度大于带宽，那么数据就会在链路中发生堆积（在收端或者中间节点的缓存队列中），那么这里的排队时延就会逐渐增高，即链路的时延/RTT会发生增长。当堆积进一步加重，缓存已经堆满时候，链路就发生了拥塞，新到达的数据会发生丢失，即产生拥塞丢包。上述的场景常常发生在网络带宽较差或不稳定的用户身上，而对于那些网络带宽较大的用户，即使发生了用户数目波动或者数据源发送激进，也很难超过剩余的带宽大小，用户依然能够以低延时零丢包体验网络服务。
带宽的估算方法
这个坑留在后面CC的时候再填，在实际应用场景中，最简单的方法就是对一段时间（记为t）内被ACK的所有数据包大小进行求和（记为D），\(D/t\)就是这段时间采样得到的接收速率，或者是数据成功交付的速率，随着时间的推移持续对该值进行采样，采样得到的最大值就是最靠近带宽的值。（比较简单、实用但不准确的方法）
小结以及一些值得注意的点
本文对网络传输中的带宽进行了解读，结合延时与丢包，网络画像的基本要素已经相对齐全了，即将踏上进阶之路。
一些值得注意的点
- 带宽并不是发送速率的上限，发送速率是可以超过带宽的，而长期超过带宽的代价就是上文的拥塞；
- 数据成功交付的速率的上限是带宽；
- 想到了再回来补充...
本文来自博客园，转载请注明原文链接：https://www.cnblogs.com/mapleumr/p/17464980.html
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。
标签：带宽,发送,传输,谈谈,Bw,链路,速率 From： https://www.cnblogs.com/mapleumr/p/17469513.html