In our previous article, we explained HTTP/1.0 and HTTP/1.1. It ends with the disadvantage of HTTP/1.1 and highly recommend you to spend some minutes in my previous articles.
*Recap *
HTTP/1.1 reuses TCP connections by keeping the sockets alive. If a client makes multiple requests, all the requests have to use the same connection to save resources. If a browser needs to render a webpage, it needs to make a number of API calls to get all the resources. Because they share a single TCP connection, API calls have to wait in a queue to get a chance to use it.
Immediate Patch Work Browsers open more than one connection (let's say 6) to make multiple API calls at the same time, but the number of connections has a strict resource limit.
What if we want to make more than 6 API calls? HTTP/2.0
MULTIPLEXING
To make API calls at the same time, HTTP/2 breaks the HTTP message into small pieces called frames. To identify the API calls from each other, HTTP/2 gives them a unique ID called a Stream ID. It adds this Stream ID to the frames before handing them down to TCP, which helps the computer on the other end separate and rebuild the API calls correctly.
SERVER PUSH
To render the website fast and fully utilize multiplexing, the server pushes multiple resources in advance before the API call is made by the client. For example, if we make an API call for an HTML page which has style.css in the style tag, the server also pushes the style.css file along with the HTML file using different Stream IDs. The client can accept this stream and store it in cache, or it can reject it. (Note: Modern browsers like Chrome are actually removing this feature now because it is too hard to manage caches efficiently, but this is exactly how it was designed to work.)
SECURE BY DEFAULT & ALPN
TLS is a mechanism to make API calls secure by encrypting the data. While the HTTP/2 rulebook technically allows unencrypted connections, all major web browsers strictly require TLS for HTTP/2. ALPN (Application-Layer Protocol Negotiation) is part of the TLS handshake. It is a negotiation where the client presents all the HTTP versions it supports, and the server selects the highest version it can support.
HEADER COMPRESSION (HPACK)
In HTTP/1.1, headers are sent as plain text in every request, which wastes bandwidth. HTTP/2 uses HPACK to compress these headers. It uses dictionaries (static and dynamic tables) to replace common text with tiny numbers (e.g., sending the number "2" instead of the text "GET"). This makes requests much smaller and faster.
BINARY PROTOCOL
Instead of sending messages in plain text, HTTP/2 converts everything into binary (0s and 1s). The compressed headers are packed into a HEADERS frame, and the data is packed into a DATA frame. Because it is binary and explicitly labeled, computers can process it instantly without wasting time scanning for text line breaks.
Top comments (0)