Siklus Hidup Koneksi TCP: Handshake, Teardown, dan TIME_WAIT

Pertanyaan dan Cakupan

Sebuah klien API Linux tidak menggunakan ulang koneksi dan membuka 5.000 koneksi TCP pendek per detik ke satu upstream. Klien tersebut kemudian melaporkan connection timeout dan populasi TIME_WAIT yang besar. Jelaskan bagaimana TCP membuka dan menutup koneksi, endpoint mana yang memasuki TIME_WAIT, mengapa status tersebut ada, serta bagaimana Anda mendiagnosis dan memperbaiki insiden tersebut.

Gunakan asumsi dasar yang eksplisit. Klien memiliki satu IP sumber, serta IP dan port upstream bersifat tetap. Rentang port ephemeral adalah default yang terdokumentasi pada Linux yaitu 32768–60999, tanpa port yang direservasi. Tangkapan paket (packet capture) menunjukkan bahwa klien mengirimkan FIN pertama, dan entri TIME_WAIT yang teramati berlangsung sekitar 60 detik. Dua fakta terakhir adalah bukti yang diberikan oleh skenario, bukan konstanta sistem operasi yang universal.

Pertanyaan ini cocok untuk wawancara backend, infrastruktur, SRE, klien, dan rekayasa perangkat lunak umum. Tugas sebenarnya bukanlah melafalkan "three-way handshake dan four-way teardown." Tugasnya adalah menggunakan status TCP, kapasitas four-tuple, dan bukti paket untuk memisahkan pembersihan normal dari habisnya port ephemeral, kehilangan paket (packet loss), dan kelebihan beban upstream (upstream overload).

Apa yang Diuji oleh Pewawancara

Pertama, dapatkah kandidat menjelaskan bahwa handshake menyinkronkan kedua nomor urut awal (initial sequence number)? Sebuah SYN mengonsumsi satu nomor urut, dan acknowledgment mengidentifikasi nomor urut berikutnya yang diharapkan. Pesan ketiga mengonfirmasi bahwa inisiator telah menerima nomor urut awal milik peer. Mendaftar SYN, SYN+ACK, dan ACK tanpa tujuan ini adalah jawaban yang tidak lengkap.

Kedua, dapatkah kandidat memetakan semantik penutupan full-duplex ke status soket? Kedua arah dapat berhenti mengirim secara independen, sehingga penutupan normal biasanya ditampilkan sebagai FIN → ACK → FIN → ACK. Sebuah ACK dapat digabungkan dengan FIN, sehingga tangkapan paket tidak selalu berisi empat paket terpisah. Jawaban yang kuat menjelaskan apa yang sedang ditunggu oleh FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK, dan TIME-WAIT.

Ketiga, dapatkah kandidat mengidentifikasi pemilik TIME_WAIT? Pemiliknya biasanya adalah endpoint yang melakukan active close dan mengirimkan ACK terakhir. Endpoint tersebut bisa berupa klien atau server. Jika kedua endpoint melakukan active close secara bersamaan, keduanya dapat memasuki TIME_WAIT. Label klien dan server saja tidak menentukan status tersebut.

Keempat, dapatkah kandidat menghindari mendiagnosis setiap jumlah TIME_WAIT yang besar sebagai sebuah kegagalan? Banyak koneksi pendek secara alami menghasilkan banyak entri. Habisnya port (port exhaustion) memerlukan analisis hubungan antara persediaan tuple, laju pembuatan koneksi, perilaku error, dan bukti paket.

Kelima, dapatkah kandidat mengusulkan perbaikan dalam urutan risiko yang meningkat? Kurangi pembuatan koneksi terlebih dahulu, periksa kapasitas dan jalur jaringan berikutnya, dan pertimbangkan pengaturan kernel paling akhir. Memotong status, menurunkan batas bucket, atau menggunakan RST untuk melewati penutupan normal dapat mengubah masalah kapasitas yang jelas menjadi kegagalan kebenaran data yang berselang-seling (intermittent correctness failures).

Pertanyaan untuk Diklarifikasi Terlebih Dahulu

• Endpoint mana yang melakukan active close? Endpoint yang mengirim FIN pertama biasanya mengikuti jalur active-close. Jika upstream menutup terlebih dahulu, TIME_WAIT di sisi klien memerlukan penjelasan lain.
• Apa arti “connection timeout” dalam data error? Alokasi port lokal dapat langsung gagal dengan error seperti EADDRNOTAVAIL. Koneksi yang tetap berada di SYN-SENT dan melakukan retransmisi lebih mengarah pada masalah jalur, filter, tekanan listen backlog, atau upstream yang tidak responsif. Tipe error dan durasi mengubah arah investigasi.
• Bisakah protokol menggunakan ulang koneksi? HTTP keep-alive, connection pool, HTTP/2 multiplexing, atau transport persisten lainnya dapat menghilangkan sebagian besar handshake dan penutupan koneksi. Perluasan kapasitas menjadi relevan hanya ketika perilaku satu-permintaan-per-koneksi benar-benar diperlukan.
• Di mana letak batasan port? Host memiliki rentang port ephemeral. NAT, proxy, atau load balancer memiliki pool pemetaan alamat publik dan port tersendiri. Port host yang tersisa tidak membuktikan bahwa perangkat egress memiliki tuple yang tersisa.
• Apakah tujuannya tetap? Koneksi TCP diidentifikasi oleh alamat sumber, port sumber, alamat tujuan, dan port tujuan. Port lokal yang sama dapat digunakan untuk tujuan yang berbeda, sehingga konsentrasi pada satu upstream lebih penting daripada total koneksi di seluruh mesin.
• Bagaimana konfigurasi sistem yang berjalan (live system)? Rentang port, port yang direservasi, timestamp TCP, kebijakan penggunaan ulang, dan versi kernel memengaruhi kapasitas. Default skenario mendukung perkiraan awal, sementara kesimpulan produksi memerlukan pembacaan nilai sebenarnya.

Kerangka Jawaban 30 Detik

“Three-way handshake mempertukarkan dan mengonfirmasi kedua initial sequence number. Klien mengirim SYN, SYN+ACK server mengakui nomor klien dan memberikan nomornya sendiri, dan klien melakukan ACK terhadap nomor tersebut. Penutupan normal memiliki dua arah independen, sehingga umumnya berupa FIN, ACK, FIN, ACK. Pihak active closer yang mengirimkan ACK terakhir biasanya memasuki TIME_WAIT sehingga dapat mengakui FIN yang ditransmisikan ulang dan mencegah duplikat tertunda dari koneksi lama mengganggu penggunaan baru dari tuple yang sama.

Jumlah TIMEWAIT yang tinggi tidak otomatis berarti kebocoran (leak). Saya akan memeriksa tipe error, jumlah SYN-SENT, tangkapan paket, dan rentang port. Satu IP sumber ke satu upstream memiliki 28.232 port dalam rentang default yang disebutkan. Pada 5.000 koneksi baru per detik dengan sekitar 60 detik teramati di TIMEWAIT, permintaannya sekitar 300.000 tuple baru-baru ini, jauh di atas persediaan. Pertama-tama saya akan menambahkan pooling atau multiplexing, lalu memeriksa kapasitas NAT dan tuple, dan baru kemudian mempertimbangkan rentang yang lebih luas atau lebih banyak alamat sumber. Saya tidak akan memulainya dengan menghapus TIMEWAIT atau mengubah tcptw_reuse secara membabi buta.”

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Jelaskan handshake dengan nomor urut

Misalkan initial sequence number klien adalah x dan milik server adalah y:

Sebuah SYN mengonsumsi satu nomor urut, itulah sebabnya acknowledgment bernilai x+1 atau y+1. ACK murni tidak mengonsumsi ruang urutan. Handshake memberikan initial sequence number milik peer kepada masing-masing endpoint beserta konfirmasi bahwa nomor miliknya telah diterima. Hal ini juga mengurangi kemungkinan permintaan koneksi duplikat lama disalahartikan sebagai koneksi baru.

Setelah hanya dua pesan, inisiator telah melihat konfirmasi server, tetapi server belum menerima konfirmasi bahwa klien menerima initial sequence number server. “Ini memeriksa bahwa jaringan berfungsi di kedua arah” adalah jalan pintas yang tidak presisi. TCP sedang membangun ruang urutan yang diakui dan dapat ditransmisikan ulang serta status koneksi bersama (shared connection state).

Langkah 2: Menurunkan teardown dari dua arah yang independen

TCP adalah byte stream full-duplex. Menutup satu arah pengiriman berarti “Saya tidak memiliki data lagi untuk dikirim,” sementara endpoint tersebut dapat terus menerima data yang belum selesai dikirim oleh peer. Oleh karena itu, penutupan normal menghentikan dua arah:

Populasi CLOSE-WAIT yang persisten biasanya berarti aplikasi telah diberitahu tentang penutupan oleh peer tetapi tidak segera menutup soketnya sendiri. Itu adalah kegagalan yang berbeda dari TIME_WAIT. FIN-WAIT-2 yang persisten berarti FIN dari active closer telah diakui, tetapi peer belum mengirimkan FIN-nya. Menyebut semua ini sebagai “koneksi yang tidak dilepaskan” menghilangkan nilai diagnostik dari state machine.

Deskripsi empat pesan adalah kasus normal yang berguna, bukan jumlah paket yang kaku. Passive closer tanpa sisa data dapat menggabungkan ACK dan FIN-nya. Penutupan aktif simultan (simultaneous active close) dapat menggunakan CLOSING dan dapat meninggalkan kedua endpoint di TIME-WAIT.

Langkah 3: Jelaskan dua fungsi TIME_WAIT

Endpoint yang mengirimkan ACK terakhir tidak dapat langsung melupakan koneksi karena dua alasan utama.

Pertama, ACK terakhir bisa hilang. Passive closer tetap berada di LAST-ACK dan mentransmisikan ulang FIN-nya. Active closer yang masih memiliki status TIME_WAIT dapat mengakui FIN tersebut lagi. Jika status tersebut langsung hilang, FIN yang ditransmisikan ulang dapat menerima RST dan penutupan normal akan kehilangan sifat keandalannya (reliability).

Kedua, segmen yang tertunda atau terduplikasi dari koneksi lama mungkin masih ada di jaringan. TCP mengidentifikasi koneksi berdasarkan four-tuple miliknya. Jika tuple yang sama segera ditetapkan ke koneksi baru, segmen lama dapat tumpang tindih dengan ruang urutan yang baru. Standar TCP mengharuskan koneksi yang ditutup secara aktif untuk bertahan selama 2 × MSL, memberikan waktu bagi segmen lama untuk kedaluwarsa dan mempertahankan kemampuan untuk mengakui FIN yang ditransmisikan ulang. RFC 1337 menjelaskan bagaimana mengakhiri perlindungan ini lebih awal dapat memunculkan kembali bahaya penerimaan data lama, desinkronisasi, dan ACK yang keliru.

Oleh karena itu, TIME_WAIT adalah mekanisme kebenaran (correctness mechanism), bukan sinonim dari memory leak. Pertanyaan pertama haruslah mengapa aplikasi membuat begitu banyak koneksi, apakah persediaan tuple mencukupi, dan endpoint mana yang menutup secara aktif—bukan bagaimana cara membuat jumlahnya menjadi nol.

Langkah 4: Estimasi tekanan port ephemeral

Default ip_local_port_range yang terdokumentasi pada Linux adalah 32768–60999. Dengan asumsi skenario bahwa tidak ada port yang direservasi, pool alokasi otomatis berisi:

60999 - 32768 + 1 = 28232

Untuk satu IP sumber, satu IP tujuan, dan satu port tujuan, terdapat sekitar 28.232 slot port sumber ketika tuple lama belum dapat digunakan kembali dengan aman. Pada 5.000 koneksi baru per detik, aplikasi membuat tuple sebanyak itu dalam waktu sekitar 5,65 detik:

28232 / 5000 ≈ 5.65 seconds

Skenario ini juga memberikan durasi TIME_WAIT yang teramati sekitar 60 detik. Perkiraan permintaan penutupan baru-baru ini adalah:

5000 × 60 = 300000 recent connections

Tiga ratus ribu jauh di atas 28.232, sehingga “satu IP sumber, satu upstream, tanpa penggunaan ulang koneksi” merupakan risiko kapasitas yang jelas. Ini tidak membuktikan bahwa kegagalan terjadi tepat pada 5,65 detik. Penggunaan ulang kernel yang aman, koneksi yang sudah established, port yang direservasi, durasi koneksi, dan perilaku NAT semuanya mengubah hasil aktual di lingkungan live. Estimasi ini membuktikan adanya ketidaksesuaian tingkat magnitudo dan memberi tahu penyelidik bukti apa yang harus dikumpulkan selanjutnya.

Port sumber yang sama dapat melayani koneksi ke tujuan yang berbeda, sehingga total koneksi baru di seluruh mesin tidak dapat dibagi secara membabi buta dengan jumlah port. Dengan NAT, sumber daya yang langka mungkin berupa tuple pemetaan alamat NAT publik ke arah tujuan.

Langkah 5: Pisahkan penyebab dengan status, error, dan paket

Mulailah dengan bukti yang tidak mengubah perilaku sistem:

ss -s
ss -Htan state syn-sent | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state close-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/ipv4/ip_local_reserved_ports
sysctl net.ipv4.tcp_tw_reuse

Kemudian lakukan percabangan berdasarkan bukti:

Tangkapan paket harus menjawab tiga pertanyaan: siapa yang mengirim FIN pertama, apakah koneksi yang gagal memancarkan SYN sama sekali, dan di mana retransmisi terjadi. Total dari ss tidak dapat membuktikan habisnya port, dan log aplikasi yang berisi kata “timeout” tidak dapat membuktikan packet loss.

Langkah 6: Perbaiki dalam urutan risiko yang meningkat

Perbaikan pertama adalah membuat lebih sedikit koneksi. Konfigurasikan connection pool, HTTP keep-alive, HTTP/2 multiplexing, atau saluran persisten lain yang sesuai sehingga permintaan berbagi koneksi yang sudah terbentuk. Ini mengurangi latensi handshake, CPU, penggunaan port ephemeral, dan TIME_WAIT secara bersamaan, mengatasi penyebab alih-alih gejalanya.

Selanjutnya, perbaiki siklus hidup koneksi. Jangan menutup koneksi yang sehat secara aktif setelah setiap permintaan. Berikan pool konkurensi yang dibatasi (bounded concurrency), idle timeout yang sesuai, masa pakai maksimum, dan batas konkurensi upstream. Jika server menutup terlalu agresif, periksa pengaturan keep-alive, idle timeout load balancer, dan perilaku deployment. Tujuannya adalah untuk menghilangkan perputaran koneksi (connection churn) yang sia-sia, bukan hanya memindahkan active close ke endpoint lain.

Jika penggunaan ulang masih belum mencukupi, perluas persediaan tuple. Setelah memeriksa port yang direservasi, evaluasi rentang ephemeral yang lebih luas. Hotspot satu tujuan juga dapat menggunakan lebih banyak IP sumber atau lebih banyak alamat tujuan. Jika NAT digunakan, perluas atau bagi (shard) pool alamat NAT publik juga; menambahkan IP sumber di dalam jaringan aplikasi mungkin tidak berpengaruh setelah proses translasi.

Hanya setelah itu lakukan evaluasi pengaturan reuse pada kernel. Linux mendokumentasikan tcp_tw_reuse sebagai penggunaan ulang soket TIME_WAIT hanya jika protokol menganggapnya aman dan memperingatkan agar tidak mengubahnya tanpa saran ahli. tcp_max_tw_buckets adalah batas defensif terhadap kondisi denial-of-service sederhana; dokumentasi secara eksplisit menyatakan untuk tidak menurunkannya secara artifisial. Melebihinya akan langsung menghancurkan soket time-wait dan mencatat peringatan. Setiap perubahan memerlukan bukti versi kernel, timestamp, perilaku peer, load test, dan rencana rollback.

Jangan gunakan RST sebagai optimasi umum. RST membatalkan koneksi dan langsung membuang status; data yang belum dipertanggungjawabkan secara aman oleh aplikasi dapat hilang. “Membuat server menutup terlebih dahulu” juga bukan perbaikan universal. Ini hanya memindahkan tekanan TIME_WAIT dan dapat menciptakan tekanan port, memori, atau status koneksi di sisi server.

Langkah 7: Verifikasi perbaikan

Verifikasi harus mencakup kapasitas, kebenaran (correctness), dan bukti jaringan:

1. Putar ulang lalu lintas yang sama dan bandingkan koneksi TCP baru per detik, rasio penggunaan ulang, dan throughput permintaan.
2. Lacak SYN-SENT, TIME_WAIT, CLOSE-WAIT, file descriptor, dan penggunaan port lokal dari waktu ke waktu daripada hanya pada satu saat.
3. Tangkap sampel yang gagal untuk memastikan apakah SYN keluar, apakah SYN+ACK kembali, dan endpoint mana yang melakukan active close.
4. Periksa metrik transport klien, NAT, load balancer, dan upstream agar bottleneck pada egress tidak terlewatkan.
5. Jalankan pengujian berkelanjutan dan periksa data yang terpotong, jumlah RST yang lebih tinggi, tail latency yang memburuk, atau koneksi pool yang basi (stale).

Keberhasilan berarti bahwa throughput bisnis yang sama menghasilkan koneksi baru yang jauh lebih sedikit, error menghilang, headroom port tetap stabil, dan kebenaran permintaan tidak mengalami regresi. Jumlah TIME_WAIT yang lebih rendah adalah konsekuensi dari perbaikan tersebut, bukan satu-satunya tujuan.

Contoh Jawaban yang Kuat

“Pertama-tama saya akan menetapkan dua fakta dari insiden tersebut: endpoint mana yang mengirim FIN pertama, dan apakah 'timeout' berarti error lokal langsung atau SYN yang tidak menerima respons. TIME_WAIT biasanya milik active closer yang mengirimkan ACK terakhir, sementara beberapa kegagalan yang tidak terkait dapat terlihat seperti connection timeout.

Selama pembentukan koneksi, klien mengirimkan SYN dengan initial sequence number x. SYN+ACK server mengakui x+1 dan memberikan nomornya sendiri y. Klien kemudian mengakui y+1. Kedua endpoint kini telah bertukar dan mengonfirmasi ruang urutan, dan proses tersebut dapat menolak upaya koneksi duplikat lama. Teardown menutup dua arah pengiriman secara independen, sehingga urutan umumnya adalah FIN, ACK, FIN, ACK. Active closer bergerak melalui FIN-WAIT-1 dan FIN-WAIT-2, melakukan ACK terhadap FIN milik peer, dan memasuki TIME_WAIT. Status tersebut memungkinkannya mengirim ulang ACK untuk FIN yang ditransmisikan ulang jika ACK terakhir hilang, serta mencegah duplikat tertunda dari koneksi lama mencemari penggunaan ulang langsung dari four-tuple yang sama.

Kapasitas skenario ini mencurigakan. Port 32768 hingga 60999 menyediakan 28.232 port ephemeral default. Satu IP sumber membuat 5.000 koneksi per detik ke tujuan yang sama, dan durasi TIME_WAIT yang teramati adalah sekitar 60 detik, yang menyiratkan sekitar 300.000 penutupan baru-baru ini—jauh lebih banyak daripada slot port yang tersedia. Saya tidak akan berhenti pada estimasi tersebut. Jika connect langsung gagal dengan error alamat lokal dan tidak ada SYN, saya akan menyelidiki persediaan tuple host dan NAT. Jika banyak soket tetap berada di SYN-SENT dan melakukan retransmisi, saya akan menyelidiki jalur, ACL, listen backlog, dan upstream.

Pertama-tama saya akan menambahkan pooling, keep-alive, atau HTTP/2 multiplexing untuk mengurangi koneksi baru. Kemudian saya akan memeriksa idle timeout pada pool, perilaku penutupan upstream, dan kapasitas NAT. Jika beban kerja masih membutuhkan tingkat pembentukan koneksi yang tinggi, saya akan mempertimbangkan rentang ephemeral yang lebih luas, lebih banyak alamat sumber, atau distribusi tujuan. tcptwreuse hanya aman di bawah kondisi protokol tertentu dan Linux memperingatkan terhadap perubahan yang sembarangan. Saya tidak akan memulainya dengan memperpendek TIME_WAIT, menurunkan batas bucket, atau memaksakan penutupan dengan RST. Terakhir, saya akan memvalidasi laju koneksi baru, error, setiap status TCP yang relevan, tangkapan paket, dan metrik NAT di bawah beban yang sama.”

Kesalahan Umum

• Menggambarkan handshake sebagai “menyapa” (saying hello) → Ini mengabaikan semantik sequence dan acknowledgment serta tidak dapat menjelaskan mengapa dua pesan tidak cukup → turunkan dari kedua initial sequence number dan konfirmasi ketiga.
• Mengasumsikan klien selalu memiliki TIME_WAIT → Peran active-close yang menentukan status, bukan label klien → identifikasi FIN pertama dan ACK terakhir.
• Menganggap teardown tepat empat paket → ACK dan FIN dapat digabungkan, dan penutupan simultan dapat terjadi → jelaskan dua arah yang independen dan transisi statusnya.
• Menyebut setiap jumlah TIME_WAIT yang besar sebagai kebocoran → Koneksi pendek secara alami menciptakan status tersebut → gabungkan laju pembuatan, rentang, tipe error, dan bukti paket.
• Menyalahkan habisnya port untuk setiap connect timeout → Kehilangan SYN, ACL, overload upstream, dan tekanan listen backlog juga dapat menyebabkan timeout → pisahkan kegagalan lokal langsung dari retransmisi SYN.
• Menurunkan tcpmaxtw_buckets terlebih dahulu → Melebihi batas akan menghancurkan status lebih awal, dan Linux secara eksplisit memperingatkan agar tidak menurunkannya secara artifisial → kurangi churn sebelum memperluas kapasitas.
• Menggunakan RST alih-alih penutupan normal → Penghapusan status seketika dapat membuang data yang belum terkirim dengan aman → pertahankan penutupan berbasis FIN untuk penyelesaian normal dan simpan RST untuk pembatalan yang sebenarnya.
• Hanya memperluas rentang port aplikasi → Batasan sebenarnya mungkin berada pada pool pemetaan publik NAT → periksa kapasitas tuple pada host sumber, perangkat egress, dan upstream.

Pertanyaan Lanjutan

Lanjutan 1: Bagaimana TIME_WAIT memulihkan kondisi saat ACK terakhir hilang?

Passive closer tetap berada di LAST-ACK menunggu acknowledgment untuk FIN-nya. Jika ACK terakhir hilang, ia mentransmisikan ulang FIN tersebut. Active closer masih memiliki status TIME_WAIT, mengenali FIN yang ditransmisikan ulang, mengirimkan ACK lagi, dan memulai ulang timer tunggu. Jika endpoint aktif telah melupakan koneksi tersebut, FIN itu dapat memicu RST dan penutupan normal yang andal tidak lagi terjaga.

Lanjutan 2: Apa perbedaan populasi CLOSE_WAIT yang besar?

CLOSE-WAIT berarti peer mengirim FIN dan TCP stack lokal telah memberitahu aplikasi, tetapi aplikasi belum menutup arah pengirimannya sendiri; aplikasi lokal masih dapat mengirim sisa data. Ini biasanya mengarah pada siklus hidup aplikasi, penanganan exception, atau manajemen file descriptor. TIME_WAIT berarti active closer telah menyelesaikan pertukaran data dan sedang melindungi pemulihan ACK terakhir serta isolasi segmen lama. Keduanya muncul selama penutupan, tetapi penyebabnya, kemampuan untuk membawa sisa data, dan perbaikannya berbeda.

Lanjutan 3: Bagaimana satu port sumber bisa dimiliki oleh beberapa koneksi?

Four-tuple yang lengkap mengidentifikasi sebuah koneksi. Jika alamat tujuan atau port tujuan berbeda, port lokal yang sama dapat mengidentifikasi koneksi lain. Oleh karena itu, tekanan port ephemeral harus dianalisis berdasarkan IP sumber dan hotspot tujuan. Lalu lintas yang tersebar di banyak tujuan dapat mendukung lebih banyak total koneksi daripada yang disarankan oleh satu rentang port, sedangkan konsentrasi pada satu upstream menghabiskan tuple yang dapat digunakan lebih cepat.

Lanjutan 4: Apakah melakukan scaling klien menjadi sepuluh instance akan menyelesaikan masalah kehabisan port?

Belum tentu. IP sumber independen meningkatkan persediaan tuple di sisi host, tetapi jika semua instance berbagi NAT dengan hanya beberapa IP publik, koneksi-koneksi tersebut akan menyatu ke dalam pool pemetaan milik NAT. Upstream juga dapat membatasi laju (rate-limit) berdasarkan IP sumber, dan koneksi konkuren tambahan dapat melebihi listen backlog, file descriptor, atau kapasitas load balancer miliknya.

Lanjutan 5: Kapan tcptwreuse layak dipertimbangkan?

Pertama-tama buktikan bahwa penggunaan ulang koneksi, pengaturan pool, rentang port, dan kapasitas NAT tetap tidak mencukupi. Kemudian periksa versi kernel yang tepat, perilaku timestamp TCP, dan karakteristik peer. Linux mengizinkan penggunaan ulang hanya jika aman dari perspektif protokol dan secara eksplisit memperingatkan agar tidak mengubah pengaturan secara sembarangan. Uji penyambungan ulang dan kebenaran data di bawah beban, pantau RST, kegagalan, dan latensi, serta siapkan rencana rollback. Ini bukan pengganti untuk penggunaan ulang koneksi di tingkat aplikasi.