WebSockets协议与HTTP

Question

关于websocket和HTTP有很多博客和讨论，许多开发人员和网站都强烈支持websockets，但我仍然无法理解为什么。

例如（websocket爱好者的参数）：

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

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

在与WebSocket连接期间，客户端和服务器每帧交换2个字节的数据，而连续轮询时则为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协议？

Answer 1

您似乎假设WebSocket是HTTP的替代品。它不是。这是一个扩展。WebSockets的主要用例是Javascript应用程序，它们在Web浏览器中运行并从服务器接收实时数据。游戏就是一个很好的例子。在WebSockets之前，Javascript应用程序与服务器交互的唯一方法是通过XmlHttpRequest。但这些都有一个主要的缺点：服务器无法发送数据，除非客户端已明确请求它。但新的WebSocket功能允许服务器随时发送数据。这允许实现具有低得多的延迟的基于浏览器的游戏，而不必使用诸如AJAX长轮询或浏览器插件之类的丑陋黑客。那么为什么不使用普通的HTTP与流式请求和响应在对另一个答案的评论中，您建议只是异步地流式传输客户端请求和响应正文。实际上，WebSockets基本上就是这样。尝试从客户端打开WebSocket连接首先看起来像HTTP请求，但标题中的特殊指令（Upgrade：websocket）告诉服务器开始以此异步模式进行通信。WebSocket协议的初稿并不仅仅是那些以及确保服务器实际理解客户端想要异步通信的一些握手。但后来人们意识到代理服务器会被它混淆，因为它们习惯于HTTP的通常请求/响应模型。一个潜在的攻击场景中对代理服务器被发现。为了防止这种情况，有必要使WebSocket流量看起来不像任何普通的HTTP流量。这就是为什么要引入屏蔽键的原因协议的最终版本。