webSocket原理探索

摘要：帧是发送数据的基本单位，下边是它的报文格式报文内容中规定了数据标示操作代码掩码数据数据长度等格式。首先我们明白了客户端和服务端进行消息传递是这样的客户端将消息切割成多个帧，并发送给服务端。服务端接收消息帧，并将关联的帧重新组装成完整的消息。

Web Sockets的目标是在一个多带带的持久连接上提供全双工、双向通信。在Javascript创建了Web Socket之后，会有一个HTTP请求发送到浏览器以发起连接。在取得服务器响应后，建立的连接会将HTTP升级从HTTP协议交换为WebSocket协议。
由于WebSocket使用自定义的协议，所以URL模式也略有不同。未加密的连接不再是http://，而是ws://;加密的连接也不是https://，而是wss://。在使用WebSocket URL时，必须带着这个模式，因为将来还有可能支持其他的模式。
使用自定义协议而非HTTP协议的好处是，能够在客户端和服务器之间发送非常少量的数据，而不必担心HTTP那样字节级的开销。由于传递的数据包很小，所以WebSocket非常适合移动应用。
上文中只是对Web Sockets进行了笼统的描述，接下来的篇幅会对Web Sockets的细节实现进行深入的探索，本文接下来的四个小节不会涉及到大量的代码片段，但是会对相关的API和技术原理进行分析，相信大家读完下文之后再来看这段描述，会有一种豁然开朗的感觉。

“握手通道”是HTTP协议中客户端和服务端通过"TCP三次握手"建立的连接通道。客户端和服务端使用HTTP协议进行的每次交互都需要先建立这样一条“通道”，然后通过这条通道进行通信。我们熟悉的ajax交互就是在这样一个通道上完成数据传输的，下面是HTTP协议中建立“握手通道”的过程示意图：

上文中我们提到：在Javascript创建了WebSocket之后，会有一个HTTP请求发送到浏览器以发起连接，然后服务端响应，这就是“握手“的过程，在这个握手的过程当中，客户端和服务端主要做了两件事情：

建立了一条连接“握手通道”用于通信（这点和HTTP协议相同，不同的是HTTP协议完成数据交互后就释放了这条握手通道，这就是所谓的“短连接”，它的生命周期是一次数据交互的时间，通常是毫秒级别的。）

将HTTP协议升级到WebSocket协议，并复用HTTP协议的握手通道，从而建立一条持久连接。

说到这里可能有人会问：HTTP协议为什么不复用自己的“握手通道”，而非要在每次进行数据交互的时候都通过TCP三次握手重新建立“握手通道”呢？答案是这样的：虽然“长连接”在客户端和服务端交互的过程中省去了每次都建立“握手通道”的麻烦步骤，但是维持这样一条“长连接”是需要消耗服务器资源的，而在大多数情况下，这种资源的消耗又是不必要的，可以说HTTP标准的制定经过了深思熟虑的考量。到我们后边说到WebSocket协议数据帧时，大家可能就会明白，维持一条“持久连接”服务端和客户端需要做的事情太多了。

说完了握手通道，我们再来看HTTP协议如何升级到WebSocket协议的。

升级协议需要客户端和服务端交流，服务端怎么知道要将HTTP协议升级到WebSocket协议呢？它一定是接收到了客户端发送过来的某种信号。下面是我从谷歌浏览器中截取的“客户端发起协议升级请求的报文”，通过分析这段报文，我们能够得到有关WebSocket中协议升级的更多细节。

首先，客户端发起协议升级请求。采用的是标准的HTTP报文格式，且只支持GET方法。下面是重点请求的首部的意义：

Connection：Upgrade：表示要升级的协议

Upgrade: websocket：表示要升级到websocket协议

Sec-WebSocket-Version: 13：表示websocket的版本

Sec-WebSocket-Key:UdTUf90CC561cQXn4n5XRg== ：与Response Header中的响应首部Sec-WebSocket-Accept: GZk41FJZSYY0CmsrZPGpUGRQzkY=是配套的，提供基本的防护，比如恶意的连接或者无意的连接。

其中Connection就是我们前边提到的，客户端发送给服务端的信号，服务端接受到信号之后，才会对HTTP协议进行升级。那么服务端怎样确认客户端发送过来的请求是否是合法的呢？在客户端每次发起协议升级请求的时候都会产生一个唯一码：Sec-WebSocket-Key。服务端拿到这个码后，通过一个算法进行校验，然后通过Sec-WebSocket-Accept响应给客户端，客户端再对Sec-WebSocket-Accept进行校验来完成验证。这个算法很简单：

1.将Sec-WebSocket-Key跟全局唯一的（GUID，[RFC4122]）标识：258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接

2.通过SHA1计算出摘要，并转成base64字符串

258EAFA5-E914-47DA-95CA-C5AB0DC85B11这个字符串又叫“魔串"，至于为什么要使用它作为Websocket握手计算中使用的字符串，这点我们无需关心，只需要知道它是RFC标准规定就可以了，官方的解析也只是简单的说此值不大可能被不明白WebSocket协议的网络终端使用。我们还是用世界上最好的语言来描述一下这个算法吧。

public function dohandshake($sock, $data, $key) {
        if (preg_match("/Sec-WebSocket-Key: (.*)
/", $data, $match)) {
            $response = base64_encode(sha1($match[1] . "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", true));
            $upgrade  = "HTTP/1.1 101 Switching Protocol
" .
                "Upgrade: websocket
" .
                "Connection: Upgrade
" .
                "Sec-WebSocket-Accept: " . $response . "

";
            socket_write($sock, $upgrade, strlen($upgrade));
            $this->isHand[$key] = true;
        }
    }

服务端响应客户端的头部信息和HTTP协议的格式是相同的，所以这里Sec-WebSocket-Accept字段后边的两个换行符是少不了的，这和我们使用curl工具模拟get请求是一个道理。这样展示结果似乎不太直观，我们使用命令行CLI来根据上图中的Sec-WebSocket-Key和握手算法来计算一下服务端返回的Sec-WebSocket-Accept是否正确：

从图中可以看到，通过算法算出来的base64字符串和Sec-WebSocket-Accept是一样的。那么假如服务端在握手的过程中返回一个错误的Sec-WebSocket-Accept字符串会怎么样呢？当然是客户端会报错，连接会建立失败，大家最好尝试一下，例如将全局唯一标识符258EAFA5-E914-47DA-95CA-C5AB0DC85B11改为258EAFA5-E914-47DA-95CA-C5AB0DC85B12。

下图是我做的一个测试：将小说《飘》的第一章内容复制成文本数据，通过客户端发送到服务端，然后服务端响应相同的信息完成了一次通信。

可以看到一篇足足有将近15000字节的数据在客户端和服务端完成通信只用了150ms的时间。我们还可以清晰的看到浏览器控制台中frame栏中显示的客户端发送和服务端响应的文本数据，你一定惊讶WebSocket通信强大的数据传输能力。数据是否真的像frame中展示的那样客户端直接将一大篇文本数据发送到服务端，服务端接收到数据之后，再将一大篇文本数据返回给客户端呢？这当然是不可能的，我们都知道HTTP协议是基于TCP实现的，HTTP发送数据也是分包转发的，就是将大数据根据报文形式分割成一小块一小块发送到服务端,服务端接收到客户端发送的报文后，再将小块的数据拼接组装。关于HTTP的分包策略，大家可以查看相关资料进行研究，websocket协议也是通过分片打包数据进行转发的，不过策略上和HTTP的分包不一样。frame（帧）是websocket发送数据的基本单位，下边是它的报文格式：

报文内容中规定了数据标示,操作代码、掩码、数据、数据长度等格式。不太理解没关系，下面我通过讲解大家只要理解报文中重要标志的作用就可以了。首先我们明白了客户端和服务端进行Websocket消息传递是这样的:

客户端：将消息切割成多个帧，并发送给服务端。

服务端：接收消息帧，并将关联的帧重新组装成完整的消息。

服务端在接收到客户端发送的帧消息的时候，将这些帧进行组装，它怎么知道何时数据组装完成的呢？这就是报文中左上角FIN(占一个比特)存储的信息，1表示这是消息的最后一个分片（fragment)如果是0,表示不是消息的最后一个分片。websocket通信中，客户端发送数据分片是有序的，这一点和HTTP不一样，HTTP将消息分包之后，是并发无序的发送给服务端的，包信息在数据中的位置则在HTTP报文中存储，而websocket仅仅需要一个FIN比特位就能保证将数据完整的发送到服务端。
接下来的RSV1,RSV2,RSV3三个比特位的作用又是什么呢？这三个标志位是留给客户端开发者和服务端开发者开发过程中协商进行拓展的，默认是0。拓展如何使用必须在握手的阶段就协商好，其实握手本身也是客户端和服务端的协商。

Websocket是长连接，为了保持客户端和服务端的实时双向通信，需要确保客户端和服务端之间的TCP通道保持连接没有断开。但是对于长时间没有数据往来的连接，如果依旧保持着，可能会浪费服务端资源。但是不排除有些场景，客户端和服务端虽然长时间没有数据往来，仍然需要保持连接，就比如说你几个月没有和一个QQ好友聊天了，突然有一天他发QQ消息告诉你他要结婚了，你还是能在第一时间收到。那是因为，客户端和服务端一直再采用心跳来检查连接。客户端和服务端的心跳连接检测就像打乒乓球一样：

发送方->接收方：ping

接收方->发送方：pong

等什么时候没有ping、pong了，那么连接一定是存在问题了。
说了这么多，接下来我使用Go语言来实现一个心跳检测，Websocket通信实现细节是一件繁琐的事情，直接使用开源的类库是比较不错的选择，我使用的是：gorilla/websocket。这个类库已经将websocket的实现细节（握手，数据解码)封装的很好啦。下面我就直接贴代码了:

package main

import (
    "net/http"
    "time"

    "github.com/gorilla/websocket"
)

var (
    //完成握手操作
    upgrade = websocket.Upgrader{
       //允许跨域(一般来讲,websocket都是独立部署的)
       CheckOrigin:func(r *http.Request) bool {
            return true
       },
    }
)

func wsHandler(w http.ResponseWriter, r *http.Request) {
   var (
         conn *websocket.Conn
         err error
         data []byte
   )
   //服务端对客户端的http请求(升级为websocket协议)进行应答，应答之后，协议升级为websocket，http建立连接时的tcp三次握手将保持。
   if conn, err = upgrade.Upgrade(w, r, nil); err != nil {
        return
   }

    //启动一个协程，每隔1s向客户端发送一次心跳消息
    go func() {
        var (
            err error
        )
        for {
            if err = conn.WriteMessage(websocket.TextMessage, []byte("heartbeat")); err != nil {
                return
            }
            time.Sleep(1 * time.Second)
        }
    }()

   //得到websocket的长链接之后,就可以对客户端传递的数据进行操作了
   for {
         //通过websocket长链接读到的数据可以是text文本数据，也可以是二进制Binary
        if _, data, err = conn.ReadMessage(); err != nil {
            goto ERR
     }
     if err = conn.WriteMessage(websocket.TextMessage, data); err != nil {
         goto ERR
     }
   }
ERR:
    //出错之后，关闭socket连接
    conn.Close()
}

func main() {
    http.HandleFunc("/ws", wsHandler)
    http.ListenAndServe("0.0.0.0:7777", nil)
}

借助go语言很容易搭建协程的特点，我专门开启了一个协程每秒向客户端发送一条消息。打开客户端浏览器可以看到，frame中每秒的心跳数据一直在跳动，当长链接断开之后，心跳就没有了，就像人没有了心跳一样：