1. Pertanyaan dan Konteks
Sebuah klien berumur panjang terhubung melalui NAT, load balancer, dan server. Setelah terjadi gangguan jaringan, sistem operasi masih melaporkan soket sebagai established. Tim memperdebatkan apakah TCP Keepalive saja sudah cukup atau protokol harus menambahkan pesan ping/pong. Bandingkan kedua mekanisme tersebut dan usulkan perilaku deteksi, batas waktu (timeout), proxy, dan rekoneksi. Asumsikan bisnis perlu mengetahui apakah sesi masih dapat memproses permintaan, bukan sekadar apakah antarmuka jaringan dapat dijangkau.
2. Apa yang Diuji oleh Pewawancara
- Apakah Anda membedakan pemeriksaan (probing) transport dari pemeriksaan ketersediaan aplikasi.
- Apakah Anda mengetahui bahwa TCP Keepalive menggunakan timer kernel, sehingga nilai default dan perilaku middlebox bukanlah SLA bisnis.
- Apakah Anda dapat merancang state machine yang terikat untuk heartbeat, timeout, penutupan, dan rekoneksi tanpa false positive atau badai rekoneksi.
- Apakah Anda memperhitungkan NAT, idle timeout pada proxy, jaringan seluler, dan beban server dalam desain menyeluruh (end-to-end).
3. Pertanyaan Klarifikasi yang Perlu Diajukan Terlebih Dahulu
- Apakah kita perlu mendeteksi jalur jaringan, proses peer TCP, atau ketersediaan sesi aplikasi?
- Idle timeout apa yang berlaku pada NAT, gateway, dan load balancer?
- Apakah koneksi membawa operasi baca yang dapat diulang (replayable reads), atau perintah dan transaksi yang memerlukan konfirmasi?
- Berapa banyak klien yang ada, berapa banyak bandwidth tambahan yang dapat diterima, dan berapa banyak rekoneksi yang boleh berjalan secara bersamaan?
4. Kerangka Jawaban 30 Detik
TCP Keepalive dikirim oleh kernel dan terutama mendeteksi peer TCP half-open yang idle atau jalur yang terputus. Heartbeat aplikasi ditentukan oleh protokol dan dapat memverifikasi bahwa aplikasi peer masih membaca, menulis, dan mengembalikan pengakuan (acknowledgement) bisnis. Saya akan menentukan status healthy, suspect, closed, dan backoff, lalu menyetel interval heartbeat berdasarkan idle timeout middlebox terpendek. Keepalive adalah fallback transport; heartbeat aplikasi memegang SLA bisnis. Saat batas waktu habis, tutup soket lama, sambungkan kembali dengan exponential backoff ber-jitter, dan batasi konkurensi.
5. Jawaban Mendalam Langkah demi Langkah
Langkah 1: Tentukan Apa yang Diamati Setiap Mekanisme
TCP Keepalive bekerja pada lapisan soket. Linux tcp(7) mengekspos periode idle, interval probe, dan jumlah probe; ACK hanya membuktikan bahwa stack TCP dapat menjawab. Ini tidak membuktikan bahwa aplikasi terautentikasi, sewa (lease)-nya valid, atau dapat memproses permintaan. Keepalive berguna untuk mendeteksi koneksi half-open yang hening dan melepaskan sumber daya kernel.
Heartbeat aplikasi adalah pesan protokol, seperti ping yang membawa data sesi atau kapabilitas, yang dijawab oleh pong atau respons stateful. Ini dapat mendeteksi event loop yang terblokir, lease yang kedaluwarsa, autentikasi yang tidak valid, atau layanan yang kelebihan beban yang tidak dapat dilihat oleh TCP. Biayanya berupa CPU aplikasi, bandwidth, dan kapasitas koneksi.
Langkah 2: Tetapkan Parameter dari Anggaran Waktu End-to-End
Temukan idle timeout middlebox terpendek T_idle, lalu pilih interval heartbeat di bawahnya dengan margin jitter, misalnya T_hb <= T_idle / 2. Pertahankan batas waktu respons aplikasi di bawah waktu terputus yang diizinkan bisnis; wajibkan N kegagalan berturut-turut sebelum menyatakannya mati agar satu paket yang hilang tidak mematikan sesi yang sehat. TCP Keepalive dapat menggunakan periode idle yang lebih lama sebagai fallback transport selama aplikasi hening; ini tidak dapat menggantikan SLA aplikasi.
Langkah 3: Rancang Status dan Tindakan
Setelah terhubung, masuk ke healthy. Mengirim heartbeat akan berpindah ke suspect; respons aplikasi sebelum batas waktu mengembalikannya ke healthy. Kegagalan berturut-turut akan menutup soket dan masuk ke backoff. Gunakan pertumbuhan eksponensial dengan jitter acak dan batas atas (cap); jeda pemanggilan koneksi saat offline atau saat halaman disembunyikan, lalu jalankan pemeriksaan kesehatan sebelum melanjutkan. Tutup soket lama terlebih dahulu agar dua koneksi tidak dapat mengonsumsi satu aliran perintah yang sama.
Langkah 4: Pulihkan Berdasarkan Semantik Pesan
Notifikasi dapat diabaikan dan dilanggan ulang setelah rekoneksi. Perintah tulis tidak boleh bergantung pada konfirmasi heartbeat: lampirkan kunci idempotensi atau nomor urut, terima konfirmasi eksplisit, dan catat titik konfirmasi berurutan terakhir. Setelah rekoneksi, putar ulang dari kursor atau kueri status. Jika eksekusi tidak pasti, baca status server sebelum memutuskan apakah akan mencoba lagi.
Langkah 5: Verifikasi Middlebox dan Sinyal Operasional
Gunakan tangkapan paket (packet capture) atau log koneksi untuk mengonfirmasi bahwa heartbeat melewati NAT, proxy, dan load balancer. Catat RTT heartbeat, tingkat timeout, probe Keepalive yang gagal, usia koneksi, upaya rekoneksi, durasi backoff, dan lonjakan konkurensi. Lakukan pengujian jaringan yang dicabut, reklamasi NAT, event loop server yang terblokir, autentikasi yang kedaluwarsa, dan pemutusan serentak. Status TCP ESTABLISHED saja tidak membuktikan ketersediaan bisnis.
6. Contoh Jawaban Berkualitas Tinggi
Saya memisahkan kedua mekanisme berdasarkan layernya. TCP Keepalive adalah probe kernel yang dapat menemukan koneksi TCP half-open yang hening, tetapi ACK tidak berarti aplikasi dapat memproses permintaan. Heartbeat aplikasi dapat memverifikasi kesehatan protokol, autentikasi, dan lease, sehingga ia memegang keputusan bisnis. Saya mengukur idle timeout NAT atau load balancer terpendek, mengatur heartbeat sekitar setengahnya, dan menambahkan batas waktu respons serta ambang kegagalan berturut-turut. State machine koneksi bergerak antara healthy, suspect, closed, dan backoff dengan jitter; batas waktu yang habis akan menutup soket lama sebelum menyambung kembali. Notifikasi berlangganan ulang setelah pemulihan, sementara perintah menggunakan kunci idempotensi dan kursor konfirmasi. Keepalive adalah fallback selama aplikasi hening, bukan pengganti heartbeat atau loop percobaan ulang tanpa batas.
7. Kesalahan Umum
- Menganggap ACK TCP sebagai bukti kesehatan bisnis → kernel dapat menjawab saat thread aplikasi macet → gunakan heartbeat request-response aplikasi.
- Mengadopsi default Keepalive sistem tanpa perubahan → periode idle mungkin melebihi timeout proxy → konfigurasikan dari anggaran waktu end-to-end.
- Menyambung kembali setelah satu heartbeat terlewat → kehilangan paket singkat menciptakan badai → gunakan batas waktu, ambang kegagalan berturut-turut, dan backoff ber-jitter.
- Hanya menyetel heartbeat klien → NAT atau load balancer mungkin masih mereklamasi lebih awal → periksa setiap middlebox.
- Mengulang kembali perintah tulis secara membabi buta setelah rekoneksi → menagih atau membuat sumber daya dua kali → gunakan kunci idempotensi, titik konfirmasi, dan pembacaan status.
8. Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Jika heartbeat aplikasi lebih kuat, mengapa tetap mempertahankan TCP Keepalive?
Aplikasi mungkin hening untuk waktu yang lama atau kode protokolnya mungkin mengalami masalah. Keepalive dapat menemukan transport yang mati selama masa hening tersebut dan melepaskan soket. Ini adalah fallback lapisan bawah, bukan pengakuan bisnis.
Pertanyaan Lanjutan 2: Haruskah interval heartbeat dibuat sesingkat mungkin?
Tidak. Interval yang lebih pendek mendeteksi kegagalan lebih cepat tetapi menghabiskan lebih banyak CPU, bandwidth, baterai ponsel, dan konkurensi server. Pertama, penuhi anggaran idle middlebox, lalu gunakan latihan simulasi kegagalan untuk mengukur false positive dan keterlambatan deteksi, dengan tingkatan untuk berbagai jenis koneksi.
Pertanyaan Lanjutan 3: Bagaimana Anda menghindari badai rekoneksi setelah restart seluruh armada (fleet-wide restart)?
Klien menggunakan exponential backoff dengan jitter acak. Server membatasi laju (rate limit) berdasarkan tenant atau jenis koneksi dan dapat memberikan waktu coba lagi. Klien yang offline berhenti memanggil; ketika konektivitas kembali, mereka terhubung kembali secara bertahap dalam batch dan mengekspos lonjakan tersebut untuk pemantauan.