Websocket原理简介

WebSocket（RFC6455）是HTML5开始提供的一种在单个TCP连接上进行全双工通讯的协议。

 

---

Websocket与HTTP

WebSocket是HTML5出的东西（一个新协议），跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充。他们之间只是存在交集而已：

HTTP是不支持持久连接的（长连接，循环连接的不算），所谓的 keep-alive，也就是把多个HTTP请求合并为一个。

另外：

Html5是指的一系列新规范，新技术。

Http协议本身Html本身没有直接关系，你可以用HTTP协议传输非Html数据，简单来说，层级不一样。

 

---

Websocket协议

Websocket是一个持久化的协议，相对的HTTP是非持久的协议。

HTTP的生命周期通过 Request 来界定：

• 在 HTTP1.0 中一个 Request 一个 Response，这次HTTP请求就结束了。

• 在HTTP1.1中进行了改进（keep-alive）：在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住Request与Response一一对应，也就是说一个request只能有一个response，而且这个response也是被动的，不能主动发起。

 

Websocket借用了HTTP的协议来完成一部分握手。典型的 Websocket 握手：

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

Origin: http://example.com

这段类似HTTP协议的握手请求中，多了几个东西：

Upgrade: websocket

Connection: Upgrade

这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理（不是那个HTTP）。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

• Sec-WebSocket-Key 是一个Base64 encode 的值，是浏览器随机生成的，用于验证服务端是不是Websocket助理。

• Sec_WebSocket-Protocol是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。

• Sec-WebSocket-Version 是告诉服务器所使用的协议版本

 

服务器返回下列东西，表示接受到请求， 成功建立Websocket啦！

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Sec-WebSocket-Protocol: chat

这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦

Upgrade: websocket

Connection: Upgrade

依然是固定的，告诉客户端即将升级的是 Websocket 协议，而非其他。

• Sec-WebSocket-Accept 是经过服务器确认，并且加密过后的 Sec-WebSocket-Key，用于证明服务器自身。加密方法为：

    mask  = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";  

    accept = base64( sha1( key + mask ) );

• Sec-WebSocket-Protocol 则是表示最终使用的协议。

至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。

 

---

Websocket的作用

在讲Websocket之前，先看下long poll 和 ajax轮询 的原理。

 

ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。场景再现：

客户端：啦啦啦，有没有新信息(Request)

服务端：没有（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：没有。。（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：你好烦啊，没有啊。。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：好啦好啦，有啦给你。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：。。。。。没。。。。没。。。没有（Response）

--loop--

 

long poll 其实原理跟ajax轮询差不多，都是采用轮询的方式，不过采取的是阻塞模型，也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。场景再现：

客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）

服务端：额。。 等待到有消息的时候。。来 给你（Response）

客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）

--loop--

 

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性（服务端不能主动联系客户端，只能有客户端发起）。不管怎么样，上面这两种都是非常消耗资源的。

• ajax轮询 需要服务器有很快的处理速度和资源。（速度）

• long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）

所以 ajax轮询 和 long poll 都有可能发生这种情况。

客户端：啦啦啦啦，有新信息么？

服务端：月线正忙，请稍后再试（503 Server Unavailable）

客户端：。。。。好吧，啦啦啦，有新信息么？

服务端：月线正忙，请稍后再试（503 Server Unavailable）

 

Websocket的出现，解决了HTTP的这几个难题。

• 被动性：当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。只需要经过一次HTTP请求，就可以做到源源不断的信息传送了（回调，或事件通知）。

• 同步延迟：有消息时，能立即通知客户端；

• 资源消耗：Websocket只需要一次HTTP握手（传统HTTP需要不断的建立，关闭HTTP协议，同时由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁）。

 

所以上面的情景就变成了这样。

客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）

服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）

客户端：麻烦你有信息的时候推送给我噢。。

服务端：ok，有的时候会告诉你的。

服务端：balabalabalabala

服务端：balabalabalabala

服务端：哈哈哈哈哈啊哈哈哈哈

服务端：笑死我了哈哈哈哈哈哈哈