精华内容
下载资源
问答
  • websocket原理

    2021-08-05 22:18:20
    websocket原理 简介:websocket是h5提供j的一种在单个tcp连接上进行的全双工双向传输的协议,最主要支持服务端主动向客户端推送消息,期间只需一次握手即可。 在websocket未诞生之前,由于http短连接,无状态的特行,...

    websocket原理

    简介:websocket是h5提供j的一种在单个tcp连接上进行的全双工双向传输的协议,最主要支持服务端主动向客户端推送消息,期间只需一次握手即可。

    在websocket未诞生之前,由于http短连接,无状态的特行,一般实时通话常用的技术是长连接和ajax轮询

    ajax轮询原理:浏览器每隔几秒发送一个请求,询问服务器是否有新消息。

    • 客户端:是否有新消息?request

    • 服务端:没有 response

    • 客户端:是否有新消息 reques

    • 服务端:有了,给你 response

    长连接原理:和ajax轮询相似,但是是阻塞式长连接,请求发给服务器后,若没有新消息则这个连接不中断,服务端不返回response,客户端一直借不到请求,则这个请求阻塞在收请求,等有新消息后服务端返回新消息给客户端,客户端再进行依次轮询。

    • 客户端:有新消息吗 ,没有就等有再发给我 request
    • 服务端:…sleep(),,,
    • 服务端:有新消息–>发送给客户端 response
    • 客户端:有新消息吗 ,没有就等有再发给我 request

    ajax轮询和长连接都是不断的建立http连接,等待服务端处理,则体现了http的另一特性:被动

    特点:ajax轮询和长连接都消耗资源较大,ajax轮询 需要服务器有很快的处理速度和资源(速度),长连接需要有很高的并发,也就是说同时接待客户的能力(场地大小),所以ajax轮询 和长连接 都有可能发生客户端请求服务端是服务端返回503错误(网站超过了系统资源限制造成的,主要是程序占用资源太多).

    websocket实现:websocket是持久化协议,websocket基于http,或者简而言之是借用http来完成一部分握手,协议中,upgrade:websocket connection:upgrade告诉服务器发起的是一个websocket协议

    • Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== base64.encode之后的值,浏览器随笔生成,用来验证是否为websocket助理
      Sec-WebSocket-Protocol: chat, superchat 用户自己定义的字符串,用来区分同url下,不同服务需要用到的协议(我要服务于谁的意思)
      Sec-WebSocket-Version: 13 协议版本,先再统一使用13版本
    websocket协议   ---->>>客户端发送请求
    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
    Origin: http://example.com
    
    服务端回复-------->>>成功建立连接
    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket        表明现在已是websocket协议	
    Connection: Upgrade
    Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=     经过服务器将客户端传会的webocket-key加密,用来验证真伪
    Sec-WebSocket-Protocol: chat   最终使用的协议
    
    • 客户端:升级建立websocket协议连接 request
    • 服务端:已经升级为websocket协议连接 response
    • 客户端:有新消息回推消息 request
    • 服务端:新消息--------->>>客户端
    • 服务端:新消息--------->>>客户端

    只需经过一次http请求就建立持久连接。

    websocket为什么他会解决服务器上消耗资源的问题呢?
    我们所用的程序是要经过两层代理,首先是服务器通过接收到的请求进行解析后来转交给应用程序处理后来返回数据给客户端。

    服务器相当于接线员,程序相当于客服,接线员速度很快,来多少个人都能准确地将电话转接给客服,但是客服处理速度很慢。导致响应速度很慢。

    而websocket相当于,有信息的时候客服将信息交给接线员,接线员再统一交给用户。这样就解决客户处理速度慢的情况。

    同时,传统http连接法,http时短连接且无状态,需要不停的建立连接关闭连接,无状态每次都需要告诉服务器你是谁,会造成转接到客服的效率下降,同时有客户端主动询问转变为服务器有消息就推送。

    缺陷:websocket在发送消息中通过网络链路中各个节点转发到目的地是一个跨越千山万水的过程,很容易在中间某个节点出现问题,可能长时间不发送消息中间节点会自主断开连接,而计算机网络协议栈的实现中又会有一层套一层的缓存,除非填满这些缓存,程序根本不会发现任何错误,这样虽然服务器在给客户端一直发送消息但是客户端时一直接收不到的。

    解决方案:让服务器和客户端能够发送 Ping/Pong Frame。这种 Frame 是一种特殊的数据包,它只包含一些元数据而不需要真正的 Data Payload,可以在不影响 Application 的情况下维持住中间网络的连接状态。

    展开全文
  • Websocket原理

    2019-09-16 15:06:45
    看完让你彻底搞懂Websocket原理 偶然在知乎上看到一篇回帖,瞬间觉得之前看的那么多资料都不及这一篇回帖让我对websocket的认识深刻有木有。所以转到我博客里,分享一下。比较喜欢看这种博客,读起来很轻松,不枯燥...

    看完让你彻底搞懂Websocket原理

    偶然在知乎上看到一篇回帖,瞬间觉得之前看的那么多资料都不及这一篇回帖让我对 websocket 的认识深刻有木有。所以转到我博客里,分享一下。比较喜欢看这种博客,读起来很轻松,不枯燥,没有布道师的阵仗,纯粹为分享。废话这么多了,最后再赞一个~

    一、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的生命周期通过 Request 来界定,也就是一个 Request 一个 Response ,那么在 HTTP1.0 中,这次HTTP请求就结束了。

    在HTTP1.1中进行了改进,使得有一个keep-alive,也就是说,在一个HTTP连接中,可以发送多个Request,接收多个Response。但是请记住 Request = Response, 在HTTP中永远是这样,也就是说一个request只能有一个response。而且这个response也是被动的,不能主动发起。

    教练,你BB了这么多,跟Websocket有什么关系呢?_(:з」∠)_好吧,我正准备说Websocket呢。。

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

    首先我们来看个典型的 Websocket 握手(借用Wikipedia的。。)

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
    Origin: http://example.com

    熟悉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轮询 不都可以实现实时信息传递么。

    好好好,年轻人,那我们来讲一讲Websocket有什么用。来给你吃点胡(苏)萝(丹)卜(红)

    三、Websocket的作用

    在讲Websocket之前,我就顺带着讲下 long poll 和 ajax轮询 的原理。

    ajax轮询

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

    场景再现:

    客户端:啦啦啦,有没有新信息(Request)

    服务端:没有(Response)

    客户端:啦啦啦,有没有新信息(Request)

    服务端:没有。。(Response)

    客户端:啦啦啦,有没有新信息(Request)

    服务端:你好烦啊,没有啊。。(Response)

    客户端:啦啦啦,有没有新消息(Request)

    服务端:好啦好啦,有啦给你。(Response)

    客户端:啦啦啦,有没有新消息(Request)

    服务端:。。。。。没。。。。没。。。没有(Response) —- loop

    long 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还是一个状态协议。

    通俗的说就是,服务器因为每天要接待太多客户了,是个健忘鬼,你一挂电话,他就把你的东西全忘光了,把你的东西全丢掉了。你第二次还得再告诉服务器一遍。

    所以在这种情况下出现了,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 轮询 来 模拟出类似的效果

    ——————–

    展开全文
  • WebSocket原理

    2020-04-08 17:32:00
    WebSocket原理 WebSocket是HTML5出的东西(协议),也就是说HTTP协议没有变化,或者说没关系,但HTTP是不支持持久连接的(长连接,循环连接的不算) 首先HTTP有1.1和1.0之说,也就是所谓的keep-alive,把多个HTTP...

    WebSocket原理

    WebSocket是HTML5出的东西(协议),也就是说HTTP协议没有变化,或者说没关系,但HTTP是不支持持久连接的(长连接,循环连接的不算)

    • 首先HTTP有1.1和1.0之说,也就是所谓的keep-alive,把多个HTTP请求合并为一个,但是Websocket其实是一个新协议,跟HTTP协议基本没有关系,只是为了兼容现有浏览器的握手规范而已,也就是说它是HTTP协议上的一种补充可以通过这样一张图理解

    Websocket是什么样的协议,具体有什么优点

    • 首先,Websocket是一个持久化的协议,相对于HTTP这种非持久的协议来说。
    • HTTP的生命周期通过Request来界定,也就是一个Request 一个Response,那么在HTTP1.0中,这次HTTP请求就结束了。
    • 在HTTP1.1中进行了改进,使得有一个keep-alive,也就是说,在一个HTTP连接中,可以发送多个Request,接收多个Response。
    • 但是请记住 Request = Response , 在HTTP中永远是这样,也就是说一个request只能有一个response。而且这个response也是被动的,不能主动发起。

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

    • 首先我们来看个典型的Websocket握手(借用Wikipedia的。。)
    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
    Origin: http://example.com
    
    • 熟悉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协议太多可是一个大难题。。不过现在还好,已经定下来啦~大家都使用的一个东西
    • 然后服务器会返回下列东西,表示已经接受到请求, 成功建立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协议进行了。

    Websocket的作用

    • 在讲Websocket之前,我就顺带着讲下 long poll 和 ajax轮询 的原理。
    • ajax轮询 的原理非常简单,让浏览器隔个几秒就发送一次请求,询问服务器是否有新信息。
    • long poll 其实原理跟 ajax轮询 差不多,都是采用轮询的方式,不过采取的是阻塞模型(一直打电话,没收到就不挂电话),也就是说,客户端发起连接后,如果没消息,就一直不返回Response给客户端。直到有消息才返回,返回完之后,客户端再次建立连接,周而复始。
    • 从上面可以看出其实这两种方式,都是在不断地建立HTTP连接,然后等待服务端处理,可以体现HTTP协议的另外一个特点,被动性。何为被动性呢,其实就是,服务端不能主动联系客户端,只能有客户端发起。
    • 我们可以看出,这两种方式都不是最好的方式,需要很多资源。一种需要更快的速度,一种需要更多的'电话'。这两种都会导致'电话'的需求越来越高。
    • Websocket解决了HTTP的这几个难题
      • 服务端就可以主动推送信息给客户端啦。
      • 解决服务器上消耗资源的问题
        • 其实我们所用的程序是要经过两层代理的,即HTTP协议在Nginx等服务器的解析下,然后再传送给相应的Handler(PHP、java等)来处理。
        • 简单地说,我们有一个非常快速的接线员(Nginx),他负责把问题转交给相应的客服(Handler)
        • 本身接线员基本上速度是足够的,但是每次都卡在客服(Handler)了,老有客服处理速度太慢。,导致客服不够。
        • Websocket就解决了这样一个难题,建立后,可以直接跟接线员建立持久连接,有信息的时候客服想办法通知接线员,然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。
        • 同时,在传统的方式上,要不断的建立,关闭HTTP协议,由于HTTP是非状态性的,每次都要重新传输identity info(鉴别信息),来告诉服务端你是谁。虽然接线员很快速,但是每次都要听这么一堆,效率也会有所下降的,同时还得不断把这些信息转交给客服,不但浪费客服的处理时间,而且还会在网路传输中消耗过多的流量/时间。但是Websocket只需要一次HTTP握手,所以说整个通讯过程是建立在一次连接/状态中,也就避免了HTTP的非状态性,服务端会一直知道你的信息,直到你关闭请求,这样就解决了接线员要反复解析HTTP协议,还要查看identity info的信息。
    展开全文
  • WebSocket 原理

    2016-05-15 09:42:06
    WebSocket 原理 转载自个人博客,转载请声明,走啊走的记录:WebSocket 原理 背景 以前的网站为了实现推送功能,使用的方法都是轮询。所谓的轮询就是在特定的时间间隔(例如1秒),由浏览器向服务器发出一个 ...

    WebSocket 原理

    转载自个人博客,转载请声明走啊走的记录:WebSocket 原理

    背景

    以前的网站为了实现推送功能,使用的方法都是轮询。所谓的轮询就是在特定的时间间隔(例如1秒),由浏览器向服务器发出一个 Http request,然后服务器返回最新的数据给客户端浏览器,从而给出一种服务端实时推送的假象。由于Http RequestHeader(请求头)很长,而传输的数据可能很短就只占一点点,每次请求消耗的带宽大部分都消耗在 Header上。从网上资料得知后来还有改进的轮询方法叫做 Comet,使用 Ajax。但这种技术虽然可达到双向通信,但依然需要发出请求,而且在Comet中,普遍采用了长链接,这也会大量消耗服务器带宽和资源。

    所以HTML5定义了 WebSocket 协议,以及相关的编程API,能更好的实现双向通信且节省服务器资源和带宽。

    注意WebSocket 实际上指的是一种协议,与我们熟知的 Http 协议是同等的一个网络协议。用网络模型结构来解释的话, WebSocketHttp 协议都属于 应用层协议,两者都基于传输层协议 TCP

    WebSocket 协议

    与HTML5的联系

    Html5是指的一系列新的API,或者说新规范,新技术。在这个新规范中定义了一个为了实现双向实时通信的新协议 WebSocket,并且提供了一套 JavaScript API 供开发者来调用实现通信。服务器端的实现由诸如:Tomcat、Jetty等等。

    与Http协议的联系

    简单概括来看: WebSocket 不是 Http 协议, Http 协议只是被 WebSocket 使用来建立 WebSocket 连接,连接建立了以后客户端与服务器的双向通信就与 Http 无关了。

    WebSocket 协议和 HTTP 协议是两种不同的东西,它们的联系如下:

    客户端开始建立 WebSocket 连接时要发送一个 header 标记了 Upgrade 的 HTTP 请求,表示请求协议升级。所以服务器端做出响应的简便方法是,直接在现有的 HTTP 服务器软件和现有的端口上实现 WebSocket 协议,重用现有代码(比如解析和认证这个 HTTP 请求。如果在 TCP 协议上实现,这两个功能就要重新实现),然后再回一个状态码为 101 的 HTTP 响应完成握手,再往后发送数据时就没 HTTP 的事了。

    作者:长天之云
    链接:https://www.zhihu.com/question/20215561/answer/14365823
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处.

    例子

    下面给出发出建立连接请求时的 requestresponse

    注意:下面的请求报文与响应报文中的内容不是完整的报文,而是 WebSocket 基于 Http 请求(响应)报文添加的内容。

    浏览器请求

    GET / HTTP/1.1
    Upgrade: websocket
    Connection: Upgrade
    Host: example.com
    Origin: null
    Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
    Sec-WebSocket-Version: 13

    服务器回应

    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
    Sec-WebSocket-Origin: null
    Sec-WebSocket-Location: ws://example.com/
    展开全文
  • 看完让你彻底搞懂Websocket原理

    万次阅读 多人点赞 2016-03-11 15:46:38
    偶然在知乎上看到一篇回帖,瞬间觉得之前看的那么多资料都不及这一篇回帖让我对websocket的认识深刻有木有。所以转到我博客里,分享一下。比较喜欢看这种博客,读起来很轻松,不枯燥,没有布道师的阵仗,纯粹为分享...
  • Websocket 原理

    2019-10-09 04:58:23
    websocket约定了一种通信规范,通过一个握手机制,客户端和服务器之间能建立一个类似tcp的连接,从而方便它们的通信。websocket出现之前,web交互一般是基于http协议的短连接或长连接。 补充:http是运行在TCP...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 26,162
精华内容 10,464
关键字:

websocket原理