37、网络服务质量与视频流复制方案解析

study

于 2025-10-10 15:27:32 发布

阅读量20

点赞数

CC 4.0 BY-SA版权

分类专栏：多媒体网络管理前沿文章标签： QoSJava 网络服务质量视频流复制

本文链接：https://blog.youkuaiyun.com/study/article/details/153440019

多媒体网络管理前沿专栏收录该内容

44 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

网络服务质量与视频流复制方案解析

1. QoSJava：端到端的服务质量解决方案

QoSJava 在网络服务质量保障方面发挥着重要作用。当设备驱动执行带有 #MODIFY_SERVICECLASS 指令的脚本时，该指令会被解析为一系列命令，以完成服务类别的修改任务。具体操作步骤如下：
1. 建立连接 ：利用操作系统提供的 Telnet 包 API 远程登录到路由器并建立连接（ @TELNETCONN ）。
2. 身份验证 ：向路由器传输密码进行身份验证，验证通过后使用 “enable” 命令提升管理员权限，并再次输入密码。
3. 修改服务类别 ：使用 “police” 命令设置相关参数，包括承诺信息速率（cir）、确认突发（bc）、峰值信息速率（pir）、超额突发（be）以及速率小于 cir 的数据包所附带的 dscp 值（ set-dscp-transmit ），同时表明速率大于 cir 的所有数据包将被丢弃。
4. 断开连接 ：任务完成后，断开与路由器的连接（ @TELNETDISC ）。这些命令会批量执行，避免管理员的干扰。

QoSJava 在网络的每个域中进行分布式部署，可由服务器群或具有强大计算能力的计算机承载。

2. QoSJava 的实现与实验结果

在相关实验中，构建了包含不同 QoS 机制（如 DiffServ 和 MPLS）以及来自不同厂商（Cisco、Juniper 和 HuaWei）网络设备的测试平台，部署了 20 多个路由器。用户通过网页订阅服务级别协议（SLA），技术参数会转化为资源需求，并由准入控制组件进行审核。审核通过后，QoS 机制适配器和设备驱动会根据域中的 QoS 机制和设备系列对网络设备进行配置。

使用 Agilent 的 RouterTest 仪器和 Iperf 作为流量生成器，模拟网络拥塞情况。RouterTest 以 171.24Mb/s 的速率生成 256kb UDP 数据包，使链路 172.16.4.0 拥塞；Iperf 向路由器 11.11.11.11 注入数据包，使链路/接口 172.16.12.0 拥塞。实验记录了拥塞情况下路由器接口的 CPU 利用率、带宽利用率和数据包丢失率等信息。

以下是不同服务等级下音频和视频服务的性能对比：
|服务类型|服务等级|丢包率|延迟和抖动|语音/视频质量|
| ---- | ---- | ---- | ---- | ---- |
|音频服务|黄金服务|约 2.6%|非常小|优秀|
|音频服务|青铜服务|约 40%|显著增加|语音不连续|
|视频服务|白银服务| - | - |优于青铜服务|
|视频服务|青铜服务| - | - |较差|

从实验结果可以看出，即使在具有异构 QoS 机制和网络设备的网络中，QoSJava 也能提供差异化的服务质量。

3. 部分视频复制的对等网络流方案

在对等网络（P2P）中进行视频流传输正受到越来越多的关注。传统的 P2P 视频流方案大多假设所有客户端都存储完整的视频，但实际上，客户端可能由于存储空间有限而只能存储部分视频，这带来了一系列挑战，例如如何确定一组对等节点是否足以流式传输视频、如何选择要存储的视频片段等。

为了解决这些问题，提出了两种方案：
- 非合作方案 ：节点之间不进行通信来确定要复制的片段。每个节点首先确定要存储的视频比例 fi ，并选择一个随机数种子 si 。如果 rand(si, j) <= fi ，则节点存储第 j 个片段。当节点发送流请求时，每个对等节点会返回 (fi, si) 对。请求节点需要选择一组对等节点来流式传输视频，目标是选择满足每个片段至少由一个对等节点存储且节点数量尽可能少的子集。具体步骤如下：
1. 广播请求消息，接收各对等节点的 (fi, si) 对。
2. 将 fi 按降序排序，选择最大的值，直到 M ∏i=k i=1(1 - fi) ≤ 阈值 。
3. 根据 (fi, si) 信息确定每个对等节点存储的片段。
- 合作方案 ：基于全局优化标准和效用函数来选择要存储的片段。效用函数 Um 是网络中所有片段效用的总和，片段 Si 的效用 vi 随着其副本数量的增加而缓慢增加。原始视频源维护片段向量 Cm ，每个节点根据效用函数确定要复制的片段。当节点加入或离开网络时，需要更新 Cm 。为了处理这些问题，为每个视频指定一个领导者，领导者维护 Cm 并处理更新和检索请求。具体步骤如下：
1. 领导者接收节点的 fi 值和请求，计算节点要复制的片段。
2. 更新 Cm 。
3. 当客户端请求视频时，领导者使用存储的本地向量 Dm 找到一组能够流式传输视频的对等节点。
4. 选择满足每个片段至少由一个对等节点存储且节点数量尽可能少的子集。

以下是合作方案中解决对等节点选择问题的伪代码：

Greedy-Set-Cover(X,F)
01 U ←X
02 C ←∅
03 while U ̸ =∅
04     select an S ∈F that maximizes | S ∩U |
05     U ←U-S
06     C ←C ∪{S}
07 return C

通过模拟实验对这两种方案进行评估，合作方案性能更好，但实现和维护难度较大；非合作方案实现简单，但性能相对较低。

下面是两种方案的对比流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([开始]):::startend --> B{选择方案类型}:::process
    B -->|非合作方案| C(确定fi和si):::process
    C --> D(广播请求消息):::process
    D --> E(接收(fi, si)对):::process
    E --> F(排序并选择对等节点):::process
    F --> G(确定存储片段):::process
    B -->|合作方案| H(领导者维护Cm):::process
    H --> I(节点发送fi和请求):::process
    I --> J(领导者计算复制片段):::process
    J --> K(更新Cm):::process
    K --> L(客户端请求视频):::process
    L --> M(领导者选择对等节点):::process
    G --> N([结束]):::startend
    M --> N

综上所述，QoSJava 为网络服务质量提供了有效的解决方案，而部分视频复制的对等网络流方案则为解决 P2P 网络中视频存储和传输问题提供了新的思路。不同的方案各有优缺点，在实际应用中需要根据具体需求进行选择。

网络服务质量与视频流复制方案解析

4. 合作方案的深入分析

合作方案旨在通过全局优化来提高视频流的整体性能。其核心在于利用效用函数选择存储的视频片段，以确保网络资源的有效利用。

4.1 效用函数的特性

效用函数 Um 是网络中所有片段效用的总和，每个片段的效用 vi 具有以下特性：
- 随着片段副本数量的增加，效用值增加，但增速逐渐放缓。例如，从 3 个副本增加到 4 个副本可能会带来较大的效用提升，但从 199 个副本增加到 200 个副本，效用提升则微乎其微。
- 效用函数独立于每个视频，因为客户端只能存储其观看的视频。

4.2 领导者的作用

在合作方案中，领导者扮演着至关重要的角色，其主要职责包括：
- 维护片段向量 Cm ：领导者收集所有存储部分视频的节点信息，实时更新 Cm ，以反映网络中每个片段的副本数量。
- 处理节点加入和离开 ：当节点加入或离开网络时，领导者根据节点提供的信息更新 Cm ，确保其准确性。
- 选择供应节点 ：当客户端请求视频时，领导者使用存储的本地向量 Dm 找到一组能够流式传输视频的对等节点，以满足每个片段至少由一个节点存储且节点数量尽可能少的条件。

以下是领导者处理节点加入和视频请求的流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([节点加入]):::startend --> B(发送fi和请求):::process
    B --> C(领导者接收信息):::process
    C --> D(计算复制片段):::process
    D --> E(更新Cm):::process
    E --> F([等待视频请求]):::startend
    F --> G(客户端请求视频):::process
    G --> H(领导者接收请求):::process
    H --> I(选择供应节点):::process
    I --> J(通知客户端和供应节点):::process
    J --> K([结束]):::startend