浏览器-web协商机制

服务器和客户端如何协商使用什么协议？使用的是HTTP Upgrade（http1.1升级协议）和ALPN（应用层协议协商）。

一 明确概念

在 Web 通信中，“协议协商” 指的是客户端（浏览器）和服务器在正式传输数据之前，通过一系列请求和响应，共同决定将要使用的通信协议（如 HTTP/1.1, HTTP/2, HTTP/3）的过程。

二 核心协商方式

（1）基于 HTTP 的升级机制（HTTP Upgrade）

• 原理：客户端在请求头中声明自己支持的协议，服务器根据自身能力选择并返回。

• 示例

  1
  2
  3
  4
  

  GET / HTTP/1.1
  Host: example.com
  Connection: Upgrade
  Upgrade: h2c, h3-29

  • Connection: Upgrade 表示要升级协议。

  • Upgrade: h2c, h3-29 列出客户端支持的协议（h2c 表示 HTTP/2 明文，h3-29 表示 HTTP/3 Draft 29）。

  • 服务器响应：

    1
    2
    3
    

    HTTP/1.1 101 Switching Protocols
    Connection: Upgrade
    Upgrade: h2c

    • 返回 101 Switching Protocols 状态码，确认切换到 HTTP/2。

（2）基于 ALPN（Application-Layer Protocol Negotiation）

• 原理：在建立 TLS 连接时，客户端在 ClientHello 消息中携带支持的协议列表，服务器选择一个并在 ServerHello 中返回。

• 特点：

  • 比 HTTP Upgrade 更高效，因为在 TLS 握手阶段完成协商，无需额外的 HTTP 往返。
  • 是 HTTP/2 和 HTTP/3 推荐的协商方式。

• 示例：

  • 客户端 TLS ClientHello：

    1
    

    ALPN Extension: h2, http/1.1, h3

  • 服务器 TLS ServerHello：

    1
    

    ALPN Extension: h2

    • 确认使用 HTTP/2。

三 协议优先级与回退

• 协商优先级：当客户端同时支持两种协商方式时，会优先尝试 ALPN。因为 ALPN 是在 TLS 握手阶段完成协议协商，不需要额外的 HTTP 请求往返，能直接建立最优协议的连接；而 HTTP Upgrade 是基于 HTTP/1.1 先建立连接，再发起升级请求，多了一次网络往返，效率更低。
• 客户端：会按照优先级列出支持的协议（通常 HTTP/3 > HTTP/2 > HTTP/1.1）。
• 服务器：选择自己支持的最高优先级协议。
• 回退机制：如果服务器不支持任何客户端声明的协议，会回退到默认协议（通常是 HTTP/1.1）。

四 实际应用场景

• HTTP/2：几乎所有现代浏览器和服务器都支持，通过 ALPN 协商。
• HTTP/3：基于 QUIC 协议，部分浏览器（Chrome、Firefox）和服务器（Nginx、Cloudflare）已支持，同样通过 ALPN 协商。
• WebSocket：使用 HTTP Upgrade 机制从 HTTP/1.1 升级到 WebSocket 协议。

五 其它场景

1：WebSocket 为什么不用 ALPN，而要用 HTTP Upgrade 机制？

面试官您好，主要有两个核心原因：

1. 历史兼容性：WebSocket 诞生于 HTTP/2 普及之前，最初就是基于 HTTP/1.1 设计的，HTTP Upgrade 是当时唯一成熟的协议升级方案，能兼容大量老旧服务器和客户端。
2. 场景适配性：WebSocket 是 “按需升级” 的双向通信协议，很多场景下客户端只需要在特定请求时切换到 WebSocket（比如聊天、实时通知），而不是整个连接都用 WebSocket。HTTP Upgrade 可以针对单个请求发起升级，灵活性更高；而 ALPN 是在 TLS 握手时确定全局协议，无法做到 “按需切换”。

当然，在 HTTP/2 环境下，也可以通过 CONNECT 方法实现 WebSocket，但 HTTP Upgrade 仍是主流方案，核心还是为了兼容。

2：如果服务器不支持 ALPN，还能使用 HTTP/2 吗？

可以的。HTTP/2 有两个版本：

• h2：基于 TLS + ALPN，是主流的安全版本；
• h2c：明文版本，不依赖 TLS，可通过 HTTP Upgrade 机制协商。

如果服务器不支持 ALPN，客户端可以发送带 Connection: Upgrade 和 Upgrade: h2c 的 HTTP/1.1 请求，服务器返回 101 状态码后，就能切换到 HTTP/2 明文通信。但要注意，h2c 没有加密，存在安全风险，生产环境一般不推荐使用，仅用于内部服务通信等可信场景。

六 总结

1. HTTP Upgrade 机制客户端在 HTTP 请求头带 Connection: Upgrade 和 Upgrade: 协议名（比如 WebSocket、h2c），发起协议升级请求。服务器支持的话，返回 101 状态码确认，多用于从 HTTP/1.1 升级到 WebSocket。
2. ALPN 扩展机制在 TLS 握手阶段完成协商，无需额外 HTTP 往返，更高效。客户端在 ClientHello 里带支持的协议列表（如 h3, h2, http/1.1），服务器选自己支持的最高优先级协议，通过 ServerHello 返回。这是 HTTP/2、HTTP/3 的主流协商方式。

简单来说，ALPN 优先，Upgrade 候补；协议排序，321 步，即

1. ALPN 优先

   TLS 握手阶段直接协商，无额外往返，效率高，是 HTTP/2、HTTP/3 的首选。

2. Upgrade 候补

   仅 ALPN 协商失败时才用，基于 HTTP/1.1 升级，多用于 WebSocket。

3. 协议排序，321 步

   客户端协议优先级固定：HTTP/3 > HTTP/2 > HTTP/1.1，服务器按此选最优。