用Go快速搭建IM即时通讯系统
WebSocket的目标是在一个单独的持久连接上提供全双工、双向通信。在Javascript创建了Web Socket之后，会有一个HTTP请求发送到浏览器以发起连接。在取得服务器响应后，建立的连接会将HTTP升级从HTTP协议交换为WebSocket协议。
由于WebSocket使用自定义的协议，所以URL模式也略有不同。未加密的连接不再是http://，而是ws://;加密的连接也不是https://，而是wss://。在使用WebSocket URL时，必须带着这个模式，因为将来还有可能支持其他的模式。
使用自定义协议而非HTTP协议的好处是，能够在客户端和服务器之间发送非常少量的数据，而不必担心HTTP那样字节级的开销。由于传递的数据包很小，所以WebSocket非常适合移动应用。
接下来的篇幅会对Web Sockets的细节实现进行深入的探索，本文接下来的四个小节不会涉及到大量的代码片段，但是会对相关的API和技术原理进行分析，相信大家读完下文之后再来看这段描述，会有一种豁然开朗的感觉。
“握手通道”是HTTP协议中客户端和服务端通过"TCP三次握手"建立的通信通道。客户端和服务端使用HTTP协议进行的每次交互都需要先建立这样一条“通道”，然后通过这条通道进行通信。我们熟悉的ajax交互就是在这样一个通道上完成数据传输的，只不过ajax交互是短连接，在一次 request->response 之后，“通道”连接就断开了。
在Javascript创建了WebSocket之后，会有一个HTTP请求发送到浏览器以发起连接，然后服务端响应，这就是“握手“的过程。
在这个握手的过程当中，客户端和服务端主要做了两件事情：
1）建立了一条连接“握手通道”用于通信（这点和HTTP协议相同，不同的是HTTP协议完成数据交互后就释放了这条握手通道，这就是所谓的“短连接”，它的生命周期是一次数据交互的时间，通常是毫秒级别的）；2）将HTTP协议升级到WebSocket协议，并复用HTTP协议的握手通道，从而建立一条持久连接。
说到这里可能有人会问：HTTP协议为什么不复用自己的“握手通道”，而非要在每次进行数据交互的时候都通过TCP三次握手重新建立“握手通道”呢？
答案是这样的：虽然“长连接”在客户端和服务端交互的过程中省去了每次都建立“握手通道”的麻烦步骤，但是维持这样一条“长连接”是需要消耗服务器资源的，而在大多数情况下，这种资源的消耗又是不必要的，可以说HTTP标准的制定经过了深思熟虑的考量。到我们后边说到WebSocket协议数据帧时，大家可能就会明白，维持一条“长连接”服务端和客户端需要做的事情太多了。
说完了握手通道，我们再来看HTTP协议如何升级到WebSocket协议的。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询即可
升级协议需要客户端和服务端交流，服务端怎么知道要将HTTP协议升级到WebSocket协议呢？它一定是接收到了客户端发送过来的某种信号。下面是我从谷歌浏览器中截取的“客户端发起协议升级请求的报文”，通过分析这段报文，我们能够得到有关WebSocket中协议升级的更多细节。
首先，客户端发起协议升级请求。采用的是标准的HTTP报文格式，且只支持GET方法。
下面是重点请求的首部的意义：
1）Connection：Upgrade：表示要升级的协议2）Upgrade: websocket：表示要升级到websocket协议3）Sec-WebSocket-Version: 13：表示websocket的版本4）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）标识：258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接；2）通过SHA1计算出摘要，并转成base64字符串。
258EAFA5-E914-47DA-95CA-C5AB0DC85B11 这个字符串又叫“魔串"，至于为什么要使用它作为Websocket握手计算中使用的字符串，这点我们无需关心，只需要知道它是RFC标准规定就可以了，官方的解析也只是简单的说此值不大可能被不明白WebSocket协议的网络终端使用。
服务端响应客户端的头部信息和HTTP协议的格式是相同的，HTTP1.1协议是以换行符(\r\n)分割的，我们可以通过正则匹配解析出Sec-WebSocket-Accept的值，这和我们使用curl工具模拟get请求是一个道理。这样展示结果似乎不太直观，我们使用命令行CLI来根据上图中的Sec-WebSocket-Key和握手算法来计算一下服务端返回的Sec-WebSocket-Accept是否正确。