音频数据在传输时是“时间压缩的”。

想象一个携带 8 kHz 8 位 VoIP 数据的 800 字节 UDP 数据报。

回放时，800 个样本覆盖 1/10 秒（或 100 毫秒）。该数据报在线路上占用 800 + 8 + 20 + 38 = 866 个字节（有效负载 + UDP 开销 + IPv4 开销 + 以太网开销），或 6,928 位。使用快速以太网 (100 Mbit/s)，这些位只需 0.06928 毫秒即可传输，而不是它们所代表的 100 毫秒。

因此，单个 100M 接口可以同时处理 14,400 个此类流而不会丢帧。

（实际上 VoIP 数据包更小，增加了开销部分，但我想明白这一点。）

流媒体服务的另一点是存在延迟。

对于双向通话，他们会尝试将延迟控制在 1 秒以内，这样您就不会注意到。

对于实时事件的视频流，延迟可能很重要。有 1-2 分钟的延迟可以通过防止卡顿/缓冲来显着提高流的可靠性，但观众并不总是可以接受（想到体育赛事）。

HTTP 实时流 (HLS) 非常复杂。视频不是一个大的 TCP 流，而是分成许多小片段（对于“实时”流，每个片段可能是 10 秒）。观众下载它们并背靠背播放它们。如果在获取一个 10 秒的 URL 时出现问题，查看器可以冻结 10 秒然后继续下一个。

如果观看比直播延迟 60 秒，那么像 Akamai 这样的公司就有时间通过​​其全球缓存基础设施分发 10 秒的片段，从而允许观众从“关闭”的服务器下载以获得更好的性能。如果第一次下载失败，延迟还允许查看者尝试第二次下载，也许在“冻结”之前获取片段是必要的。这些片段还允许在中间开始观看现场活动，而无需下载整个节目。