HOL(Head of Line) Blocking issue
It’s a quasi-term. Let’s just try to understand it.
There are only 65,535 ports available on a computer. The ports from 0 to 1023 are considered system ports and are generally used for common services like DNS, SMTP, and HTTP. Higher numbered ports are considered ‘dynamic’ and will be assigned if needed by any programs. So considering that we can say that there will be a limit on the number of connections while having communication with the computer. — We know that TCP needs a connection to communicate with the server and HTTP uses TCP as a transport-layer communication. So, this limitation is the cause of the HOL issue for HTTP, yeah, that simple 😇😇.
Because of this issue, every browser/client will have limited connections. 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 others to complete the process. So the head of line requests blocks the subsequent ones.
There were many workarounds, but the popular one was pipelining that also turned out to be a disaster. If you know about HTTP1, It is basically a request and response protocol: the browser asks for a resource (be it a HTML page, a CSS file, an image… whatever) and then waits for the response. During this time that connection cannot do anything else — it is blocked waiting on this response. In HTTP1, pipelining came, It helped to send more requests while waiting. Responses must still come back in order requested so it is not a true multi-request protocol but was a good improvement. After pipelining, the HOL issue became more apparent on connection level, but it was not over because if the first request takes a long time then all the other requests are queued up behind it, even if they are ready to go.
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. 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. Let’s talk about QUIC protocol in another blog.
Note: It has taken almost 20 years to solve this issue 🙃🙃🙃🙃.
References:
