如何理解mqtt用到的101交换协议？

使用过mqtt的同窗都知道，mqtt链接时，在Network面板中的status是101。

Name	Status	Time
mqtt	101（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.bar
Request Method: GET
Status Code: 101 Switching Protocols

Request Headers

Connection: Upgrade 
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: xxx
Sec-WebSocket-Protocol: mqtt
Sec-WebSocket-Version: 13
Upgrade: websocket // client告诉server使用websocket协议
...

Response Headers

connection: Upgrade
sec-websocket-accept: fNs9ByuvC+rD75+tj2GMQAzbJms= // server基于client发出的Sec-WebSocket-Key:xxx计算得出，计算过程文章末尾有介绍
sec-websocket-protocol: mqtt
Upgrade: 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.1
Host: www.example.com
Connection: upgrade
Upgrade: 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: Upgrade
Upgrade: 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: xxx
Sec-WebSocket-Accept: fNs9ByuvC+rD75+tj2GMQAzbJms=

经过Sec-WebSocket-Key生成Sec-WebSocket-Accept的编码过程以下：

const SecWebSocketKey = "xxx"
const helper = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
const result = SecWebSocketKey + helper

const 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...

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

努力成为优秀的前端开发工程师！