HTTP：协议升级机制

向右看齐 2022-09-03 05:12 238阅读 0赞

HTTP协议提供了一种特殊的机制，这一机制**允许将一个已建立的连接升级成新的、不相容的协议**。

通常来说这一机制总是由**客户端**发起的（不过也有例外，比如说可以**由服务端发起升级到传输层安全协议(TLS)**），**服务端可以选择是否要升级到新协议**。借助这一技术，连接可以以常用的协议启动(比如HTTP/1.1)，随后再升级到HTTP2甚至是WebSockets.

> 注意：HTTP/2 明确禁止使用此机制，这个机制只属于HTTP/1.1

# 升级HTTP/1.1的链接 #

协议升级请求总是由客户端发起的；暂时没有服务端请求协议更改的机制。当客户端试图升级到一个新的协议时，可以先发送一个普通的请求如GET、POST等，不过这个请求需要进行特殊配置以包含升级请求。

这个请求需要添加两项额外的header：

*  `Connection: Upgrade`：设置 Connection 头的值为 “Upgrade” 来指示这是一个升级请求.
 *  `Upgrade: protocols`：Upgrade 头指定一项或多项协议名，按优先级排序，以逗号分隔。

一个典型的包含升级请求的例子差不多是这样的：

GET /index.html HTTP/1.1
    Host: www.example.com
    Connection: upgrade
    Upgrade: example/1, foo/2

如果服务器没有升级这次连接，它会忽略客户端发送的 Upgrade 头部字段，返回一个常规的响应（例如一个200 OK）

如果服务器决定升级这次连接，就会返回一个`101 Switching Protocols` 响应状态码，和一个要切换到的协议的头部字段Upgrade。

HTTP/1.1 101 Switching Protocols
    Upgrade: foo/2
    Connection: Upgrade

服务在发送 101 状态码之后，就可以使用新的协议，并可以根据需要执行任何其他协议指定的握手。实际上，一旦这次升级完成了，连接就变成了双向管道。并且可以通过新协议完成启动升级的请求。

由HTTP/1.1请求建立的连接可以升级为HTTP/2协议的连接，但是反过来不可以。事实上HTTP/2已经不再支持101状态码了，也不再支持任何连接升级机制。

# 升级机制的常用场合 #

## 升级到WebSocket协议的连接 ##

如果想要自己重头实现WebSocket 连接，就必须要处理**握手和升级**过程。在创建初始HTTP/1.1会话之后你需要发送另一个HTTP标准请求，但在headers中要带上Upgrade (en-US) and Connection，也就是：

Connection: Upgrade
    Upgrade: websocket

## WebSocket 专有的 headers ##

以下headers是在WebSocket升级过程中会出现的。除了`Upgrade`和`Connection`，其他的一般浏览器和服务器都会在交互过程中处理好

### Sec-WebSocket-Extensions ###

用于指定一个或者多个请求服务器使用的协议级websocket扩展。允许在一个请求中使用多个Sec-WebSocket-Extension头，它会自动合并到**一**个头文件。

Sec-WebSocket-Extensions: extensions

`extensions`：指需要(或支持)的扩展的逗号分隔列表。这些值来自[IANA WebSocket 扩展名注册表][IANA WebSocket]。带参数的扩展使用分号表示。比如：

Sec-WebSocket-Extensions: superspeed, colormode; depth=16

### Sec-WebSocket-Key ###

向服务器提供所需的消息，以确认客户端有权请求升级到WebSocket。当不安全(HTTP)客户端希望升级时，可以使用此头，以提供某种程度的保护，防止滥用。密钥的值是使用WebSocket规范中定义的算法计算的，因此这并不提供安全性。相反，它有助于防止非WebSocket客户端无意或者误用的请求WebSocket连接。从本质上说，它确认了“是的，我真的想打开一个WebSocket连接。”

Sec-WebSocket-Key: key

key：此升级请求的关键字。如果客户端希望这样做，则客户端会添加这个，服务器将在响应中包含自己的密钥，客户端将在向您交付升级响应之前验证该密钥。

服务器响应的Sec-WebSocket-Accept是基于基于key计算的。

### Sec-WebSocket-Protocol ###

按优先级排序指定了一个或多个你想要使用的WebSocket协议。服务器将在响应中包含的aSec-WebSocket-Protocol中选择并返回服务器支持的第一个协议。你也可以在头文件中多次使用它;结果与在单个头文件中使用逗号分隔的子协议标识符列表相同。

Sec-WebSocket-Protocol: subprotocols

subprotocols：以逗号分隔的子协议名称列表，按优先顺序排列。子协议可以从IANA WebSocket子协议名称注册表或者可以是客户机和服务器共同理解的自定义名称。

### Sec-WebSocket-Version ###

#### 请求头中 ####

*  指定客户端希望使用的WebSocket协议版本，以便服务器可以确认其端部是否支持该版本。

Sec-WebSocket-Version: version

version：客户端在与服务器通信时希望使用的WebSocket协议版本。此编号应该是中列出的最新版本IANA WebSocket版本号注册表. WebSocket协议的最新最终版本是版本13。

#### 响应头中 ####

*  如果服务器不能使用指定版本的WebSocket协议进行通信，它将响应一个错误(比如426 Upgrade Required)，该错误包含在其报头Sec-WebSocket-Version中，并以逗号分隔支持的协议版本列表。
 *  如果服务器确实支持请求的协议版本，响应中将包含Sec-WebSocket-Version头。

Sec-WebSocket-Version: supportedVersions

supportedVersions：服务器支持的WebSocket协议版本的逗号分隔列表。

## 响应头 ##

仅用于服务器响应

### Sec-WebSocket-Accept ###

当服务器愿意初始化WebSocket连接时，在开始握手过程中，服务器的响应消息中包含该消息。它将在响应头中只出现一次。

Sec-WebSocket-Accept: hash

### 文章目录 ###

*  升级HTTP/1.1的链接
 *  升级机制的常用场合
 *   *  升级到WebSocket协议的连接
     *  WebSocket 专有的 headers
     *   *  Sec-WebSocket-Extensions
         *  Sec-WebSocket-Key
         *  Sec-WebSocket-Protocol
         *  Sec-WebSocket-Version
         *   *  请求头中
             *  响应头中
     *  响应头
     *   *  Sec-WebSocket-Accept

[IANA WebSocket]: https://www.iana.org/assignments/websocket/websocket.xml#extension-name