浏览器访问 HTTPS 网站时数据如何传输
你在 Chrome 里打开一个 HTTPS 网站时，浏览器到底做了哪些网络动作？ 很多解释会把 HTTPS、TLS、TCP、QUIC 混在一起讲，听起来像一锅粥。 本文用工程视角把它们拆开，并用两张图把关系一次讲透。
一句话总结
HTTPS 是“应用层语义”，QUIC 是“传输层协议”。
HTTP/1和HTTP/2，HTTPS 跑在 TCP 上； HTTP/3，HTTPS 跑在 QUIC 上。HTTPS和QUIC是上下层关系。
1. 先把“层级”搞清楚
用最简化的网络分层来看：
| 层级 | 你会在浏览器/网络里看到的名字 | 它负责什么 |
|---|---|---|
| 应用层 | HTTP / HTTPS | 请求/响应语义：URL、Header、Body、状态码、缓存等 |
| 传输层 | TCP 或 QUIC | 怎么把字节可靠地传过去：握手、重传、拥塞控制、多路复用等 |
| 网络层 | IP | 路由与寻址：从你这台设备把包送到目标服务器 |
HTTPS 不负责“怎么传”，它只规定“你传的网页请求长什么样”； QUIC 不关心“你传的是什么网页”，它只负责把数据更快、更稳地送到对端。
2. 传统 HTTPS 是怎么跑的（HTTPS over TCP）
传统路径可以概括为： HTTPS = HTTP + TLS，而 TLS 通常运行在 TCP 之上。
你访问一个 HTTPS 网站时，典型流程是：
这条路径的特点是“中间设备很熟”。 TCP 的行为模式、TLS 握手的阶段性、以及连接层面的特征都非常标准化。 在工程侧，这意味着生态成熟； 在网络侧，这也意味着各种代理、网关、加速与审计设备都对它“看得很懂”。
3. QUIC 解决什么问题
QUIC 的一句话解释是： 它把传统上分散在 TCP、TLS、以及部分 HTTP 能力中的关键机制“工程化整合”，并运行在 UDP 之上。 它的目标是让传输更快、更适合移动网络。
| 项目 | TCP（传统） | QUIC（现代） |
|---|---|---|
| 底层承载 | TCP | UDP |
| 握手成本 | TCP + TLS（常见 2~3 RTT） | 更接近一次握手（常见 1 RTT） |
| 多路复用 | 可能受队头阻塞影响 | 更天然的多路复用，降低队头阻塞问题 |
| 移动网络体验 | 切网/IP 变化更容易断 | 对切网更友好，连接迁移能力更强 |
4. HTTPS + QUIC = HTTP/3
当你看到这些说法： HTTPS over QUIC、HTTP/3、QUIC TLS 流量， 它们基本是在描述同一件事的不同侧面。
把它重新放回分层结构就非常清晰：
应用层：HTTPS（HTTP 语义）
传输层：QUIC（基于 UDP）
网络层：IP
所以，HTTP/3 不是“替代 HTTPS”，而是把 HTTPS 的承载从 TCP 切换到了 QUIC。
5. 简单的理解方式
- HTTPS 是你在浏览器里看到的“安全网页协议”。它规定网页怎么请求、怎么响应。
- QUIC 是底层“怎么把数据更快送到服务器”的方式之一。它不改变网页的语义，只改变传输路径。
- HTTP/3 = HTTPS over QUIC。这是现代浏览器与网站逐步普及的方向。