Understand HTTP/1.1

In this article, we are going to write about the HTTP/1.1 protocol in some depth and its disadvantages. In our previous articles, we discussed
sockets, how computers talk to each other through OS abstraction
IPv4 and IPv6: how computers identify each other
URL, how the internet abstracted the identification of computers to benefit the end user.

HTTP message

An HTTP message is nothing but a text message that follows some rules. These messages can be categorized into two types: request and response. This request and response analogy was already mentioned in a previous article; I highly recommend that you spend time on that or use some AI to learn quickly.

There are three parts of an HTTP message

1. Start line
2. Headers
3. Body, or we can say data. This is optional

Request Message Structure

<method> <request-URL> <version> 
<headers>

<entity-body>

Response Message Structure

<version> <status> <reason-phrase>
<headers>

<entity-body>

You can compare the example figure match with the message structure. The client is requesting an image from the server at www.joes.hardware.com.

The message from the client to the server is the request message. At the beginning, you can see “GET /specials/saw-blade.gif Http/1.1”

There are multiple versions of HTTP; each has completely different rules. By mentioning Http/1.0 in the request, the client indicates to the server that it follows Http/1.0 protocol and expects a response of the same version.

We have a URL path “/specials/saw-blade.gif” in the starter line. There are many resources like HTML, multiple images, and videos on the same server, but we request the saw-blade GIF image. To request the exact resource among others, we use a path / sub-url.

The starter line has “GET”, which indicates to the server what action is expected.

GET is one of the methods used in HTTP to request resources. Similarly we have

POST - to create an entity
PUT/PATCH - to update the existing entity
DELETE - to delete an entity
HEAD - to get only the metadata and to avoid body data to save bandwidth and memory
GET - to get the info/resources/services

From the next line, we have key-value pairs like Host, Accept. These are all meta info about the body data, the client’s information, and the client's expectations. Here, Host defines which server we need to talk to; many servers may run on the same address. ACCEPT tells the server it's expecting a file format.

Like ACCEPT and HOST, we have many headers which is used in the protocol, and we can create our own headers.

If the request message is POST or PUT, there is a need to send body data separately from the headers; we have to leave a blank line between the body and headers to show the difference. You can see that blank line in the response message in our example.

The headers and body data we discussed holds good for the response message, but the starter line of the message has a slight change. We have the version in the request line, followed by the status code and a message.

The status code tells the client about the server’s reaction to the request. Each number has its own meaning. I mentioned some below, and if we find any new headers and status codes, we can refer to the documentation. We can eventually get used to this, instead of memorizing.

200 - success
201 - successfully created (typically used after a POST request creates a new entity)
204 - success but nothing to return (this is the code for when the server processes the request but has no body data to send back)
301 / 302 - redirect (the resource has moved to a new URL)
304 - not modified (tells the client's browser to just use the cached version it already has)
401 - unauthorized (client needs to log in or authenticate)
403 - server understands but is not giving a response due to security reasons (forbidden)
404 - not found
500 - internal server error (a generic server-side crash or error)
502 - bad gateway (the server acting as a proxy received an invalid response from another server)

The last one, “OK”, is just the message to the client. We can override this, and it has less significance than the status code.

Connection Management

We are done with the messages; this HTTP 1.1 protocol is completely based on the Transmission Control Protocol (TCP). The application developers hand over the request message to the TCP socket and get the response from the TCP socket. In our previous article, we discussed about the article, i highly encourage you to spend some time learning from any source.

Before data transfer happens between two TCP sockets, we need to establish a connection.

The mental model of a TCP connection is two parallel pipes: one for server-to-client data flow and another for client-to-server. I name those pipes pipe1 and pipe2.

1. The client side will send a SYN message to the server, which is the request to establish a connection ( for pipe1 ).

2. The server sends back an ACK + SYN message to the client, which acknowledges the SYN from the client ( pipe1 created for data from client to server ) and SYN, which indicates a connection request for the creation of pipe2

3. The client sent back the ACK to the server ( pipe2 created for data from server to client ).

These 3 are called the TCP handshake, which establishes a TCP connection. After this, we can send the data. The HTTP message is made into small chunks called segments and sent through the connection.

In HTTP/1.0, each API request has its own TCP connection; similarly, the connection after the response message. Practically, we need to make many requests to the same server, so in HTTP/1.1 we decided to reuse the TCP connection. TCP connection is maintained for some amount of time to reuse; however, if computers want to free their resources, they can close the connection at any time.

1. Client sends FIN ( finish message ), requesting to close;
2. Server sends back ACK, closing pipe1.
3. When the server finishes sending data, it sends FIN ( requesting to close pipe2 )
4. Client sends back ACK, closes pipe2, informing the server.

Disadvantages and beginning of HTTP/2.0

In HTTP/1.0, every request has its own TCP connection, which takes lots of resources and an unnecessary handshake round trip. To overcome this, we reused TCP connection in HTTP/1.1. Now, even though we are using the same connection for multiple requests, we were making requests in a serialized manner (one by one). For example, if we want to see a website that has 3 images. The API call for HTML was carried out first, then requests for image1, image2, and image3. Even if image3 is very small and it will take a very small time, it has to wait for image1 and image2. If image1 is very large, it takes a very long time to load, and this blocks other API calls for a long time. Though there is progress, the inactive UI makes the user feel the website is not working. We are going to overcome this with HTTP/2.0