WebSocket基础

本文详细介绍了WebSocket协议,这是一种实现实时双向通信的技术。与传统的AJAX轮询和LongPoll相比,WebSocket更加高效,适用于聊天应用、多人游戏等场景。文章还提供了WebSocket在Tomcat服务器端和浏览器客户端的具体实现示例。
摘要由CSDN通过智能技术生成

什么是WebSocket

WebSocket是Web客户端和服务端进行异步全双工通信的协议,可以用来创建高性能实时的Web应用。WebSocket通信协议于2011年被IETF定为标准RFC 6455,WebSocketAPI被W3C定为标准。

为什么要用WebSocket

Web通信的传统实现方式主要有,
AJAX轮询:浏览器每隔一定时间就发一次请求,询问服务器是否有新信息。
Long Poll:也是采用轮询的方式,不过采取的是阻塞模型,也就是说,客户端发起连接后,如果没消息,就一直不返回response给客户端。直到有消息才返回,返回完之后,客户端再次建立连接,周而复始。

这两种都非常消耗资源,在处理高并发及实时性需求的时候,会遇到瓶颈,我们需要一种高效节能的双向通信机制来保证数据的实时传输。在此背景下,基于HTML5规范的、有Web TCP 之称的WebSocket应运而生。

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

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

客户端和服务端交互流程

客户端和服务端进行WebSocket交互的方式也可以理解为“HTTP握手 + TCP数据传输”的方式:

(1) 浏览器(支持Websocket的浏览器)像HTTP一样,发起一个请求,然后等待服务端的响应;
(2) 服务器返回握手响应,告诉浏览器请将后续的数据按照WebSocket制定的数据格式传过来;
(3) 浏览器和服务器的Socket连接不中断,此时这个连接和HTTP不同的是它是双工的了;
(4) 浏览器和服务器有任何需要传递的数据的时候使用这个长连接进行数据传递。

WebSockets适用场景

聊天应用
多人游戏
股票交易和金融应用
文档合作编辑
社交应用

WebSocket实现

WebSocket的实现分为客户端和服务端两部分,客户端(通常为浏览器)发出 WebSocket 连接请求,服务端响应,实现类似 TCP 握手的动作,从而在浏览器客户端和 WebSocket 服务端之间形成一条 HTTP 长连接快速通道。两者之间后续进行直接的数据互相传送,不再需要发起连接和相应。
服务端实现:WebSocket服务端在各个主流应用服务器厂商中已基本获得符合 JEE JSR356 标准规范 API 的支持。如Tomcat 7.0.5+,Jetty 7.0+,WebLogic 12c等。
客户端实现:主流的浏览器(包括 PC 和移动终端)现已都支持标准的 HTML5 的 WebSocket API。如Chrome version 4+、Firefox version 5+、    IE version 10+等。

Tomcat7.0.5 版本的服务端示例代码:
JSR356 的 WebSocket 规范使用 javax.websocket.*的 API,可以将一个普通 Java 对象(POJO)使用 @ServerEndpoint 注释作为 WebSocket 服务器的端点,代码示例如下:

@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) {
    //以下代码省略...
    }
}

客户端示例代码:

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客户端服务端实例源码 WebSocket ws实例 HTML5 用java实现的服务端 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 支持。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值