65536 +1 Koneksi pada suatu sistem


35

Ada 65536 port untuk setiap sistem dalam jaringan, dan setiap koneksi atau Kirim / Terima akan menggunakan salah satunya.

Pertanyaan saya adalah: apa yang terjadi jika kita memiliki 65536 + 1 koneksi ?!

Saya tahu itu tidak terjadi dengan cara biasa, tetapi saya ingin tahu bagaimana Sistem Operasi menanganinya.


12
Koneksi akan ditolak. Tapi secara realistis Anda akan mengalami masalah lama, jauh sebelum 65.535 koneksi terbuka.
ChrisInEdmonton

1
@ChrisInEdmonton No. Jika ini adalah koneksi keluar, ia akan mendapatkan kesalahan mengikat karena tidak dapat mengalokasikan port lokal. Jika ini koneksi inbound, batas port tidak berlaku.
user207421

jika koneksi sedang inbout, Anda akan menerima koneksi yang ditolak, jika keluar, panggilan socket Anda akan error. Saya tidak akan menempatkan ini sebagai jawaban karena saya tidak yakin.
Jorge Aldo

Jawaban:


61

Perlu diketahui bahwa suatu sistem dapat menangani lebih dari 65536 koneksi bersamaan, karena masing-masing tidak harus menggunakan port terpisah.

Koneksi TCP atau aliran UDP ditentukan oleh 4-tuple:

(source IP address, source port, destination IP address, destination port)

Jadi, bahkan jika Anda memiliki mesin server web dengan hanya satu alamat IP, dan satu paket perangkat lunak server HTTP yang hanya mendengarkan pada port 80, secara teoritis ia dapat menangani 65536 koneksi per alamat IP klien yang terhubung . Jadi koneksi 64Ki dari alamat IP klien 1, ditambah koneksi 64Ki dari alamat IP klien 2, dll.

Jadi protokol mendukung, untuk perkiraan pertama, 2 48 koneksi / mengalir ke port TCP atau UDP tunggal pada alamat IPv4 tunggal. Pertimbangkan TCP dan UDP secara bersamaan, dan kedua ruang alamat IPv4 dan ruang alamat IPv6 yang besar secara kosmis / komikal, dan Anda dapat melihat bahwa protokol itu sendiri tidak akan pernah menjadi sumber batas jumlah koneksi bersamaan yang dimiliki oleh suatu host dapat menangani.

Demikian pula, tidak ada dalam protokol TCP atau UDP yang menjaga mesin klien dari menggunakan port sumber tunggal pada alamat IP tunggal untuk membuat beberapa koneksi keluar ke berbagai alamat server dan port. Terkadang API jaringan OS tertentu mungkin tidak membuat ini mudah, tetapi penting untuk diingat bahwa, katakanlah, API "[BSD] Sockets" lama yang terhormat hanyalah satu API untuk TCP dan UDP. TCP dan UDP mungkin memiliki kemampuan yang tidak diekspos oleh API Soket tradisional.

Jadi jumlah koneksi TCP bersamaan atau aliran UDP yang dapat ditangani oleh host tertentu tidak dibatasi oleh jumlah port, tetapi oleh sumber daya sistem seperti ruang RAM dan waktu CPU yang diperlukan untuk melacak semua koneksi tersebut dan melayani semuanya. Juga detail khusus implementasi OS dapat memaksakan batas buatan. Misalnya, dalam filosofi Unix "everything is a file", mungkin ada deskriptor file untuk setiap koneksi TCP atau aliran UDP. Jika kernel Unix Anda memiliki batasan jumlah deskriptor file yang dapat dilacak, batas deskriptor file adalah batas buatan pada jumlah koneksi TCP bersamaan atau aliran UDP yang dapat ditangani oleh kernel Anda.


2
Mungkin layak untuk ditautkan ke en.wikipedia.org/wiki/C10k_problem dalam jawaban yang sangat bagus ini.
ChrisInEdmonton

1
Saya menerapkan server TCP yang dapat menampung 65.534 koneksi dari setiap alamat IP yang mungkin secara bersamaan. Itu tidak melakukan banyak hal - itu hanya gema teks yang masuk dengan beberapa penggantian karakter - tetapi berjalan pada platform perangkat keras yang sangat kecil. Saya tidak berpikir itu cukup RFC-compliant, tetapi tampaknya berfungsi cukup baik, meskipun tidak mengetahui atau tidak peduli berapa banyak koneksi TCP yang terbuka di sebagian besar port-nya.
supercat

2
Jika Anda benar - benar perlu menghubungkan lebih dari 65536 koneksi antara dua mesin, maka Anda dapat mengatur mesin untuk menggunakan beberapa alamat IP. Setiap alamat IP yang Anda tambahkan ke dua mesin meningkatkan jumlah koneksi maksimum secara kuadratik (setidaknya secara teori, Anda akan lebih cenderung memenuhi masalah lain terlebih dahulu).
Lie Ryan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.