WebSocket 学习
是一种有效利用 JavaScript 和 DOM 的操作，以达到局部 Web 页面替换加载的异步通信手段。
缺点是：利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求差生。
Comet
一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。
也就是说，基于原本的 Http，服务器在接收到请求后，会将响应至于挂起状态，当服务器内容有了更新，就会通过该响应返回给客户。
缺点是：为了保留响应，一次连接的持续时间也边长了。期间，为了维持连接会消耗更多的资源。
但是 Ajax 和 Comet 并没有解决 Http 本身的疼点。
在 TCP/IP 的应用层与运输层之间通过新加一层会话层，加入 SPDY，使用 SPDY 后，Http 协议额外获得以下的功能：
多路复用流
通过单一的 Tcp 连接，可以无限制处理多个 Http 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
赋予请求优先级
SPDY 不仅可以无限地并发处理请求，还可以给请求逐个分配优先级顺序，这样主要是为了在发送多个请求时，解决因带宽低而导致响应慢的问题。
压缩 Http 首部
压缩 Http 请求和响应的首部，这样通信产生的数据包数量和发送的字节数就更少了。
推送
支持服务器主动向客户端推送数据。这样，服务器可以直接发送数据，而不必等待客户端的请求。
服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免不必要的请求。
上面的功能可以发现，SPDY 在一定程度上消除了 Http 瓶颈的技术。但是 SPDY 也有它自身的缺点：
SPDY 基本上只是将单个域名（IP 地址）的通信进行多路复用，所以，一个 Web 网站上使用多个域名下的资源，改善效果就会搜到限制。
SPDY 必须使用 TLS 协议，所以这会导致建立连接的时间变长。
SPDY 在实际使用的效果不是很好。
知道Http2.0的人，其实就能理解 Http2.0 很大程度的借鉴了 SPDY 的技术，所以有人把 SPDY 看成是 Http2.0 的前身，也是可以理解的。
在 Http2.0 出现之前，通过使用 Ajax、Comet，就必须要使用 Http，如果使用 Http，就无法彻底解决瓶颈问题，这是出现了新的一种技术，就是 WebSocket，它正是为了解决这些问题而实现的一套新协议以及 API。
====================================================================================
通过上面的介绍，我们知道WebSocket 不是 Http，它就是一套独立的 Api。但是在使用中，还是要靠 Http 来建立通信。
那这里会有一个疑问：为什么 Ajax/Comet 是基于 Http 的，所以它们本质上所以 Http，但是 WebSocket 却不是呢？
答案是：
Ajax/Comet 发送请求、响应本质都是在 Http 协议上完成的
而 WebSocket 使用到 Http 的地方只有一个，那就是 连接的时候，在连接完之后，Http 就没用了，使用的都是 WebSocekt 的东西。所以 WebSocket 本质上不是 Http。
Http1.1 有这么些疼点：
可先后发送多个 http 请求,不用等待回复,但是回复必须按顺序一个一个回复.
客户端只能做请求，服务端只能做响应
这说明 Http1.1 是 半双工通信，半双工就相当于是“一条道的双向马路”，在一个时间任意方向只能过一辆车。
（Http2.0 则实现了全双工）
WebSocket 在客户端与服务器之间使用全双工通信标准。全双工通信允许数据在两个方向上同时传输，它在能力上相当于两个单工通信方式的结合。WebSocekt 建立了“多道的双向马路”，使得客户端和服务端都实现了请求和接收消息的功能。
所以数据之间的传输相较于 Http，效率上是快挺多的。
所以 WebSocket 也解决了 Ajax 和 Comet 的一些缺陷。
一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML 或图片等任意格式的数据。
由于是建立在 HTTP 基础上的协议，因此连接的发起方仍是客户端，而一旦确立 WebSocket 通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。 这也是全双工通信带来的效益。
所以，它可以很自由的实现下面几点：
推送功能
服务器可以向客户端推送数据，而无需等待客户端的请求
减少通信量
只要建立起 WebSocket，就希望一直保持连接状态。（这里的“希望”指的是，我们在开发中一般都会为 WebSocket 实现长连接，所以 WebSocket 协议的优势是建立在长连接之上）。
和 Http 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应的减少了。
我们知道，在 Http 建立连接后，WebSocekt 的通道也就建立了，但是这个 通道的建立并不是随着 Http 建立而建立。
WebSocket 有它自己的 “握手”，在 Http 建立后，还要再进行一次 WebSocekt 的握手，才算是真正建立 WebSocket 通道。
相比于 TCP3 次握手，WebSocket 就是“2 次握手”：
（1）握手—请求
为了实现 WebSoccket 通信，还需要用到 Http 的 Upgrade首部字段，告知服务器通信协议发送改变，以达到握手的目的：
上面的首部中：
Connecti
on
代表着要使用 Upgrade 的协议，即 WebSocket
Sec-WebSocket-Key
记录着握手过程中必不可少的键值
Sec-WebSocket-Protocol
记录使用的子协议
Sec-WebSocket-Version
记录 WebSocket 版本
（2）握手—响应
对于该请求，服务端返回状态码为 101 Switching Protocols 的响应：
响应的首部中：
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论