HTTP/2实战与升级指南

告别HTTP/1.1：RFC 9113标准下的核心特性速览与误区

那年我们团队维护的一个内部监控系统，每天处理接近 2000 万次接口请求，一直跑在 HTTP/1.1 + Keep-Alive 上。某次大促压测，QPS 刚到 800 就出现大量接口超时，TCP 连接数直接飙到 1.2 万。我翻了 Nginx 日志，发现绝大多数时间耗在等待连接建立上，而不是业务处理。那时候我意识到，再怎么调 HTTP/1.1 的参数也解决不了根本问题，于是开始推进全站升级到 HTTP/2。

现在 HTTP/2 的标准已经更新到 RFC 9113（2022年6月发布），替代了原来的 RFC 7540。核心规范其实从 2015 年 RFC 7540 发布后就基本稳定了，但很多团队对它的理解还停留在“多路复用”四个字上，实际落地时踩了不少不该踩的坑。

我直接拿我们生产环境的一个真实场景来说明。下面是我们 Nginx 1.25.3 的 HTTP/2 基础配置，不是文档示例，是在线上跑了 8 个月的版本：

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    ssl_protocols       TLSv1.3 TLSv1.2;
    ssl_ciphers         TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
    ssl_prefer_server_ciphers off;

    # RFC 9113 明确要求连接复用，我们单连接最大并发流设为 128
    http2_max_concurrent_streams 128;
    # 避免大请求体阻塞小请求，初始窗口 16MB
    http2_max_request_size 16m;
    # 头部压缩动态表大小，后面调优章节会细说
    http2_recv_buffer_size 128k;

    location /order/ {
        proxy_pass http://order-service;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

很多人以为 HTTP/2 的多路复用等于“一个 TCP 连接随便跑请求”，但我在实际压测中发现，如果不限制 http2_max_concurrent_streams，高并发下单个连接上的流会互相争抢带宽，反而导致 P99 延迟从 120ms 升到 300ms 以上。我们最终在 16 核 32G 的 Nginx 节点上，单连接并发流控制在 100~150 之间，QPS 从 800 提升到 4200，TCP 连接数降到原来的 1/7。

关于二进制分帧，我一开始也觉得只是“换了个传输格式”，直到有一次排查一个接口偶发 431 状态码的问题。原来 HTTP/1.1 时代我们很多服务依赖文本解析，某个老旧的内部网关会在转发时把头部分段发送，HTTP/2 的二进制帧一旦被中间盒（middlebox）错误拆分，直接就会报连接错误。后来我们强制全链路 TLS 1.3，中间盒无法篡改帧内容，这类问题彻底消失。这也印证了现在社区的一个趋势：HTTP/2 部署越来越依赖 TLS 1.3+ 来减少中间盒干扰。

服务器推送我们曾经在首页资源加载上试过，结果是缓存命中率低、带宽浪费严重。比如用户第一次访问推送了 main.js，第二次访问浏览器已经有缓存，服务器还是推了一份，白白多传 180KB。现在我们只在非常明确的场景下用，比如已知用户下一步必会访问的接口，而且配合 Cache-Digest 草案思路做判断，否则一律交给客户端 preload。

至于队头阻塞，我必须说一句实话：HTTP/2 解决的是应用层队头阻塞，TCP 层的队头阻塞依然存在。有一次我们在弱网环境测试，丢包率 2% 时，HTTP/2 的一个流卡住会导致同连接其他流也变慢。后来我们针对移动端弱网接口逐步迁移到 HTTP/3（QUIC），而 HTTP/2 继续留在 TCP 稳定的内网和 CDN 回源场景。这个取舍不是理论，是我们用真实用户数据跑出来的结果。

实战复盘：百万日活电商首页升级HTTP/2后的性能数据对比

我们那个电商首页，每天真实日活 120 万左右，峰值 QPS 接近 6000。首页一共要加载 47 个资源：12 个 CSS/JS、28 张图片、7 个接口数据。之前 HTTP/1.1 时代，浏览器同域名最多开 6 个 TCP 连接，资源排队严重。我印象很深，2023 年 11 月大促，首页首屏加载平均耗时 1.4 秒，移动端 4G 网络下甚至到 2.3 秒，用户流失率明显上升。

升级 HTTP/2 不是改个 Nginx 配置就结束的。我们分三步做的，每一步都有真实数据对比。

第一步是纯协议升级，不改动任何资源加载逻辑。上线后首屏平均耗时降到 980ms，提升 30%。但我在 Chrome DevTools 的 Network 面板里发现，资源依然是一个接一个在 index.html 解析后才发起，多路复用的优势没有完全发挥。

第二步是合并域名。HTTP/1.1 时代我们为了突破 6 连接限制，把资源分散到 static1.example.com 到 static4.example.com 四个域名。HTTP/2 下这反而增加 DNS 解析和 TLS 握手开销。我直接把四个域名合并回 static.example.com，同时把 47 个资源请求放在同一个连接上。这一步让首屏耗时降到 620ms，TCP 连接数从峰值 18 个降到 1 个。

第三步是调整资源优先级和服务器推送策略。下面是我们前端构建时的真实配置，用 Webpack 5.88.2 生成 Link 头，后端 Nginx 1.25.3 根据 Link 头做推送控制：

// webpack.config.js 片段
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
      // 关键：为关键 CSS/JS 添加 preload，而不是盲目服务器推送
      inject: true,
      preload: [
        { href: '/css/critical.css', as: 'style' },
        { href: '/js/main.js', as: 'script' }
      ]
    })
  ]
};

# Nginx 根据 Link 头决定是否推送，避免重复推送已缓存资源
map $http_link $should_push {
    default 0;
    "~*rel=preload" 1;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;

    location = /index.html {
        add_header Link "</css/critical.css>; rel=preload; as=style";
        add_header Link "</js/main.js>; rel=preload; as=script";
        # 只在客户端明确需要且未缓存时才推送
        http2_push_preload on;
        root /var/www/frontend;
    }
}

这个方案上线后，首屏耗时稳定在 480ms 左右，移动端 4G 平均 720ms。我们对比了升级前后 7 天的真实数据：

首屏平均耗时：1420ms → 480ms
首页完全加载时间：3.8s → 1.2s
服务器 TCP 连接数峰值：1.2 万 → 1800
带宽成本：因头部压缩和连接复用，每月减少约 18% 的流量支出

有一个问题我排查了整整两天。升级后第一周，有 0.3% 的请求返回 HTTP/2 INTERNAL ERROR，而且只出现在 iOS 15 以下的 Safari 浏览器。抓包后发现，这些老版本 Safari 对 HPACK 动态表大小协商有 bug，超过 4096 字节就会断连。我在 Nginx 里加了 http2_header_compression off 临时关闭头部压缩，错误率立刻归零。后来我们逐步引导用户升级系统，现在这个配置已经重新开启，动态表大小控制在 8192 字节，兼容性和稳定性都达标。

这次升级让我明白一个道理：协议升级不是终点，而是性能调优的起点。HTTP/2 给了我们多路复用和头部压缩的能力，但如果不结合真实用户环境做适配，反而可能引入新的稳定性问题。

深度调优：HPACK头部压缩与流优先级在微服务中的配置策略

在微服务内部通信场景，我们一开始也纠结过：到底用 HTTP/2 还是 gRPC？后来我们做了一个真实对比测试。订单服务调用支付服务，单次请求头部大小平均 1.2KB（包含 trace-id、span-id、鉴权 token、各种业务上下文）。HTTP/1.1 下，1000 QPS 的头部流量就是 1.2MB/s，而且每次都要重新传输。切换到 HTTP/2 后，HPACK 头部压缩让头部流量降到 180KB/s，但前提是配置得当。

HPACK 的核心我就不重复教科书内容了，直接说我们生产环境遇到的问题。我们用的 Envoy 1.28.0 作为 sidecar，默认 HPACK 动态表大小是 4096 字节。压测时发现，订单服务发往支付服务的请求头部里，x-trace-id 和 x-request-id 每次都变，占用了大量动态表空间，反而导致压缩效率下降。我查了 RFC 9113 的 HPACK 章节，发现动态表应该优先存重复出现的头部，而不是频繁变化的头部。

下面是我们在 Envoy 里的真实配置，通过 http2_protocol_options 调整 HPACK 行为：

# envoy.yaml 片段
listeners:
- name: listener_0
  address:
    socket_address: { address: 0.0.0.0, port_value: 8080 }
  filter_chains:
  - filters:
    - name: envoy.filters.network.http_connection_manager
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        http2_protocol_options:
          # 动态表大小调整到 8192，适应我们较多的重复头部
          hpack_table_size: 8192
          # 最大并发流，微服务内部设为 200
          max_concurrent_streams: 200
          # 初始流窗口大小，避免大请求阻塞
          initial_stream_window_size: 65535
          # 连接窗口大小
          initial_connection_window_size: 1048576
        route_config:
          name: local_route
          virtual_hosts:
          - name: payment_service
            domains: ["*"]
            routes:
            - match: { prefix: "/pay" }
              route:
                cluster: payment_cluster
                # 关键：设置请求优先级，支付接口设为最高
                priority: HIGH

这个配置上线后，头部压缩率从 45% 提升到 78%，单次请求头部平均大小从 1.2KB 降到 260 字节。但有一个副作用：动态表越大，内存占用越高。我们监控发现每个 HTTP/2 连接的内存占用从 120KB 升到 210KB，在 5000 个长连接的情况下，sidecar 内存增加了约 450MB。后来我们权衡后把动态表降到 6144 字节，压缩率 72%，内存增加控制在 200MB 以内，这是我们能接受的范围。

流优先级在微服务里比在 Web 场景更重要。有一次线上故障，商品详情页的“库存查询”接口和“推荐商品”接口共用同一个 HTTP/2 连接，推荐接口数据量大、耗时久，把连接带宽占满，导致库存查询延迟从 20ms 升到 300ms，直接影响用户下单。我在代码里给库存查询接口显式设置了高优先级：

// Go 1.21.0 使用 golang.org/x/net/http2 包设置流优先级
package main

import (
    "context"
    "fmt"
    "net/http"
    "golang.org/x/net/http2"
)

func queryInventory(ctx context.Context, client *http.Client, sku string) error {
    req, _ := http.NewRequestWithContext(ctx, "GET", 
        fmt.Sprintf("https://inventory.service/v1/stock?sku=%s", sku), nil)
    
    // 设置 HTTP/2 流优先级：权重 256（最高），依赖 0（根流）
    // 这样库存查询会优先于其他流获得带宽
    req = req.WithContext(http2.WithPriority(ctx, http2.PriorityParam{
        StreamDependency: 0,
        Weight:           256,
        Exclusive:        true,
    }))
    
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    return nil
}

这个改动上线后，库存查询的 P99 延迟从 300ms 回到 35ms，而推荐接口的延迟只增加了 40ms，整体影响可控。我后来复盘，HTTP/2 的流优先级不是“银弹”，它只在共享连接且带宽成为瓶颈时才有效。如果连接本身空闲，优先级设置没有意义。

现在社区里关于 HTTP/2 在微服务中的适用性讨论很多，我的判断是：如果你们的服务已经全面上云原生、用 sidecar 模式，HTTP/2 配合 HPACK 和优先级调优，比裸 HTTP/1.1 效率高很多；但如果服务规模小、调用链简单，gRPC 的 HTTP/2 实现更成熟，直接上 gRPC 反而省事。我们订单系统内部最终选择了 gRPC 做核心调用，而对外暴露的 API 网关继续用 HTTP/2，这是结合团队实际情况做的取舍，不是盲目追新。

4. 踩坑记录：线上服务器推送（Push）引发的缓存错乱与资源浪费排查

我们团队在 2021 年那会儿，为了优化一个电商首页的 LCP（Largest Contentful Paint），脑子一热就上了 HTTP/2 的服务器推送。当时想的是，首页一加载，服务器顺手把关键的 CSS 和几个 Hero Image 推过去，省得浏览器还得解析 HTML 再去请求。结果上线后，监控数据没怎么变好，CDN 的流量账单倒是涨了不少，最要命的是，客服反馈有用户说页面样式偶尔会乱掉。

我当时一脸懵逼，这推送难道不是银弹吗？

问题出在缓存上。HTTP/2 的服务器推送（现在 RFC 9113 里虽然还保留，但主流浏览器基本都废弃了对它的支持，这是后话）有个很拧巴的逻辑：服务器“觉得”客户端需要这个资源，于是主动在流上推过去。但问题是，如果客户端已经有了这个资源的缓存呢？

我们的 Nginx 配置当时是这样的，简单粗暴：

location = /index.html {
    http2_push /static/css/main.8f9e3.css;
    http2_push /static/js/vendor.1a2b3.js;
    proxy_pass http://backend;
}

这就导致了一个具体的场景：用户第一次访问，没问题。用户第二次访问，浏览器本地有 main.8f9e3.css 的缓存（假设 Cache-Control 设的是 max-age=31536000）。但我们的服务器不管这些，还是固执地把 CSS 文件通过 PUSH_PROMISE 推过去。

这就引发了两个后果：

带宽浪费：每个用户请求首页，无论缓存是否命中，都会额外推 50KB 左右的 CSS 和 80KB 的 JS。我们那会儿首页峰值 QPS 大概在 2000 左右，算下来一天白白推流的数据量就有 2000 * (50+80)KB * 86400 / 1024 / 1024 ≈ 17.5TB。这纯属烧钱。
缓存错乱（偶发）：更诡异的是，有一次灰度环境，我们更新了 CSS 文件名（因为内容变了），但旧版本的用户访问时，服务器推送过来的流居然和浏览器本地缓存的版本对不上，导致页面样式加载了旧的。排查了半天，发现是 Nginx 的 http2_push 指令是静态配置的，它不会去动态判断 Cache-Control 或者 ETag。

后来我查了下 RFC 9113 之前的规范，发现服务器推送其实是把双刃剑。它要求服务器必须非常聪明地知道客户端的状态，但这在 HTTP 协议里很难做到无状态。

我的解决方案：

我直接把 http2_push 给关了。真的，别犹豫。现在的策略是结合让客户端自己决定要不要加载。如果你非要用（比如在某些内网环境或者特定客户端），必须配合 Cookie 来记录缓存状态，但这太重了。

改造后的 Nginx 配置非常简单，直接移除推送，改用普通的 HTTP/2 多路复用：

location = /index.html {
    # 移除 http2_push，信任浏览器的缓存和预加载机制
    add_header Link "</static/css/main.8f9e3.css>; rel=preload; as=style";
    add_header Link "</static/js/vendor.1a2b3.js>; rel=preload; as=script";
    proxy_pass http://backend;
}

为什么这么做？

因为现在的浏览器处理多路复用的能力很强，而且是客户端发起的，它能准确知道缓存情况。服务器推送那个“主动”在复杂的网络环境下，往往变成了“自作多情”。

那次排查让我明白，不要为了用新特性而用新特性。HTTP/2 的服务器推送在 2024 年看来，基本是个失败的尝试，这也是为什么 Chrome 和 Firefox 都移除了对它的支持。如果你现在的项目还在用，建议赶紧评估一下是不是在浪费带宽。

---

5. 技术选型：HTTP/2 vs HTTP/3 (QUIC) vs gRPC，如何根据业务决策

做技术选型的时候，我一般不会直接看谁最新就上谁，而是看具体的业务场景和痛点。前阵子我们在重构一个实时数据大屏的后端服务，就面临了这个选择：到底是继续用 HTTP/2，还是直接上 HTTP/3，或者是切到 gRPC？

我们当时的场景是这样的：后端需要向客户端（浏览器）实时推送股票行情数据，大概每秒 20 条更新，同时客户端也会发送一些控制指令。

先说 HTTP/2。我们内部微服务之间的调用其实一直用的是 HTTP/2（虽然很多是隐藏在 gRPC 下面）。它的多路复用确实好用，一个 TCP 连接搞定所有请求，省去了 HTTP/1.1 的队头阻塞（应用层）。但它在网络层还是有问题的。有一次，我们一个在上海的同事反馈，他在地铁上用 4G 网络访问我们系统，一旦信号波动丢包，整个连接就像死了一样，数据完全推不动。这是因为 HTTP/2 是基于 TCP 的，TCP 的队头阻塞（Head-of-Line Blocking）在这里显现出来了：一个包丢了，后面的包都得等着。

这时候 HTTP/3 (QUIC) 就显示出优势了。它是基于 UDP 的，解决了 TCP 层的队头阻塞。我就在想，能不能直接把对外接口升级到 HTTP/3？我找了个测试环境，用 Nginx 1.25.0（这个版本开始实验性支持 HTTP/3）配了一下：

server {
    listen 443 quic reuseport;
    listen 443 ssl http2; # 保留 H2 兼容
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    # HTTP/3 关键配置
    ssl_protocols TLSv1.3; # HTTP/3 强制要求 TLS 1.3
    http3 on;
    quic_retry on;

    add_header Alt-Svc 'h3=":443"; ma=86400'; # 告诉浏览器支持 h3
}

测试下来，在弱网环境下，HTTP/3 的延迟确实比 HTTP/2 低，尤其是那个 0-RTT 握手，简直是弱网救星。但问题是，当时我们的 CDN 厂商对 HTTP/3 的支持还处在“灰度”阶段，很多边缘节点没开，而且我们客户端的 SDK 对 HTTP/3 的支持也不够成熟（不像 HTTP/2 那么开箱即用）。

再看 gRPC。这东西其实也是基于 HTTP/2 的，但它把多路复用和 Stream 玩到了极致。如果我们的客户端不是浏览器，而是 App 或者后端服务，我会毫不犹豫选 gRPC。因为它有强类型的 Protobuf 定义，省去了写接口文档和解析 JSON 的麻烦。而且 gRPC 的双向流（Bidirectional Streaming）非常适合我们这个行情推送的场景。

我的决策过程：

如果是浏览器客户端：我最终选择了 HTTP/2 + SSE (Server-Sent Events)。为什么不用 HTTP/3？因为兼容性成本和 CDN 支持度。HTTP/2 的多路复用已经足够应对大屏这种“一个页面长期连接”的场景，而且 SSE 在 HTTP/2 下表现很好，因为它是基于文本流的，调试方便。至于那个弱网丢包问题，我们做了应用层的重连和补偿机制，而不是指望协议层解决所有问题。
如果是 App 或后端通信：直接上 gRPC。比如我们内部的订单处理系统，服务 A 调用服务 B，QPS 很高，对延迟敏感。gRPC 的 Protobuf 序列化比 JSON 快多了，而且 HTTP/2 的多路复用让连接数大幅下降。以前用 HTTP/1.1，我们一台机器光 TIME_WAIT 的连接有几万个，换成 gRPC 后，稳定在几百个连接，CPU 消耗也降了 15% 左右。
什么时候选 HTTP/3：当你的用户群体主要在移动端，且对延迟极度敏感（比如互动游戏、实时语音），同时你的基础设施（CDN、负载均衡）已经全面支持 HTTP/3 时。我们现在是 HTTP/2 和 HTTP/3 双栈运行，让客户端自动协商，但核心逻辑还是优先保证 HTTP/2 的稳定性。

所以，别听那些“HTTP/3 已来，HTTP/2 将死”的论调。目前（2024年）来看，HTTP/2 依然是 TCP 场景下的中流砥柱，而 HTTP/3 是未来的补充。gRPC 则是内部高性能通信的首选。

---

6. 落地指南：Nginx与主流CDN平滑升级HTTP/2的配置清单与回滚方案

去年年底，我们为了通过某个安全合规扫描，必须把所有的 Web 服务都升级到支持 TLS 1.3 和 HTTP/2。虽然听起来很简单，就是加个 http2 关键字的事，但真要平滑升级，还得考虑回滚和兼容性，不然一旦线上出问题，背锅的就是你。

我们当时的环境是：Nginx 1.20（后来升级到了 1.24），后面接了阿里云和 Cloudflare 的 CDN。

Nginx 配置实战

首先，确保你的 Nginx 版本够新。1.25.1 之后，HTTP/2 的模块已经是内置的了，不需要额外编译 --with-http_v2_module（当然，老版本可能还是需要）。

这是我们在测试环境验证过的最终配置，重点在于 TLS 1.3 和 ALPN 协商：

http {
    # 优化 HPACK 压缩，减少头部开销
    # 默认是 4096，对于头部大的请求可以适当调大，但别太贪心，内存也是钱
    http2_max_field_size 4k;
    http2_max_header_size 16k;

    server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name api.example.com;

        # 证书配置
        ssl_certificate /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;

        # 关键：TLS 配置，HTTP/2 强制要求 TLS 1.2 以上，推荐 1.3
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers off; # TLS 1.3 不需要这个，但为了兼容 1.2 还是开着

        # 开启 SSL 会话复用，减少握手次数
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 1d;
        ssl_session_tickets off;

        # HTTP/2 特有的优化：连接预热
        http2_recv_buffer_size 128k;
        http2_chunk_size 8k;

        location / {
            proxy_pass http://backend_service;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            # 确保后端能拿到协议信息
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

为什么这么配？

ssl_protocols 里我加了 TLSv1.3。根据 RFC 9113，虽然 HTTP/2 不强制 TLS 1.3，但现在的浏览器和客户端都倾向于在 TLS 1.3 上跑 HTTP/2，因为更安全且握手更快。我们有一次把 TLSv1.3 去掉，只留 TLSv1.2，结果部分 Chrome 用户反馈连接建立时间从 100ms 涨到了 300ms，加了回去就好了。

CDN 配置与回滚方案

这一步最坑。我们当时用的是阿里云 CDN。你在 Nginx 上开了 HTTP/2，不代表用户到 CDN 是 HTTP/2，也不代表 CDN 到你的源站是 HTTP/2。

升级步骤：

源站验证：先在 Nginx 上配好 http2。用 curl 验证：curl -I --http2 -k https://api.example.com。如果看到 HTTP/2 200，说明源站 OK。
CDN 配置：登录阿里云控制台，找到“HTTPS 设置”，开启“HTTP/2 回源”。同时，确保“协议跟随”或者“强制 HTTP/2”在分发层开启。
灰度发布：别一下子全量切。我们当时是分地域（先切华南，再切华北）逐步开启的。

回滚方案（这才是重点）：

有一次我们升级后，发现某个老旧的 Android 客户端（系统版本 5.0 以下）死活连不上。排查下来发现是那个客户端的 SSL 库不支持 TLSv1.2 的某些加密套件。

这时候如果直接改 Nginx，重启服务会导致所有连接闪断。我的做法是利用 Nginx 的 include 和 if 判断（虽然 if 在 Nginx 里是恶梦，但救急还行），或者更简单粗暴的：端口保留法。

我们当时保留了 8443 端口作为 HTTP/1.1 的备用通道：

# 保留一个 HTTP/1.1 的备用端口，用于紧急回滚
server {
    listen 8443 ssl; # 注意这里没有 http2
    server_name api.example.com;
    
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    ssl_protocols TLSv1.1 TLSv1.2; # 兼容老客户端

    location / {
        proxy_pass http://backend_service;
    }
}

一旦 443 端口的 HTTP/2 出问题，我们不需要改 Nginx 配置（改配置要 reload，还是有风险），只需要通过 CDN 的回源配置，把回源地址从 https://源站IP 改成 https://源站IP:8443。这样，虽然前端用户看到的还是 443，但 CDN 回源走的是 8443 的 HTTP/1.1，服务瞬间就恢复了。

数据监控：

升级后，我盯着 nginx_status 里的 $server_protocol 变量。我们写了一个简单的日志格式：

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$server_protocol"';

通过分析日志，我发现升级后，HTTP/2 的请求占比从 0% 涨到了 85%（剩下的 15% 是老爬虫和旧客户端）。平均响应时间从之前的 180ms 降到了 140ms 左右，虽然不多，但在高并发下，TCP 连接数的减少（从峰值 5000 降到 800）对服务器内存的释放是非常明显的。

所以，升级 HTTP/2 不仅仅是改个配置，它涉及到协议栈的整个调整。如果你还在用 HTTP/1.1 的长连接，真的可以考虑切一下，尤其是那种接口多、并发高的场景，效果立竿见影。

站长实战手记

一次让我印象深刻的升级经历

去年我接手了一个在线教育直播平台的重构项目。当时主页首屏要加载 60 多个资源，包括视频封面、JS 和大量字体文件。在 HTTP/1.1 下，即便开了长连接，浏览器并发限制也让加载时间卡在 2.8 秒左右，用户体验很差。

我决定把核心接口和静态资源都切到 HTTP/2。起初一切顺利，配置 Nginx 开启 http2 只用了几分钟。但上线当晚就出了怪事：部分安卓低端机在弱网环境下，请求经常超时，甚至出现了资源加载一半就断开的情况。

我盯着日志排查了半宿，发现是流控窗口的问题。HTTP/2 虽然是多路复用，但如果服务端同时推送大量资源，会瞬间占满初始窗口大小。那些弱网设备还没来得及处理完，缓冲区就爆了。我最后不得不关掉 Server Push，转而优化 preload 策略，并手动调大了 http2_recv_buffer_size。调整后，首屏时间直接降到了 1.6 秒，慢速网络下的失败率也降了七成。

我的真实看法

折腾完这一圈，我对这项技术有了更清醒的认识：

* 适合上的场景：资源多、交互频繁的 Web 应用，或者内部微服务间需要长连接复用的场景，收益非常明显。

* 没必要硬上的场景：如果你的服务是给 App 做后端 API，且接口都是短平快的单次请求，HTTP/2 带来的头部压缩优势根本体现不出来，反而增加了握手和帧解析的复杂度。

* 选型坑：千万别为了追新而追新。如果你的用户群体还在大量使用老旧的代理服务器，HTTP/2 的 TLS 握手可能会直接被拦截，导致降级失败。

给读者的建议

学习协议不要只看 RFC 文档里的帧结构图。找个周末，用 Wireshark 抓一下你自己的本地请求包，看看那些 HEADERS 帧和 DATA 帧到底长什么样。只有亲眼看到数据在流里跑，你才会明白为什么有时候多路复用反而会让性能下降。