Learning about the HTTP “Connection: keep-alive” header

A couple of weeks back, I was presenting the basics of HTTP and TCP at a Networking book club I am a part of. While preparing for the presentation, I learned about the default header in HTTP/1.1 — Connection: keep-alive — and found how important it is to an application’s performance.

HTTP has evolved from a one-line protocol intended to transfer HTML documents to a ubiquitously adopted protocol by most applications on the internet designed to transfer rich media in addition to text. When HTTP/1.1 was released, a number of improvements and optimizations were made from HTTP/1.0 and one of them was keep-alive/persistent connections. HTTP/1.1 and HTTP/2.0 are defined to use TCP so their performance also greatly depends on how TCP is configured. Let’s briefly go through some important aspects of TCP.

A little bit about TCP

TCP is a reliable protocol on top of an unreliable network. It provides various features like retransmission of lost data, in-order delivery, congestion control and avoidance, data integrity, and more. Every TCP connection

• begins with a 3-way handshake. You can also see this in action.
• has a slow-start because of the congestion window (cwnd) size and cannot use the full bandwidth available on the network. cwnd prevents the client and server from saturating the network.

There are other important aspects of TCP as well which you can read about here but the above two are relevant in understanding how the “Connection: keep-alive” header impacts the application performance.

Keep-alive connections

Keep-alive connections allow the client and server to use the same TCP connection to send and receive multiple HTTP requests and responses. This helps avoid

• 3-way handshake for new connections— a full roundtrip of latency
• slow-start

Keep-alive connections are enabled by default in HTTP/1.1 while not in HTTP/1.0. HTTP/1.0 was designed to close the connection after every request between client and server. We can actually check this difference using telnet.

Showing Connection header keep-alive and closed for HTTP/1.1 and HTTP/1.0 respectively

The good thing is that most modern browsers will use persistent HTTP connections as long as servers comply. This means if you are building a web application, enabling persistent/keep-alive connections will help improve the performance. HTTP/1.1 also allows to set a timeout for keep-alive connections (how long to wait before resetting the connection after idleness) and the number of requests to be allowed from the client before resetting the connection.

Building microservices? Try using keep-alive connections

In the world of microservices where services interact with each other over an API, I wanted to see how keep-alive connections would impact the performance while interacting with an API. So, I wrote two scripts — one uses the same connection for 50 consecutive requests and one initiates a new connection for every request — to collect 50 public transactions on Venmo using its API.

Using persistent connection for all HTTP requests

The requests.Session()object in python requests library allows to use persistent connection.

Using new TCP connection for each HTTP request

I ran both scripts five times and the result was very interesting. (On a side note, Venmo transaction messages are hilarious. I highly recommend checking them out by running one of these scripts.)

Average time with keep-alive/persistent connections: 7.00 seconds

Average time with new connections: 22.38 seconds

It is a difference of almost 3 orders which makes sense as we know with keep-alive/persistent connections, the three way handshake (a full roundtrip of latency) is avoided. The slow-start wouldn’t have much impact here because the request and response are quite small so the amount of bandwidth required is pretty low.

If you try to run these scripts yourself, the logs will display when new HTTPS connections are being made.

Logs for some HTTP requests showing when new connections are made

This small experiment got me really excited about tuning my applications and improving performance by understanding more about the underlying network protocols.

Interested in transitioning to a career in data engineering?
Find out more about the Insight Data Engineering Fellows Program in New York and Silicon Valley, apply today, or sign up for program updates