type
status
date
slug
summary
tags
category
icon
password

引言

在当今的互联网应用中，「网络速度」往往是影响用户体验的关键因素之一。即使后端服务器处理能力和程序性能再强大，如果网络本身的延迟过高或可靠性不足，也会导致用户体验“卡顿”甚至无法访问。本篇文章从多维度探讨如何构建“足够快”的网络服务，既包含可量化的延迟指标，也涵盖 HTTPS 加密、现代拥塞控制、域名解析和 QUIC 等方方面面。

常见延迟指标

在开始优化网络之前，先了解一些重要的操作或事件所需的时间量级非常必要。下表给出了各种常见操作的延迟范围（其中 ns 表示纳秒，μs 表示微秒，ms 表示毫秒，s 表示秒）：
操作
延迟
CPU 从一级缓存中读取数据
1 ns
CPU 分支预测错误（Branch mispredict）
3 ns
CPU 从二级缓存中读取数据
4 ns
线程间，共享资源加锁/解锁
17 ns
在 1Gbps 的网络上发送 2KB 数据
44 ns
访问一次主存
100 ns
使用 Zippy 压缩 1KB 数据
2,000 ns ≈ 2 μs
从内存顺序读取 1 MB 数据
3,000 ns ≈ 3 μs
一次 SSD 随机读
16,000 ns ≈ 16 μs
从 SSD 顺序读取 1 MB 数据
49,000 ns ≈ 49 μs
一个数据包在同一个数据中心往返
500,000 ns ≈ 0.5 ms
从磁盘顺序读取 1 MB 数据
825,000 ns ≈ 0.8 ms
一次磁盘寻址
2,000,000 ns ≈ 2 ms
一次 DNS 解析查询
50,000,000 ns ≈ 50 ms
把一个数据包从美国发送到欧洲
150,000,000 ns ≈ 150 ms
在宿主机中冷启动一个常规容器
5,000 ms ≈ 5 s

核心对比：

  • CPU 缓存操作（纳秒级） 比 磁盘随机访问（毫秒级） 快 百万倍。
  • 主存访问（100ns） 比 SSD 随机读（16μs） 快 两个数量级。
  • 数据中心内部通信（0.5ms） 比 跨洲通信（150ms） 快 300倍。
  • 磁盘顺序读取（0.8ms） 比 冷启动容器（5s） 快 6,000倍。
这表清晰地展现了延迟的“金字塔”：硬件越接近 CPU，速度越快；网络和系统层级越高，延迟越大。
提示：地理物理距离限制往往无法突破，例如从上海到美国的请求延迟很难低于 750 ms。这意味着在跨国环境中，物理距离导致的时延并非通过软件层面即可完全消除。

HTTPS 请求与优化思路

HTTPS 五大阶段与 RTT 影响

一个完整（且未复用连接）的 HTTPS 请求通常包含五个阶段：
  1. DNS 域名解析
  1. TCP 握手
  1. SSL 握手
  1. 服务器处理
  1. 内容传输
下图展示了每个阶段所需的 RTT（往返时间）：
notion image
因此，整个请求往往需要 5 个 RTT：
  • 1 RTT（DNS Lookup）
  • 1 RTT（TCP Handshake）
  • 2 RTT（SSL Handshake）
  • 1 RTT（数据传输）
以 北京 -> 美国洛杉矶 为例，假设单程 RTT ~190 ms，则 HTTPS 请求的时延至少是 4 × 190 ms + 服务器处理时间。由于 RTT 反映的是因物理距离带来的延迟，而 SSL 阶段又包含大量的加密/解密计算消耗。因此，优化工作应该集中在减少 RTT 和降低 SSL 计算量上。由此可见，减少 RTT 和加速加密计算 是提升跨国访问性能的重中之重。

curl 分析各阶段耗时

可以使用 curl -w 命令来打印 HTTPS 请求过程中的各项时延：
其中常见的关键变量有：
  • time_namelookup：DNS 解析所花费的时间
  • time_connect：建立 TCP 连接的时间
  • time_appconnect：完成 SSL/TLS 握手的时间
  • time_total：整个请求总耗时

HTTPS 优化手段总览

  1. 域名解析优化：减少 DNS 解析时间（例如，提前获取缓存）。
  1. 内容压缩：减小数据体积（Gzip / Brotli 等），降低网络传输量。
  1. SSL/TLS 优化：升级至 TLS 1.3，可将 SSL 握手时延从 2 RTT 减到 1 RTT。
  1. 传输层优化：使用先进的拥塞控制算法（如 BBR）。
  1. 网络层优化：使用商用的 动态加速服务（CDN、Akamai、CloudFront 等）。
  1. 升级 HTTP 协议：采用 HTTP/2 或基于 QUIC 的 HTTP/3。

域名解析与 DNS 优化

域名解析过程

平时我们在浏览器中输入域名访问网站时，往往经过如下解析流程：
notion image
notion image
  1. 用户向 DNS 解析器（LocalDNS）发送请求（如 114.114.114.114）。
  1. DNS 解析器检查自身缓存，若未命中，则向 根域名服务器 查询本域名所属的 TLD 域名服务器（.com、.cn 等）。
  1. DNS 解析器获得对应 TLD 服务器信息后，继续查询该域名的 权威域名服务器。
  1. 权威域名服务器返回最终的解析记录到 DNS 解析器，然后本地用户得到 IP 地址。
注：有人说“全球只有 13 台根域名服务器”，其实这是 13 个根服务器逻辑编号，真实物理部署数量远超 13 台。

排查域名解析故障

  • nslookup <域名> 查看域名解析结果
  • dig @8.8.8.8 <域名> 使用不同的 DNS 解析器来定位问题

DNS 系统设计与 HTTPDNS

  1. DNS 系统设计
      • 可以将「权威域名服务器」放在 SLB 后面，或使用 OSPF Anycast 形式避免单点故障。
      • 考虑“自建集群 + 公有云”混合部署，提高服务可靠性。
      解决方案一：SLB（负载均衡）
      • 将域名服务器放在 SLB（Server Load Balancer，负载均衡器） 后面。
      • 负载均衡的作用是将流量分发给多个后端服务器。
      • 好处：
          1. 如果一个服务器挂了，流量会自动切换到其他服务器，服务不会中断。
          1. 提高系统的扩展性，无论有多少流量，随时可以添加服务器应对。
      解决方案二：OSPF + Anycast
      • OSPF（Open Shortest Path First） 是一种网络路由协议，用于选择最佳路径。
      • Anycast 是一种技术，允许多个服务器共享一个 IP 地址，用户会被路由到离自己最近的服务器。
      • 结合 OSPF 和 Anycast 技术：
          1. 用户的查询请求会被路由到距离最近的服务器，减少查询延迟。
          1. 如果某一个服务器宕机，OSPF 路由协议会自动更新，将流量切换到其他服务器。
      总结：无论是 SLB 还是 Anycast，都可以避免单点故障，让你的域名解析服务更加高可用。
      如果生产环境要进行很大风险性的操作，除了慎之又慎外，合理的方式应该使用一种二次确认的方式。例如，修改一个 iptables 规则，修改之后增加 10 分钟“观察期”。观察期结束后，系统自动恢复原来的配置，运维人员确认观察期内数据没有任何问题之后，再执行正式的操作。
  1. HTTPDNS：绕过本地DNS
      2. notion image
      在网络环境复杂或“本地 DNS”不稳定的情况下，客户端可直接通过 HTTP/HTTPS 协议向特定“软件定义解析服务”请求域名解析（例如运营商、公共云提供的 HTTPDNS 服务），跳过默认的 UDP DNS 解析过程，有效避免 DNS 污染和 LocalDNS 宕机。

内容压缩：Gzip 与 Brotli

在大多数网络请求中，传输的数据越小，速度越快，尤其是图片、静态文本等体量较大的资源文件。
下图展示了 HTTP 客户端 和 服务器 之间针对压缩算法的协商过程：
notion image
  • 客户端在 Accept-Encoding 首部列出支持的压缩算法（如 gzip、br、deflate）。
  • 服务端选择其中一种可兼容的算法，响应时带 Content-Encoding 指明压缩方式。

Brotli：更高的压缩率

notion image
  • Brotli 由 Google 推出，针对文本型内容（HTML、CSS、JS）拥有更高压缩效率。
  • 压缩比可比传统 gzip 高出 17%~30%。
在 Nginx 中同时启用 Brotli 与 Gzip，例如：

HTTPS 加密原理

对称加密与非对称加密

加密和解密的过程可以使用一个密钥（Share key）作为参数，密钥必须保密，但加密和解密的过程可以公开。换句话说，只有知道密钥的人才能解密密文。常用的对称加密算法有 AES、ChaCha20、DES 等。因此，只要密钥不被中间人获取，两方通信的机密性就能得到保证。
notion image
对称加密的核心在于如何保证密钥不被暴露。但由于 HTTP 通信模型是 1 对 N，如果所有人都共享同一个密钥，其实就相当于没有加密。
notion image
如果由每个客户端随机生成一个密钥，并传输给服务端，那么就不存在共享密钥的问题了。但问题是客户端随机生成的密钥怎么传给服务端，同时不被别人知道。因为协商过程是明文的，密钥依然存在被中间人截获的可能性。
非对称机密：简单说就是有两把密钥，通常一把叫做公钥（Public Key），可以向公众开放。另一把叫私钥或密钥（Private Key），私钥是必须保密的。用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
notion image
非对称加密算法通常需要更多的计算资源，尤其在加密或解密大量数据时计算消耗更大。因此，我们使用计算效率更高的对称加密算法来加密 HTTP 内容，非对称加密算法来加密对称加密的密钥。请看下面的过程：
  • 首先，客户端与服务端会进行协商，确定一个双方都支持的对称加密算法，例如 AES。
  • 确认对称加密算法后，客户端会随机生成一个对称加密密钥 K。
  • 客户端使用服务端的公钥加密密钥 K，并将密文传输给服务端。此时，只有服务端的私钥能够解密密钥 K。

数字证书与数字签名

在实际的 HTTPS 通信中，通常采用“非对称加密”来交换“对称密钥”，再使用对称密钥快速加解密数据。但有一个重要问题：公钥仍有被劫持的可能性，公钥被劫持怎么办？
  • 数字证书（CA 机构颁发）：网站在使用 HTTPS 前，需要向权威 CA 机构申请，证书内包含域名、公钥、过期时间等。
  • 数字签名：CA 机构使用自己的私钥对「证书明文数据 T 的 Hash 值」做加密得到签名 S；浏览器可用 CA 的公钥反向验证签名是否匹配，判断证书是否被篡改。
notion image

HTTPS 通信流程

notion image
  1. 服务器 向 CA 申请证书并在 TLS 握手 阶段把证书传给客户端。
  1. 客户端 验证证书合法性并提取公钥。
  1. 客户端 使用公钥加密随机生成的对称密钥 K 发送给服务器，只有私钥能解密。
  1. 后续通过 Session ID 复用密钥，避免重复握手。

HTTPS 性能优化实践

TLS 版本与证书类型

  1. TLS 1.3
      2. 将握手从 2 RTT 减到 1 RTT，提升连接建立速度；支持更安全的密码套件。
  1. RSA 证书
      2. 算法成熟、兼容性好，但不支持「完美前向保密（PFS）」。
  1. ECC 证书
      2. 以更小的密钥长度提供更强或相当的安全性，支持 PFS，计算速度快但兼容性略逊于 RSA。
      Nginx 可配置 “双证书”，在 TLS 握手阶段根据 Cipher Suite 协商返回相应类型的证书。
      使用 openssl ciphers -v 命令，可查看服务端配置在实际环境下支持的密码套件及优先级。

HTTPS 会话缓存与 OCSP Stapling

  • 会话缓存：使后续连接复用之前的握手结果，减少重复 SSL 握手带来的延迟。
  • OCSP Stapling：服务器提前获取并缓存证书的 OCSP 响应，客户端无需再额外发起 OCSP 查询，从而降低请求耗时。
notion image

性能测试：QAT、ECC 与 RSA 对比

对 RSA / ECC 证书、TLS1.2 / TLS1.3 版本，以及 QAT（Quick Assist Technology） 硬件加速进行多组压测，结果如表所示：
证书、TLS 版本配置
QPS
单次发出请求数
延迟
RSA 证书 + TLS1.2
316.20
100
316.254 ms
RSA 证书 + TLS1.2 + QAT
530.48
100
188.507 ms
RSA 证书 + TLS1.3
303.01
100
330.017 ms
RSA 证书 + TLS1.3 + QAT
499.29
100
200.285 ms
ECC 证书 + TLS1.2
639.39
100
203.319 ms
ECC 证书 + TLS1.3
627.39
100
159.390 ms
  • ECC 证书 性能显著优于 RSA；
  • QAT 硬件加速虽可提升 RSA 性能，但依然不及 ECC 原生表现，且需要额外硬件成本。
推荐：使用 TLS1.3 + ECC 证书 作为兼顾安全与性能的最佳实践。
优化完成后可通过 https://myssl.com/ 验证配置是否生效。

网络拥塞控制：BBR 与现代算法

网络传输效率（吞吐量）取决于RTT（往返时延）和带宽：
  1. RTT 越小，延迟越低；
  1. 带宽越高，单位时间能传输的数据越多。
网络拥塞控制的目标是：调整发送速率，避免过多数据进入网络，既充分利用带宽，又避免丢包或长时间延迟。
关键术语解释：
  1. RTprop（最小时延）：水管的长度，距离越远延迟越大。
  1. BtlBw（瓶颈带宽）：水管最窄处的流量，决定最大数据速率。
  1. BDP（带宽-时延积）：水管中能同时容纳的数据量，= 带宽 × 时延。
  1. inflight 数据：已发出但未被确认的数据包，相当于水管中的水流量。
网络状态的三个区间：
  1. (0，BDP) 应用受限区： 发送数据量不足，未占满带宽，RTT 最小，速率最高。
  1. (BDP，BDP + 缓冲区) 带宽受限区： 数据量达到带宽容量，RTT 增大，速率达到瓶颈。
  1. (BDP + 缓冲区，∞) 缓冲受限区： 数据量超过网络容量，丢包增多，延迟和速率受影响。
理想状态：
inflight 数据量接近 BDP，既满载带宽，又不丢包。
  • RTprop：最小 RTT，对应物理距离的基准时延
  • BtlBw：瓶颈带宽
  • BDP（Bandwidth × Delay Product）：可同时在网络中“飞行”的数据量

传统拥塞控制的局限

诸如 Reno、Cubic 等算法往往把「丢包」当成拥塞信号，这在高带宽、高延迟或者微丢包的网络中表现不佳，难以充分利用链路。

BBR：带宽与延迟双探测

  1. 最大带宽（max BW） 与 最小延迟（min RTT） 交替测量
  1. 运行态分为 4 个阶段：
    1. STARTUP：快速探测瓶颈带宽
    2. DRAIN：降低速率，清空缓存队列
    3. PROBE_BW：稳定发送速率并偶尔测试是否可进一步提升
    4. PROBE_RTT：主动降低发送量测量 min RTT
结果证明，在轻微丢包环境下，BBR 能维持高吞吐量，显著优于传统丢包驱动算法。

动态加速：弱网场景的利器

对于无法缓存的动态请求，传统 CDN 针对静态内容的就近分发策略并不适用。此时「动态加速」可以发挥作用——通过优化网络传输路径，在跨国、跨运营商或弱网环境中显著降低延迟。

原理与过程

  1. CNAME 配置：将业务域名解析指向加速服务商的全球加速网络。
  1. 加速节点探测：转发节点测量丢包、RTT 等网络质量。
  1. 优选路由：选择最优路径，绕过公共 Internet 的拥塞路段。
  1. 动态加速效果：东南亚 → 香港的测试中可降低 30%~50% 的延迟。

为什么有效

  • 不同国家和地区的网络质量差异大，官方路由易绕远路；
  • 专用加速网络可避开拥塞，提供更稳定的时延保障。

QUIC 与 HTTP/3：下一代传输协议

早期 HTTP 协议基于 TCP 传输，即使升级到 HTTP/2，依然存在 队头阻塞、连接建立时延高等问题。为此，Google 推出了基于 UDP 的 QUIC 协议（Quick UDP Internet Connection，快速 UDP 网络连接），并被标准化为 HTTP/3，旨在取代 TCP，成为新一代互联网的主流传输协议。
根据图所示的各版本 HTTP 协议区别，可以看出 HTTP/3 最大的特点是：底层基于 UDP 、默认集成了 TLS 安全协议。
notion image
QUIC 出现之前，HTTP 采用 TCP 作为底层协议来实现可靠的数据传输。
TCP 暴露出来的先天设计缺陷体现在以下三个方面：
  • 建立连接时延迟大：HTTPS 初次连接（TCP 握手 + TLS 握手）至少需要 3 个 RTT 才能建立。
  • 队头阻塞问题：以 HTTP/2 为例，一个 TCP 连接上的所有 stream（流，HTTP/2 传输的数据单元）必须按顺序依次传输。如果一个 stream 丢失，后面的 stream 将被阻塞，直到丢失的数据重传。
  • 协议僵化问题：作为一个运行了接近 40 多年的协议，许多中间设备（如防火墙和路由器）已经变得依赖某些隐式规则，打补丁或者说推动 TCP 协议更新脱离现实。

QUIC 核心特性

  1. 连接迁移
      2. QUIC 使用「Connection ID」标识连接，当用户从 Wi-Fi 切换到 4G 时，无需中断重连，显著提升移动端体验。
      notion image
  1. 低时延连接
      2. 以 HTTPS 请求为例，即使是最新的 TLS 1.3 协议，初次连接也至少需要 2-RTT 才能开启数据传输，QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，再经过 TLS 握手才开启数据传输。QUIC 初次连接只需要 1- RTT 就能开启数据传输。
      notion image
  1. 可插拔拥塞控制
      2. 运行在用户态，可灵活选择 Reno、Cubic、BBR 等算法。
  1. 多路并行传输
      2. 每个 Stream 独立重传，不会因一个丢包阻塞所有请求，解决了 TCP 层面的队头阻塞问题，降低对丢包的影响。
      notion image

QUIC 实践与测试结果

爱奇艺在 2022 年测试了 HTTP/1.1、HTTP/2、HTTP/3 在不同网络质量下的性能：
notion image
在相同网络条件下，HTTP/3 的耗时较 HTTP/2 显著降低，降低了近一半，但请求成功率略低。
notion image
猜测原因：
  1. 某些运营商或防火墙阻断 UDP；
  1. QUIC 生态尚在发展，一些老旧设备和网络环境不兼容。
综上所述，无论是服务端还是客户端，集成 QUIC 协议并非易事：
  • 服务端层面：不仅需要适配 QUIC 协议，还要确保与 TCP 协议兼容。此外，TCP 经过多年的深度优化，QUIC 实际的效能表现是否能够与 TCP 相媲美？
  • 客户端层面：需要在适配、收益之间进行成本权衡。采用 QUIC 协议的客户端必须具备降级容错能力，并准备长时间同时维护新旧两种网络库。
部署注意：服务端需在并行兼容 TCP + QUIC，客户端也需要具备降级策略，在不支持或阻断 UDP 的场景退回到 TCP/HTTP2。

小结

  1. 网络优化是端到端的系统性工作，通常遵循二八原则：80% 的性能瓶颈往往来源于 20% 的关键环节。
  1. HTTPS 升级 不仅要考虑安全（TLS1.3、ECC 证书等），也要在性能（握手次数、硬件加速）上下功夫。
  1. 域名解析 是整个请求的起点，LocalDNS 故障或污染会让任何后端高可用架构失效。
  1. 拥塞控制算法（如 BBR） 与 动态加速 能在弱网或跨国场景下显著提升吞吐量和响应速度。
  1. QUIC/HTTP/3 代表了下一代的网络传输趋势，解决了 TCP 时代的队头阻塞、连接迁移等痛点，但仍需要在兼容性和成熟度上持续完善。
通过以上各方面的综合实践，你将能更好地构建一个「足够快」且稳定的网络服务，为用户提供更佳的访问体验。
本文主要受益于isno分享，使我收益颇丰，感谢大佬分享。
 
Relate Posts
深入Linux内核网络技术
云原生技术概论
深入高可用系统原理与设计【读书笔记】
中年觉醒：人生的第二曲线
人生最大杠杆在于与高质量的人同行
投资这件事
2023雷军年度演讲—“成长”深入Linux内核网络技术