从 TCP 到 HTTP/3：一篇讲清 HTTP 协议栈演进、长连接、WebSocket 与轮询机制

打开一个网页，看起来只是点了一下链接。

但在这背后，浏览器、HTTP、TCP、TLS，甚至 QUIC，要一起配合，才能把页面安全、完整、尽快地送到你眼前。

很多性能问题，本质上都不是“页面太大”这么简单，而是链路上多等了几轮来回。理解这件事，最好的入口就是三个词：

• RTT
• 连接
• 协议栈

这篇文章会沿着一条尽量自然的主线展开：

1. 先讲 TCP 和 UDP 为什么不同
2. 再讲 HTTP 是怎么跑在它们之上的
3. 然后讲 长连接、轮询、WebSocket 这些业务侧通信方式
4. 最后落到 HTTP/3 + QUIC 为什么会出现

在正式展开之前，先放一条压缩时间线，方便后面建立整体历史感。

说明：

• “提出或标准化时间”优先按 RFC 或公开提出的时间来写
• “稳定应用时间”不是某个单点，而是一个大致区间，表示主流浏览器、服务器、中间件和业务系统开始普遍可用的阶段

一、先看全局：一次请求经过哪些层

可以先把一条网络请求理解成一条分工明确的流水线：

flowchart TB
    A["浏览器 / App"] --> B["HTTP<br/>定义请求和响应语义"]
    B --> C["TLS<br/>负责身份认证与加密"]
    C --> D["TCP 或 QUIC<br/>负责传输"]
    D --> E["IP<br/>负责寻址与路由"]
    E --> F["物理网络"]

这几层里：

• HTTP 负责“我要什么，你给我什么”
• TLS 负责“对方是不是真服务器，数据会不会被偷看”
• TCP 或 QUIC 负责“数据怎么送过去，是否可靠，顺序是否正确”
• IP 负责“包往哪里走”

先记住一个非常重要的结论：

HTTP 不负责建立连接。

它总是运行在更下面的传输能力之上。

二、为什么世界上既有 TCP，又有 UDP

传输层最经典的两种协议就是 TCP 和 UDP。

1. TCP 是“可靠送达优先”

TCP 更像一条可靠的快递链路，它的特点是：

• 面向连接
• 保证可靠传输
• 保证数据有序到达
• 丢了会重传
• 自带流量控制和拥塞控制

它适合这类场景：

• 网页加载
• API 调用
• 文件传输
• 数据库连接
• 邮件、SSH

一句话概括：能慢一点，但不能乱、不能丢。

2. UDP 是“轻量、低负担优先”

UDP 更像直接发报文，它的特点是：

• 无连接
• 不保证送达
• 不保证顺序
• 不内建重传
• 协议头更轻

它常见在这类场景：

• 音视频实时通话
• 在线游戏
• DNS 查询
• 直播
• 实时互动

一句话概括：宁可偶尔丢一点，也不想多等一轮。

3. UDP 不等于天然更快

很多人会把 UDP 直接理解成“快协议”，把 TCP 理解成“慢协议”。这不严谨。

UDP 只是更轻，不是自动更快。
如果你的业务需要可靠、有序、可恢复，那你最终还是得自己补上这些能力。

这也是后来 QUIC 的思路：用 UDP 做承载外壳，但在上层重新做一套更现代的可靠传输。

三、RTT：理解网络等待成本的钥匙

聊 HTTP 性能，绕不开 RTT。

RTT 是 Round-Trip Time，也就是往返时延。
一条消息从客户端发到服务器，再从服务器返回客户端，花掉的总时间，就是一次 RTT。

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: 请求
    Note over C,S: 0.5 RTT
    S-->>C: 响应
    Note over C,S: 0.5 RTT

所以：

• 单程延迟可以粗略理解成 0.5 RTT
• 每多一次“来回确认”，就多消耗一次 RTT
• 所谓优化链路，本质上往往是在减少来回次数

这也是为什么网页的 TTFB 经常和 RTT 强相关。

因为在真正收到页面第一个字节之前，链路上往往已经来回跑了好几轮。

四、HTTP 还没开始之前，TCP 已经先忙起来了

如果 HTTP 跑在 TCP 上，那么浏览器发出第一个真正的 HTTP 请求之前，通常要先完成 TCP 三次握手。

1. TCP 三次握手

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: SYN
    Note over C,S: 0.5 RTT
    S-->>C: SYN-ACK
    Note over C,S: 累计 1 RTT
    C->>S: ACK
    Note over C,S: 再加 0.5 RTT

严格来说：

• SYN -> SYN-ACK 走完是 1 RTT
• 最后一个 ACK 再走到服务端，还要 0.5 RTT

所以完整三次握手的网络耗时，通常说成 1.5 RTT 更严谨。

2. HTTP 从什么时候开始“出现”

关键点在这里：

HTTP 往往从第三个包开始体现。

也就是客户端收到 SYN-ACK 之后，发出的第三个包，通常不只是 ACK，还会顺带把 HTTP 请求一起带上。

sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: SYN
    S-->>B: SYN-ACK
    B->>S: ACK + HTTP Request
    S-->>B: HTTP Response

也就是说：

• 前两个包是纯 TCP
• 第三个包开始，HTTP 才真正进入链路

3. TCP 挥手为什么通常更慢

TCP 断开连接通常是四次挥手，典型情况大约需要 2 RTT。

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: FIN
    S-->>C: ACK
    S-->>C: FIN
    C->>S: ACK

原因也很简单：
建立连接时，双方是在同步“我要连”；断开连接时，双方需要分别确认“我没数据了”和“你也没数据了”。

五、HTTP/1.0：短连接时代为什么低效

HTTP/1.0 的典型风格是短连接。

意思很简单：

• 来一个请求，建一次连接
• 收到响应，断开连接
• 下一个请求，再重复一遍

flowchart LR
    A["建立 TCP 连接"] --> B["发送 HTTP 请求"]
    B --> C["接收 HTTP 响应"]
    C --> D["关闭 TCP 连接"]

这个模型简单直接，但问题在于现代网页几乎不只有一个资源。

一个页面背后通常还有：

• CSS
• JavaScript
• 图片
• 字体
• 接口请求

如果每个资源都重新经历一次“握手、请求、响应、挥手”，开销会非常大。

所以 HTTP/1.0 最大的问题不是“不能用”，而是：

重复建连成本太高。

六、HTTP/1.1：长连接第一次真正提速

HTTP/1.1 引入了一个非常关键的变化：Keep-Alive。

它的核心思想是：

一个 TCP 连接，不要只用一次就丢。

于是短连接变成长连接：

flowchart LR
    A["建立一次 TCP 连接"] --> B["请求 1 / 响应 1"]
    B --> C["请求 2 / 响应 2"]
    C --> D["请求 3 / 响应 3"]
    D --> E["最后再关闭连接"]

这样带来的好处很直接：

• 不用每个请求都重新三次握手
• 减少 RTT 消耗
• 降低客户端和服务端频繁建连的资源开销

HTTP 长连接和 TCP 长连接是什么关系

这里很容易混淆。

• TCP 长连接：底层连接保持不立即关闭
• HTTP 长连接：HTTP 请求复用同一条 TCP 连接

所以日常说的“HTTP 长连接”，本质上还是在利用 TCP 长连接能力。

但长连接不等于一切都解决了

HTTP/1.1 虽然减少了重复建连，但仍然有一个老问题：请求排队。

一个连接虽然能复用，但大多数情况下仍然容易出现“前一个请求没处理完，后一个请求不好推进”的情况。于是浏览器经常只能：

• 复用已有连接
• 同时再多开几个 TCP 连接

这能缓解问题，但没有真正从协议设计上根治。

七、轮询是怎么出现的：因为 HTTP 天然是请求-响应模型

HTTP 最原始的工作方式是：

• 客户端发请求
• 服务端回响应

这对“拉取一个页面”很适合。
但如果业务变成“服务端一有新消息，就尽快通知客户端”，问题就来了。

浏览器没法天然等着服务端主动开口，于是就出现了轮询。

1. 短轮询

短轮询就是客户端定时去问：

“有新消息吗？”

sequenceDiagram
    participant C as Client
    participant S as Server
    loop 每隔几秒
        C->>S: GET /updates
        S-->>C: 暂无新消息 / 返回消息
    end

优点：

• 简单
• 好实现
• 对部署要求低

缺点：

• 空请求很多
• 实时性一般
• 服务端和网络都有额外负担

2. 长轮询

长轮询会更聪明一点：

• 客户端先发起请求
• 如果服务端暂时没有新消息，就先不立即返回
• 一旦有消息，再把响应返回
• 客户端收到后立刻再发下一个请求

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: GET /updates?timeout=30
    Note over S: 暂无消息时先挂住请求
    S-->>C: 有消息后立即返回
    C->>S: 再次发起长轮询

和短轮询比，长轮询：

• 更省空转请求
• 更接近实时
• 但本质上仍然是“客户端主动拉”

八、用 Telegram Bot 看轮询与 Webhook

Telegram Bot 是理解这些通信方式的很好例子。

1. 短轮询

最笨的方式就是不断调 getUpdates：

• 每隔 1 秒调一次
• 有消息就处理
• 没消息就继续下一次

它实现简单，但浪费很明显。

2. 长轮询

更常见的方式是给 getUpdates 带一个较长超时：

• 请求发出去后，Telegram 先挂着
• 一旦有新消息，就立即返回
• 你的程序收到后，再马上发起下一次请求

这其实就是标准长轮询。

3. Webhook

Webhook 则是完全不同的思路：

• 你提供一个公网可访问的 URL
• 一旦 Bot 收到消息，Telegram 主动把事件推送给你

sequenceDiagram
    participant U as User
    participant T as Telegram
    participant B as Bot Server
    U->>T: 发送消息
    T->>B: POST /webhook
    B-->>T: 200 OK

三种方式的区别可以浓缩成一句话：

• 短轮询：你不停去问
• 长轮询：你问一次，等对方有结果再答
• Webhook：你不问，对方直接来通知你

九、HTTPS 出现以后，链路为什么更长了

HTTP 本身不加密。
所以后来 HTTPS 成为主流，本质上就是：

HTTP + TLS

TLS 主要做三件事：

• 验证服务器身份
• 协商加密算法
• 完成密钥交换

于是链路从原来的：

TCP -> HTTP

变成了：

TCP -> TLS -> HTTP

可以粗略理解成这样：

flowchart LR
    A["TCP 握手"] --> B["TLS 握手"]
    B --> C["发送 HTTP 请求"]
    C --> D["收到 HTTP 响应"]

也就是说，在真正发业务请求前，又多了一段安全协商。

这就是为什么 HTTPS 时代，TTFB 往往不仅受 HTTP 影响，还受这些因素共同影响：

• TCP 建连
• TLS 握手
• 服务器处理时间

顺手纠正一个常见说法：

现代语境里更准确的说法是 TLS，不是 SSL。

SSL 是历史名称，今天实际使用的是 TLS，尤其是 TLS 1.2 和 TLS 1.3。

十、HTTP/2：应用层做到了更聪明，但底层还是 TCP

HTTP/2 解决了 HTTP/1.1 很多应用层问题。

它最重要的改进有三点：

• 二进制分帧
• 头部压缩
• 多路复用

其中最关键的是多路复用：

多个请求可以共享同一条连接，并发传输。

这比 HTTP/1.1 先进很多。
但问题是，HTTP/2 仍然跑在 TCP 上。

只要底层 TCP 某个包丢了，TCP 就要先保证顺序和重传。于是连接上的其他流，即使本来已经准备好了，也可能被一起拖住。

这就是经典的队头阻塞问题。

到这里，瓶颈已经不主要是 HTTP 本身，而是 TCP 本身了。

十一、WebSocket：为什么它比长轮询更像“真正的实时通信”

轮询无论怎么优化，本质仍然是“请求-响应”。

WebSocket 不一样。它通常先借助 HTTP 发起一次升级握手，建立成功后，就进入一个持久、双向、实时的通信通道。

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: HTTP Upgrade 请求
    S-->>C: 101 Switching Protocols
    C<<->>S: 持续双向消息传输

1. WebSocket 到底是基于 TCP 还是 UDP

先给结论：

标准 WebSocket 是基于 TCP 的，不是基于 UDP 的。

更准确地说：

• ws:// 通常跑在 TCP 之上
• wss:// 通常跑在 TLS + TCP 之上

可以把它理解成这样：

flowchart LR
    A["WebSocket 应用消息"] --> B["WebSocket 帧"]
    B --> C["HTTP Upgrade 握手"]
    C --> D["TCP 或 TLS+TCP"]

这也意味着，WebSocket 会继承 TCP 的很多特性：

• 可靠传输
• 按序到达
• 丢包重传
• 在弱网下也可能受到 TCP 队头阻塞影响

2. 为什么它看起来很“实时”，却仍然不是 UDP

很多人会误以为 WebSocket 更像 UDP，是因为它的体验看起来很实时：

• 连接一旦建好，双方都能主动发消息
• 不需要每次都重新发 HTTP 请求
• 聊天、推送、协作编辑这些场景体验很好

但“实时”不等于“基于 UDP”。

WebSocket 实时性的来源主要是：

• 连接常驻
• 应用层不再是请求一次、响应一次
• 服务端可以主动推数据

它并不是靠 UDP 来实现低时延，而是靠省掉重复请求响应模型的额外成本。

3. WebSocket 和 HTTP/2、HTTP/3 的关系

这里也很容易混淆。

WebSocket 和 HTTP/1.1

最经典的 WebSocket 建连方式，是通过 HTTP/1.1 的 Upgrade 机制完成：

• 先发一个 HTTP 请求
• 服务端返回 101 Switching Protocols
• 后续进入 WebSocket 双向通信

WebSocket 和 HTTP/2

HTTP/2 没有继续沿用 HTTP/1.1 的那套 Upgrade 路径，而是后来通过扩展机制支持 WebSocket。

从工程角度理解，可以简单记成：

• WebSocket 最经典、最常见的形态，仍然是 HTTP/1.1 + TCP
• 在 HTTP/2 场景里，可以通过额外扩展来承载 WebSocket

WebSocket 和 HTTP/3

到了 HTTP/3 时代，很多人会自然地问：

那 WebSocket 会不会也直接跑到 UDP / QUIC 上？

从“产品理解”上，最好不要把它想成“WebSocket 变成了 UDP 协议”。

更稳妥的理解是：

• WebSocket 这个概念本身，历史上是建立在 TCP 语义之上的
• 到了 HTTP/3 / QUIC 时代，如果你真正想要更接近 QUIC 能力的浏览器双向流式传输，今天更值得关注的是 WebTransport

也就是说：

• 想理解经典实时 Web 通信，先抓住 WebSocket = 基于 TCP
• 想理解新一代浏览器里的低时延双向传输，再去看 QUIC / WebTransport

它和长轮询的区别非常大：

• 长轮询仍然是一问一答
• WebSocket 建立后，双方都可以随时发消息

它适合：

• 聊天
• 协作编辑
• 实时行情
• 在线状态同步
• 实时通知

所以可以把它理解成：

当业务真正需要持续双向通信时，WebSocket 往往比轮询更自然。

十二、WebRTC：为什么它更像浏览器里的实时媒体通道

如果说 WebSocket 解决的是“网页里实时收发消息”的问题，那么 WebRTC 更像是在解决：

浏览器里如何做低时延、实时、双向的媒体和数据传输。

它最典型的场景是：

• 音视频通话
• 在线会议
• 直播连麦
• 屏幕共享
• 浏览器端点对点数据传输

1. WebRTC 到底是基于 TCP 还是 UDP

先给结论：

WebRTC 的实时媒体传输主要是基于 UDP 的。

更准确地说，它不是简单“直接用 UDP”，而是在浏览器里组合了多层能力：

• 信令：常常借助 HTTP、WebSocket 等上层通道交换 SDP/ICE 信息
• 传输：核心媒体通常走 UDP
• 安全：使用 DTLS、SRTP 等机制保护音视频和数据
• 穿透：通过 ICE、STUN、TURN 尝试打通 NAT 和防火墙

可以把它粗略理解成这样：

flowchart TB
    A["应用层<br/>通话 / 直播 / 协作"] --> B["WebRTC API"]
    B --> C["信令通道<br/>常见是 HTTP / WebSocket"]
    B --> D["ICE / STUN / TURN"]
    D --> E["UDP 优先的媒体传输"]
    E --> F["音频 / 视频 / DataChannel"]

所以 WebRTC 和 WebSocket 的一个本质区别就是：

• WebSocket 更像基于 TCP 的实时消息通道
• WebRTC 更像基于 UDP 的实时媒体与数据通道

2. 为什么 WebRTC 更适合音视频，而不是 WebSocket

原因其实很直接：音视频场景对“低时延”的要求，往往高于“绝对不丢”。

比如视频通话里：

• 丢一两个包，用户通常只会觉得画面轻微抖一下
• 如果因为可靠重传多等几轮，用户会明显感觉卡顿、延迟高、对话打架

这正是 UDP 型思路更适合的地方：

• 不强求每个包都补回来
• 优先保证当前时刻尽快送达
• 时效性比完美一致性更重要

所以 WebRTC 天然适合：

• 实时音频
• 实时视频
• 对时延敏感的互动场景

而不太适合拿来替代普通 Web API 通信。

3. WebRTC 和 WebSocket 的职责分工

很多初学者会把两者混在一起，原因是它们都和“实时”有关。

但它们解决的问题并不一样：

最常见的组合方式其实是：

• 用 WebSocket 做信令
• 用 WebRTC 真正传音视频或低时延数据

这个流程通常像这样：

sequenceDiagram
    participant A as 浏览器 A
    participant S as 信令服务器
    participant B as 浏览器 B
    A->>S: 通过 WebSocket 发送 SDP / ICE
    S->>B: 转发 SDP / ICE
    B->>S: 回传 SDP / ICE
    S->>A: 转发 SDP / ICE
    A<<->>B: 建立 WebRTC 媒体 / 数据通道

也就是说：

• WebSocket 常常只是“牵线搭桥”
• 真正承载实时媒体流的，是后面的 WebRTC 通道

4. WebRTC 与 WebSocket 怎么选

如果你的核心需求是：

• 服务端推送消息
• 房间状态同步
• 在线人数广播
• 文本聊天

通常优先选 WebSocket，因为它更简单，服务端架构也更直接。

如果你的核心需求是：

• 音视频通话
• 低时延语音互动
• 浏览器点对点传输
• 屏幕共享

通常优先看 WebRTC，因为它就是为这类场景设计的。

再压缩成一句话：

• WebSocket 更像实时消息层
• WebRTC 更像实时媒体层

5. WebSocket、WebRTC、WebTransport 在真实项目里怎么选

如果把这几个技术都摆在架构评审桌上，最实用的判断方式不是先看“谁更新”，而是先看：

• 你的核心数据是什么
• 你最怕的是什么
• 你的浏览器兼容目标有多宽

可以先用这张表做第一轮判断：

如果按需求来归类，可以直接这样判断：

只要实时消息，不碰音视频

优先考虑 WebSocket。

典型场景：

• 在线聊天
• 通知推送
• 协作文档里的状态同步
• 行情订阅
• 控制面消息

原因是它足够成熟，而且大部分团队已经有现成的服务端组件、网关支持和监控经验。

主要是音视频或超低时延互动

优先考虑 WebRTC。

典型场景：

• 会议系统
• 语音房
• 直播连麦
• 屏幕共享
• 浏览器点对点媒体流

原因是这些场景更在意“当前这一帧赶紧到”，而不是“每个包都必须补回来”。

既想要浏览器原生双向传输，又想比 WebSocket 更接近 QUIC 能力

这时再评估 WebTransport。

它更适合这类需求：

• 一条连接里同时跑多种数据类型
• 某些数据要求可靠，某些数据允许丢一点
• 想避免单一 TCP 流的队头阻塞
• 希望更贴近未来的 HTTP/3 / QUIC 架构

但今天做选型时，通常要额外确认三件事：

• 目标浏览器范围
• 服务端是否有成熟实现
• 监控、降级、排障工具是否跟得上

需要最高兼容性，且实时性要求没那么高

这时别忘了最朴素的方案仍然成立：

• 短轮询
• 长轮询
• Webhook

不是所有系统都需要一上来就用 WebSocket 或 WebRTC。
如果业务更新频率低、客户端环境复杂、或者系统更偏后台集成，简单方案往往更稳。

最后可以把它们压缩成一句工程化判断：

• 消息优先：先看 WebSocket
• 媒体优先：先看 WebRTC
• 传输能力优先：再评估 WebTransport
• 兼容和简单优先：轮询 / Webhook 也完全合理

十三、为什么 HTTP/3 最终跑到了 UDP 上

如果继续沿着 HTTP/2 往前走，会发现问题越来越集中在 TCP 上。

于是行业没有继续只改 HTTP，而是开始改传输层思路。这就是 QUIC 的出现背景。

QUIC 的核心思路很大胆：

• 底层使用 UDP
• 但不裸奔
• 在 UDP 之上，自己补齐可靠传输、流控、拥塞控制、加密握手

所以更准确的关系是：

flowchart TB
    A["HTTP/3"] --> B["QUIC"]
    B --> C["UDP"]
    C --> D["IP"]

注意这里的重点：

HTTP/3 不是“HTTP 直接基于 UDP”。

而是：

HTTP/3 over QUIC over UDP

十四、HTTP/3 最大的变化：建连和安全握手合并了

传统 HTTPS 链路里，首次请求前大致要经历：

• TCP 握手
• TLS 握手
• 然后才能发 HTTP 请求

而在 HTTP/3 里，这些步骤被显著压缩。因为 QUIC 把 TLS 1.3 直接集成进了自己的握手过程。

可以把两者对比看成这样：

flowchart LR
    A["HTTP/2 over TCP + TLS"] --> B["TCP 握手"]
    B --> C["TLS 握手"]
    C --> D["HTTP 请求"]

    E["HTTP/3 over QUIC"] --> F["QUIC 握手中直接完成 TLS 1.3"]
    F --> G["HTTP/3 请求"]

新连接时，HTTP/3 通常可以在 1 RTT 内完成安全连接建立。
如果是会话恢复，还可能做到 0-RTT。

所以更严谨地说：

HTTP/3 建连过程中，会直接完成 TLS 1.3 的证书校验、身份认证和密钥交换，而不再像 TCP + TLS 那样分成两段。

十五、把这些概念放回一张图里

如果把“协议演进”和“通信模式演进”分开看，会更清楚：

flowchart LR
    A1["HTTP/1.0<br/>短连接"] --> A2["HTTP/1.1<br/>长连接"]
    A2 --> A3["HTTPS + TLS"]
    A3 --> A4["HTTP/2"]
    A4 --> A5["HTTP/3 + QUIC"]

flowchart LR
    B1["普通请求响应"] --> B2["短轮询"]
    B2 --> B3["长轮询"]
    B3 --> B4["WebSocket"]
    B3 --> B5["Webhook"]
    B4 --> B6["WebRTC 信令协作"]

这两条线不要混淆：

• HTTP/1.1、HTTP/2、HTTP/3 主要是在讲协议栈怎么演进
• 长轮询、WebSocket、Webhook、WebRTC 主要是在讲业务如何组织通信

它们有关联，但不是一组同层概念。

十六、结语：协议栈演进，本质上是在不断减少等待

回头看这条发展路径，会发现目标一直没变：

• 少一点等待
• 少一点重复建连
• 多一点并发能力
• 更好地兼顾安全与性能
• 更贴近实时业务需求

从 HTTP/1.0 的短连接，到 HTTP/1.1 的长连接；
从轮询，到 WebSocket 和 Webhook；
从 TCP + TLS，到 QUIC + HTTP/3。

表面看是协议越来越多，
本质上，是工程师在不断回答同一个问题：

怎样才能让一条网络链路，又快、又稳、又安全。

附录：最容易混淆的几个概念

1. TCP 和 UDP 的区别

• TCP：可靠、有序、面向连接
• UDP：轻量、无连接、不保证可靠

2. RTT 和 TTFB 的区别

• RTT：一次来回耗时
• TTFB：从发出请求到收到第一个字节的时间

TTFB 往往包含多个 RTT，再加上服务端处理时间。

3. HTTP 长连接和 TCP 长连接的区别

• TCP 长连接：底层连接不立即断开
• HTTP 长连接：多个 HTTP 请求复用同一条 TCP 连接

4. 长轮询和 WebSocket 的区别

• 长轮询：本质上还是请求-响应
• WebSocket：建立后是持续双向通信

5. WebRTC 和 WebSocket 的区别

• WebSocket：更适合实时消息、状态同步、推送
• WebRTC：更适合实时音视频和低时延点对点数据
• WebSocket 多数基于 TCP
• WebRTC 媒体传输多数基于 UDP

6. Webhook 和轮询的区别

• 轮询：客户端主动拉
• Webhook：服务端主动推

7. HTTP/3、WebSocket、Webhook、WebRTC 为什么不是一类东西

• HTTP/3：协议栈层面的传输方案
• WebSocket：一种持续双向通信机制
• Webhook：一种事件通知模式
• WebRTC：一种面向实时音视频和点对点传输的浏览器通信体系

它们解决的问题并不在同一层。