Anatomi Thundering Herd di Edge Ingress M-Banking: Dari SYN Flood Palsu hingga TCP Socket Depletion

Pukul 12.05 WIB di tanggal 25 setiap bulannya adalah jam keramat bagi tim site reliability engineering dan infrastruktur perbankan di Indonesia. Notifikasi alert PagerDuty mulai meraung, dashboard APM memerah, dan media massa seperti Infobanknews biasanya langsung menerbitkan artikel kilat mengenai keluhan nasabah yang gagal membuka aplikasi m-banking mereka. Pernyataan publik yang sering muncul hampir seragam: 'kapasitas server tidak mampu menampung lonjakan jutaan pengguna sekaligus'. Namun ketika Anda membuka console war room, ada anomali teknis yang janggal. Utilisasi CPU pada pod Kubernetes aplikasi Core Banking dan Payment Gateway sering kali masih santai di angka 15% hingga 25%. Database connection pool tidak mengalami starvation, dan memori JVM masih jauh dari batas OOMKilled. Masalah sebenarnya bukan karena business logic Java atau Go Anda lambat mengeksekusi query saldo. Request HTTP nasabah bahkan tidak pernah menyentuh application layer. Masalahnya terkunci jauh di bawah: di lapisan Linux kernel network stack pada edge reverse proxy, di mana jutaan paket TCP SYN terlempar ke jurang oblivion sebelum koneksi sempat terjalin.

Ilusi SYN Flood di Balik Payday Rush

Ketika 2 juta pengguna membuka aplikasi mobile banking secara simultan dalam jendela waktu 3 menit, ingress balancer menerima ledakan request connection establishment yang brutal. Secara mekanisme layer 4, setiap koneksi baru membutuhkan TCP three-way handshake (SYN > SYN-ACK > ACK). Kernel Linux mengelola fase ini menggunakan dua antrean terpisah: SYN queue (antrean half-open connection) dan Accept queue (antrean koneksi yang sudah selesai handshake namun belum di-accept() oleh aplikasi). Secara default pada sebagian besar distribusi Linux enterprise, nilai net.ipv4.tcp_max_syn_backlog dan net.core.somaxconn disetel sangat konservatif (sering kali hanya berkisar 128 hingga 4096). Ketika gelombang SYN datang laksana tsunami, SYN queue langsung terisi penuh dalam hitungan milidetik. Begitu queue ini penuh, kernel berasumsi bahwa sistem sedang berada di bawah serangan SYN Flood berbahaya. Jika net.ipv4.tcp_syncookies aktif, kernel beralih ke mode cryptographic hashing untuk memverifikasi handshake tanpa mengalokasikan entri tabel koneksi. Masalahnya, begitu SYN cookies diaktifkan di bawah beban tinggi, fitur TCP lanjutan seperti Window Scaling dan SACK (Selective Acknowledgment) sering kali dinegosiasikan ulang secara cacat tergantung konfigurasi timestamp kernel. Jika SYN cookies tidak mampu mengejar laju kedatangan paket, kernel langsung mengeksekusi tcp_drop. Bagi smartphone pengguna di jaringan seluler 4G/5G yang tidak stabil, drop paket SYN awal ini diterjemahkan sebagai connection timeout. Sialnya, SDK mobile banking modern yang dipasang di jutaan gawai nasabah dikonfigurasi dengan aggressive auto-retry tanpa exponential backoff ataupun jitter. Hasilnya adalah amplifikasi beban: 2 juta request awal bertransformasi menjadi 10 juta paket SYN yang menghantam firewall dalam rentang detik berikutnya.

BASH

# Mengecek apakah kernel Anda sedang mendrop paket pada SYN queue dan listen queue
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPReqQFullDrop

# Memeriksa kapasitas backlog soket aktif pada ingress proxy
ss -lnt '( sport = :443 )'

Jika metrik TcpExtListenOverflows terus merangkak naik, sistem Anda sedang mencekik dirinya sendiri di pintu gerbang kernel, membuang koneksi valid bahkan sebelum proxy layer 7 (seperti Envoy atau NGINX) menyadari ada nasabah yang mengetuk pintu.

Saturasi Epoll dan Thundering Herd di Worker Process

Setelah paket SYN berhasil melewati SYN queue dan menyelesaikan three-way handshake, soket tersebut dipindahkan ke Accept queue milik proses reverse proxy. Di sinilah problem klasik thundering herd modern terjadi pada level user space. Sebelum adanya patch kernel modern, ketika soket listening menerima koneksi baru, kernel akan membangunkan (wake up) seluruh worker process yang sedang tertidur di syscall epoll_wait(). Seluruh worker terbangun, berebut memanggil accept(), namun hanya satu worker yang menang mendapatkan file descriptor soket tersebut. Sisanya kembali tidur dengan membawa penalti context switching yang mahal. Kendati flag EPOLLEXCLUSIVE sudah memitigasi sebagian besar thundering herd pada level thread individual, bottleneck baru muncul ketika accept queue (somaxconn) penuh karena worker thread proxy sibuk melakukan TLS handshake kriptografis. Ketika accept queue mencapai batas limitnya, kernel default Linux akan mendrop paket ACK final dari klien atau mengabaikannya. Klien mengira koneksi sudah ESTABLISHED, namun proxy di edge menganggap koneksi tersebut belum ada.

BASH

# Tuning mendasar sysctl untuk edge gateway m-banking berkapasitas tinggi
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_abort_on_overflow=0
sysctl -w net.ipv4.ip_local_port_range='1024 65535'

Menyetel net.ipv4.tcp_abort_on_overflow=0 memberi instruksi kepada kernel untuk mendiamkan paket ACK klien jika accept queue penuh, memaksa klien melakukan retransmit ACK dengan harapan worker proxy segera menyelesaikan pemrosesan antrean sebelumnya, alih-alih langsung mereset koneksi dengan paket RST yang membuat aplikasi perbankan menampilkan dialog error fatal di layar nasabah.

Kriptografi TLS: Pembunuh Senyap yang Menguras Socket & CPU

Banyak tim infrastruktur mengira bahwa proses pembukaan TCP socket selesai begitu handshake layer 4 tuntas. Pada arsitektur perbankan, kepatuhan keamanan menuntut enkripsi mutlak via TLS 1.2 atau TLS 1.3 dengan cipher suite modern (ECDHE-ECDSA/RSA). Operasi komputasi asimetris untuk menukar kunci Diffie-Hellman pada puluhan ribu koneksi baru per detik menghabiskan siklus CPU core di edge node dengan sangat rakus. Tragedi sesungguhnya terjadi ketika edge tier menggunakan cluster load balancer multi-node tanpa session caching yang terdistribusi. Nasabah yang membuka aplikasi m-banking mengirimkan request awal, melakukan TLS full handshake, lalu koneksinya ditutup oleh gateway karena batas timeout yang terlalu ketat. Ketika nasabah tersebut menyentuh menu 'Cek Saldo' satu detik kemudian, request diarahkan oleh L4 load balancer ke node edge proxy yang berbeda. Karena node baru ini tidak menyimpan TLS session state dari node pertama, klien dipaksa menjalani full TLS handshake ulang dari awal. Tanpa TLS Session Resumption yang solid (baik melalui TLS Session Tickets RFC 5077 dengan key rotation yang disinkronkan antar proxy, atau shared session cache via in-memory store), edge router Anda membuang 80% dayanya hanya untuk menghitung matematika kurva eliptik berulang kali untuk nasabah yang sama.

NGINX

# Snippet optimasi SSL Session Cache pada NGINX Edge
ssl_session_cache shared:SSL:100m;
ssl_session_timeout 1h;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/tls_keys/current.key;

Sinkronisasi key file ssl_session_ticket_key ke seluruh armada edge proxy memastikan bahwa nasabah mana pun yang melompat antar node edge proxy tidak akan memicu re-negosiasi TLS yang menguras komputasi CPU.

Melampaui Default: Socket Sharding dan Arsitektur Klien

Menyelesaikan problem thundering herd di gerbang m-banking membutuhkan intervensi dua arah: dari sisi kernel plumbing dan tata kelola traffic klien. Dari sisi infrastruktur Linux, penerapan opsi soket SO_REUSEPORT adalah keharusan mutlak. Dengan SO_REUSEPORT, kernel Linux mendistribusikan koneksi masuk secara langsung ke beberapa accept queue independen milik masing-masing worker process menggunakan algoritma 4-tuple hashing. Ini menghapus contention lock tunggal pada listen queue dan membagi beban penanganan socket establishment merata ke seluruh core prosesor tanpa worker saling berebut. Namun, perbaikan infrastruktur paling canggih sekalipun akan bertekuk lutut jika tim mobile app banking Anda membiarkan jutaan klien menembak endpoint tanpa kendali. Retensi koneksi HTTP/2 multiplexing dengan keep-alive yang agresif harus dipertahankan selama sesi aplikasi aktif agar nasabah tidak membuka-tutup TCP connection untuk setiap klik menu. Dan yang terpenting: ketika edge server mulai mengirimkan respons kode 429 (Too Many Requests) atau latency handshake mulai merayap naik, SDK mobile wajib mengaktifkan jittered exponential backoff secara lokal. Menghadapi payday rush bukanlah soal membakar anggaran cloud untuk membeli puluhan VM berukuran monster secara serampangan. Ini adalah seni menyelaraskan toleransi kernel Linux, efisiensi epoll, serta disiplin penanganan koneksi di edge layer sebelum satu byte pun data transaksi finansial diproses oleh sistem backend.