websocket工作原理,websocket 详解

  websocket工作原理,websocket 详解

  http://blog..net/frank_good/article/details/50856585

  偶然在知乎上看到一个回复,瞬间觉得之前看的那么多资料都不如这个回复,让我对websocket有了深刻的认识。所以去我的博客分享一下吧。我更喜欢看这类博客。读起来很轻松,不枯燥,也没有布道者之战,只是为了分享。废话那么多,给你最后一个赞~

  1.websocket和http

  WebSocket是HTML5的一个产品(协议),也就是说HTTP协议没变,或者说没关系,但是HTTP不支持持久连接(长连接,循环连接不算)。

  首先,HTTP有1.1和1.0,即所谓的keep-alive,将多个HTTP请求合二为一。不过Websocket其实是一个新的协议,基本上和HTTP协议没什么关系,只是为了兼容现有浏览器的握手规范。也就是说它是对HTTP协议的补充,从这样一个图就可以理解。

  有交集,但不是全部。

  另外,Html5指的是一系列新的API,或者说新的规范和技术。Http协议本身只有1.0和1.1,和Html本身没有直接关系。一般来说,可以用HTTP协议传输非Html数据,就是这样=。=

  简单来说就是层次不同。

  二、Websocket是一种什么样的协议,具体有什么优势?

  首先,Websocket是一个持久性协议,相对于非持久性协议HTTP。我们举个简单的例子,用目前广泛使用的PHP生命周期来解释。

  HTTP的生命周期是由请求定义的,即一个请求和一个响应,所以在HTTP1.0中,这个HTTP请求就结束了。

  在HTTP1.1中,它被改进为具有keep-alive,即在一个HTTP连接中,可以发送多个请求并接收多个响应。但是请记住Request=Response,在HTTP中总是这样,也就是说一个请求只能有一个响应。而且这种反应是被动的,不能主动发起。

  蔻驰,你BB这么多,跟Websocket有什么关系?_(:“)_嗯,我正要说Websocket。

  首先,Websocket是基于HTTP协议的,或者说是借用HTTP协议来完成一些握手。

  首先,我们来看一个典型的Websocket握手(借用维基百科。)

  获取/聊天HTTP/1.1

  主持人:server.example.com

  升级:websocket

  连接:升级

  sec-web socket-Key:x3jjhmbdl 1 ezlkh 9 gbhxdw==

  sec-web socket-协议:聊天,超级聊天

  sec-web socket-版本:13

  产地:http://example.com

  熟悉HTTP的童鞋可能已经发现,这个握手请求中类似HTTP协议的东西还多了几个。我顺便解释一下功能。

  升级:websocket

  连接:升级

  这是Websocket的核心。告诉Apache、Nginx等服务器:注意,我发起了Websocket协议。请帮我找相应的助手快速处理~不是那么老套的HTTP。

  sec-web socket-Key:x3jjhmbdl 1 ezlkh 9 gbhxdw==

  sec-web socket-协议:聊天,超级聊天

  sec-web socket-版本:13

  首先Sec-Websocket-Key是Base64 encode的一个值,由浏览器随机生成。告诉服务器:泥炭,别糊弄窝。我想验证一下Tony是不是真的是WebSocket助手。

  然后,Sec_WebSocket-Protocol是一个自定义字符串,用来区分同一URL下不同服务所需的协议。简单理解:今晚我要去服A,别搞错了~

  最后,Sec-Websocket-Version告诉服务器使用的是哪个Websocket草案(协议版本)。当初Websocket协议还在草案阶段,有各种奇怪的协议,有很多奇怪的东西,比如Firefox和Chrome用不同的版本。起初,太多的WebSocket协议是一个大问题。不过现在好了,解决了~大家都用的东西~脱水:服务员,我要一个13岁的哦_

  然后服务器会返回如下,表示请求已经收到,Websocket已经成功建立!

  HTTP/1.1 101交换协议

  升级:websocket

  连接:升级

  sec-web socket-Accept:hsmrc 0 smlyukagmm 5 oppg 2 hag wk=

  sec-web socket-协议:聊天

  这里是HTTP最后负责的区域。告诉客户我已经成功切换协议了~

  升级:websocket

  连接:升级

  它仍然是固定的,告诉客户端Websocket协议即将升级,而不是mozillasocket、lurnarsocket或shitsocket。

  那么,Sec-WebSocket-Accept就是已经被服务器确认并加密的Sec-WebSocket-Key。服务器:好,好,我知道了。我给你看我的身份证证明一下。

  后来Sec-WebSocket-Protocol就是最后要用的协议。

  至此,HTTP已经完成了所有的工作,接下来就完全按照Websocket协议进行了。具体协议这里就不细说了。

  3354————,技术分析部分讲完了,33543333333334

  你BBB了这么久,Websocket到底有什么用?http长轮询或ajax轮询可以实现实时信息传输。

  好了,小伙子,我们来谈谈Websocket的使用。来,我给你一些胡(苏)罗(丹)布(红)

  第三,Websocket的作用

  在讲Websocket之前,我先讲一下长轮询和ajax轮询的原理。

  Ajax轮询

  ajax轮询的原理很简单,浏览器每隔几秒就发送一个请求,询问服务器是否有新的信息。

  客户:啦啦啦,有没有新的信息(请求)

  服务器:你这么烦,没有。(回应)

  客户:啦啦啦,有什么新消息(请求)吗?

  服务员:好的,好的,给你。(回应)

  客户:啦啦啦,有什么新消息(请求)吗?

  服务器:没有。没有。否(响应)——循环

  长轮询

  其实长轮询的原理和ajax轮询类似,都是采用轮询的方式,只是采用的是阻塞模式(一直打,没收到就别挂)。也就是说,客户端发起连接后,如果没有消息,就永远不会向客户端返回响应。直到有消息才返回。返回后,客户端再次建立连接,如此循环往复。

  场景再现:

  客户:啦啦啦,你有什么新消息吗?如果没有,请等到你有了再还给我(要求)

  服务器:金额。等待消息。给你(回应)

  客户:啦啦啦,有什么新消息吗?如果没有,就等你有了,再还给我(请求)-循环

  从上面可以看出,其实这两种方法都是不断建立HTTP连接,然后等待服务器处理,这可以体现HTTP协议的另一个特点,被动性。

  什么是被动?实际上,服务器无法主动联系客户端,只有客户端才能发起。

  简单来说,服务器就是个懒冰箱(是个梗)(不会,不能主动发起连接),但是老板有命令,如果有客户来了,不管多累都要好好接待。

  之后,让我们来谈谈上述缺陷(原谅我说了这么多废话OAQ)

  从上面很容易看出来。无论如何,以上两种都是非常耗费资源的。

  Ajax轮询要求服务器具有快速的处理速度和资源。(速度)长轮询需要有高并发,也就是同时接待客户的能力。(网站大小)

  因此,ajax轮询和长轮询都可能发生。

  客户:啦啦啦啦,有新消息吗?

  服务器:月线忙,请稍后再试(503服务器不可用)

  客户端:好吧,啦啦啦,有新消息吗?

  服务器:月线忙,请稍后再试(503服务器不可用)

  客户端:然后服务器端忙的要死:冰箱,我要更多的冰箱!更多。更多。我错了。这又是梗。)

  无论如何,我们来谈谈Websocket。

  从上面的例子我们可以看出,这两种方法都不是最好的,都需要大量的资源。

  一个需要更快的速度,一个需要更多的‘电话’。两者都会导致对‘电话’的需求越来越高。

  哦,对了,我忘了说HTTP还是有状态协议。

  通俗地说,服务器就是一个健忘鬼,因为它每天接收的客户端太多了。你一挂电话,他就把你的东西全忘了,把你的东西全扔了。第二次你得再告诉服务器一次。

  所以在这种情况下,Websocket出现了。他解决了HTTP的这些问题。首先是被动性,当服务器完成协议升级(HTTP- Websocket)时,服务器可以主动向客户端推送信息。所以上面的场景可以修改如下。

  客户端:啦啦啦啦,我想建立Websocket协议,需要的服务:聊天,Websocket协议版本:17(HTTP请求)

  服务器:好的,确认,已经升级到Websocket协议(HTTP协议切换)。

  客户:有信息请推给我。

  服务器:好的,我有时候会告诉你。

  服务器:巴拉巴拉巴拉

  服务器:巴拉巴拉巴拉

  服务器:哈哈哈哈哈哈哈哈哈

  服务器:笑死我了。哈哈哈哈哈哈哈哈。

  变成了这样,只需要一个HTTP请求就可以实现源源不断的信息传输。(在编程中,这种设计叫回调,就是当你有信息的时候,请通知我,而不是每次都傻傻的问你。)

  该协议解决了同步延迟和消耗大量资源的问题。那么他为什么要解决服务器上的资源消耗问题呢?

  其实我们用的程序要经过两层代理,也就是HTTP协议由Nginx等服务器解析,然后传输到相应的Handler(PHP等。)进行处理。简单来说,我们有一个非常快的接线员(Nginx),负责把问题转给相应的客服(处理员)。

  运营商自己的速度基本够用,但是每次卡在客服(处理员)那里,客服总是处理的太慢。导致客户服务不足。Websocket解决了这样一个问题。建立后,它可以直接与运营商建立永久连接。有信息的时候,客服会想办法通知运营商,然后运营商统一转给客户。

  这样就解决了客服处理速度慢的问题。

  同时,在传统的方式下,需要不断地建立和关闭HTTP协议。因为HTTP是非状态的,所以每次都要重新传输身份信息,告诉服务器你是谁。

  虽然接线员速度很快,但是每次都要听这样一堆,效率就会降低。同时,他还要不断地将这些信息传递给客服,不仅浪费了客服的处理时间,也耗费了太多的网络传输流量/时间。

  而Websocket只需要一次HTTP握手,所以整个通信过程都是在一个连接/状态下建立的,避免了HTTP的无状态。服务器会一直知道你的信息,直到你关闭请求,这样就解决了运营商要反复分析HTTP协议,检查身份信息的信息的问题。

  同时客户端会主动询问,有空就转化为服务器(push)发送信息(当然客户端会等待主动发送信息。),没有资料的时候交给运营商(Nginx),这样就没必要占用慢客服(Handler)了。

  ——————

  至于如何在不支持Websocket的客户端上使用Websocket。答案是:不会。

  但是类似的效果可以通过上面提到的长轮询和ajax轮询来模拟。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: