Web Socket

Web Socket

Web Socket生命周期

Socket的生命周期是这样：

如图

所有的一切都发生在 TCP Socket里边。首先一个常规的HTTP请求会要求服务器更新Socket并协商，这个就叫做HTTP握手

然后消息就可以在Socket里边来回传送，直到这个消息的被主动关闭，在主动关闭的时候关闭的原因也会被通信。

HTTP握手

·每一个Web Socket开始的时候都是一个简单的HTTP Socket

·客户端首先发送一个Get请求到服务器,Get请求来请求升级为Socket

·如果服务器同意的话， Socket就从这时候开始就变成了Web Socket

如图

同意的状态码就是101。

以下是请求升级的那个请求：

如图：

升级请求他 upgrade web socket，表示请求从 socket升级为web socket，他的请求是HTTP的。然后这里边有一些比如说WebSocket-Key实际上是比较重要的，它能防止缓存的问题。

如图：

服务器理解这个请求之后，并且同意以后，它的响应就是这样的，它返回101这个状态码表示切换协议是Switching Protocols，如果返回的不是101，那么浏览器就会知道服务器没有处理 WebSocket的能力。

此外 head里边还有一个 upgrade是变成web socket，而这里边有一个WebSocket-accept。这串东西是根据 Key，它俩是对应的。具体要看文档，然后我们看一下消息类。

消息类型

·web socket它的消息类型可以是文本，也可以是二进制，同时也包括控制类的消息，比如说Ping/Pong和关闭。

·每一个消息它有一个或者是多个frame组成：
如图：

在这里边这一个消息里边有三个frame，这里边的frame它都是二进制的，所以说如果是发送的文本的话，那么首先也会转化成二进制，frame里边还有若干个叫header bits。

这些header bits有的可以表示这个frame是否是消息的最后一个frame，有的可以表示消息的类型，有的可以表示消息是否被毙了(客户端到服务器端的消息被掩蔽了)

为了防止缓存投毒，就是使用恶意数据替换缓存，有的可以设置payload的长度，payload会占住占据frame的剩下的地方，但实际上使用的时候基本不会察觉到 frame，它都是在后台处理的，你能看到的完整的消息，但是在浏览器调试的时候，你看到的是frame挨个传递进来，而不是整个消息。