WebSockets协议vs HTTP

 

有很多关于websocket和HTTP的博客和讨论，许多开发人员和站点强烈提倡websocket，但我仍然不明白为什么。

例如（websocket爱好者的论点）：

HTML5 Web Sockets代表了Web通信的下一个发展 - 一种全双工的双向通信通道，通过Web上的单个套接字进行操作。 （http://www.websocket.org/quantum.html）

HTTP支持流式传输：请求正文流式传输（您在上传大型文件时使用它）和响应正文流式传输。

在与WebSocket建立连接时，客户端和服务器每帧交换两个字节的数据，而在连续轮询时，与8千字节的http头相比。

为什么2个字节不包含tcp和tcp协议开销？ 

GET /about.html HTTP/1.1
Host: example.org

这是约48个字节的http头。

http chunked编码 - http://ru.wikipedia.org/wiki/Chunked_transfer_encoding： 

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0
  • 所以，每个块的开销并不大。

    • 此外，这两种协议都是通过TCP协议工作的，因此所有具有长连接的TCP问题仍然存在。

    题：

  • 为什么websockets协议更好？
  • 为什么它实现而不是更新http协议？

    • 1）为什么WebSockets协议更好？

    WebSockets更适合涉及低延迟通信的情况，尤其适用于客户端到服务器消息的低延迟。 对于服务器到客户端的数据，您可以使用长时间连接和分块传输获得相当低的延迟。 但是，这对客户端到服务器的延迟无效，这需要为每个客户端到服务器的消息建立一个新的连接。

    您的48字节HTTP握手对于真实世界的HTTP浏览器连接而言并不现实，在这些连接中，经常会有几千字节的数据作为请求的一部分（双向）发送，包括许多标头和cookie数据。 以下是使用Chrome的请求/响应示例：

    请求示例（包含Cookie数据的2800字节，不含Cookie数据的490字节）： 

    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无论如何）。

    更新 ：

    这是一个思考网络协议的框架：

  • 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草案建议中所述，HTTP 1.1管道未广泛部署，因此这大大限制了HTTP 1.1解决浏览器和服务器之间延迟的实用性。
  • 长时间轮询 ：对HTTP（1.0或1.1）进行“破解”，其中服务器不会立即响应（或仅响应部分头部响应）客户端请求。 在服务器响应之后，客户端立即发送一个新请求（如果通过HTTP 1.1使用相同的连接）。
  • HTTP流 ：多种技术（多部分/分块响应），允许服务器向单个客户端请求发送多个响应。 W3C使用text/event-stream MIME类型将其标准化为Server-Sent Events。 浏览器API（与WebSocket API非常相似）称为EventSource API。
  • Comet /服务器推送 ：这是一个涵盖长时间轮询和HTTP流媒体的总称。 彗星库通常支持多种技术来尝试并最大化跨浏览器和跨服务器支持。
  • WebSockets ：使用HTTP友好的内置TCP的传输层升级握手。 与TCP是一种流式传输方式不同，WebSockets是一种基于消息的传输方式：消息在网络上被分隔，并在传送到应用程序之前被全部重新组装。 WebSocket连接是双向的，全双工和长期的。 在初始握手请求/响应之后，没有事务性语义，并且每消息开销很少。 客户端和服务器可能随时发送消息，并且必须异步处理消息接收。
  • SPDY ：谷歌提出的使用更有效的有线协议来扩展HTTP，但保持所有HTTP语义（请求/响应，cookies，编码）的提议。 SPDY引入了一种新的成帧格式（带长度前缀的帧），并指定了将HTTP请求/响应对分层到新的成帧层上的方法。 连接建立后，可以压缩标题并发送新的标题。 浏览器和服务器中有SPDY的真实世界实现。
  • HTTP 2.0 ：与SPDY具有相似的目标：减少HTTP延迟和开销，同时保留HTTP语义。 目前的草案来源于SPDY，并定义了与握手和组帧的WebSocket标准非常相似的升级握手和数据组帧。 另一个HTTP 2.0草案提案（httpbis-speed-mobility）实际上将WebSocket用于传输层，并将SPDY多路复用和HTTP映射作为WebSocket扩展添加（WebSocket扩展在握手期间进行协商）。
  • WebRTC / CU-WebRTC ：允许浏览器之间进行点对点连接的建议。 这可以实现较低的平均和最大延迟通信，因为底层传输是SDP /数据报而不是TCP。 这允许分组/消息的乱序传送，这避免了由丢弃的分组引起的延迟尖峰的TCP问题，这延迟了所有后续分组的传送（以保证按顺序传送）。
  • QUIC ：是一个实验性协议，旨在减少TCP的Web延迟。 表面上，QUIC与在UDP上实现的TCP + TLS + SPDY非常相似。 QUIC提供等效于HTTP / 2的复用和流控制，与TLS等效的安全性，以及与TCP等同的连接语义，可靠性和拥塞控制。 由于TCP是在操作系统内核和中间件固件中实现的，所以对TCP进行重大更改几乎是不可能的。 然而，由于QUIC是建立在UDP之上的，所以它没有这种限制。 QUIC针对HTTP / 2语义进行了设计和优化。

    • 参考 ：

  • HTTP ：
  • 维基百科HTTP页面
  • W3C HTTP相关草稿/协议列表
  • IETF HTTP / 1.1和HTTP / 2.0草稿列表
  • 服务器发送的事件 ：
  • W3C服务器发送的事件/事件源候选推荐
  • W3C服务器发送的事件/事件源草案
  • WebSockets ：
  • IETF RFC 6455 WebSockets协议
  • IETF RFC 6455 WebSocket勘误表
  • SPDY ：
  • IETF SPDY草案
  • HTTP 2.0 ：
  • IETF HTTP 2.0 httpbis-http2草案
  • IETF HTTP 2.0 httpbis-speed-mobility草案
  • IETF httpbis-network-friendly草案 - 一个较早的HTTP 2.0相关提案
  • WebRTC ：
  • W3C WebRTC API草案
  • IETF WebRTC草案列表
  • IETF WebRTC概览草案
  • IETF WebRTC DataChannel草案
  • 微软CU-WebRTC提案开始页
  • QUIC ：
  • QUIC Chrominum项目
  • IETF QUIC Draft

    • 你似乎认为WebSocket是HTTP的替代品。 不是这样。 这是一个扩展。

    WebSockets的主要用例是在Web浏览器中运行并从服务器接收实时数据的Javascript应用程序。 游戏就是一个很好的例子。

    在WebSockets之前，Javascript应用程序与服务器交互的唯一方法是通过XmlHttpRequest 。 但是这些有一个主要的缺点：服务器不能发送数据，除非客户端明确要求它。

    但新的WebSocket功能允许服务器随时发送数据。 这允许以低得多的延迟实现基于浏览器的游戏，而不必使用AJAX长轮询或浏览器插件等丑陋的黑客攻击。

    那么为什么不使用正常的HTTP与流请求和响应

    在对另一个答案的评论中，您建议只是异步流式传输客户端请求和响应主体。

    事实上，WebSockets基本上就是这样。 尝试从客户端打开WebSocket连接看起来就像是一个HTTP请求，但头部中的一个特殊指令（Upgrade：websocket）告诉服务器以这种异步模式开始通信。 WebSocket协议的第一次草案并没有太多，有些握手以确保服务器真正了解客户端想要异步通信。 但是后来才意识到，代理服务器会被这样的混淆，因为它们习惯于HTTP的通常请求/响应模式。 发现了针对代理服务器的潜在攻击情形。 为了防止这种情况，有必要使WebSocket流量看起来不像任何正常的HTTP流量。 这就是为什么在协议的最终版本中引入掩码密钥的原因。

    对于TL; DR，这里是2美分，对于你的问题更简单的版本：

  • WebSockets通过HTTP提供这些好处：

  • 连接期间的持久状态连接
  • 低延迟：服务器/客户端之间的近实时通信，因为不需要HTTP为每个请求重新建立连接的开销。
  • 全双工：服务器和客户端可以同时发送/接收

  • WebSocket和HTTP协议被设计为解决不同的问题，IE WebSocket旨在改进双向通信，而HTTP被设计为无状态，使用请求/响应模型进行分发。 除了因为遗留原因（防火墙/代理渗透）而共享端口之外，将它们组合成一个协议没有太多共同点。

    • 链接地址: http://www.djcxy.com/p/44701.html

    上一篇: WebSockets protocol vs HTTP

    下一篇: Connecting to HTML5 Websocket