WebSocket介绍和Socket的区别

　　WebSocket介绍与原理

　　WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。一开始的握手需要借助HTTP请求完成。

　　——百度百科

　　目的：即时通讯，替代轮询

　　应用场景：网站上的即时通讯是很常见的，比如网页的QQ，聊天系统等。按照以往的技术能力通常是采用轮询、Comet技术解决。

　　HTTP协议是非持久化的，单向的网络协议，在建立连接后只允许浏览器向服务器发出请求后，服务器才能返回相应的数据。当需要即时通讯时，通过轮询在特定的时间间隔（如1秒），由浏览器向服务器发送Request请求，然后将最新的数据返回给浏览器。这样的方法最明显的缺点就是需要不断的发送请求，而且通常HTTP request的Header是非常长的，为了传输一个很小的数据需要付出巨大的代价，是很不合算的，占用了很多的宽带。

　　缺点：会导致过多不必要的请求，浪费流量和服务器资源，每一次请求、应答，都浪费了一定流量在相同的头部信息上

　　然而WebSocket的出现可以弥补这一缺点。在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。

　　原理：WebSocket同HTTP一样也是应用层的协议，但是它是一种双向通信协议，是建立在TCP之上的。

　　连接过程——握手过程

　　1.浏览器、服务器建立TCP连接，三次握手。这是通信的基础，传输控制层，若失败后续都不执行。

　　2.TCP连接成功后，浏览器通过HTTP协议向服务器传送WebSocket支持的版本号等信息。（开始前的HTTP握手）

　　3.服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。

　　4.当收到了连接成功的消息后，通过TCP通道进行传输通信。

　　WebSocket与HTTP的关系

　　相同点

　　都是一样基于TCP的，都是可靠性传输协议。

　　都是应用层协议。

　　不同点

　　WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。HTTP是单向的。

　　WebSocket是需要握手进行建立连接的。

　　联系

　　WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。

　　WebSocket与Socket的关系

　　Socket其实并不是一个协议，而是为了方便使用TCP或UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。WebSocket则是一个典型的应用层协议。Socket是传输控制层协议，WebSocket是应用层协议。

　　HTML5与WebSocket的关系

　　WebSocket API是HTML5标准的一部分，但这并不代表WebSocket一定要用在HTML中，或者只能在基于浏览器的应用程序中使用。实际上，许多语言、框架和服务器都提供了WebSocket支持，例如：

　　*基于C的libwebsocket.org

　　*基于Node.js的Socket.io

　　*基于Python的ws4py

　　*基于C++的WebSocket++

　　*Apache对WebSocket的支持：Apache Module mod_proxy_wstunnel

　　*Nginx对WebSockets的支持：NGINX as a WebSockets Proxy、NGINX Announces Support for WebSocket Protocol、WebSocket proxying

　　*lighttpd对WebSocket的支持：mod_websocket

　　WebSocket机制

　　WebSocket是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，它建立在TCP之上，同HTTP一样通过TCP来传输数据，但是它和HTTP最大不同是：

　　WebSocket是一种双向通信协议，在建立连接后，WebSocket服务器和Browser/Client Agent都能主动的向对方发送或接收数据，就像Socket一样；WebSocket需要类似TCP的客户端和服务器端通过握手连接，连接成功后才能相互通信。

　　非WebSocket模式传统HTTP客户端与服务器的交互如下图所示：

　　图1.传统HTTP请求响应客户端服务器交互图

　　使用WebSocket模式客户端与服务器的交互如下图：

　　图2.WebSocket请求响应客户端服务器交互图

　　上图对比可以看出，相对于传统HTTP每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket是类似Socket的TCP长连接的通讯模式，一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

　　我们再通过客户端和服务端交互的报文看一下WebSocket通讯与传统HTTP的不同：

　　在客户端，new WebSocket实例化一个新的WebSocket客户端对象，连接类似ws://yourdomain:port/path的服务端WebSocket URL，WebSocket客户端对象会自动解析并识别为WebSocket请求，从而连接服务端端口，执行双方握手过程，客户端发送数据格式类似：

　　清单1.WebSocket客户端连接报文

　　GET/webfin/websocket/HTTP/1.1

　　Host:localhost

　　Upgrade:websocket

　　Connection:Upgrade

　　Sec-WebSocket-Key:xqBt3ImNzJbYqRINxEFlkg==

　　Origin:

　　http://localhost

　　:8080

　　Sec-WebSocket-Version:13

　　http://localhost

　　:8080

　　Sec-WebSocket-Version:13

　　可以看到，客户端发起的WebSocket连接报文类似传统HTTP报文，”Upgrade：websocket”参数值表明这是WebSocket类型请求，“Sec-WebSocket-Key”是WebSocket客户端发送的一个base64编码的密文，要求服务端必须返回一个对应加密的“Sec-WebSocket-Accept”应答，否则客户端会抛出“Error during WebSocket handshake”错误，并关闭连接。

　　服务端收到报文后返回的数据格式类似：

　　清单2.WebSocket服务端响应报文

　　HTTP/1.1 101 Switching Protocols

　　Upgrade:websocket

　　Connection:Upgrade

　　Sec-WebSocket-Accept:K7DJLdLooIwIG/MOpvWFB3y3FE8=

　　“Sec-WebSocket-Accept”的值是服务端采用与客户端一致的密钥计算出来后返回客户端的,“HTTP/1.1 101 Switching Protocols”表示服务端接受WebSocket协议的客户端连接，经过这样的请求-响应处理后，客户端服务端的WebSocket连接握手成功,后续就可以进行TCP通讯了。

　　在开发方面，WebSocket API也十分简单，我们只需要实例化WebSocket，创建连接，然后服务端和客户端就可以相互发送和响应消息，在下文WebSocket实现及案例分析部分，可以看到详细的WebSocket API及代码实现。

　　WebSocket实现

　　如上文所述，WebSocket的实现分为客户端和服务端两部分，客户端（通常为浏览器）发出WebSocket连接请求，服务端响应，实现类似TCP握手的动作，从而在浏览器客户端和WebSocket服务端之间形成一条HTTP长连接快速通道。两者之间后续进行直接的数据互相传送，不再需要发起连接和相应。

　　以下简要描述WebSocket服务端API及客户端API。

　　WebSocket服务端API

　　WebSocket服务端在各个主流应用服务器厂商中已基本获得符合JEE JSR356标准规范API的支持，以下列举了部分常见的商用及开源应用服务器对WebSocket Server端的支持情况：

　　表1.WebSocket服务端支持

　　厂商应用服务器备注

　　IBM WebSphere WebSphere 8.0以上版本支持，7.X之前版本结合MQTT支持类似的HTTP长连接

　　甲骨文WebLogic WebLogic 12c支持，11g及10g版本通过HTTP Publish支持类似的HTTP长连接

　　微软IIS IIS 7.0+支持

　　Apache Tomcat Tomcat 7.0.5＋支持，7.0.2X及7.0.3X通过自定义API支持

　　Jetty Jetty 7.0＋支持

　　以下我们使用Tomcat7.0.5版本的服务端示例代码说明WebSocket服务端的实现：

　　JSR356的WebSocket规范使用javax.websocket.*的API，可以将一个普通Java对象（POJO）使用 ServerEndpoint注释作为WebSocket服务器的端点，代码示例如下：

　　清单3.WebSocket服务端API示例

　　 ServerEndpoint("/echo")

　　public class EchoEndpoint{

　　 OnOpen

　　public void onOpen(Session session)throws IOException{

　　//以下代码省略...

　　}

　　 OnMessage

　　public String onMessage(String message){

　　//以下代码省略...

　　}

　　 Message(maxMessageSize=6)

　　public void receiveMessage(String s){

　　//以下代码省略...

　　}

　　 OnError

　　public void onError(Throwable t){

　　//以下代码省略...

　　}

　　 OnClose

　　public void onClose(Session session,CloseReason reason){

　　//以下代码省略...

　　}

　　}

　　代码解释：

　　上文的简洁代码即建立了一个WebSocket的服务端， ServerEndpoint("/echo")的annotation注释端点表示将WebSocket服务端运行在ws://[Server端IP或域名]:[Server端口]/websockets/echo的访问端点，客户端浏览器已经可以对WebSocket客户端API发起HTTP长连接了。

　　使用ServerEndpoint注释的类必须有一个公共的无参数构造函数， onMessage注解的Java方法用于接收传入的WebSocket信息，这个信息可以是文本格式，也可以是二进制格式。

　　OnOpen在这个端点一个新的连接建立时被调用。参数提供了连接的另一端的更多细节。Session表明两个WebSocket端点对话连接的另一端，可以理解为类似HTTPSession的概念。

　　OnClose在连接被终止时调用。参数closeReason可封装更多细节，如为什么一个WebSocket连接关闭。

　　更高级的定制如 Message注释，MaxMessageSize属性可以被用来定义消息字节最大限制，在示例程序中，如果超过6个字节的信息被接收，就报告错误和连接关闭。

　　注意：早期不同应用服务器支持的WebSocket方式不尽相同，即使同一厂商，不同版本也有细微差别，如Tomcat服务器7.0.5以上的版本都是标准JSR356规范实现，而7.0.2x/7.0.3X的版本使用自定义API（WebSocketServlet和StreamInbound，前者是一个容器，用来初始化WebSocket环境；后者是用来具体处理WebSocket请求和响应，详见案例分析部分），且Tomcat7.0.3x与7.0.2x的createWebSocketInbound方法的定义不同，增加了一个HttpServletRequest参数，使得可以从request参数中获取更多WebSocket客户端的信息，如下代码所示：

　　清单4.Tomcat7.0.3X版本WebSocket API

　　public class EchoServlet extends WebSocketServlet{

　　 Override

　　protected StreamInbound createWebSocketInbound(String subProtocol,

　　HttpServletRequest request){

　　//以下代码省略....

　　return new MessageInbound(){

　　//以下代码省略....

　　}

　　protected void onBinaryMessage(ByteBuffer buffer)

　　throws IOException{

　　//以下代码省略...

　　}

　　protected void onTextMessage(CharBuffer buffer)throws IOException{

　　getWsOutbound().writeTextMessage(buffer);

　　//以下代码省略...

　　}

　　};

　　}

　　}

　　因此选择WebSocket的Server端重点需要选择其版本，通常情况下，更新的版本对WebSocket的支持是标准JSR规范API，但也要考虑开发易用性及老版本程序移植性等方面的问题，如下文所述的客户案例，就是因为客户要求统一应用服务器版本所以使用的Tomcat 7.0.3X版本的WebSocketServlet实现，而不是JSR356的 ServerEndpoint注释端点。

　　WebSocket客户端API

　　对于WebSocket客户端，主流的浏览器（包括PC和移动终端）现已都支持标准的HTML5的WebSocket API，这意味着客户端的WebSocket JavaScirpt脚本具备良好的一致性和跨平台特性，以下列举了常见的浏览器厂商对WebSocket的支持情况：

　　表2.WebSocket客户端支持

　　浏览器支持情况

　　Chrome Chrome version 4+支持

　　Firefox Firefox version 5+支持

　　IE IE version 10+支持

　　Safari IOS 5+支持

　　Android Brower Android 4.5+支持

　　客户端WebSocket API基本上已经在各个主流浏览器厂商中实现了统一，因此使用标准HTML5定义的WebSocket客户端的JavaScript API即可，当然也可以使用业界满足WebSocket标准规范的开源框架，如Socket.io。

　　以下以一段代码示例说明WebSocket的客户端实现：

　　清单5.WebSocket客户端API示例

　　var ws=new WebSocket(“ws://echo.websocket.org”);

　　ws.onopen=function(){ws.send(“Test!”);};

　　ws.onmessage=function(evt){console.log(evt.data);ws.close();};

　　ws.onclose=function(evt){console.log(“WebSocketClosed!”);};

　　ws.onerror=function(evt){console.log(“WebSocketError!”);};

　　第一行代码是在申请一个WebSocket对象，参数是需要连接的服务器端的地址，同HTTP协议开头一样，WebSocket协议的URL使用ws://开头，另外安全的WebSocket协议使用wss://开头。

　　第二行到第五行为WebSocket对象注册消息的处理函数，WebSocket对象一共支持四个消息onopen,onmessage,onclose和onerror，有了这4个事件，我们就可以很容易很轻松的驾驭WebSocket。

　　当Browser和WebSocketServer连接成功后，会触发onopen消息；如果连接失败，发送、接收数据失败或者处理数据出现错误，browser会触发onerror消息；当Browser接收到WebSocketServer发送过来的数据时，就会触发onmessage消息，参数evt中包含Server传输过来的数据；当Browser接收到WebSocketServer端发送的关闭连接请求时，就会触发onclose消息。我们可以看出所有的操作都是采用异步回调的方式触发，这样不会阻塞UI，可以获得更快的响应时间，更好的用户体验。