WebSocket可以被视作 HTTP 协议为了支持长连接的一个补丁。
keep-alive connection
HTTP是一个请求<->响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端->服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和编程实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。
Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。市场上 的大部分Web服务器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。
对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连 接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep- Alive功能对资源利用的影响尤其突出。
此功能为HTTP 1.1预设的功能，HTTP 1.0加上Keep-Aliveheader也可以提供HTTP的持续作用功能。
Keep-Alive: timeout=5, max=100
timeout：过期时间5秒（对应httpd.conf里的参数是：KeepAliveTimeout），max是最多一百次请求，强制断掉连接
HTTP/1.0
在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接
HTTP/1.1
在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close ，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它
Polling
所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。
传统的Polling实现方式比较单一，由客户端JavaScript脚本定时发送http请求。收到客户端请求后，服务端马上执行脚本查询，并且立即响应客户端。客户端等待的时间很短，客户端唯一要做的事情就是定时向服务端发出查询请求。
Long Polling
与Polling相比，Long Polling的客户端和服务端充满信任, 客户端只要说下自己想要什么, 服务器端可以不立即回复,而是等到满足条件才回复, 客户端也不需要老是问.
传统的Polling一般是由C向S询问：“有我的信件吗？”。S接到询问之后，会立即查询，并且把查询结果告诉C，不管有没有C的信件，要么回复：“嗯，你有X封信。”，要么回复：“没，没有你的信”。
而Long Polling是这样的，C向S发出询问：“有我的信件吗？”，S开始查询，如果有则回复C：“嗯，有你x封信”。如果没有，则不作任何回复，而是让C等着，自己一遍一遍地查询是否有订阅者的信。
换句话说：当S收到C的查询请求之后，Polling则只查询一次，并且把查询结果告诉C;而Long Polling收到请求之后，则会一遍一遍地查询，直到有消息才会响应C，不然一直hold Client。
Long Polling相较传统的Polling而言，最大的实惠在于：减少了请求次数。举个例子，假定一个用户每2小时内，有可能收到2条新消息。如果采用传通的Polling方式，每30秒发向服务端发送一次查询请求的话。则在这2小时内，服务器需要处理240(60*60*2/30)次请求，其中至少有238次请求是没有实际意义的。试想，如果是10000的并发量的话，这种浪费是很惊人的。相较而方，Long Polling没有那么浪费服务器资源来处理这些没有实际意义的请求。
客户端处理完服务器返回的信息后，再次发出请求，重新建立连接。这样周而复始。
Websocket
WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送
优点：长连接，双向、低延迟和易于处理错误。
缺点：需要特殊的服务器支持
通过第一个 HTTP request 建立了 TCP 连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。
有 multiplexing 功能，几个不同的 URL可以复用同一个 WebSocket 连接。
半死不活问题
WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket 真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。
比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。
而解决方案，WebSocket 的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态
Server-Sent Events(SSE)
HTML5功能，允许服务端推送数据到客户端。(单向)。当数据源有新数据，它马上发送到客户端，不需要等待客户端请求。这些新数据可能是最新闻，最新股票行情，来自朋友的聊天信息，天气预报等。SSE用于web应用程序刷新数据，不需要用户做任何动作。
支持代理服务器与认证技术。
如果需要发送大部二进制数据从服务端到客户端，WebSocket是更好的选择。
FlashSocket
WebSocket的替代品, 客户端JavaScript与Flash交互调用：JS调用Flash Socket接口发送数据，Flash Socket与服务器端Socket服务器通信
优点： 支持所有带flash的浏览器
缺点： 需要安装flash插件，要求打开防火墙的 843 端口，以便 Flash 组件能够执行 HTTP 请求来检索包含域授权的策略文件。
WebRTC
网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。2011年5月开放了工程的源代码，在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。