这是一个活跃的研究领域。我碰巧在这方面做了一些工作，所以我会分享我能分享的基本想法（这项工作是与行业合作伙伴合作的，我不能分享秘密细节:)）。

tl; dr 通常可以将加密的流量流识别为携带视频，并且通常可以估计其分辨率 - 但它很复杂，而且并不总是准确的。有很多人正在研究如何更一致、更准确地做到这一点。

视频流量有一些特定的特征，可以将其与其他类型的流量区分开来。在这里，我专门指的是视频点播——而不是直播视频。视频点播通常没有此答案中提到的那些优先级标签。另外我特指的是自适应视频，意思就是把视频分成几段（每段长约2-10秒），每段视频都经过多个质量等级编码（质量等级含义：长期视频码率、编解码器、和分辨率）。当您播放视频时，下载下一段的质量级别取决于应用程序认为您的网络可以支持的数据速率。（这就是这个答案中提到的 DASH 协议。）

如果您的手机正在播放视频，并且您查看一段时间内流向您手机的流量的（加权移动平均）数据速率，它可能看起来像这样：

（这是从 Verizon 上的 YouTube 会话中捕获的。有超过 15 秒的移动平均线和短期平均线。）

本次会议有几个不同的部分：

首先，视频应用程序（YouTube 播放器）尝试将缓冲区填充到缓冲区容量。在此期间，它以网络可以支持的任何速率提取数据。在这个阶段，它基本上与大文件下载没有区别，除非您可以推断它是来自远程地址的视频流量（如this answer中所述）。

一旦缓冲区已满，您就会定期获得“突发”。假设您的缓冲区可以容纳 200 秒的视频。当缓冲区中有 200 秒的视频时，应用程序将停止下载。然后在一段视频播放后（比如 5 秒），缓冲区中又有空间，所以它会下载下一段，然后再次停止。这就是导致这种突发模式的原因。

这种模式是视频的特征——来自其他应用程序的流量没有这种模式——因此网络服务提供商可以很容易地挑选出承载视频流量的流量。在某些情况下，您可能永远不会观察到这种模式 - 例如，如果视频太短以至于整个内容一次加载到缓冲区中，然后客户端停止下载。在这种情况下，很难将视频流量与文件下载区分开来（除非您可以通过远程地址弄清楚）。

无论如何，一旦您将流识别为承载视频流量 - 通过远程地址（并非总是可能，因为主要视频提供商使用并非视频专有的内容分发网络）或其流量模式（如果视频会话是可能的）长，如果它太短以至于整个视频一次都加载到缓冲区中，那就更困难了）...

现在，正如Hector 所说，您可以尝试通过查看每个“突发”数据的大小（以字节为单位）来猜测比特率的分辨率：

根据每个持续时间的大小，您可以对分辨率做出合理的估计 - 特别是如果您保持滚动平均值。

但是，这可能很困难。以我的示例中的 YouTube 会话为例：

• 并非所有片段的持续时间都相同 - 一次请求的视频持续时间取决于几个因素（质量水平、网络状态、您正在播放视频的设备类型等）。所以你不一定能看到“突发”然后说，“好吧，这是代表 5 秒视频的 X 字节，所以我知道视频数据速率”。有时您可以计算出可能的分段持续时间，但有时这很棘手。
• 对于给定的视频质量级别和片段持续时间，不同的片段将具有不同的大小（取决于视频的该部分中发生了多少运动）。
• 即使对于相同的视频分辨率，长期数据率也会有所不同——使用 VP9 编码的 1080p 视频不会具有与使用 H.264 编码的视频相同的长期数据率。
• 视频质量级别根据感知的网络质量（网络服务提供商可见）和缓冲区状态（不可见）而变化。因此，您可以查看超过 30 秒的长期数据速率，但实际视频质量水平可能在 30 秒内发生了多次变化。
• 在缓冲区尽可能快地耗尽或填充期间（当您没有那些“突发”时），估计视频中发生的事情要困难得多。
• 更复杂的是：有时视频流会在多个低层流中“条带化”。有时会从一个地址检索部分视频，然后会切换到从另一个地址检索视频。

我在上面向您展示的数据速率图？以下是该时间间隔内的视频分辨率：

这里，颜色表示视频分辨率。所以...你可以从流量模式中估计出正在发生的事情。但这是一个难题！您可以查看流量​​中的其他标记。我不能确切地说任何一家服务提供商是如何做到的。但至少就学术最先进的情况而言，没有任何方法可以始终以完美的准确性做到这一点（除非你有视频提供商的合作......）

如果您有兴趣了解有关用于此类问题的技术的更多信息，请参阅大量学术文献 - 例如，请参阅BUFFEST：Predicting Buffer Conditions and Real-time Requirements of HTTP(S) Adaptive Streaming Clients as a初始点。（不是我的论文——只是我最近读过的一篇。）

除了流式视频，没有什么能以一致的速率最大化带宽。

此外，为了确保优先处理流（而不是像下载大文件那样），流源以一种告诉运营商它是流视频的方式标记数据包。数据包的其余部分是加密的，但是告诉 ISP 如何路由它的元数据可以看到这部分。如果他们不这样做，那么当 ISP 试图平衡当时网络流量的所有需求时，流很可能会被中断或降级。

Verizon 说他们会这样做：

Verizon 本身显然不会将视频转换为较低的分辨率。相反，它将设置视频应用程序必须调整的带宽限制。“我们通过将速度设置为不超过 10Mbps 来管理高清视频吞吐量，这可以提供高达 1080p 视频的高清视频，”Verizon 告诉 Ars。Mbps 可能会低于 Verizon 将视频限制为 480p 或 720p 的情况。

这意味着订阅者和流量以某种方式形成的事实，因为它是某种类型的视频，这意味着它被标记了。

如何？Verizon 有一个视频优化系统，即使在 2017 年 8 月宣布新上限之前，该系统已被证明可以将 Netflix 和 YouTube 限制为 10 Mbps。

Verizon 承认使用了新的视频优化系统，但表示这是临时测试的一部分，不会影响视频的实际质量。视频优化似乎适用于无限和有限的移动计划。

但一些 YouTube 用户报告视频质量下降，称使用 VPN 服务可以绕过 Verizon 限制。

这表明 Verizon 能够识别视频流并相应地限制带宽，即使内容是通过 HTTPS（而不是 VPN）交付的。

Schroeder 几乎可以肯定是正确的，因为它只是一种营销方式，说他们将带宽限制到某些站点的 IP 地址或在数据包上寻找优先级标记。

然而值得注意的是，如果唯一的目的是在视频流式传输时强制用户达到特定分辨率，那么理论上有一些方法可以让这项工作变得更好。

如今，许多互联网流媒体使用称为 DASH（HTTP 上的动态自适应流媒体）的过程。它的工作方式是请求一小块视频，在下载时测量带宽，并以允许在第一个块完成时及时接收的分辨率/压缩方案选择下一个视频块玩。

这意味着请求中有关于用户正在做什么的提示。如果您的设备每 3 秒向一个网站发送一个请求，请求一个下载时间不到 3 秒的文件，那么该网站很有可能正在流式传输视频。根据每个持续时间的大小，您可以对分辨率做出合理的估计 - 特别是如果您保持滚动平均值。然后，您可以将带宽限制为该 IP 地址。

通过在决策权重中使用主要视频提供商（googlevideo (youtube)、Netflix 等）的已知 IP 地址，您可以使算法更具侵略性，而不会出现太多误报。

最重要的是您连接的地址。HTTPS 保护传输中的数据，但不保护您正在与之交谈的地址。如果 Verizon 知道 Netflix 服务器的 IP 地址，他们可以限制来自特定范围内的这些 IP 的数据流。然后，Netflix 将根据可用带宽自动调整其播放。

基于具有小于最大可能的恒定数据速率的流量也可以广泛地注意到。这可能意味着某种类型的媒体流，尽管它也可能是带宽受限的文件传输，因此会有一些误报。

我相信在他们宣布更改时提到的技术细节中，他们只是计划使用 IP 地址来设置限制，但我不确定这是否会随着时间的推移而改变，或者我什至没有正确地记住它有自宣布以来已经有一段时间了，我没有记录我关于它的原始研究。