Keep Alive Mechanism

This happens between the client and server. Each application protocol can have its own keep-alive. We mostly see HTTP. But SSH, FTP, and DB connections use the same logic.

Application must close idle connections

If the app doesn't close idle connections, the kernel closes them after a timeout. This is usually 2 hours, but the OS can set it.

Until then, the connection stays ESTABLISHED.

Advantages of keep-alive

1. The client and server reuse the connection. No new handshake is needed.
2. Reuses socket buffers.
3. SSL handshake isn't required again.

Handle multiple messages

For the network layer, these are just a stream of IP packets. It doesn't care if they're one message or many from the app.

The app must know when a message starts and ends. For example, in HTTP, the app 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.

The kernel does these checks to see if the connection is still alive. This is off by default. Else the kernel would keep a connection alive even when the app isn't using it.

Kernel keep alive logic

Kernel keep-alive packets don't reach the app level. They just send an empty packet with the sequence number of an already acknowledged one.

The TCP packet processor on the receiver checks it and returns the same ACK. The packet never goes up the network stack.

keep-alive at multiple levels

At the network layer, the kernel sometimes sends keep-alive packets. This checks if the connection is alive.

At the application layer, the app can send keep-alive packets. This keeps the kernel from closing the connection.

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

With a load balancer like NGINX, the TCP connection ends at NGINX. It then starts new connections to the app servers.

Keep-alive happens at two levels. Each level has its own timeout and error handling.