Keep Alive Mechanism

This is something that happens between the client and server. Each application protocol can have its own keep-alive mechanism. We come across HTTP mostly but the same logic is implemented in SSH, FTP, DB connections, etc.

Application must close idle connections

If the application doesn't close idle connections, then the kernel will close them after a timeout. This timeout is usually 2 hours but can be configured in the OS.

until then the connection state remains as ESTABLISHED.

Advantages of keep-alive

1. It let's the client and server to reuse existing connection and no need to perform a new handshake.
2. Reuses socket buffers.
3. SSL handshake isn't required again.

Handle multiple messages

For the network layer, they're just stream of IP packets. It doesn't care if they belong to one single message or multiple messages generated by the application.

It's the application that must understand when the message starts and ends. For example, in case of HTTP, the application knows the start of a new message.

Kernel keep-alive vs Application keep-alive

• Kernel keep-alive is to check if the connection is still alive.
• Application keep-alive is to ensure the connection isn't closed by the kernel due to inactivity.

Kernel level checks are done by the kernel to check if the connection is still alive. This is disabled by default. Otherwise the kernel will enable the a connection even if the application isn't using it.

Kernel keep alive logic

Kernel keep alive packets doesn't reach the application level. It just sends an empty packet with the sequence number of an already acknowledged packet.

So the TCP packet processor on the receiver just checks and returns the same ACK again to the sender. The packet never goes up to the next level in the network stack.

keep-alive at multiple levels

At the network layer, the kernel itself sometimes sends keep-alive packets. This is to check if the connection is still alive.

At the application layer, the application can also send keep-alive packets. This is just done to ensure the connection isn't closed by the kernel.

Keep-alive in HTTP

1. HTTP/1.0 - Connection: keep-alive otherwise connection is closed by default after every request-response.
2. HTTP/1.1 - Keep-alive is enabled by default. Connection: close must be sent to close the connection.
3. HTTP/2 - Keep-alive is implicit here as well.
   But the connection is multiplexed and parallel requests can be sent over the same connection. Systems can differentiate between different requests using stream IDs.
4. HTTP/3 - This again has implicit keep-alive. But this uses UDP as the transport protocol instead of TCP.

no keep-alive messages

HTTP doesn't have any keep-alive messages like TCP keep-alive packets. The application layer itself manages the keep-alive mechanism.

Load balancers

In case of load balancer such as NGINX, the TCP connections terminates at NGINX and it will start new connections to the application servers.

This means, the keep-alive happens at two levels and each level will have it's own timeout and error handling mechanism.