本文主要包含WebSocket,HTTP,HTML5,http4,HTML4等相关知识,匿名希望在学习及工作中可以帮助到您
WebSocket是HTML5出的东西 也就是说HTTP协议没有变化 但HTTP是不支持持久连接的（长连接，循环连接的不算）
或者说WebSocket干脆就不是基于HTTP来执行的。但是。。。说不通啊。。。
他是怎么实现的呢？？为什么可以实现持久连接？？？？
-----------------------------
【【【【【【【【【【【【【【补充】】】】】】】】】】：：：：：
既然WebSocket和HTTP是两个协议 为什么要在HTML5才支持
又如果说HTML5 出来以后可以用WebSocket了 就说明WebSocket是本来就有点东西只是HTML4不支持而已 http4时代 如何使用WebSocket呢？？ 谢谢
我一个个来回答吧
一、WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）
首先HTTP有1.1和1.0之说，也就是所谓的keep-alive，把多个HTTP请求合并为一个，但是Websocket其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充可以通过这样一张图理解
有交集，但是并不是全部。
另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。
通俗来说，你可以用HTTP协议传输非Html数据，就是这样=。=
再简单来说，层级不一样。
二、Websocket是什么样的协议，具体有什么优点
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。
简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。
1) HTTP的生命周期通过Request来界定，也就是一个Request 一个Response，那么在HTTP1.0中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。
但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。
教练，你BB了这么多，跟Websocket有什么关系呢？
_(:з」∠)_好吧，我正准备说Websocket呢。。
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
在握手阶段是一样的
-------以下涉及专业技术内容，不想看的可以跳过lol:，或者只看加黑内容--------
首先我们来看个典型的Websocket握手（借用Wikipedia的。。）
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 你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁，它和 HTTP 有一些共性，是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求，但是对每个请求仍然要单独发 header；所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。它们建立的“长连接”都是伪.长连接，只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。
WebSocket 解决的第一个问题是，通过第一个 HTTP request 建立了 TCP 连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息。此外还有 multiplexing 功能，几个不同的 URI 可以复用同一个 WebSocket 连接。这些都是原来的 HTTP 不能做到的。
另外说一点技术细节，因为看到有人提问 WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket 真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。
比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。
而解决方案，WebSocket 的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态。 WebSocket 是一种协议，基于 TCP 协议；HTTP 也是一种协议，基于 TCP 协议。
连接要保持还是关闭是由你服务器应用来控制的。
WebSocket 协议和 HTTP 协议是两种不同的东西，它们扯上关系是只是因为：
客户端开始建立 WebSocket 连接时要发送一个 header 标记了 Upgrade 的 HTTP 请求，表示请求协议升级。
所以服务器端做出响应的简便方法是，直接在现有的 HTTP 服务器软件和现有的端口上实现 WebSocket 协议，重用现有代码（比如解析和认证这个 HTTP 请求。如果在 TCP 协议上实现，这两个功能就要重新实现），然后再回一个状态码为 101 的 HTTP 响应完成握手，再往后发送数据时就没 HTTP 的事了。
=====
看了补充，问题已经越来越奇怪了，变成了历史问题。这种概念上的问题多看点书很容易解决。
互联网一共才十几年历史，而 WebSocket 从提议变成推荐标准就需要几年，因为中间要经过大量的安全验证和实验。
Web 1 的时代人们访问 Web 页面是即停即走。Web 2 之后单个页面停留时间越来越长，页面功能越来越丰富——这时有了 RIA 的概念，改变了客户端的编程模型——更甚至许多实时应用根本不用离开页面，比如聊天、游戏应用。
客户端浏览器决定了客户端编程语言的能拥有的功能，以前如何做那些交互性很高的应用呢？
一些技术有 XHR，iframe, 实时性要求非常高的就只能用第三方插件，比如 Flash 或 Silverlight。
但 XHR 和 iframe 存在一些根本避免不了问题：1）每次交互就需要两个 HTTP 请求 2）即使单个 HTTP 请求也要传送很多字节（header 笨重）3）客户端不知道消息何时能够到达，只能轮询。服务器肯定会表示压力很大！
插件则需要额外安装，还有安全性问题和移动设备根本不能被支持的问题。
有了需要之后才有了解决方案—— WebSocket 就是这种灵丹妙药，看看主要特性：实时交互、服务器能够主动推送内容、只需要建立一次连接、快速（延迟小，每条消息可以小到两个字节）、开发者友好（接口简单，并是熟悉的事件模型）等等。
所以，HTML 4 选择权很小，是否要支持 WebSocket 依据需求和环境而定；而选择 HTML 5 的话，有了 socket 通信和图形编程的能力，能够开发出什么精彩应用只取决于你的想象力。
PS：如果要找现成方案，这个 Wiki 上有很多：https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills HTML5 是一个很宽广的概念，是对大量新 API 的总称。不存在 HTTP5 的概念，HTTP 最高的版本号是 1.1。简单来说，你可以完全抛开 HTML5 和 HTML4 的概念，只考虑浏览器要么支持 WebSocket，要么不支持。
WebSocket 跟其他 API 比较不一样的是，它不仅仅依赖于浏览器支持，同时要求服务器和代理（假若需要经过代理的话）支持。WebSocket 本质上跟 HTTP 完全不一样，只不过为了兼容性，WebSocket 的握手是以 HTTP 的形式发起的，如果服务器或者代理不支持 WebSocket，它们会把这当做一个不认识的 HTTP 请求从而优雅地拒绝掉。
如果你真的很想知道这个协议具体是如何操作的，建议还是去看 RFC：http://tools.ietf.org/html/rfc6455 websocket的实现已经有朋友提到了基于HTTP来发起
或者说WebSocket干脆就不是基于HTTP来执行的。但是。。。说不通啊。。。
他是怎么实现的呢？？为什么可以实现持久连接？？？？
-----------------------------
【【【【【【【【【【【【【【补充】】】】】】】】】】：：：：：
既然WebSocket和HTTP是两个协议 为什么要在HTML5才支持
又如果说HTML5 出来以后可以用WebSocket了 就说明WebSocket是本来就有点东西只是HTML4不支持而已 http4时代 如何使用WebSocket呢？？ 谢谢
回复内容：
额。。最高票答案没答到点子上，最后怎么跑到Nodejs上去了。。Websocket只是协议而已。。我一个个来回答吧
一、WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）
首先HTTP有1.1和1.0之说，也就是所谓的keep-alive，把多个HTTP请求合并为一个，但是Websocket其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充可以通过这样一张图理解
有交集，但是并不是全部。另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。
通俗来说，你可以用HTTP协议传输非Html数据，就是这样=。=
再简单来说，层级不一样。
二、Websocket是什么样的协议，具体有什么优点
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。
简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。
1) HTTP的生命周期通过Request来界定，也就是一个Request 一个Response，那么在HTTP1.0中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。
但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。
教练，你BB了这么多，跟Websocket有什么关系呢？
_(:з」∠)_好吧，我正准备说Websocket呢。。
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
在握手阶段是一样的
-------以下涉及专业技术内容，不想看的可以跳过lol:，或者只看加黑内容--------
首先我们来看个典型的Websocket握手（借用Wikipedia的。。）
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 你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁，它和 HTTP 有一些共性，是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求，但是对每个请求仍然要单独发 header；所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。它们建立的“长连接”都是伪.长连接，只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。
WebSocket 解决的第一个问题是，通过第一个 HTTP request 建立了 TCP 连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息。此外还有 multiplexing 功能，几个不同的 URI 可以复用同一个 WebSocket 连接。这些都是原来的 HTTP 不能做到的。
另外说一点技术细节，因为看到有人提问 WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket 真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。
比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。
而解决方案，WebSocket 的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态。 WebSocket 是一种协议，基于 TCP 协议；HTTP 也是一种协议，基于 TCP 协议。
连接要保持还是关闭是由你服务器应用来控制的。
WebSocket 协议和 HTTP 协议是两种不同的东西，它们扯上关系是只是因为：
客户端开始建立 WebSocket 连接时要发送一个 header 标记了 Upgrade 的 HTTP 请求，表示请求协议升级。
所以服务器端做出响应的简便方法是，直接在现有的 HTTP 服务器软件和现有的端口上实现 WebSocket 协议，重用现有代码（比如解析和认证这个 HTTP 请求。如果在 TCP 协议上实现，这两个功能就要重新实现），然后再回一个状态码为 101 的 HTTP 响应完成握手，再往后发送数据时就没 HTTP 的事了。
=====
看了补充，问题已经越来越奇怪了，变成了历史问题。这种概念上的问题多看点书很容易解决。
互联网一共才十几年历史，而 WebSocket 从提议变成推荐标准就需要几年，因为中间要经过大量的安全验证和实验。
Web 1 的时代人们访问 Web 页面是即停即走。Web 2 之后单个页面停留时间越来越长，页面功能越来越丰富——这时有了 RIA 的概念，改变了客户端的编程模型——更甚至许多实时应用根本不用离开页面，比如聊天、游戏应用。
客户端浏览器决定了客户端编程语言的能拥有的功能，以前如何做那些交互性很高的应用呢？
一些技术有 XHR，iframe, 实时性要求非常高的就只能用第三方插件，比如 Flash 或 Silverlight。
但 XHR 和 iframe 存在一些根本避免不了问题：1）每次交互就需要两个 HTTP 请求 2）即使单个 HTTP 请求也要传送很多字节（header 笨重）3）客户端不知道消息何时能够到达，只能轮询。服务器肯定会表示压力很大！
插件则需要额外安装，还有安全性问题和移动设备根本不能被支持的问题。
有了需要之后才有了解决方案—— WebSocket 就是这种灵丹妙药，看看主要特性：实时交互、服务器能够主动推送内容、只需要建立一次连接、快速（延迟小，每条消息可以小到两个字节）、开发者友好（接口简单，并是熟悉的事件模型）等等。
所以，HTML 4 选择权很小，是否要支持 WebSocket 依据需求和环境而定；而选择 HTML 5 的话，有了 socket 通信和图形编程的能力，能够开发出什么精彩应用只取决于你的想象力。
PS：如果要找现成方案，这个 Wiki 上有很多：https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills HTML5 是一个很宽广的概念，是对大量新 API 的总称。不存在 HTTP5 的概念，HTTP 最高的版本号是 1.1。简单来说，你可以完全抛开 HTML5 和 HTML4 的概念，只考虑浏览器要么支持 WebSocket，要么不支持。
WebSocket 跟其他 API 比较不一样的是，它不仅仅依赖于浏览器支持，同时要求服务器和代理（假若需要经过代理的话）支持。WebSocket 本质上跟 HTTP 完全不一样，只不过为了兼容性，WebSocket 的握手是以 HTTP 的形式发起的，如果服务器或者代理不支持 WebSocket，它们会把这当做一个不认识的 HTTP 请求从而优雅地拒绝掉。
如果你真的很想知道这个协议具体是如何操作的，建议还是去看 RFC：http://tools.ietf.org/html/rfc6455 websocket的实现已经有朋友提到了基于HTTP来发起