{{HTTPSidebar}}
HTTP协议 提供了一种特殊的机制，这一机制允许将一个已建立的连接升级成新的、不相容的协议。这篇指南涵盖了其工作原理和使用场景。
通常来说这一机制总是由客户端发起的 （不过也有例外，比如说可以由服务端发起{{anch("Server-initiated upgrade to TLS", "升级到传输层安全协议（TLS）")}}）， 服务端可以选择是否要升级到新协议。借助这一技术，连接可以以常用的协议启动（如HTTP/1.1），随后再升级到HTTP2甚至是WebSockets.
注意：HTTP/2 明确禁止使用此机制，这个机制只属于HTTP/1.1
协议升级请求总是由客户端发起的；暂时没有服务端请求协议更改的机制。当客户端试图升级到一个新的协议时，可以先发送一个普通的请求（{{HTTPMethod("GET")}}，{{HTTPMethod("POST")}}等），不过这个请求需要进行特殊配置以包含升级请求。
特别这个请求需要添加两项额外的header：
Connection: UpgradeConnection 头的值为 "Upgrade" 来指示这是一个升级请求.Upgrade: protocolsUpgrade 头指定一项或多项协议名，按优先级排序，以逗号分隔。一个典型的包含升级请求的例子差不多是这样的：
GET /index.html HTTP/1.1 Host: www.example.com Connection: upgrade Upgrade: example/1, foo/2
根据之前的请求的协议，可能需要其他头部信息，例如：从HTTP/1.1升级到WebSocket 允许配置有关 WebSocket 连接的头部详细信息，以及在连接时提供一定程度的安全性。查看 {{anch("Upgrading to a WebSocket connection")}} 获取更多信息。
如果服务器决定升级这次连接，就会返回一个 {{HTTPStatus(101, "101 Switching Protocols")}} 响应状态码，和一个要切换到的协议的头部字段Upgrade。 如果服务器没有（或者不能）升级这次连接，它会忽略客户端发送的 "Upgrade 头部字段，返回一个常规的响应：例如一个{{HTTPStatus(200, "200 OK")}}).
服务在发送 {{HTTPStatus(101)}} 状态码之后，就可以使用新的协议，并可以根据需要执行任何其他协议指定的握手。实际上，一旦这次升级完成了，连接就变成了双向管道。并且可以通过新协议完成启动升级的请求。
由HTTP/1.1请求建立的连接可以升级为HTTP/2协议的连接，但是反过来不可以。事实上HTTP/2已经不再支持101状态码了，也不再支持任何连接升级机制。
此处将介绍最常用到 Upgrade header的场合。
至今为止最经常会需要升级一个HTTP连接的场合就是使用WebSocket。当你用 WebSocket API 以及其他大部分实现WebSockets的库去建立WebSocket连接时，基本上都不用操心升级的过程，因为这些API已经实现了这一步。比如，用如下API打开一个WebSocket连接：
webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");
{{domxref("WebSocket.WebSocket", "WebSocket()")}} 构造函数已经自动完成了发送初始 HTTP/1.1 请求，处理握手及升级过程。
你也可以用 "wss://" 地址格式来打开安全的WebSocket连接。
如果想要自己重头实现WebSocket 连接，就必须要处理握手和升级过程。在创建初始HTTP/1.1会话之后你需要发送另一个HTTP标准请求，但在headers中要带上{{HTTPHeader("Upgrade")}} and {{HTTPHeader("Connection")}}，也就是：
Connection: Upgrade Upgrade: websocket
以下headers是在WebSocket升级过程中会出现的。除了 {{HTTPHeader("Upgrade")}} 和 {{HTTPHeader("Connection")}} headers, 其他的一般浏览器和服务器都会在交互过程中处理好。
用于指定一个或多个请求服务器使用的协议级WebSocket扩展。允许在一个请求中使用多个Sec-WebSocket-Extension头，结果跟在一个头文件中包含了所有列出的扩展一样。
Sec-WebSocket-Extensions: extensions
extensions例如：
Sec-WebSocket-Extensions: superspeed, colormode; depth=16
Provides information to the server which is needed in order to confirm that the client is entitled to request an upgrade to WebSocket. This header can be used when insecure (HTTP) clients wish to upgrade, in order to offer some degree of protection against abuse. The value of the key is computed using an algorithm defined in the WebSocket specification, so this does not provide security. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection. In essence, then, this key simply confirms that "Yes, I really mean to open a WebSocket connection."
This header is automatically added by clients that choose to use it; it cannot be added using the {{domxref("XMLHttpRequest.setRequestHeader()")}} method.
Sec-WebSocket-Key: key
keyThe server's response's Sec-WebSocket-Accept header will have a value computed based upon the specified key.
The Sec-WebSocket-Protocol header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a Sec-WebSocket-Protocol header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.
Sec-WebSocket-Protocol: subprotocols
subprotocolsSpecifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.
Sec-WebSocket-Version: version
versionIf the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a Sec-WebSocket-Version header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no Sec-WebSocket-Version header is included in the response.
Sec-WebSocket-Version: supportedVersions
supportedVersionsThe response from the server may include these.
Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the repsonse headers.
Sec-WebSocket-Accept: hash
hashSec-WebSocket-Key header was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the {{interwiki("wikipedia", "SHA-1")}} hash of that concatenated string, resulting in a 20-byte value. That value is then base64 encoded to obtain the value of this property.You can also upgrade an HTTP/1.1 connection to TLS/1.0. The main advantages to this are that you can avoid using URL redirection from "http://" to "https://" on the server and you can easily use TLS on virtual hosts. This may, however, introduce problems with proxy servers.
Upgrading an HTTP connection to use {{Glossary("TLS")}} uses the {{HTTPHeader("Upgrade")}} header with the token "TLS/1.0". If the switch is made successfully, the original request (which included Upgrade) is completed as normal, but on the TLS connection.
The request to TLS can be made either optionally or mandatorily.
To upgrade to TLS optionally (that is, allowing the connection to continue in cleartext if the upgrade to TLS fails), you simply use the Upgrade and {{HTTPHeader("Connection")}} headers as expected. For example, given the original request:
GET http://destination.server.ext/secretpage.html HTTP/1.1 Host: destination.server.ext Upgrade: TLS/1.0 Connection: Upgrade
If the server does not support TLS upgrade, or is unable to upgrade to TLS at the time, it responds with a standard HTTP/1.1 response, such as:
HTTP/1.1 200 OK Date: Thu, 17 Aug 2017 21:07:44 GMT Server: Apache Last-Modified: Thu, 17 Aug 2017 08:30:15 GMT Content-Type: text/html; charset=utf-8 Content-Length: 31374 <html> ... </html>
If the server does support TLS upgrade and wishes to permit the upgrade, it responds with the "101 Switching Protocols" response code, like this:
HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1
Once the TLS handshake is complete, the original request will be responded to as normal.
To request a mandatory upgrade to TLS—that is, to upgrade and fail the connection if the upgrade is not successful—your first request must be an {{HTTPMethod("OPTIONS")}} request, like this:
OPTIONS * HTTP/1.1 Host: destination.server.ext Upgrade: TLS/1.0 Connection: Upgrade
If the upgrade to TLS succeeds, the server will respond with "101 Switching Protocols" as described in the previous section. If the upgrade fails, the HTTP/1.1 connection will fail.
This works roughly the same way as a client-initiated upgrade; an optional upgrade is requested by adding the {{HTTPHeader("Upgrade")}} header to any message. A mandatory upgrade, though, works slightly differently, in that it requests the upgrade by replying to a message it receives with the {{HTTPStatus(426)}} status code, like this:
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.1, HTTP/1.1
Connection: Upgrade
<html>
... Human-readable HTML page describing why the upgrade is required
and what to do if this text is seen ...
</html>
If the client receiving the "426 Upgrade Required" response is willing and able to upgrade to TLS, it should then start the same process covered above under {{anch("Client-initiated upgrade to TLS")}}.