Connection tracking di security group cloud kedaluwarsa Cloud security group connection tracking timeout
ID penyebab dc-cloud-conntrack · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Firewall yang terpasang di server cloud (security group) juga melacak koneksi, dan entri pelacakan untuk koneksi idle kedaluwarsa setelah waktu tertentu. Server yang tersambung langsung tanpa load balancer pun bisa membuat pemain yang lama diam terputus.
Mengapa Konfigurasi yang membuat security group melacak koneksi game (hanya mengizinkan alamat tertentu, membatasi aturan outbound, lewat NLB, dan sebagainya) → Akibatnya Entri pelacakan untuk koneksi yang idle cukup lama kedaluwarsa, lalu security group membuang diam-diam paket yang datang sesudahnya → Di layar Setelah AFK, pemain bergerak lagi tetapi tidak ada respons, lalu disconnect. Program server baru menyadarinya lama kemudian
Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game
Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (jika TCP 350 detik, maksimal 175 detik; jika UDP stream 180 detik, maksimal 90 detik), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi lewat token sesi.
Tugas Tim Infrastruktur
Periksa waktu connection tracking instance (TcpEstablishedTimeout) dan perpanjang jika perlu (UDP tidak bisa diperpanjang karena maksimal 180 detik), tinjau konfigurasi security group yang tidak memicu pelacakan (izinkan semua alamat untuk port game, izinkan semua trafik outbound; koneksi lewat NLB tetap dilacak), jalankan uji koneksi idle saat pindah ke generasi instance yang baru.
Kisaran angka
Di AWS, tipe instance Nitro v6 menghapus entri pelacakan koneksi TCP idle setelah 350 detik secara default (tipe lain 5 hari). Untuk UDP, defaultnya 180 detik untuk flow yang request dan response-nya bolak-balik beberapa kali (stream), dan 30 detik untuk flow yang hanya satu arah atau hanya satu kali request dan response.
Di grafik
Koneksi putus serentak · Jumlah disconnect, waktu idle sebelum terputus
Yang diperiksa
Periksa konfigurasi waktu connection tracking instance dan aturan security group (apakah konfigurasinya memicu pelacakan), lalu kumpulkan waktu idle koneksi yang terputus. Segera setelah terputus, jalankan ss -tnoi di server dan periksa apakah koneksi itu masih ESTABLISHED dengan timer retransmisi (timer:(on,…)) berjalan dan backoff yang terus membesar
Cocok jika
Waktu idle koneksi yang terputus terkumpul tepat setelah 350 detik untuk TCP, 180 detik untuk UDP stream, dan 30 detik untuk UDP satu arah, dan socket di sisi server tetap ESTABLISHED tanpa mendeteksi putusnya koneksi (jika server punya data untuk dikirim, ia hanya terus mengirim ulang)
Tidak cocok jika
Konfigurasi security group tidak memicu pelacakan (port game diizinkan untuk semua alamat, aturan outbound mengizinkan semua, tidak lewat NLB): bukan penyebab ini. Jika lewat NLB, bandingkan nilainya dengan “Idle timeout load balancer”
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Sumber
Amazon EC2 security group connection trackingAWS Pelacakan TCP idle default 350 detik (Nitro v6; tipe lain 432.000 detik = 5 hari), UDP satu arah 30 detik dan stream 180 detik (maksimal 180); tidak dilacak jika aturannya mengizinkan semua alamat; koneksi lewat NLB selalu dilacak
ss(8) — Linux manual pageiproute2 timer:(on,…) pada -o adalah timer retransmisi, dan backoff pada -i adalah berapa kali waktu tunggu retransmisi digandakan
Lihat juga
Lapisan yang sama: L5 Perangkat jaringan data center