Kitaran Hayat Sambungan TCP: Jabat Tangan, Penamatan, dan TIME_WAIT

Soalan dan Skop

Satu klien API Linux tidak menggunakan semula sambungan dan membuka 5,000 sambungan TCP pendek sesaat ke satu huluan. Ia kemudian melaporkan tamat masa sambungan dan populasi TIME_WAIT yang besar. Terangkan bagaimana TCP dibuka dan ditutup, titik akhir manakah yang memasuki TIME_WAIT, mengapa keadaan itu wujud, dan bagaimana anda akan mendiagnosis serta membetulkan insiden tersebut.

Gunakan andaian garis dasar yang jelas. Klien mempunyai satu IP sumber, dan IP serta port huluan adalah tetap. Julat port efemeral adalah lalai yang didokumenkan Linux bagi 32768–60999, tanpa port terpelihara. Tangkapan paket menunjukkan bahawa klien menghantar FIN pertama, dan entri TIME_WAIT yang diperhatikan bertahan kira-kira 60 saat. Dua fakta terakhir ini adalah bukti yang dibekalkan oleh senario, bukan pemalar sistem pengendalian sejagat.

Soalan ini sesuai untuk temu duga kejuruteraan perisian bahagian belakang, infrastruktur, SRE, klien, dan am. Tugas sebenar bukanlah untuk membaca “jabat tangan tiga hala dan penamatan empat hala.” Ia adalah untuk menggunakan keadaan TCP, kapasiti empat-tupel, dan bukti paket bagi memisahkan pembersihan normal daripada kehabisan port efemeral, kehilangan paket, dan beban lampau huluan.

Perkara yang Diuji oleh Penemu Duga

Pertama, bolehkah calon menerangkan bahawa jabat tangan menyegerakkan kedua-dua nombor jujukan awal? Satu SYN menggunakan satu nombor jujukan, dan perakuan mengenal pasti nombor jujukan seterusnya yang dijangkakan. Mesej ketiga mengesahkan bahawa pemula telah menerima nombor jujukan awal rakan setara. Menyenaraikan SYN, SYN+ACK, dan ACK tanpa tujuan ini adalah tidak lengkap.

Kedua, bolehkah calon memetakan semantik tutup dupleks penuh kepada keadaan? Kedua-dua arah boleh berhenti menghantar secara bebas, jadi penutupan normal biasanya ditunjukkan sebagai FIN → ACK → FIN → ACK. Satu ACK boleh digabungkan dengan FIN, jadi tangkapan tidak selalu mengandungi empat paket berasingan. Jawapan yang kukuh menerangkan apa yang ditunggu oleh FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK, dan TIME-WAIT.

Ketiga, bolehkah calon mengenal pasti pemilik TIME_WAIT? Ia biasanya titik akhir yang menutup secara aktif dan menghantar ACK terakhir. Titik akhir tersebut boleh menjadi klien atau pelayan. Jika kedua-dua titik akhir menutup secara aktif pada masa yang sama, kedua-duanya boleh memasuki TIME_WAIT. Label klien dan pelayan sahaja tidak menentukan keadaan tersebut.

Keempat, bolehkah calon mengelak daripada mendiagnosis setiap kiraan TIME_WAIT yang besar sebagai kegagalan? Banyak sambungan pendek secara semula jadi menghasilkan banyak entri. Kehabisan port memerlukan hubungan antara bekalan tupel, kadar penciptaan sambungan, tingkah laku ralat, dan bukti paket.

Kelima, bolehkah calon mencadangkan penyelesaian mengikut susunan risiko yang meningkat? Kurangkan penciptaan sambungan dahulu, periksa kapasiti dan laluan rangkaian seterusnya, dan pertimbangkan tetapan kernel akhir sekali. Memendekkan keadaan, menurunkan had baldi, atau menggunakan RST untuk memintas penutupan normal boleh mengubah masalah kapasiti yang jelas menjadi kegagalan ketepatan yang berselang-seli.

Soalan untuk Dijelaskan Terlebih Dahulu

• Titik akhir manakah yang menutup secara aktif? Titik akhir yang menghantar FIN pertama biasanya mengikuti laluan tutup aktif. Jika huluan menutup dahulu, TIME_WAIT bahagian klien memerlukan penjelasan lain.
• Apakah maksud “tamat masa sambungan” dalam data ralat? Peruntukan port tempatan boleh gagal serta-merta dengan ralat seperti EADDRNOTAVAIL. Sambungan yang kekal dalam SYN-SENT dan menghantar semula lebih menjurus ke arah masalah laluan, penapis, tekanan tunggakan dengar (listen backlog), atau huluan yang tidak bertindak balas. Jenis ralat dan tempoh masa mengubah penyiasatan.
• Bolehkah protokol menggunakan semula sambungan? Keep-alive HTTP, kolam sambungan (connection pool), pemultipleksan HTTP/2, atau pengangkutan berterusan lain boleh menghapuskan kebanyakan jabat tangan dan penutupan. Pengembangan kapasiti hanya menjadi relevan apabila tingkah laku satu permintaan setiap sambungan benar-benar diperlukan.
• Di manakah kekangan port berlaku? Hos mempunyai julat port efemeral. NAT, proksi, atau pengimbang beban mempunyai kolam pemetaan alamat awam dan port tersendiri. Port hos yang lapang tidak membuktikan bahawa peranti keluar (egress) mempunyai tupel yang lapang.
• Adakah destinasi itu tetap? Sambungan TCP dikenal pasti oleh alamat sumber, port sumber, alamat destinasi, dan port destinasi. Port tempatan yang sama boleh digunakan untuk destinasi berbeza, jadi penumpuan pada satu huluan lebih penting daripada jumlah sambungan keseluruhan mesin.
• Apakah konfigurasi sistem langsung? Julat port, port terpelihara, cap masa TCP, dasar penggunaan semula, dan versi kernel mempengaruhi kapasiti. Nilai lalai senario menyokong anggaran awal, manakala kesimpulan pengeluaran memerlukan pembacaan nilai sebenar.

Rangka Kerja Jawapan 30 Saat

“Jabat tangan tiga hala bertukar dan mengesahkan kedua-dua nombor jujukan awal. Klien menghantar SYN, SYN+ACK pelayan memperakui nombor klien dan membekalkan nombornya sendiri, dan klien memperakui (ACK) nombor tersebut. Penutupan normal mempunyai dua arah yang bebas, jadi ia biasanya FIN, ACK, FIN, ACK. Penutup aktif yang menghantar ACK terakhir biasanya memasuki TIME_WAIT supaya ia boleh memperakui FIN yang dihantar semula dan menjauhkan pendua tertangguh daripada sambungan lama daripada penggunaan baharu bagi tupel yang sama.

Kiraan TIMEWAIT yang tinggi bukan secara automatik merupakan kebocoran. Saya akan memeriksa jenis ralat, kiraan SYN-SENT, tangkapan paket, dan julat port. Satu IP sumber ke satu huluan mempunyai 28,232 port dalam julat lalai yang dinyatakan. Pada 5,000 sambungan baharu sesaat dengan kira-kira 60 saat diperhatikan dalam TIMEWAIT, permintaan adalah sekitar 300,000 tupel terkini, jauh melebihi bekalan. Mula-mula saya akan menambah penyatuan kolam (pooling) atau pemultipleksan, kemudian memeriksa kapasiti NAT dan tupel, dan hanya selepas itu mempertimbangkan julat yang lebih luas atau lebih banyak alamat sumber. Saya tidak akan bermula dengan memadam TIMEWAIT atau menukar tcptw_reuse secara membabi buta.”

Analisis Mendalam Langkah demi Langkah

Langkah 1: Terangkan jabat tangan dengan nombor jujukan

Biarkan nombor jujukan awal klien menjadi x dan pelayan menjadi y:

Satu SYN menggunakan satu nombor jujukan, itulah sebabnya perakuannya ialah x+1 atau y+1. ACK tulen tidak menggunakan ruang jujukan. Jabat tangan memberikan setiap titik akhir nombor jujukan awal rakan setara dan pengesahan bahawa nombornya sendiri telah diterima. Ia juga mengurangkan kemungkinan bahawa permintaan sambungan pendua yang lama disalah anggap sebagai sambungan baharu.

Selepas hanya dua mesej, pemula telah melihat pengesahan pelayan, tetapi pelayan belum menerima pengesahan bahawa klien menerima nombor jujukan awal pelayan. “Ia memeriksa bahawa rangkaian berfungsi dalam kedua-dua arah” adalah jalan pintas yang tidak tepat. TCP sedang membina ruang jujukan yang diperakui, boleh dihantar semula, dan keadaan sambungan yang dikongsi.

Langkah 2: Terbitkan penamatan daripada dua arah yang bebas

TCP ialah strim bait dupleks penuh. Menutup satu arah penghantaran bermaksud “Saya tiada lagi data untuk dihantar,” manakala titik akhir tersebut boleh terus menerima data yang belum selesai dihantar oleh rakan setara. Oleh itu, penutupan normal menamatkan dua arah:

Populasi CLOSE-WAIT yang berterusan biasanya bermaksud bahawa aplikasi telah diberitahu tentang penutupan rakan setara tetapi tidak menutup soketnya sendiri dengan segera. Itu adalah kegagalan yang berbeza daripada TIME_WAIT. FIN-WAIT-2 yang berterusan bermaksud FIN penutup aktif telah diperakui, tetapi rakan setara belum menghantar FIN miliknya. Menyebut semua ini sebagai “sambungan yang tidak dilepaskan” menghilangkan nilai diagnostik mesin keadaan.

Penerangan empat mesej ialah kes normal yang berguna, bukan kiraan paket yang tetap. Penutup pasif tanpa baki data boleh menggabungkan ACK dan FIN miliknya. Penutupan aktif serentak boleh menggunakan CLOSING dan boleh meninggalkan kedua-dua titik akhir dalam TIME-WAIT.

Langkah 3: Terangkan dua fungsi TIME_WAIT

Titik akhir yang menghantar ACK terakhir tidak boleh melupakan sambungan dengan serta-merta atas dua sebab utama.

Pertama, ACK terakhir boleh hilang. Penutup pasif kekal dalam LAST-ACK dan menghantar semula FIN miliknya. Penutup aktif yang masih mempunyai keadaan TIME_WAIT boleh memperakui FIN itu sekali lagi. Jika keadaan itu hilang serta-merta, FIN yang dihantar semula boleh menerima RST dan penutupan normal akan kehilangan sifat kebolehpercayaannya.

Kedua, segmen yang tertangguh atau bertindih daripada sambungan lama mungkin masih wujud dalam rangkaian. TCP mengenal pasti sambungan melalui empat-tupelnya. Jika tupel yang sama diperuntukkan serta-merta kepada sambungan baharu, segmen lama boleh bertindih dengan ruang jujukan baharu. Piawaian TCP memerlukan sambungan yang ditutup secara aktif untuk kekal selama 2 × MSL, memberikan masa kepada segmen lama untuk luput dan mengekalkan keupayaan untuk memperakui FIN yang dihantar semula. RFC 1337 menerangkan bagaimana menamatkan perlindungan ini lebih awal boleh memperkenalkan semula penerimaan data lama, penyahsegerakan, dan bahaya ACK yang salah.

Oleh itu, TIME_WAIT ialah mekanisme ketepatan, bukan sinonim untuk kebocoran memori. Soalan pertama sepatutnya mengapa aplikasi mencipta begitu banyak sambungan, sama ada bekalan tupel mencukupi, dan titik akhir manakah yang menutup secara aktif—bukan bagaimana untuk menjadikan kiraan itu sifar.

Langkah 4: Anggarkan tekanan port efemeral

Lalai yang didokumenkan Linux bagi ip_local_port_range ialah 32768–60999. Dengan andaian senario bahawa tiada port terpelihara, kolam peruntukan automatik mengandungi:

60999 - 32768 + 1 = 28232

Bagi satu IP sumber, satu IP destinasi, dan satu port destinasi, terdapat kira-kira 28,232 slot port sumber apabila tupel lama belum boleh digunakan semula dengan selamat. Pada 5,000 sambungan baharu sesaat, aplikasi mencipta sebanyak itu tupel dalam masa kira-kira 5.65 saat:

28232 / 5000 ≈ 5.65 seconds

Senario ini juga membekalkan tempoh TIME_WAIT yang diperhatikan selama kira-kira 60 saat. Permintaan penutupan terkini secara kasar ialah:

5000 × 60 = 300000 recent connections

Tiga ratus ribu adalah jauh melebihi 28,232, jadi “satu IP sumber, satu huluan, tiada penggunaan semula sambungan” adalah risiko kapasiti yang jelas. Ini tidak membuktikan bahawa kegagalan berlaku tepat pada 5.65 saat. Penggunaan semula kernel yang selamat, sambungan mapan (established), port terpelihara, tempoh sambungan, dan tingkah laku NAT semuanya mengubah hasil langsung. Anggaran ini membuktikan ketidakpadanan magnitud dan memberitahu penyiasat bukti apa yang perlu dikumpulkan seterusnya.

Port sumber yang sama boleh melayani sambungan ke destinasi berbeza, jadi jumlah sambungan baharu seluruh mesin tidak boleh dibahagikan secara membabi buta dengan kiraan port. Dengan NAT, sumber yang terhad mungkin sebaliknya merupakan tupel pemetaan alamat NAT awam ke arah destinasi.

Langkah 5: Pisahkan punca dengan keadaan, ralat, dan paket

Mulakan dengan bukti yang tidak mengubah tingkah laku 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 pecahkan mengikut bukti:

Tangkapan paket harus menjawab tiga soalan: siapa yang menghantar FIN pertama, sama ada sambungan yang gagal mengeluarkan SYN langsung, dan di mana penghantaran semula berlaku. Jumlah daripada ss tidak boleh membuktikan kehabisan port, dan log aplikasi yang mengandungi perkataan “tamat masa” tidak boleh membuktikan kehilangan paket.

Langkah 6: Betulkan mengikut susunan risiko yang meningkat

Pembetulan pertama adalah untuk mencipta lebih sedikit sambungan. Konfigurasikan kolam sambungan, keep-alive HTTP, pemultipleksan HTTP/2, atau saluran berterusan lain yang sesuai supaya permintaan berkongsi sambungan yang telah dibina. Ini mengurangkan kependaman jabat tangan, CPU, penggunaan port efemeral, dan TIME_WAIT secara bersama, menangani punca dan bukannya gejala.

Seterusnya, betulkan kitaran hayat sambungan. Jangan tutup sambungan yang sihat secara aktif selepas setiap permintaan. Berikan kolam keserentakan yang terikat, tamat masa melahu yang sesuai, jangka hayat maksimum, dan had keserentakan huluan. Jika pelayan menutup secara terlalu agresif, periksa tetapan keep-alive miliknya, tamat masa melahu pengimbang beban, dan tingkah laku penggunaan (deployment). Matlamatnya adalah untuk menghapuskan perubahan sambungan (churn) yang tidak berguna, bukan sekadar memindahkan penutupan aktif ke titik akhir yang satu lagi.

Jika penggunaan semula masih tidak mencukupi, kembangkan bekalan tupel. Selepas memeriksa port terpelihara, nilaikan julat efemeral yang lebih luas. Titik tumpuan destinasi tunggal juga boleh menggunakan lebih banyak IP sumber atau lebih banyak alamat destinasi. Jika NAT wujud, kembangkan atau bahagikan (shard) kolam alamat NAT awam juga; menambah IP sumber di dalam rangkaian aplikasi mungkin tidak mempunyai kesan selepas terjemahan.

Hanya selepas itu nilaikan tetapan penggunaan semula kernel. Linux mendokumenkan tcp_tw_reuse sebagai hanya menggunakan semula soket TIME_WAIT apabila protokol menganggapnya selamat dan memberi amaran agar tidak mengubahnya tanpa nasihat pakar. tcp_max_tw_buckets ialah had pertahanan terhadap keadaan penafian perkhidmatan (DoS) mudah; dokumentasi secara eksplisit menyatakan untuk tidak menurunkannya secara buatan. Melebihi had ini akan memusnahkan soket time-wait serta-merta dan merekodkan amaran. Sebarang perubahan memerlukan bukti versi kernel, cap masa, tingkah laku rakan setara, ujian beban, dan pelan pengunduran (rollback).

Jangan gunakan RST sebagai pengoptimuman umum. RST menggugurkan sambungan dan membuang keadaan serta-merta; data yang belum diambil kira dengan selamat oleh aplikasi boleh hilang. “Membuat pelayan menutup dahulu” juga bukan pembetulan sejagat. Ia memindahkan tekanan TIME_WAIT dan mungkin mencipta tekanan port, memori, atau keadaan sambungan di bahagian pelayan.

Langkah 7: Sahkan pembetulan

Pengesahan mesti merangkumi kapasiti, ketepatan, dan bukti rangkaian:

1. Main semula trafik yang sama dan bandingkan sambungan TCP baharu sesaat, nisbah penggunaan semula, dan daya pemprosesan permintaan.
2. Jejak SYN-SENT, TIME_WAIT, CLOSE-WAIT, deskriptor fail, dan penggunaan port tempatan dari semasa ke semasa dan bukan pada satu ketika sahaja.
3. Tangkap sampel yang gagal untuk mengesahkan sama ada SYN keluar, sama ada SYN+ACK kembali, dan titik akhir manakah yang menutup secara aktif.
4. Periksa metrik pengangkutan klien, NAT, pengimbang beban, dan huluan supaya kesesakan keluar tidak terlepas pandang.
5. Jalankan ujian berterusan dan periksa data yang terpotong, kiraan RST yang lebih tinggi, kependaman ekor (tail latency) yang lebih teruk, atau sambungan kolam yang lapuk.

Kejayaan bermakna daya pemprosesan perniagaan yang sama mencipta sambungan baharu yang jauh lebih sedikit, ralat hilang, ruang port kekal stabil, dan ketepatan permintaan tidak merosot. Kiraan TIME_WAIT yang lebih rendah adalah akibat daripada penambahbaikan tersebut, bukan satu-satunya objektif.

Contoh Jawapan yang Mantap

“Mula-mula saya akan menentukan dua fakta daripada insiden tersebut: titik akhir manakah yang menghantar FIN pertama, dan sama ada ‘tamat masa’ bermaksud ralat tempatan serta-merta atau SYN yang tidak menerima respons. TIME_WAIT biasanya milik penutup aktif yang menghantar ACK terakhir, manakala beberapa kegagalan yang tidak berkaitan boleh kelihatan seperti tamat masa sambungan.

Semasa pembentukan, klien menghantar SYN dengan nombor jujukan awal x. SYN+ACK pelayan memperakui x+1 dan membekalkan nombornya sendiri y. Klien kemudian memperakui y+1. Kedua-dua titik akhir kini telah bertukar dan mengesahkan ruang jujukan, dan proses ini boleh menolak percubaan sambungan pendua yang lama. Penamatan menutup kedua-dua arah penghantaran secara bebas, jadi jujukan biasa ialah FIN, ACK, FIN, ACK. Penutup aktif bergerak melalui FIN-WAIT-1 dan FIN-WAIT-2, memperakui FIN rakan setara, dan memasuki TIME_WAIT. Keadaan itu membolehkannya memperakui semula FIN yang dihantar semula jika ACK terakhir hilang dan menghalang pendua tertangguh daripada sambungan lama daripada mencemari penggunaan semula serta-merta bagi empat-tupel yang sama.

Kapasiti senario ini mencurigakan. Port 32768 hingga 60999 memberikan 28,232 port efemeral lalai. Satu IP sumber mencipta 5,000 sambungan sesaat ke destinasi yang sama, dan tempoh TIME_WAIT yang diperhatikan adalah kira-kira 60 saat, membayangkan sekitar 300,000 penutupan terkini—jauh lebih banyak daripada slot port. Saya tidak akan berhenti pada anggaran tersebut. Jika sambungan gagal serta-merta dengan ralat alamat tempatan dan tiada SYN, saya akan menyiasat bekalan tupel hos dan NAT. Jika banyak soket kekal dalam SYN-SENT dan menghantar semula, saya akan menyiasat laluan, ACL, tunggakan dengar, dan huluan.

Mula-mula saya akan menambah penyatuan kolam, keep-alive, atau pemultipleksan HTTP/2 untuk mengurangkan sambungan baharu. Kemudian saya akan memeriksa tamat masa melahu kolam, tingkah laku penutupan huluan, dan kapasiti NAT. Jika beban kerja masih memerlukan kadar pembentukan yang tinggi, saya akan mempertimbangkan julat efemeral yang lebih luas, lebih banyak alamat sumber, atau pengedaran destinasi. tcptwreuse hanya selamat di bawah syarat protokol dan Linux memberi amaran terhadap perubahan sembarangan. Saya tidak akan bermula dengan memendekkan TIME_WAIT, menurunkan had baldi, atau memaksa penutupan RST. Akhir sekali, saya akan mengesahkan kadar sambungan baharu, ralat, setiap keadaan TCP yang berkaitan, tangkapan paket, dan metrik NAT di bawah beban yang sama.”

Kesilapan Lazim

• Menerangkan jabat tangan sebagai “mengucapkan salam” → Ia mengabaikan semantik jujukan dan perakuan serta tidak dapat menerangkan mengapa dua mesej tidak mencukupi → terbitkannya daripada kedua-dua nombor jujukan awal dan pengesahan ketiga.
• Menganggap klien sentiasa memiliki TIME_WAIT → Peranan tutup aktif menentukan keadaan, bukan label klien → kenal pasti FIN pertama dan ACK terakhir.
• Menganggap penamatan sebagai tepat empat paket → ACK dan FIN boleh bergabung, dan penutupan serentak wujud → terangkan dua arah bebas dan peralihan keadaannya.
• Memanggil setiap kiraan TIME_WAIT yang besar sebagai kebocoran → Sambungan pendek secara semula jadi mencipta keadaan tersebut → gabungkan kadar penciptaan, julat, jenis ralat, dan bukti paket.
• Menyalahkan kehabisan port untuk setiap tamat masa sambungan → Kehilangan SYN, ACL, beban lampau huluan, dan tekanan tunggakan dengar juga boleh menyebabkan tamat masa → asingkan kegagalan tempatan serta-merta daripada penghantaran semula SYN.
• Menurunkan tcpmaxtw_buckets terlebih dahulu → Melebihi had memusnahkan keadaan lebih awal, dan Linux secara jelas memberi amaran terhadap menurunkannya secara buatan → kurangkan churn sebelum mengembangkan kapasiti.
• Menggunakan RST dan bukannya penutupan normal → Pemadaman keadaan serta-merta boleh membuang data yang tidak dihantar dengan selamat → kekalkan penutupan berasaskan FIN untuk penyelesaian normal dan simpan RST untuk pembatalan sebenar.
• Hanya meluaskan julat port aplikasi → Had sebenar mungkin merupakan kolam pemetaan awam NAT → periksa kapasiti tupel pada hos sumber, peranti keluar, dan huluan.

Soalan Susulan

Susulan 1: Bagaimanakah TIME_WAIT pulih apabila ACK terakhir hilang?

Penutup pasif kekal dalam LAST-ACK menunggu perakuan bagi FIN miliknya. Jika ACK terakhir hilang, ia menghantar semula FIN. Penutup aktif masih mempunyai keadaan TIME_WAIT, mengecam FIN yang dihantar semula, menghantar ACK sekali lagi, dan memulakan semula pemasa menunggu. Jika titik akhir aktif telah melupakan sambungan, FIN tersebut boleh mencetuskan RST dan penutupan normal yang boleh dipercayai tidak lagi dipelihara.

Susulan 2: Bagaimanakah populasi CLOSE_WAIT yang besar berbeza?

CLOSE-WAIT bermaksud rakan setara telah menghantar FIN dan tindanan TCP tempatan telah memberitahu aplikasi, tetapi aplikasi belum menutup arah penghantarannya sendiri; aplikasi tempatan masih boleh menghantar baki data. Ia biasanya menunjukkan isu kitaran hayat aplikasi, pengendalian pengecualian, atau pengurusan deskriptor fail. TIME_WAIT bermaksud penutup aktif telah menyelesaikan pertukaran dan sedang melindungi pemulihan ACK terakhir serta pengasingan segmen lama. Kedua-duanya muncul semasa penutupan, tetapi puncanya, keupayaan membawa baki data, dan pembetulannya adalah berbeza.

Susulan 3: Bagaimanakah satu port sumber boleh dimiliki oleh pelbagai sambungan?

Empat-tupel yang lengkap mengenal pasti sambungan. Jika alamat destinasi atau port destinasi berbeza, port tempatan yang sama boleh mengenal pasti sambungan lain. Oleh itu, tekanan port efemeral mesti dianalisis mengikut IP sumber dan titik tumpuan destinasi. Trafik yang tersebar merentasi banyak destinasi boleh menyokong lebih banyak jumlah sambungan daripada yang dicadangkan oleh satu julat port, manakala penumpuan pada satu huluan menghabiskan tupel yang boleh digunakan dengan lebih cepat.

Susulan 4: Adakah menskalakan klien kepada sepuluh tika akan menyelesaikan kehabisan port?

Tidak semestinya. IP sumber yang bebas meningkatkan bekalan tupel di bahagian hos, tetapi jika semua tika berkongsi NAT dengan hanya beberapa IP awam, sambungan akan bertumpu ke dalam kolam pemetaan NAT. Huluan juga mungkin mengehadkan kadar mengikut IP sumber, dan sambungan serentak tambahan mungkin melebihi tunggakan dengar, deskriptor fail, atau kapasiti pengimbang beban miliknya.

Susulan 5: Bilakah tcptwreuse wajar dipertimbangkan?

Mula-mula buktikan bahawa penggunaan semula sambungan, tetapan kolam, julat port, dan kapasiti NAT masih tidak mencukupi. Kemudian periksa versi kernel yang tepat, tingkah laku cap masa TCP, dan ciri-ciri rakan setara. Linux membenarkan penggunaan semula hanya apabila ia selamat dari perspektif protokol dan secara jelas memberi amaran terhadap penukaran tetapan secara sembarangan. Uji penyambungan semula dan ketepatan data di bawah beban, pantau RST, kegagalan, dan kependaman, serta sediakan pelan pengunduran. Ia bukan pengganti bagi penggunaan semula sambungan di peringkat aplikasi.