websocket深入,tomcat,jetty服务器使用对比

转载整理自https://www.zhihu.com/question/20215561

http://www.open-open.com/lib/view/open1435905714122.html

http://www.ibm.com/developerworks/cn/java/j-lo-WebSocket/

http://www.open-open.com/lib/view/open1413011727155.html

一、WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）

首先HTTP有1.1和1.0之说，也就是所谓的keep-alive，把多个HTTP请求合并为一个，但是Websocket其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充可以通过这样一张图理解

<img src="https://pic1.zhimg.com/6651f2f811ec133b0e6d7e6d0e194b4c_b.jpg" data-rawwidth="374" data-rawheight="133" class="content_image" width="374">有交集，但是并不是全部。 有交集，但是并不是全部。
另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。
通俗来说，你可以用HTTP 协议传输非Html 数据，就是这样=。=
再简单来说， 层级不一样。

二、Websocket是什么样的协议，具体有什么优点
首先，Websocket是一个 持久化的协议，相对于HTTP这种 非持久的协议来说。
简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。
1) HTTP的生命周期通过Request来界定，也就是一个Request 一个Response，那么 在HTTP1.0 中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。
但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是 被动的，不能主动发起。

教练，你BB了这么多，跟Websocket有什么关系呢？
_(:з」∠)_好吧，我正准备说Websocket呢。。
首先Websocket是基于HTTP协议的，或者说 借用了HTTP的协议来完成一部分握手。
在握手阶段是一样的
-------以下涉及专业技术内容，不想看的可以跳过lol:，或者只看加黑内容--------
首先我们来看个典型的Websocket握手（借用Wikipedia的。。）

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的童鞋可能发现了，这段类似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下，不同的服务所需要的协议。简单理解： 今晚我要服务A，别搞错啦~
最后，Sec-WebSocket-Version 是告诉服务器所使用的Websocket Draft（协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦~大家都使用的一个东西~ 脱水： 服务员，我要的是13岁的噢→_→

然后服务器会返回下列东西，表示已经接受到请求， 成功建立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协议，而不是mozillasocket，lurnarsocket或者shitsocket。
然后，Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key。服务器： 好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。。
后面的，Sec-WebSocket-Protocol 则是表示最终使用的协议。

至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。
具体的协议就不在这阐述了。
------------------技术解析部分完毕------------------


<img src="https://pic4.zhimg.com/31ddf0cfbeecef21568d85ca60b5f1ff_b.jpg" data-rawwidth="53" data-rawheight="65" class="content_image" width="53"> 三、Websocket的作用
在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。
首先是 ajax轮询 ，ajax轮询 的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
客户端：啦啦啦，有没有新信息(Request)
服务端：没有（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：没有。。（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：你好烦啊，没有啊。。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：好啦好啦，有啦给你。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：。。。。。没。。。。没。。。没有（Response） ---- loop

long poll
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）
服务端：额。。 等待到有消息的时候。。来 给你（Response）
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点， 被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。

说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）
long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以ajax轮询 和long poll 都有可能发生这种情况。

客户端：啦啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）
客户端：。。。。好吧，啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）


然后服务端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我错了。。这又是梗。。）

--------------------------
言归正传，我们来说Websocket吧
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的'电话'。这两种都会导致'电话'的需求越来越高。
哦对了，忘记说了HTTP还是一个无状态协议。（感谢评论区的各位指出OAQ）
通俗的说就是，服务器因为每天要接待太多客户了，是个 健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。

所以在这种情况下出现了，Websocket出现了。
他解决了HTTP的这几个难题。
首先， 被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。
所以上面的情景可以做如下修改。
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）
服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）
客户端：麻烦你有信息的时候推送给我噢。。
服务端：ok，有的时候会告诉你的。
服务端：balabalabalabala
服务端：balabalabalabala
服务端：哈哈哈哈哈啊哈哈哈哈
服务端：笑死我了哈哈哈哈哈哈哈

就变成了这样，只需要经过 一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。
那么为什么他会解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即 HTTP协议在Nginx等服务器的解析下，然后再传送给相应的 Handler（PHP等）来处理。
简单地说，我们有一个非常快速的接 线员（Nginx），他负责把问题转交给相应的 客服（Handler）。
本身 接线员基本上速度是足够的，但是每次都卡在 客服（Handler）了，老有 客服处理速度太慢。，导致客服不够。
Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持 久连接，有信息的时候客服想办法通知接线员，然后 接线员在统一转交给客户。
这样就可以解决客服处理速度过慢的问题了。

同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要 重新传输identity info（鉴别信息），来告诉服务端你是谁。
虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的 处理时间，而且还会在网路传输中消耗 过多的流量/时间。
但是Websocket只需要 一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
同时由 客户主动询问，转换为 服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的 客服（Handler）了
--------------------
至于怎么在不支持Websocket的客户端上使用Websocket。。答案是： 不能
但是可以通过上面说的 long poll 和 ajax 轮询来 模拟出类似的效果

作者：董可人
链接：https://www.zhihu.com/question/20215561/answer/40250050
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁，它和 HTTP 有一些共性，是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求，但是对每个请求仍然要单独发 header；所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。它们建立的“长连接”都是伪.长连接，只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。

WebSocket 解决的第一个问题是，通过第一个 HTTP request 建立了 TCP 连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息。此外还有 multiplexing 功能，几个不同的 URI 可以复用同一个 WebSocket 连接。这些都是原来的 HTTP 不能做到的。

另外说一点技术细节，因为看到有人提问 WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket 真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。

比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。

而解决方案，WebSocket 的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（ RFC 6455 - The WebSocket Protocol）。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态。

作者：劳永超
链接：https://www.zhihu.com/question/20215561/answer/17884059
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

websocket的实现已经有朋友提到了基于HTTP来发起，我这里不讨论太多实现，而是主要回答一下题主补充的问题：“【【【【【【【【【【【【【【补充】】】】】】】】】】：：：：：
既然WebSocket和HTTP是两个协议 为什么要在HTML5才支持
又如果说HTML5 出来以后可以用WebSocket了 就说明WebSocket是本来就有点东西只是HTML4不支持而已 http4时代 如何使用WebSocket呢？？ 谢谢”

websocket是随着WWW的发展，应用场景越来越复杂而提出的，针对浏览器和web服务器之间双向持续通信而设计，而且优雅地兼容HTTP（我猜想：同时因为建立在HTTP上，也可以利用好HTTP原有的基础比如basic认证）。它和HTML5不是非得扯到一起，但是刚好是同时期，而且HTML5也刚好需要“socket”功能，因此顺理成章成为一部分。

而 websocket 的使用，更多的是“脚本”层面的事情，比如在javascript（不是非得javascript，但是javascript已经成为和浏览器交互的事实标准）中创建Websocket对象以便操作浏览器的websocket功能（这个功能便是浏览器根据HTML5草案实现出来的，参考草案的interface WebSocket部分定义），然后注册onopen/onmessage等回调接口，有数据或者状态变更之类的时机你就可以做相应的处理了。而这部分刚好在旧的标准没定义，浏览器也没有这样的功能，因此遵循HTML4编写的页面不会用到这些功能。

作者：长天之云
链接：https://www.zhihu.com/question/20215561/answer/14365823
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

Web 1 的时代人们访问 Web 页面是即停即走。Web 2 之后单个页面停留时间越来越长，页面功能越来越丰富——这时有了 RIA 的概念，改变了客户端的编程模型——更甚至许多实时应用根本不用离开页面，比如聊天、游戏应用。
客户端浏览器决定了客户端编程语言的能拥有的功能，以前如何做那些交互性很高的应用呢？
一些技术有 XHR，iframe, 实时性要求非常高的就只能用第三方插件，比如 Flash 或 Silverlight。
但 XHR 和 iframe 存在一些根本避免不了问题：1）每次交互就需要两个 HTTP 请求 2）即使单个 HTTP 请求也要传送很多字节（header 笨重）3）客户端不知道消息何时能够到达，只能轮询。服务器肯定会表示压力很大！
插件则需要额外安装，还有安全性问题和移动设备根本不能被支持的问题。
有了需要之后才有了解决方案—— WebSocket 就是这种灵丹妙药，看看主要特性：实时交互、服务器能够主动推送内容、只需要建立一次连接、快速（延迟小，每条消息可以小到两个字节）、开发者友好（接口简单，并是熟悉的事件模型）等等。
所以，HTML 4 选择权很小，是否要支持 WebSocket 依据需求和环境而定；而选择 HTML 5 的话，有了 socket 通信和图形编程的能力，能够开发出什么精彩应用只取决于你的想象力。

Tomcat：

       J2EE下面用的最多的容器应该就是tomcat了。说到tomcat对WebSocket的支持，不得不先提一下，目前的WebSocket协议已经经过了好几代的演变，不同浏览器对此协议的支持程度也不同，因此，如果作为服务器，最理想的是支持尽可能多的WebSocket协议版本。

tomcat8真正支持jsr-356（包含对websocket的支持）， tomcat7支持部分版本的websocket实现不兼容jsr-356。因此，能用tomcat8的话，还是尽量用。

 

代码实现相当简单，以下是一个列子，只需要tomcat8的基本库，不需要其他依赖。

    import java.io.IOException;    
    import javax.websocket.OnClose;    
    import javax.websocket.OnMessage;    
    import javax.websocket.OnOpen;    
    import javax.websocket.Session;    
    import javax.websocket.server.ServerEndpoint;    
      
      
    @ServerEndpoint("/websocket")    
    public class WebSocketTest {    
        
        @OnMessage    
        public void onMessage(String message, Session session) throws IOException,    
                InterruptedException {    
            // Print the client message for testing purposes    
            System.out.println("Received: " + message);    
            // Send the first message to the client    
            session.getBasicRemote().sendText("This is the first server message");    
            // Send 3 messages to the client every 5 seconds    
            int sentMessages = 0;    
            while (sentMessages < 3) {    
                Thread.sleep(5000);    
                session.getBasicRemote().sendText("This is an intermediate server message. Count: " + sentMessages);    
                sentMessages++;    
            }    
            // Send a final message to the client    
            session.getBasicRemote().sendText("This is the last server message");    
        }    
        
        @OnOpen    
        public void onOpen() {    
            System.out.println("Client connected");    
        }    
        
        @OnClose    
        public void onClose() {    
            System.out.println("Connection closed");    
        }    
    }    

Jetty：

       Jetty和Tomcat一样，也是一个Servlet的容器。如果说不同之处，那么最大的不同应该是Tomcat采用的是BIO处理方式，也就是说一个request会用一个线程去处理，即使是WebSocket这种长连接，也是会独立开一个线程。作为一个普通的Web服务器，tomcat可以轻松应对耗时比较短的Request/Response。但是如果换成是长连接的WebSocket，那麻烦就来了，对于上万用户的聊天和推送，总不能开上万个线程去处理吧。此时，Jetty的性能就体现出来了，Jetty采用的是NIO，一个线程可以处理多个WebSocket的长链接，如果你的需求是大量耗时比较长的request或者大量长连接，那么建议采用Jetty。

 

        Jetty对WebSocket的实现有点绕，Servlet不再是继承原来的HttpServlet，而是继承WebSocketServlet。此处要注意导入jetty-util.jar和jetty-websocket.jar两个包，否则可能会有class not found错误。

ReverseAjaxServlet.java:

    import java.io.IOException;  
    import java.util.Date;  
    import java.util.Random;  
       
    import javax.servlet.ServletException;  
    import javax.servlet.http.HttpServletRequest;  
    import javax.servlet.http.HttpServletResponse;  
       
    import org.codehaus.jettison.json.JSONArray;  
    import org.eclipse.jetty.websocket.WebSocket;  
    import org.eclipse.jetty.websocket.WebSocketServlet;  
       
    /** 
     * @author Mathieu Carbou (mathieu.carbou@gmail.com) 
     */  
    public final class ReverseAjaxServlet extends WebSocketServlet {  
       
        private final Endpoints endpoints = new Endpoints();  
        private final Random random = new Random();  
        private final Thread generator = new Thread("Event generator") {  
            @Override  
            public void run() {  
                while (!Thread.currentThread().isInterrupted()) {  
                    try {  
                        Thread.sleep(random.nextInt(5000));  
                        endpoints.broadcast(new JSONArray().put("At " + new Date()).toString());  
                    } catch (InterruptedException e) {  
                        Thread.currentThread().interrupt();  
                    }  
                }  
            }  
        };  
       
        @Override  
        public void init() throws ServletException {  
            super.init();  
            generator.start();  
        }  
       
        @Override  
        public void destroy() {  
            generator.interrupt();  
            super.destroy();  
        }  
           
        @Override  
        public WebSocket doWebSocketConnect(HttpServletRequest request, String protocol) {  
            return endpoints.newEndpoint();  
        }  
       
        @Override  
        protected void doGet(HttpServletRequest req, HttpServletResponse resp)  
                throws ServletException, IOException {  
            resp.getWriter().write("11111");  
        }  
    }  

Endpoints.java:

    package com.cn.test.chapter2.websocket;  
      
    import org.eclipse.jetty.websocket.WebSocket;  
      
    import java.util.Queue;  
    import java.util.concurrent.ConcurrentLinkedQueue;  
       
    /** 
     * @author Mathieu Carbou (mathieu.carbou@gmail.com) 
     */  
    final class Endpoints {  
        private final Queue<Endpoint> endpoints = new ConcurrentLinkedQueue<Endpoint>();  
       
        void broadcast(String data) {  
    //        for (Endpoint endpoint : endpoints) {  
    //            endpoint.onMessage(data);  
    //        }  
        }  
       
        void offer(Endpoint endpoint) {  
            endpoints.offer(endpoint);  
        }  
       
        void remove(Endpoint endpoint) {  
            endpoints.remove(endpoint);  
        }  
       
        public WebSocket newEndpoint() {  
            return new Endpoint(this);  
        }  
    }  

Endpoint.java

    import java.io.IOException;  
    import java.util.concurrent.ConcurrentLinkedQueue;  
       
      
      
      
    import org.codehaus.jettison.json.JSONArray;  
    import org.eclipse.jetty.websocket.WebSocket;  
       
    /** 
     * @author Mathieu Carbou (mathieu.carbou@gmail.com) 
     */  
    class Endpoint implements WebSocket.OnTextMessage  {  
       
        protected Connection _connection;  
           
        private Endpoints endpoints;  
           
        private static int clientCounter = 0;  
        private int clientId = clientCounter++;  
           
        public Endpoint(Endpoints endpoints) {  
            this.setEndpoints(endpoints);  
        }  
           
        @Override  
        public void onClose(int code, String message) {  
            System.out.println("Client disconnected");    
              
            this.endpoints.remove(this);  
        }  
       
        @Override  
        public void onOpen(Connection connection) {  
            System.out.println("Client connected");    
            _connection = connection;  
            try {  
                this._connection.sendMessage(new JSONArray().put("ClientID = " + clientId).toString());  
            } catch (IOException e) {  
                // TODO Auto-generated catch block  
                e.printStackTrace();  
            }  
            endpoints.offer(this);  
        }  
       
        @Override  
        public void onMessage(final String data) {  
            System.out.println("Received data: " + data);    
            this.endpoints.broadcast(data);  
        }  
       
        public Endpoints getEndpoints() {  
            return endpoints;  
        }  
       
        public void setEndpoints(Endpoints endpoints) {  
            this.endpoints = endpoints;  
        }  
    }  

 

 

辅助工具：

        在编写服务器最麻烦的是要写对应的客户端来测试，还好Chrome为我们解决了这个问题。下载Chrome插件WebSocket Clinet可以轻松地和服务器建立连接，发送消息到服务器。

来自：http://blog.csdn.net/lrenjun/article/details/39934823

WebSocket 前世今生

众所周知，Web 应用的交互过程通常是客户端通过浏览器发出一个请求，服务器端接收请求后进行处理并返回结果给客户端，客户端浏览器将信息呈现，这种机制对于信息变化不是特别频繁的应用尚可，但对于实时要求高、海量并发的应用来说显得捉襟见肘，尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是 Web 应用经常面临的问题，比如金融证券的实时信息，Web 导航应用中的地理位置获取，社交网络的实时消息推送等。

传统的请求-响应模式的 Web 开发在处理此类业务场景时，通常采用实时通讯方案，常见的是：

• 轮询，原理简单易懂，就是客户端通过一定的时间间隔以频繁请求的方式向服务器发送请求，来保持客户端和服务器端的数据同步。问题很明显，当客户端以固定频率向服务器端发送请求时，服务器端的数据可能并没有更新，带来很多无谓请求，浪费带宽，效率低下。
• 基于 Flash，AdobeFlash 通过自己的 Socket 实现完成数据交换，再利用 Flash 暴露出相应的接口为 JavaScript 调用，从而达到实时传输目的。此方式比轮询要高效，且因为 Flash 安装率高，应用场景比较广泛，但在移动互联网终端上 Flash 的支持并不好。IOS 系统中没有 Flash 的存在，在 Android 中虽然有 Flash 的支持，但实际的使用效果差强人意，且对移动设备的硬件配置要求较高。2012 年 Adobe 官方宣布不再支持 Android4.1+系统，宣告了 Flash 在移动终端上的死亡。

从上文可以看出，传统 Web 模式在处理高并发及实时性需求的时候，会遇到难以逾越的瓶颈，我们需要一种高效节能的双向通信机制来保证数据的实时传输。在此背景下，基于 HTML5 规范的、有 Web TCP 之称的 WebSocket 应运而生。

早期 HTML5 并没有形成业界统一的规范，各个浏览器和应用服务器厂商有着各异的类似实现，如 IBM 的 MQTT，Comet 开源框架等，直到 2014 年，HTML5 在 IBM、微软、Google 等巨头的推动和协作下终于尘埃落地，正式从草案落实为实际标准规范，各个应用服务器及浏览器厂商逐步开始统一，在 JavaEE7 中也实现了 WebSocket 协议，从而无论是客户端还是服务端的 WebSocket 都已完备，读者可以查阅HTML5 规范，熟悉新的 HTML 协议规范及 WebSocket 支持。

回页首

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

可以看到，客户端发起的 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 协议栈了解 WebSocket 客户端和服务端更详细的交互数据格式。

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

回页首

WebSocket 实现

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

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

WebSocket 服务端 API

WebSocket 服务端在各个主流应用服务器厂商中已基本获得符合 JEE JSR356 标准规范 API 的支持（详见JSR356 WebSocket 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，可以获得更快的响应时间，更好的用户体验。

回页首

WebSocket 案例分析

以下我们以一个真实的客户案例来分析说明 WebSocket 的优势及具体开发实现（为保护客户隐私，以下描述省去客户名，具体涉及业务细节的代码在文中不再累述）。

案例介绍

该客户为一个移动设备制造商，移动设备装载的是 Android/IOS 操作系统，设备分两类（以下简称 A，B 两类），A 类设备随时处于移动状态中，B 类设备为 A 类设备的管理控制设备，客户需要随时在 B 类设备中看到所属 A 类设备的地理位置信息及状态信息。如 A 类设备上线，离线的时候，B 类设备需要立即获得消息通知，A 类设备上报时，B 类设备也需要实时获得该上报 A 类设备的地理位置信息。

为降低跨平台的难度及实施工作量，客户考虑轻量级的 Web App 的方式屏蔽 Android/IOS 平台的差异性，A 类设备数量众多，且在工作状态下 A 类设备处于不定时的移动状态，而 B 类设备对 A 类设备状态变化的感知实时性要求很高（秒级）。

根据以上需求，A/B 类设备信息存放在后台数据库中，A/B 类设备的交互涉及 Web 客户端/服务器频繁和高并发的请求-相应，如果使用传统的 HTTP 请求-响应模式，B 类设备的 Web App 上需要对服务进行轮询，势必会对服务器带来大的负载压力，且当 A 类设备没有上线或者上报等活动事件时，B 类设备的轮询严重浪费网络资源。

解决方案

综上所述，项目采用 WebSocket 技术实现实时消息的通知及推送，每当 A 类设备/B 类设备上线登录成功即打开 WebSocket 的 HTTP 长连接，新的 A 类设备上线，位置变化，离线等状态变化通过 WebSocket 发送实时消息，WebSocket Server 端处理 A 类设备的实时消息，并向所从属的 B 类设备实时推送。

WebSocket 客户端使用 jQuery Mobile（jQuery Mobile 移动端开发在本文中不再详细描述，感兴趣的读者可以参考jQuery Mobile 简介)，使用原生 WebSocket API 实现与服务端交互。

服务端沿用客户已有的应用服务器 Tomcat 7.0.33 版本，使用 Apache 自定义 API 实现 WebSocket Server 端，为一个上线的 A 类设备生成一个 WebSocket 的 HTTP 长连接，每当 A 类设备有上线，位置更新，离线等事件的时候，客户端发送文本消息，服务端识别并处理后，向所属 B 类设备发送实时消息，B 类设备客户端接收消息后，识别到 A 类设备的相应事件，完成对应的 A 类设备位置刷新以及其他业务操作。

其涉及的 A 类设备，B 类设备及后台服务器交互时序图如下：

图 3：A/B 类设备 WebSocket 交互图

A/B 类设备的 WebSocket 客户端封装在 websocket.js 的 JavaScript 代码中，与 jQuery MobileApp 一同打包为移动端 apk/ipa 安装包；WebSocket 服务端实现主要为 WebSocketDeviceServlet.java, WebSocketDeviceInbound.java，WebSocketDeviceInboundPool.java 几个类。下文我们一一介绍其具体代码实现。

代码实现

在下文中我们把本案例中的主要代码实现做解释说明，读者可以下载完整的代码清单做详细了解。

WebSocketDeviceServlet 类

A 类设备或者 B 类设备发起 WebSocket 长连接后，服务端接受请求的是 WebSocketDeviceServlet 类，跟传统 HttpServlet 不同的是，WebSocketDeviceServlet 类实现 createWebSocketInbound 方法，类似 SocketServer 的 accept 方法，新生产的 WebSocketInbound 实例对应客户端 HTTP 长连接，处理与客户端交互功能。

WebSocketDeviceServlet 服务端代码示例如下：

清单 6.WebSocketDeviceServlet.java 代码示例

public class WebSocketDeviceServlet extends org.apache.catalina.websocket.WebSocketServlet {

private static final long serialVersionUID = 1L;

 @Override
 protected StreamInbound createWebSocketInbound(String subProtocol,HttpServletRequest request) {
 
 WebSocketDeviceInbound newClientConn = new WebSocketDeviceInbound(request);
 WebSocketDeviceInboundPool.addMessageInbound(newClientConn);
 return newClientConn;
 
 }

}

代码解释：

WebSocketServlet 是 WebSocket 协议的后台监听进程，和传统 HTTP 请求一样，WebSocketServlet 类似 Spring/Struct 中的 Servlet 监听进程，只不过通过客户端 ws 的前缀指定了其监听的协议为 WebSocket。

WebSocketDeviceInboundPool 实现了类似 JDBC 数据库连接池的客户端 WebSocket 连接池功能，并统一处理 WebSocket 服务端对单个客户端/多个客户端（同组 A 类设备）的消息推送，详见 WebSocketDeviceInboundPool 代码类解释。

WebSocketDeviceInboundl 类

WebSocketDeviceInbound 类为每个 A 类和 B 类设备验证登录后，客户端建立的 HTTP 长连接的对应后台服务类，类似 Socket 编程中的 SocketServer accept 后的 Socket 进程，在 WebSocketInbound 中接收客户端发送的实时位置信息等消息，并向客户端（B 类设备）发送下属 A 类设备实时位置信息及位置分析结果数据，输入流和输出流都是 WebSocket 协议定制的。WsOutbound 负责输出结果，StreamInbound 和 WsInputStream 负责接收数据：

清单 7.WebSocketDeviceInbound.java 类代码示例

public class WebSocketDeviceInbound extends MessageInbound {
private final HttpServletRequest request;
private DeviceAccount connectedDevice;

public DeviceAccount getConnectedDevice() {
return connectedDevice;
}


public void setConnectedDevice(DeviceAccount connectedDevice) {
this.connectedDevice = connectedDevice;
}


public HttpServletRequest getRequest() {
return request;
}


public WebSocketDeviceInbound(HttpServletRequest request) {
this.request = request;
DeviceAccount connectedDa = (DeviceAccount)request.getSession(true).getAttribute("connectedDevice");
if(connectedDa==null)
{
String deviceId = request.getParameter("id");
DeviceAccountDao deviceDao = new DeviceAccountDao();
connectedDa = deviceDao.getDaById(Integer.parseInt(deviceId));
}
this.setConnectedDevice(connectedDa);
}

	
@Override
protected void onOpen(WsOutbound outbound) {
 /

}

@Override
protected void onClose(int status) {
WebSocketDeviceInboundPool.removeMessageInbound(this);

}

@Override
protected void onBinaryMessage(ByteBuffer message) throws IOException {
throw new UnsupportedOperationException("Binary message not supported.");
}

@Override
protected void onTextMessage(CharBuffer message) throws IOException {
WebSocketDeviceInboundPool.processTextMessage(this, message.toString());

}


public void sendMessage(BaseEvent event)
{
String eventStr = JSON.toJSONString(event);
try {
this.getWsOutbound().writeTextMessage(CharBuffer.wrap(eventStr));
//…以下代码省略
} catch (IOException e) {
e.printStackTrace();
}
}
}

代码解释：

connectedDevice 是当前连接的 A/B 类客户端设备类实例，在这里做为成员变量以便后续处理交互。

sendMessage 函数向客户端发送数据，使用 Websocket WsOutbound 输出流向客户端推送数据，数据格式统一为 JSON。

onTextMessage 函数为客户端发送消息到服务器时触发事件，调用 WebSocketDeviceInboundPool 的 processTextMessage 统一处理 A 类设备的登入，更新位置，离线等消息。

onClose 函数触发关闭事件，在连接池中移除连接。

WebSocketDeviceInbound 构造函数为客户端建立连接后，WebSocketServlet 的 createWebSocketInbound 函数触发，查询 A 类/B 类设备在后台数据库的详细数据并实例化 connectedDevice 做为 WebSocketDeviceInbound 的成员变量，WebSocketServlet 类此时将新的 WebSocketInbound 实例加入自定义的 WebSocketDeviceInboundPool 连接池中，以便统一处理 A/B 设备组员关系及位置分布信息计算等业务逻辑。

WebSocketDeviceInboundPool 类

WebSocketInboundPool 类: 由于需要处理大量 A 类 B 类设备的实时消息，服务端会同时存在大量 HTTP 长连接，为统一管理和有效利用 HTTP 长连接资源，项目中使用了简单的 HashMap 实现内存连接池机制，每次设备登入新建的 WebSocketInbound 都放入 WebSocketInbound 实例的连接池中，当设备登出时，从连接池中 remove 对应的 WebSocketInbound 实例。

此外，WebSocketInboundPool 类还承担 WebSocket 客户端处理 A 类和 B 类设备间消息传递的作用，在客户端发送 A 类设备登入、登出及位置更新消息的时候，服务端 WebSocketInboundPool 进行位置分布信息的计算，并将计算完的结果向同时在线的 B 类设备推送。

清单 8.WebSocketDeviceInboundPool.java 代码示例

public class WebSocketDeviceInboundPool {

private static final ArrayList<WebSocketDeviceInbound> connections =
new ArrayList<WebSocketDeviceInbound>();

public static void addMessageInbound(WebSocketDeviceInbound inbound){
//添加连接
DeviceAccount da = inbound.getConnectedDevice();
System.out.println("新上线设备 : " + da.getDeviceNm());
connections.add(inbound);
}

public static ArrayList<DeviceAccount> getOnlineDevices(){
ArrayList<DeviceAccount> onlineDevices = new ArrayList<DeviceAccount>();
for(WebSocketDeviceInbound webClient:connections)
{
onlineDevices.add(webClient.getConnectedDevice());
}
return onlineDevices;
}

public static WebSocketDeviceInbound getGroupBDevices(String group){
WebSocketDeviceInbound retWebClient =null;
for(WebSocketDeviceInbound webClient:connections)
{
if(webClient.getConnectedDevice().getDeviceGroup().equals(group)&&
webClient.getConnectedDevice().getType().equals("B")){
retWebClient = webClient;
}
}
return retWebClient;
}
public static void removeMessageInbound(WebSocketDeviceInbound inbound){
//移除连接
System.out.println("设备离线 : " + inbound.getConnectedDevice());
connections.remove(inbound);
}

public static void processTextMessage(WebSocketDeviceInbound inbound,String message){


BaseEvent receiveEvent = (BaseEvent)JSON.parseObject(message.toString(),BaseEvent.class);
DBEventHandleImpl dbEventHandle = new DBEventHandleImpl();
dbEventHandle.setReceiveEvent(receiveEvent);
dbEventHandle.HandleEvent();
if(receiveEvent.getEventType()==EventConst.EVENT_MATCHMATIC_RESULT||
receiveEvent.getEventType()==EventConst.EVENT_GROUP_DEVICES_RESULT||
receiveEvent.getEventType()==EventConst.EVENT_A_REPAIRE){
String clientDeviceGroup = ((ArrayList<DeviceAccount>)
receiveEvent.getEventObjs()).get(0).getDeviceGroup();
WebSocketDeviceInbound bClient = getGroupBDevices(clientDeviceGroup);
if(bClient!=null){
sendMessageToSingleClient(bClient,dbEventHandle.getReceiveEvent());
}
}
}
}
public static void sendMessageToAllDevices(BaseEvent event){
try {
for (WebSocketDeviceInbound webClient : connections) {
webClient.sendMessage(event);
}
} catch (Exception e) {
e.printStackTrace();
}
}
public static void sendMessageToSingleClient(WebSocketDeviceInbound webClient,BaseEvent event){

try {
webClient.sendMessage(event);

}
catch (Exception e) {
e.printStackTrace();
}
}
}

代码解释：

addMessageInbound 函数向连接池中添加客户端建立好的连接。

getOnlineDevices 函数获取所有的连线的 A/B 类设备。

removeMessageInbound 函数实现 A 类设备或者 B 类设备离线退出（服务端收到客户端关闭 WebSocket 连接事件，触发 WebSocketInbound 中的 onClose 方法），从连接池中删除连接设备客户端的连接实例。

processTextMessage 完成处理客户端消息，这里使用了消息处理的机制，包括解码客户端消息，根据消息构造 Event 事件，通过 EventHandle 多线程处理，处理完后向客户端返回，可以向该组 B 设备推送消息，也可以向发送消息的客户端推送消息。

sendMessageToAllDevices 函数实现发送数据给所有在线 A/B 类设备客户端。sendMessageToSingleClient 函数实现向某一 A/B 类设备客户端发送数据。

websocket.js 客户端代码

客户端代码 websocket.js，客户端使用标准 HTML5 定义的 WebSocket API，从而保证支持 IE9+，Chrome，FireFox 等多种浏览器，并结合 jQueryJS 库 API 处理 JSON 数据的处理及发送。

清单 9：客户端 WebSocket.js 脚本示例

var websocket=window.WebSocket || window.MozWebSocket; 
var isConnected = false;

function doOpen(){
 isConnected = true;
if(deviceType=='B'){
 mapArea='mapB';
 doLoginB(mapArea);
 }
 else{
 mapArea='mapA';
 doLoginA(mapArea);
 }

}

function doClose(){
showDiagMsg("infoField","已经断开连接", "infoDialog");
isConnected = false;
}

function doError() {
showDiagMsg("infoField","连接异常!", "infoDialog");
isConnected = false;

}

function doMessage(message){
var event = $.parseJSON(message.data);
doReciveEvent(event);
}

function doSend(message) {
if (websocket != null) {
websocket.send(JSON.stringify(message));
} else {
showDiagMsg("infoField","您已经掉线，无法与服务器通信!", "infoDialog");
}
}

//初始话 WebSocket
function initWebSocket(wcUrl) {
if (window.WebSocket) {
websocket = new WebSocket(encodeURI(wcUrl));
websocket.onopen = doOpen;
websocket.onerror = doError;
websocket.onclose = doClose;
websocket.onmessage = doMessage;
}
else{
showDiagMsg("infoField","您的设备不支持 webSocket!", "infoDialog");

}
};

function doReciveEvent(event){
//设备不存在，客户端断开连接
if(event.eventType==101){
showDiagMsg("infoField","设备不存在或设备号密码错!", "infoDialog");
websocket.close();
}
//返回组设备及计算目标位置信息，更新地图
else if(event.eventType==104||event.eventType==103){
clearGMapOverlays(mapB); 
 $.each(event.eventObjs,function(idx,item){
 var deviceNm = item.deviceNm;
 //google api
// var deviceLocale = new google.maps.LatLng(item.lag,item.lat);
//baidu api
 var deviceLocale = new BMap.Point(item.lng,item.lat);
 var newMarker;
 if(item.status=='target'){
 newMarker = addMarkToMap(mapB,deviceLocale,deviceNm,true);
 //…以下代码省略
 }
 else{
 newMarker = addMarkToMap(mapB,deviceLocale,deviceNm);
 } 
 markArray.push(newMarker);
 });
 showDiagMsg("infoField","有新报修设备或设备离线, 地图已更新！", "infoDialog");
}

}

代码解释：

doOpen 回调函数处理打开 WebSocket，A 类设备或者 B 类设备连接上 WebSocket 服务端后，将初始化地图并显示默认位置，然后向服务端发送设备登入的消息。

doReciveEvent 函数处理关闭 WebSocket，A 类/B 类设备离线（退出移动终端上的应用）时，服务端关闭 HTTP 长连接，客户端 WebSocket 对象执行 onclose 回调句柄。

initWebSocket 初始化 WebSocket，连接 WebSocket 服务端，并设置处理回调句柄，如果浏览器版本过低而不支持 HTML5，提示客户设备不支持 WebSocket。

doSend 函数处理客户端向服务端发送消息，注意 message 是 JSON OBJ 对象，通过 JSON 标准 API 格式化字符串。

doMessage 函数处理 WebSocket 服务端返回的消息，后台返回的 message 为 JSON 字符串，通过 jQuery 的 parseJSON API 格式化为 JSON Object 以便客户端处理 doReciveEvent 函数时客户端收到服务端返回消息的具体处理，由于涉及大量业务逻辑在此不再赘述。

回页首

结束语

以上简要介绍了 WebSocket 的由来，原理机制以及服务端/客户端实现，并以实际客户案例指导并讲解了如何使用 WebSocket 解决实时响应及服务端消息推送方面的问题。本文适用于熟悉 HTML 协议规范和 J2EE Web 编程的读者，旨在帮助读者快速熟悉 HTML5 WebSocket 的原理和开发应用。文中的服务端及客户端项目代码可供下载，修改后可用于用户基于 WebSocket 的 HTTP 长连接的实际生产环境中。

使用四种框架分别实现1百万websocket常连接的服务器

参见：http://www.open-open.com/lib/view/open1435905714122.html