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 the connection with WebSocket, client, and server exchange data per frame which is 2 bytes each, compared to 8 kilobytes of HTTP header when you do continuous polling.
Why do 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 – https://en.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 protocols work over TCP, so all TCP issues with long-live connections are still there.
Questions:
- Why is the WebSockets protocol better?
- Why was it implemented instead of updating the HTTP protocol?
Best Answer
1) Why is the WebSockets protocol better?
WebSockets is better for situations that involve low-latency communication especially for low latency for client to server messages. For server to client data you can get fairly low latency using long-held connections and chunked transfer. However, this doesn't help with client to server latency which requires a new connection to be established for each client to server message.
Your 48 byte HTTP handshake is not realistic for real-world HTTP browser connections where there is often several kilobytes of data sent as part of the request (in both directions) including many headers and cookie data. Here is an example of a request/response to using Chrome:
Example request (2800 bytes including cookie data, 490 bytes without cookie data):
Example response (355 bytes):
Both HTTP and WebSockets have equivalent sized initial connection handshakes, but with a WebSocket connection the initial handshake is performed once and then small messages only have 6 bytes of overhead (2 for the header and 4 for the mask value). The latency overhead is not so much from the size of the headers, but from the logic to parse/handle/store those headers. In addition, the TCP connection setup latency is probably a bigger factor than the size or processing time for each request.
2) Why was it implemented instead of updating HTTP protocol?
There are efforts to re-engineer the HTTP protocol to achieve better performance and lower latency such as SPDY, HTTP 2.0 and QUIC. This will improve the situation for normal HTTP requests, but it is likely that WebSockets and/or WebRTC DataChannel will still have lower latency for client to server data transfer than HTTP protocol (or it will be used in a mode that looks a lot like WebSockets anyways).
Update:
Here is a framework for thinking about web protocols:
text/event-streamMIME type. The browser API (which is fairly similar to the WebSocket API) is called the EventSource API.References: