应用过mqtt的同学都晓得，mqtt连贯时，在Network面板中的status是101。

NameStatusTime
mqtt101（Switching Protocols）Pending

那么101（Switching Protocols）到底是什么意思呢？
这篇文章将带你了解101替换协定是什么，以及101替换协定使用的协定降级机制。

  • 101替换协定
  • 协定降级机制

101替换协定

HTTP的101替换协定意味着client向server发送的音讯中蕴含了Upgrade申请头，server会依据client发送的这个申请头切换协定。

server会在response中增加一个Upgrade响应头，来批示server切换到的协定。

用一句话来说就是：client通过在申请头中增加Upgrade通知server切换协定，server在响应头中增加upgrade阐明切换后的协定。

再简略一点就是：客户端通知服务端去切换协定。

General

Request URL: wss://foo.barRequest Method: GETStatus Code: 101 Switching Protocols

Request Headers

Connection: Upgrade Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bitsSec-WebSocket-Key: xxxSec-WebSocket-Protocol: mqttSec-WebSocket-Version: 13Upgrade: websocket // client通知server应用websocket协定...

Response Headers

connection: Upgradesec-websocket-accept: fNs9ByuvC+rD75+tj2GMQAzbJms= // server基于client收回的Sec-WebSocket-Key:xxx计算得出，计算过程文章开端有介绍sec-websocket-protocol: mqttUpgrade: websocket // server通知client，咱们（client，server）应用的是websocket协定...

其中这些申请头是什么意思呢？Connection，Sec-WebSocket-Extensions，Sec-WebSocket-Key，Sec-WebSocket-Protocol，Sec-WebSocket-Version等等。
响应头呢？sec-websocket-accept，sec-websocket-protocol。

看了上面的协定降级机制就明确了。

协定降级机制

HTTP1.1版本的协定有一个非凡的机制：降级一个曾经建设的连贯为另外一个协定，个别是通过Upgrade头来实现。

这个机制是可选的，它不能强制协定扭转。尽管实现反对新协定，然而也能够抉择不降级。在理论利用中，通常这个机制用于疏导WebSocket进行连贯。

留神，HTTP2.0版本明确禁止应用这个机制。只能用于HTTP1.1。

降级HTTP/1.1连贯

client能够应用Upgrade头去邀请服务器去切换为协定列表中的某一项，依照降序。

因为Upgrade是一个逐跳头，因而它须要一个Connection头。
这也就意味着一个典型的蕴含Upgrade报文头的申请为：

GET /index.html HTTP/1.1Host: www.example.comConnection: upgradeUpgrade: example/1, foo/2

其余的头个别是依赖申请协定的；例如，WebSocket降级容许额定的头去配置WebSocket连贯，并在关上时就有肯定的安全性。

如果服务器决定去降级连贯，分为降级胜利和降级失败两种状况：

  • 降级胜利：它会返回一个101 Switching Protocols响应状态，并且Upgrade头中指明它切换后的协定。
  • 降级失败：如果服务端不能降级连贯，它会疏忽Upgrade头，而后返回一个惯例的响应（例如 200 OK）

服务器发送完101状态码之后，它能够立刻开始应用新协定，并且进行与其余协定的handshake。一旦连贯建设实现，连贯就变为双向管道，初始化降级的申请能够再协定之上初始化。

协定降级机制的惯例用法

Upgrade这个头会用在哪些场景呢？而且与WebSocket连贯无关的申请头都有哪些呢？

  • 降级为WebSocket连贯

  • 与WebSocket连贯无关的申请头

    • Sec-WebSocket-Extensions
    • Sec-WebSocket-Key
    • Sec-WebSocket-Protocol
    • Sec-WebSocket-Version
    • Sec-WebSocket-Accept（只读）
降级为WebSocket连贯

最常见的降级HTTP连贯的场景，就是应用WebSockets的场景，通常是通过降级HTTP或者HTTPS连贯的形式来实现。如果你应用WebSocket API去开启一个连贯，或者任何WebSockets的库，大多数或者说所有的事件都曾经为你做好了。

例如：建设一个WebSocket连贯非常简单，只须要这样既可：

webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol")

WebSockek()构造函数为开发者在外部做了所有创立一个HTTP/1.1连贯，握手和降级的事件。

能够用"wss://" 去建设一个平安的WebSocket连贯。

如果你想本人手动建设一个WebSocket连贯的话，你须要本人去解决握手过程。在创立完HTTP/1.1会话之后，你须要在申请上增加Upgrade和Connection这两个申请头。

Connection: UpgradeUpgrade: websocket
与WebSocket连贯无关的申请头

上面这些申请头是WebSocket降级过程中蕴含的申请头。与Upgrade和Connection头不同，上面这些申请头

Sec-WebSocket-Extensions

申明一个或者多个协定级的WebSocket扩大区通知服务器应用。在一个申请里应用一个或者多个Sec-WebSocket-Extension头是能够的；放在一起用分号隔开也能够。

Sec-WebSocket-Extensions: extensions

extensions须要用分号离开。须要从插件列表里抉择。

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

咱们下面例子中的permessage-deflate也在其中。

permessage-deflate | WebSocket Per-Message Deflate | [RFC7692] | None | [RFC7692]

Sec-WebSocket-Key

向服务端提供客户端有权降级为WebSocket的信息。这个头可用于不平安的HTTP想要降级时，为了提供某种程度的爱护，避免滥用。key的值应用在WebSocket标准中定义的算法生成，所以这并不保障安全性。

这个key是为了搁置非WebSocket的客户端无心中进行websocket连贯或者滥用。
实质上，这个key代表着：“是的，我的确是要开启一个WebSocket连贯的。”

这个头会主动被应用它的客户端增加，不能被XMLHttpRequest.setRequestHeader() 增加

Sec-WebSocket-Key: key

基于这个key，服务器会在响应的Sec-WebSocket-Accept头中加一个基于这个key的计算数据。

Sec-WebSocket-Protocol

这个头会申明一个或者多个你想要应用的WebSocket协定。
申请头发送Sec-WebSocket-Protocol，响应头也会返回Sec-WebSocket-Protocol。

Sec-WebSocket-Protocol: subprotocols

subprotocols包含以下这些协定：https://www.iana.org/assignme...

下面示例中的mqtt也在其中：mqtt | mqtt | [MQTT Version 5.0]

Sec-WebSocket-Version

作为申请头：
申明客户端应用的WebSocket协定版本。

Sec-WebSocket-Version: version

服务器与客户端通信的WebSocket协定版本：https://www.iana.org/assignme...

最罕用的是13。

作为响应头：
如果服务器不反对WebSocket协定，会返回相似426（Upgrade Required）并且在Sec-WebSocket-Version头中返回反对的WebSocket版本列表。如果不反对，不返回Sec-WebSocket-Version头。

Sec-WebSocket-Version: supportedVersions
Sec-WebSocket-Accept

服务器与客户端建设握手过程中的响应头。至少呈现一次：

Sec-WebSocket-Accept: hash

如果有Sec-WebSocket-Key，将字符串“ 258EAFA5-E914-47DA-95CA-C5AB0DC85B11”连贯到该字符串，并且取SHA-1的20位 hash值。最初进行base64编码。

在咱们的例子中：

Sec-WebSocket-Key: xxxSec-WebSocket-Accept: fNs9ByuvC+rD75+tj2GMQAzbJms=

通过Sec-WebSocket-Key生成Sec-WebSocket-Accept的编码过程如下：

const SecWebSocketKey = "xxx"const helper = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"const result = SecWebSocketKey + helperconst crypto = require('crypto')const shasum = crypto.createHash('sha1')shasum.update(result)const SecWebSocketAccept = shasum.digest('base64');console.log(SecWebSocketAccept) // fNs9ByuvC+rD75+tj2GMQAzbJms=

在线demo：https://www.jdoodle.com/ia/e3G

既然key到accept的算法曾经很清晰了，那么能够通过accept反向求解出key吗？
答案是否定的。这是因为用到了sha1加密。

明码强哈希函数有两个特点:其中一个很重要的特点就是不可逆。不可逆性意味着原始数据无奈从其散列中重建，所以不能通过accept反向求解出key。

参考资料：

https://developer.mozilla.org...
https://developer.mozilla.org...
https://stackoverflow.com/que...
https://nodejs.org/api/buffer...
https://stackoverflow.com/que...

文章首发于前端公众号：大大大前端

致力成为优良的前端开发工程师！