WebSocket 理论知识

WebSocket 理论知识

基本信息

官网（已不可用）：websocket.org - Powered by Kaazing

维基百科：WebSocket - 维基百科，自由的百科全书

协议规范：RFC6455

协议标准：WebSockets Standard，不怎么长，很快能看完。

这里提一句 WHATWG 这个组织：

WHATWG 是 Web Hypertext Application Technology Working Group 的缩写，即 Web 超文本应用技术工作组。这个组织是一个由志愿者组成的组织，致力于开发和维护 Web 标准。其目标是使 Web 成为一个更开放、更创新、更安全的平台。官方网站为 WHATWG.org。

我们在学习 JavaScript 的相关知识的时候，会经常访问这个组织维护的 HTML Standard

WebSocket 是一种类似于 HTTP 网络传输协议，两者都是基于 TCP 协议，但是 WebSocket 更加简单，也更加高效，浏览器和服务器只需要完成一次握手，两者之间就可以建立持久性的连接，并进行双向的数据传输，即

除了客户端可以请求服务端之后，服务端还可以在客户端没有请求的情况下主动向客户端推送数据，而通过 HTTP 是无法做到这一点的。简而言之就是，在 WebSocket 协议中，建立连接的两端是平等的。

WebSocket 协议规范将 ws（WebSocket）和 wss（WebSocket Secure）定义为两个新的 统一资源标识符（URI）方案 [4|4]，分别对应明文和加密连接。除了方案名称和片段 ID（不支持 #）之外，其余的 URI 组件都被定义为此 URI 的通用语法。[5|5]。例如 ws://example.com/wsapi、wss://secure.example.com/wsapi。

Websocket 与 HTTP 和 HTTPS 使用相同的 TCP端口，可以绕过大多数 防火墙 的限制。默认情况下，Websocket 协议使用 80 端口；运行在 TLS 之上时，默认使用 443 端口。

WebSocket 与 HTTP 的关系与比较

参考博客：websocket 优缺点、应用场景以及与 HTTP 协议的异同 - 掘金

WebSocket 是一种与 HTTP 不同的协议。两者都位于 OSI 模型 的 应用层，并且都依赖于 传输层 的 TCP 协议。虽然它们不同，但是 RFC 6455 中规定：it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries（WebSocket 通过 HTTP 端口 80 和 443 进行工作，并支持 HTTP 代理和中介），从而使其与 HTTP 协议兼容。 为了实现兼容性，WebSocket 握手使用 HTTP Upgrade 头 [1|1] 从 HTTP 协议更改为 WebSocket 协议。

也就是说，虽然 WebSocket 和 HTTP 是两个不同的协议，但是 WebSocket 协议在握手阶段的工作是基于 HTTP 协议的。这个我们在后面的请求分析阶段有所验证。

与 HTTP 协议的相同点

与 HTTP 协议的不同点

HTTP 的缺点是什么

WebSocket 相比 HTTP 的优势

HTTP 是无状态的短链接，WebSocket 是有状态的长连接。WebSocket 对 HTTP 的优势主要还是在效率上有多方面的提升，这种效率的提升其实可以看作是长连接对短链接的提升。

长连接和短链接的区别请看下图：

可以看到 HTTP 每一次都是短连接，一个 TCP 连接的建立需要经过三四握手，因此 TCP 是比较重的，好不容易建立了连接，在 HTTP 协议中就用那么一会儿，虽然可以通过 TCP 复用来提高 TCP 连接的利用率，但是效率还是不如 WebSocket，在 WebSocket 中，一个 TCP 连接可以持续使用，而且是双向通信。

优势：

WebSocket 缺点也是有的：

主要用于做什么

WebSocket 解决了 HTTP 协议中传统轮询 (Traditional Polling)、长轮询 (Long Polling) 带来的问题（服务端负载、延迟等）。

WebSocket 在实时通信领域运用的比较多，比如社交聊天、弹幕、多玩家游戏、协同编辑、股票基金实时报价、体育实况更新、视频会议/聊天、基于位置的应用、在线教育、智能家居等需要高实时的场景。

WebSocket 的工作过程

参考博客：

WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系 (下篇)-网页端 IM 开发/专项技术区 - 即时通讯开发者社区！

万字长文，一篇吃透 WebSocket：概念、原理、易错常识、动手实践 - 网页端 IM 开发/专项技术区 - 即时通讯开发者社区！

WebSocket 协议深入探究_语言 & 开发_陈映平_InfoQ 精选文章

工作过程如下图所示：

首先，我们要清楚一点，WebSocket 基于 TCP，因此，我们需要通过三次握手，建立 TCP 连接，然后再开始进行通信。

《用电信号传输 TCP/IP 数据 —— 探索协议栈和网卡》的 TCP 报文头详解，

TCP 连接建立之后，首先由服务端发起一个 HTTP 请求到服务端，进行握手，握手之后，服务端和客户端同时升级 HTTP 协议为 WebSocket 协议，然后双方开始以 WebSocket 协议交换数据。

也就是说，WebSocket 的握手阶段，是通过 HTTP 协议实现的，然后后续服务端和客户端均采用的 WebSocket 协议，也是从当前已经建立的 HTTP 连接中升级而来，此时，我们会发现，WebSocket 对 HTTP 的兼容非常好，只要是能建立 HTTP 请求的地方，都可以实现 WebSocket 协议的通信，这也是 WebSocket 的握手使用 HTTP 来实现的目的，即最大的对 HTTP 的兼容。现有的网络环境（客户端、服务器、网络中间人、代理等）对 HTTP 都有很好的支持，所以这样做可以充分利用现有的 HTTP 的基础设施。

下面我们来详细分析握手和数据传输这两个阶段

通过 HTTP 握手

Websocket 通过 HTTP/1.1 协议的 101 状态码 进行握手。

客户端发起的请求消息如下，注意必须是 GET 请求，且 HTTP 版本必须大于 1.1

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

对消息头/报头的分析如下：

如果服务器接受了这个请求，可能会发送如下这样的返回信息，这是一个标准的 HTTP 的 Response 消息。101 表示服务器收到了客户端切换协议的请求，并且同意切换到此协议。

RFC2616 规定只有切换到的协议「比 HTTP1.1 更好」的时候才能同意切换。

服务端返回的响应：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

如果返回的返回码不是 101，则按照 RFC2616 进行处理。如果是 101，进行下一步，开始解析 header 域，所有 header 域的值不区分大小写；

判断是否含有 Upgrade 头，且内容包含 websocket；

判断是否含有 Connection 头，且内容包含 Upgrade；

判断是否含有 Sec-WebSocket-Accept 头，其内容在下面介绍；

如果含有 Sec-WebSocket-Extensions 头，要判断是否之前的 Request 握手带有此内容，如果没有，则连接失败；

如果含有 Sec-WebSocket-Protocol 头，要判断是否之前的 Request 握手带有此协议，如果没有，则连接失败。

Sec-WebSocket-Key 与 Sec-WebSocket-Accept

服务端为了告知客户端它已经接收到了客户端的握手请求，服务端需要返回一个包含 Sec-WebSocket-Accept 的握手响应。这个值的信息来自于客户端的握手请求中的 Sec-WebSocket-Key 头字段：

也就是说，服务端返回的 Header 字段 Sec-WebSocket-Accept 是根据客户端请求 Header 中的 Sec-WebSocket-Key 计算出来。

Sec-WebSocket-Key/Sec-WebSocket-Accept 在主要作用在于提供基础的防护，减少恶意连接、意外连接。作用大致归纳如下：

  1. 避免服务端收到非法的 WebSocket 连接（比如 http 客户端不小心请求连接 WebSocket 服务，此时服务端可以直接拒绝连接）
  2. 确保服务端理解 WebSocket 连接。因为 ws 握手阶段采用的是 http 协议，因此可能 ws 连接是被一个 http 服务器处理并返回的，此时客户端可以通过 Sec-WebSocket-Key 来确保服务端认识 ws 协议。（并非百分百保险，比如总是存在那么些无聊的 http 服务器，光处理 Sec-WebSocket-Key，但并没有实现 ws 协议。。。）
  3. 用浏览器里发起 ajax 请求，设置 header 时，Sec-WebSocket-Key 以及其他相关的 header 是被禁止的。这样可以避免客户端发送 ajax 请求时，意外请求协议升级（websocket upgrade）
  4. 可以防止反向代理（不理解 ws 协议）返回错误的数据。比如反向代理前后收到两次 ws 连接的升级请求，反向代理把第一次请求的返回给 cache 住，然后第二次请求到来时直接把 cache 住的请求给返回（无意义的返回）。
  5. Sec-WebSocket-Key 主要目的并不是确保数据的安全性，因为 Sec-WebSocket-Key、Sec-WebSocket-Accept 的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）。

强调：Sec-WebSocket-Key+Sec-WebSocket-Accept，只能带来基本的保障，但连接是否安全、数据是否安全、客户端 / 服务端是否合法的 ws 客户端、ws 服务端，其实并没有实际性的保证。也避免不了中间人攻击，因为 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 是一个固定值，而 HTTP 请求中的 header 又是很容易获得的，因此可以很容易地进行劫持，如果想要避免中间人攻击，得使用加密后的 WebSocket，即 wss。

通过 WebSocket 协议传输数据

WebSocket 中所有发送的数据使用帧的形式发送。客户端发送的数据帧都要经过掩码处理，服务端发送的所有数据帧都不能经过掩码处理。否则对方需要发送关闭帧。

一个帧包含一个帧类型的标识码，一个负载长度，和负载。负载包括扩展内容和应用内容，结构很简单。

帧其实就是比特流，输出的时候，就是一个比特接着一个比特地输出。

针对上图，你可以理解为每一行的比特都是接在上一行最后一个比特的后面的，之所以用 32 个比特一行来拆分成多行，主要是为了方便展示，不然只用一行比特的话，直观是直观，但是不好看

第二行的 0-9 的循环，表示的是比特位，第一行 0123 表示的是比特数量的十位，一行总共 32 个比特，也就是 4 个字节。

Payload data 以外的部分，其实都是为了通信而增加的成本，当这个成本很大的时候，消息传递的效率就很低。在握手阶段结束后，采用 WebSocket 协议交换数据，通过上面对数据帧的分析，我们可以发现，用于协议控制的数据包头部相对 HTTP 来说是很小的。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有 2 至 10 字节（只包含 FIN、RSV1, RSV2, RSV3、Opcode、Mask、Payload length）；对于客户端到服务器的内容，此头部还需要加上额外的 4 字节的掩码（Masking-key）。相对于 HTTP 请求每次都要携带完整的头部，此项开销显著减少了。

掩码算法

参考：websocket 报文格式及掩码处理方式 - 老耗子 - 博客园

掩码键 Masking-key 是由客户端生成的 32 位的随机数。掩码、反掩码操作均以字节为单位进行异或运算，而不是以比特为单位进行异或运算，掩码操作不会影响数据载荷的长度。

首先，介绍几个概念

掩码、反掩码操作都采用如下算法：

掩码算法描述为：original-octet-i 与 masking-key-octet-j 异或后，得到 transformed-octet-i。

j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

反掩码算法描述为：transformed-octet-i 与 masking-key-octet-j 异或后，得到 original-octet-i。

j = i MOD 4
original-octet-i = transformed-octet-i XOR masking-key-octet-j

这里用到了一个定理，参与异或运算的两个数，异或运算的结果和其中一个数继续进行异或运算，可以得出另一个数

《Java 基本程序设计结构》的 位运算符 小节在讲解异或运算的时候介绍过

简单实践：

客户端：发送语音文件到服务端，先发送 txt 消息文件名称 "tts"；再读物文件，发送 bin 消息二进制流数据 (多帧发送)。

服务端：先接收 txt 消息，需要接收的文件名称并创建打开；再接收 bin 消息语音流消息，并写入文件；当接收到最后一帧二进制后，关闭打开的文件。

传输 txt 消息的时候，生成的掩码 KEY：00001110 00101001 10101100 11010000，四个字节对应的数字为 14、51、172、208。

客服端处理消息，字母 t 的 ASCII 码为 116，字母 s 的 ASCII 码为 115，"tts" 转化为 ASCII 码为 116 116 115，

最终发送的用于网络传输的消息的字节为 122，71，223

服务端收到消息数据：122，71，223 后，也获取了四字节的掩码 00001110 00101001 10101100 11010000，四个字节对应的数字为 14、51、172、208。然后开始反掩码运算

解码获取字符串：116，116，115；即字符：tts

掩码的这个计算方式，其实并不能起到多大的安全作用，本质原因是因为一个消息帧中包含了掩码本身，经过简单的运算即可进行反编码操作拿到原始的消息，可见，掩码的设计，并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）等问题。关于代理缓存污染攻击的原理可以参考 WebSocket 协议深入探究 的 数据掩码的作用 小节。

数据分片

参考：WebSocket 协议深入探究_语言 & 开发_陈映平_InfoQ 精选文章

当我们只需要用一个帧就可以传完的时候，FIN 为 1，Opcode 为 1，表示传递的是一个文本，而且已经传完，如果是二进制帧，则 Opcode 为 2

当我们需要用多个帧来传递一个字符串的时候，每一个帧的情况如下，

  1. FIN=0，opcode=0x1，表示发送的是文本类型，且消息还没发送完成，还有后续的数据帧。
  2. FIN=0，opcode=0x0，表示消息还没发送完成，还有后续的数据帧，当前的数据帧需要接在上一条数据帧之后。
  3. FIN=1，opcode=0x0，表示消息已经发送完成，没有后续的数据帧，当前的数据帧需要接在上一条数据帧之后。服务端可以将关联的数据帧组装成完整的消息。

与 HTTP 消息/报文的不同

HTTP 是文本协议，我们在看 HTTP 报文的时候一般看到的都是字符 (其实最终也是以 TCP 帧的格式传递)，而 WebSocket 的消息并不是一个文本协议，其直接采用跟 TCP 一样的比文本更底层的二进制数据帧，这样可以直接对接 TCP 的 socket，我们在分析 WebSocket 的帧的时候，跟分析 tcp 的请求的时候感觉很像。

关于 TCP 的数据帧的分析，请看《用电信号传输 TCP/IP 数据 —— 探索协议栈和网卡》的 TCP 报文头详解，

总结

学完 WebSocket 之后，感觉基于 TCP，或者说基于 socket，开发一个自定义的网络协议，并不是一种难事。开发一种网络传输协议，实际上就是将数据以一种固定的格式序列化化成一个消息帧，然后在接收端根据协议格式将数据读取出来。TCP、HTTP 还有 WebSocket 都是如此。

关于如何将消息序列化成帧，请看《Java 序列化》

在学习了 Netty 之后，我们和可以很方便地进行 socket 编程，而且可以直接操作字节流，更多详细信息，请看《Netty 设计》和《Netty 基础实践》

通过 Nginx 代理

WebScoket 协议如需要通过 nginx 代理，需要 location 节点增加以下节点即可正常建立连接

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

一个是启用 HTTP 1.1，因为 Nginx 对 HTTP 的反向代理，默认使用 HTTP 1.0 连接到后端，那样没法保持长连接，后端作出 HTTP 响应后，连接就被掐断了，所以启用 HTTP 1.1 以支持长连接。

一个是设置消息头 Upgrade 和 Connection，为什么要让 Nginx 加这个请求头，对于 WebSocket 协议，客户端不是已经加了 Upgrade 和 Connection 请求头了吗？那是因为根据 HTTP 协议规范，Upgrade 和 Connection 属于 hop-by-hop 请求头（跳跳请求头），Nginx 作为中间的代理，按照规范不能直接转发 hop-by-hop header，所以需要我们手工强制设定。

关于什么是 hop-by-hop header，请看《nginxTips.md》

跨域

参考博客：javascript - Why is there no same-origin policy for WebSockets? Why can I connect to ws://localhost? - Stack Overflow

首先我们要搞清楚，什么同源策略 SOP（Same Origin Policy），所谓 " 同源 " 指的是 " 三个相同 "。

举例来说，http://www.example.com/dir/page.html 这个网址，协议是 http://，域名是 www.example.com，端口是 80（默认端口可以省略）。它的同源情况如下。

随着互联网的发展，" 同源政策 " 越来越严格。目前，如果非同源，共有三种行为受到限制。

关于跨域的详细知识，请看《跨域相关知识》

我们所说的跨域请求（Cross Origin Request），其实就是违反了同源策略的跨源请求。

这里有一点需要注意，并不是 JavaScript 中所有的 URL 请求都受到 SOP 的限制，而是这些 URL 请求中，只有通过 AJAX 发出的时候，才会被 SOP 限制，请求资源 (包括 <img>、<link> 和 <script> 标签) 的跨域 GET 请求和提交表单时的跨域 POST 请求一直被允许的，是可行的，这两种请求是 Web 的基本特性。现在，请求具有相同属性的跨域 AJAX 调用也被允许，称为 简单跨域请求。但是，除非服务器的 CORS 消息头明确允许，否则不允许在代码中访问来自此类请求的返回数据。而且，正是因为某些恶意网站会发起这种 简单跨域请求（主要是 POST 请求），所以服务器需要 anti-CSRF tokens 来保护自己（CSRF：Cross-site request forgery），以阻止数据被不信任的请求篡改。

为什么 WebSocket 可以跨域？

首先，WebSocket 建立连接是通过 WebSocket 的自己的客户端，而不是通过 AJAX，因此，是不受 SOP 限制的。

而且 WebSocket 协议本身不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。在 通过 HTTP 握手 小节，分析 WebSocket 握手时的 HTTP 请求分析过，有一个消息头是 Origin，表示该请求的请求源（origin），即发自哪个域名。这个消息头必须有，否则 WebSocket 服务器需要回复 HTTP 403 状态码（禁止访问），正是因为有了 Origin 这个字段，所以 WebSocket 才没有实行同源政策。因为服务器可以根据这个字段，判断是否许可本次通信。如果该域名在白名单内，，服务器就会正常响应。

其实也可以换个角度解释，为什么 WebSocket 不跟 HTTP 一样采用相同的同源限制设计（采用 CROS 之类的设计）。

对于 AJAX，在实行 SOP 策略的时代，服务器从不期望经过身份验证的浏览器从不同的域发送请求，因此不需要确保请求来自受信任的位置，只需检查会话 cookie。后来 SOP 有所放松 (如 CORS)，必须进行客户端检查，以避免使现有应用程序遭受 CSRF（Cross-site request forgery）攻击。

如果 Web 是今天发明的，了解我们现在所知道的，那么 AJAX 就不需要 SOP 和 CORS 了，所有的验证都可能留给服务器。

WebSockets 作为一种较新的技术，从一开始就被设计为支持跨域场景，所有的对请求来源的验证和限制，都留给了服务器。任何编写服务器逻辑的人都应该意识到跨域请求的可能性，并执行必要的验证，而不需要像 CORS 那样采取严厉的浏览器端预防措施。

超时配置

参考博客：# nginx中的超时设置，请求超时、响应等待超时等

Nginx 在将请求转发给被代理的服务的时候，也是有一个超时时间的，不可能无限等待，但是如果有的请求处理就是非常耗时，那么我们就需要将超时时间调大一点，避免 Nginx 抛出超时异常，比如 502 badgateway（对应 error.log 中的 connect() failed 10060）,配置超时大概有以下几个配置：
nginx 比较强大,可以针对单个域名请求做出单个连接超时的配置. 
比如些动态解释和静态解释可以根据业务的需求配置