其他分享
首页 > 其他分享> > 基于Websocket草案10协议的升级及基于Netty的握手实现

基于Websocket草案10协议的升级及基于Netty的握手实现

作者:互联网

    最近发现,WEBWW在chrome14及FF6.5中没法与后台建立连接了,后面经过查找原因,是chrome14中使用最新的websocket协议草案,而chrome12中使用的websocket协议标准还是草案7.5、7.6的标准;现在草案的最新版本是草案10,草案的链接地址为:http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10,本次协议变更比较大,主要体现在安全性和可扩展性上:

    1、握手的标准:

1)、最老的websocket草案标准中是没有安全key,草案7.5、7.6中有两个安全key,而现在的草案10中只有一个安全key,即将7.5、7.6中http头中的"Sec-WebSocket-Key1"与"Sec-WebSocket-Key2"合并为了一个"Sec-WebSocket-Key"

2)、把http头中Upgrade的值由"WebSocket"修改为了"websocket";

3)、把http头中的"-Origin"修改为了"Sec-WebSocket-Origin";

4)、增加了http头"Sec-WebSocket-Accept",用来返回原来草案7.5、7.6服务器返回给客户端的握手验证,原来是以内容的形式返回,现在是放到了http头中;另外服务器返回客户端的验证方式也变了,后面会有介绍。

    2、数据传输的格式:

以下是一个格式标准图:

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位,任意的应用数据,放在扩展数据之后,应用数据的长度=负载数据的长度-扩展数据的长度。

    数据帧协议是按照扩展的巴科斯范式(ANBF:Augmented Backus-Naur Form RFC5234)组成的:       

 

   ws-frame                = frame-fin
                             frame-rsv1
                             frame-rsv2
                             frame-rsv3
                             frame-opcode
                             frame-masked
                             frame-payload-length
                             [ frame-masking-key ]
                             frame-payload-data

   frame-fin               = %x0 ; 表示这不是当前消息的最后一帧,后面还有消息
                           / %x1 ; 表示这是当前消息的最后一帧

   frame-rsv1              = %x0
                             ; 1 bit, 如果没有扩展约定,该值必须为0

   frame-rsv2              = %x0
                             ; 1 bit, 如果没有扩展约定,该值必须为0

   frame-rsv3              = %x0
                             ; 1 bit, 如果没有扩展约定,该值必须为0

   frame-opcode            = %x0 ; 表示这是一个连续帧消息
                           / %x1 ; 表示文本消息
                           / %x2 ; 表示二进制消息
                           / %x3-7 ; 保留
                           / %x8 ; 表示客户端发起的关闭
                           / %x9 ; ping(用于心跳)
                           / %xA ; pong(用于心跳)
                           / %xB-F ; 保留

   frame-masked            = %x0 ; 数据帧没有加掩码,后面没有掩码key
                           / %x1 ; 数据帧加了掩码,后面有掩码key

   frame-payload-length    = %x00-7D
                           / %x7E frame-payload-length-16
                           / %x7F frame-payload-length-63
			   ; 表示数据帧的长度

   frame-payload-length-16 = %x0000-FFFF
			   ; 表示数据帧的长度

   frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
			   ; 表示数据帧的长度

   frame-masking-key       = 4( %0x00-FF ) ; 掩码key,只有当掩码位为1时出现

   frame-payload-data      = (frame-masked-extension-data
                              frame-masked-application-data)   ; 当掩码位为1时,这里的数据为带掩码的数据,扩展数据及应用数据都带掩码
                           / (frame-unmasked-extension-data
                              frame-unmasked-application-data) ; 当掩码位为0时,这里的数据为不带掩码的数据,扩展数据及应用数据都不带掩码

   frame-masked-extension-data     = *( %x00-FF ) ; 目前保留,以后定义

   frame-masked-application-data   = *( %x00-FF )

   frame-unmasked-extension-data   = *( %x00-FF ) ; 目前保留,以后定义

   frame-unmasked-application-data = *( %x00-FF )

 

    还有一些其它的变更,详细的可以查看查案文档了,主要的应该就是上面提到的两大块。

    后台Server使用的是Netty NIO框架,目前Netty官方还没有对websocket草案10的实现,只支持到草案7.6,自己根据草案标准实现netty的encode及decoder也不难,不过在非官方还是找到了Netty支持最新草案10的实现:https://github.com/joewalnes/webbit/tree/0356ba12f5c21f8a297a5afb433215bb2f738008/src/main/java/org/webbitserver/netty,呵,有现成的就用现成的了。

    在后台只需要判断是最新的草案10,将Encoder及Decoder分别换成Hybi10WebSocketFrameDecoder()及Hybi10WebSocketFrameEncoder(),判断是否最新草案10的websocket协议,只需要判断请求头中是否同时包括了这两个请求头:Sec-WebSocket-Origin及Sec-WebSocket-Key,如果包含了那说明是草案10标准,如果不是再判断是否草案76或最老的草案标准,进行相应的处理。

    握手的实现,首先要获取到请求头中的Sec-WebSocket-Key的值,再把这一段GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"加到获取到的Sec-WebSocket-Key的值的后面,然后拿这个字符串做SHA-1 hash计算,然后再把得到的结果通过base64加密,就得到了返回给客户端的Sec-WebSocket-Accept的http响应头的值,以下是基于Netty的JAVA实现:    

 

    private HttpResponse buildWebSocketRes(HttpRequest req, boolean isWebSocketProtocolAfterDraft7) {
        String reasonPhrase = "";
        // websocket协议草案7后面的格式,可以参看wikipedia上面的说明,比较前后版本的不同:http://en.wikipedia.org/wiki/WebSocket
        reasonPhrase = "Switching Protocols";
        HttpResponse res = new DefaultHttpResponse(HttpVersion.HTTP_1_1, new HttpResponseStatus(101, reasonPhrase));
        res.addHeader(HttpHeaders.Names.UPGRADE, "websocket");
        res.addHeader(HttpHeaders.Names.CONNECTION, HttpHeaders.Values.UPGRADE);
		String protocol = req.getHeader(Names.SEC_WEBSOCKET_PROTOCOL);
		if (protocol != null) {
			res.addHeader(Names.SEC_WEBSOCKET_PROTOCOL, protocol);
		}
		res.addHeader(SEC_WEBSOCKET_ACCEPT, getSecWebSocketAccept(req));
        return res;
    }
	private String getSecWebSocketAccept(HttpRequest req) {
        // CHROME WEBSOCKET VERSION 8中定义的GUID,详细文档地址:http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10
        String guid = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
        String key = "";
        key = req.getHeader(SEC_WEBSOCKET_KEY);
        key += guid;
        try {
            MessageDigest md = MessageDigest.getInstance("SHA-1");
            md.update(key.getBytes("iso-8859-1"), 0, key.length());
            byte[] sha1Hash = md.digest();
            key = base64Encode(sha1Hash);
        } catch (NoSuchAlgorithmException e) {
            if (logger.isErrorEnabled()) {
                logger.error("NoSuchAlgorithmException:" + e.getMessage(), e);
            }
        } catch (UnsupportedEncodingException e) {
            if (logger.isErrorEnabled()) {
                logger.error("UnsupportedEncodingException:" + e.getMessage(), e);
            }
        }
        return key;
    }
	/**
     * 将输入字节数组进行base64编码,再返回编码后的字符串
     * 
     * @param input
     * @return
     */
    public static String base64Encode(byte[] input) {
        BASE64Encoder encoder = new BASE64Encoder();
        String base64 = encoder.encode(input);
        return base64;
    }

 

    另外,最老版本的无安全Key的WebSocket的握手实现以及基于草案76以前的握手实现,可以参看我的另外一篇文章:http://blog.csdn.net/fenglibing/article/details/6699154

 

本文出自:冯立彬的博客

 

 


再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

标签:10,基于,Websocket,frame,草案,key,掩码,WebSocket,数据
来源: https://www.cnblogs.com/skiwdhwhssh/p/10340590.html