Koneksi TCP yang sudah terbentuk dapat tetap senyap dalam waktu lama. Kondisi ini tidak langsung berarti salah satu endpoint gagal: aplikasi mungkin memang sedang tidak memiliki data untuk dipertukarkan. Sifat tersebut berguna untuk sesi berumur panjang, tetapi juga menimbulkan masalah operasional ketika peer menghilang tanpa mengirim FIN atau RST.
Mesin dapat kehilangan daya, jalur jaringan dapat terputus, atau state pada perangkat perantara dapat hilang. Endpoint yang masih aktif bisa mempertahankan socket yang tetap terlihat established karena tidak ada paket yang datang untuk membuktikan kondisi sebaliknya. TCP keepalive menyediakan mekanisme opsional untuk menguji koneksi idle seperti ini.
Koneksi idle tidak wajib menghasilkan traffic
TCP melacak sequence number, acknowledgment, retransmission, dan state koneksi ketika data bergerak. Saat aplikasi mengirim byte dan acknowledgment berhenti datang, mekanisme retransmission memiliki indikasi bahwa pengiriman sedang gagal.
Koneksi yang benar-benar idle berbeda. Tidak ada data aplikasi yang sedang menunggu retransmission. Tanpa traffic, stack lokal mungkin tidak memperoleh sinyal langsung bahwa host remote atau jalur menuju host tersebut telah hilang.
Keepalive menambahkan traffic khusus untuk kondisi ini. Setelah interval idle yang dikonfigurasi tercapai, stack mengirim probe yang dirancang untuk memicu respons dari peer yang masih dapat dijangkau. Respons yang berhasil mempertahankan koneksi. Kegagalan berulang pada akhirnya dapat membuat stack lokal menyatakan koneksi mati.
Keepalive merupakan kebijakan socket opsional
Keepalive tidak otomatis aktif pada setiap socket TCP. Aplikasi biasanya mengaktifkannya melalui opsi socket SO_KEEPALIVE. Sistem operasi kemudian menerapkan kebijakan waktu keepalive, yang pada beberapa sistem juga dapat diatur untuk setiap socket.
Pada Linux, kontrol yang umum terkait mekanisme ini adalah tcp_keepalive_time, tcp_keepalive_intvl, dan tcp_keepalive_probes. Ketiganya mengatur durasi idle sebelum probe dimulai, interval antarprobe yang gagal, serta jumlah probe sebelum kegagalan dinyatakan.
Pengaturan tersebut menjadikan keepalive sebagai kebijakan deteksi kegagalan, bukan sifat TCP dengan waktu yang selalu sama. Host dengan interval panjang dapat mempertahankan sesi senyap dengan sedikit traffic latar belakang, tetapi membutuhkan waktu lebih lama untuk mengenali peer yang tidak dapat dijangkau. Interval lebih pendek mempercepat deteksi dengan konsekuensi traffic probe lebih banyak dan toleransi lebih rendah terhadap gangguan konektivitas berkepanjangan.
Probe keepalive tidak membuktikan progres aplikasi
Probe digunakan untuk menguji reachability dan state TCP. Mekanisme ini bukan pengganti pesan aplikasi, deadline request, acknowledgment transaksi, atau pemeriksaan kesehatan pada level protokol aplikasi.
Peer dapat memiliki stack TCP yang berfungsi sementara aplikasi di atasnya macet. Dalam kondisi tersebut, traffic keepalive masih dapat memperoleh respons TCP yang valid meskipun service tidak lagi membuat progres yang berguna. Transport dapat memastikan endpoint koneksi masih dapat dijangkau tanpa membuktikan bahwa query database, handler RPC, atau worker bekerja dengan baik.
Aplikasi yang membutuhkan batas waktu respons tetap memerlukan deadline sendiri. Keepalive dan timeout aplikasi menangani jenis kegagalan yang berbeda dan sering kali digunakan bersama.
Deteksi kegagalan memang membutuhkan waktu
Mengaktifkan keepalive tidak membuat kegagalan senyap langsung terlihat. Deteksi baru dimulai setelah koneksi berada dalam kondisi idle selama periode yang ditentukan. Stack kemudian memerlukan sejumlah probe yang tidak berhasil sebelum menyimpulkan bahwa peer tidak dapat dijangkau.
Penundaan ini disengaja. Satu paket yang hilang bukan bukti kuat bahwa koneksi telah mati. Jaringan dapat menjatuhkan paket untuk sementara, route dapat mengalami konvergensi ulang, dan link nirkabel dapat terhenti sesaat. Beberapa probe yang gagal mengurangi kemungkinan gangguan singkat menghancurkan sesi berumur panjang yang sebenarnya masih valid.
Waktu deteksi praktis bergantung pada ambang idle, jarak waktu antarprobe, jumlah probe, dan detail implementasi sistem operasi. Nilai tersebut sebaiknya diperlakukan sebagai bagian dari anggaran kegagalan service, bukan menganggap aktivasi SO_KEEPALIVE otomatis menghasilkan deadline tertentu.
Middlebox memiliki timer lain
Firewall, perangkat NAT, dan load balancer sering menyimpan state koneksi sendiri. Sebagian menghapus flow idle setelah timeout tertentu. Koneksi TCP masih dapat ada pada kedua endpoint ketika perangkat perantara sudah membuang mapping yang dibutuhkan paket berikutnya.
Traffic keepalive berkala dapat menyegarkan state pada sebagian perangkat jaringan karena flow tidak lagi sepenuhnya idle. Efek ini berguna, tetapi perilakunya tidak seragam pada semua perangkat. Kebijakan middlebox berbeda-beda dan operator mungkin tidak mengendalikan seluruh perangkat pada jalur jaringan.
Interval keepalive juga perlu sesuai dengan lingkungan. Probe yang baru dikirim setelah timeout idle perangkat perantara terlewati tidak dapat mempertahankan state yang sudah hilang. Sebaliknya, probe yang terlalu agresif pada populasi koneksi sangat besar menghasilkan pekerjaan jaringan dan CPU secara berulang.
Keepalive melengkapi aturan lifecycle koneksi
Service berumur panjang biasanya memerlukan beberapa kontrol yang terpisah. Deadline aplikasi membatasi waktu untuk pekerjaan yang harus menghasilkan progres. Kebijakan sesi idle menentukan kapan koneksi yang tidak digunakan perlu ditutup secara sengaja. Retransmission TCP menangani kehilangan ketika masih ada byte yang menunggu acknowledgment. Keepalive menangani kasus yang lebih sempit: koneksi sedang senyap dan peer menghilang tanpa penutupan normal.
Pemisahan tersebut membuat penanganan kegagalan lebih presisi. Service tidak perlu membebankan semua tanggung jawab pada satu timer. Sistem dapat mempertahankan sesi idle yang memang masih diperlukan, mendeteksi kegagalan transport senyap dalam periode yang dapat diterima, dan tetap menerapkan deadline lebih ketat pada operasi yang seharusnya menghasilkan progres.
TCP keepalive paling efektif ketika timernya dipilih berdasarkan kebutuhan operasional tersebut. Mekanisme ini mengubah keheningan tanpa batas menjadi pengujian reachability berkala, sementara kesehatan aplikasi dan waktu transaksi tetap ditangani oleh layer yang memiliki konteks untuk menilainya.