HTTP Pipelining and Multiplexing

This week I learned about a feature introduced in HTTP 1.1 called Pipelining.

HTTP stands for Hyper Text Transfer Protocol. Clients (such as your web browser) communicate with servers (computers contain the websites data) by sending HTTP requests and receiving HTTP responses.

In HTTP 1.0, requests could only be sent in sequence one at a time on a single TCP connection.

Transmission Control Protocol (TCP) enables two hosts to establish a connection and exchange streams of data.

https://www.webopedia.com/TERM/T/TCP.html

After sending a request, you would need to wait for a response before sending the next request. The introduction of Pipelining in HTTP 1.1 allows you to send multiple requests over the same connection without awaiting the response.

However with pipelining you still have to receive the responses in the order they were sent. If the first request is very slow, you will have to wait for it before you can receive the next responses. This means the advantage of pipelining in HTTP 1.1 vs no pipelining is minimal.

In HTTP/2, pipelining has been replaced by Multiplexing. Multiplexing is actually asynchronous, meaning you receive the responses as soon as they are done no matter what order they were sent in.

It manages this by allowing both the client and server to break down the HTTP message into independent frames (which are binary pieces of data) with an associated stream ID. They are sent back as soon as they are ready and reassembled on the other end using the stream ID.

As with asynchronous development, multiplexing is very useful when trying to make applications and services as quick and responsive as possible. Removing potential blockers in the HTTP chain caused by large packets (known as head of line blocking issues) is very helpful. Multiplexing also allows you to do this in one connection, rather than multiple connections that would be needed in HTTP 1.0 and 1.1. There is a limit to the number of concurrent connections that can be made, which makes multiplexing much more scalable and efficient.

With HTTP/2 the TCP connection is also kept open for a certain amount of time after the last response, meaning you can re-use connections to a client. This is useful if you are making lots of requests in a short time frame, as you do not need to keep creating the connections.

Here is a comparison of the 3 methods.

You can find the list of all of my Knowledge Sharing posts here.