Day 13 — 多媒体网络、流媒体、CDN 与 QoS#

前情回顾：Day 11 我们聊了链路层和以太网，理解了 MAC 地址、CSMA/CD、VLAN 这些底层基石。至此，五层模型的每一层我们都已经翻了个遍。今天，我们换个视角——不再逐层拆解，而是聚焦一个改变互联网面貌的应用领域：多媒体网络。你每天刷的 B 站、追的 Netflix、开的腾讯会议，背后全是我们今天要聊的技术。

一、多媒体网络：互联网的”流量巨兽”#

1.1 多媒体流量到底有多恐怖？#

先来感受一组数据：

YouTube 每分钟上传超过 500 小时的视频
Netflix 占北美互联网流量的 30%+
2025 年全球 IP 流量中，视频流量占比超过 80%

可以说，今天的互联网基本就是一个巨大的视频管道。文本？那只是管壁上的一层薄漆。

生活类比：想象互联网是一条高速公路。早期只有几辆自行车（文本邮件），后来有了小汽车（网页图片），现在呢？全是重型卡车（视频流），一辆接一辆，日夜不停。

多媒体应用对网络的需求和传统应用截然不同：

特性	传统应用（HTTP、邮件）	多媒体应用（视频、语音）
延迟敏感度	不太敏感	极其敏感（>300ms 就难受）
丢包容忍度	零容忍（文件不能缺字节）	有一定容忍（丢几帧无所谓）
带宽需求	低～中等	高～极高
持续时间	短连接为主	长时间持续流

这张表揭示了一个核心矛盾：多媒体要低延迟，但又需要大带宽；能容忍丢包，但 TCP 偏偏不丢包。这个矛盾贯穿了整个多媒体网络的设计。

二、流式存储视频：DASH 横空出世#

2.1 从”下载完再看”到”边下边看”#

远古时代（2000 年代初），在网上看视频的体验是这样的：点开链接 → 等待 → 等待 → 进度条慢慢爬 → 下完了 → 终于能看了。

这叫 下载-播放模型，显然不符合人类的即时满足需求。

于是有了 流式传输（Streaming）：视频数据像流水一样源源不断地从服务器涌向你的设备，你一边接水一边喝，不需要等整个水池灌满。

生活类比：下载-播放就像你得把整个 bathtub 的水放满才能泡澡；流式传输就像淋浴——水一边来你一边洗，随到随用。

2.2 UDP 流 vs HTTP 流#

早期流媒体用 UDP（比如 RTSP 协议），因为 UDP 延迟低。但问题来了：

很多防火墙/NAT 会挡 UDP
CDN 和缓存系统是围绕 HTTP 设计的
UDP 没有拥塞控制，容易把网络搞崩

所以现代流媒体几乎全转向了 HTTP 流：用 TCP/HTTP 传视频，就像传普通网页一样。防火墙不挡，CDN 能缓存，皆大欢喜。

代价呢？TCP 的头部开销和重传机制会增加一点延迟。但对于非实时的流式视频（不是视频通话），这点延迟完全可以接受。

2.3 DASH：动态自适应流#

DASH（Dynamic Adaptive Streaming over HTTP） 是现代流媒体的核心技术。B 站、YouTube、Netflix 用的都是这个思路（具体实现可能是 HLS、MPEG-DASH 等变体）。

核心思想非常优雅：不要只准备一个版本的视频，准备很多个版本，让客户端自己选。

工作原理#

服务器把视频切割成等时长的小块（比如每块 2～10 秒），每个块编码成多个质量等级（不同码率、分辨率）：

视频源 → 切分成 N 个块

块 1: [240p 500kbps] [480p 1Mbps] [720p 2Mbps] [1080p 5Mbps] [4K 15Mbps]
块 2: [240p 500kbps] [480p 1Mbps] [720p 2Mbps] [1080p 5Mbps] [4K 15Mbps]
块 3: [240p 500kbps] [480p 1Mbps] [720p 2Mbps] [1080p 5Mbps] [4K 15Mbps]
...

同时服务器提供一个 manifest 文件（清单），列出了所有块和所有质量等级的 URL。

客户端（播放器）的工作流程：

先拉 manifest 文件，了解有哪些版本可选
根据当前带宽估计，选择一个合适的质量等级
请求第一个块 → 播放
持续监控带宽变化
如果带宽充裕 → 下一块选更高画质
如果带宽变差 → 降级到更低画质

这就是你在 B 站看视频时，画质自动在 1080p 和 360p 之间跳来跳去的原因。

生活类比：DASH 就像自助餐厅。厨师（服务器）把每道菜都做成了大份、中份、小份。你（客户端）根据自己的胃口（带宽）决定拿哪份。今天胃口好 → 大份牛排；突然胃疼 → 换小份沙拉。全程不用跟厨师说话，自己拿就行。

DASH 的聪明之处#

DASH 的精妙在于它把智能下放到了客户端：

服务器不需要知道客户端的网络状况
服务器只需要存一堆文件，用普通 HTTP 服务器就能搞定
客户端自己决定拉什么质量，完全自治
不同客户端可以有完全不同的体验，互不干扰

这也是为什么 CDN 非常喜欢 DASH——它就是一堆静态文件的 HTTP 请求，和缓存网页没有任何区别。

告警：码率切换的”突变”问题#

你可能注意过，B 站视频有时会在 1080p 和 360p 之间反复横跳，画面突然模糊又突然清晰，非常难受。

这是因为带宽估计不稳定。如果客户端的算法太激进，网络一抖动就降到最低画质，网络一恢复就冲到最高画质，用户体验就很糟糕。

优秀的 ABR（Adaptive Bit Rate）算法需要在稳定性和响应速度之间找平衡。Netflix 甚至用机器学习来优化这个决策过程。

三、CDN：内容分发网络#

3.1 为什么需要 CDN？#

假设你在中国上海，想看一个托管在美国纽约服务器的视频。数据要跨越太平洋，经过十几个路由器，延迟 200ms+。如果同时有一万个人在看这个视频，纽约服务器的带宽直接爆炸。

这个问题的解决方案不是把服务器搬到每个城市（成本太高），而是 CDN（Content Distribution Network）。

CDN 的核心思想：在全世界各地部署大量缓存节点（边缘服务器），把内容的副本放在离用户最近的地方。用户访问时，被引导到最近的节点，直接从那里获取数据。

生活类比：CDN 就像连锁超市。你不需要每次想吃薯片都去工厂总部（源服务器）买。工厂把薯片分销到你家门口的超市（CDN 节点），你走两分钟就能买到。库存没了？超市会让工厂补货。

3.2 CDN 的工作流程#

当你在浏览器输入 bc970321.cn 时（假设接了 CDN），发生的事情：

1. 用户请求 https://bc970321.cn/some-video.mp4
2. DNS 查询：bc970321.cn 的 DNS 记录不是 A 记录，而是 CNAME 指向 CDN 提供商的域名
3. CDN 的 DNS 服务器根据用户 IP 地址，返回最近的边缘节点 IP
4. 用户连接到该边缘节点
5. 边缘节点检查：有没有这个视频的缓存？
   - 有 → 直接返回（缓存命中，Cache Hit）
   - 没有 → 从源服务器拉取，缓存一份，再返回用户（缓存未命中，Cache Miss）
6. 后续其他用户请求同一视频 → 直接从边缘节点返回

3.3 CDN 的关键设计挑战#

选哪个节点？#

CDN 的 DNS 需要决定把用户导向哪个节点。最简单的策略是基于地理距离，但距离不等于网络质量。一个北京用户可能到天津节点的延迟比到北京本地某节点还低（取决于运营商路由）。

高级 CDN（Cloudflare、Akamai、AWS CloudFront）使用：

BGP Anycast：同一个 IP 地址在全球广播，用户的数据包自然路由到最近的节点
实时网络探测：持续测量各节点到各地区的延迟和丢包率
机器学习预测：根据历史数据预测最优节点

缓存什么？缓存多久？#

CDN 的缓存策略决定了命中率：

Pull 策略：用户第一次请求时，节点从源服务器拉取并缓存。最常见。
Push 策略：源服务器主动把热门内容推到所有节点。适合大文件首发的场景。
TTL（Time To Live）：缓存的有效期。过期后下次请求会重新从源服务器拉取。

对于你的博客 bc970321.cn：

HTML 页面：TTL 短（几分钟），确保内容更新能及时生效
图片/CSS/JS 静态资源：TTL 长（几天到几个月），反正不怎么变
如果上了 Hexo 博客，可以用 hexo_asset_img 等插件给静态资源加 hash 后缀，实现长缓存 + 自动更新

缓存替换策略#

边缘节点的存储空间有限，新内容来了，旧内容就得淘汰。常见策略：

LRU（Least Recently Used）：淘汰最久没用的
LFU（Least Frequently Used）：淘汰使用频率最低的
大多数 CDN 用 LRU 的变体

四、实战分析：bc970321.cn 博客接入 CDN#

说了这么多理论，来点实际的。假设我们要给 bc970321.cn 这个 Hexo 博客接入 CDN，怎么做？

4.1 方案一：全站 CDN（Cloudflare 免费版）#

最简单的方案——把整个域名丢给 Cloudflare：

1
2
3

DNS 记录：
bc970321.cn    A    → 你的源站 IP（通过 Cloudflare 橙云代理）
www            CNAME → bc970321.cn

Cloudflare 会自动：

缓存所有静态资源（CSS、JS、图片）
提供 DDoS 防护
提供 TLS 证书（免费）
全球 300+ 节点加速

缓存规则建议：

# Cloudflare Page Rules
1. *.bc970321.cn/images/*    → Cache Everything, TTL 1 month
2. *.bc970321.cn/css/*       → Cache Everything, TTL 1 month  
3. *.bc970321.cn/js/*        → Cache Everywhere, TTL 1 month
4. *.bc970321.cn/*           → Cache Everything, TTL 5 min

4.2 方案二：静态资源走 CDN，动态请求走源站#

如果你想更精细地控制：

1
2
3

DNS 记录：
bc970321.cn          A     → 你的源站 IP（灰云，不代理）
cdn.bc970321.cn      CNAME → CDN 提供商

在 Hexo 模板里，把静态资源 URL 改成 CDN 地址：

1 2	<link rel="stylesheet" href="https://cdn.bc970321.cn/css/style.min.css"> <img src="https://cdn.bc970321.cn/images/avatar.jpg">

对 Hexo 来说，可以在 _config.yml 里设置：

url: https://bc970321.cn
# 如果主题支持 CDN 加速
cdn: 
  enable: true
  prefix: https://cdn.bc970321.cn

4.3 Nginx 的流媒体能力#

你的服务器上跑着 Nginx，它其实也是流媒体的一把好手：

Nginx 做 HLS 直播/点播#

# 点播 HLS
location /hls/ {
    types {
        application/vnd.apple.mpegurl m3u8;
        video/mp2t ts;
    }
    root /var/videos;
    add_header Cache-Control public;
    add_header Access-Control-Allow-Origin *;
}

# 直播 HLS（需要 nginx-rtmp-module）
rtmp {
    server {
        listen 1935;
        application live {
            live on;
            hls on;
            hls_path /var/hls;
            hls_fragment 3;
        }
    }
}

Nginx 做 DASH#

location /dash/ {
    types {
        application/dash+xml mpd;
        video/mp4 m4s;
    }
    root /var/videos/dash;
    add_header Cache-Control public;
}

Nginx 的限速功能（保护源站带宽）#

# 限制每个 IP 的视频流带宽
location /video/ {
    limit_rate 2m;  # 每个连接限速 2MB/s
    limit_rate_after 1m;  # 前 1MB 不限速（快速起播）
    root /var/videos;
}

这个 limit_rate_after 很聪明——先让你快速拿到前面的数据（快速起播），然后再限速（防止占太多带宽）。和 DASH 的思路异曲同工。

五、视频会议：实时多媒体的硬核战场#

5.1 和流媒体的区别#

流式视频（YouTube、B 站）是 存储视频——内容已经存在服务器上，可以提前编码、切分、缓存，对延迟的要求是”尽量低”但不是”必须低”。

视频会议（Zoom、腾讯会议、Discord）是 实时交互——画面是即时的，没有预编码和缓存的机会，延迟必须 < 300ms，否则人类就会觉得”卡”。

生活类比：流式视频像看录播的电视剧——你可以暂停、倒退、换清晰度。视频会议像打电话——你说完一句，对方 0.5 秒后才听到，这对话就没法正常进行了。

5.2 视频会议的架构#

经典架构：MCU（Multipoint Control Unit）#

早期视频会议用集中式服务器 MCU：

1
2
3

用户A ──┐
用户B ──┼──→ MCU 服务器（解码所有流 → 合成画面 → 重新编码 → 发给所有人）
用户C ──┘

问题：MCU 服务器的计算压力极大（要解码+编码 N 路视频），延迟也高。

现代架构：SFU（Selective Forwarding Unit）#

WebRTC 时代的主流方案：

1
2
3

用户A ──发送多路质量的流──→ SFU ──→ 转发给 B 和 C（按需选择质量）
用户B ──发送多路质量的流──→ SFU ──→ 转发给 A 和 C
用户C ──发送多路质量的流──→ SFU ──→ 转发给 A 和 B

SFU 不解码视频，只做选择性转发。它就像一个聪明的快递分拣员——不看包裹里是什么，只看标签决定转发给谁。

这和 DASH 的”多质量等级”思想一脉相承：发送端同时发多路不同质量的流（Simulcast），SFU 根据接收端的带宽选择转发哪一路。

5.3 WebRTC：浏览器的实时通信#

WebRTC 是浏览器内置的实时通信框架，核心技术包括：

音视频编解码：VP8/VP9、H.264、Opus 音频
传输协议：RTP over UDP（不走 TCP！实时性优先）
NAT 穿透：ICE/STUN/TURN 协议组合拳
拥塞控制：自定义的 GCC（Google Congestion Control）

为什么 WebRTC 不用 TCP？因为实时通信中，迟到的帧不如丢弃的帧。如果用 TCP，一个丢包会导致后续所有数据被阻塞（队头阻塞），视频就卡住了。UDP 丢了就丢了，后面的帧照常到达，画面顶多闪一下。

六、RTP 与 RTCP：多媒体的传输协议#

6.1 RTP（Real-time Transport Protocol）#

既然视频会议用 UDP，但 UDP 啥都不保证，怎么知道包的顺序？怎么知道时间戳？这就需要 RTP。

RTP 运行在 UDP 之上，给每个包加上了：

序列号：检测丢包和重排序
时间戳：音视频同步
负载类型：标识编码格式（H.264、Opus 等）
SSRC：标识发送源（多个人的流混在一起时区分谁是谁）

RTP 包头：
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       序列号                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          时间戳                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    同步源标识 (SSRC)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2 RTCP（RTP Control Protocol）#

RTP 只管传数据，但发送方需要知道：接收方收到了吗？网络质量怎么样？这就需要 RTCP。

RTCP 定期发送控制包，包含：

接收报告（RR）：告诉发送方”我收到了多少、丢了多少、延迟抖动多大”
发送报告（SR）：告诉接收方”我发了多少数据”

发送方根据 RTCP 的反馈来动态调整编码率和发送速率。这就是 网络自适应 的基础。

生活类比：RTP 是你不断往邮筒里塞信（数据包），RTCP 是收件人偶尔给你回一张明信片说”最近信件到达率 85%，有几封晚了 3 天”。你根据反馈调整寄信策略。

七、QoS：服务质量保障#

7.1 为什么需要 QoS？#

当网络拥塞时，所有流量一视同仁地丢包和延迟。但问题是：你的 SSH 会话丢几个包只是屏幕闪一下，而你的视频会议丢几个包就是”你说什么？我听不——“。

QoS（Quality of Service） 的目标就是：在网络资源有限时，优先保障重要流量的质量。

生活类比：QoS 就像医院的分诊制度。所有人都挤在急诊室（路由器队列），但心脏病发作的（实时语音）优先看，崴脚的（文件下载）慢慢等。

7.2 QoS 的关键技术#

调度策略（Scheduling）#

路由器在出口有多个队列，如何决定先发哪个？

FIFO（First In First Out）：先来先服务，默认策略，没有优先级
Priority Queuing（优先级队列）：高优先级队列先清空，低优先级等着。问题是低优先级可能被饿死
Round Robin（轮询）：轮流给每个队列发，公平但没优先级
WFQ（Weighted Fair Queuing，加权公平队列）：给每个队列分配权重，按比例分配带宽。最常用

权重分配示例：
  语音流    权重 50  → 分到 50% 带宽
  视频流    权重 30  → 分到 30% 带宽
  HTTP     权重 15  → 分到 15% 带宽
  其他      权重 5   → 分到 5% 带宽

流量标记（DSCP / ToS）#

IP 包头有个字段叫 DSCP（Differentiated Services Code Point），6 个 bit，可以标记 64 个优先级。

路由器看到标记后，把包放进对应的队列。常见标记值：

EF（Expedited Forwarding）：最高优先级，用于实时语音
AF（Assured Forwarding）：中等优先级，分多个子级别
BE（Best Effort）：默认，尽力而为

流量整形（Traffic Shaping）#

用 令牌桶（Token Bucket） 算法限制流的速率：

令牌桶原理：
  - 桶里有令牌，每个令牌代表发送一定数据的权限
  - 令牌以固定速率 r 加入桶中
  - 桶满了（容量 b），多余的令牌丢弃
  - 发送数据时，消耗对应数量的令牌
  - 没有令牌 → 等待

效果：
  - 平均速率 = r（令牌生成速率）
  - 突发容量 = b（桶大小），允许短时间的流量突发

生活类比：令牌桶就像游乐场的过山车。每分钟放 10 个人上车（令牌生成速率 r），但排队区最多容纳 50 人（桶大小 b）。平时队不长，大家按 10 人/分钟上车。节假日突然来了 100 人？前 50 人排队，后面的人就得等——或者直接被劝退（丢包）。

主动队列管理：RED#

当队列太长时，所有包都经历高延迟。RED（Random Early Detection） 在队列快满之前就开始随机丢包，给发送方 TCP 一个”嘿，快堵了，慢点发”的信号。

这比等队列满了再全部丢包好得多——后者会导致 TCP 全局同步（所有连接同时减速，带宽利用率暴跌）。

7.3 QoS 的现实困境#

理论上 QoS 很美好，实践中却很难全面部署：

端到端问题：你的包要经过多个 ISP，每个 ISP 的 QoS 策略不同。你标记了 EF 优先级，别人的路由器可能直接忽略
资源分配之争：谁的语音通话比谁的重要？运营商之间很难达成一致
识别困难：Deep Packet Inspection（DPI）能识别流量类型，但加密（HTTPS/TLS）让 DPI 很难工作

所以现代方案更倾向于Provisioning（过度配置带宽）——带宽够用的话，QoS 的问题根本不存在。这也是为什么近年来 QoS 的讨论越来越少了——光纤入户、5G 时代，带宽不再是稀缺资源。

但对你的服务器来说，Nginx 的 limit_rate、limit_conn 就是一种轻量级 QoS，在带宽有限时仍然很有用。

八、内容分发的新趋势：P2P + CDN 混合#

8.1 P2P 辅助 CDN#

纯 CDN 的成本很高（每个节点都要服务器和带宽）。P2P-CDN 混合方案让用户之间互相分享数据，减轻服务器压力。

WebRTC 的 DataChannel 让浏览器之间可以直接传数据，不需要插件。这就催生了基于浏览器的 P2P-CDN：

传统 CDN：
  CDN节点 → 用户A
  CDN节点 → 用户B
  CDN节点 → 用户C
  （服务器带宽 = 3 份流量）

P2P-CDN：
  CDN节点 → 用户A → 用户B → 用户C（部分数据从 A 和 B 互相获取）
  （服务器带宽 = 1～1.5 份流量）

B 站和部分直播平台已经在用这种技术了。你在看直播时，你的浏览器其实在悄悄给其他观众传数据。

8.2 边缘计算#

CDN 节点不再只是缓存静态文件，而是在边缘节点运行代码（Cloudflare Workers、AWS Lambda@Edge）。这意味着：

视频转码可以在边缘完成
个性化推荐可以在边缘处理
ABR 策略可以在边缘优化

九、完整链路：你发一条视频消息的全旅程#

把今天学的全部串起来。假设你在微信发一条 30 秒的视频消息给朋友：

1. 拍摄 → 手机编码（H.264/H.265 压缩，减少数据量）
2. 上传 → HTTP POST 到微信服务器
3. 服务器处理 → 转码成多个质量等级（DASH/HLS）
4. 分发 → 通过 CDN 缓存到全国各节点
5. 朋友点击 → DNS 解析到最近的 CDN 节点
6. 播放 → DASH 自适应选择合适画质
7. 传输 → HTTP over TCP（非实时，所以用 TCP 没问题）
8. 解码 → 朋友的手机解码播放

如果你俩在视频通话呢？流程完全不同：

1. 采集 → 摄像头/麦克风实时采集
2. 编码 → 实时编码（VP8/H.264）
3. 传输 → RTP over UDP（实时性优先！）
4. NAT 穿透 → STUN/TURN 服务器帮忙打通连接
5. 转发 → 通过 SFU 服务器转发给对方
6. 反馈 → RTCP 报告网络质量，动态调整码率
7. 解码播放 → 对方的设备实时解码

同一个”视频”，因为场景不同，背后用的技术完全不一样。这就是计算机网络的美妙之处——没有银弹，只有适合场景的设计。

关键知识点回顾#

📌 流媒体核心概念#

概念	一句话总结
流式传输	边下边看，不需要下载完整文件
DASH	服务器切多质量等级的视频块，客户端按带宽自适应选择
Manifest 文件	告诉客户端有哪些版本可选的”菜单”
ABR 算法	客户端决定下一块选哪个质量的核心算法

📌 CDN 核心概念#

概念	一句话总结
CDN	全球部署缓存节点，让用户从最近的节点获取内容
DNS 重定向	通过 DNS 把用户引导到最近的 CDN 节点
缓存命中率	命中率越高，回源流量越少，性能越好
缓存策略	Pull（被动拉取）、Push（主动推送）、TTL（有效期）

📌 实时多媒体核心概念#

概念	一句话总结
RTP	UDP 之上的实时传输协议，带序列号和时间戳
RTCP	RTP 的控制协议，反馈网络质量
WebRTC	浏览器内置的实时通信框架
SFU	选择性转发单元，现代视频会议的核心架构
Simulcast	发送端同时发多质量等级的流

📌 QoS 核心概念#

概念	一句话总结
QoS	在有限资源下优先保障重要流量
调度策略	FIFO / 优先级 / WFQ 决定队列发送顺序
DSCP	IP 包头标记优先级的字段
令牌桶	限制流量速率的经典算法
RED	主动队列管理，避免全局同步

Day 14 预告：网络安全——加密、认证、SSL/TLS、防火墙 🔒#

今天我们聊了多媒体数据怎么高效传输，但有一个问题一直被我们忽略：这些数据在传输过程中安全吗？ 你在咖啡厅连公共 WiFi 看视频，旁边的人能截获你的流量吗？你确定你在访问的是真正的 bc970321.cn 而不是钓鱼网站？

Day 14 我们进入计算机网络最关键的领域——安全。我们会聊：

对称加密 vs 非对称加密：一把钥匙还是两把钥匙？
数字签名与证书：怎么证明”我就是我”？
SSL/TLS：HTTPS 背后的守护神
防火墙与 IDS/IPS：网络安全的门卫和监控摄像头
VPN：在公共网络上建一条加密隧道

网络安全是整个计算机网络学习的收官之战，也是现实中最重要的话题。毕竟，一个不安全的网络，速度再快也没用。

“There are two types of companies: those that have been hacked, and those who don’t know they have been hacked.” — Robert Mueller

我们 Day 14 见！🚀

本文是《计算机网络：自顶向下方法》（第 8 版）读书笔记系列的第 13 篇。系列文章持续更新中。

计算机网络：自顶向下方法 - Day 13 | 多媒体网络、流媒体、CDN 与 QoS