websocket数据传输做游戏数据传输有必要加密吗?如果有,怎么加密

&&&&&&&&&&&&&
WebSocket protocol 是一种新的协议。它是实现了浏览器与服务器全双工通信(full-duplex)。
& & & &现 很多网站为了实现即时通讯,所用的技术都是轮询(polling)。轮询是在特定的的时间间隔(如每1秒),由浏览器对服务器发出HTTP request,然后由服务器返回最新的数据给客服端的浏览器。这种传统的HTTP request 的模式带来很明显的缺点 & 浏览器需要不断的向服务器发出请求,然而HTTP request 的header是非常长的,里面包含的数据可能只是一个很小的值,这样会占用很多的带宽。
& & & &而最比较新的技术去做轮询的效果是Comet & 用了AJAX。但这种技术虽然可达到全双工通信,但依然需要发出请求。
& & & &在 WebSocket API,浏览器和服务器只需要要做一个握手的动作,然后,浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送,改变了原有的B/S模式。
& & & &在这里是关于Websocket在 php 中的实现,这篇文章里,我主要对websocket 协议进行一个简单的介绍。
Websocket 业务模型
浏览器端的websocket 请求一般是
&// javacsript
& var ws = new WebSocket("ws://127.0.0.1:4000");
& ws.onopen = function(){
& & console.log("succeed");
& ws.onerror = function(){
& & console.log(&error&);
& ws.onmessage = function(e){
& console.log(e);&
当 new 一个 websocket 对象之后,就会向服务器发送一个 get 请求
& & & &这个请求是对摸个服务器的端口发送的,一般的话,会预先在服务器将一个socket 绑定到一个端口上,客户端和服务器端在这个预定的端口上通信(我这里绑定的就是 4000 端口,默认情况下,websocke 使用 80 端口)。
& & & &然 后,在服务器端的socket监听到这个packet 之后就生成一个新的 socket,将发送过来的数据中的 Sec-WebSocket-Key 解析出来,然后按照把&Sec-WebSocket-Ke&加上一个魔幻字符串&258EAFA5-E914-47DA-95CA- C5AB0DC85B11&。使用SHA-1加密,之后进行BASE-64编码,将结果做为&Sec-WebSocket-Accept&头的值,返回给 客户端。
& & & &客户端收到这个之后,就会将 通信协议 upgrade 到 websocket 协议。
& & & &然后就会在这个持久的通道下进行通信,包括浏览器的询问,服务器的push,双方是在一个全双工的状态下相互通信。 切换后的websocket 协议中的 数据传输帧的格式(此时不再使用html协议) 官方文档给出的说明:
& & & &直接看这个,谁都会有点头大: 我花了一幅图来简单的解释这个 frame 的结构。
各字段的解释:
FIN & & & & & & &1bit 表示信息的最后一帧,flag,也就是标记符
RSV 1-3 & & & &1bit each 以后备用的 默认都为 0
Opcode & & & & 4bit 帧类型,
Mask & & & & & & &1bit 掩码,是否加密数据,默认必须置为1&
Payload len & 7bit 数据的长度,当这个7 bit的数据 == 126 时,后面的2 个字节也是表示数 & & 据长度,当它 == 127 时,后面的 8 个字节表示数据长度Masking-key & & &1 or 4 bit 掩码Payload data &playload len &bytes 数据
& & & &所以我们这里的代码,通过判断 Playload len的值,来用 substr 截取 Masking-key 和 PlayloadData。
& & & &根据掩码解析数据的方法是:
for( i = 0; i & data. i++){
& &orginalData += data[i] &^ &maskingKey[i mod 4];&
& & & &在PHP中,当我们收到数据之后,按照这里的格式截取数据,并将其按照这里的方法解析后就得到了浏览器发送过来的数据。 当我们想把数据发送给浏览器时,也要按照这个格式组装frame。 这里是我的方法:
& function frame($s){
& $a = str_split($s, 125);
& if (count($a) == 1){
& return "\x81" . chr(strlen($a[0])) . $a[0];
& $ns = "";
& foreach ($a as $o){
& $ns .= "\x81" . chr(strlen($o)) . $o;
& return $
& & & &强 行将要发送的数据分割成 125 Byte / frame,这样 playload len 只需要 7 bits。也就是直接将数据的长度的ascall码拼接上去,然后后面跟上要发送的数据。 每一个 frame 前面加的 &\x81& 用二进制就是: 00 :
000 是三个备用的bit
0001 : 指的是 opcode 官方的解释:
& & & &可以设置 opcode的值,来告诉浏览器这个frame的数据属性。
&posted on
阅读(...) 评论()WebSocket 是什么原理?为什么可以实现持久连接? - 知乎5343被浏览391751分享邀请回答GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
熟悉HTTP的童鞋可能发现了,这段类似HTTP协议的握手请求中,多了几个东西。我会顺便讲解下作用。Upgrade: websocket
Connection: Upgrade
这个就是Websocket的核心了,告诉Apache、Nginx等服务器:注意啦,窝发起的是Websocket协议,快点帮我找到对应的助理处理~不是那个老土的HTTP。Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
首先,Sec-WebSocket-Key 是一个Base64 encode的值,这个是浏览器随机生成的,告诉服务器:泥煤,不要忽悠窝,我要验证尼是不是真的是Websocket助理。然后,Sec_WebSocket-Protocol 是一个用户定义的字符串,用来区分同URL下,不同的服务所需要的协议。简单理解:今晚我要服务A,别搞错啦~最后,Sec-WebSocket-Version 是告诉服务器所使用的Websocket Draft(协议版本),在最初的时候,Websocket协议还在 Draft 阶段,各种奇奇怪怪的协议都有,而且还有很多期奇奇怪怪不同的东西,什么Firefox和Chrome用的不是一个版本之类的,当初Websocket协议太多可是一个大难题。。不过现在还好,已经定下来啦~大家都使用的一个东西~ 脱水:服务员,我要的是13岁的噢→_→然后服务器会返回下列东西,表示已经接受到请求, 成功建立Websocket啦!HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
这里开始就是HTTP最后负责的区域了,告诉客户,我已经成功切换协议啦~Upgrade: websocket
Connection: Upgrade
依然是固定的,告诉客户端即将升级的是Websocket协议,而不是mozillasocket,lurnarsocket或者shitsocket。然后,Sec-WebSocket-Accept 这个则是经过服务器确认,并且加密过后的 Sec-WebSocket-Key。服务器:好啦好啦,知道啦,给你看我的ID CARD来证明行了吧。。后面的,Sec-WebSocket-Protocol 则是表示最终使用的协议。至此,HTTP已经完成它所有工作了,接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。------------------技术解析部分完毕------------------你TMD又BBB了这么久,那到底Websocket有什么鬼用,http long poll,或者ajax轮询不都可以实现实时信息传递么。你TMD又BBB了这么久,那到底Websocket有什么鬼用,http long poll,或者ajax轮询不都可以实现实时信息传递么。好好好,年轻人,那我们来讲一讲Websocket有什么用。来给你吃点胡(苏)萝(丹)卜(红)三、Websocket的作用在讲Websocket之前,我就顺带着讲下 long poll 和 ajax轮询 的原理。首先是 ajax轮询 ,ajax轮询 的原理非常简单,让浏览器隔个几秒就发送一次请求,询问服务器是否有新信息。场景再现:客户端:啦啦啦,有没有新信息(Request)服务端:没有(Response)客户端:啦啦啦,有没有新信息(Request)服务端:没有。。(Response)客户端:啦啦啦,有没有新信息(Request)服务端:你好烦啊,没有啊。。(Response)客户端:啦啦啦,有没有新消息(Request)服务端:好啦好啦,有啦给你。(Response)客户端:啦啦啦,有没有新消息(Request)服务端:。。。。。没。。。。没。。。没有(Response) ---- looplong poll long poll 其实原理跟 ajax轮询 差不多,都是采用轮询的方式,不过采取的是阻塞模型(一直打电话,没收到就不挂电话),也就是说,客户端发起连接后,如果没消息,就一直不返回Response给客户端。直到有消息才返回,返回完之后,客户端再次建立连接,周而复始。场景再现客户端:啦啦啦,有没有新信息,没有的话就等有了才返回给我吧(Request)服务端:额。。
等待到有消息的时候。。来 给你(Response)客户端:啦啦啦,有没有新信息,没有的话就等有了才返回给我吧(Request) -loop从上面可以看出其实这两种方式,都是在不断地建立HTTP连接,然后等待服务端处理,可以体现HTTP协议的另外一个特点,被动性。何为被动性呢,其实就是,服务端不能主动联系客户端,只能有客户端发起。简单地说就是,服务器是一个很懒的冰箱(这是个梗)(不会、不能主动发起连接),但是上司有命令,如果有客户来,不管多么累都要好好接待。说完这个,我们再来说一说上面的缺陷(原谅我废话这么多吧OAQ)从上面很容易看出来,不管怎么样,上面这两种都是非常消耗资源的。ajax轮询 需要服务器有很快的处理速度和资源。(速度)long poll 需要有很高的并发,也就是说同时接待客户的能力。(场地大小)所以ajax轮询 和long poll 都有可能发生这种情况。客户端:啦啦啦啦,有新信息么?服务端:月线正忙,请稍后再试(503 Server Unavailable)客户端:。。。。好吧,啦啦啦,有新信息么?服务端:月线正忙,请稍后再试(503 Server Unavailable)客户端:然后服务端在一旁忙的要死:冰箱,我要更多的冰箱!更多。。更多。。(我错了。。这又是梗。。)--------------------------言归正传,我们来说Websocket吧通过上面这个例子,我们可以看出,这两种方式都不是最好的方式,需要很多资源。一种需要更快的速度,一种需要更多的'电话'。这两种都会导致'电话'的需求越来越高。哦对了,忘记说了HTTP还是一个无状态协议。(感谢评论区的各位指出OAQ)通俗的说就是,服务器因为每天要接待太多客户了,是个健忘鬼,你一挂电话,他就把你的东西全忘光了,把你的东西全丢掉了。你第二次还得再告诉服务器一遍。所以在这种情况下出现了,Websocket出现了。他解决了HTTP的这几个难题。首先,被动性,当服务器完成协议升级后(HTTP-&Websocket),服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。客户端:啦啦啦,我要建立Websocket协议,需要的服务:chat,Websocket协议版本:17(HTTP Request)服务端:ok,确认,已升级为Websocket协议(HTTP Protocols Switched)客户端:麻烦你有信息的时候推送给我噢。。服务端:ok,有的时候会告诉你的。服务端:balabalabalabala服务端:balabalabalabala服务端:哈哈哈哈哈啊哈哈哈哈服务端:笑死我了哈哈哈哈哈哈哈就变成了这样,只需要经过一次HTTP请求,就可以做到源源不断的信息传送了。(在程序设计中,这种设计叫做回调,即:你有信息了再来通知我,而不是我傻乎乎的每次跑来问你)这样的协议解决了上面同步有延迟,而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢?其实我们所用的程序是要经过两层代理的,即HTTP协议在Nginx等服务器的解析下,然后再传送给相应的Handler(PHP等)来处理。简单地说,我们有一个非常快速的接线员(Nginx),他负责把问题转交给相应的客服(Handler)。本身接线员基本上速度是足够的,但是每次都卡在客服(Handler)了,老有客服处理速度太慢。,导致客服不够。Websocket就解决了这样一个难题,建立后,可以直接跟接线员建立持久连接,有信息的时候客服想办法通知接线员,然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。同时,在传统的方式上,要不断的建立,关闭HTTP协议,由于HTTP是非状态性的,每次都要重新传输identity info(鉴别信息),来告诉服务端你是谁。虽然接线员很快速,但是每次都要听这么一堆,效率也会有所下降的,同时还得不断把这些信息转交给客服,不但浪费客服的处理时间,而且还会在网路传输中消耗过多的流量/时间。但是Websocket只需要一次HTTP握手,所以说整个通讯过程是建立在一次连接/状态中,也就避免了HTTP的非状态性,服务端会一直知道你的信息,直到你关闭请求,这样就解决了接线员要反复解析HTTP协议,还要查看identity info的信息。同时由客户主动询问,转换为服务器(推送)有信息的时候就发送(当然客户端还是等主动发送信息过来的。。),没有信息的时候就交给接线员(Nginx),不需要占用本身速度就慢的客服(Handler)了--------------------至于怎么在不支持Websocket的客户端上使用Websocket。。答案是:不能但是可以通过上面说的 long poll 和 ajax 轮询来 模拟出类似的效果-----_(:з」∠)_两天写了两篇科普类文章。。好累OAQ,求赞。。对啦,如果有错误,欢迎大家在底下留言指出噢~5.1K245 条评论分享收藏感谢收起43431 条评论分享收藏感谢收起查看更多回答1 个回答被折叠()登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 九月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于:
HTML5 Web Sockets与代理服务器交互
HTML5 Web Sockets与代理服务器交互
Peter Lubbers
0&他的粉丝
0&他的粉丝
日. 估计阅读时间:
:Facebook、Snapchat、Tumblr等背后的核心技术
相关厂商内容
相关赞助商
要使用HTML5 Web Sockets从一个Web客户端连接到一个远程端点,你要创建一个新的WebSocket实例并为之提供一个URL来表示你想要连接到的远程端点。该规范定义了ws://以及wss://模式来分别表示WebSocket和安全WebSocket连接。一个WebSocket连接是在客户端与服务器之间HTTP协议的初始握手阶段将其升级到Web Socket协议来建立的,其底层仍是TCP/IP连接。
Proxy Servers
一个代理服务器是作为客户端与另一个服务器之间的一个中介(比如,因特网上的一个web服务器)。代理服务器通常被用作内容缓存,因特网连接,安全,以及企业内容过滤。典型的,一个代理服务器被架设在私有网络与因特网之间。代理服务器可以监控流量并断开连接,如果该连接已打开很久。对于使用长期活跃连接的web应用来说(比如,Comet HTTP流或者HTML5 Web Sockets),代理服务器的问题是明显的:HTTP代理服务器&&原本最初设计用来文档转移&&可能会选择关闭流或闲置的WebSocket连接,因为它们看起好像是尝试连接一个没有回应的HTTP服务器。这一行为对于长久的连接,比如WebSockets来说,是存在问题的。另外,代理服务器可能会缓冲未加密的HTTP响应,这将会对HTTP响应流带来不可估计的延迟。
HTML5 Web Sockets和代理服务器
让我们看看HTML5 Web Sockets是如何与代理服务器工作的。WebSocket连接使用标准HTTP端口(80和443),这让很多人管它叫做&代理服务器和防火墙友好协议&。因此,HTML5 Web Sockets不需要安装新的硬件,或者要求公司网络开放新的端口&&这两件事足以使任何新的协议夭折。在浏览器与WebSocket服务器之间不需要任何中间服务器(代理或反向代理服务器,防火墙,负载平衡路由器等等),只要服务器和客户端双方都理解Web Socket协议,WebSocket连接就可以顺利的建立。然而,在真实的环境中,许多网络流量都被路由到中间服务器。
一图胜千言。图1展示了一个简化的网络拓扑,客户端使用浏览器来访问后端基于TCP的服务,这里使用了全双工的HTML5 WebSocket连接。一些客户端位于公司网络内部,受到公司防火墙的保护,并被配置为通过显式的或者已知的代理服务器来访问因特网,这些代理服务器会提供内容缓存和安全;而其它的客户端则直接在因特网上访问WebSocket。两种情况中,客户端的请求都可能被路由到透明的,或者未知的代理服务器(例如,一个数据中心的代理服务器或者远程服务器前端的一个反向代理服务器)。代理服务器甚至还有可能有它们自己的显式的代理服务器,这又增加了WebSocket传输需要的中继数。
图1&&有着显式和透明的代理服务器的Web Sockets架构
跟常规的使用请求/响应协议的HTTP传输不一样,WebSocket连接可以长时间保持打开。代理服务器也许可以支持这点并优雅地处理,但它们同时也可能带来破坏因素。
WebSocket Upgrade
HTML5 Web Sockets使用HTTP Upgrade机制升级到Web Socket协议。HTML5 Web Sockets有着兼容HTTP的握手机制,因此HTTP服务器可以与WebSocket服务器共享默认的HTTP与HTTPS端(80和443)。要建立一个WebSocket连接,客户端和服务器在初次握手的时候从HTTP协议提升到Web Socket协议,如例1所展示的。一旦连接建立,WebSocket数据帧就可以以全双工的模式在客户端和服务器之间来回传输。
例1&WebSocket升级握手
客户端到服务器:
GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Protocol: sample
服务器到客户端:
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin:
WebSocket-Location: ws:///demo
WebSocket-Protocol: sample
未加密的WebSocket连接
Web Socket协议本身并不知道代理服务器与防火墙;它只定义了WebSocket升级握手与WebSocket数据帧的格式。让我们看看在两种代理服务器场景(显式的和透明的)中未加密WebSocket传输的情况。
未加密WebSocket连接与显式代理服务器
如果一个浏览器被配置为使用显式的代理服务器,那么在建立WebSocket连接时它首先向代理服务器发出HTTP CONNECT方法。比如,要使用ws://模式(通常是通过80端口)连接到服务器,浏览器客户端就会像例2所示的那样向代理服务器发出HTTP CONNECT方法。
例2&使用80端口的HTTP CONNECT方法
:80 HTTP/1.1
当这个显式的代理服务器允许CONNECT方法时,WebSocket连接升级握手得以完成,握手成功后,WebSocket信息流就可以畅通无阻地通过代理服务器传输了。
未加密的WebSocket连接与透明代理服务器
如果是未加密的WebSocket信息流通过透明的代理传输到WebSocket服务器这种情况,实践中连接很可能失败,因为在这种情况下,浏览器没有发出CONNECT方法。当代理服务器将请求转发到(WebSocket)服务器时,将会被剥去一些特定的消息头,包括Connection消息头。因此,一个工作良好的透明代理服务器几乎会立刻引起WebSocekt升级握手失败。
并非所有的代理服务器在所期待的代理行为方面都遵循HTTP标准。比如,一些代理服务器被配置为不删除Connection: Upgrade消息头,并将其传送给WebSocket服务器,反过来服务器又会发送101 Web Socket Protocol Handshake响应。而当客户端或服务器开始发送第一个WebSocket帧时问题就出现了。因为这帧数据与代理服务器所期待的任何事物(比如常规的HTTP流量)都不相同,就可能会产生一些异常,除非代理服务器被特别配置为处理WebSocket流量。
在WebSocket的握手阶段,Connection: Upgrade消息头被发送给WebSocket服务器。如果代理服务器不得不参与进升级机制的话,额外的代理服务器就必不可少,因为使用了逐跳传送;从代理服务器发送到浏览器的升级只适用于一跳,而代理服务器必须发送它自己的升级消息头来处理从代理服务器到WebSocket服务器(或另一个中间服务器)的下一跳。同时代理服务器还必须停止按HTTP来处理该请求。
目前,大部分透明代理服务器都还不了解Web Socket协议,而这些代理服务器也无法支持Web Socket协议。然而,未来,代理服务器将会是Web Socket可知的,并且能够合理的处理与转发WebSocket信息流。
加密的WebSocket连接
现在,让我们来看看加密的WebSocket信息流在两种不同的代理服务器场景下的情况(显式的和透明的)。
加密的WebSocket连接与显式的代理服务器
如果一个浏览器被配置为使用显式的代理服务器,那么在建立WebSocket连接时它首先会向该代理服务器发出一个HTTP CONNECT方法。比如,要使用wss://模式(典型地是通过443端口),连接到服务器,浏览器客户端会发送如例3所示的HTTP CONNECT方法到代理服务器。
例3&&使用端口443的HTTP CONNECT方法
:443 HTTP/1.1
当显式的代理服务器允许CONNECT方法时,TLS握手被发送出去,后面紧跟着WebSocket连接升级握手。这系列的握手成功后,WebSocket信息流就可以开始无阻碍的通过代理服务器了。HTTPS(HTTP over TLS)也是以同样的方式工作的;使用加密通常会触发HTTP CONNECT方法。
加密的WebSocket连接与透明的代理服务器
如果是透明代理服务器的情况,浏览器不知道代理服务器,因此不会有HTTP CONNECT方法被发送。然而,因为线上信息是加密的,中间的透明代理服务器可能会简单的让加密的信息通过。因此,如果使用了Web Sockets安全的话,WebSocket连接成功的几率要大得多。因此,始终与TLS加密一起使用Web Sockets安全来连接到WebSocket服务器是最佳的做法,除非你非常确实不会存在中间服务器。虽然这样做的好处是带来了更好的安全,但TLS加密确实会增加客户端与服务器两方面的CPU消耗,尽管这并非是特别大的增加,而且通过硬件的SSL/TLS加速,可以将其减小到几乎可忽略。
让我们再重述一下要点。图2展示了在浏览器与WebSocket服务器之间建立WebSocket连接过程中所做的决定。这张图展示了在WebSocket(ws://)与WebSocket安全(wss://)两种情况中使用显式的和透明的代理服务器建立连接的不同场景。
图2&&代理服务器遍历决策树
图2显示了在几乎是最简单的网络拓扑中为什么使用未加密的WebSocket连接更容易失败。所有都归结到要理解你所要部署WebSocket应用的端到端网络拓扑。一些HTTP代理服务器也许会限制端口或者只允许特定的被授权的服务器来访问。在这种场景中使用的WebSocket服务器必须被加入到服务器白名单中,连接才有可能成功。 通常,应当使用哪个协议(ws://或是wss://)来进行连接的是由客户端开发者来决定,同时还需要基于WebSocket信息流的隐私特征。未来,WebSocket网关和服务器能够支持在探测到不合作的代理服务器时,动态地升级到Web Socket安全。
Kaazing WebSocket网关和代理服务器
Kaazing WebSocket网关的特色功能有Web Socket模拟,以支持Web Socket对所有浏览器可用,包括那些不支持Web Sockets的。这一模拟工作在纯粹的JavaScript环境,不需要插件,同时还有Kazzing独家的Opportunistic Optimization&技术可以保证最佳的连接环境,无论客户端与中间代理服务器是否支持最新的协议。
例如:如果Kaazing WebSocket网关探测到存在Flash插件,客户端类库可以充分利用单一的(Flash)TCP套接字连接的优势,并且,如果直接连接无法实现(例如,如果通讯必须经过防火墙或者一个HTTP代理服务器),那么客户端类库仍然可以利用Flash运行时的优势,最小化客户端的内存剖析。
如果中间代理服务器位于Kaazing WebSocket网关与客户端的中间,那么就会使用一个高度优化的加密流式连接,并且代理-服务器-感知的网关会自动的转发HTTP请求,以使用加密的HTTP(HTTPS)连接来让流式特性的下行HTTP信息流忽略代理服务器。在生产环境中,需要预先考虑到HTTPS流可以被用作最坏情况的场景下,以留有一步余地。然而,为了使起动作起来,网关必须被配置适用于TLS加密的证书。如果没有的话(这会被视为一个配置错误),Kaazing将会退回到一种高级的非流式的实现。
kaazing的Web Socket模拟是高度优化的,并且轻而易举的就可以超越大部分的遗留Comet解决方案,因为它通过退回到HTTPS流保证了最小的延迟,这得归功于Kazzing底层对于跨不同源的HTTP和HTTPS请求的支持。注意不同的退回场景仅被用于模拟模式。使用Kaazing WebSocket网关及其Web Socket模拟的一个主要好处就是你现在就可以按照HTML5 Web Sockets标准来编码,并且这些应用可以运行于所有的浏览器。
负载平衡路由器与防火墙
这一节描述了HTML5 Web Socket是如何与负载平衡路由器和防火墙一起工作的。另外,还解释了Kaazing WebSocket网关如何带到额外的价值。
HTML5 Web Sockets与负载平衡路由器
对于这一讨论,让我们首先分清两种不同类型的负载平衡路由器:
&O TCP(第4层)负载平衡路由器以与HTML5 Web Sockets很好的工作,因为他们有同样的连接形式:一开始连接一次并保持连接,而不是HTTP文档转移的请求&&响应式的形式。
&O HTTP(第7层)负载平衡路由器它本是为HTTP信息流准备的,因此很容易就会被WebSocket升级信息流所迷惑。因此,第7层负载平衡路由器需要被配置为能明确感知WebSocket信息流。
HTML5 Web Sockets与防火墙
因为防火墙通常是在对进入的流量控制和出去的流量路由上加上规则(比如,通过代理服务器)因此通常来说没有对于WebSocket信息流相关的防火墙顾虑。
kaazing Websocket网关与负载均衡路由器
第7层负载均衡路由器被置于浏览器与多个WebSocket服务器之间的关键路径时,有可能会被WebSocket协议升级请求搞糊涂。出于这个目的,运行于Kaazing WebSocket网关的服务支持伙伴负载均衡器感知,这允许负载均衡路由器被配置为WebSocket服务器的伙伴。通过这种方式,负载均衡路由器只需要处理初始的客户端请求并可以发现最佳的活动网关实例来路由信息。
一旦负载均衡路由器选择了网关实例,该网关实例就可以将浏览器转接,直接连接到该活动的网关实例。这意味着负载均衡路由器不介入真正的WebSocket流量,由此减少了延迟。然而,出现了硬件失效或网络错误的时候,客户端会自动重连到负载均衡路由器,这将会自动的将那些请求转发到另一个活动的kaazing网关实例。
Comet与代理服务器
最后,让我们来看看Comet是如何与代理服务器交互的。因为不存在Comet的标准,让我们区别来看两种不同类型的Comet实现:长轮询与流式查询。
&O 长轮询,其实现方式健壮,不会受代理服务器问题的太大影响,因为它仅仅使用HTTP请求响应模型。然而,每个请求和响应载体会有许多不必要的HTTP头信息开销和延迟。这正是HTML5 Web Sockets大展身手的地方&&它能够提供1000:1的降低不必要的网络流量和延迟。
同时请查阅:我们的桔皮书《 》,其中对于Web Sockets较遗留的Comet解决方案所能带来的显著减少不必要的网络流量提供了详尽的分析。
&O 流式查询通常比长轮询更高效,因为它在服务器上保持响应开放,并只将关键的数据通过开放连接发送给客户端。然而,这一方案会受到之前提到的代理服务器问题的影响。比如,一个代理服务器可能会缓冲响应而造成延迟。作为替代,代理服务器可以被配置为断开保持了一定时间的HTTP连接。这也是为什么大多数遗留Comet解决方案简单的使用长轮询的原因。
尽管HTML5 Web Socket协议本身并不知晓代理服务器和防火墙,但它具有HTTP兼容的握手这一特色,因此HTTP服务器可以和WebSocket服务器共享它们默认的HTTP和HTTPS端口(80和443)。一些代理服务器于Web Sockets无害并且能很好的工作,其它一些有可能妨碍Web Sockets正常工作,导致连接失败。在一些情况下可能需要一些额外的代理服务器配置,而一些特定的代理服务器可能需要被升级以支持Web Sockets。
如果一个浏览器被配置为使用显式的代理服务器(对于加密和未加密的WebSocket连接都是),那么在建立WebSocket连接时它首先会发出一个HTTP CONNECT方法到那个代理服务器。
如果使用的是一个未加密的WebSocket连接(ws://),那么在透明的代理服务器情况下,浏览器是不知道代理服务器的,所以不会发送HTTP CONNECT方法。因此,在目前的实践中连接通常会失败。
如果使用的是加密的WebSocket安全连接(wss://),那么在透明代理服务器下,浏览器不知道代理服务器,所以不会发出 HTTP CONNECT方法。然而,因为线上信息是加密的,中间透明代理服务器会简单的让加密信息通过,因此使用加密的WebSocket连接而成功建立WebSocket连接的几率就大大增加了。
kaazing WebSocket网关是高度优化的,代理感知的WebSocket网关,提供原生的WebSocket支持和针对上一代浏览器的Web Socket模拟功能。如果中间代理服务器被检测到,那么下行HTTP信息流就会使用一个高度优化的加密流式连接。这是通过Kaazing底层通过跨源的HTTP和HTTPS请求支持来实现的。在这一方面,不管是原生的或模拟的方式,我们可以通过WebSocket网关100%的建立WebSocket连接。
Peter Lubbers是Kaazing的文档和培训主管,掌控文档和培训工作的各个方面,Peter是Apress出版的《Pro HTML5 Programming》的合著者并教授HTML5培训课程。是HTML5和WebSocket的热衷者,他经常在国际活动上公开演讲。
在加入Kaazing之前,Peter是Oracle的一名信息架构师,他编写了多本书箱,包括获奖的Oracle应用服务器门户配置手册,以及Oracle应用服务器微软Office交互开发者指南。Peter同时还开发文档自动化解决方案,并获得了两项发明专利。
在加入Oracle之前,Peter架构并开发了国际化的微软Office运用专家测试框架。Peter同时还是《Pro JSF and Ajax: Building Rich Internet Components》(Apress,2006)这本书的技术审稿人。
查看英文原文:。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至。也欢迎大家加入到中与我们的编辑和其他读者朋友交流。
Author Contacted
语言 & 开发
27 他的粉丝
架构 & 设计
185 他的粉丝
50 他的粉丝
0 他的粉丝
19 他的粉丝
10 他的粉丝
0 他的粉丝
0 他的粉丝
881 他的粉丝
0 他的粉丝
0 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要,加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容,版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意:如果要修改您的邮箱,我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为:
公司性质:
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为:
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷,但为了保证InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。

我要回帖

更多关于 socket数据传输原理 的文章

 

随机推荐