19、IPTV与对等网络电视广播系统剖析

IPTV与对等网络电视广播系统剖析

1. IPTV 与安全

当前的广播采用 ARIB STD B25 数字版权管理（DRM）内容保护技术。该技术利用条件访问系统（CAS）对客户端进行身份验证并对内容进行解扰。构建 IPTV 内容保护系统主要有两类方式：
- 通过认证、授权和计费（AAA）服务保护网络访问。
- 通过证书认证（CA）或 DRM 方法保护媒体本身。

所有用户的访问都会连接到用户管理系统（SMS）和计费服务器（BS），以请求对每个 IPTV 用户的访问计费。接收媒体后，DRM 会控制媒体的存储、重新分发到其他编解码器以及传输到其他显示设备的过程。

在 IP 基础设施中，通常期望在选择频道后能立即观看内容，例如频道切换。因此，使用与广播方法兼容的限时许可方式是比较理想的。

2. 传统 IP 组播服务架构的问题与特点

由于视频压缩算法、处理器、CPU 容量和硅内存等方面的快速显著技术改进，我们可以在普通 PC 平台上享受高质量的视频播放和处理，无需特殊硬件或加速器。然而，过去专业提供商在向大量客户进行实时视频交付时遇到了以下技术难题：
- 质量方面 ：每个客户可用或可承受的带宽为 100 - 300 Kbps。当可用带宽为 300 Kbps 时，即使使用最新的视频压缩技术，视频图像质量仍比传统模拟电视节目或录像带视频（如 VHS）差。
- 数量方面 ：最大客户数量为 1000 - 10000。这远小于传统广播系统的能力。这种系统特点是由于使用了传统的内容分发网络（CDN）技术或传统单播技术。

2.1 基于单播的组播

每个客户端节点使用单播传输服务直接从服务器节点接收数据。
- 优点 ：
- 无需任何特殊设备、软件或配置。因为许多应用都使用单播数据包传输，互联网服务提供商（ISP）无需在其网络中安装特殊设备。
- 具备丢包错误恢复能力。TCP 可应用于基于单播的组播服务，提供商可以提供无错误的组播服务。TCP 为每个客户管理流量，其针对丢包的数据包重传能力可恢复传输错误。即使使用 UDP，许多使用 UDP 套接字的应用也会在服务器和客户端之间实现自己的错误检查和恢复功能。
- 适用于所有 ISP。单播 IP 数据包传输在几乎所有 ISP 中普遍可用，ISP 之间维持着全球通用的 IP 数据包交付。因此，无需关心客户端节点属于哪个 ISP。
- 实现和操作稳定。网络设备、客户端节点和服务器节点之间的互操作性已经很好地建立。网络运营商和家庭用户对单播通信的配置和管理也很熟悉。重要的是，使用单播服务时，网络中路由器的路由条目不受终端用户设备的影响。
- 与防火墙路由器和网络地址转换（NAT）路由器友好。许多安全软硬件产品熟悉单播通信，原因如下：
- 连接由客户端节点发起，而不是客户端到客户端或服务器到客户端。
- 服务器节点使用的 TCP/UDP 端口号通常是固定的。
- 缺点 ：
- 服务器所需带宽大 ：服务器节点必须向不同的目标客户端节点传输大量完全相同的数据。这意味着服务器所需的带宽与客户端节点的数量成正比。例如，对于 10000 个客户端节点，每个用户流量为 300 Kbps，服务器需要 3 Gbps 的带宽；对于 100000 个客户端节点，服务器必须提供 30 Gbps 的带宽。实际上，对于未来更大的带宽需求，单个站点无法提供。
- 网络所需带宽大 ：网络中的所需带宽资源是所有客户端流量的（带宽）×（传输距离）的总和。
- 频道切换响应慢 ：开始播放接收到的数据的延迟强烈依赖于客户端节点的初始缓冲量。当数据包传输抖动较大时，需要更大的初始缓冲。此外，当客户端提供无错误数据传输时，必须对丢失的数据包进行数据重传，这就需要相当大的初始缓冲。在许多单播实现中，初始缓冲时间可达几十秒。

2.2 IP 组播

在 IP 组播中，中间节点（即路由器节点）与服务器节点和客户端节点一样起着重要作用。即使客户端节点数量很多，服务器也只需发送一个 IP 数据包。中间节点运行与组播服务相关的多个协议（如 IGMP、DVMRP、PIM - SM），根据这些特殊协议获取的信息，适当的中间节点（即组播路由器和交换机）会对接收到的（组播）IP 数据包进行复制并转发。
- 优点 ：
- 服务器所需带宽稳定 ：即使客户端节点数量增加，服务器端所需的带宽也不会增加，甚至可能与客户端节点所需的带宽相同。
- 网络所需带宽小 ：由于 IP 数据包在中间节点（即组播路由器和交换机）进行复制，总的带宽资源通常比基于单播的组播小得多。
- 频道切换响应快 ：服务器不直接向客户端节点传输 IP 数据包。虽然 IP 组播系统可能难以实现无错误的数据交付，但系统无需运行错误纠正/恢复功能。而且，客户端节点的初始缓冲较小，因为初始缓冲仅与数据包传输抖动有关，而抖动通常不大。实际上，IP 组播系统中的频道切换延迟通常小于 1 秒。
- 缺点 ：
- 需要支持组播的设备和软件 ：IP 组播技术的研发已经进行了 20 多年，但 IP 组播网络的发展主要基于 M - Bone（一种使用 IP 隧道的覆盖网络），且主要在学术网络中，在商业 ISP 中并不常见。商业 ISP 犹豫引入 IP 组播服务的主要原因是并非所有设备都支持 IP 组播，并且 ISP 运营商需要进行一些额外的配置。如果 ISP 未开启 IP 组播，组播 IP 数据包将被丢弃。
- 难以提供无错误的数据交付 ：由于服务器不维护每个流的数据交付，IP 组播服务难以实现无错误的数据交付。为了提高组播数据包的质量，经常会应用数据包丢弃优先级控制和传输调度，但这仍不是真正的无错误。
- 难以实现跨 ISP 操作 ：当一个 ISP 未开启 IP 组播时，从相邻 ISP 接收到的 IP 数据包必须被丢弃。这意味着当客户端节点属于未开启 IP 组播的 ISP 时，服务器无法向该客户端节点提供 IP 组播服务。
- 操作和实现的稳定性问题 ：ISP 运营商最担心的是，在 IP 组播服务中，ISP 路由器中的路由条目会自然受到客户端节点行为的影响。根据客户端节点的加入和退出，（组播）路由条目会发生变化，这使得 ISP 运营商难以维持网络的操作和控制主动性。此外，ISP 运营商缺乏相关操作经验也是一个原因。
- 难以与防火墙和 NAT 路由器共存 ：许多防火墙路由器和 NAT 路由器不识别 IP 组播服务，未识别的路由器的默认行为是丢弃接收到的数据包。为了与这些路由器兼容，需要额外的设备或配置，如 IGMP 代理。

2.3 覆盖组播（OLM）

OLM 将对等（P2P）技术应用于组播服务。服务器将 IP 数据包传输给一些选定的客户端节点，这些选定的节点再将接收到的 IP 数据包转发给其他客户端节点。这种数据包转发算法可以递归应用，以适应大量客户端节点。OLM 系统中的数据包传输通常是单播。
- 优点 ：
- 服务器所需带宽恒定 ：在 OLM 系统中，服务器仅向选定的客户端节点传输数据。通过控制这些客户端节点的数量恒定，服务器所需的带宽可以保持恒定。
- 无需特殊设备 ：由于服务器 - 客户端和客户端 - 客户端之间的每个数据包传输都是单播，网络中无需特殊设备。
- 无错误数据包交付 ：客户端节点和服务器之间的数据包传输使用 TCP，可以实现无错误的数据包交付。
- 跨 ISP 服务交付 ：由于数据包传输是单播，服务可以轻松扩展到其他 ISP。
- 缺点 ：
- 频道切换延迟大 ：与基于单播的组播一样，OLM 系统在节点之间提供无错误的数据包交付，这意味着每个节点必须对丢失的数据包进行数据重传。为了执行数据包重传，需要相当大的初始缓冲。此外，OLM 需要额外的延迟来搜索负责数据包重传的节点。
- 服务稳定性差 ：由于 OLM 缺乏足够的操作经验，其操作稳定性和软件稳定性不如传统组播（即基于单播的组播和 IP 组播）。而且，由于 OLM 依赖于终端用户设备的合作，系统通常可靠性和稳定性较低。
- 网络资源使用效率低 ：当 OLM 数据包交付树的层次关系/拓扑与物理网络拓扑相同时，网络带宽资源使用效率最高。但当这些拓扑不同时，网络资源使用效率会很低。
- 与防火墙路由器和 NAT 路由器兼容性差 ：许多防火墙路由器和 NAT 路由器允许出站连接，但不允许入站连接，这可能会限制客户端之间的数据包传输。

下面用表格对比一下这三种组播方式的优缺点：
| 组播方式 | 优点 | 缺点 |
| — | — | — |
| 基于单播的组播 | 无需特殊设备、有丢包恢复能力、适用于所有 ISP、实现和操作稳定、与防火墙和 NAT 路由器友好 | 服务器和网络所需带宽大、频道切换响应慢 |
| IP 组播 | 服务器所需带宽稳定、网络所需带宽小、频道切换响应快 | 需要支持组播的设备和软件、难以提供无错误数据交付、难以跨 ISP 操作、操作和实现稳定性差、难以与防火墙和 NAT 路由器共存 |
| 覆盖组播（OLM） | 服务器所需带宽恒定、无需特殊设备、无错误数据包交付、跨 ISP 服务交付 | 频道切换延迟大、服务稳定性差、网络资源使用效率低、与防火墙路由器和 NAT 路由器兼容性差 |

2.4 对等网络电视组播系统的业务部署

TV Bank 公司（www.tv - bank.com）基于 OLM 技术为所有 ISP 提供电视组播服务。该公司提供内容交付技术并采购专业内容进行交付（即内容聚合），其提供的内容交付技术包括：
- 前端系统 ：从内容持有者处收集内容。
- 视频点播（VoD）内容交付系统 。
- 使用 OLM 技术的半实时组播内容交付服务，称为“BBbroadcast”系统。

2.5 BBbroadcast 系统

BBbroadcast 系统由 TV Bank 公司和 Roxbeam Media Network（中国）开发，由服务器和客户端软件组成。终端用户安装 BBbroadcast 的客户端软件以加入 OLM 网络，系统以直播流的方式提供具有电视质量的实时视频。流文件仅在内存空间中生成，不会在磁盘空间中生成，这对内容持有者和内容服务提供商来说是一个重要特性，并且其许多技术特性（如内容查询或缓冲）与许多非专业的文件共享应用（如 Winny）有很大不同。

2.5.1 服务器系统组件

服务器系统由以下三个组件组成：
- 包服务器 ：将原始内容提供给 BBbroadcast 网络。每个组播频道必须运行一个活动的包服务器。包服务器从 Windows 媒体服务器获取相应组播频道的媒体数据，并以 BBbroadcast 系统的数据格式传输数据。同时，该服务器会对 BBbroadcast 系统中的数据进行加密，以防止客户恶意使用内容数据。
- 交付支持服务器 ：将内容复制并转发给下游的交付支持服务器或客户端节点。包服务器是内容交付树的根，交付支持服务器是内容交付树中的中间节点。快速建立或配置最佳或合适的内容交付树是 OLM 系统高效运行的关键。
- 引导服务器 ：为新加入的客户端节点提供足够的信息。新加入的客户端节点登录引导服务器并获取合作伙伴列表，该列表包含一些交付支持服务器和其他客户端的信息，新节点应连接到这些节点。初始阶段过后，客户端节点会定期相互交换合作伙伴列表，并自主寻找更好的合作伙伴。

2.5.2 客户端软件组件

客户端软件由 BBbroadcast 模块（P2P 引擎）及其控制模块（Active X 控制）组成。当客户端节点访问内容交付网页时，网页发送的 JavaScript 会执行 BBbroadcast 模块。

由于 BBbroadcast 系统是一个依赖终端用户节点提供服务的 P2P 系统，为了提供足够健壮和稳定的服务，系统采用了以下技术：
- 网状拓扑网络 ：BBbroadcast 系统使用网状拓扑进行内容数据交付，而不是简单的树状拓扑。树状拓扑虽然在网络资源（即带宽）使用方面是最优和高效的，但存在单点故障问题。而网状拓扑网络可以避免单点故障，因为它为节点故障提供了多个（或替代）内容交付路径，但系统无法实现有效的资源使用。在 BBbroadcast 系统中，引入了许多优化机制来建立有效的网状拓扑，而不是效率极低的全网状拓扑。
- 本地缓存缓冲区 ：流文件仅在内存空间中生成，避免了在客户节点进行非法复制，这对内容持有者和内容服务提供商很重要。视频数据在 PC 的内存空间中进行缓冲，以实现 PC 之间的丢包重传。BBbroadcast 使用客户端节点之间的“逐跳”TCP，而不是内容服务器和客户端节点之间的端到端 TCP，以实现无错误的组播数据交付。本地缓冲区还在提高系统对短期网络故障的鲁棒性方面发挥重要作用。对于使用不稳定链接（如 ADSL 或 WiFi）的客户节点，在多播数据传输中会经历暂时的质量下降，即使在无线接入和有线接入之间进行节点切换时，本地缓冲也能提高客户端节点之间多播数据交付的质量。
- 双向数据传输 ：在传统 P2P 系统中，想要获取文件的客户端节点首先要解析包含目标文件的（目标）节点，然后访问目标节点请求文件传输，当目标文件所在节点位于 NAT 段时，需要使用特殊通信协议或在非 NAT 段安装代理节点，这称为单向数据传输。而在 BBbroadcast 中，由于是直播流系统，所有客户端节点基本拥有相同的数据，客户端节点只需找出可访问的、应具有目标数据的客户端节点，并且客户端节点之间的 TCP 会话没有方向之分。在日本，许多家庭用户使用 NAT 路由器连接网络，在这种环境下，传统 P2P 系统可能无法正常工作，但 BBbroadcast 系统即使在有大量 NAT 路由器段的情况下也能正常工作。
- 高速合作伙伴搜索/解析 ：当新客户端节点加入网络时，希望尽快连接到网络。系统会在引导服务器或已连接的客户端节点中提供有关接受入站连接的合作伙伴节点的提示信息，利用这些信息可以快速建立更好的网络拓扑。
- 混合 P2P ：在实际操作中，新加入的客户端节点通常需要较长时间才能找到合适的合作伙伴节点，或者新加入节点试图连接的节点可能会因客户端数量过多而过载。
- 服务安全 ：确保系统的安全性，防止数据泄露和恶意攻击。

下面是 BBbroadcast 系统客户端节点加入网络的流程图：

graph TD;
    A[新客户端节点加入] --> B[登录引导服务器];
    B --> C[获取合作伙伴列表];
    C --> D[连接到合作伙伴节点];
    D --> E[定期交换合作伙伴列表];
    E --> F[自主寻找更好的合作伙伴];

综上所述，不同的组播方式各有优缺点，在实际应用中需要根据具体需求和场景选择合适的组播方式。BBbroadcast 系统通过采用多种技术，在一定程度上解决了传统组播方式的一些问题，为对等网络电视组播服务提供了一种可行的解决方案。

3. BBbroadcast 系统技术详解

3.1 网状拓扑网络

在内容数据传输方面，BBbroadcast 系统摒弃了简单的树状拓扑，转而采用网状拓扑。树状拓扑虽然在网络带宽利用上达到了最优和高效，但它存在一个致命的弱点——单点故障。一旦树状结构中的某个节点出现故障，故障节点之后的整个内容传输系统都会陷入瘫痪。

与之形成鲜明对比的是，网状拓扑网络能够有效避免单点故障。它为可能出现的节点故障提供了多条替代的内容传输路径。不过，网状拓扑也并非十全十美，它在资源利用效率上有所欠缺。为了克服这一不足，BBbroadcast 系统引入了多种优化机制，旨在构建一个高效的网状拓扑，而非效率低下的全网状拓扑。

3.2 本地缓存缓冲区

BBbroadcast 系统的流文件仅在内存空间中生成，这一设计巧妙地避免了在用户节点进行非法复制，对于内容持有者和内容服务提供商而言，无疑是一颗“定心丸”。视频数据在 PC 的内存空间中进行缓冲，这一举措为 PC 之间的丢包重传提供了有力支持。

与 IP 组播使用 UDP 数据包传输难以实现无差错组播数据传输不同，BBbroadcast 系统在客户端节点之间采用“逐跳”的 TCP 协议，从而实现了无差错的组播数据传输。此外，本地缓冲区在提升系统对短期网络故障的抗干扰能力方面也发挥着关键作用。对于那些使用 ADSL 或 WiFi 等不稳定连接的用户节点，在多播数据传输过程中可能会出现短暂的质量下降情况。即便在无线接入和有线接入之间进行节点切换时，本地缓冲也能够显著提高客户端节点之间多播数据传输的质量。

3.3 双向数据传输

传统的 P2P 系统采用单向数据传输模式。当客户端节点想要获取某个文件时，它首先需要解析出包含目标文件的节点，然后向该目标节点发出文件传输请求。如果目标文件所在的节点位于 NAT 网段，就需要使用特殊的通信协议或者在非 NAT 网段安装代理节点。

而 BBbroadcast 系统则采用了双向数据传输模式。由于该系统采用直播流技术，所有客户端节点基本上都拥有相同的数据。因此，客户端节点只需找出可访问的、包含目标数据的客户端节点即可。而且，客户端节点之间的 TCP 会话没有明确的方向之分。在日本，许多家庭用户通过 NAT 路由器接入网络，在这种网络环境下，传统的 P2P 系统往往难以正常工作，但 BBbroadcast 系统却能够稳定运行，即使存在大量的 NAT 路由器网段也不受影响。

3.4 高速合作伙伴搜索/解析

当新的客户端节点加入网络时，它迫切希望能够尽快连接到网络。为了满足这一需求，系统会在引导服务器或已连接的客户端节点中提供有关接受入站连接的合作伙伴节点的提示信息。新节点可以利用这些信息，迅速建立起更优的网络拓扑结构。

3.5 混合 P2P

在实际运行过程中，新加入的客户端节点常常会面临一些问题。一方面，它们可能需要花费较长时间才能找到合适的合作伙伴节点；另一方面，新节点试图连接的节点可能会因为客户端数量过多而不堪重负，出现过载的情况。

3.6 服务安全

服务安全是 BBbroadcast 系统的重要组成部分。系统采取了一系列措施来确保数据的安全性，防止数据泄露和恶意攻击。例如，对传输的数据进行加密处理，对用户进行身份验证和授权等。

4. 不同组播方式对比总结

为了更清晰地展示不同组播方式的特点，下面用表格对基于单播的组播、IP 组播和覆盖组播（OLM）进行详细对比：
| 组播方式 | 服务器带宽需求 | 网络带宽需求 | 频道切换响应 | 设备与软件要求 | 错误数据交付 | 跨 ISP 操作 | 稳定性 | 与防火墙和 NAT 路由器兼容性 |
| — | — | — | — | — | — | — | — | — |
| 基于单播的组播 | 与客户端数量成正比，需求大 | 总和大 | 慢 | 无需特殊设备和软件 | 可实现无错误交付 | 可实现 | 稳定 | 友好 |
| IP 组播 | 稳定，不随客户端数量增加 | 小 | 快 | 需要支持组播的设备和软件 | 难以实现无错误交付 | 难 | 较差 | 差 |
| 覆盖组播（OLM） | 恒定 | 取决于拓扑匹配度 | 慢 | 无需特殊设备 | 可实现无错误交付 | 可实现 | 较差 | 差 |

从这个表格中可以看出，每种组播方式都有其独特的优势和劣势。基于单播的组播在实现和操作上较为稳定，与现有网络设备兼容性好，但带宽需求大且频道切换响应慢；IP 组播在带宽利用和频道切换响应方面表现出色，但对设备和软件要求高，且操作稳定性和跨 ISP 操作存在困难；覆盖组播（OLM）在服务器带宽和跨 ISP 服务交付方面有优势，但频道切换延迟大，服务稳定性和网络资源利用效率有待提高。

5. 结论与展望

综上所述，不同的组播方式在不同的场景下各有优劣。在选择组播方式时，需要综合考虑服务器带宽、网络带宽、频道切换响应、设备和软件成本、服务稳定性以及与现有网络设备的兼容性等多个因素。

BBbroadcast 系统通过采用网状拓扑网络、本地缓存缓冲区、双向数据传输、高速合作伙伴搜索/解析、混合 P2P 和服务安全等多种技术，在一定程度上解决了传统组播方式存在的问题，为对等网络电视组播服务提供了一种可行的解决方案。然而，该系统也并非完美无缺，例如在频道切换延迟和服务稳定性方面仍有改进的空间。

未来，随着网络技术的不断发展和用户需求的不断提高，组播技术也将不断创新和完善。例如，可能会出现更加高效的带宽利用技术，进一步降低服务器和网络的带宽需求；或者开发出更加智能的节点搜索和数据传输算法，提高频道切换响应速度和服务稳定性。同时，随着网络安全问题日益突出，组播系统的安全性也将成为未来研究的重点方向之一。我们期待着组播技术在未来能够为用户带来更加优质、稳定和安全的网络电视服务。

下面是一个简单的决策流程图，帮助在不同场景下选择合适的组播方式：

graph TD;
    A[选择组播方式] --> B{对带宽要求高?};
    B -- 是 --> C{需要快速频道切换?};
    C -- 是 --> D[IP 组播];
    C -- 否 --> E[覆盖组播（OLM）];
    B -- 否 --> F{对稳定性要求高?};
    F -- 是 --> G[基于单播的组播];
    F -- 否 --> H{跨 ISP 操作需求大?};
    H -- 是 --> E;
    H -- 否 --> D;

通过这个流程图，可以根据具体的需求和场景，快速选择合适的组播方式。在实际应用中，还需要根据实际情况进行进一步的评估和调整。