ajax – WebSockets协议与HTTP

WebSockets更适合涉及低延迟通信的情况，特别是对于客户端到服务器消息的低延迟。对于服务器到客户端数据，您可以使用长期连接和分块传输获得相当低的延迟。然而，这不会帮助客户端到服务器的延迟，这需要为每个客户端到服务器消息建立新的连接。

您的48字节HTTP握手对于真实世界的HTTP浏览器连接是不现实的，其中作为请求的一部分(在两个方向上)发送通常几千字节的数据，包括许多报头和cookie数据。以下是使用Chrome的请求/响应示例：

请求示例(2800字节，包括Cookie数据，490字节，无Cookie数据)：

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML,like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

响应示例(355字节)：

HTTP/1.1 200 OK
Server: nginx
Date: Wed,13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed,13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60,private
Expires: Wed,13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

HTTP和WebSockets具有相同大小的初始连接握手，但是对于WebSocket连接，初始握手执行一次，然后小消息只有6字节的开销(头部为2字节，掩码值为4字节)。延迟开销不是从头的大小，而是从逻辑到解析/处理/存储那些头。此外，TCP连接建立延迟可能是比每个请求的大小或处理时间更大的因素。

2)为什么实现它而不是更新HTTP协议？

有努力重新设计HTTP协议以实现更好的性能和更低的延迟，如SPDY,HTTP 2.0和QUIC.这将改善正常HTTP请求的情况，但是很可能WebSockets和/或WebRTC DataChannel将仍然较低客户端到服务器数据传输的延迟比HTTP协议(或者它将被使用在一个看起来很像WebSockets的模式)。

更新：

这里是一个思考Web协议的框架：

> TCP：低级，双向，全双工和保证的顺序传输层。没有浏览器支持(通过插件/ Flash除外)。
> HTTP 1.0：在TCP上分层的请求 – 响应传输协议。客户端发出一个完整的请求，服务器给出一个完整的响应，然后关闭连接。请求方法(GET，POST，HEAD)对服务器上的资源具有特定的事务意义。
> HTTP 1.1：维护HTTP 1.0的请求 – 响应性质，但允许连接保持打开多个完整请求/完全响应(每个请求一个响应)。在请求和响应中仍然具有完整的标头，但连接被重用并且未关闭。 HTTP 1.1还添加了一些额外的请求方法(OPTIONS，PUT，DELETE，TRACE，CONNECT)，这些方法还具有特定的事务含义。然而，如在HTTP 2.0草案提案的introduction中所指出的，HTTP 1.1流水线不被广泛部署，因此这极大地限制了HTTP 1.1的用于解决浏览器和服务器之间的延迟的效用。
>长轮询：对服务器不立即响应(或仅部分响应报头)到客户端请求的HTTP(1.0或1.1)的“hack”排序。在服务器响应之后，客户端立即发送新的请求(如果通过HTTP 1.1，则使用相同的连接)。
> HTTP流传输：允许服务器向单个客户端请求发送多个响应的各种技术(multipart / chunked响应)。 W3C正在使用文本/事件流MIME类型将其标准化为Server-Sent Events。浏览器API(非常类似于WebSocket API)被称为EventSource API。
>彗星/服务器推送：这是一个包括长轮询和HTTP流的总称。 Comet库通常支持多种技术来尝试并最大化跨浏览器和跨服务器支持。
> WebSockets：基于传输层的内置TCP，使用HTTP友好的升级握手。与TCP(流传输)不同，WebSockets是基于消息的传输：消息在线路上分隔，并在传递到应用程序之前完全重新汇编。 WebSocket连接是双向的，全双工的和长期的。在初始握手请求/响应之后，没有事务语义，并且每个消息开销非常少。客户端和服务器可以在任何时间发送消息，并且必须异步地处理消息接收。
> SPDY：Google发起了使用更高效的有线协议扩展HTTP，但是维护所有HTTP语义(请求/响应，Cookie，编码)的提议。 SPDY引入了新的成帧格式(带有长度前缀的帧)，并且指定了将HTTP请求/响应对分层到新的成帧层上的方式。可以压缩报头，并在建立连接后发送新的报头。在浏览器和服务器中存在SPDY的真实世界实现。
> HTTP 2.0：具有与SPDY类似的目标：减少HTTP延迟和开销，同时保留HTTP语义。当前草案来自SPDY，并定义了一个升级握手和数据框架，它与用于握手和框架的WebSocket标准非常相似。另一个HTTP 2.0草案提案(httpbis-speed-mobility)实际上将WebSockets用于传输层，并将SPDY复用和HTTP映射添加为WebSocket扩展(在握手期间协商WebSocket扩展)。
> WebRTC/C++U-WebRTC：允许浏览器之间建立对等连接的建议。这可以实现较低的平均和最大等待时间通信，因为作为底层传输是SDP /数据报而不是TCP。这允许分组/消息的无序传送，这避免了由延迟所有后续分组的传送的丢弃分组引起的延迟尖峰的TCP问题(以保证按序传送)。
> QUIC：是一个旨在减少Web延迟的实验协议。表面上，QUIC非常类似于在UDP上实现的TCP TLS SPDY。 QUIC提供等价于HTTP / 2的复用和流控制，等同于TLS的安全性，以及等同于TCP的连接语义，可靠性和拥塞控制。因为TCP在操作系统内核和中间件固件中实现，对TCP进行重大更改是不可能的。然而，由于QUIC是建立在UDP之上的，它没有这样的限制。 QUIC是针对HTTP / 2语义设计和优化的。

参考文献：

> HTTP：

> Wikipedia HTTP Page
> W3C List of HTTP related Drafts/Protocols
> List of IETF HTTP/1.1 and HTTP/2.0 Drafts

>服务器发送事件：

> W3C Server-Sent Events/EventSource Candidate Recommendation
> W3C Server-Sent Events/EventSource Draft

> WebSockets：

> IETF RFC 6455 WebSockets Protocol
> IETF RFC 6455 WebSocket Errata

> SPDY：

> IETF SPDY Draft

> HTTP 2.0：

> IETF HTTP 2.0 httpbis-http2 Draft
> IETF HTTP 2.0 httpbis-speed-mobility Draft
> IETF httpbis-network-friendly Draft – 一个旧的HTTP 2.0相关提议

> WebRTC：

> W3C WebRTC API Draft
> List of IETF WebRTC Drafts
> IETF WebRTC Overview Draft
> IETF WebRTC DataChannel Draft
> Microsoft CU-WebRTC Proposal Start Page

> QUIC：

> QUIC Chrominum Project
> IETF QUIC Draft