WebSocket学习

因为自己项目中一直使用的是WebSocket，我对WebSocket的知识只是有个大概的了解，今天通过《图解Http》来总结下下WebSocket的知识。

1. WebSocket出现前Http的发展

WebSocket是Http发展时，为了弥补Http自身的缺点，而研究出来的一种产物。

1.1 Ajax和Comet

Http的瓶颈有：

• 一条连接上只可发送一个请求
• 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
• 请求/响应首部未经压缩就发送。首部信息越多延迟越大。
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多
• 可任意选择数据压缩格式。非强制压缩发送。

为了突破这些瓶颈，出现了一些技术。
例如：

• Ajax
  是一种有效利用 JavaScript 和 DOM的操作，以达到局部 Web 页面替换加载的异步通信手段。
  缺点是：利用Ajax实时地从服务器获取内容，有可能会导致大量请求差生。
• Comet
  一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。
  也就是说，基于原本的Http，服务器在接收到请求后，会将响应至于挂起状态，当服务器内容有了更新，就会通过该响应返回给客户。
  缺点是：为了保留响应，一次连接的持续时间也边长了。期间，为了维持连接会消耗更多的资源。

但是Ajax和Comet并没有解决Http本身的疼点。

1.2 SPDY

在 TCP/IP的应用层与运输层之间通过新加一层会话层，加入SPDY，使用SPDY后，Http协议额外获得以下的功能：

• 多路复用流
  通过单一的Tcp连接，可以无限制处理多个Http请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
• 赋予请求优先级
  SPDY不仅可以无限地并发处理请求，还可以给请求逐个分配优先级顺序，这样主要是为了在发送多个请求时，解决因带宽低而导致响应慢的问题。
• 压缩Http首部
  压缩Http请求和响应的首部，这样通信产生的数据包数量和发送的字节数就更少了。
• 推送
  支持服务器主动向客户端推送数据。这样，服务器可以直接发送数据，而不必等待客户端的请求。
• 服务器提示功能
  服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免不必要的请求。

上面的功能可以发现，SPDY在一定程度上消除了Http瓶颈的技术。但是SPDY也有它自身的缺点：

• SPDY基本上只是将单个域名（IP地址）的通信进行多路复用，所以，一个Web网站上使用多个域名下的资源，改善效果就会搜到限制。
• SPDY必须使用TLS协议，所以这会导致建立连接的时间变长。
• SPDY在实际使用的效果不是很好。

知道Http2.0的人，其实就能理解Http2.0很大程度的借鉴了SPDY的技术，所以有人把SPDY看成是Http2.0的前身，也是可以理解的。

在Http2.0出现之前，通过使用 Ajax、Comet，就必须要使用Http，如果使用Http，就无法彻底解决瓶颈问题，这是出现了新的一种技术，就是WebSocket，它正是为了解决这些问题而实现的一套新协议以及API。

2. WebSocket的技术与功能

通过上面的介绍，我们知道WebSocket 不是Http，它就是一套独立的Api。但是在使用中，还是要靠Http来建立通信。

那这里会有一个疑问：为什么Ajax/Comet是基于Http的，所以它们本质上所以Http，但是WebSocket却不是呢？
答案是：

• Ajax/Comet发送请求、响应本质都是在Http协议上完成的
• 而 WebSocket使用到Http的地方只有一个，那就是 连接的时候，在连接完之后，Http就没用了，使用的都是WebSocekt的东西。所以WebSocket本质上不是Http。

2.1 全双工通信设计

Http1.1有这么些疼点：

• 可先后发送多个http请求,不用等待回复,但是回复必须按顺序一个一个回复.
• 客户端只能做请求，服务端只能做响应

这说明Http1.1是 半双工通信，半双工就相当于是“一条道的双向马路”，在一个时间任意方向只能过一辆车。
（Http2.0则实现了全双工）

WebSocket在客户端与服务器之间使用全双工通信标准。全双工通信允许数据在两个方向上同时传输，它在能力上相当于两个单工通信方式的结合。WebSocekt建立了“多道的双向马路”，使得客户端和服务端都实现了请求和接收消息的功能。
所以数据之间的传输相较于Http，效率上是快挺多的。

所以WebSocket也解决了Ajax和Comet的一些缺陷。

2.2 WebSocket协议

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML 或图片等任意格式的数据。

由于是建立在 HTTP 基础上的协议，因此连接的发起方仍是客户端，而一旦确立 WebSocket 通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。 这也是全双工通信带来的效益。

所以，它可以很自由的实现下面几点：

• 推送功能
  服务器可以向客户端推送数据，而无需等待客户端的请求
• 减少通信量
  只要建立起WebSocket，就希望一直保持连接状态。（这里的“希望”指的是，我们在开发中一般都会为WebSocket实现长连接，所以WebSocket协议的优势是建立在长连接之上）。
  和Http相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应的减少了。

2.3 WebSocket握手

我们知道，在Http建立连接后，WebSocekt的通道也就建立了，但是这个 通道的建立并不是随着Http建立而建立。

WebSocket有它自己的 “握手”，在Http建立后，还要再进行一次WebSocekt的握手，才算是真正建立WebSocket通道。
相比于TCP3次握手，WebSocket就是“2次握手”：

（1）握手—请求
为了实现WebSoccket通信，还需要用到Http的 Upgrade首部字段，告知服务器通信协议发送改变，以达到握手的目的：

上面的首部中：

• Connection
  代表着要使用 Upgrade的协议，即WebSocket
• Sec-WebSocket-Key
  记录着握手过程中必不可少的键值
• Sec-WebSocket-Protocol
  记录使用的子协议
• Sec-WebSocket-Version
  记录WebSocket版本

（2）握手—响应
对于该请求，服务端返回状态码为 101 Switching Protocols的响应：

响应的首部中：

• Connection
  使用该Upgrade协议，即WebSocket
• Sec-WebSocket-Accept
  是由握手请求中的 Sec-WebSocket-Key 的字段值生成的。

2.4 传输用的数据

在通过WebSocket握手成功，建立好连接后，就不再使用Http的数据帧，而是采用WebSocket独立的数据帧，进行传输。

3. WebSocket的缺点

相比于Http1.1，WebSocekt解决它的一些疼点，所以它的优势还是挺多的。
但是它也有一些缺点：

• 最大的缺点：服务端需要维护一套WebSocket的组件，由于WebSocket是需要长连接的，这导致对服务端的技术要求高。
  所以对于服务端来说，WebSocket的组件可能会很复杂，耦合性会很高。
  这也是因为Http发展的久用的人多，有很多可复用的组件，而WebSocket只用于特定的场景，所以研究出来的组件比较少。
• 既然后端要做WebSocket的长连接， 那么前端也要做，虽然前端难度没有后端那么大，也需要前端人员有一定的数据驱动能力。
• 有些Web浏览器不支持WebSocket，比如较低版本的IE不兼容。

在如今的开发中，如果只是为了实现推送和长连接功能（它也只能做这两个功能），WebSocket未免太过复杂和庞大。
所以新出现了一种技术 MQTT，它是一种基于 发布/订阅者模型的消息协议，相比于WebSocket，它轻量、简单、开发且容易实现，最重要的是，它在硬件性能底下的远程设备，以及网络状态糟糕的情况下也能使信息的传输更加靠谱，比如物联网、M2M(机器与机器)。在智能家居、医疗设备等领域已经广泛使用了。