Engineering Review Lab

Appearance

09. 现代移动端网络底座：HTTP/1.1、HTTP/2、HTTP/3(QUIC) 与弱网治理 ​

一句话定位：这一页不是教你背协议名词，而是帮你建立移动端网络底座的判断框架：DNS 怎么选、连接怎么建、请求库怎么配、UI/状态层怎么承接弱网结果，以及为什么今天很多优化会从 HTTP/2 继续走向 HTTP/3 / QUIC。

相关专题：00 基础知识（Foundations） · TLS 1.2、ECDHE 密钥协商与 CA 信任链 · 08. 移动端弱网与长连接治理：WebSocket/gRPC、智能心跳重连与离线 WAL 同步 · Token 鉴权体系、JWT、OAuth2 与移动端双 Token 自动无感刷新

这页解决什么问题 ​

  • 为什么同样是“一个请求”，在办公室 Wi‑Fi 很快，进电梯或地库后却会突然卡一大截？
    • 一句话答：因为移动端真正耗时的不只是接口执行，还包括 DNS 解析、TCP/TLS/QUIC 建连、丢包重传、连接复用、网络切换；弱网下最容易暴露的是连接层而不是业务层。
  • 为什么 HTTP/2 已经多路复用了，弱网下还是会出现“一个包丢了，整个连接像都慢了”的体感？
    • 一句话答：HTTP/2 只是把“多条请求”放进一个 TCP 连接里，TCP 依然要求按序交付，所以一个包丢失仍可能拖住整条连接上的多个流。
  • HTTP/3 / QUIC 到底解决了什么？是不是上了它就没有弱网问题了？
    • 一句话答：QUIC 主要解决 TCP 层队头阻塞、握手时延、网络切换重连成本，但不解决 DNS 选错、服务端慢、业务重试乱配、UI 没做取消与兜底。
  • Android / Flutter / Compose 里，协议升级和日常开发有什么真实关系？
    • 一句话答：你日常写的是 OkHttp、Dio、Repository、ViewModel/Notifier、取消请求和错误态，但这些体验的上限，最终受到底层连接协议、TLS、安全策略和网络治理能力约束。
  • HTTPDNS、阿里 DNS、一键登录这类能力应该放在什么层看？
    • 一句话答：它们都属于“移动网络底座”的组成部分，但不是这一页的展开重点；这里先把它们放回正确层级，并说明它们解决什么典型问题、该去哪里继续看。

一张图看懂 HTTP/1.1 / 2 / 3 ​

HTTP/1.1 到 HTTP/3 对照图

图注：HTTP/1.1 的问题主要是“连接太多、握手太多”；HTTP/2 的改进是“把很多请求塞进一个 TCP 连接”；HTTP/3 则进一步把“连接复用”从 TCP 约束里解放出来，用 QUIC 在用户态按 Stream 管理传输。

先别急着记定义，先记体感差异 ​

  • HTTP/1.1 像开很多条单车道：每条道都能跑，但建太多连接，握手和维护成本高。
  • HTTP/2 像把很多车并进一条高速：平时效率很高，但如果高速某段因为丢包被卡，后面的很多车都会受影响。
  • HTTP/3 像高速仍是一条入口，但每条业务流在传输层更独立：一条流出问题，不必让别的流一起等。

为什么 HTTP/2 弱网仍会卡 ​

先解决一个常见误解 ​

很多人听到“HTTP/2 多路复用”后，会下意识以为它已经彻底解决了并发请求互相影响的问题。这个结论只对了一半。

HTTP/2 的确解决了 HTTP/1.1 应用层的队头阻塞：不用再靠多开很多 TCP 连接来并发请求，多个请求可以复用一条连接里的多个 Stream。

但它没有解决 TCP 自己的按序交付约束。

HTTP/2 与 HTTP/3 的丢包恢复差异图

图注：HTTP/2 的 Stream 是“应用层并发单元”，但真正往外发数据的还是同一条 TCP。只要 TCP 还没等到前面丢失的那段字节，后面的数据就不能按序交给上层，所以用户会感到“明明只丢了一个包，怎么整个页面都慢了”。

这件事在移动端为什么更明显 ​

  • 地铁、电梯、地下车库这类场景里，瞬时丢包和 RTT 抖动 很常见。
  • 移动端往往会同时发很多小请求：接口、图片、埋点、配置、实验开关。
  • 当这些请求共用一个 HTTP/2 连接时，一处丢包可能拖慢整批请求的交付节奏。

举个更贴近 App 的例子 ​

假设首页同时发 6 个请求：

  1. 用户信息
  2. 卡片流
  3. 角标数
  4. 实验开关
  5. 营销弹窗配置
  6. 埋点上报

如果它们都跑在同一个 HTTP/2 连接上，而某个早到的数据包丢了，那么后面即使有些响应片段已经到达设备，也可能因为 TCP 还在等重传而不能及时交付。你看到的现象往往不是“某一个接口报错”，而是：

  • 首屏整体慢一下
  • loading 一起多转半秒到两秒
  • 某些卡片晚出现
  • 页面像“顿了一下”

这就是为什么在极端弱网下，HTTP/2 的理论优势不一定完全转化为体感优势。

QUIC/HTTP3 解决什么与没解决什么 ​

QUIC 主要解决什么 ​

1. 解决 TCP 层队头阻塞 ​

QUIC 建在 UDP 之上，自己在用户态维护可靠传输和流控制。它的关键点不是“UDP 更快”这么简单，而是：不同 Stream 的传输状态不必像 TCP 那样绑定成一个全局按序字节流。

  • 某个 Stream 丢包时，主要影响这个 Stream 自己。
  • 其他 Stream 只要数据已经满足交付条件，可以继续往上层走。

2. 解决握手链路过长 ​

HTTP/1.1 / HTTP/2 通常是：

  • 先 TCP 建连
  • 再 TLS 握手
  • 然后才能发业务数据

HTTP/3 把传输层和加密握手结合得更紧，结合 TLS 1.3 后，首包到可发业务数据的路径更短。这对弱网、高 RTT、冷启动首个请求特别有价值。

3. 解决切网后整条连接作废 ​

TCP 连接由四元组标识：

  • 源 IP
  • 源端口
  • 目的 IP
  • 目的端口

手机从 Wi‑Fi 切到 4G/5G，本地 IP 一变，原 TCP 连接通常就废了。

QUIC 引入 Connection ID，连接标识不再死绑当前 IP。于是网络切换时，连接迁移成本明显更低，用户体感就是：

  • 切网时更不容易整页重新转圈
  • 长列表滚动中发请求没那么容易整体断掉
  • 长连接/流式请求更容易平滑恢复

QUIC 没解决什么 ​

  • 没解决 DNS 解析错地址：域名如果被劫持、缓存脏了、调度 IP 不合理，底层协议再先进也白搭。
  • 没解决服务端本身慢：接口 800ms 花在数据库和下游调用上，不会因为 HTTP/3 自动变 80ms。
  • 没解决业务侧乱重试：比如超时 3 秒、重试 3 次、没有幂等保护，还是会把问题放大。
  • 没解决 UI 没做取消/兜底：页面销毁了还在请求、切 tab 不取消、错误态和骨架屏没设计，用户依然觉得卡。
  • 没解决企业网/防火墙封 UDP：部分网络环境会限制 UDP，这时往往还需要回退到 HTTP/2。

一个实用判断 ​

如果你要回答“HTTP/3 有没有价值”，更准确的说法不是“它更快”，而是：

  • 在弱网、高 RTT、切网频繁的移动端场景里，它更稳，也更容易把延迟尖刺压下去。
  • 但它只覆盖网络底座的一部分，不是万能药。

移动端网络链路分层：DNS、连接、请求库、UI ​

把移动端一次请求拆开看，通常更容易判断问题在哪一层：

移动端网络链路分层图

图注：DNS 层决定“去哪里”；连接层决定“怎么连得快且稳”；请求库层决定“超时、重试、缓存、证书、拦截器怎么配”；应用层负责 Repository/UseCase 等业务编排；UI/状态层负责取消、降级、加载态、错误态和重试交互。

1. DNS 层：先决定“连到谁” ​

这一层处理的是：

  • 域名解析
  • 调度到哪个 IP / 边缘节点
  • 是否命中运营商劫持、脏缓存、TTL 失真

典型问题：

  • 明明接口服务没挂，但某地区用户大量超时
  • 同一个域名在不同网络下解析到质量差的节点
  • 系统 DNS 被运营商污染，导致解析结果不稳定

2. 连接层：再决定“怎么连” ​

这一层处理的是：

  • TCP / TLS / QUIC 建连
  • 连接复用
  • 丢包恢复
  • 切网迁移
  • HTTP/2 / HTTP/3 协商与回退

典型问题：

  • 冷启动首个请求慢
  • 弱网下偶发整批请求一起卡
  • Wi‑Fi 切蜂窝时长连接或请求中断

3. 请求库层：把连接能力变成工程配置 ​

这一层你最常碰到的是：

  • OkHttp / Retrofit
  • Dio / dart:io HttpClient
  • 拦截器、超时、重试、缓存、Pinning、取消、日志

这一层决定的不是协议原理，而是协议能力有没有被你正确用起来。

4. UI / 状态层：把失败变成“可承受的失败” ​

真正影响用户体感的最后一层，是：

  • 页面切走后请求有没有取消
  • 首屏是骨架屏、局部 loading 还是整页菊花
  • 错误态能不能局部重试
  • 数据有没有缓存回显
  • 是否把“网络慢”放大成“整个页面不能操作”

很多所谓“网络优化”最后改的其实不是网络协议，而是这层的交互策略。

Android / Flutter / Compose 映射 ​

先看总映射 ​

层级Android / KotlinFlutter / DartCompose / UI 侧关注点iOS 对照
DNS 层系统 DNS、自定义 Dns、HTTPDNS SDKdart:io / 插件封装 / 平台侧解析通常不直接感知，但会影响首屏与重试策略URLSession / Network.framework + 自定义解析
连接层OkHttp、Cronet、TLS、HTTP/2、HTTP/3Dio 底层 HttpClient、插件桥接 Cronet/平台能力影响加载态时机、取消、切网恢复URLSession、Network.framework
请求库层Retrofit + OkHttp，拦截器、连接池、PinningDio，拦截器、CancelToken、证书校验ViewModel / Notifier 决定怎么消费结果URLSession + adapter
状态/UI 层Repository + UseCase + ViewModel + StateFlowRepository + Notifier/Bloc + AsyncValue/StateCompose UiState、Flutter AsyncValue / sealed stateObservableObject / async-await

结论先说：Android 和 Flutter 的差别，很多时候不在“网络问题本质不同”，而在一边更容易直接触到 OkHttp/TLS 细节，另一边更常通过 Dio + 插件 + 平台桥接去间接使用这些能力。

Android：通常更容易直接触到连接层细节 ​

Android 主流栈里，Retrofit 底层就是 OkHttp，所以你经常能直接配置：

  • connectTimeout / readTimeout / writeTimeout
  • retryOnConnectionFailure
  • ConnectionPool
  • CertificatePinner
  • 应用拦截器 / 网络拦截器

这也是为什么 Android 工程师通常对“连接池、TLS、Pinning、DNS、自定义 Dns、协议版本”更容易形成一手认知。

Flutter：更多通过请求库和平台桥接承接 ​

Flutter 主流是 Dio，但 Dio 本身更偏“请求编排层”，不是完整复刻 OkHttp 的网络栈。

你在 Flutter 里通常会这样分工：

  • 用 Dio 做请求模型、拦截器、超时、错误归一化、401 刷新、取消
  • 用 dart:io HttpClient 或平台插件承接底层证书、代理、平台网络能力
  • 需要更强连接能力时，通过插件桥到 Android/iOS 原生网络栈

这和仓库里参考架构文档的分层是一致的：UI → Notifier/ViewModel → Repository → DataSource(Dio/平台能力)，网络层不应该直接泄漏到 Widget 或 Composable 中。

Compose：协议本身不在 UI 层，但体感问题最后都落到 UI 层 ​

Compose 不会直接让 HTTP/3 生效，但它会决定用户如何感知网络：

  • 页面是否用单一 UiState 表达 loading / success / error
  • 一个子卡片失败，是否拖死整页
  • 列表分页时，是否把“下一页失败”做成局部错误而不是整屏报错
  • 切换页面时，是否及时取消旧请求

所以更准确地说：

  • HTTP/3/QUIC 优化的是连接层上限
  • Compose / Flutter 状态管理决定的是这个上限有没有被用户真正感受到

iOS 只做简要对照 ​

iOS 侧核心概念并不特殊：

  • 仍然要处理 DNS、TLS、连接复用、切网、证书校验
  • 主要入口通常是 URLSession 或 Network.framework
  • ATS 会默认抬高 TLS 合规门槛

差异主要在 API 形态和平台策略，不在网络问题本质本身。这一页以 Android / Flutter 为主，不在这里展开 iOS 工程细节。

保留的关键工程抓手：OkHttp / Dio / TLS / Pinning ​

OkHttp：Android 端最常落地的网络抓手 ​

OkHttp 值得保留，不是因为它“有名”，而是因为它把很多连接层能力以工程配置形式暴露出来了。

你至少要熟这几类配置：

kotlin
val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(30, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .certificatePinner(
        CertificatePinner.Builder()
            .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
            .add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
            .build()
    )
    .addInterceptor { chain ->
        val request = chain.request().newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        chain.proceed(request)
    }
    .build()
  • connectTimeout 更偏建连阶段。
  • readTimeout 更偏“连上了但迟迟收不到数据”。
  • retryOnConnectionFailure 对幂等请求更安全，不能无脑放大到所有写操作。
  • CertificatePinner 是通信安全加固，不是性能优化。

Dio：Flutter 端最常落地的请求编排抓手 ​

Dio 的价值主要在：

  • 统一请求/响应/错误模型
  • 拦截器里做鉴权、埋点、错误归一化
  • 用 CancelToken 承接页面销毁或状态切换
  • 通过队列/锁做 401 无感刷新
dart
final dio = Dio()
  ..interceptors.add(
    InterceptorsWrapper(
      onRequest: (options, handler) {
        options.headers['Authorization'] = 'Bearer ${getToken()}';
        handler.next(options);
      },
      onError: (error, handler) {
        if (error.response?.statusCode == 401) {
          refreshTokenAndRetry(error, handler);
        } else {
          handler.next(error);
        }
      },
    ),
  );

final cancelToken = CancelToken();

一个很常见但很关键的细节是：Flutter 里网络慢，经常不是“请求真的慢很多”，而是页面销毁、切 tab、列表复用时没有及时 cancel，导致过期结果回写 UI。

TLS 与 Pinning：它们是安全底座，不是 QUIC 的替代品 ​

这一页只保留你做移动端时最该记住的判断：

  • TLS 解决的是加密、身份认证、完整性。
  • QUIC / HTTP/3 解决的是更快更稳地传输。
  • Pinning 解决的是即使系统信任链被代理利用，也要额外校验是不是“我认的服务端”。

如果你要深入 TLS 1.2 / 1.3、ECDHE、CA 信任链，请直接看： TLS 1.2、ECDHE 密钥协商与 CA 信任链

HTTPDNS 与一键登录只做摘要入口 ​

HTTPDNS / 阿里 DNS 在这条链路里属于哪一层 ​

它属于 DNS 层，核心价值不是“让请求更快”这么泛，而是：

  • 避开系统 DNS 被劫持或污染
  • 避开某些地区解析结果不稳定
  • 让客户端更可控地拿到可用 IP
  • 给多机房/多边缘节点调度留下空间

它通常解决什么真实问题 ​

  • 某运营商网络下偶发大面积超时，但服务端没挂
  • 同域名解析到质量差节点，导致特定地区首包慢
  • 系统 DNS 缓存脏、TTL 不准、切网后解析结果滞后

这页只保留一个工程结论 ​

很多团队不是“简单接了个 HTTPDNS SDK 就结束”，而是会做二次工程化改造，例如：

  • 把解析结果接入自家请求栈而不是孤立调用
  • 增加过期策略、失败回退、灰度开关
  • 协调 HTTPS 证书校验、Host 头、SNI 与 IP 直连之间的边界
  • 在弱网和切网时处理缓存命中与重新解析时机

也就是说，真实价值不只是“用了 HTTPDNS”，而是把它工程化到能解决线上解析与调度问题。

延伸专题：HTTPDNS / 阿里 DNS 移动端工程化。如果你想真正看懂它为什么不只是 resolveDomain，重点看 Host / SNI / TLS / 回退策略如何一起收口。

一键登录在这条链路里属于哪一层 ​

一键登录更接近 接入层 / 鉴权与运营商能力编排层，不属于 HTTP/3 本身，但它强依赖移动网络环境、运营商链路、超时策略与回退策略。

它通常解决什么真实问题 ​

  • 降低手机号登录输入成本
  • 在注册/登录首转阶段减少流失
  • 借助运营商认证能力缩短登录路径

这页只保留一个工程结论 ​

真实项目里，一键登录插件通常也不是“拿来即用”就够了，往往会做二次工程化改造，比如：

  • 统一 Android / Flutter 的调用封装与错误码映射
  • 处理厂商 ROM、页面生命周期、弹窗时机、返回栈异常
  • 增加兜底：超时后自动回退短信验证码或其他登录方式
  • 把埋点、A/B 开关、风控策略、协议弹窗校验接进去

所以这类能力的复盘重点应该放在：它如何被工程化成稳定的登录入口，而不是只看 SDK API 怎么调。

跳转入口：鉴权主线可先看 Token 鉴权体系、JWT、OAuth2 与移动端双 Token 自动无感刷新；工程化细节再看 移动端一键登录工程化。

反复碰到的问题 ​

1. 为什么切到 HTTP/3 了，首屏还是慢 ​

  • 原因常常不在协议本身：可能是 DNS 慢、接口聚合差、服务端慢、图片太大、UI 等全部接口回来才渲染。
  • 会怎样：你会误以为“HTTP/3 没效果”，其实瓶颈不在连接层。
  • 怎么判断：拆开看 DNS、建连、TTFB、业务处理、首屏渲染各花了多少时间。

2. 为什么弱网下会出现“偶发全部请求都慢一下” ​

  • 常见原因：HTTP/2 连接共用 + TCP 丢包；或者某个网段抖动导致整条连接的有效吞吐瞬时下降。
  • 会怎样：页面不是彻底失败，而是多个模块一起延后。
  • 举例：首页同时请求多个卡片接口，结果它们像商量好一样晚 1 秒出来。

3. 为什么切网后有些请求像失踪了一样 ​

  • 常见原因：老连接失效、DNS 结果过期、上层没有及时取消与重发。
  • 会怎样：用户看到 loading 一直转，或者操作后长时间无反馈。
  • 举例：从公司 Wi‑Fi 走到室外 5G，提交按钮点了但迟迟不成功，最后又重复提交。

4. 为什么 Pinning 一上就出事故 ​

  • 常见原因：只 pin 了单张叶子证书，没有预埋备用公钥或轮换窗口。
  • 会怎样：证书续期后，旧版本 App 大面积握手失败。
  • 举例：服务端证书正常更新，但客户端全量报 SSL 校验错误。

5. 为什么 Flutter 页面对弱网更容易“看起来乱” ​

  • 常见原因：没有 cancel 旧请求、Notifier/Bloc 状态收口不清晰、错误态和局部 loading 没拆开。
  • 会怎样：过期响应覆盖新状态，列表抖动，切页后旧请求还回写。
  • 举例：快速切换筛选条件，最后页面显示的不是最后一次点击对应的数据。

高频面试题 ​

  1. HTTP/2 都已经多路复用了，为什么还需要 HTTP/3？

    答：因为 HTTP/2 的多路复用建立在 TCP 之上，应用层不阻塞不代表传输层不阻塞。弱网丢包时，TCP 的按序交付会拖住整条连接上的多个 Stream；HTTP/3 把可靠传输和流控制搬到 QUIC，能更好隔离不同流之间的影响，并降低握手与切网成本。

  2. HTTP/3 / QUIC 最适合解决移动端什么问题？

    答：最适合解决三类问题：弱网下的丢包拖累、冷启动首请求建连成本、Wi‑Fi 与蜂窝切换时的连接迁移成本。它的价值主要体现在“更稳”和“延迟尖刺更少”，而不是所有请求都绝对更快。

  3. HTTP/3 上线后，是不是可以把 HTTP/2 彻底关掉？

    答：通常不能。因为一部分网络环境会限制 UDP，或中间网络设备对 QUIC 支持不佳，所以工程上通常需要保留 HTTP/2 作为回退路径，而不是孤注一掷只跑 HTTP/3。

  4. OkHttp 和 Dio 在这张图里分别扮演什么角色？

    答：它们更多属于“请求库层”。OkHttp 更靠近 Android 连接细节，方便直接配置 TLS、连接池、Pinning、拦截器等；Dio 更偏 Flutter 侧请求编排与状态接入，常配合 dart:io 或平台插件承接底层能力。

  5. HTTPDNS 的核心价值是什么？

    答：核心价值不是简单“提速”，而是让客户端对解析结果更可控，减少系统 DNS 劫持、污染、节点调度不合理等问题。真正落地时，重点在于它和现有请求栈、证书校验、缓存/回退策略如何工程化集成。

  6. 一键登录为什么也可以放进“移动网络底座”视角里看？

    答：因为它强依赖运营商网络链路、超时、回退、页面生命周期和端侧封装稳定性。真正难点不只是调起 SDK，而是把运营商能力、登录状态机、异常回退和跨端封装整合成稳定入口。

对应专题与实验室入口 ​

先去这些已存在专题 ​

当前页对应实验情况 ​

类型入口说明
HTTPDNS 专题09. HTTPDNS / 阿里 DNS 移动端工程化：Android / Flutter 主线、Host/SNI/TLS 边界与回退策略从解析层看 HTTPDNS / 阿里 DNS：它解决什么、为什么不是只会 resolveDomain、以及 Host / SNI / TLS / 回退策略怎么协同。
HTTPDNS Labflutter-httpdns-override READMEFlutter host 的首版工程化承载，包含预解析、候选 IP、系统 DNS 回退、请求计划与 TLS/SNI 边界演示。
一键登录专题移动端一键登录工程化从运营商能力、授权页生命周期、回退策略与状态收敛角度看一键登录为什么不是普通 HTTP 登录。
一键登录 Labmobile-one-tap-login READMEFlutter host 的状态机 / 回退策略 demo，演示协议校验、失败分叉、短信验证码兜底与登录后用户信息收敛。
仍建议后续补的实验QUIC / HTTP2 弱网对比抓包或时序实验；OkHttp / Dio 超时、取消、重试、401 刷新实验当前主文与两条专题链路已经有真实入口，但 QUIC 抓包与请求库专题实验仍值得后续补齐。

复习检查题 ​

  1. 为什么 HTTP/2 的“多路复用”不能等同于“弱网下一定不卡”？

    答：因为 HTTP/2 只是把多个请求复用到一条 TCP 连接里，应用层并发并不等于传输层完全隔离；一旦 TCP 前面的包丢了，后面的字节即使到了也不能乱序交付，整条连接上的多个 Stream 都可能一起慢下来。

  2. QUIC 最值得移动端重视的三个点是什么？

    答：第一是减轻 TCP 层队头阻塞带来的整批卡顿；第二是结合 TLS 1.3 降低建连时延；第三是用 Connection ID 改善 Wi‑Fi/蜂窝切换时的连接迁移体验。

  3. 为什么说“网络优化”不能只盯着协议版本？

    答：因为用户体感由整条链路共同决定：DNS、建连、服务端处理、请求库配置、缓存、取消、错误态和 UI 渲染都可能成为主瓶颈。只升级 HTTP/3，不会自动修好 DNS 污染、接口慢、乱重试和糟糕的页面状态管理。

  4. Flutter 页面里，什么网络问题经常被误判成“Dio 很慢”？

    答：常见根因是请求没有在页面销毁、参数切换、tab 切换时及时取消，导致过期结果晚到后回写 UI；表现上像“网络乱、响应慢”，但本质是请求生命周期和状态管理没收好。

  5. HTTPDNS 和一键登录在这页里为什么只做摘要入口，不展开实现？

    答：因为这页主轴是移动网络底座总览，要先回答“它们分别属于哪一层、解决什么问题、为什么真实价值在工程化集成”。具体 SDK 接法、平台坑、异常码处理更适合放到独立专题，否则会冲散 HTTP/2 / HTTP/3 / 弱网治理这条主线。

速记 ​

  • HTTP/1.1：连接多，握手重，靠多开连接并发。
  • HTTP/2：一个 TCP 扛多请求，平时高效，弱网怕 TCP 丢包拖全局。
  • HTTP/3：QUIC over UDP，重点是更稳的多流隔离、更短握手、更好的切网迁移。
  • 移动端网络要分层看：DNS 决定去哪里，连接层决定怎么连，请求库决定怎么配，UI 层决定用户怎么感知失败。
  • HTTPDNS / 一键登录：都不是“接 SDK 就完事”，真正价值在二次工程化改造和线上问题治理。

站点构建时间：2026/08/24 23:45:00

Copyright © 2026-present Engineering Review Lab. All Rights Reserved. (CC BY-NC-SA 4.0)

站点构建时间：2026/8/24 23:43:17

Copyright © 2026-present Engineering Review Lab. All Rights Reserved. (CC BY-NC-SA 4.0)