WebSocket是为了解决双向通信的问题，因为一方面HTTP的设计是单向的，只能是一边发另一边收。而另一方面，HTTP等都是建立在TCP连接之上的，HTTP请求完就会把TCP给关了，而TCP连接本身就是一个长连接吗，只要连接双方不断关闭连接它就会一直连接态，所以有必要再搞一个WebSocket的东西吗？
我们可以考虑一下，如果不搞WebSocket怎么实现长连接：
（1）HTTP有一个keep-alive的字段，这个字段的作用是复用TCP连接，可以让一个TCP连接用来发多个http请求，重复利用，避免新的TCP连接又得三次握手。这个keep-alive的时间服务器如 Apache 的时间是5s，而 nginx 默认是75s，超过这个时间服务器就会主动把TCP连接关闭了，因为不关闭的话会有大量的TCP连接占用系统资源。所以这个keep-alive也不是为了长连接设计的，只是为了提高http请求的效率，而http请求上面已经提到它是面向单向的，要么是服务端下发数据，要么是客户端上传数据。
（2）使用HTTP的轮询，这也是一种很常用的方法，没有websocket之前，基本上网页的聊天功能都是这么实现的，每隔几秒就向服器发个请求拉取新消息。这个方法的问题就在于它也是需要不断地建立TCP连接，同时HTTP头部是很大的，效率低下。
（3）直接和服务器建立一个TCP连接，保持这个连接不中断。这个至少在浏览器端是做不到的，因为没有相关的API。所以就有了WebSocket直接和服务器建立一个TCP连接。
TCP连接是使用套接字建立的，如果你写过Linux服务的话，就知道怎么用系统底层的API（C语言）建立一个TCP连接，它是使用的套接字socket，这个过程大概如下，服务端使用socket创建一个TCP监听：
// 先创建一个套接字，返回一个句柄，类似于setTimout返回的tId
// AF_INET是指使用IPv4地址，SOCK_STREAM表示建立TCP连接（相对于UDP）
int sockfd = socket(AF_INET, SOCK_STREAM, 0));
// 把这个套接字句柄绑定到一个地址，如localhost:9000
bind(sockfd, servaddr, sizeof(servaddr));
// 开始使用这个套接字监听，最大pending的连接数为100
listen(sockfd, 100);
客户端也使用的套接字进行连接：
// 客户端也是创建一个套接字
int sockfd = socket(AF_INET, SOCK_STREAM, 0));
// 用这个套接字连接到一个serveraddr
connect(sockfd, servaddr, sizeof(servaddr));
// 向这个套接字发送数据
send(sockfd, sendline, strlen(sendline), 0);
// 关闭连接
close(sockfd);
也就是说TCP和UDP连接都是使用套接字创建的，所以WebSocket的名字就是这么来的，本质上它就是一个套接字，并变成了一个标准，浏览器器开放了API，让网页开发人员也能直接创建套接字和服务端进行通信，并且这个套接字什么时候要关闭了由你们去决定，而不像http一样请求完了浏览器或者服务器就自动把TCP的套接字连接关了。
所以说WebSocket并不是一个什么神奇的东西，它就是一个套接字。同时，WebSocket得借助于现有的网络基础，如果它再从头搞一套建立连接的标准代价就会很大。在它之前能够和服务连接的就只有http请求，所以它得借助于http请求来建立一个原生的socket连接，因此才有了协议转换的那些东西。
浏览器建立一个WebSocket连接非常简单，只需要几行代码：
// 创建一个套接字
const socket = new WebSocket('ws://192.168.123.20:9090');
// 连接成功
socket.onopen = function (event) {
console.log('opened');
// 发送数据
socket.send('hello, this is from client');
};
因为浏览器已经按照文档实现好了，而要创建一个WebSocket的服务端应该怎么写呢？这里我们先抛开Chrome源码，先研究服务端的实现，然后再反过来看浏览器客户端的实现。准备用Node.js实现一个WebSocket的服务端，来研究整一个连接建立和接收发送数据的过程是怎么样的。
WebSocket已经在 RFC 6455 里面进行了标准化，我们只要按照文档的规定进行实现就能和浏览器进行对接，这个文档的说明比较有趣，特别是第1部分，有兴趣的读者可以看看，并且我们发现WebSocket的实现非常简单，读者如果有时间的话可以先尝试自己实现一个，然后再回过头来，对比本文的实现。
1. 连接建立
使用Node.js创建一个hello, world的http服务，如下代码index.js所示：
let http = require("http");
const hostname = "192.168.123.20"; // 或者是localhost
const port = "9090";
// 创建一个http服务
let server = http.createServer((req, res) => {
// 收到请求
console.log("recv request");
console.log(req.headers);
// 进行响应，发送数据
// res.write('hello, world');
// res.end();
});
// 开始监听
server.listen(port, hostname, () => {
// 启动成功
console.log(`Server running at ${hostname}:${port}`);
});
注意到这里没有任何的出错和异常处理，被省略了，在实际的代码里面为了提高程序的稳健性需要有异常处理，特别是这种server类的服务，不能让一个请求就把整个server搞挂了。相关出错处理可以参考Node.js的文档。
保存文件，执行node index.js启动这个服务。
然后写一个index.html，请求上面写的服务：
<!DOCType html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<script>
!function() {
const socket = new WebSocket('ws://192.168.123.20:9090');
socket.onopen = function (event) {
console.log('opened');
socket.send('hello, this is from client');
};
}();
</script>
</body>
</html>
但是我们发现，Node.js代码里的请求响应回调函数并不会执行，查了文档发现是因为Node.js有另外一个upgrade的事件：
// 协议升级
server.on("upgrade", (request, socket, head) => {
console.log(request.headers);
});
因为WebSocket需要先协议升级，在upgrade里面就能收到升级的请求。把收到的请求头打印出来，如下所示：
{ host: ‘192.168.123.20:9090’,
connection: ‘ Upgrade ‘,
pragma: ‘no-cache’,
‘cache-control’: ‘no-cache’,
upgrade: ‘websocket’,
origin: ‘http://127.0.0.1:8080’,
‘sec-websocket-version’: ’13’,
‘user-agent’: ‘Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36’,
‘accept-encoding’: ‘gzip, deflate’,
‘accept-language’: ‘en,zh-CN;q=0.9,zh;q=0.8,zh-TW;q=0.7’,
‘ sec-websocket-key ‘: ‘KR6cP3rhKGrnmIY2iu04Uw==’,
‘sec-websocket-extensions’: ‘permessage-deflate; client_max_window_bits’ }
这是我们建立连接收到的第一个请求，里面有两个关键的字段，一个是connection: ‘Upgrade’表示它是一个升级协议请求，另外一个是sec-websocket-key，这是一个用来确认对方身份的随机的base64字符串，下面将会用到。
我们需要对这个请求进行响应，按照文档的说明，需要包含以下字段：
server.on("upgrade", (request, socket, head) => {
let base64Value = '';
// 第一行是响应行（Response line），返回状态码101
socket.write('HTTP/1.1 101 Web Socket Protocol Handshake\r\n' +
// http响应头部字段用\r\n隔开
'Upgrade: WebSocket\r\n' +
'Connection: Upgrade\r\n' +
// 这是一个给浏览器确认身份的字符串
`Sec-WebSocket-Accept: ${base64Value}\r\n` +
'\r\n');
});
响应报文需要按照http规定的格式，第一行是响应行，包含了http的版本号，状态码101，状态码的解释。每个头部字段用\r\n隔开，这里面最关键的一个是Sec-WebSocket-Accept，它需要计算一下返回浏览器。怎么计算呢？文档是这么规定的：
GUID(Globally_Unique_Identifier) = ‘258EAFA5-E914-47DA-95CA-C5AB0DC85B11’
Sec-WebSocket-Accept = base64(sha1(Sec-Websocket-key + GUID))
使用浏览器给我的sec-websocket-key值，拼上一个固定的字符串，这个字符串叫全局唯一标志符，然后取它的sha1值，再进行base64编码，返回给浏览器。如果浏览器发现这个值不对的话，就会抛异常，拒绝下一步的连接操作：
因为它发现你是一个假的WebSocket服务，起码不是按照文档实现的，所以不是同一个世界，没有共同语言，下面的交流就没有必要了。
为了计算这个值需要引入一个sha1库，base64转换可以使用Node.js的Buffer转换，如下代码所示：
let sha1 = require('sha1');
// 协议升级
server.on("upgrade", (request, socket, head) => {
// 取出浏览器发送的key值
let secKey = request.headers['sec-websocket-key'];
// RFC 6455规定的全局标志符(GUID)
const UNIQUE_IDENTIFIER = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
// 计算sha1和base64值
let shaValue = sha1(secKey + UNIQUE_IDENTIFIER),
base64Value = Buffer.from(shaValue, 'hex').toString('base64');
socket.write('HTTP/1.1 101 Web Socket Protocol Handshake\r\n' +
'Upgrade: WebSocket\r\n' +
'Connection: Upgrade\r\n' +
`Sec-WebSocket-Accept: ${base64Value}\r\n` +
'\r\n');
});
使用上面浏览器发送的key计算得到的accept值为：
RWMSYL3Zmo91ZR+r39JVM2+PxXc=
把这个值发给浏览器，Chrome就不会报刚刚那个检验出错了，确认过眼神，遇上对的人。这样WebSocket连接就建立了，没错就是这么简单。Chrome开发者工具Network面板里的websocket连接将会从pending状态变成101状态，如果连接关闭了就会变成200状态。
上面浏览器的代码在建立连接完成之后还send了一个数据过来：
socket.send('hello, this is from client');
怎么读取这个数据呢？
2. 接收数据
数据的传送，文档规定了WebSocket数据帧格式，长这个样子：
不要被这个吓到，一个个拆解来看的话，还是挺简单的。可以分成两个部分，帧头字段和有效内容或者叫有效负载（Payload Data），帧头字段主要的作用是为了解释这个帧的，如第1位（bit） FIN 如果置为1就表示它是一个结束帧，如果数据比较长就会被拆成几个帧发送，FIN为1表示它是当前数据流的最后一个帧。第4到第7倍的 opcode 是用来做一些指令控制的，如果值为1话就表示Payload Data是文本格式的，2则表示二进制内容，8表示连接关闭。第9位到第15位共7位 Payload Len 表示有效负载的字节数，7位二进制数最大表示127，如果有效负载字节数大于127的话就需要用到Extended payload length部分。
第8位的 Mask 如果设置为1就表示这个帧的有效负载内容被掩码处理过了，客户端向服务端发送的帧需要进行掩码，而服务端向客户端发送的数据帧不需要掩码。为什么要使用掩码，这个掩码计算又是怎么进行的呢？掩码计算很简单，就是把要发送的数据和另一个数字异或一下再放到Payload Data， 这个数字就是上面数据帧里的 Masking-key ，它是一个32位的数字。接收方把Payload Data再和这个数异或一下就能得到原始的数据，因为和同一个数异或两次等于原本的数，即：
a ^ b ^ b = a
并且每个帧里的Making-key要求都是随机的，不可被（代理）服务所预测的，为什么要这样呢？文档里面是这么说的：
The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire
这个解释有点含糊， Stackoverflow 上有人说是为了避免代理缓存中毒攻击，具体可参考 Http Cache Poinsing .
所以我们需要从这个帧里面取出掩码的key值，还原原始的paylod数据。
数据的发送和传输都要靠socket对象，因为它不是走的http请求，所以在http的响应函数里面是收不到数据的，在upgrade事件里面可以拿到这个socket，监听这个socket对象的data事件，就可以得到接收的数据：
socket.on('data', buffer => {
console.log('buffer len = ', buffer.length);
console.log(buffer);
});
返回的数据类型是Node.js里的Buffer对象，把这个buffer打印出来：
buffer len = 32 <Buffer 81 9a 4c 3f 64 75 24 5a 08 19 23 13 44 01 24 56 17 55 25 4c 44 13 3e 50 09 55 2f 53 0d 10 22 4b>
这个buffer就是websocket客户端给我们发送的数据帧了，总共有32个字节，上面的打印是用的16进制表示，可以改二进制0101表示，和上面那个数据帧格式图一一对照，就能够解释这个数据帧是什么意思，有什么内容。把它打印成原始二进制表示：
参照报文格式，如下图所示：
通过opcode可以知道它是一个文本数据的帧，payload len得到文本长度为26个字节，这个刚好等于上面发送的内容长度：
同时掩码Mask是打开的，掩码key值存放范围是[16, 16 + 32]，因为这里不需要使用扩展字段，所以Masking-key就直接跟在Payload len后面了，再往后就是Payload Data，范围是[48, 48 + 26 * 8].
这就是一个完整的数据帧了，还需要把payload data用掩码异或一下，还原原始数据。在Node.js里面进行处理。Node.js里面的Buffer类只能操作字节级别，如读取第n个字节的内容，没办法直接操作位，如读取第n位的数据。所以额外引入一个库，网上找了一个BitBuffer，但是它的实现好像有问题，所以自已实现了一个。
如下代码所示，实现一个能够读取任意位的BitBuffer：
class BitBuffer {
// 构造函数传一个Buffer对象
constructor (buffer) {
this.buffer = buffer;
}
// 获取第offset个位的内容
_getBit (offset) {
let byteIndex = offset / 8 >> 0,
byteOffset = offset % 8;
// readUInt8可以读取第n个字节的数据
// 取出这个数的第m位即可
let num = this.buffer.readUInt8(byteIndex) & (1 << (7 - byteOffset));
return num >> (7 - byteOffset);
}
}
原理很简单，先调Node.js的Buffer的readUInt8读取第n个字节的数据，然后计算一下所要读取的位数在这个字节的第几位，通过与运算，把这个位取出来，更多位运算可以参考： 巧用JS位运算 。
用这个代码取出第8位的Mask Flag是否有设置，如下代码：
socket.on('data', buffer => {
let bitBuffer = new BitBuffer(buffer);
let maskFlag = bitBuffer._getBit(8);
console.log('maskFlag = ' + maskFlag);
});
打印maskFlag = 1。那么怎么取出连续的n位呢，如opcode，是从第4位到7位。这个也好办就是把第4位到第7位分别取出来拼成一个数就好了：
getBit (offset, len = 1) {
let result = 0;
for (let i = 0; i < len; i++) {
result += this._getBit(offset + i) << (len - i - 1);
}
return result;
}
这个代码的效率不是很高，但是容易理解。有个小坑就是JS的位移只支持32位整数的操作，1 << 31会变成一个负数，具体不展开讨论。用这个函数取32位的掩码值就会有问题。
可以利用这个函数取出opcode和payload len：
socket.on('data', buffer => {
let bitBuffer = new BitBuffer(buffer);
let maskFlag = bitBuffer.getBit(8),
opcode = bitBuffer.getBit(4, 4),
payloadLen = bitBuffer.getBit(9, 7);
console.log('maskFlag = ' + maskFlag);
console.log('opcode = ' + opcode);
console.log('payloadLen = ' + payloadLen);
});
打印如下：
maskFlag = 1 opcode = 1 payloadLen = 26
取掩码值单独实现一下，这个掩码是拆成4个数使用的，一个字节表示一个数，借助上面的getBit函数，代码如下：
getMaskingKey (offset) {
const BYTE_COUNT = 4;
let masks = [];
for (let i = 0; i < BYTE_COUNT; i++) {
masks.push(this.getBit(offset + i * 8, 8));
}
return masks;
}
这个例子的掩码值是从第16位开始，所以offset是16：
let maskKeys = bitBuffer.getMaskingKey(16);
console.log('maskKey = ' + maskKeys);
打印出来的maskKey为：
maskKeys = 76, 63, 100, 117
怎么用这个Mask Key进行异或呢，文档里面是这么规定的：
j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-j
也就是把Payload Data里面的第n，n + 1，n + 2，n + 3个字节内容分别与makKey数组的第0，1，2，3进行异或即可，所以这个实现也比较简单，如下代码所示：
getXorString (byteOffset, byteCount, maskingKeys) {
let text = '';
for (let i = 0; i < byteCount; i++) {
let j = i % 4;
// 通过异或得到原始的utf-8编码
let transformedByte = this.buffer.readUInt8(byteOffset + i)
^ maskingKeys[j];
// 把编码值转成对应的字符
text += String.fromCharCode(transformedByte);
}
return text;
}
异或操作之后就可以得到编码值，再借助String.fromCharCode就能得到对应的文本，如根据ASCII表，97就会被还原成字母’a’。
这个例子的payload data的偏移是第6个字节开始的，这里我们先直接写死：
let payloadLen = bitBuffer.getBit(9, 7),
maskKeys = bitBuffer.getMaskingKey(16);
let payloadText = bitBuffer.getXorString(48 / 8, payloadLen, maskKeys);
console.log('payloadText = ' + payloadText);
打印的文本内容为：
payloadText = hello, this is from client
到这里，就把接收的数据还原出来了。如果想要发送数据，就是把读取的过程逆一下，按照帧格式去拼一个符合规范的帧发送给对方，区别是服务端的帧数据是不需要Mask的，如果你Mask了，Chrome会报一个异常，说数据不需要Mask，拒绝解析接收到的数据。
我们再从Chrome源码看Websocket客户端的实现，来补充一些细节。
Chrome的websockets代码是在src/net/websockets，例如Chrome在握手的时候是怎么生成一个随机的sec-websocket-key？如下代码所示：
std::string GenerateHandshakeChallenge() {
std::string raw_challenge(websockets::kRawChallengeLength, '\0');
crypto::RandBytes(base::string_as_array(&raw_challenge),
raw_challenge.length());
std::string encoded_challenge;
base::Base64Encode(raw_challenge, &encoded_challenge);
return encoded_challenge;
}
它是用的一个crypto::RandBytes生成随机字节，而在检验sec-websocket-accept也是用的同样的计算方法：
std::string ComputeSecWebSocketAccept(const std::string& key) {
std::string accept;
std::string hash = base::SHA1HashString(key + websockets::kWebSocketGuid);
base::Base64Encode(hash, &accept);
return accept;
}
而在使用掩码计算的时候也是用的一样的方法：
inline void MaskWebSocketFramePayloadByBytes(
const WebSocketMaskingKey& masking_key,
size_t masking_key_offset,
char* const begin,
char* const end) {
for (char* masked = begin; masked != end; ++masked) {
*masked ^= masking_key.key[masking_key_offset++];
if (masking_key_offset == WebSocketFrameHeader::kMaskingKeyLength)
masking_key_offset = 0;
}
}
其它的还有deflate压缩、cookie、扩展extensions等，本文不再展开讨论。
另外还有一个问题，使用一个WebSocket就需要操持一个TCP连接，如果有1000个用户同时在线，那么服务端就得保持1000个TCP连接，而一个TCP连接通常需要占用一个独立的线程，而线程的开销是很大的，所以WebSocket对服务端的压力特别大？其实也不见得有那么大，因为Linux有一个epoll的服务模型，它是一个事件驱动机制的，能够让一个核支持并发的很多个连接。
最后一个问题，由于连接是一直操持的，如果连接双方有一方异常退出了，没有发送一个关闭连接的包通知对方，那么对方就会傻傻地操持着这个没用的连接，所以WebSocket又引入了一个ping/pong的消息帧，帧头里的opcode为0x9就表示是一个ping帧，0x10表示pong的响应帧。所以可以让客户端不断地ping，如每隔30秒就ping一次，服务收到了ping就知道当前客户端还活着，给一个pong的响应，如果服务端太久没收到ping了如1分钟，那么就认为这个客户端已经走了直接关闭连接。而客户端如果没收到pong响应那么就认为当前连接已经断了，需要重连。浏览器JS的API没有开放ping/pong，需要自已实现一个消息类型。
本篇主要讨论了WebSocket存在的意义，给浏览器开放一个socket的API，并进行标准化，除了浏览器，APP等也都可以按照这个标准实现，弥补了HTTP单向传输的缺点。还讨论了WebSocket报文帧的格式，以及怎么用Node.js读取这个报文帧，客户端会把它发送的内容进行掩码处理，服务端收到的也需要进行掩码还原。我们发现Chrome客户端的实现有很多地方是类似的。
怎么保证WebSocket传输的稳定性可能又是另外一个话题了，包括出错重连机制，跨中美地区的可能需要使用专线等。
Post Views: 8
来自：https://www.yinchengli.com/2018/05/27/chrome-websocket/
扫码二维码 获取免费视频学习资料
- 本文固定链接: http://phpxs.com/post/6012/
- 转载请注明：转载必须在正文中标注并保留原文链接
- 扫码： 扫上方二维码获取免费视频资料