小智 51
带宽是可以通过"通道"传输的最大数据量.
吞吐量是指实际通过"通道"成功传输的数据量.这可能受到大量不同事物的限制,包括延迟和您正在使用的协议.
- 听起来带宽是您收取的费用，但吞吐量是您实际获得的。 (7认同)
- 那么,带宽是理论上的,吞吐量是实际的吗？ (6认同)
- 延迟如何影响吞吐量？ (2认同)
eRa*_*ToX 45
虽然这个问题的答案已经很少,但我认为有些人可能会怀疑实际上可视化不同的b/w 吞吐量和带宽 ,就像我一样 ;)直到我读到这个类比的quora(完全信用),这证明了真有帮助
考虑
一条高速公路,一次可以移动200辆车
但
在一个随机的时间,有人会注意到,比方说,有150辆汽车穿过它.
因为介于两者之间的交通堵塞...
即
容量是200但不是所有时间都被充分利用,实际流量只有150,最多200.
即 带宽是每单位时间200,但实际吞吐量仍为150 ......
我认为这可能对某人有所帮助......
小智 17
链路的带宽是可以通过该信道发送的理论最大数据量,而不考虑实际考虑因素.例如,您可以通过Cat-6e或光缆在千兆以太网链路上每秒泵送10 ^ 9位.不幸的是,这将是一个完全无格式的比特流.
为了使其实际有用,在任何实际数据位之前存在帧序列的开始,在结束时用于错误检测的帧校验序列和在传输帧之间的空闲时段.所有这些都占据了所谓的"位时间",意味着在线路上传输一位所需的时间.这是所有必要的开销,但是从链路的总带宽中减去.
这仅适用于将原始数据填充到线路上的最低级别协议.一旦开始添加MAC地址,IP标头和TCP或UDP标头,您就增加了更多的开销.
查看http://en.wikipedia.org/wiki/Ethernet_frame.其他传输媒体也存在类似的问题.
use*_*768 12
作为类比，将水管视为通道。管道直径对应于带宽或容量，管道内容对应于吞吐量或使用量。在下图中，我们可以看到三个管道（或通道），所有这些管道都未得到充分利用，因此，无需使用更大的管道即可增加使用量。
这是另一个示例，可帮助您想象根据情况可能会有什么不同。
想象
- 您有一个 1 MB 的文件（比如一张照片），您想与 3 个朋友分享。
- 然而，他们每个人都使用不同的云存储应用程序——Google Drive、Microsoft OneDrive 和 Dropbox。因此，他们都创建了一个文件夹并授予您访问权限，以便您可以将文件上传到他们的文件夹。
- 您在浏览器中打开这三个文件夹的 URL（比如在 3 个不同的选项卡中）并将文件（或多或少同时）拖放到每个选项卡上，以便上传。
- 您通过光纤电缆连接到 Internet，这使您能够以每秒 1 Gb 的速度进行传输（即这是您的带宽- 您可以利用您的连接的最大容量）。
知道，理论上（假设没有数据丢失，没有大的协议开销，连接到云存储服务提供至少相同的带宽等）你可以通过 1 Gbps 连接传输一个 1 MB 的文件大约：1MB / 1 Gbps = 1 x 10 ^3 x 8 / 1x10^9 这给出了大约 8x10^-6 秒或大约 10 毫秒。现在，您有 1 个文件要上传到 3 个目的地，您的连接带宽足够大，因此您可以同时将同一个文件传输到 3 个目的地（我们也可以假设您有一台配备多核的现代笔记本电脑CPU，因此可以并行完成通过 3 个连接到 Google Drive、MS OneDrive 和 Dropbox 的数据传输）。因此，无需等待 30 毫秒将同一文件传输到 3 个不同的目的地，您只需等待 10 毫秒，因为您拥有非常好的带宽。
现在让我们考虑正在使用什么协议以及它带来的影响。当您使用浏览器上传文件时，所使用的协议是运行在 TCP 协议之上的 HTTP/S。TCP 协议的一个重要特性是它确保在发送下一批数据之前，一批数据已成功到达任何目的地。这是由 TCP 发送方等待确认（简称ACK) 表示在开始发送第二批数据之前已经接收到第一批数据。这意味着，如果向一个方向传输 1 批数据需要 0.5 秒，然后收到 ACK 需要 0.5 秒，那么您需要等待 1 秒，直到 1 批数据传输并成功确认已收到（再次，假设没有数据丢失，因此无需重新传输同一批）。由于 TCP 协议需要此往返行程，因此似乎存在阻止程序。拦截器是您在一次往返中遇到的延迟，包括传输 1 批数据及其成功确认。考虑到这一点，我们需要看看一批数据有多大。这可能会有所不同，但通常为 64KB。所以你到 1 个目的地的实际流量（即吞吐量) 受此延迟（即等待时间）和批量大小的约束，如下等式：
throughput = batch size / latency
在我们的示例中，吞吐量为 64KB/s，由于我们可以将 1 MB 拆分为大约 15.6 个 64KB 大小的批次，因此传输 1 MB 文件需要大约 15.6 秒。与我们早期所做的仅基于带宽的计算相比，这是一个重大的放缓。