网络基础 — 一次请求在网线上到底走了几个来回Networking Fundamentals: TCP/UDP, HTTP/1.1·2·3·QUIC, DNS, TLS Handshake, L4 vs L7 LB

问题场景 + 需求约束

你在为一个全球 API 平台设计接入层：5000 万用户散布五大洲，移动端占七成，网络丢包率常态 1–3%；API 请求 p99 延迟目标 < 150ms，其中连接建立（DNS + TCP + TLS）往往就吃掉移动端首字节时间的一半。一个从东京发往美西机房的请求，光物理往返（RTT）就 ~120ms，握手若要 3 个 RTT 就是 360ms——用户还没看到一个字节。

问题不在「加机器」，而在每一个 RTT 都要抠：DNS 怎么把用户导到最近的健康机房、传输层用 TCP 还是 UDP、握手怎么从 3 个 RTT 压到 0、负载均衡在第 4 层还是第 7 层做。这四件事决定了首包延迟，也是架构师面试里区分「会调 Nginx」和「懂网络」的分水岭。

高层架构（一次请求的网络路径）

graph LR
    U["客户端
移动/浏览器"]
    DNS["DNS 解析
GeoDNS + Anycast"]
    EDGE["Edge / L4 LB
Anycast VIP · DSR"]
    L7["L7 LB / 网关
TLS 终止 · 路由"]
    APP["App 集群"]

    U -->|"① 域名→IP"| DNS
    U -->|"② TCP/QUIC 握手"| EDGE
    EDGE -->|"③ TLS 握手 + HTTP"| L7
    L7 -->|"④ keep-alive 连接池"| APP

    classDef client fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef edge fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef app fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    class U client
    class DNS,EDGE,L7 edge
    class APP app

DNS 决定去哪个机房；L4 决定进哪台边缘；L7 终止 TLS 并按路径/租户路由；到源站复用长连接省握手

四个组件各管一段延迟：DNS 把用户就近导流（Anycast 让「最近」由 BGP 路由自动决定）；L4 LB 按连接四元组转发、吞吐极高但不看内容；L7 LB/网关 终止 TLS、看到 HTTP 报文才能做路径路由、限流、灰度；到源站用连接池 keep-alive 摊掉握手。理解这条链，才能定位「慢在哪个 RTT」。

关键技术点

1. TCP vs UDP：可靠有序 vs 无连接低延迟

原理：TCP 提供可靠、有序、面向连接的字节流——三次握手建连、序列号 + ACK 重传丢包、滑动窗口做流控、拥塞控制（Cubic/BBR）避免压垮网络。代价是：建连要 1 个 RTT，且字节流的「有序」是把双刃剑——一个包丢了，后面已到达的字节也必须在内核缓冲区里干等重传，这就是队头阻塞（HOL blocking）的根源。UDP 则是无连接的数据报：发出去不管到没到、不排序、无拥塞控制，零握手、零队头阻塞，但可靠性/有序/拥塞全得应用层自己造。

# 选型直觉：先问「丢一个包，业务能不能接受？」
可丢、要最新   → UDP（实时语音：丢帧不如等旧帧）
不可丢、要有序 → TCP / QUIC（API、文件、支付）
要有序但怕队头阻塞 + 移动端频繁切网 → QUIC（HTTP/3）

2. HTTP 演进：队头阻塞的三层围剿

原理：HTTP 性能史，本质是与队头阻塞的三次战争。HTTP/1.1 一条连接一次只能处理一个请求（pipelining 因实现问题几乎废弃），浏览器只好开 6 条 TCP 并发——这是连接级队头阻塞。HTTP/2 在一条 TCP 上做应用层多路复用：把请求切成带 stream id 的 frame 交错传输，解决了应用层队头阻塞——但所有 stream 仍共享一条 TCP 字节流，一个 TCP 包丢失会卡住全部并发 stream（传输层队头阻塞仍在，且比 HTTP/1.1 更痛，因为 6 条连接的损失被压进 1 条）。HTTP/3 干脆抛弃 TCP，在 QUIC 上跑：每条 stream 有独立的序列空间，丢包只卡它自己那条流，其余照常交付——队头阻塞被彻底解决。

关键洞察：HTTP/2 在丢包高的移动/跨洋链路上，性能可能不如 HTTP/1.1 的多连接——因为把所有蛋放进一条 TCP 篮子，篮子一晃全撒。这正是必须下沉到 QUIC 的原因：队头阻塞不在应用层，光升级 HTTP 版本治不了根，得换传输层。

3. TLS 握手：从 2-RTT 到 0-RTT，以及重放的坑

原理：TLS 在明文 TCP 上叠加加密。TLS 1.2 需要 2 个 RTT（ClientHello→ServerHello+证书→密钥交换→Finished）才能发第一个字节，叠加 TCP 的 1-RTT 就是 3 个 RTT。TLS 1.3 砍掉一轮协商，只要 1 个 RTT；对回访用户用会话票据（session ticket）可做 0-RTT：客户端在第一个包里就带上应用数据（early data），握手与数据并行。QUIC 更进一步，把传输握手和 TLS 握手合并，新连接 1-RTT、回访 0-RTT。省下的每个 RTT 在跨洋链路上就是几十上百毫秒。

sequenceDiagram
    participant C as Client
    participant S as Server
    Note over C,S: TLS 1.2 (2-RTT)
    C->>S: ClientHello
    S->>C: ServerHello + Cert
    C->>S: KeyExchange + Finished
    S->>C: Finished ✓ 才能发数据
    Note over C,S: TLS 1.3 0-RTT (回访)
    C->>S: ClientHello + early data (请求已在此)
    S->>C: 响应 + Finished

4. DNS + L4 vs L7 负载均衡：流量怎么落到最近的健康机房

原理：请求发出前先要 DNS 解析——递归解析器逐级问 root→TLD→权威服务器，靠 TTL 缓存避免每次都走全程。全球化用两招：GeoDNS 按解析者地理位置返回不同 IP；Anycast 让同一个 IP 在多地宣告，BGP 自动把用户路由到网络最近的节点。流量到了机房，负载均衡分两层：L4（传输层）只看 IP:Port 四元组做连接转发，不解密、吞吐极高、常配 DSR（回包绕过 LB 直返）；L7（应用层）终止 TLS、解析 HTTP，才能按 URL 路径/Header/Cookie 路由、做金丝雀、限流、WAF——代价是每连接都要解密解析，成本高得多。

# 生产常见组合：Anycast → L4（抗量+均衡）→ L7（智能路由）
Client --DNS/Anycast--> [L4 LB: 一致性哈希选边缘, DSR 回程]
                         --> [L7 网关: 终止 TLS, /v2/* 灰度 5%]
                             --> App 连接池 (keep-alive 复用, 免重复握手)
# L4 用一致性哈希是为了后端增减时不打乱既有连接（见 Day 4 分片）

扩展与优化

• 连接复用打底：到源站永远用 keep-alive 连接池，把 TCP+TLS 握手摊到成百上千请求上——这是省 RTT 性价比最高的一招。
• 0-RTT 递进：TLS 1.3 → HTTP/3 0-RTT，回访用户首包近乎零握手；但严守幂等约束。
• 就近终止 TLS：在离用户最近的边缘节点终止 TLS（握手 RTT 短），边缘到源站走已建好的长连接（见 Day 28 CDN/Edge）。
• 拥塞控制升级：长肥管道（高带宽高延迟，如跨洋）从 Cubic 换 BBR，按实测带宽/RTT 建模，吞吐更稳。
• 下一步：多区域就近路由与故障转移（Day 42）、边缘缓存卸载回源（Day 28）。

常见陷阱 + 面试问题

高频追问：

1. 画出一次 HTTPS 请求从输域名到收到首字节，经过哪些 RTT？各能怎么省？
2. HTTP/2 已经多路复用了，为什么还要 HTTP/3？TCP 队头阻塞具体怎么发生？
3. L4 和 L7 负载均衡分别在什么层、能看到什么、什么场景必须用 L7？
4. Anycast 怎么实现「就近」？它对 TCP 长连接有什么隐患（路由抖动换节点）？
5. TLS 1.3 0-RTT 为什么快、为什么危险？你会怎么在网关层安全启用它？

深入资源

• 《High Performance Browser Networking》（Ilya Grigorik，hpbn.co 免费在线）：TCP/UDP/TLS/HTTP 各层延迟来源与优化的权威教材。
• Cloudflare Blog：HTTP/3 past-present-future、TLS 1.3 概览、0-RTT——队头阻塞与握手优化的一手讲解。
• 《Designing Data-Intensive Applications》（Kleppmann）第 8 章：网络的不可靠性、超时与分区，把「网络」放进分布式系统语境。
• RFC 9000 (QUIC) / RFC 9114 (HTTP/3) / RFC 8446 (TLS 1.3)：协议一手规范，读握手与 0-RTT anti-replay 部分即可。

深入思考（点击展开答案）