为什么会出现HTTP，WebSocket？

假设1984年，人们使用TCP协议通讯，假设那时候还没网页浏览器，都是通过各种软件直接通讯。假设到了1986，人们使用浏览器浏览网页，假设当时电脑时100MHz，100M内存。

早年tcp链接数量有限制，不是内存，主要是select函数效率问题，select要轮询所有连接才能确定有哪些已经就绪。

在引入epoll/kqueue/完成端口之后，效率问题解决了，大量并发TCP连接就不是问题了，看过2013年的论文，有人用java在一台pc上支持50万个TCP长连接。

于是服务器要求“所有客户端，打开网页之后，必须关闭TCP连接”。这就是HTTP的初衷。按照这个协议，服务器接受TCP连接，几秒钟之内读取数据，检验之后，回复数据，断开连接，节省“资源”。

等到二十年后，QQ桌面版好好的，QQ网页版用的越来越多。由于浏览器都是连接之后很快断开，QQ网页版，只能靠各种polling方式持续交互数据（HTTP keep-alive也有自己的缺点），浪费大量的带宽（这时候带宽的费用就大了），同时客户端收到消息也不及时，还有各种其它问题。QQ网页版想直接用TCP协议长时间连接，但是QQ网页版能做的，都是浏览器允许做的。

可以说，websocket的出现，就是因为浏览器不支持TCP直连，不给开后门。于是“希望所有的浏览器都能够直接进行TCP连接”，于是浏览器出现了websocket协议。所以，因为某些原因，人们在TCP上面弄了一个HTTP协议，把TCP支持的一些特性删除了，然后若干年之后想要那些被删除的特性，返回TCP，于是出现了WebSocket。WebSocket实际上可以看作HTTP的降级！

“不是WebSocket基于HTTP，而是可以看成可以看成可以看成HTTP基于WebSocket”。

WebSocket 不是 HTML5 的东西。

WebSocket 是一个协议，归属于 IETF。

WebSocket API 是一个 Web API，归属 W3C。

两个规范是独立发布的。

广义上的 HTML5 里面包含的是 WebSocket API，并不是 WebSocket。简单的说，可以把 WebSocket 当成 HTTP，WebSocket API 当成 Ajax。

只是因为 WebSocket 对于非 Web 部分的意义不大（毕竟直接用 TCP 就好了），所以从现实角度的概率上而言 WebSocket 目前基本只会通过 Web API 里的 WebSocket API 来使用。但并不等于 WebSocket 属于 WebSocket API。

HTTP是运行在TCP协议传输层上的应用协议，而WebSocket是通过HTTP协议协商如何连接，然后独立运行在TCP协议传输层上的应用协议。你需要知道WebSocket仅仅是利用了HTTP协议做连接请求。WebSocket相当于一个简化版的TCP传输子层（实际上WebSocket也是应用层协议）。WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。

如果你要问为什么HTTP不是长连接，原因是早期的HTTP在发起每个请求，响应完成后就会关闭Socket。但是后来加了多路复用KeepAlive协议后HTTP协议已经可以实现长连接了，可以处理长连接事务了。至于添加WebSocket特性，是为了更好、更灵活，轻量的与服务器通讯。因为WebSocket提供了简单的消息规范，可以更快的适应长连接的环境，其实现在HTTP协议自身就可以做，但是不太轻便。

为什么HTML4不支持WebSocket？

WebSocket的协商机制HTML4底层API没有实现。