从 HTTP 到 QUIC：一文串起 HTTPS、DNS、HTTP/2 与 HTTP/3

很多网络协议的知识点单独看并不难，但一旦把 HTTP、HTTPS、TLS、DNS、ARP、HTTP/2、HTTP/3、QUIC、SSE、WebSocket 放到一起，往往就会混成一团。本文尝试把这些概念收敛到同一条访问链路里：从浏览器输入一个 https:// 网址开始，一路看到页面返回，顺便理清现代 Web 常见协议之间的关系。

一、先从分层模型建立整体视角

学习网络协议时，很多人先接触的是 OSI 七层模型：

物理层
数据链路层
网络层
传输层
会话层
表示层
应用层

这个模型适合教学，但现实互联网更常用的是 TCP/IP 四层或五层模型。工程上通常可以这样理解：

应用层：HTTP、HTTPS、DNS、SSE、WebSocket
传输层：TCP、UDP、QUIC
网络层：IP、ICMP
数据链路层：Ethernet、Wi-Fi、ARP
物理层：网线、光纤、无线电信号

一个典型的现代 Web 请求大致长这样：

HTTP/3
  -> QUIC
    -> UDP
      -> IP
        -> Ethernet / Wi-Fi

如果是更传统的 HTTPS 访问，则通常是：

HTTP/2
  -> TLS
    -> TCP
      -> IP
        -> Ethernet / Wi-Fi

这也是理解后文的起点：HTTP 关注“应用如何通信”，TCP/UDP/QUIC 关注“数据如何传”，IP 负责跨网络寻址，链路层负责本地局域网内的帧传输。

二、HTTP 到底是什么，HTTPS 又多了什么

HTTP 的全称是 HyperText Transfer Protocol，也就是“超文本传输协议”。它定义了浏览器和服务器之间如何进行请求与响应。

最基本的过程是：

浏览器发出 HTTP 请求
服务器处理请求
服务器返回 HTTP 响应
浏览器解析响应并渲染页面

常见请求方法包括：

GET：读取资源
POST：提交数据
PUT：更新或创建指定资源
DELETE：删除资源

HTTPS 则可以理解为 HTTP + TLS。它并没有改掉 HTTP 的请求响应模型，而是在 HTTP 之下增加了一层安全机制，用来解决三件事：

机密性：传输内容被加密，外部无法直接看到明文
完整性：防止数据在中途被篡改
身份认证：客户端能校验服务器身份

因此，HTTP 和 HTTPS 的根本区别不是“有没有网页”，而是“HTTP 内容在传输过程中是否被安全保护”。

三、HTTPS 中对称加密、非对称加密和证书分别负责什么

很多人第一次学 HTTPS 时容易误以为“全程都靠公钥私钥在加密”。实际上不是这样。

在现代 TLS 中，两类密码学机制是分工协作的：

1. 非对称密码学

使用一对密钥：

公钥
私钥

它的主要作用不是高效传大量业务数据，而是：

校验服务器身份
完成密钥交换
证明服务器确实持有对应私钥

2. 对称加密

双方使用同一个会话密钥进行加密和解密。它的特点是速度快，因此更适合真正的业务流量传输。

换句话说，HTTPS 的主流程通常是：

先用非对称密码学完成认证和密钥协商
再用对称加密传输后续 HTTP 数据

3. TLS 和 SSL 的关系

TLS 全称是 Transport Layer Security
SSL 全称是 Secure Sockets Layer

SSL 是更早的旧协议族，今天实际主流已经是 TLS。日常口语里很多人还会把证书或加密统称为“SSL”，但更准确的说法通常是 TLS。

4. 如果 HTTPS 的对称会话密钥泄露，会发生什么

如果某一次 HTTPS 连接使用的对称会话密钥泄露，最直接的后果是：

这次连接中已经抓到的加密流量可能被解密
该连接中的请求内容、Cookie、响应体等敏感数据可能暴露
如果攻击者还能介入连接过程，数据完整性也可能受到破坏

不过现代 TLS 通常具备前向保密（Forward Secrecy）特性，所以风险一般主要局限在对应会话，而不会因为一次会话密钥泄露就自动影响所有历史连接。

换句话说：

泄露的是哪一条连接的会话密钥，主要影响哪一条连接
它通常不能反推出服务器私钥
也不能自动解密其他会话

因此，HTTPS 中真正需要长期严密保护的是服务器私钥，而会话密钥泄露的风险则更偏向“单次连接失守”。

四、输入一个 HTTPS 网址后，浏览器具体做了什么

假设在浏览器里输入：

https://example.com/news

浏览器通常会按下面的顺序推进：

1. 解析 URL

浏览器拆出协议、域名、路径、默认端口：

协议：https
域名：example.com
路径：/news
端口：443

2. DNS 解析

浏览器先尝试从本地缓存中找到 example.com 的 IP。没有命中时，会请求递归 DNS 服务器。

这里有两个很容易混淆的概念：

递归查询：你直接帮我查到最终结果
迭代查询：你告诉我下一步该问谁

现实里通常是：

客户端到递归 DNS：递归查询
递归 DNS 到根 DNS、顶级域 DNS、权威 DNS：迭代查询

3. 局域网内解析下一跳的 MAC 地址

得到目标 IP 后，如果目标不在本地网段，主机不会直接去找远端服务器的 MAC，而是先找默认网关的 MAC。这个过程靠 ARP 完成。

ARP 的全称是 Address Resolution Protocol，即地址解析协议。它在局域网内把：

IP 地址
映射到对应的 MAC 地址

常见流程是：

查本机 ARP 缓存
缓存没有则发送 ARP 广播
拥有该 IP 的设备返回 ARP 响应
本机记录 IP -> MAC 映射

4. 建立传输层连接

这里会分两种情况：

如果协商使用 HTTP/1.1 或 HTTP/2，通常基于 TCP
如果使用 HTTP/3，通常基于 QUIC over UDP

5. 完成 TLS 握手

如果当前链路是 HTTPS over TCP，浏览器会先完成 TLS 握手，再发送真正的 HTTP 请求。

6. 发送 HTTP 请求并接收响应

请求可能是：

GET /news HTTP/1.1
Host: example.com

服务器返回状态码、响应头和响应体，浏览器再继续解析 HTML、拉取 CSS/JS/图片，最终完成渲染。

五、HTTP 常见状态码应该如何理解

HTTP 状态码可以粗分为 5 类：

1xx：信息性响应
2xx：成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误

日常开发里最常见的是下面这些：

成功类

200 OK：请求成功
201 Created：成功创建新资源，最常见于 POST 创建场景
204 No Content：请求成功，但响应体为空

需要注意的是，201 不是“专属于 POST”，而是“成功创建资源”的语义。某些 PUT 在首次创建资源时也可以返回 201。

重定向类

301 Moved Permanently：永久重定向
302 Found：临时重定向
304 Not Modified：资源未变化，可直接使用缓存

客户端错误类

400 Bad Request：请求格式或参数有问题
401 Unauthorized：尚未完成认证
403 Forbidden：身份可识别，但没有权限
404 Not Found：资源不存在
429 Too Many Requests：请求过多，被限流

服务端错误类

500 Internal Server Error：服务器内部错误
502 Bad Gateway：代理或网关拿到无效上游响应
503 Service Unavailable：服务暂时不可用
504 Gateway Timeout：上游响应超时

六、HTTP/1.0、1.1、2、3 是怎么一步步演进过来的

1. HTTP/1.0

HTTP/1.0 的特点是简单，但连接成本高。典型情况是：

一个请求对应一个 TCP 连接
请求结束后连接很快关闭

一个页面如果包含大量 CSS、JS 和图片，就需要频繁建立 TCP 连接，效率较低。

2. HTTP/1.1

HTTP/1.1 的关键改进不在多路复用，而在：

默认支持长连接
增加 Host 头
更完整的缓存控制
支持分块传输

HTTP/1.1 也定义了 Pipelining（管线化），允许客户端连续发送多个请求，但响应顺序仍然受前序请求影响，因此实际使用并不理想。

3. HTTP/2

HTTP/2 的核心改进包括：

二进制分帧
多路复用
头部压缩（HPACK）

这里要特别区分：

管线化：请求能连续发，但响应通常仍然要按顺序处理
多路复用：多个请求和响应可以在同一连接里并发交错传输

所以，HTTP/1.1 和 HTTP/2 的关键差异才是多路复用，而不是 HTTP/1.0 和 HTTP/1.1。

4. HTTP/3

HTTP/3 最大的变化是换掉了 TCP，改跑在 QUIC 上。

它保留了 HTTP 语义，但底层传输机制变成：

HTTP/3 -> QUIC -> UDP -> IP

这一步主要是为了解决 HTTP/2 over TCP 在弱网和丢包场景下的传输层瓶颈。

七、HTTP/2 中 TLS 握手和 ALPN 的角色

如果浏览器通过 HTTPS + HTTP/2 访问网站，常见协议栈是：

HTTP/2 -> TLS 1.3 -> TCP -> IP

TLS 握手的大致过程可以概括为：

浏览器发 ClientHello
声明支持的 TLS 版本、密码套件、SNI、ALPN
服务器回 ServerHello
服务器发送证书链、签名信息和握手完成消息
浏览器校验证书是否合法、域名是否匹配
双方导出会话密钥
后续用对称密钥传输真正的 HTTP 内容

其中一个容易被忽略的点是 ALPN（Application-Layer Protocol Negotiation）。它的作用是告诉服务器：

我支持 h2
我也支持 http/1.1

服务器再从中选择最终应用层协议。如果最终协商结果是 h2，双方才会在 TLS 之上开始传输 HTTP/2 帧。

八、为什么 HTTP/2 明明已经多路复用，还是会被丢包拖慢

这里要分清两种“阻塞”：

应用层队头阻塞
传输层队头阻塞

HTTP/1.1 的管线化更容易遇到应用层队头阻塞：前一个响应没返回，后面的响应也会跟着排队。

HTTP/2 通过多路复用大幅缓解了应用层问题，但它仍然跑在 TCP 上，所以还会遇到传输层队头阻塞。

其根本原因在于 TCP 是：

面向连接
可靠传输
按序交付
面向字节流

如果一个 TCP 连接中的前面某段数据丢了，即使后面的数据已经到达，TCP 也不能把后续字节先交给上层。于是同一个连接上的其他 HTTP/2 流也会受到拖累。

这就是“HTTP/2 有多路复用，但仍然会被 TCP 队头阻塞拖慢”的原因。

九、结合 TCP 和 UDP 的区别，理解 QUIC 为什么能解决这个问题

先看两个基本事实：

TCP 是面向字节流的
UDP 是面向报文的

所谓“UDP 面向报文”，意思是应用层一次发送一个数据报，接收方接收时也以一个独立报文为单位处理，协议本身保留消息边界。

这并不意味着 UDP 比 TCP 高级，而是意味着 UDP 本身不强制提供：

全连接统一排序
全连接可靠重传
全连接按序交付

也正因为底层没有把这些能力写死，QUIC 才能在 UDP 之上重新实现一套更适合现代 Web 的传输机制。

可以把 QUIC 粗略理解为：

一个运行在 UDP 之上的、具备传输层能力的协议
它提供可靠传输、拥塞控制、流控、加密握手、多流并发、连接迁移等能力

关键点不在“QUIC 很像 TCP”，而在它把“有序交付”的约束限制在单个流内部，而不是整个连接。

TCP connection
  stream A lost one packet
  -> stream B waits
  -> stream C waits

QUIC connection
  stream A lost one packet
  -> stream A waits
  -> stream B can continue
  -> stream C can continue

这就是 HTTP/3 相比 HTTP/2 的核心优势之一：一个流丢包，不必把同一连接中的其他流一起拖住。

十、SSE 和 WebSocket 分别适合什么场景

现代 Web 开发里，很多“实时通信”需求并不是都要上 WebSocket。常见还有 SSE。

1. SSE

SSE 的全称是 Server-Sent Events。它本质上是：

基于 HTTP 长连接
响应类型通常为 text/event-stream
由服务器持续向客户端单向推送文本事件

所以：

SSE 是单向通信
适合服务端持续推消息给浏览器

典型场景包括：

AI 对话流式输出
实时通知
日志流展示

2. WebSocket

WebSocket 则是在 HTTP 握手后升级协议，建立一个持久的双向通信通道。

它的特点是：

双向通信
文本和二进制都支持
更适合高频双向交互

典型场景包括：

在线聊天
协同编辑
实时游戏

如果只是服务端不断推送消息给前端，SSE 往往更简单；如果需要真正的双向实时交互，才更适合选 WebSocket。

十一、把这些概念串回一条完整访问链路

当你在浏览器输入一个 https:// 地址时，背后大致发生的是：

浏览器解析 URL，确定协议、域名、路径和端口
通过 DNS 查询域名对应的 IP
在局域网内通过 ARP 找到下一跳设备的 MAC 地址
与服务器建立 TCP + TLS 或 QUIC 连接
如果是 HTTPS over TCP，先完成 TLS 握手
发送 HTTP 请求，接收状态码、响应头和响应体
继续请求 CSS、JS、图片、接口数据
浏览器解析资源并渲染页面

如果站点使用 HTTP/2：

你会得到多路复用能力
但仍然受限于 TCP 的传输层队头阻塞

如果站点使用 HTTP/3：

你会基于 QUIC 获得更灵活的多流传输
丢包时其他流不容易被一起卡住
移动网络切换和弱网环境下体验通常更稳定

十二、总结

现代 Web 协议栈不是“某一个协议单独解决所有问题”，而是一层层协作的结果：

DNS 负责先找到目标 IP
ARP 负责本地链路上的地址解析
TCP/UDP/QUIC 负责传输层行为
TLS 负责安全握手和加密传输
HTTP 负责应用层的请求和响应语义
SSE 和 WebSocket 则是在应用层针对实时通信需求做出的不同选择

如果要用一句话概括 HTTP/3 出现的价值，那就是：

HTTP/2 已经把应用层做得足够高效，而 HTTP/3 通过 QUIC 继续解决了 TCP 在现代 Web 场景里的天然限制。

当这些概念放回同一条链路中理解后，很多零散的术语其实会自然串起来。