【转】websocket协议规范

在线版目录:

1.引言——WebSocket协议翻译

2.一致性要求——WebSocket协议翻译

3.WebSocket URI——WebSocket协议翻译

4.打开阶段握手——WebSocket协议翻译

5.数据帧——WebSocket协议翻译

6.发送和接收数据——WebSocket协议翻译

7.关闭连接——WebSocket协议翻译

8.错误处理——WebSocket协议翻译

9.扩展——WebSocket协议翻译

10.安全注意事项——WebSocket协议翻译

11. IANA考虑——WebSocket协议翻译

12.其他规范使用WebSocket协议——WebSocket协议翻译

13.致谢——WebSocket协议翻译

14.参考资料——WebSocket协议翻译

 

英文版

http://tools.ietf.org/html/rfc6455

 

Introduction

很多网站为了实现实时推送技术,会采用轮询(polling)的方法:在特定的时间间隔内(如1s),由Client对Server发起Http Request,然后由Server返回最新的数据给Client。这种方法需要Client不停的向Server发起请求,然而HTTP Request Header是非常长的,会浪费带宽和服务器资源。
HTML5 定义了WebSocket协议(下面简称WS),用于实现一种全双工的通信方式。
 
WS可以分为两个阶段:
1、握手阶段(在建立TCP连接之后);
2、数据传输阶段;
 
 

Websocket的握手过程比较简单:
Client给Server发一个Http Request,Server给Client回一个Http Response,即握手阶段是基于HTTP协议的。
 
WS握手的一个例子:
Client Request
Connection:Upgrade
Host:echo.websocket.org
Origin:http://websocket.org
Sec-WebSocket-Key:ov0xgaSDKDbFH7uZ1o+nSw==
Sec-WebSocket-Version:13
Upgrade:websocket 
 
其中,
Connection头的作用是与Server协商,我们别用HTTP了,改用WS协议吧;
Sec-WebSocket-Key头是Client产生的一串随机数,然后base64之后填进去的;
Sec-WebSocket-Version头指WS协议的版本;
 
Server Response
HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Date:Sun, 29 Jan 2012 18:05:49 GMT
Sec-WebSocket-Accept:7vI97qQ5QRxq6lD6E5RRX36mOBc=
Server:jetty
Upgrade:websocket
 
其中,
Connection头的作用是告诉Client,同意采用WS协议;
Sec-WebSocket-Accept头是根据Sec-WebSocket-Key计算出来的值,计算方法如下:
BASE64( SHA1( ${Sec-WebSocket-Key} + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" ) )
 

握手成功后,进入数据流阶段,这个阶段和HTTP协议就没什么关系了。
下面是ws协议传输的数据格式:
 
      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 ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+
 
 
说明:

FIN:1位,用来表明这是一个消息的最后的消息片断,当然第一个消息片断也可能是最后的一个消息片断;

RSV1, RSV2, RSV3: 分别都是1位,如果双方之间没有约定自定义协议,那么这几位的值都必须为0,否则必须断掉WebSocket连接;

Opcode:4位操作码,定义有效负载数据,如果收到了一个未知的操作码,连接也必须断掉,以下是定义的操作码:
* %x0 表示连续消息片断
* %x1 表示文本消息片断
* %x2 表未二进制消息片断
* %x3-7 为将来的非控制消息片断保留的操作码
* %x8 表示连接关闭
* %x9 表示心跳检查的ping
* %xA 表示心跳检查的pong
* %xB-F 为将来的控制消息片断的保留操作码

Mask:1位,定义传输的数据是否有加掩码,如果设置为1,掩码键必须放在masking-key区域,客户端发送给服务端的所有消息,此位的值都是1;

Payload length: 传输数据的长度,以字节的形式表示:7位、7+16位、或者7+64位。如果这个值以字节表示是0-125这个范围,那这个值就表示传输数据的长度;如果这个值是126,则随后的两个字节表示的是一个16进制无符号数,用来表示传输数据的长度;如果这个值是127,则随后的是8个字节表示的一个64位无符合数,这个数用来表示传输数据的长度。多字节长度的数量是以网络字节的顺序表示。负载数据的长度为扩展数据及应用数据之和,扩展数据的长度可能为0,因而此时负载数据的长度就为应用数据的长度。

Masking-key:0或4个字节,客户端发送给服务端的数据,都是通过内嵌的一个32位值作为掩码的;掩码键只有在掩码位设置为1的时候存在。
Payload data: (x+y)位,负载数据为扩展数据及应用数据长度之和。
Extension data:x位,如果客户端与服务端之间没有特殊约定,那么扩展数据的长度始终为0,任何的扩展都必须指定扩展数据的长度,或者长度的计算方式,以及在握手时如何确定正确的握手方式。如果存在扩展数据,则扩展数据就会包括在负载数据的长度之内。

Application data:y位,任意的应用数据,放在扩展数据之后,应用数据的长度=负载数据的长度-扩展数据的长度。

 
 
 
 
 
 
 
 
 
posted @ 2014-02-10 09:53  如果的事  阅读(996)  评论(0编辑  收藏  举报