WebSocket虽然很常见，但是我很少用到，源自某次群里的讨(吹)论(比)，于是就实现了一下，一直没有整理代码，今天顺便写点分析，更多的也就是试着说一下自己是如何学习一个新接触的东西的。


一、简介
        网上的介绍相当多，我就简单地理解优势，相对于HTTP，服务端可以不需要客户Duan去主动请求就可以[推送]数据。所以在聊天室、客服、推送等场景中的应用特别多。但是归根到底，它和HTTP都是TCP。
        最权威的资料当然是RFC 6455 [The WebSocket Protocol]，里面有各种标准定义，本源码以及分析也都是基于这个RFC：https://tools.ietf.org/html/rfc6455
        这也是我的学习习惯，尽量看原版的权威资料，翻译或者博客经常有很多谬误，容易被误导，反而耽误时间。

二、抓包
        ws:的抓包相当简单，任意一个可以抓取tcp数据的工具都可以，wss:则由于是SSL，都是密文，还是用网卡抓包工具的话分析起来就很麻烦。所以我是利用Chrome浏览器的开发者工具抓包。当然只是Opcode为Text的情况才可以利用这个来分析Frame信息，但是握手数据却是可以很简单看到的，二进制数据我没有做过，那大概就需要分析客户Duan代码(javascript)了。

三、握手
        RFC6455 4.1 Client Requirements ：https://tools.ietf.org/html/rfc6455#section-4.1
        请求：
        下面就是一个普通的握手请求，标注星号的不是必须。
                 GET / HTTP/1.1
                 Accept-Language: zh-CN
                 Host: 121.40.165.18:8088//不是默认端口则跟上端口
                 Sec-WebSocket-Version: 13
                 Upgrade: websocket
                 Sec-WebSocket-Key: 2mzaxLsKR++Hp0c5q2ufwg==//随机16byte的base64编码
                 Connection: Upgrade
                *User-Agent:  Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
                *Origin: //121.40.165.18
                *Sec-WebSocket-Protocol:
                *Sec-WebSocket-Extensions:
                *Cookie:
                *Authorization:

        响应：
        下面就是一个普通的握手响应。
                HTTP/1.1 101 Switching Protocols
                Upgrade: websocket
                Connection: Upgrade
                Sec-WebSocket-Accept: Gk9vEODnOs/Kmjxy9leCLqw+9f8=

                并不是每个ws的握手的响应的状态码都是101，如果不是101，则根据RFC rfc2616  https://tools.ietf.org/html/rfc2616 来进行处理。如果状态码是401，则可能需要执行身份验证。

                Sec-WebSocket-Accept 应当为Sec-WebSocket-Key + “258EAFA5-E914-47DA-95CA-C5AB0DC85B1” 的SHA1值的base64

四丶数据包
        Base Framing Protocol：https://tools.ietf.org/html/rfc6455#section-5.2

        数据包构造和解析应该是WebSocket学习中最重要的部分了，其实也就是看一看RFC就出来了。
        下面我配合着RFC挨个解释下，也方便英文不太好的朋友：
                1 byte(字节) = 8 bit(位)  这种基础知识就不说了

Fin：1 bit
                        标识着这个 Frame 是不是一个消息中的最后一条
                        有的消息可能被拆成了若干个Frame
                RSV1, RSV2, RSV3： 每个都是 1 bit  
                        就是 Reserved(保留)的意思，在一些扩展协yi以外一般赋0。
                Opcode：4 bits
                        操作码，标识着 Payload Data 的类型：
                                OPCODE_CONTINUATION0继续
                                OPCODE_TEXT1文本
                                OPCODE_BINARY2二进制
                                OPCODE_CLOSE8关闭
                                OPCODE_PING9ping
                                OPCODE_PONG10pong
                        以及一堆保留的操作码
                Mask：1 bit
                        标识着是否需要进行掩码计算
                Payload length：7 或者 7+16 或者 7+64 bits
                        这儿是 Payload Data 的长度，要注意，这个长度不一样，占用的位数也不一样。
                        其实这个Frame的设计相当令人佩服，尽可能地减少空间，这才是网络传输中睿智的选择。
                        假设 DataLen 是 Payload Data 的长度，那么：
                                当 DataLen ≤ 125 的时候
                                        Payload length 占用的位数为 7 bits，直接表示了 DataLen 。
                        对位运算不熟悉的朋友可以下载源码看 EncryptData 和 DecryptData 部分的写法。
                                当 126 ≤ DataLen ≤ 65535 的时候
                                        Payload length 占用的位数为 7+16 bits，
                                        前 7 bits 置为126，紧跟的 16 bits (相当于易的短整数型，但是是无符号的。)来表示 DataLen
                                当 DataLen ＞ 65535 的时候
                                        Payload length 占用的位数为 7+64 bits，
                                        前 7 bits 置为127，紧跟的 64 bits (相当于易的长整数型，但是是无符号的。)来表示 DataLen
                Masking-key：0 bit 或者 4 bytes
                        这儿是 掩码计算的Key。
                        如果 Mask 位为0 这儿就不需要 为 0 bit。否则则需要随机一个4字节的key。
                        严格按照规范的话，普通的随机数生成的key不合格，需要足够安全的随机数。
                Payload data：x+y  bytes
                        扩展：x bytes
                                在没有协商扩展的情况下，为0
                        应用：y bytes
                                例程中发送或者读取的也就是这儿的数据。

四丶Masked 掩码计算
        就是简单的异或，将那 4 bytes 的 Masking-key 每 byte 地和 Payload Data 进行异或运算。

五、异步
        异步当然是最适合WebSocket的写法，这个实现里为了符合自己的习惯，没有用异步。

六、wss
        wss和ws没有很大区别，但是需要SSL。
        由于个人洁癖不喜欢用第三方库，所以此处用到心冷丶鱼儿开源的用CryptoAPI实现的SSL。
        而且发给我一些SSL的资料，受益很多，此处感谢。

七、关于模块
        找来了一些在线聊天室的ws和wss进行了实现，写在了demo里。
        更多的兼容没有去做，但是我相信所有的疑问都可以在这个RFC6455中找到答案。
        调用方法也相当简单，
                Init → 传入URL
                HandShake → 握手
                Send → 发送
                Recv → 接收
                SetHeader → 设置协yi头


源码、资料以及本篇的doc下载：