title: WebSockets protocol vs HTTP
body: <p>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.</p>
  <p>For example (arguments of WebSocket lovers):</p>
  <blockquote>
  <p>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. - <a href="https://web.archive.org/web/20210812191126/http://www.websocket.org/quantum.html" rel="noreferrer">websocket.org</a></p>
  </blockquote>
  <p>HTTP supports streaming: request body streaming(you are using it while uploading large files) and response body streaming.</p>
  <blockquote>
  <p>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.</p>
  </blockquote>
  <p>Why do that 2 bytes not include TCP and under TCP protocols overhead?</p>
  <pre><code>GET /about.html HTTP/1.1
  Host: example.org
  </code></pre>
  <p>This is ~48 bytes HTTP header.</p>
  <p>HTTP chunked encoding - <a href="https://en.wikipedia.org/wiki/Chunked_transfer_encoding" rel="noreferrer">Chunked transfer encoding</a>:</p>
  <pre><code>23
  This is the data in the first chunk
  1A
  and this is the second one
  3
  con
  8
  sequence
  0
  </code></pre>
  <ul>
  <li>So, the overhead per each chunk is not big.</li>
  </ul>
  <p>Also, both protocols work over TCP, so all TCP issues with long-live connections are still there.</p>
  <h3>Questions:</h3>
  <ol>
  <li>Why is the WebSockets protocol better?</li>
  <li>Why was it implemented instead of updating the HTTP protocol?</li>
  </ol>