Android中使用WebSocket实现群聊和消息推送功能(不使用WebView)
作者：wlfcolin
字体：[ ] 类型：转载 时间：
WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。本文给大家介绍Android中使用WebSocket实现群聊和消息推送功能(不使用WebView)，需要的朋友参考下
WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。WebSocket是Web2.0时代的新产物，用于弥补HTTP协议的某些不足，不过他们之间真实的关系是兄弟关系，都是对socket的进一步封装，其目前最直观的表现就是服务器推送和聊天功能。更多知识参考：如何理解 TCP/IP, SPDY, WebSocket 三者之间的关系？
今天的重点是讲如何在Android中脱离WebView使用WebSocket，而不是在Web浏览器使用，如果是在Web浏览器中使用，网上已经太多教程、框架和demo，没必要讲。
到目前为止我个人认为安卓端比较好用的WebSocketClient有：autobahn、AndroidAsync、Java-WebSocket。好不好用其实需要看实际需求而定，此处我选择Java-WebSocket。
一、Android客户端的创建（使用Java-WebSocket库）：
　　　1、其实只需要掌握一个类，WebSocketClient即可
　　　2、指定IP/域名和端口连接服务器，当服务器端有通知时会回调onMessage方法
　　　3、然后调用connect方法进行连接
　　 4、连接后就可以发送消息了，发送消息也很简单，除了支持String的发送还支持byte发送，好了，客户端就这么愉快的写完了（详细代码见后面打包的demo）。　
二、服务端的创建：
　　　　1-1、Java Application服务端创建（使用Java-WebSocket库），其实也很简单，就继承一个类WebSocketServer：　　　　　　
　　　　1-2、然后在main方法中开启服务端，现在就可以用Android客户端来连接进行聊天、接收推送了，实在是太简单了。
　　　　2-1、Java Web（tomcat）服务端创建，这里不使用Java-WebSocket库，直接使用Java API javax.websocket包中的WebSocket相关类（注意Java API只实现了标准的RFC 6455（JSR256），如果你非要选择其它早期草案则需要用Java-WebSocket来实现，在Java-WebSocket中连接协议“Draft_17”就是标准的RFC 6455（JSR256），另外要使用Java API javax.websocket包中的WebSocket相关类要求JDK7及以上,Tomcat 7.0.49及以上）：　　
　　　　2-2、然后启动tomcat就可以愉快的用Android客户端来连接进行聊天、接收推送了。
　　三、相关截图：
　　1-1、Java后台：
　　1-2、Java后台对应的Android客户端
　　2-1、Java Web后台：
　　2-2、Java Web后台对应的Android客户端
　　2-3、html前端（浏览器）：
以上通过图文并茂的方式给大家介绍了Android中使用WebSocket实现群聊和消息推送功能(不使用WebView) ，希望对大家有所帮助！
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具如何全面掌控session？且看WebSocket跨站劫持 -
| 关注黑客与极客
如何全面掌控session？且看WebSocket跨站劫持
共172734人围观
，发现 26 个不明物体
WebSockets是一个能够给单TCP连接提供全双工信道的HTML5特性。它的持续性连接功能，使得构建B/S模式的实时应用成为可能。Websockets常常用在那些带有聊天功能的WEB应用上。
下面的图片就非常贴切地阐释了一个APT攻击用到的websockets：
FreeBuf小科普：
同源策略（Same&origin&policy）：同源是指，域名，协议，端口相同，即浏览器会检查同一浏览器的不同选项卡中，来源相同的脚本才能跨选项卡执行。
Origin字段：浏览器在发送POST请求的时候可能会加上一个Origin字段，这个Origin字段主要是用来标识出最初请求是从哪里发起的。如果浏览器不能确定源在哪里，那么在发送的请求里面Origin字段的值就为空。
IronWASP：某开源WEB测试平台，用户可以自定义安全扫描，并且可以自己用python/ruby来定义插件系统。相关介绍见：/tools/32948.html&
ZAP(Zed&Attack&Proxy)：是一款集成各种工具的渗透测试框架，可以发现在WEB应用程序中的漏洞，相关介绍见：/tools/5427.html
WebSocket的安全评估
最近，我们对一个拥有复杂菜单选项和功能的WEB应用做了安全评估。该应用中大部分操作都用到了web-sockets，这意味着其大多数行为都不会记录到http代理日志上。
首先，我们打开主页后，网站会加载一个带有JS脚本和CSS文件的静态网页。此后，整个通信交互会转为Websockets模式，浏览器和服务端之间会建立websocket连接，从而加载网站里所有可见的HTML资源。点击链接或者提交Form表单时，浏览器会向服务端发送一些WebSocket消息。服务器处理了这些消息后，会通过WebSocket进行反馈，而后客户端浏览器会展示新的HTML内容。
这时当websocket消息在进行交互时，通信数量是非常巨大的。每隔一秒它们之间会有心跳探测包的交互。然而现有的工具达不到我的要求，我不得不给IronWASP添加了一个Websocket消息分析装置和一个WebSocket客户端，这样它才能识别Websocket从而尝试fuzz其漏洞。你可以在在了解下相关知识。
在测试这个应用时，我发现它存在WebSocket跨站劫持（Cross-Site WebSocket Hijacking）漏洞（由首创）。当然，我会在给大家介绍测试方法之前，解释下这个漏洞的影响。在测试相关Websockets应用之前，我们需要先做下准备。
WebSocket跨站劫持漏洞实验准备
大家应该明白，同源策略（SOP）不会通过浏览器在websockets上强制执行（同一浏览器下，受SSL保护的页面，不会让非SSL的WebSocket通过），我们测试的应用采用了http cookie作为session认证，WebSocket通过浏览器发送的消息不会有Session ID或是随机参数。
这样一来，如果某用户登录了带有漏洞的WEB应用，然后在同一浏览器还打开了（攻击者的网站），可以尝试通过该漏洞应用与应用的服务端建立一个WebSocket连接，然后通过浏览器发送一个带有效的认证Session ID的请求包。于是，这个由攻击者网站建立的WebSocket连接会和应用本身有相同的权限。
由于整个应用都是以websockets为基础运行的，劫持了WebSocket就相当于劫持了用户的session。所以这个漏洞在本质上和存储型跨站脚本漏洞是一样的。
如果你认为这就很糟了，那当你听到某些情况下WebSocket跨站脚本，甚至可以在用户系统上实现远程代码执行的时候，会不会更惊讶呢？事见的案例。
测试之前，你首先要做的就是确认该应用是否存在WebSockets。幸运的是，做这个非常简单，你只需要知道以下三点:
1.WebSocket的URL连接一般是以ws://或者wss://开头的。
2.需要检测建立连接的Origin头，该网页可能是通过Origin字段建立的WebSocket链接。
3.浏览器和服务端之间发送的消息中，我们可以从中检查出普通WebSocket连接的特征。
下面这张图会给你展示：如何通过IronWASP日志得到Origin字段的值和WebSocket的URL值。
一旦你得到这些信息，你可以使用一些特殊方法，对跨站WebSocket劫持漏洞进行检测。我在这里例举三个简单的例子：
使用代理软件（如Burpsuite）:
这里必须提到的是，burpsuite可以捕获和记录WebSockets的消息。而ZAP和IronWASP是我所知道的，可以重放websocket请求的软件。
在burpsuite里，我们不能重放websockets消息，但我们还是可以在有限条件下，检测WebSocket握手包是否成功。为了进行测试，我们需要分析websocket的升级请求包：它们会通过http或者https发送，因此可以被重放。
以下截图为burpsuite重放器（Repeat选项卡）的记录，其显示了websocket连接的有效请求和应答情况：
为了测试这个漏洞，我们需要发送另一个带有重制后的Origin头的请求包。如果我们回应包里有“101 Web Socket Protocol Handshake”的标志，这就表示WebSocket已经建立成功了。
如果连接没有建立成功，那就意味着该应用不存在这个漏洞，因为它会拒绝外部的WebSocket连接。建立成功后，我们就可以开始下一步测试，看看该应用是否有WebSocket跨站劫持漏洞。这里需要说明一下：即使已经建立连接，也需要其如Origin的正常连接一般，确认得到服务端对WebSocket消息的应答之后，才能证明该应用存在漏洞。这是因为开发者可能会同时启用Origin检测与连接权限认证。因此我们的实验中也许会出下面这种情况：建立的连接可以一直保持，但拥有外部来源的Origins不会通过认证。
ZAP可以重放WebSocket消息，但据我了解，它并不能更改Origin头。下面介绍的方法可以给你科普下，如何通过CSWSH（WebSocket跨站劫持）来获得更多的东西。
使用WebSocket跨站劫持的在线测试工具
打开需要测试的WEB应用登入其中，然后在同一浏览器中开一个新选项卡，访问??http://ironwasp.org/cswsh.html（模拟的黑客网站），输入该WebSocket的URL地址，然后点击网页上的Connect按钮。一旦建立连接，你就可以通过这个页面向WebSocket的服务器发送消息。我们需要通过重放有效session发送过的消息，然后查看服务器的回应包。??
如果服务端的回应与前面有效session发送的正常包相同，那就说明该应用可能存在WebSocket跨站劫持漏洞。
使用IronWASP
IronWASP可以做到更多，即使是最基础的检测也能提供自动化脚本检查。
使用IronWASP的WebSocket客户端
以上测试Origin的方法的使用的服务端是http://ironwasp.org，如果你想要更加灵活地设置Origin值，你可以使用IronWASP的客户端功能。它允许你自定义Origin值来测试WebSocket连接。
在以下环境下可能会用到客户端功能：
1.应用允许来自开放的Origin的WebSocket连接
2.应用允许来自localhost和内网IP的Origin字段值
这种做法是为了方便开发者和应用的内部测试。通过使用IronWASP的客户端，你可以尝试内网IP或者localhost作为Origin是否能够生效。如果可以的话，那没准儿你可以耍一点小手段，在真实环境下利用这个漏洞。比如，如果某个应用允许http:/127.0.0.1:8080作为Origin字段，那我们就可以这样做：若受害者正好有个在本地8080端口运行的WEB应用，而且其存在跨站脚本漏洞。如果满足这些条件，黑客可以先在该WEB应用上进行跨站攻击，然后再向目标应用服务端建立WebSocket连接：
使用IronWASP的WebSocket API进行自动化检测
如果你需要利用localhost或者内网IP进行测试Origin头，使用客户端脚本进行自动化检测会让你的行动更加轻松。IronWASP允许你使用Python或者Ruby进行实现自定义脚本编写。
下面这个脚本可以单独检测Origin头里填充的内网IP地址，测试服务端对此是否认可：
import&clr
clr.AddReference(&WebsocketClient.exe&)
from&WebsocketClient&import&*
def&check_conn(origin):
&&&&print&&Testing&origin&-&&&+&origin
&&&&ws&=&SyncWebsockClient()
&&&&ws.Connect(&ws:///ws&,&origin,&&SessionID=KSDI2923EWE9DJSDS01212&)
&&&&ws.Send(&first&message&to&send&)
&&&&msg&=&ws.Read()
&&&&ws.Close()
&&&&if&msg&==&&message&that&is&part&of&valid&session&:
&&&&&&print&&Connection&successful!!&
&&&&&&return&True
&&&&&&return&False
def&check_nw():
&&for&nws&in&[&192.168.0.0/16&,&&172.16.0.0/12&,&&10.0.0.0/8&]:
&&&&for&ip&in&Tools.NwToIp(nws):
&&&&&&if&check_conn(&http://&&+&ip):
&&&&&&&&break
check_nw()
[参考来源，由FreeBuf小编dawner翻译，转载请注明来自]
245篇文章等级：9级
黎明已经过去，黑暗就在眼前！
必须您当前尚未登录。
必须（保密）
黎明已经过去，黑暗就在眼前！
分享每日精选文章Posts - 348,
Articles - 0,
Comments - 868
-正确的时间经历正确的事情
09:54 by 轩脉刃, ... 阅读,
这个是一次组内分享，关于websocket的协议和应用的。文章在分享之前就写好了，整理下放出来。
对应的PPT地址是：
从推送技术开始说
一篇文章10 Years of Push Technology, Comet, and WebSockets（//push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/）非常详细的说明清楚了从年推送技术的更新。2000年之前为第一波Push技术，使用的概念叫Webcasting。大致思想就是用户来服务端注册一个或者多个通道channel，然后服务端确定给某些个channel或某个channel发送消息。年最火的词叫comet，比如有Polling（这个是最普通的轮询），Long Polling（hold住HTTP的response端，当有消息的时候才返回），至于HTTP发起是在不同的哪些地方，Ajax，Flash，Iframe，然后就有各自不同的叫法和名词。但是不管什么技术，都限制于浏览器，因为浏览器只能发起HTTP请求。但是推送最好的一种方法当然是保持Socket长连接，浏览器如何能发起TCP连接呢？HTML5的Websocket技术就解决了这个问题。
websocket概述
websocket的版本发展：
draft-hixie-00
draft-hixie-76
draft-hybi-00
draft-hybi-17
所以有的地方会出现hixie，hybi的字样，纯粹是为了满足之前的版本。好消息是从2011年12月份开始，websocket的RFC正式版出来了。
客户端现状
从客户端来讲，大部分浏览器支持的是hybi-13版本，比如我使用的chrome v24，firefox v16。相信各家浏览器都很快能出现支持RFC版本的浏览器了。网上有很多文章说&支持websocket的浏览器&，这个说法其实是不对的，至少是不完整的。比如Chrome从草案开始就已经支持websocket了，你拿一个支持hixie76版本的chrome调用实现了RFC 6455的服务端，那是怎么样也对不上的。所以说&支持websocket的浏览器&还应该多带一句，支持什么版本。
浏览器来说还分为手机浏览器和PC浏览器。手机浏览器特别是android上的浏览器版本支持websocket的比PC上少很多（这可能和大家几乎不会去定期更新手机浏览器有关）。网上对那些版本浏览器支持那些版本的websocket有好多文章进行统计了。但是由于浏览器种类繁多，版本之多，记住这些版本，不如在定义需求的时候明确我需要支持哪些浏览器的哪些版本，然后写一个简单例子试一下更为准确。
服务端现状
下面是服务端。服务端对websocket的语言开发已经是没有问题了。 wiki上列出了各种服务端语言开发websocket的第三方包了。可以直接拿来用，也可以根据协议自己开发个websocket包，比如。甚至于像apache，nginx（1.3.13）这些现成的web服务器产品也都渐渐支持websocket了（nginx现在只是支持nginx代理）。
socket.io这个包是node上用的最多的一个第三方包。它其实并不仅仅是websocket。官方的faq
也说明清楚了为什么它不直接叫&websocket&包。socket.io的js包可以给客户端使用，也可以给服务端使用，客户端使用socket.io能很简单建立websocket连接，但是上，支持websocket的浏览器是不需要使用socket.io来建立websocket连接的。在服务端，使用socket.io并不是只能创建websocket服务器，就是说socket.io要建立的服务是&socket服务&而不仅仅是&websocket服务&。
websocket的原理
websocket是一种协议，本质上和http，tcp一样。协议是用来说明数据是如何传输的。它的url前缀是ws:// 或者wss://，后者是加密的websocket。它的url诸如这样：ws://10.16.15.64:3201/
客户端和服务端进行websocket交互的方式也有人理解为&HTTP握手+TCP数据传输&的方式。
HTTP握手+TCP数据传输
握手和传输的整个流程是这样的：
浏览器（支持Websocket的浏览器）像HTTP一样，发起一个请求，然后等待服务端的响应
服务器返回握手响应，告诉浏览器请将后续的数据按照websocket制定的数据格式传过来
浏览器和服务器的socket连接不中断，此时这个连接和http不同的是它是双工的了
浏览器和服务器有任何需要传递的数据的时候使用这个长连接进行数据传递
这里说它是HTTP握手，是因为浏览器和服务器在建立长连接的握手过程是按照HTTP1.1的协议发送的，有Request，Request Header， Response， Response Header。但是不同的是Header里面的字段是有特定含义的。
说它是TCP传输，主要体现在建立长连接后，浏览器是可以给服务器发送数据，服务器也可以给浏览器发送请求的。当然它的数据格式并不是自己定义的，是在要传输的数据外层有ws协议规定的外层包的。
这是一个握手过程的例子。
Upgrade头表示的意思是&客户端除了http之外也支持websocket协议，而且更倾向使用websocket，服务端如果支持的话，咱们就换websocket协议吧&
sec-websocket-version：是指出浏览器支持的websocket号。这里是支持hybi-13。这里是不会出现9-12的版本号的。websocket协议规定9-12是保留字段。
sec-websocket-key：算是一种验证返回回来的服务端是否是支持websocket的验证算法。与Response中的sec-websocket-accept是对应的。
sec-websocket-accept与sec-websocket-key的对应算法是：
sec-websocket-accept = base64(hsa1(sec-websocket-key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11))
如果返回的sec-websocket-accept不对，在chrome下会出现Sec-WebSocket-Accept dismatch的错误。
Response返回的HTTP Staus是101，代表服务端说&我们双方后面就按照websocket协议来进行数据传输吧&
数据传输过程
websocket的数据传输是frame形式传输的，比如会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处：
1 大数据的传输可以分片传输，不用考虑到数据大小导致的长度标志位不足够的情况。
2 和http的chunk一样，可以边生成数据边传递消息，即提高传输效率。
传输协议：
FIN：1位，用来表明这是一个消息的最后的消息片断，当然第一个消息片断也可能是最后的一个消息片断
RSV1, RSV2, RSV3: 分别都是1位，如果双方之间没有约定自定义协议，那么这几位的值都必须为0,否则必须断掉WebSocket连接
Opcode:4位操作码，定义有效负载数据，如果收到了一个未知的操作码，连接也必须断掉，以下是定义的操作码：
&&&&& *& %x0 表示连续消息片断
&&&&& *& %x1 表示文本消息片断
&&&&& *& %x2 表未二进制消息片断
&&&&& *& %x3-7 为将来的非控制消息片断保留的操作码
&&&&& *& %x8 表示连接关闭
&&&&& *& %x9 表示心跳检查的ping
&&&&& *& %xA 表示心跳检查的pong
&&&&& *& %xB-F 为将来的控制消息片断的保留操作码
Mask:1位，定义传输的数据是否有加掩码,如果设置为1,掩码键必须放在masking-key区域，客户端发送给服务端的所有消息，此位的值都是1
Payload length: 传输数据的长度，以字节的形式表示：7位、7+16位、或者7+64位。如果这个值以字节表示是0-125这个范围，那这个值就表示传输数据的长度；如果这个值是126，则随后的两个字节表示的是一个16进制无符号数，用来表示传输数据的长度；如果这个值是127,则随后的是8个字节表示的一个64位无符合数，这个数用来表示传输数据的长度。多字节长度的数量是以网络字节的顺序表示。负载数据的长度为扩展数据及应用数据之和，扩展数据的长度可能为0,因而此时负载数据的长度就为应用数据的长度
Masking-key:0或4个字节，客户端发送给服务端的数据，都是通过内嵌的一个32位值作为掩码的；掩码键只有在掩码位设置为1的时候存在
Payload data: (x+y)位，负载数据为扩展数据及应用数据长度之和
Extension data:x位，如果客户端与服务端之间没有特殊约定，那么扩展数据的长度始终为0，任何的扩展都必须指定扩展数据的长度，或者长度的计算方式，以及在握手时如何确定正确的握手方式。如果存在扩展数据，则扩展数据就会包括在负载数据的长度之内
Application data:y位，任意的应用数据，放在扩展数据之后，应用数据的长度=负载数据的长度-扩展数据的长度
读取数据需要按照这个格式读取，发送数据也需要按照这个格式发送返回。
代码示例：
1 chatofPemelo
远程控制air
3 nginx1.3.13
nginx1.3.13只是支持了websocket代理
Feature: support for proxying of WebSocket connections.& 开源中国(OSChina.NET) |
开源中国社区(OSChina.net)是工信部
指定的官方社区html5（21）
为了实现移动客户端实时通信，拟采用安卓webview内嵌html实现方式开发app，通信则采用最新的html5新特性websocket实现。经测试，android4.0以下内置浏览器都不支持websocket特性。经过google后，发现以下方案可以解决：
使用(采用flash实现websocket的替代方案）
既然内置浏览器不支持websocket，是不是可以采用支持websocket的浏览器来实现呢？github上面就有一个，仔细看了一下，发现github上面只是说比原生webview多一些新特性，但是并未提及websocket，而且github的repository是安卓4.2的
既然已经在android系统环境下，那么何不在webview下使用javascript调用java，通过java api直接创建socket与服务器相连，或者？实例源码（经测试，访问协议地址【ws://echo.websocket.org/】可以，但是访问tomcat7.0.50根本没有触发onopen事件，也就是说没有建立连接。websocket.java里面的构造方法使用的draft75，不知道tomcat使用的是websocket哪个草案啊，RCF？但是应该传什么参数呢？直接RCF?）
其他人的工作&&&&
后面就一个一个办法试一试了，感谢他们的工作！
长按图片识别图中二维码(或搜索微信公众号FrontEndStory)关注“前端那些事儿”，带你了解最新的前端技术。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：92414次
积分：1574
积分：1574
排名：第17655名
原创：39篇
转载：195篇
(7)(7)(2)(4)(3)(4)(2)(4)(5)(3)(6)(2)(1)(5)(18)(17)(20)(7)(9)(4)(14)(13)(7)(15)(4)(9)(30)(13)