WebSocket协议的握手和数据帧

WebSocket的握手和数据帧WebSocket是定义服务器和客户端如何通过Web通信的一种网络协议。协议是通信的议定规则。组成互联网的协议组由IETF(互联网工程任务组)发布。IETF发布评议请求(RequestforComments，RFC)，精确地规定了协议(包括RFC6455)：WebSocket协议。RFC6455于2011年12月发布，包含了实现WebSocket客户端和服务器时必须遵循的规则。websocket基本上是一个很简单的协议,主要非常少,实现起来也很简单。为简单起见,下面只分析握手和数据帧的报文.一.握手(handshake).握手协议由客户端发起,服务器响应,一来一回就完成了.基本上是为了兼容现有的http基础设施.下面是一个客户端发起的握手请求:474554202F20485454502F312E310D0AGET./.HTTP/1.1.. 557067726164653A20776562736F636BUpgrade:.websock 65740D0A436F6E6E656374696F6E3A20et..Connection:. 557067726164650D0A486F73743A2031Upgrade..Host:.1 39322E3136382E382E3132383A31333092.168.8.128:130 300D0A4F726967696E3A206E756C6C0D0..Origin:.null. 0A507261676D613A206E6F2D63616368.Pragma:.no-cach 650D0A43616368652D436F6E74726F6Ce..Cache-Control 3A206E6F2D63616368650D0A5365632D:.no-cache..Sec- 576562536F636B65742D4B65793A2064WebSocket-Key:.d 33353946646F366F6D79716678795946359Fdo6omyqfxyYF 37596163773D3D0D0A5365632D5765627Yacw==..Sec-Web 536F636B65742D56657273696F6E3A20Socket-Version:. 31330D0A5365632D576562536F636B6513..Sec-WebSocke 742D457874656E73696F6E733A20782Dt-Extensions:.x- 7765626B69742D6465666C6174652D66webkit-deflate-f 72616D650D0A557365722D4167656E74rame..User-Agent 3A204D6F7A696C6C612F352E30202857:.Mozilla/5.0.(W 696E646F7773204E5420362E313B2057indows.NT.6.1;.W 4F57363429204170706C655765624B69OW64).AppleWebKi 742F3533372E333620284B48544D4C2Ct/537.36.(KHTML, 206C696B65204765636B6F2920436872.like.Gecko).Chr 6F6D652F33322E302E313635332E3020ome/32.0.1653.0. 5361666172692F3533372E33360D0A0DSafari/537.36... 0A  0D0A0D0A,也就是用"\r\n\r\n"收尾,这和http头没什么区别.转换成字符串就是:GET/HTTP/1.1 Upgrade:websocket Connection:Upgrade Host:192.168.8.128:1300 Origin:null Pragma:no-cache Cache-Control:no-cache Sec-WebSocket-Key:d359Fdo6omyqfxyYF7Yacw== Sec-WebSocket-Version:13 Sec-WebSocket-Extensions:x-webkit-deflate-frame User-Agent:Mozilla/5.0(WindowsNT6.1;WOW64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/32.0.1653.0Safari/537.36 其中有一对重要的kv,就是Sec-WebSocket-Key:d359Fdo6omyqfxyYF7Yacw==,看上去是一个base64编码后的结果,服务器需要对这个sec-key作一些处理,并返回握手响应,这个处理是:1.byte[] sha = sha1(("d359Fdo6omyqfxyYF7Yacw==" + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11").getBytes());  2.System.out.println(new String(Base64.getEncoder().encode(sha)));  也就是原封不动的拿着这个sec-key和另一个神奇的字符串"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"相连,再经过sha1摘要算法处理,最后再经过base64编码输出即可,上面的输出结果应该是:pLO2KC7b5t0TZl1E6A3sqJ6EzU4=服务器在收到握手请求后,如果愿意提供服务,则返回一个握手响应,如下:1.HTTP/1.1 101 Switching Protocols  2.Connection: Upgrade  3.Upgrade: WebSocket  4.Sec-WebSocket-Accept: pLO2KC7b5t0TZl1E6A3sqJ6EzU4=  遵循http的规则,字节流上一样是要以"\r\n\r\n"收尾.二.数据帧rfc6455上叫做非控制帧,除了非控制帧之外,就是控制帧.包括connectionclose,ping,pong等帧,这里只讲非控制帧,也就是数据帧.数据帧从长度上可以分为三种.帧中的静荷数据(payloaddata)长度小于0x7E的为小帧,静荷数据长度>=0x7E又<=0x10000的为中帧,再长的叫大帧.数据帧从类型上暂时可以分为两种,文本帧和二进制帧.例子:a).一个从客户端发向服务端的小帧.1.82 B0 6A F7 C6 30 0A D9 C6 34 D4 18 78 C1 6E F5 ..j..0...4..x.n.  2.C6 30 6C D5 CC 10 23 87 AF 48 3C A2 9C 64 01 C4 .0l...#..H<..d..  3.AE 59 04 C5 B1 5B 35 85 A3 41 18 B0 F5 5C 13 8E .Y...[5..A...\..  4.92 42 02 84 85 53                               .B...S  82二进制为:10000010,最高位(FIN)为1,表示这是最后一帧,第一个帧也可能是最后一帧.身后还有三位为预留.低位四0010为操作码.也就是0x02,表示这是一个二进制帧,0x01为文本帧.B0二进制为:10110000,最高位(MASK)为1,表示当前帧的静荷数据部分使用了掩码,事实上,rfc6455规定从客户端发往服务器端的数据帧必需使用掩码,反过来,从服务器发回来的,则必需不使用掩码.低7位为静荷数据长度字段,这里是0110000,也就是0x30,从上面的报文上看,这个0x30没有包含后面的掩码.6AF7C630掩码,掩码总是四个字节.0AD9C6...一直到最后为经过掩码加工后的静荷数据.要回到数据本来的面目,使用下面的算法:1.byte by[] = new byte[]{0x82, 0xB0, 0x6A, 0xF7, 0xC6, 0x30, 0x0A....};  2.byte mask[] = new byte[] { 0x6A, (byte) 0xF7, (byte) 0xC6, 0x30 };  3.for (int i = 6 /* 越过掩码. */; i < by.length; i++)  4.    by[i] = (byte) (by[i] ^ mask[(i - 6) % 4]);  得到的结果应该是:1.82 B0 6A F7 C6 30 60 2E 00 04 BE EF BE F1 04 02 ..j..0`.........  2.00 00 06 22 0A 20 49 70 69 78 56 55 5A 54 6B 33 ..."..IpixVUZTk3  3.68 69 6E 32 77 6B 5F 72 65 71 72 47 33 6C 79 79 hin2wk_reqrG3lyy  4.54 72 68 73 43 63                               TrhsCc  b).一个从服务器发给客户端的小帧.1.82 29 61 27 01 04 BE EF BE F1 05 02 00 00 06 1B .)a'............  2.0A 08 55 3B 02 19 39 35 E2 44 12 0F 21 EC BC 47 ..U;..95.D..!..G  3.02 F3 EC 70 ED 5B 7B 07 C7 F4 D0                ...p.[{....  更简单了,还是82,最后一帧,二进制帧,29,00101001,无掩码,也就是身后全长为0x29.c).未使用掩码的中帧.817E0100667788...,帧长为0x0100,也就是256个字节.d).未使用掩码的大帧.827F0000000011223344667788...,帧长为0x0000000011223344,直接跳过4字节,而使用8字节来表示长度,非常暴力.这里需要注意的是,websocket要求使用最小帧原则,也就是静荷数据长度小于0x7E帧,不能使用中帧或大帧的来表示.长度小于0x10000的帧也不能用大帧来表示.【编辑推荐】1.网络协议X档案网络传输协议篇2.应用Wireshark观察基本网络协议3.移动网络性能揭秘--网络协议及性能提升实践