---

Must read dev article

HTTP Auth

HTTP1.1 and HTTP2 Animation

HTTP1

Only one request for one connection. If we want to send the second request we need to establish new tcp connection to that server

Every request to the server requires separate TCP connection

HTTP1.1

We could reuse the single tcp connection but still to solve the Head-of-line Blocking we are using the multiple TCP connections and every tcp connection is reused.

Pipelining

It also allows the pipelining. Client can send the multiple requests before waiting for each response for that request. The response must be received in the same order as the request. This is tricky to handle, so the support for the Pipelining is removed in the many browsers.

Head-of-line Blocking

The subsequent request of the same connection must wait for the previous request to complete.

HTTP Head of line blocking

Head of Line blocking in HTTP terms is often referring to the fact that each browser/client has a limited number of connections to a server and doing a new request over one of those connections has to wait for the ones to complete before it can fire it off.

The head of line requests block the subsequent ones.

HTTP/2 solves this by introducing multiplexing so that you can issue new requests over the same connection without having to wait for the previous ones to complete.

In theory, the pipelining of HTTP/1.1 also offered a way around HOL, but it was tricky and very error-prone to implement in practice. That has made it not get widely enabled on the web even up till today.

TCP Head of line blocking

HTTP/2 does however still suffer from another kind of HOL, namely on the TCP level. One lost packet in the TCP stream makes all streams wait until that packet is re-transmitted and received. This HOL is being addressed with the QUIC protocol...

QUIC is a "TCP-like" protocol implemented over UDP where each stream is independent so that a lost packet only halts the particular stream to which the lost packet belongs, while the other streams can go on.

HTTP/3 is being done over QUIC instead of TCP and TLS.

Multiple TCP connection

To keep the loading perfomrance in the acceptable level browsers normally keep multiple TCP connections to the same server and send request in parallel

HTTP2

HTTP Streams, where the multiple streams of request could sent to the same server on a single TCP connection. Unlike HTTP1.1 pipelining each stream is independent of each other.(It doesnot need to sent/receive in order). It solves the Head-of-line Blocking issue in the Application Layer but still the issue persists in the transport Layer.

source

HTTP2 streams(streams at Application layer) is like one request has multiple streams (kind of individual requests to the server). The Bottelneck is at Transport layer (TCP) so if there is any issue with that packet which carries 5 to 10 streams then it will be retransmitted again.

This is solved by the HTTP3 using UDP (stream is at transport layer).. based on the id only the lost id is retransmitted.

Push

HTTP3

The Head-of-line blocking is eliminated in the Transport layer by using the QUIC over UDP.

QUIC can easily handle the switch between one network to another. Since it not uses the TCP. It uses UDP and also the connection ID plays important role in the QUIC. So change in the IP address doesn't affect the performance

Ex: When we switch from WiFi to Cellular connection TCP will be teardown and establish new connection but in the QUIC its not the case.