socket.io 原理斟酌

import websocket
from threading import Thread
import time
import sys


class MyApp(websocket.WebSocketApp):
    def on_message(self, message):
        print(message)

    def on_error(self, error):
        print(error)

    def on_close(self):
        print("### closed ###")

    def on_open(self):
        def run(*args):
            for i in range(3):
                # send the message, then wait
                # so thread doesn't exit and socket
                # isn't closed
                self.send("Hello %d" % i)
                time.sleep(1)

            time.sleep(1)
            self.close()
            print("Thread terminating...")

        Thread(target=run).start()


if __name__ == "__main__":
    websocket.enableTrace(True)
    if len(sys.argv) < 2:
        host = "ws://echo.websocket.org/"
    else:
        host = sys.argv[1]
    ws = MyApp(host)
    ws.run_forever()

服务端接收消息流程

而服务端接收新闻并回到3个新的event为”server_response”,数据为”TEST”,代码如下,个中socketio是flask_socketio模块的SocketIO对象,它提供了装饰器方法
on将自定义的client_event和处理函数test_client_event注册到sockerio服务器的handlers中。

当收到到 client_event 消息时,会通过sockerio/server.py中的
_handle_eio_message()格局处理音讯,对于socket.io的EVENT类型的音信最后会通过_trigger_event()主意处理,该措施也正是从handlers中得到client_event对应的处理函数并调用之。

from flask_socketio import SocketIO, emit
socketio = SocketIO(...)

@socketio.on("client_event")
def test_client_event(msg):
    emit("server_response", {"data": msg["data"].upper()})
    ws = websocket.WebSocketApp("ws://echo.websocket.org/",
                              on_message = on_message,
                              on_error = on_error,
                              on_close = on_close)
    ws.on_open = on_open
    ws.run_forever()

服务端发送新闻到客户端

服务端发送消息通过
flask_socketio提供的emit方法完毕,如前一节分析的,最终依然经过的engine.io包装成engine.io的消息格式后发生。

42["server_response",{"data":"TEST"}]

短连接:

三番五次建立

第壹,客户端会发送3个polling请求来树立连接。此时的央求参数没有sid,表示要确立连接。
engine.io服务器通过handle_get_request()handle_post_request()艺术来分别处理初阶化连接以及长轮询中的
GET 和 POST 请求。

socket.io在开始化时便登记了一个事件到engine.io的handlers中,分别是connect(处理函数_handle_eio_connect),message(_handle_eio_message),disconnect(_handle_eio_disconnect),在engine.io套接字接收到了上述四个类型的音信后,在自家做了对应处理后都会触发socket.io中的对应的处理函数做尤其处理。

当接过到GET请求且未有sid参数时,则engine.io服务器会调用
_handle_connect()艺术来树立连接。这么些主意首要办事是为方今客户端生成sid,创建Socket对象并保存到engine.io服务器的sockets集合中。做了这么些开端化学工业作后,engine.io服务器会发送1个OPEN类型的数据包给客户端,接着会触发socket.io服务器的connect事件。

客户端第三次接二连三的时候,socket.io也要做一些起头化的做事,这是在socket.io服务器的_handle_eio_connect()处理的。那里做的工作要害有几点:

  • 开端化manager,比如用的是redis做后端队列的话,则必要起初化redis_manager,包罗安装redis连接配置,订阅频道,暗许频道是”socket.io”,即便选用flask_socketio则频道是”flask_socketio”,如若用到gevent,则还要对redis模块的socket库打monkey-patch等。

  • 将该客户端参加到暗中认可房间None,sid中。

  • 调用代码中对connect事件注册的函数。如下边那一个,注意下,socket.io中也有个用于事件处理的handlers,它保存的是在后端代码中对socket.io事件注册的函数(开发者定义的),而engine.io的handlers中保存的函数是socket.io注册的那四个针对connect,message和disconnect事件的固化的处理函数。

    socketio.on("connect")
    def test_connect():
        print "client connected"
    
  • 出殡二个sockeio的connect数据包给客户端。

末段在响应中engine.io会为客户端设置三个名字为io值为sid的cookie,响应内容payload包括五个数据包,二个是engine.io的OPEN数据包,内容为sid,pingTimeout等配置和参数;另二个是socket.io的connect数据包,内容为40。个中4代表的是engine.io的message音讯,0则意味着socket.io的connect消息,以字节流回到。那里的pingTimeout客户端和服务端共享这几个布局,用于检查实验对端是还是不是过期。

继之会发送贰个轮询请求和websocket握手请求,假若websocket握手成功后客户端会发送2 probe探测帧,服务端回应3 probe,然后客户端会发送内容为5的Upgrade帧,服务端回应内容为6的noop帧。探测帧检查通过后,客户端截止轮询请求,将传输通道转到websocket连接,转到websocket后,接下去就从头为期(暗许是贰五秒)的
ping/pong(那是socket.io自定义的ping/pong,除却,uwsgi也会定期(暗中认可30秒)对客户端ping,客户端回应pong,这几个在chrome的Frames里面是看不到的,需求信赖wireshark恐怕用其它浏览器插件来考查)。

 

关门连接

客户端要百尺竿头更进一步关闭连接,在JS中调用 socket.close()
即可,此时发送的数额包为
41,在那之中四表示的是engine.io的音信类型message,而数据一则是指的socket.io的音讯类型disconnect,关闭流程见上一章的认证。

安装

客户端发送新闻给服务端

要是要发送新闻给服务器,在浏览器输入框输入test,点击echo按钮,能够看来websocket发送的帧的始末如下,当中4是engine.io的message类型标识,二是socket.io的EVENT类型标识,而后面则是事件名称和数量,数据足以是字符串,字典,列表等类型。

42["client_event",{"data":"test"}]

(2)header:
客户发送websocket握手请求的请求头,{‘head一:value1′,’head二:value二’}。

3 engine.io和socket.io

近年来提到socket.io是基于engine.io的包装,engine.io(协议版本三)有1套自身的合计,任何engine.io服务器都不可能不帮助polling(包蕴jsonp和xhr)和websocket三种传输格局。engine.io使用websocket时有一套自个儿的ping/pong机制,使用的是opcode为0x一(Text)类型的数据帧,不是websocket共同商议明确的ping/pong类型的帧,标准的
ping/pong 帧被uwsgi使用

engine.io的数据编码分为Packet和Payload,当中 Packet是数据包,有陆体系型:

  • 0 open:从服务端发出,标识二个新的传输格局已经打开。
  • 壹 close:请求关闭那条传输连接,然则它本身并不闭馆那几个接二连三。
  • 2ping:客户端周期性发送ping,服务端响应pong。注意这一个与uwsgi自带的ping/pong不一致,uwsgi里面发送ping,而浏览器重回pong。
  • 3 pong:服务端发送。
  • 四 message:实际发送的音信。
  • 五upgrade:在转换transport前,engine.io会发送探测包测试新的transport(如websocket)是不是可用,假如OK,则客户端会发送3个upgrade新闻给服务端,服务端关闭老的transport然后切换来新的transport。
  • 6noop:空操作数据包,客户端收到noop新闻会将事先等待暂停的轮询暂停,用于在吸收接纳到贰个新的websocket强制七个新的轮询周期。

而Payload是指壹多级绑定到联合的编码后的Packet,它只用在poll中,websocket里面使用websocket帧里面包车型客车Payload字段来传输数据。假设客户端不帮助XHTiguan2,则payload格式如下,当中length是数据包Packet的长度,而packet则是编码后的数额包内容。

<length1>:<packet1>[<length2>:<packet2>[...]]

若支持XH凯雷德2,则payload中内容总体以2进制编码,当中第①位0表示字符串,一意味贰进制数据,而前面跟着的数字则是象征packet长度,然后以\xff结尾。借使2个长短为十九的字符类型的数据包,则前面长度编码是
\x00\x01\x00\x09\xff,然后后边接packet内容。

<0 for string data, 1 for binary data><Any number of numbers between 0 and 9><The number 255><packet1 (first type,
then data)>[...]

engine.io服务器维护了二个socket的字典结构用于管理总是到该机的客户端,而客户端的标识正是sid。即使有七个worker,则供给确认保障同三个客户端的连天落在同样台worker上(能够配备nginx依照sid分发)。因为各类worker只保证了1局部客户端连接,要是要扶助广播,room等风味,则后端须要选取redis 可能 RabbitMQ
音讯队列,使用redis的话则是通过redis的订阅发表机制完成多机多worker之间的音信推送。

socket.io是engine.io的卷入,在其基础上增添了自动重连,多路复用,namespace,room等特色。socket.io本人也有壹套协议,它Packet类型分为(CONNECT 0, DISCONNECT 1, EVENT 2, ACK 3, ERROR 4, BINARY_EVENT 5, BINARY_ACK 6)。注意与engine.io的Packet类型有所区别,不过socket.io的packet实际是注重的engine.io的Message类型发送的,在末端实例中能够见到Packet的编码方式。当连接出错的时候,socket.io会通过自行重连机制再一次连接。

——

6 总结

正文示例中,为了有利于分析,只用了默许的namespace和room,而在实际上项目中能够依照工作要求运用namespace,room等高级天性。

nginx+uwsgi应用socket.io时,当用到websocket时,注意nginx的逾期配置proxy_read_timeout和uwsgi的websocket超时配置websocket-ping-freq和websockets-pong-tolerance,配置不当会招致socke.io因为websocket的ping/pong超时而不止重连。

        if not ping_timeout or ping_timeout <= 0:
            ping_timeout = None
        if ping_timeout and ping_interval and ping_interval <= ping_timeout:
            raise WebSocketException("Ensure ping_interval > ping_timeout")

服务端新闻发送流程

而服务端要给客户端发送音信,则要求经过socket.io服务器的emit方法,注意emit方法是指向room来发送音信的,假设是context-aware的,则emit暗许是对namespace为/且room名称叫sid的房间发送,假使是context-free的,则默许是广播即对拥有连接的客户端发送音讯(当然在context-free的风貌下边,你也得以钦赐room来只给钦命room推送音讯)。

socket.io要落到实处多进度以及广播,房间等功能,势必须求连接二个redis之类的音信队列,进而socket.io的emit会调用对应队列管理器pubsub_manager的emit方法,比如用redis做新闻队列则最后调用
redis_manager中的_publish()
方法通过redis的订阅公布成效将音信推送到flask_socketio频道。另一方面,全数的socket在一连时都订阅了
flask_socketio频道,而且都有二个体协会程(或线程)在监听频道中是还是不是有消息,1旦有新闻,就会调用pubsub_manager._handle_emit()方法对本机对应的socket发送对应的音讯,最后是因此socket.io服务器的_emit_internal()艺术实现对本机中room为sid的兼具socket发送消息的,假设room为None,则正是广播,即对富有连接到本机的保有客户端推送音信。

socket.io服务器发送音信要基于engine.io音信包装,所以总结到底如故调用的engine.io套接字中的send()主意。engine.io为种种客户端都会维护三个音信队列,发送数据都以先存到行列之中待拉取,websocket除了探测帧之外的任何数据帧也都以由此该消息队列发送。

 

服务端音信接收流程

对吸收音讯的则统一通过engine.io套接字的receive()函数处理:

  • 对于轮询,壹旦接收了polling的POST请求,则会调用receive往该socket的消息队列之中发送新闻,从而释放此前hang住的GET请求。
  • 对于websocket:
    • 接受了ping,则会即时响应3个pong。
    • 吸收到了upgrade新闻,则即时发送二个noop新闻。
    • 收起到了message,则调用socket.io注册到engine.io的_handle_eio_message措施来处理socket.io本身定义的种种新闻。

 

确立连接

在chrome中开拓页面可以见见发了一个请求,分别是:

1 http://127.0.0.1/socket.io/?EIO=3&transport=polling&t=MAkXxBR
2 http://127.0.0.1/socket.io/? EIO=3&transport=polling&t=MAkXxEz&sid=9c54f9c1759c4dbab8f3ce20c1fe43a4
3 ws://127.0.0.1/socket.io/?EIO=3&transport=websocket&sid=9c54f9c1759c4dbab8f3ce20c1fe43a4

请求暗许路径是/socket.io,注意命名空间并不会在途径中,而是在参数中传送。第1个请求是polling,EIO是engine.io协议的版本号,t是一个4意字符串,第二个请求时还还平素不生成sid。服务端接收到信息后会调用engine.io/server.py_handle_connect()树立连接。

回到的结果是

## Response Headers: Content-Type: application/octet-stream ##
�ÿ0{"pingInterval":25000,"pingTimeout":60000,"upgrades":["websocket"],"sid":"9c54f9c1759c4dbab8f3ce20c1fe43a4"}�ÿ40

能够看到,那里重返的是字节流的payload,content-type为”application/octet-stream”。这一个payload其实包罗五个packet,首个packet是engine.io的OPEN音信,类型为0,它的始末为pingInterval,pingTimeout,sid等;第二个packet类型是4(message),而它的数目内容是0,表示socket.io的CONNECT。而内部的看起来乱码的1对其实是眼下提到的payload编码中的长度的编码\x00\x01\x00\x09\xff\x00\x02\xff

  • 第1个请求是轮询请求,假设websocket建立并测试成功(使用内容为probe的ping/pong帧)后,会搁浅轮询请求。能够看到轮询请求一向hang住到websocket建立并测试成功后才回到,响应结果是�ÿ6,后边乱码部分是payload长度编码\x00\x01\xff,前面包车型客车数字陆是engine.io的noop音信。

  • 第四个请求是websocket握手请求,握手成功后,能够在chrome的Frames中间来看websocket的数目帧交互流程,能够看出如前方分析,确实是首发的探测帧,然后是Upgrade帧,接着正是定期的ping/pong帧了。

    2probe
    3probe
    5
    2
    3
    ...
    

 长连接,参数介绍:

在项目中用到socket.io狠抓时推送,遂花了点时间看了socket.io完成,做个不难解析,如有错漏,欢迎指正。

ping_interval:自动发送“ping”命令,各种钦赐的年华(秒),假诺设置为0,则不会自动发送。

1 概述

socket.io是贰个基于WebSocket的CS的实时通信库,它底层基于engine.io。engine.io使用WebSocket和xhr-polling(或jsonp)封装了一套本人的商议,在不扶助WebSocket的低版本浏览器中(援救websocket的浏览器版本见这里)使用了长轮询(long
polling)来代表。socket.io在engine.io的底蕴上加码了namespace,room,自动重连等天性。

正文接下去会先不难介绍websocket协议,然后在此基础上上课下engine.io和socket.io协议以及源码分析,后续再经过例子表达socket.io的行事流程。

 

参考资料

  • https://tools.ietf.org/html/rfc6455
  • https://www.nginx.com/blog/websocket-nginx/
  • https://security.stackexchange.com/questions/36930/how-does-websocket-frame-masking-protect-against-cache-poisoning
  • https://github.com/suexcxine/blog/blob/master/source/\_posts/websocket.md
  • https://github.com/abbshr/abbshr.github.io/issues/47
  • https://socket.io/docs/logging-and-debugging/
  • http://uwsgi-docs.readthedocs.io/en/latest/WebSockets.html
  • https://flask-socketio.readthedocs.io/en/latest/

(4)on_message:那几个指标在收取到服务器重返的消息时调用。有八个参数,三个是此类自个儿,1个是大家从服务器获取的字符串(utf-捌格式)。

5 实例

切磋表明简单令人某些头晕,websocket,engine.io,socket.io,各自行车运动组织议是如何行事的,看看实例只怕会比较清晰,为了便于测试,笔者写了个Dockerfile,安装了docker的童鞋能够拉取代码执行
bin/start.sh 即可运转拥有完全的
nginx+uwsgi+gevent+flask_socketio测试环境的器皿起先测试,浏览器打开http://127.0.0.1即可测试。async_mode用的是gevent_uwsgi,完整代码见
这里。

对于不协理websocket的低版本浏览器,socket.io会退化为长轮询的法子,通过为期的发送GET,
POST请求来拉取数据。未有数据时,会将呼吁数据的GET请求hang住,直到服务端有多少发生只怕客户端的POST请求将GET请求释放,释放之后会随之再度发送2个GET请求,除了那几个之外,协议分析和拍卖流程与websocket格局基本一致。实例只针对使用websocket的开始展览解析

为了调查socket.io客户端的调用流程,可以设置localStorage.debug = '*';,测试的前段代码片段如下(完整代码见仓库):

 <script type="text/javascript" charset="utf-8">
    var socket = io.connect('/', {
        "reconnectionDelayMax": 10000,
        "reconnectionAttempts": 10
    });
    socket.on('connect', function() {
        $('#log').append('<br>' + $('<div/>').text('connected').html());
    })

    $(document).ready(function() {

        socket.on('server_response', function(msg) {
            $('#log').append('<br>' + $('<div/>').text('Received from server: ' + ': ' + msg.data).html());
        });

        $('form#emit').submit(function(event) {
            socket.emit('client_event', {data: $('#emit_data').val()});
            return false;
        });
    });

 </script>

测试代码相比较简单,引进socket.io的js库文件,然后在连接成功后在页面呈现“connected”,在输入框输入文字,能够透过接二连三发送至服务器,然后服务器将浏览器发送的字符串加上server标识回显回来。

示例2:

四 源码分析

在建立连接后,每种socket会被自动进入到四个暗许的命名空间/。在每种命名空间中,socket会被暗中认可参预多个名称叫Nonesid的屋子。None的屋子用于广播,而sid是时下客户端的session
id,用于单播。除默许的屋子外,大家得以依据需求将对应socket参与自定义房间,roomid唯1即可。socket.io基于engine.io,接济websocket和long
polling。假使是long polling,会定时发送GET,
POST请求,当未有数量时,GET请求在拉取队列音信时会hang住(超时时间为ping提姆eout),假使hang住中间服务器向来尚未数据爆发,则须求等到客户端发送下1个POST请求时,此时服务器会往队列中贮存POST请求中的新闻,那样上2个GET请求才会回去。如若upgrade到了websocket连接,则会定期ping/pong来保活连接。

为便于描述,上边提到的engine.io服务器对应源文件是engineio/server.py,engine.io套接字对应源文件engineio/socket.py,而socket.io服务器则对应socketio/server.py。上面分析下socket.io连接建立、音信接收和发送、连接关闭进度。socket.io版本为壹.九.0,engine.io版本为2.0.肆。

python
websocket

关闭连接(只分析websocket)

websocket可能尤其关闭的景况多多。比如客户端发了ping后等待pong超时关闭,服务端接收到ping跟上多少个ping之间超过了pingTimeout;用的uwsgi的话,uwsgi发送ping,假诺在websockets-pong-tolerance(默许3秒)内接收不到pong回应,也会关闭连接;还有假设nginx的proxy_read_timeout配置的比pingInterval小等。

要是否客户端主动关闭连接,socket.io就会在一而再出错后不断重试以建立连接。重试间隔和重试次数由reconnectionDelayMax(默认5秒)reconnectionAttempts(暗中同意一向重连)设定。上边钻探客户端平常关闭的事态,种种分外关闭状态请具体情状具体分析。

客户端主动关闭

设若客户端调用socket.close()百尺竿头更进一步关闭websocket连接,则会头阵送多少个消息41(肆:engine.io的message,壹:socket.io的disconnect)再关闭连接。如前方提到,engine.io套接字接收到信息后会交给socket.io服务器注册的
_handle_eio_message()拍卖。最终是调用的socket.io的_handle_disconnect(),该函数工作包含调用socketio.on("disconnect")挂号的函数,将该客户端从出席的房间中移除,清理环境变量等。

uwsgi而接受到客户端关闭websocket连接音信后会关闭服务端到客户端的接连。engine.io服务器的websocket数据接受例程ws.wait()因为一连关闭报IOError,触发服务端循环收发数据经过甘休,并从尊敬的sockets集合中移除那一个闭馆的sid。然后调用engine.io套接字的close(wait=True, abort=True)措施,由于是客户端主动关闭,那里就不会再给客户端发送三个CLOSE消息。而
engine.io服务器的close方法一致会触发socket.io以前注册的disconnect事件处理函数,由于前面已经调用_handle_disconnect()拍卖了倒闭连接事件,所以那边_handle_eio_disconnect()不须求再做别的操作(这些操作不是剩下的,其效力见后一节)。

浏览器关闭

直白关门浏览器发送的是websocket的标准CLOSE新闻,opcode为捌。socket.io服务端处理格局基本一致,由于这种状态下并不曾发送socket.io的闭馆音讯41,socket.io的关门操作须求等到engine.io触发的_handle_eio_disconnect()中拍卖,那正是前一节中为什么engine.io服务器后边还要多调用一回
_handle_eio_disconnect()的缘由所在。

ping的晚点时间,要压倒ping间隔时间

2 WebSocket协议

咱俩理解,在HTTP 协议开发的时候,并不是为着双向通讯程序准备的,起首的
web 应用程序只须求 “请求-响应”
就够了。由于历史原因,在创立拥有双向通讯机制的 web
应用程序时,就只可以选择 HTTP 轮询的章程,由此产生了 “短轮询” 和
“长轮询”(注意区分短连接和长连接)。

短轮询通过客户端定期轮询来明白服务端是还是不是有新的消息发生,缺点也是醒目,轮询间隔大了则音讯不够实时,轮询间隔过小又会开支过多的流量,扩展服务器的承担。长轮询是对短轮询的优化,必要服务端做相应的修改来帮忙。客户端向服务端发送请求时,借使这时候服务端未有新的音信发生,并不霎时回去,而是Hang住1段时间等有新的消息照旧逾期再回到,客户端收到服务器的对答后继续轮询。能够见见长轮询比短轮询能够减掉大气不行的伸手,并且客户端接收取新新闻也会实时不少。

就算长轮询比短轮询优化了广大,但是每一趟请求仍旧都要带上HTTP请求底部,而且在长轮询的连天达成之后,服务器端积累的新音讯要等到下次客户端连接时才能传递。越来越好的艺术是只用3个TCP连接来贯彻客户端和服务端的双向通讯,WebSocket商业事务就是为此而生。WebSocket是基于TCP的二个独门的商业事务,它与HTTP协议的唯1涉及正是它的握手请求可以视作二个Upgrade request历经HTTP服务器解析,且与HTTP使用相同的端口。WebSocket暗中认可对普通请求使用80端口,协议为ws://,对TLS加密请求使用4四叁端口,协议为wss://

拉手是经过1个HTTP Upgrade request初始的,1个伸手和响应尾部示例如下(去掉了毫无干系的头顶)。WebSocket握手请求尾部与HTTP请求底部是卓殊的(见奔驰G级FC261六)。

## Request Headers ##
Connection: Upgrade
Host: socket.io.demo.com
Origin: http://socket.io.demo.com
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: mupA9l2rXciZKoMNQ9LphA==
Sec-WebSocket-Version: 13
Upgrade: websocket

## Response Headers ##
101 Web Socket Protocol Handshake
Connection: upgrade
Sec-WebSocket-Accept: s4VAqh7eedG0a11ziQlwTzJUY3s=
Sec-WebSocket-Origin: http://socket.io.demo.com
Server: nginx/1.6.2
Upgrade: WebSocket
  • Upgrade
    是HTTP/一.第11中学明确的用来转移当前连连的应用层协议的头顶,表示客户端希望用现有的连日转换到新的应用层协议WebSocket协议。

  • Origin
    用于幸免跨站攻击,浏览器一般会接纳那些来标识原始域,对于非浏览器的客户端应用能够根据供给接纳。

  • 请求头中的 Sec-WebSocket-Version
    是WebSocket版本号,Sec-WebSocket-Key
    是用于握手的密钥。Sec-WebSocket-Extensions 和 Sec-WebSocket-Protocol
    是可挑选,暂不探究。

  • 1呼百应头中的 Sec-WebSocket-Accept 是将请求头中的 Sec-WebSocket-Key
    的值加上一个永恒魔数258EAFA5-E914-47DA-95CA-C5AB0DC85B11经SHA壹+base6四编码后拿走。总计进度的python代码示例(uwsgi中的达成见
    core/websockets.c的 uwsgi_websocket_handshake函数):

    magic_number = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
    key = 'mupA9l2rXciZKoMNQ9LphA=='
    accept = base64.b64encode(hashlib.sha1(key + magic_number).digest())
    assert(accept == 's4VAqh7eedG0a11ziQlwTzJUY3s=')
    
  • 客户端会检查响应头中的status code 和 Sec-WebSocket-Accept
    值是还是不是是期待的值,假诺发现Accept的值不科学可能状态码不是拾壹,则不会树立WebSocket连接,也不会发送WebSocket数据帧。

WebSocket磋商使用帧(Frame)收发数据,帧格式如下。基于有惊无险考虑衡量,客户端发送给服务端的帧必须通过四字节的掩码(Masking-key)加密,服务端收到新闻后,用掩码对数据帧的Payload
Data实行异或运算解码得到数码(详见uwsgi的 core/websockets.c
中的uwsgi_websockets_parse函数),借使服务端收到未经掩码加密的数据帧,则应当即刻关闭该WebSocket。而服务端发给客户端的数额则不须求掩码加密,客户端假若接到了服务端的掩码加密的数目,则也亟须关闭它。

 0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     +---------------------------------------------------------------+

帧分为控制帧和数据帧,控制帧不能够分片,数据帧能够分片。首要字段表明如下:

  • FIN:
    未有分片的帧的FIN为一,分片帧的第3个分片的FIN为0,最后三个分片FIN为一。
  • opcode: 帧类型编号,在那之中央控制制帧:0x八 (Close), 0x九 (Ping), and 0xA
    (Pong),数据帧首要有:0x一 (Text), 0x二 (Binary)。
  • MASK:客户端发给服务端的帧MASK为一,Masking-key为加密掩码。服务端发往客户端的MASK为0,Masking-key为空。
  • Payload len和Payload Data分别是帧的数目长度和数目内容。

 

from websocket import create_connection
ws = create_connection("ws://echo.websocket.org/")
print("Sending 'Hello, World'...")
ws.send("Hello, World")
print("Sent")
print("Receiving...")
result =  ws.recv()
print("Received '%s'" % result)
ws.close()

 

 

(1一)subprotocols:一组可用的子协议,暗许为空。

长连接:

(10)get_mask_key:用于发生二个掩码。

长连接首要办法:ws.run_forever(ping_interval=60,ping_timeout=5)

相关文章