Di situs pelanggan, tim jaringan menambahkan firewall antara klien dan server. Ini menyebabkan koneksi idle terputus setelah sekitar 40 menit waktu idle. Orang-orang jaringan mengatakan bahwa firewall tidak memiliki batas waktu koneksi idle, tetapi kenyataannya adalah koneksi idle rusak.
Untuk menyiasatinya, pertama-tama kita mengkonfigurasi server (mesin Linux) dengan TCP keepalives dinyalakan dengan tcp_keepalive_time = 300, tcp_keepalive_intvl = 300, dan tcp_keepalive_probes = 30000. Ini berfungsi, dan koneksi tetap bertahan selama berhari-hari atau lebih. Namun, kami juga ingin server mendeteksi klien yang mati dan mematikan koneksi, jadi kami mengubah pengaturan ke waktu = 300, intvl = 180, probe = 10, berpikir bahwa jika klien benar-benar hidup, server akan menyelidiki setiap 300-an (5 menit) dan klien akan merespons dengan ACK dan itu akan menjaga firewall dari melihat ini sebagai koneksi siaga dan membunuhnya. Jika klien sudah mati, setelah 10 probe, server akan membatalkan koneksi. Yang mengejutkan kami, koneksi idle tapi hidup terbunuh setelah sekitar 40 menit seperti sebelumnya.
Wireshark yang berjalan di sisi klien sama sekali tidak menunjukkan keepalives antara server dan klien, bahkan ketika keepalives diaktifkan di server.
Apa yang mungkin terjadi di sini?
Jika pengaturan keepalive di server adalah waktu = 300, intvl = 180, probe = 10, saya akan berharap bahwa jika klien masih hidup tetapi menganggur, server akan mengirim probe keepalive setiap 300 detik dan meninggalkan koneksi sendirian, dan jika klien sudah mati, itu akan mengirim satu setelah 300 detik, kemudian 9 probe lagi setiap 180 detik sebelum mematikan koneksi. Apakah saya benar?
Salah satu kemungkinan adalah bahwa firewall entah bagaimana mencegat probe keepalive dari server dan gagal untuk meneruskannya ke klien, dan fakta bahwa itu mendapat probe membuatnya berpikir bahwa koneksi aktif. Apakah ini perilaku umum untuk firewall? Kami tidak tahu jenis firewall apa yang terlibat.
Server adalah simpul Teradata dan koneksi dari utilitas klien Teradata ke server database, port 1025 di sisi server, tetapi kami telah melihat masalah yang sama dengan koneksi SSH jadi kami pikir itu mempengaruhi semua koneksi TCP.