来确认对方是否支持WebSocket。当握手成功后,采用TCP传输,基本消息以数据帧为单位来传递。
所以在这个协议里HTTP只是一过客,为了和HTTP协议区分开来,WebSocket采用ws://或wss://来确定通讯地址。
当客户端连接服务端时,先利用HTTP协议,在其HTTP Header字段中表明要采用WebSocket来通信。
如:
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: BASE64(随机字符串)
Sec-WebSocket-Version: 13
服务端如果支持的话,会返回差不多的字段,不过Sec-WebSocket-Accept这个字段会加点料。
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: BASE64( SHA1( 客户端随机字符串 + websocketGUID ) );
websocketGUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
websocketGUID是固定的值,所有实现WebSocket协议的代码,都是指定的这个值.
客户端收到后,就表示两边的 WebSocket 连接握手成功,然后两边用TCP协议通讯。
WebSocket也是用数据帧(frame)作为基本单位,但注意它的帧与HTTP2的帧是不一样的。
两边的对比:
HTTP2的帧格式:
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
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 ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
微软的HTTPSpeed+Mobility提案与Google的SPDY争HTTP/2协议标准时,曾经提过一个方案,想把这两种帧格式融合。但最后还是没成.
WebSocket的帧有很多种类型定义,例如,为了维持TCP协议的心跳,在控制帧中就定义了个PingFrame, PongFrame.
具体就不细说了。 官方文档有:https://tools.ietf.org/html/rfc6455
WebSocket还提供了四个事件:onopen,onmessage,onerror,onclose 在编程时感觉非常方便。只在要合适的地方处理触发的回调即可。
WebSocket底层采用TCP协议通讯,但握手时是利用的HTTP协议,所以它叫WebSocket而不是Socket.
同时如果是网页的话,需要本地浏览器支持了这个协议才可以通讯。 非浏览器应用则要包含相关支持库才行。
WebSocket与HTTP/2协议不同的地方是,它我觉得更多是为了解决实时通讯问题而出现的。有了它,网页可以利用Js等
与其它端实现实时通讯。 实际上现在很多app.套了网页的那种和原生app也都大量用了WebSocket。包括现在我也在大量
采用了WebSocket协议. 而HTTP/2的侧重点则更多放在网页加速,减少连接和流量方面。
然后还要说下HTML5. HTML5以前风光过,后面低迷了段时间,但这二年又开始热了起来。但很多人还停留在HTML4的认知中,
以为HTML5最多就是在以前的基础上加了几个新标签,其实HTML5大了去了。
附一张维基百科上HTML5的图,可以看到真是包含太多东西了.
(图片来源:https://en.wikipedia.org/wiki/HTML5)
最后我理了下近几年定稿发布的新协议:
1999年HTTP 1.1发布
HTTP/2标准是HTTP16年来的首个更新,于2015年5月以RFC 7540正式发表。
1999年制定的HTML 4.01和XHTML 1.0标准
HTML5经过几乎8年的艰辛努力才在2014年10月由万维网联盟(W3C)宣布完成HTML5标准制定。
WebSocket协议。RFC 6455于2011年12月发布,但真正用起来,感觉就近两年的事。
再看看MQTT,1999年,IBM和合作伙伴共同发明了MQTT协议,
直到2014年,MQTT正式成为推荐的物联网传输协议标准。
个人总结:
1. 标准的推进并不容易,但因为移动互联网这几年爆发式的增长,联网设备的增多,
反过来推进了很多新标准(特别是Web/物联网等方面)的加速定稿和应用。
2.整个互联网的基础正在加速演进。
3.以HTTP1.1与HTTP/2中的优化方法的不同,可以看出,很多过去的好经验,
在新标准下可能不在适用。所以使用时要注意,不要犯经验主义错误.
要学的东西太多了,真是" 一入IT深似海,从此青春是路人"。
BLOG: http://blog.csdn.net/xcl168