基于Websocket呼叫中心应用.docVIP

基于Websocket呼叫中心应用 　　摘要：众所周知，传统的B/S架构在实现服务端与客户端实时通信方面，常采用客户端“拉”与服务器“推”等技术，这些技术都存在诸如实时性差、效率低等问题。该文通过将当今流行的WebSocket与传统的B/S实时通信技术进行比较，旨在说明采用WebSocket在B/S架构中实现实时通信的众多优点，并以呼叫中心为例简要阐述WebSocket在实际项目中的应用 关键词：WebSocket；呼叫中心；应用 中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2017）08-0074-04 1传统“Web实时”解决方案 由于HTTP协议为无状态的交互协议，客户端与服务端的交互通过一问一答来实现数据的传输。因此，对于需要实现实时业务的Web系统，传统的实时解决方案主要分为：客户端“拉”与服务端“推”两种方式，我们将之统称为反向Ajax技术（Reverse Ajax） 顾名思义，这两种Web的实时解决方案都是借助于客户端周期性反复发起的Ajax请求来反向推送服务端需要推送的实时交互信息以达到实时传输的目的。下面我们就来详细分析一下这两种方案的优缺点 1.1客户端“拉”（Client Puff） 客户端“拉”指由客户端周期性反复发起HTTP请求，将实时性数据“拉”至客户端。因此，客户端“拉”的关键在于客户端，服务端还是在被动的响应客户端的请求。这种实时性交互方案的实现方式主要分为：页面定时刷新和Ajax定时轮询两种方案 1.1.1页面定时刷新 页面定时刷新，通俗地讲就是页面周期性加载功能，它通过HTML页面自带的定时刷新功能实现消息的“实时”获取。具体实现方式为在HTML的标签中加入实现定时刷新 具体时序如?D1所示 从图中我们不难看出浏览器每隔2秒发起一次刷新，每次刷新加载的都是该HTML文件以及HTML文件中所包含的全部数据与资源文件。早期我们就是通过这种浏览器机械的刷新操作达到数据的“实时”传输。这种最为原始的消息实时交互方式有其优势，如代码逻辑简单，仅仅通过HTML内置标签就可以实现定时加载，浏览器兼容性好，但也存在不足，如界面频繁闪烁，数据的频繁传输与加载加重了服务器的负担 1.1.2 Ajax定时轮询 Ajax定时轮询的提出主要是为了解决页面定时刷新造成的页面与资源传输占用大量带宽的问题而采取的一种折中方案。Ajax（Asynchronous Javascript And XML）异步交互通信技术也称页面局部刷新技术，通过它同样可以实现数据的实时交互 具体实现方式为：在页面中启动一个js定时器，让其周期性地发起Ajax请求，以从服务器上获取数据。当Ajax请求发起的周期时间设置得越短，实时性就越高 优点：相对于页面定时刷新技术来说，Ajox定时轮询减少了不必要的资源传输与加载；由于是异步发起Web请求，因此对用户来说是“透明”的；页面无频繁闪烁，用户体验有所改善；浏览器兼容性好 缺点：服务器接入压力依旧很大。试想，如果有100个用户需要获取服务器实时数据，以每2秒为一个周期发起请求，那么服务器在10秒内需要处理500个请求，负载过大 通过以上的分析，我们不难看出，客户端“拉”实现的实时交互都是基于定时器不断轮询实现宏观上的“实时交互”，而从微观角度上分析并没有达到真正意义上的实时，并且这种实现方式会给服务端造成一定的压力，轻者存在访问延迟，重者直接造成服务端拒绝服务。因此，对于呼叫中心这种需要高效地整合电话资源并将电话线路的实时状态反应在网页上的实时性要求较高的系统，客户端“拉”的技术显然不符合要求。因为“拉”的实效性是由周期时间差所决定的，事件的随机性与周期的固定性肯定存在时间差。当一个客户呼入或挂机事件发生时，如果当前服务端没有收到客户端的周期请求，则系统将无法及时地通知到相关的坐席 1.2服务端“推”（Server Push） 鉴于客户端“拉”的实时性不理想且会对服务器造成负载压力，客户端“拉”的方案列入备选。说起服务端“推”技术，业界也有两种不同的实现方式：一是基于Http协议的长连接，二是基于客户端第三方组件的网络套接字技术。其中第二种实现方式由于需要客户端在有安装第三方组件的情况下才可以使用，因此这种方式不作为我们本文讨论的重点。如果读者感兴趣可以自行了解aflax socket与Java applet 本文重点讨论的服务端“推”技术是基于Http协议的长连接，它与客户端“拉”技术的共通之处在于都是基于浏览器发起的Http请求进行实时消息交互，不同之处在于该连接为长连接而非客户端“拉”技术的短连接。它的具体实现方式可分为基于Iframe流和基于Comet流的实现方式 1.