HTTP Keep Alive and Handshake

The speed of a server might not be only due to the lack of instances. In order to finetune the performance of a server, the connection calls between the client and the server is a must know. Let’s dig deep into what actually happens in the http protocol.

http is running on the application layer of the connection and is run on top of the tcp layer when taking the connection layers into consideration.

There are 2 types of http protocols

  1. Non-persistent http (http 1.2)

Only used in legacy systems for a single simple back and forth communication call (to pass just one message. The steps include 1) opening the connection, 2) sending the message, 3) getting response, 4) closing connection. One downside of this protocol is, in order to send multiple messages, you need multiple connections.

  1. Persistent http (http 1.1)

There are 2 different sub protocols in persistent http called 1) with tunneling 2) without tunneling. By default, http 1.1 does everything with tunneling. So let’s look into that.

Persistent http with tunneling (http 1.1)

This too includes the same steps on 1) making the connection 2) sending the message 3) getting the response 4) closing connection. But in addition to the tcp connection protocol, the client might close the connection on its end in http 1.1. In order to overcome this issue, there is a technique called keep-alive which, sends a ping to the server asking to keep the connection alive.

Vocabulary

RTT — Rount Trip Time — The time taken for the client to receive back a packet, once a packet is sent to the server.

Demo

Let’s try out a demo project expressing the idea. The demo will use node, express and Wireshark for demonstration purpose.

This is how the simple server will look like. It will be listening in on port 8191 on my machine.

Add a filter to capture only the said port’s traffic on Wireshark on the loopback interface.

Just as discussed in the previous article, the connect starts with the handshake of [SYN],[SYN,ACK],[ACK], followed by the response which is the webpage.

Also, notice the Timestamp 43.103.5968… which shows the [FIN,ACK] from the server which signals the closing of the connection. Shortly afterwards, client sends the keep-alive packet (Notice timestamp 44.103.5968) which is followed by a series of few more Keep-alives. This final packet is the result of this, which is the server sending back a [RST,ACK] or a reset packet to the client. This signals the client that the connection must be reset.

Use Case 1

However, if the client kept requesting for more before the server sends any [FIN,ACK], (this could be achieved by refreshing the same url), you can notice that after the handshake and connection establishment, there will be no [FIN], as shown below.

Use Case 2

What if we close the browser right after we receive the response? This will show the handshake followed by the GET request from client to server, followed by ACK from the server, followed by the html response from the server, followed by the ACK from client to server (for the response). Then the server closes the connection using [FIN,ACK] which is then ACKed by the client. Meanwhile, as the browser got closed, the client side gets closed, terminating the connection.

Use Case 3

Let’s change the code so the request will come and hang for 1 minute before sending back the response.

Running this will initially show the handshake packets and GET request with its ACK. Meanwhile the server is waiting on the 60 seconds.

While waiting, the client send the keep-alive header to the server in order to check on the connection. Check on timestamp 45.005157. This is because, the server didn’t respond to the request made. But as the server is also waiting on the 60 seconds, the server sends back an ACK to the Keep-alive by the client.

After the 60 seconds have passed the server sends back the html response and both sides terminate the connection.

Use Case 4

What is the server is closed in the middle of this 60 seconds. Let’s try that. As the server’s connection is closed in the middle, but the client keeps requesting a packet, reset packets will be sent. But as there are no more servers to be connected, the connection will be terminated.

That’s it for today.

Thank you for reading! Until next time 👋🏽

References

  1. https://www.youtube.com/watch?v=Yf06faA5-JY
  2. https://www.haproxy.com/blog/http-keep-alive-pipelining-multiplexing-and-connection-pooling/

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store