WebSocket协议简介

一、WebSocket协议是什么

WebSocket是基于TCP的应用层协议，用于在C/S架构的应用中实现双向通信，它实现了浏览器与服务器全双工(full-duplex)通信，也就是允许服务器主动发送信息给客户端。

WebSocket 协议主要为了解决基于 HTTP/1.x 的 Web 应用无法实现服务端向客户端主动推送的问题, 为了兼容现有的设施, WebSocket 协议使用与 HTTP 协议相同的端口, 并使用 HTTP Upgrade 机制来进行 WebSocket 握手, 当握手完成之后, 通信双方便可以按照 WebSocket 协议的方式进行交互。

需要特别注意的是：虽然WebSocket协议在建立连接时会使用HTTP协议，但这并意味着WebSocket协议是基于HTTP协议实现的。

二、WebSocket与Http的区别

实际上，WebSocket协议与Http协议有着本质的区别：

1.通信方式不同

WebSocket是双向通信模式，客户端与服务器之间只有在握手阶段是使用HTTP协议的“请求-响应”模式交互，而一旦连接建立之后的通信则使用双向模式交互，不论是客户端还是服务端都可以随时将数据发送给对方；而HTTP协议则至始至终都采用“请求-响应”模式进行通信。也正因为如此，HTTP协议的通信效率没有WebSocket高。

2.协议格式不同

WebSocket与HTTP的协议格式是完全不同的，具体来讲：
（1）HTTP协议（参见：rfc2616）比较臃肿，而WebSocket协议比较轻量。
（2）对于HTTP协议来讲，一个数据包就是一条完整的消息；而WebSocket客户端与服务端通信的最小单位是帧（frame），由1个或多个帧组成一条完整的消息（message）。即：发送端将消息切割成多个帧，并发送给服务端；服务端接收消息帧，并将关联的帧重新组装成完整的消息。
WebSocket协议格式：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

HTTP请求消息格式：

Request-LineCRLF
general-headerCRLF
request-headerCRLF
entity-headerCRLF
CRLF
[ message-body ]

HTTP响应消息格式：

Status-LineCRLF
general-headerCRLF
response-headerCRLF
entity-headerCRLF
CRLF
[ message-body ]

虽然WebSocket和HTTP是不同应用协议，但rfc6455规定：“WebSocket设计为通过80和443端口工作，以及支持HTTP代理和中介”，从而使其与HTTP协议兼容。为了实现兼容性，WebSocket握手时使用HTTP Upgrade头从HTTP协议更改为WebSocket协议。

三、为什么要使用WebSocket

随着Web应用的发展，特别是动态网页的普及，越来越多的场景需要实现数据动态刷新。
在早期的时候，实现数据刷新的方式通常有如下3种：
1.客户端定时查询
客户端定时查询（如：每隔10秒钟查询一次）是最原始也是最简单的实现数据刷新的方法，服务端不用做任何改动，只需要在客户端添加一个定时器即可。但是这种方式的缺点也很明显：大量的定时请求都是无效的，因为服务端的数据并没有更新，相应地也导致了大量的带宽浪费。

2.长轮训机制
长轮训机制是对客户端定时查询的一种改进，即：客户端依旧保持定时发送请求给服务端，但是服务端并不立即响应，而是等到真正有数据更新的时候才发送给客户端。实际上，并不是当没有数据更新时服务端就永远都不响应客户端，而是需要在等待一个超时时间之后结束该次长轮训请求。相对于客户端定时查询方式而言，当数据更新频率不确定时长轮训机制能够很明显地减少请求数。但是，在数据更新比较频繁的场景下，长轮训方式的优势就没那么明显了。
在Web开发中使用得最为普遍的长轮训实现方案为Comet（Comet (web技术)），Tomcat和Jetty都有对应的实现支持，详见：WhatIsComet，Why Asynchronous Servlets。

3.HTTP Streaming
不论是长轮训机制还是传统的客户端定时查询方式，都需要客户端不断地发送请求以获取数据更新，而HTTP Streaming则试图改变这种方式，其实现机制为：客户端发送获取数据更新请求到服务端时，服务端将保持该请求的响应数据流一直打开，只要有数据更新就实时地发送给客户端。
虽然这个设想是非常美好的，但这带来了新的问题：
(1)HTTP Streaming的实现机制违背了HTTP协议本身的语义，使得客户端与服务端不再是“请求-响应”的交互方式，而是直接在二者建立起了一个单向的“通信管道”。
(2)在HTTP Streaming模式下，服务端只要得到数据更新就发送给客户端，那么就需要客户端与服务端协商如何区分每一个更新数据包的开始和结尾，否则就可能出现解析数据错误的情况。
(3)另外，处于客户端与服务端的网络中介（如：代理）可能会缓存响应数据流，这可能会导致客户端无法真正获取到服务端的更新数据，这实际上与HTTP Streaming的本意是相违背的。
鉴于上述原因，在实际应用中HTTP Streaming并没有真正流行起来，反之使用得最多的是长轮训机制。

显然，上述几种实现数据动态刷新的方式都是基于HTTP协议实现的，或多或少地存在这样那样的问题和缺陷；而WebSocket是一个全新的应用层协议，专门用于Web应用中需要实现动态刷新的场景。
相比起HTTP协议，WebSocket具备如下特点：

支持双向通信，实时性更强。
更好的二进制支持。
较少的控制开销：连接创建后，WebSockete客户端、服务端进行数据交换时，协议控制的数据包头部较小。
支持扩展。

四、websocket的用途场景

高即时性服务，比如聊天室的群聊，server顺序收到了张三，李四的消息，立即就推送给王五，不能让王五等半天。
Ajax也可以一秒一刷，让王五去问张三说话没，如果张三10分钟没说话，王五要去问600次。 用websocket 王五不用刷，等着就好了，服务器有了消息会自动给王五的。

1.websocket社交订阅
对社交类的应用的一个裨益之处就是能够即时的知道你的朋友正在做什么。虽然听起来有点可怕，但是我们都喜欢这样做。你不会想要在数分钟之后才能知道一个家庭成员在馅饼制作大赛获胜或者一个朋友订婚的消息。你是在线的，所以你的订阅的更新应该是实时的。

2.websocket多玩家游戏

网络正在迅速转变为游戏平台。在不使用插件（我指的是Flash）的情况下，网络开发者现在可以在浏览器中实现和体验高性能的游戏。无论你是在处理DOM元素、css动画，html5的canvas或者尝试使用WebGL，玩家之间的互动效率是至关重要的。我不想在我扣动扳机之后，我的对手却已经移动位置。

3.websocket协同编辑/编程

我们生活在分布式开发团队的时代。平时使用一个文档的副本就满足工作需求了，但是你最终需要有一个方式来合并所有的编辑副本。版本控制系统，比如Git能够帮助处理某些文件，但是当Git发现一个它不能解决的冲突时,你仍然需要去跟踪人们的修改历史。通过一个协同解决方案，比如WebSocket，我们能够工作在同一个文档，从而省去所有的合并版本。这样会很容易看出谁在编辑什么或者你在和谁同时在修改文档的同一部分。

用户打开文档编辑页面，与后端建立长连接。
后端将当前用户加入当前文档编辑用户列表。
前端监听用户对于文档内容的修改，每一次修改将整个修改内容发送给后端。
后端接收到信息，不做任何处理，直接将文本信息发送给文档编辑用户列表中其他的所有用户。
前端收到后端的文本信息直接覆盖掉当前文档内容。

4.websocket收集点击流数据

分析用户与你网站的互动是提升你的网站的关键。HTTP的开销让我们只能优先考虑和收集最重要的数据部分。然后，经过六个月的线下分析，我们意识到我们应该收集一个不同的判断标准——一个看起来不是那么重要但是现在却影响了一个关键的决定。与HTTP请求的开销方式相比，使用Websocket，你可以由客户端发送不受限制的数据。想要在除页面加载之外跟踪鼠标的移动？只需要通过WebSocket连接发送这些数据到服务器，并存储在你喜欢的NoSQL数据库中就可以了（MongoDB是适合记录这样的事件的）。现在你可以通过回放用户在页面的动作来清楚的知道发生了什么。

5.股票基金报价

金融界瞬息万变——几乎是每毫秒都在变化。我们人类的大脑不能持续以那样的速度处理那么多的数据，所以我们写了一些算法来帮我们处理这些事情。虽然你不一定是在处理高频的交易，但是，过时的信息也只能导致损失。当你有一个显示盘来跟踪你感兴趣的公司时，你肯定想要随时知道他们的价值，而不是10秒前的数据。使用WebSocket可以流式更新这些数据变化而不需要等待。

6.体育实况更新

现在我们开始讨论一个让人们激情澎湃的愚蠢的东西——体育。我不是运动爱好者，但是我知道运动迷们想要什么。当爱国者在打比赛的时候，我的妹夫将会沉浸于这场比赛中而不能自拔。那是一种疯狂痴迷的状态，完全发自内心的。我虽然不理解这个，但是我敬佩他们与运动之间的这种强烈的联系，所以，最后我能做的就是给他的体验中降低延迟。如果你在你的网站应用中包含了体育新闻，WebSocket能够助力你的用户获得实时的更新。

7.多媒体聊天

视频会议并不能代替和真人相见，但当你不能在同一个屋子里见到你谈话的对象时，视频会议是个不错的选择。尽管视频会议私有化做的“不错”，但其使用还是很繁琐。我可是开放式网络的粉丝，所以用WebSockets getUserMedia API和html5音视频元素明显是个不错的选择。WebRTC的出现顺理成章的成为我刚才概括的组合体，它看起来很有希望，但其缺乏目前浏览器的支持，所以就取消了它成为候选人的资格。

8.基于位置的应用

越来越多的开发者借用移动设备的GPS功能来实现他们基于位置的网络应用。如果你一直记录用户的位置(比如运行应用来记录运动轨迹)，你可以收集到更加细致化的数据。如果你想实时的更新网络数据仪表盘(可以说是一个监视运动员的教练)，HTTP协议显得有些笨拙。借用WebSocket TCP链接可以让数据飞起来。