HTTP keep-alive

The most common issue software engineers or rather backend developers face is slow response time. Especially communication between microservices which has a major role in improving the performance of the application. The communication is mainly based on HTTP. In order to improve the performance, we need to understand how HTTP works.

HTTP has 2 main sub-components. Persistence and Non-persistence. Non-persistence HTTP is HTTP 1.2. In this case, both the server and the client open one connection and sends requests, and get the response in that time. But there is an issue with this method. Assumes we need to get 15 images from the server. Which means the client has to send 15 requests to get the images. In the meantime, the server might be handling some other process or this process. Nevertheless, the server will take quite a bit of time to send the responses back to the client. During this period, the client might think that the server has closed the connection because it won’t send the requests back soon. To get around this problem HTTP came with another version of it. HTTP 1.1 which is also known as Persistence HTTP. Sounds crazy right. Usually, is the other way round. First 1.1 and then 1.2. But who am I to decide. Anyway, this came up with a solution. In order to keep the connection alive, the client has to send a header called ‘Keep-alive’.

Let's try to understand this in 5 different scenarios. First, let's create a server

Server.js

Since this is a simple connection, I’ll be executing ‘http://localhost:8191/serverReq’ in the web browser acting as a client.

Now let's move on one by one.

1. We open a tab in the web browser, send a request and wait for the server to end the connection.

The first three lines of the above picture show the standard TCP handshake, if you look closely. I (the client) then send the request. After that, the server (8191) responds by sending an acknowledgment. Additionally, it sends the FIN flag to signal that it intends to cut off the connection. The client then acknowledges and attempts to communicate. But the connection has already been cut off by the server. As a result, the server sends the RST (reset) flag.

1. We open a tab in the web browser, send multiple requests and wait for the server to end the connection which will not happen.

It’s the same scenario as described above. The only difference is that the client (client meaning me) sends multiple requests instead of 1. Then the server acknowledges it. Sends the response. Then client acknowledges it. Then again sends the request. It’s a cycle of requests and responses. The main thing we have to notice is that the server doesn’t send the FIN flag. Why? Because we sent multiple requests repeatedly in one connection. If the SYN flag is sent once, that means it has communicated within one connection which makes it a persistent connection.

Get Shehara Luvis’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

3. We open a tab in the web browser, send a request and close the connection ourselves by closing the internet browser or the tab.

As usual, I (the client) send the request from the browser following the HTTP 3-way handshake. The server then sends the response after acknowledging the request. Similar to previously, the server will want to terminate the connection by sending the FIN flag. Following that, I closed the web browser window. This indicates that the client has also ended the connection by sending a FIN flag.

4. We open a tab in the web browser, send a request and wait for the response.

I made a slight change. I have purposely delayed the response.

If you look closely, the client sends the request at 0.0024 seconds. Let’s remove the decimals to make it easy. Basically I (the client) send the message at 0 seconds. Since I have programmed it to respond in 1 minute it should respond in 60 seconds. But at 45 sec. the client sends the server a keep-alive header informing that it’s still alive. And the server acknowledges it. After that at exactly 60 sec. the server responds to it.

5. We open a tab in the web browser, send a request, and purposely terminate the server.

In the previous scenarios, we either waited for the server to close the connection or closed the client. But now we send the request, and while the server is waiting for 1 min to send the response, we stop the server. Since I stopped the server after 45 sec. the client has already sent the keep-alive header and the server acknowledged it as well. After I stopped the server, the server can’t respond to the client’s request. Then it sends a RST (reset) flag as its trying to create a new connection.

You now realize how crucial it is to comprehend HTTP fundamentals while working with websites. Don’t make the same mistakes again now that you’re aware of it.

References

Dinesh, K., 2022. Something EVERY Software Engineer must know about HTTP (Demo). s.l.:Youtube.