波仔
🔌 第二章 用电信号传输TCP／IP数据
📄 一句话概括

实时音视频要【准时】胜过要【完整】——等重发会卡住后面的所有数据，不如直接放掉一瞬杂音，所以选 UDP。

📝 本节和前面几节的关系

2.6.2 是【丢了无所谓】；本篇是【丢了不敢等】——实时流的取舍。

一、为什么不能等重发

TCP 重发一块，后面所有数据都得排队—— 实时流等得起字节等不起时间。 宁可放一瞬杂音/花屏，也要节奏不乱。

二、⭐ 2026 现状

WebRTC（视频会议）直接用 UDP＋RTP； HTTP/3 的 QUIC 在 UDP 上自建可靠层—— 【可靠与实时兼得】的新解法已经长大。

三、动手 Demo：音视频为什么不怕丢

两种策略的后果：

for a, b in [('等重发（TCP）','卡住后面所有数据'),
             ('直接放（UDP）','一瞬杂音，几乎无损')]:
    print('%-12s %s' % (a, b))

实跑输出：

--------------------------------------------------------------------
音视频为什么不怕丢
--------------------------------------------------------------------
  语音通话丢一块数据的后果：

  策略              效果
  ---------------------------------------------
  等重发（TCP）     卡住后面所有数据，越等越糟
  直接放（UDP）     一瞬杂音，听感几乎无损
  ---------------------------------------------

  实时流要【准时】胜过要【完整】——2026 年的 WebRTC、
  以及 HTTP/3 底层的 QUIC（基于 UDP 自建可靠层），
  都在 UDP 这块地基上盖的新房。

教材当年只能选 UDP＋应用层容错； QUIC 是教材出版后最有分量的后续发展。

30 秒实验

  1. 视频会议卡顿时想想是哪层在排队。
  2. 对比看直播（UDP/QUIC）与下载视频（TCP）的体验差异。
  3. 查查 QUIC 为什么选 UDP 做地基（穿透友好、内核可更新）。

常见误区

  1. 以为实时流也该用 TCP 求完整——节奏比完整重要。
  2. 以为 UDP 上不能做可靠——QUIC 就是反例。
自测三问（点开对答案） 1. 实时流的最高优先级是什么？ —— 准时。 2. TCP 在实时流的致命伤是什么？ —— 重发阻塞后续数据。 3. QUIC 是什么？ —— 基于 UDP 自建可靠与加密的传输协议（HTTP/3 底层）。

相关笔记