Sitemap

HTTP Keep-Alive

4 min readJul 2, 2022

--

HTTP stands for Hypertext Transfer Protocol is an application-layer protocol. Mainly designed for communication between web browser and web servers by transmitting hypermedia documents such as HTML. HTTP is built on top of the TCP. So understanding how TCP works is must to continue. You can learn everything about TCP three-way handshake here. There are two types of HTTP.

  • Non-persistent HTTP or HTTP 1.0
  • Persistent HTTP or HTTP 1.1

Non-persistent connection takes 2 RTT(Round Trip Time) plus transmission time for a single request(object transmission). First it establishes the connection between server and client. The second RRT is taken to request and send the message. Non-persistent HTTP connections are closed after each request. For an example, let’s assume that our browser loads a website which takes 10 different files(Javascript, css etc). In order to load this website the browser have to create new connections to request each of these 10 files. This process can cost high page load time.

Let’s assume that client send a request but server is busy executing other process. In this case the client or HTTP connection it self will close the connection. By using a header called keep-alive we inform the server to keep the connection by sending a ping. When we have to send multiple requests also keep-alive keep the connection between the client and the server.

Get Sahan Vithanage’s stories in your inbox

Join Medium for free to get updates from this writer.

On the other hand, Persistent HTTP connection(Keep-alive header is enabled by default in HTTP 1.1) allows single TCP connection to remian open for multiple HTTP requests and responses. Persistent connection also takes 2 RTT for the connection and then transfers as many objects, as wanted. We already know that TCP connection first requires 3-way handshake before data transmission. Because of keep-alive header make sure to remain TCP connection open (no need of multiple 3-way handshakes), it reduces the network latency.

Implementation

First we write a simple Express program and run.

Press enter or click to view image in full size
server.js

run the server.

Press enter or click to view image in full size
terminal

Now open wireshark and filter the traffic into port 8191(tcp.port==8191). Now open the url in the browser(localhost:8191/wait).

First use-case

Press enter or click to view image in full size
use-case 1

First we can see the standard TCP handshake. Then we send the request and get the response. Next the server send FIN set packet and client acknowledges(ACK) but client doesn’t terminate the connection, instead it keep sends keep-alive headers. Then the server send reset packet(RST). After sometime the connection will be closed.

Second use-case

Next let’s again start from begining and hit the url(https://medium.com/send%20requests) multiple times. We can see now there’s no FIN set packet as client and server keep talking to the each other, the backend/server doesn’t try to close the connection. This what persisten HTTP is, to keep this channel up we sent SYN only once(just a single connection).

Press enter or click to view image in full size
use-case 2

Third use-case

Now again let’s send the request(incognito tab)and just after server close the connection, let’s close our browser too. In wireshark we can see that client close the connection(send FIN packet) because we close the browser tab.

Press enter or click to view image in full size
use-case 3

Fourth use-case

Now let’s modify our program so that server waits 1min to response.

Press enter or click to view image in full size
server.js

After 45sec of sending the request keep-alive headers are visible on traffic. Because the server didn’t response. Then server acknowledges the keep alive headers. After 60sec server responses. Then after the server is acknowledged server send the FIN packets(terminate connection). Then client acknowledges server but keep sending keep-alive headers. Then the server send reset packet(RST). After sometime the connection will be closed.

Press enter or click to view image in full size
use-case 4

Fifth use-case

Let’s run the server and send the request. While the client waits for the server response, let’s kill the server. In this case client send the request but server is killed. Now server sends reset packets(connection is closed) becuase the client/browser try to establish a new connection. So If a server unexpectedly closes a connection it can be the client doesn’t sending keep-alive headers.

Press enter or click to view image in full size
use-case 5

--

--