我有一个使用 ADSL 技术的电视服务。这意味着我的电视基本上通过互联网传输所有内容。
今天有人告诉我，这至少需要 1MB/s 的上行链路才能工作。对吗？
注意，我指的不是带宽下降，带宽下降会高得多。这是向上，换句话说，我的电视提供商的机顶盒至少需要 1MB/s 的上传容量才能实现 2-3MB/s 的流速（我猜测是这样的）。
它发送了什么？ACK？
答案1
这取决于流媒体协议，但它可以发送确认、重传请求、客户端质量报告、播放命令（播放/暂停/倒带）以及更改流比特率以更好地适应网络条件的请求。
这些都无法达到持续 1Mbps 的数据速率，所以它们可能要求的速率超过了实际需要，希望有了额外的空间，其他流量就不会引发拥塞和缓冲区膨胀，从而干扰流媒体服务的流畅播放和运行。
答案2
如果不知道机顶盒的具体型号以及它与电视提供商交互时使用的协议，就不可能知道，确切地，它正在使用该带宽。但是，我们可以根据您收到的服务做出一些有根据的猜测。
第一的，任何正如您所猜测的，数字视频协议将具有某种形式的“ACK”来指示成功接收数据。数字视频不是单向协议；为了保持数据包有序并保持视频流同步（以确保视频播放器播放视频的速度不会太快或太慢），双方经常向对方发送计时数据。丢弃的数据包将根据某种算法进行处理，以确定是否有时间重新发送数据包，或者只是切断视频并继续播放。它也可能愿意尝试解码和播放不完整的数据并接受可能因此发生的任何损坏（这就是为什么无线数字电视有时会出现此问题的原因）。
任何基于订阅的电视服务还应提供以下服务：
- 某种形式的验证确认您是已注册的付费客户，并具体识别你（订户）与其他人不同。该服务不是匿名的，因为您可能有一个“订阅频道包”，并且您只能获得您付费的频道。
- 以某种形式跟踪您观看的频道和时间。这可能是一种不频繁的信号，例如“当用户切换频道时，告诉提供商我们现在正在观看哪个频道”。无论提供商选择使用这些数据用于营销目的由他们决定，但无论如何都必须提供给他们，这样他们才知道要将哪个频道的视频流发送给您！
- 某种形式的活动跟踪，当您按下遥控器上的按钮时会通知提供商。作为一种改进用户界面的方式，这种做法正变得越来越普遍：他们将收集最难完成的任务的数据，并尝试在未来的更新中使其变得更容易。他们可能会删除很少使用的选项。
- 信号质量数据：如果信号频繁中断，STB 可能会告知提供商，这可以自动提醒技术人员进行调查，以确定他们这边是否有问题。或者，他们可能会提供更可靠的低质量流媒体（例如，从 1080p 平稳降级到 720p）。
- 诊断数据：您的 STB 可能会偶尔上传有关其正常运行时间、可用资源（例如存储空间和 RAM）以及任何软件崩溃的日志的数据。
1 Mbit/s 听起来可能很多，但常规 HTTP 请求（此服务可能会使用也可能不会使用）的名义开销约为2%他们对 1 Mbit/s 的估计可能基于：
- 拥有足够的带宽来传输调试日志（可能达到几兆字节）等内容，以便能够快速上传，无论哪个进程发送它们都不会超时。也许它只允许 60 或 90 秒的时间来完成该过程，然后就会放弃。
- 线路信号减弱可能意味着已配置1 Mbit/s 实际上递送大约是这个数字的一半，甚至更少，而且 ISP 可能没有动力去改善这一点。理想情况下，即使在如此恶劣的条件下，你的电视仍能正常工作，因此即使他们严格只需要 512 Kbit/s，要求 1 Mbit/s 也会给他们留下误差空间。
- 电视流媒体期间的正常运行可能会消耗少得多的带宽，但 1 Mbit/s 可能是“最坏的情况”，例如如果您经常使用遥控器、频繁切换频道、查看电视指南等 - 他们希望确保您的连接可以处理所有这些，而不会上行过于拥挤和超时。
- 如果 ADSL 线路与其他设备共享（尤其是计算机，其上传原因比电视机顶盒多得多），您将需要用户线路上有足够的上行容量。相对于当今的大多数事物而言，1 Mbit/s 的速度非常低。
视频协议的开销实际上可能远高于 2%。加密（双向）可能会增加几个百分点。也许每个数据包的大小都非常小，这会增加总体开销，因为您将拥有更多数据包，并且每个数据包都具有与之关联的元数据。所有这些都涉及一点上游，最终会累积起来。
总的来说，无法确切知道他们为什么认为您的电视机顶盒需要 1 Mbit/s 的上行速度，但这可能只是猜测，或者基于测试表明某些操作需要少量上行突发，并且必须达到一定的速度才能获得不错的性能（例如，每次机顶盒必须与提供商中心局重新协商加密层时，用于验证您的机顶盒的初始握手可能需要突发）。
我怀疑他们使用不过，在正常流式传输视频时，速度稳定在 1 Mbit/s。对于任何合理高效的视频流式传输协议来说，视频的质量和比特率都必须非常高，才能持续要求如此高的上行速率。
答案3
以太网上的 Ack 数据包大小至少为 64 字节，典型的 PPPoA DSL 部署中的“加载”下行数据包大小通常为 1492 字节。
RFC1122 规定“在一系列全尺寸段中，至少每隔一个段应该有一个 ACK”。
因此，您的最小确认带宽比率为 64/(1492*2) = 2.15%，或者每接收 1MB 需要 22,490 字节的确认，或者每下载 5Mbps 的比特率大约为 110kbps（0.1Mbps）。
出于某种原因，我认为他们想要你的上行带宽。
如果它们的“流”以唯一标识的数据块形式交付，那么让设备缓存所有下载的块并充当分布式存储将是一件轻而易举的事情。对于实时流来说，这很困难，因为数据块只有一个原点，但通过为每个流查看客户端提供一个随机的“块偏移”起点（相当于 0-30 秒的广播延迟），客户端需求可以分散到一系列块中，并且可以利用客户端将块重新分配给其他客户端。控制服务器可以智能地管理块可用性，新块首先推送到具有最高上传带宽的客户端，然后指示这些客户端依次将数据推送到另一层客户端。
如果设备具有中等本地存储空间（64GB），那么针对最近播放的内容的 VoD/PVR 服务将很容易实现，而且对提供商来说几乎不需要任何带宽成本。将指示各个设备根据需要保留或删除流块，以根据预测/测量的需求在整个分布式存储网络中保持足够的块可用性。只需请求相关块并执行一些本地缓存即可实现播放，并有中央服务器在需要时保证可用性。