WebSocket(一) -- 原理详解

1. 什么是websocket

• WebSocket是HTML5下一种新的协议（websocket协议本质上是一个基于tcp的协议）
• 它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯的目的
• Websocket是一个持久化的协议

2. websocket的原理

• websocket约定了一个通信的规范，通过一个握手的机制，客户端和服务器之间能建立一个类似tcp的连接，从而方便它们之间的通信
• 在websocket出现之前，web交互一般是基于http协议的短连接或者长连接
• websocket是一种全新的协议，不属于http无状态协议，协议名为"ws"

3. websocket与http的关系

3.1 相同点：

1. 都是基于tcp的，都是可靠性传输协议
2. 都是应用层协议

3.2 不同点：

1. WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息
2. HTTP是单向的
3. WebSocket是需要浏览器和服务器握手进行建立连接的
4. 而http是浏览器发起向服务器的连接，服务器预先并不知道这个连接

3.3 联系：

WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的

3.4 总结（总体过程）

1. 首先，客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
2. 然后，服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据；
3. 最后，客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信。

4. http存在的问题及改进方案

• http是一种无状态协议，每当一次会话完成后，服务端都不知道下一次的客户端是谁，需要每次知道对方是谁，才进行相应的响应，因此本身对于实时通讯就是一种极大的障碍
• http协议采用一次请求，一次响应，每次请求和响应就携带有大量的header头，对于实时通讯来说，解析请求头也是需要一定的时间，因此，效率也更低下
• 最重要的是，需要客户端主动发，服务端被动发，也就是一次请求，一次响应，不能实现主动发送

4.1 解决方案一：long poll(长轮询)

• 对于以上情况就出现了http解决的第一个方法——长轮询
• 基于http的特性，简单点说，就是客户端发起长轮询，如果服务端的数据没有发生变更，会 hold 住请求，直到服务端的数据发生变化，或者等待一定时间超时才会返回。返回后，客户端又会立即再次发起下一次长轮询
• 优点是解决了http不能实时更新的弊端，因为这个时间很短，发起请求即处理请求返回响应，实现了“伪·长连接”

4.1.1 张三取快递的例子：

张三今天一定要取到快递，他就一直站在快递点，等待快递一到，立马取走

从例子上来看有个问题：

假如有好多人一起在快递站等快递，那么这个地方是否足够大，（抽象解释：需要有很高的并发，同时有很多请求等待在这里）

4.1.2 总的来看：

• 推送延迟：服务端数据发生变更后，长轮询结束，立刻返回响应给客户端。
• 服务端压力：长轮询的间隔期一般很长，例如 30s、60s，并且服务端 hold 住连接不会消耗太多服务端资源。

4.2 解决方案二：Ajax轮询

• 基于http的特性，简单点说，就是规定每隔一段时间就由客户端发起一次请求，查询有没有新消息，如果有，就返回，如果没有等待相同的时间间隔再次询问
• 优点是解决了http不能实时更新的弊端，因为这个时间很短，发起请求即处理请求返回响应，把这个过程放大n倍，本质上还是request = response

4.2.1 张三取快递的例子：

假设张三今天有个快递快到了，但是张三忍耐不住，就每隔十分钟给快递员或者快递站打电话，询问快递到了没，每次快递员就说还没到，等到下午张三的快递到了，but，快递员不知道哪个电话是张三的，（可不是只有张三打电话，还有李四，王五），所以只能等张三打电话，才能通知他，你的快递到了

从例子上来看有两个问题：

1. 假如说，张三打电话的时间间隔为10分钟，当他收到快递前最后一次打电话，快递员说没到，他刚挂掉电话，快递入库了（就是到了），那么等下一次时间到了，张三打电话知道快递到了，那么这样的通讯算不算实时通讯？很显然，不算，中间有十分钟的时间差，还不算给快递员打电话的等待时间（抽象的解释：每次request的请求时间间隔等同于十分钟，请求解析相当于等待）
2. 假如说张三所在的小区每天要收很多快递，每个人都采取主动给快递员打电话的方式，那么快递员需要以多快的速度接到，其他人打电话占线也是问题（抽象解释：请求过多，服务端响应也会变慢）

4.2.2 总的来看，Ajax轮询存在的问题：

1. 推送延迟。
2. 服务端压力。配置一般不会发生变化，频繁的轮询会给服务端造成很大的压力。
3. 推送延迟和服务端压力无法中和。降低轮询的间隔，延迟降低，压力增加；增加轮询的间隔，压力降低，延迟增高

5. websocket的改进

一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端中断连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实现了“真·长链接”，实时性优势明显。

5.1 websocker连接示例：

客户端：我要建立websocket连接
服务器端：好的，已经切换到websocket协议，websocket连接已经建立
客户端：有什么消息要及时告诉（推送）我
服务器端：好的
服务器端：xxxxxx
服务器端：yyyyyyy
。。。。。

5.2 WebSocket有以下特点：

• 是真正的全双工方式，建立连接后客户端与服务器端是完全平等的，可以互相主动请求。而HTTP长连接基于HTTP，是传统的客户端对服务器发起请求的模式。
• HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后，之后交换的数据都不需要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）

6. WebScoket协议

HTTP的生命周期通过Request来界定，也就是Request一个Response，那么在Http1.0协议中，这次Http请求就结束了。在Http1.1中进行了改进，是有一个connection：Keep-alive字段，也就是说，在一个Http连接中，可以发送多个Request，接收多个Response。但是必须记住，在Http中一个Request只能对应有一个Response，而且这个Response是被动的，不能主动发起。

WebSocket是基于Http协议的，或者说借用了Http协议来完成一部分握手，在握手阶段与Http是相同的。我们来看一个websocket握手协议的实现，基本是2个属性，upgrade，connection。

来自客户端的握手的形式如下：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

而来自服务器的我收的看起来像如下形式：

多了下面2个属性：

Upgrade:webSocket
Connection:Upgrade

这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

• Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：泥煤，不要忽悠窝，我要验证尼是不是真的是Websocket助理。
• Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~
• Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft （协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦，大家都使用的一个东西。

7. WebScoket的实现

7.1 客户端（浏览器）实现

7.1.1 websocket对象

7.1.2 websocket事件

7.1.3 websocket方法

7.2 服务端实现

7.2.1 Endpoint对象

编程式：

package javax.websocket;

public abstract class Endpoint {
    public Endpoint() {
    }

    public abstract void onOpen(Session var1, EndpointConfig var2);

    public void onClose(Session session, CloseReason closeReason) {
    }

    public void onError(Session session, Throwable throwable) {
    }
}

注解式：

7.2.2 服务端如何接收客户端发送的数据

通过session添加MessageHandler消息处理器来接收消息，当采用注解方式定义Endpoint时，我们还可以通过@OnMessage注解指定接收消息的方法

7.2.3 服务器如何推送数据给客户端

参考：
https://blog.csdn.net/yexudengzhidao/article/details/92846600