协议 vs HTTP

Question

There are many blogs and discussions about websocket and HTTP, and many developers and sites strongly advocate websockets, but i still can not understand why.

for example (arguments of websocket lovers):

HTML5 Web Sockets represents the next evolution of web communications—a full-duplex, bidirectional communications channel that operates through a single socket over the Web. ( http://www.websocket.org/quantum.html )

HTTP supports streaming: request body streaming(you are using it while uploading large files) and response body streaming.

During making connection with WebSocket, client and server exchange data per frame which is 2 bytes each, compared to 8 kilo bytes of http header when you do continuous polling.

Why does that 2 bytes not include tcp and under tcp protocols overhead?

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

This is ~48 bytes http header.

http chunked encoding - 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

• So, the overhead per each chunk is not big.

Also both protocol works over TCP, so all TCP issues with long-live connections are still there.

Question:

1. Why is websockets protocol better?
2. Why was it implemented instead of updating http protocol?

转载于:https://stackoverflow.com/questions/14703627/websockets-protocol-vs-http

Answer 1

You seem to assume that WebSocket is a replacement for HTTP. It is not. It's an extension.

The main use-case of WebSockets are Javascript applications which run in the web browser and receive real-time data from a server. Games are a good example.

Before WebSockets, the only method for Javascript applications to interact with a server was through XmlHttpRequest. But these have a major disadvantage: The server can't send data unless the client has explicitly requested it.

But the new WebSocket feature allows the server to send data whenever it wants. This allows to implement browser-based games with a much lower latency and without having to use ugly hacks like AJAX long-polling or browser plugins.

So why not use normal HTTP with streamed requests and responses

In a comment to another answer you suggested to just stream the client request and response body asynchronously.

In fact, WebSockets are basically that. An attempt to open a WebSocket connection from the client looks like a HTTP request at first, but a special directive in the header (Upgrade: websocket) tells the server to start communicating in this asynchronous mode. First drafts of the WebSocket protocol weren't much more than that and some handshaking to ensure that the server actually understands that the client wants to communicate asynchronously. But then it was realized that proxy servers would be confused by that, because they are used to the usual request/response model of HTTP. A potential attack scenario against proxy servers was discovered. To prevent this it was necessary to make WebSocket traffic look unlike any normal HTTP traffic. That's why the masking keys were introduced in the final version of the protocol.