本文共 8222 字,大约阅读时间需要 27 分钟。
如何为webRTC项目选择信令协议
总体来说,有五种不同的webRTC信令协议实现方式: 信令协议_______________它是什么______________选择理由 SIP over WebSocket 继承自VoIP的老顽固 它可以和现在的多数后端建立连接 XMPP/Jingle XMPP的狂热分子 因为它是基于XMPP的 WebSocket 最流行的时常达人 它是最新的,最功能强大的基于web的C-S通信协议 XHR/Comet 经典用法 因为webSocket不能在所有的地方使用 Data Channle 寻求刺激分子 webRTC的数据通道是可于信令传输的未知领域它是web信令的经典方法。
Comet是一种用于web的技术,能使服务器能实时地将更新的信息传送到客户端,而无须客户端发出请求, 目前有两种实现方式: 长轮询和iframe流。 . 长轮询 长轮询是在打开一条连接以后保持,等待服务器推送来数据再关闭的方式。 . iframe流 iframe流方式是在页面中插入一个隐藏的iframe,利用其src属性在服务器和客户端之间创建一条长链接, 服务器向iframe传输数据(通常是HTML,内有负责插入信息的javascript),来实时更新页面。 Comet方式通俗的说就是一种长连接机制(long lived http)。 同样是由Browser端主动发起请求,但是Server端以一种似乎非常慢的响应方式给出回答。 这样在这个期间内,服务器端可以使用同一个connection把要更新的数据主动发送给Browser。 因此请求可能等待较长的时间,期间没有任何数据返回,但是一旦有了新的数据,它将立即被发送到客户机。 Comet又有很多种实现方式,但是总的来说对Server端的负载都会有增加. 虽然对于单位操作来说,每次只需要建议一次connection,但是由于connection是保持较长时间的, 对于 server端的资源的占用要有所增加。 优点: 实时性好(消息延时小);性能好(能支持大量用户) 缺点: 长期占用连接,丧失了无状态高并发的特点。 应用: 股票系统、实时通讯。 它的实现如下图中所示:WebSocket protocol 是HTML5一种新的协议。
它实现了浏览器与服务器全双工通信(full-duplex)。众所周知,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 是 HTML5 一种新的协议。
它实现了浏览器与服务器全双工通信,能更好的节省服务器资源和带宽并达到实时通讯, 它建立在 TCP 之上,同 HTTP 一样通过 TCP 来传输数据, 但是它和 HTTP 最大不同是: . WebSocket 是一种双向通信协议, 在建立连接后,WebSocket 服务器和 Browser/Client Agent 都能主动的向对方发送或接收数据, 就像 Socket 一样; . WebSocket 需要类似 TCP 的客户端和服务器端通过握手连接,连接成功后才能相互通信 非 WebSocket 模式传统 HTTP 客户端与服务器的交互如下图所示:不是所有的浏览器都支持,目前支持的浏览器有:
WebSocket客户端支持 浏览器 支持情况 Chrome Chrome version 4+支持 Firefox Firefox version 5+支持 IE IE version 10+支持 Safari IOS 5+支持 Android Brower Android 4.5+支持 也不是所有的web服务器都支持,目前支持的web服务器有: 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 支持 Apache Jetty Jetty 7.0+支持 因些,你需要考虑你的应用的架构和网络组件是否能用webSocket. 如果你计划使用webSocket,还有两个额外的事情要做: . Run them over a secured TLS connection, which in general is what you should do for any WebRTC signaling anyway . Think of using a hybrid solution like socket.io or SockJS, which can automatically “downgrade” to COMET mechanisms if WebSockets aren’t available I’d also use WebSockets whenever. As in whenever I don’t feel that options 3-5 below make sense to me. 实际上,下面的3~5的选项都不好用。 UPDATE: As someone smart pointed out – on its own, this technique still require you to define your own proprietary signaling messages. webSocket信令协议示例1
SIP(Session Initiation Protocol,会话初始协议)是由IETF
(Internet Engineering Task Force,因特网工程任务组)制定的多媒体通信协议。 它是一个基于文本的应用层控制协议,用于创建、修改和释放一个或多个参与者的会话。 广泛应用于CS(Circuit Switched,电路交换)、 NGN(Next Generation Network,下一代网络)以及 IMS(IP Multimedia Subsystem,IP多媒体子系统)的网络中, 可以支持并应用于语音、视频、数据等多媒体业务,同时也可以应用于Presence(呈现)、 Instant Message(即时消息)等特色业务。 可以说,有IP网络的地方就有SIP协议的存在。 SIP是类似于HTTP。SIP可以减少应用特别是高级应用的开发时间。 SIP协议本身是一个成熟的经过考验的网络通话协议。 SIP协议的流程和包含的信令大致如下:XMPP是一种基于标准通用标记语言的子集XML的协议,它继承了在XML环境中灵活的发展性。
因此,基于XMPP的应用具有超强的可扩展性。 经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求, 以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。 而且,XMPP包含了针对服务器端的软件协议,使之能与另一个进行通话, 这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。 它和SIP类似,只是另一个叫XMPP的协议罢了。 If you take this route, it is probably either because you have an existing XMPP installation or you need the presence capabilities that XMPP comes with out of the box (and with server side implementations readily available). I am not a fan of XMPP to say the least, but I don’t really have anything bad to say about this approach. If you know and like XMPP – go for it.WebRTC has a data channel. Once an initial connection is made between the two “endpoints”,
you can use the data channel to communication and drive your signaling instead of going via a server. There are few I’ve seen that use this approach, and it does have merit. If has 3 main benefits: Latency of signaling messages is lower, as there’s no server in-between that needs to parse and understand them Since a server isn’t involved, server scalability improves – it handles less messages from each connected browser Improved privacy, simply because tapping into the server gives you less information UPDATE: As with Comet and WebSockets, you still need to define your messages when using the data channel. 数据通道信令协议示例1Selection of the signaling protocol will decide the development effort required for certain features
as well as the cost you pay for it –in setup time of sessions, server performance, etc. It is a decision that shouldn’t be taken lightly. – While we’re here – how about subscribing to my monthly email? It deals with such questions on… a monthly basis. 参考文档: 1. https://bloggeek.me/siganling-protocol-webrtc/ 2. http://www.ibm.com/developerworks/cn/java/j-lo-WebSocket/
转载自: