概述
1996年IETF HTTP事情组发布了HTT到广泛运用的协议,相对付互联网的迅猛发展,它彷佛进步地很慢。互联网从兴起到现在,经历了门户网站盛行的web1.0时期,而后随着ajax技能的涌现,发展为web运用盛行的web2.0时期,如今又朝着web3.0的方向迈进。反不雅观http协议,从版本1.0发展到1.1,除了默认长连接之外便是缓存处理、带宽优化和安全性等方面的不痛不痒的改进。它一贯保留着无状态、要求/相应模式,彷佛从来没意识到这该当有所改变。
好在HTML5的时期已经到来,为Web端即时通讯的实现带来了WebSocket和SSE(Server-sent Events)两种技能方案。
Ajax短轮询:脚本发送的http要求
传统的web运用要想与做事器交互,必须提交一个表单(form),做事器吸收并处理传来的表单,然后返回全新的页面,由于前后两个页面的数据大部分都是相同的,这个过程传输了很多冗余的数据、摧残浪费蹂躏了带宽。于是Ajax技能便应运而生。
Ajax是Asynchronous JavaScript and XML的简称,由Jesse James Garrett 首先提出。这种技能首创性地许可浏览器脚本(JS)发送http要求。Outlook Web Access小组于98年利用,并很快成为IE4.0的一部分,但是这个技能一贯很小众,直到2005年初,google在他的goole groups、gmail等交互式运用中广泛利用此种技能,才使得Ajax迅速被大家所接管。
Ajax的涌现使客户端与做事器端传输数据少了很多,也快了很多,也知足了以丰富用户体验为特点的web2.0时期 初期发展的须要,但是逐步地也暴露了他的弊端。比如无法知足即时通信等富交互式运用的实时更新数据的哀求。这种浏览器真个小技能毕竟还是基于http协议,http协议哀求的要求/相应的模式也是无法改变的,除非http协议本身有所改变。
Comet:一种hack技能
以即时通信为代表的web运用程序对数据的Low Latency哀求,传统的基于轮询的办法已经无法知足,而且也会带来不好的用户体验。于是一种基于http长连接的“做事器推”技能便被hack出来。这种技能被命名为Comet,这个术语由Dojo Toolkit 的项目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出,并沿用下来。
实在,做事器推很早就存在了,在经典的client/server模型中有广泛利用,只是浏览器太
以下是范例的Ajax和Comet数据传输办法的比拟,差异大略明了。范例的Ajax通信办法也是http协议的经典利用办法,要想取得数据,必须首先发送要求。在Low Latency哀求比较高的web运用中,只能增加做事器要求的频率。Comet则不同,客户端与做事器端保持一个长连接,只有客户端须要的数据更新时,做事器才主动将数据推送给客户端。
Comet的实现紧张有两种办法,基于Ajax的长轮询(long-polling)办法和基于 Iframe 及 htmlfile 的流(http streaming)办法。
有关Comet技能的详细先容文章请拜会:《Comet技能详解:基于HTTP长连接的Web端实时通信技能》、《WEB端即时通讯:HTTP长连接、长轮询(long polling)详解》、《WEB端即时通讯:不用WebSocket也一样能搞定的即时性》、《开源Comet做事器iComet:支持百万并发的Web端即时通讯方案》。
1基于Ajax的长轮询(long-polling)办法
浏览器发出XMLHttpRequest 要求,做事器端吸收到要求后,会壅塞要求直到有数据或者超时才返回,浏览器JS在处理要求返复书息(超时或有效数据)后再次发出要求,重新建立连接。在此期间做事器端可能已经有新的数据到达,做事器会选择把数据保存,直到重新建立连接,浏览器会把所有数据一次性取回。
2基于 Iframe 及 htmlfile 的流(http streaming)办法
Iframe是html标记,这个标记的src属性会保持对指定做事器的长连接要求,做事器端则可以一直地返回数据,相对付第一种办法,这种办法跟传统的做事器推则更靠近。
在第一种办法中,浏览器在收到数据后会直接调用JS回调函数,但是这种办法该如何相应数据呢?可以通过在返回数据中嵌入JS脚本的办法,如“<script type="text/javascript">js_func(“data from server ”)</script>”,做事器端将返回的数据作为回调函数的参数,浏览器在收到数据后就会实行这段JS脚本。
但是这种办法有一个明显的不敷之处:IE、Morzilla Firefox 下真个进度栏都会显示加载没有完成,而且 IE 上方的图标会一直的迁徙改变,表示加载正在进行。Google 的天才们利用一个称为“htmlfile”的 ActiveX 办理了在 IE 中的加载显示问题,并将这种方法运用到了 gmail+gtalk 产品中。
Websocket:未来的办理方案1
如果说Ajax的涌现是互联网发展的一定,那么Comet技能的涌现则更多透露出一种无奈,仅仅作为一种hack技能,由于没有更好的办理方案。Comet办理的问题该当由谁来办理才是合理的呢?浏览器,html标准,还是http标准?主角该当是谁呢?实质上讲,这涉及到数据传输办法,http协议应首当其冲,是时候改变一下这个
W3C给出了答案,在新一代html标准html5中供应了一种浏览器和做事器间进行全双工通讯的网络技能Websocket。从Websocket草案得知,Websocket是一个全新的、独立的协议,基于TCP协议,与http协议兼容、却不会融入http协议,仅仅作为html5的一部分。于是乎脚本又被授予了另一种能力:发起websocket要求。这种办法我们该当很熟习,由于Ajax便是这么做的,所不同的是,Ajax发起的是http要求而已。
与http协议不同的要求/相应模式不同,Websocket在建立连接之前有一个Handshake(Opening Handshake)过程,在关闭连接前也有一个Handshake(Closing Handshake)过程,建立连接之后,双方即可双向通信。
有关WebSocket的详细介,请拜会即时通讯网有关WebSocket的系列文章:《WebSocket详解(一):初步认识WebSocket技能》、《WebSocket详解(二):技能事理、代码演示和运用案例》、《WebSocket详解(三):深入WebSocket通信协议细节》。
从浏览器支持角度来看,WebSocket已经近在面前,但仍有一段较长的路要走,特殊是在中国这个IE6、7、8依然盛行的国家,旧版本浏览器的消亡须要很长一段韶光,在完备实现浏览器全兼容前,Comet技能可能仍旧是最好的办理方案。不过,当前也已存在一些比较成熟的封装方案来办理这种兼容性限定,比如:开源的Socket.io,详见《Socket.IO先容:支持WebSocket、用于WEB真个即时通讯的框架》。
SSE:未来的办理方案2
SSE(Server-Sent Event,做事端推送事宜)是一种许可做事端向客户端推送新数据的HTML5技能。与由客户端每隔几秒从做事端轮询拉取新数据比较,这是一种更优的办理方案。
与WebSocket比较,它也能从做事端向客户端推送数据。那如何决定你是用SSE还是WebSocket呢?概括来说,WebSocket能做的,SSE也能做,反之亦然,但在完成某些任务方面,它们各有千秋。
WebSocket是一种更为繁芜的做事端实现技能,但它是真正的双向传输技能,既能从做事端向客户端推送数据,也能从客户端向做事端推送数据。
WebSocket和SSE的浏览器支持率差不多,大多数主流桌面浏览器两者都支持。在Android 4.3以及更早的版本中,系统默认浏览器两者都不支持,Firefox和Chrome则完备支持;Android 4.4中,系统默认浏览器两者都支持;Safari从5.0开始支持SSE(iOS系统从4.0开始),但直到6.0才精确地支持WebSocket(6.0之前的Safari所实现的WebSocket协议存在安全问题,以是一些主流浏览器已经禁用了基于这个协议的实现)。
与WebSocket比较,SSE有一些显著的上风。个人认为它最大的上风便是便利:不须要添加任何新组件,用任何你习气的后端措辞和框架就能连续利用。你不用为新建虚拟机、弄一个新的IP或新的端口号而操心,就像在现有网站中新增一个页面那样大略。我喜好把这称为既存根本举动步伐上风。
SSE的第二个上风是做事真个简洁。相对而言,WebSocket则很繁芜,不借助赞助类库基本搞不定(我试过,令人痛楚)。
由于SSE能在现有的HTTP/HTTPS协议上运作,以是它能直接运行于现有的代理做事器和认证技能。而对WebSocket而言,代理做事器须要做一些开拓(或其他事情)才能支持,在写这本书时,很多做事器还没有(虽然这种状况会改进)。SSE还有一个上风:它是一种文本协议,脚本调试非常随意马虎。事实上,在本书中,我们会在开拓和测试时用curl,乃至直接在命令行中运行后端脚本。
不过,这就引出了WebSocket相较SSE的一个潜在上风:WebSocket是二进制协议,而SSE是文本协议(常日利用UTF-8编码)。当然,我们可以通过SSE连接传输二进制数据:在SSE中,只有两个具有分外意义的字符,它们是CR和LF,而对它们进行转码并不难。但用SSE传输二进制数据时数据会变大,如果须要从做事端到客户端传输大量的二进制数据,最好还是用WebSocket。
WebSocket相较SSE最大的上风在于它是双向互换的,这意味向做事端发送数据就像从做事端吸收数据一样大略。用SSE时,一样平常通过一个独立的Ajax要求从客户端向做事端传送数据。相对付WebSocket,这样利用Ajax会增加开销,但也就多一点点而已。如此一来,问题就变成了“什么时候须要关心这个差异?”如果须要以1次/秒或者更快的频率向做事端传输数据,那该当用WebSocket。0.2次/秒到1次/秒的频率是一个灰色地带,用WebSocket和用SSE差别不大;但如果你期望重负载,那就有必要确定基准点。频率低于0.2次/秒旁边时,两者差别不大。
从做事端向客户端传输数据的性能如何?如果是文本数据而非二进制数据(如前文所提到的),SSE和WebSocket没什么差异。它们都用TCP/IP套接字,都是轻量级协议。延迟、带宽、做事器负载等都没有差异,除非……呃?除非什么?
当你在享用SSE的既存根本举动步伐上风,并在客户端和做事端脚本之间设了一个网络做事器,差异就显现出来了。一个SSE连接不仅利用一个套接字,还会占用一个Apache线程或进程,如果用PHP,它会为这个连接专门创建一个PHP新实例。Apache和PHP会利用大量的内存,这会限制服务器所能支持的并行连接数。以是,要做到用SSE在数据传输性能上和WebSocket完备一样,须要写一个自己的后端做事器,当然,那些在任何情形下都会用自己的做事器并利用Node.js的人,会以为这有什么稀奇的。
说一下WebSocket在旧版本浏览器上的兼容。当前,大约超过2/3的浏览器支持这些新技能,移动端浏览器的支持率会低一些。依老例,每当须要双向套接字时,就会用到Flash,并且WebSocket的向后兼容常日是用Flash来做,这已经相称繁芜了,如果浏览器上没有Flash,情形更糟。概括来说,WebSocket难兼容,SSE易兼容。
有关SSE的详细先容文章请拜会:《SSE技能详解:一种全新的HTML5做事器推送事宜技能》。
全站即时通讯技能资料分类
[1] 网络编程根本资料:
《TCP/IP详解 - 第11章·UDP:用户数据报协议》
《TCP/IP详解 - 第17章·TCP:传输掌握协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典:TCP协议的3次握手与4次挥手过程详解》
《理论联系实际:Wireshark抓包剖析TCP 3次握手、4次挥手过程》
《打算机网络通讯协议关系图(中文珍藏版)》
《NAT详解:基本事理、穿越技能(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大?》
《Java新一代网络编程模型AIO事理及Linux系统AIO先容》
《NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……
[2] 有关IM/推送的通信格式、协议的选择:
《为什么QQ用的是UDP协议而不是TCP协议?》
《移动端即时通讯协议选择:UDP还是TCP?》
《如何选择即时通讯运用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯运用数据传输格式》
《移动端IM开拓须要面对的技能问题(含通信协议选择)》
《简述移动端IM开拓的那些坑:架构设计、通信协议和客户端》
《理论联系实际:一套范例的IM通信协议设计详解》
《58到家实时系统的协议设计等技能实践分享》
>> 更多同类文章 ……
[3] 有关IM/推送的心跳保活处理:
《Android进程保活详解:一篇文章办理你的所有疑问》
《Android端推送总结:实现事理、心跳保活、碰着的问题等》
《为何基于TCP协议的移动端IM仍旧须要心跳保活机制?》
《微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践:实现Android版微信的智能心跳机制》
《移动端IM实践:WhatsApp、Line、微信的心跳策略剖析》
>> 更多同类文章 ……
[4] 有关WEB端即时通讯开拓:
《新手入门贴:史上最全Web端即时通讯技能事理详解》
《Web端即时通讯技能盘点:短轮询、Comet、Websocket、SSE》
《SSE技能详解:一种全新的HTML5做事器推送事宜技能》
《Comet技能详解:基于HTTP长连接的Web端实时通信技能》
《WebSocket详解(一):初步认识WebSocket技能》
《socket.io实现推送的一点实践及思路》
>> 更多同类文章 ……
[5] 有关IM架构设计:
《浅谈IM系统的架构设计》
《简述移动端IM开拓的那些坑:架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越:京东客服即时通讯系统的技能架构演进进程》
《蘑菇街即时通讯/IM做事器开拓之架构选择》
《腾讯QQ1.4亿在线用户的技能寻衅和架构演进之路PPT》
《微信技能总监谈架构:微信之道——大道至简(演讲全文)》
《如何解读《微信技能总监谈架构:微信之道——大道至简》》
《快速裂变:见证微信强大后台架构从0到1的演进进程(一)》
《17年的实践:腾讯海量产品的技能方法论》
>> 更多同类文章 ……
[6] 有关IM安全的文章:
《即时通讯安全篇(一):精确地理解和利用Android端加密算法》
《即时通讯安全篇(二):磋商组合加密算法在IM中的运用》
《即时通讯安全篇(三):常用加解密算法与通讯安全讲解》
《即时通讯安全篇(四):实例剖析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际:一套范例的IM通信协议设计详解(含安全层设计)》
《微信新一代通信安全办理方案:基于TLS1.3的MMTLS详解》
《来自阿里OpenIM:打造安全可靠即时通讯做事的技能实践分享》
>> 更多同类文章 ……
[7] 有关实时音视频开拓:
《即时通讯音视频开拓(一):视频编解码之理论概述》
《即时通讯音视频开拓(二):视频编解码之数字视频先容》
《即时通讯音视频开拓(三):视频编解码之编码根本》
《即时通讯音视频开拓(四):视频编解码之预测技能先容》
《即时通讯音视频开拓(五):认识主流视频编码技能H.264》
《即时通讯音视频开拓(六):如何开始音频编解码技能的学习》
《即时通讯音视频开拓(七):音频根本及编码事理入门》
《即时通讯音视频开拓(八):常见的实时语音通讯编码标准》
《即时通讯音视频开拓(九):实时语音通讯的覆信及覆信肃清概述》
《即时通讯音视频开拓(十):实时语音通讯的覆信肃清技能详解》
《即时通讯音视频开拓(十一):实时语音通讯丢包补偿技能详解》
《即时通讯音视频开拓(十二):多人实时音视频谈天架构磋商》
《即时通讯音视频开拓(十三):实时视频编码H.264的特点与上风》
《即时通讯音视频开拓(十四):实时音视频数据传输协议先容》
《即时通讯音视频开拓(十五):聊聊P2P与实时音视频的运用情形》
《即时通讯音视频开拓(十六):移动端实时音视频开拓的几个建议》
《即时通讯音视频开拓(十七):视频编码H.264、V8的前世今生》
《简述开源实时音视频技能WebRTC的优缺陷》
《良心分享:WebRTC 零根本开拓者教程(中文)》
>> 更多同类文章 ……
[8] IM开拓综合文章:
《移动端IM开拓须要面对的技能问题》
《开拓IM是自己设计协议用字节流好还是字符流好?》
《叨教有人知道语音留言谈天的主流实现办法吗?》
《IM系统中如何担保的可靠投递(即QoS机制)》
《谈谈移动端 IM 开拓中登录要求的优化》
《完备自已开拓的IM该如何设计“失落败重试”机制?》
《微信对网络影响的技能试验及剖析(论文全文)》
《即时通讯系统的事理、技能和运用(技能论文)》
《开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀》
>> 更多同类文章 ……
[9] 开源移动端IM技能框架资料:
《开源移动端IM技能框架MobileIMSDK:快速入门》
《开源移动端IM技能框架MobileIMSDK:常见问题解答》
《开源移动端IM技能框架MobileIMSDK:压力测试报告》
《开源移动端IM技能框架MobileIMSDK:Android版Demo利用帮助》
《开源移动端IM技能框架MobileIMSDK:Java版Demo利用帮助》
《开源移动端IM技能框架MobileIMSDK:iOS版Demo利用帮助》
《开源移动端IM技能框架MobileIMSDK:Android客户端开拓指南》
《开源移动端IM技能框架MobileIMSDK:Java客户端开拓指南》
《开源移动端IM技能框架MobileIMSDK:iOS客户端开拓指南》
《开源移动端IM技能框架MobileIMSDK:Server端开拓指南》
>> 更多同类文章 ……
[10] 有关推送技能的文章:
《iOS的推送做事APNs详解:设计思路、技能事理及毛病等》
《Android端推送总结:实现事理、心跳保活、碰着的问题等》
《扫盲贴:认识MQTT通信协议》
《一个基于MQTT通信协议的完全Android推送Demo》
《求教android推送:GCM、XMPP、MQTT三种方案的利害》
《移动端实时推送技能浅析》
《扫盲贴:浅谈iOS和Android后台实时推送的事理和差异》
《绝对干货:基于Netty实现海量接入的推送做事技能要点》
《移动端IM实践:谷歌推送做事(GCM)研究(来自微信)》
《为何微信、QQ这样的IM工具不该用GCM做事推送?》
>> 更多同类文章 ……
[11] 更多即时通讯技能好文分类:
http://www.52im.net/forum.php?mod=collection&op=all
16 条评论
2楼
IMDeveloper LV.5
3 年前
总结的很好,再也不用纠结了该选啥了,一览无余
署名: 国庆长假还没有缓过来,请让我静一静,产品狗去世远点...
3楼
什么狗屁云 LV.3
3 年前
不错不错,秒懂了
署名: 该会员没有填写今日想说内容.
4楼
mo_mean LV.1
3 年前
受教了·
5楼
JackJiang LV.9
楼主
3 年前
引用另一个网友的评论:
PHP即时通讯国人就搞了可用的两套方案,一套是WorkerMan,一套是Swoole.
国人纯PHP开拓的高性能谈天室框架WorkerMan:
http://www.workerman.net/workerman-chat
http://doc.workerman.net/start/environment.html
前端:HTML5 WebSocket
后端:PHP-CLI (不依赖Nginx/Apache)
WorkerMan用到了多少PHP进程掌握PECL扩展(不支持Windows):
pcntl: 进程创建,旗子暗记掌握,定时器,进程状态监控
posix: 守护进程化,用户组掌握
sysvshm: 共享内存,进程间通信
sysvmsg: 行列步队,进程间通信
libevent: 让PHP可以利用系统epoll/kqueue等高等事宜处理机制,能够显著提高WorkerMan在高并发连接时CPU利用率.
proctitle: 变动良程的名称
PECL扩展Swoole支持利用PHP来编写高性能的socket运用:
pecl remote-info swoole
http://www.swoole.com
http://git.oschina.net/matyhtf/swoole/blob/master/examples
PHPWebIM是Swoole官方基于PHP Swoole扩展和Swoole Framework开拓的WebSocket网页即时谈天工具.
PHPWebIM支持WebSocket+Comet两种协议,可用于所有种类的浏览器包括IE.
https://github.com/matyhtf/PHPWebIM
Demo: http://webim.swoole.com
署名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
上一页
第1页
第2页
第3页
第4页
第1页
下一页
我也要说两句
16
评论
12
收藏
2
赞
© 即时通讯网 - 即时通讯开拓者社区