Berapa banyak koneksi soket yang dapat ditangani server web?


114

Katakanlah jika saya harus berbagi, virtual atau hosting khusus, saya membaca di suatu tempat server / mesin hanya dapat menangani 64.000 koneksi TCP pada satu waktu, apakah ini benar? Berapa banyak jenis hosting yang dapat menangani berapa pun bandwidth-nya? Saya berasumsi HTTP bekerja melalui TCP.

Apakah ini berarti hanya 64.000 pengguna yang dapat terhubung ke situs web, dan jika saya ingin melayani lebih banyak, saya harus pindah ke web farm?


2
Permintaan maaf kepada responden, saya telah merobek utas ini seperti tornado. Ada terlalu banyak jawaban yang salah untuk saya sukai, dan masih belum ada jawaban langsung. Saya sering menggunakan stackoverflow dan menemukan banyak jawaban berkualitas tinggi. Saya berharap orang lain dapat menemukan utas ini dan menemukan jawaban informasi yang bermanfaat.
Todd

Hai David, apakah Anda menemukan jawaban yang benar untuk pertanyaan ini?
Hidangan

64000 koneksi TCP melalui satu IP server. Anda dapat meningkatkan jaringan server Anda ke skala dan mendukung lebih dari 64000.
Airy

Jawaban:


109

Singkatnya: Anda harus dapat mencapai dalam urutan jutaan koneksi TCP aktif simultan dan dengan ekstensi permintaan HTTP. Ini memberi tahu Anda kinerja maksimum yang dapat Anda harapkan dengan platform yang tepat dengan konfigurasi yang tepat.

Hari ini, saya khawatir apakah IIS dengan ASP.NET akan mendukung dalam urutan 100 koneksi bersamaan (lihat pembaruan saya, harapkan ~ 10k tanggapan per detik pada versi ASP.Net Mono yang lebih lama). Ketika saya melihat pertanyaan / jawaban ini, saya tidak bisa menahan diri untuk menjawab sendiri, banyak jawaban atas pertanyaan di sini yang sepenuhnya salah.

Kasus terbaik

Jawaban atas pertanyaan ini harus hanya memusatkan perhatian pada konfigurasi server paling sederhana untuk memisahkan dari variabel yang tak terhitung jumlahnya dan kemungkinan konfigurasi di hilir.

Jadi pertimbangkan skenario berikut untuk jawaban saya:

  1. Tidak ada lalu lintas pada sesi TCP, kecuali untuk paket yang tetap hidup (jika tidak, Anda jelas membutuhkan jumlah yang sesuai dari bandwidth jaringan dan sumber daya komputer lainnya)
  2. Perangkat lunak yang dirancang untuk menggunakan soket dan pemrograman asinkron, bukan utas perangkat keras per permintaan dari kumpulan. (mis. IIS, Node.js, Nginx ... webserver [tetapi bukan Apache] dengan perangkat lunak aplikasi yang dirancang asinkron)
  3. Performa bagus / CPU dolar / Ram. Hari ini, sewenang-wenang, katakanlah i7 (4 core) dengan 8GB RAM.
  4. Firewall / router yang bagus untuk dicocokkan.
  5. Tidak ada batas virtual / gubernur - mis. Linux somaxconn, IIS web.config ...
  6. Tidak ada ketergantungan pada perangkat keras lain yang lebih lambat - tidak ada pembacaan dari harddisk, karena ini akan menjadi penyebut dan penghambat umum terendah, bukan IO jaringan.

Jawaban Terperinci

Desain thread-terikat sinkron cenderung memiliki performa paling buruk dibandingkan dengan implementasi IO Asinkron.

WhatsApp mendapatkan satu juta DENGAN lalu lintas pada satu mesin OS rasa Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

Dan terakhir, yang ini, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , membahas banyak detail , mengeksplorasi bagaimana bahkan 10 juta dapat dicapai. Server sering kali memiliki mesin pembongkar TCP perangkat keras, ASIC dirancang untuk peran khusus ini secara lebih efisien daripada CPU tujuan umum.

Pilihan desain perangkat lunak yang bagus

Desain Asynchronous IO akan berbeda di seluruh Sistem Operasi dan platform Pemrograman. Node.js dirancang dengan asynchronous dalam pikiran. Anda harus menggunakan Promises setidaknya, dan ketika ECMAScript 7 hadir, async/await . C # /. Net sudah memiliki dukungan asinkron penuh seperti node.js. Apapun OS dan platformnya, asynchronous diharapkan dapat bekerja dengan sangat baik. Dan bahasa apa pun yang Anda pilih, cari kata kunci "asynchronous", sebagian besar bahasa modern akan memiliki beberapa dukungan, meskipun itu semacam add-on.

Ke WebFarm?

Apa pun batasannya untuk situasi khusus Anda, ya, web-farm adalah salah satu solusi yang baik untuk penskalaan. Ada banyak arsitektur untuk mencapai ini. Salah satunya adalah menggunakan penyeimbang beban (penyedia hosting dapat menawarkan ini, tetapi bahkan ini memiliki batas, bersama dengan plafon bandwidth), tetapi saya tidak menyukai opsi ini. Untuk Aplikasi Halaman Tunggal dengan koneksi yang berjalan lama, saya lebih memilih untuk memiliki daftar server terbuka yang akan dipilih aplikasi klien secara acak saat startup dan digunakan kembali selama masa pakai aplikasi. Ini menghilangkan satu titik kegagalan (load balancer) dan memungkinkan penskalaan melalui beberapa pusat data dan oleh karena itu lebih banyak bandwidth.

Menghancurkan mitos - 64K port

Untuk menjawab komponen pertanyaan tentang "64.000", ini adalah kesalahpahaman. Sebuah server dapat terhubung ke lebih dari 65535 klien. Lihat /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

Omong-omong, Http.sys di Windows mengizinkan beberapa aplikasi untuk berbagi port server yang sama di bawah skema HTTP URL. Mereka masing-masing mendaftarkan pengikatan domain terpisah, tetapi pada akhirnya ada satu aplikasi server yang mem-proxy permintaan ke aplikasi yang benar.

Perbarui 2019-05-30

Berikut adalah perbandingan terkini dari perpustakaan HTTP tercepat - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

  • Tanggal tes: 2018-06-06
  • Perangkat keras yang digunakan: Dell R440 Xeon Gold + 10 GbE
  • Pemimpin memiliki ~ 7 juta tanggapan teks biasa per detik (tanggapan bukan koneksi)
  • Fasthttp kedua untuk golang mengiklankan koneksi bersamaan 1,5 juta - lihat https://github.com/valyala/fasthttp
  • Bahasa terkemuka adalah Rust, Go, C ++, Java, C, dan bahkan C # berada di peringkat 11 (6,9 juta per detik). Scala dan Clojure berada di bawah. Python menempati urutan ke-29 dengan 2,7 juta per detik.
  • Di bagian bawah daftar, saya perhatikan laravel dan cakephp, rails, aspnet-mono-ngx, symfony, zend. Semua di bawah 10k per detik. Perhatikan, sebagian besar kerangka kerja ini dibuat untuk halaman dinamis dan cukup lama, mungkin ada varian lebih baru yang menampilkan lebih tinggi dalam daftar.
  • Ingat ini adalah teks biasa HTTP, bukan untuk spesialisasi Websocket: banyak orang yang datang ke sini kemungkinan akan tertarik dengan koneksi serentak untuk websocket.

2
Terima kasih telah menyertakan tautan ke orang-orang yang membicarakan tentang cara mereka melakukannya.
Rick Smith

Bagaimana jika satu server yang terhubung dengan klien turun? Dan bagaimana jika semua SPA Anda terhubung secara acak ke satu server dan kelebihan beban? Ide untuk menggunakan penyeimbang beban tidak hanya menggunakan 1 Anda dapat menggunakan sebanyak yang Anda suka
pyros2097

3
Klien akan memilih server secara acak. Kemungkinan semua terhubung secara acak ke salah satu secara praktis tidak mungkin. Meskipun seseorang dapat menindaklanjuti dengan jumlah klien dan server dapat meminta klien untuk pindah ke server lain jika terlalu penuh.
Todd

1
Re: batasan 64K - apa yang Anda katakan itu benar, tetapi cukup umum bagi aplikasi server untuk meminta proxy melalui beberapa layanan backend, dalam hal ini "server" sekarang menjadi "klien" dan mungkin memiliki khawatir tentang kehabisan port sementara (misalnya: nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus ). Saya yakin Anda tahu itu, tetapi menyebutkannya untuk orang lain (:
jwd

@jwd poin yang bagus, kontekstual untuk nginx di aplikasi web, tetapi untuk situs web dasar, proxy seperti itu tidak perlu terjadi. Hal yang sama juga dapat dikatakan tentang menghubungkan ke database melalui TCP dengan aplikasi web. Secara teori, ini diselesaikan dengan menggunakan semua alamat dalam rentang 127. *. *. *, Tetapi dalam praktiknya saya tidak tahu apakah ini adalah opsi yang tersedia.
Todd

54

Pertanyaan ini cukup sulit. Tidak ada batasan perangkat lunak nyata pada jumlah koneksi aktif yang dapat dimiliki mesin, meskipun beberapa OS lebih terbatas daripada yang lain. Masalah menjadi salah satu sumber daya. Misalnya, satu mesin ingin mendukung 64.000 koneksi simultan. Jika server menggunakan 1MB RAM per koneksi, itu akan membutuhkan 64GB RAM. Jika setiap klien perlu membaca file, beban akses disk atau larik penyimpanan menjadi jauh lebih besar daripada yang dapat ditangani perangkat tersebut. Jika server perlu membagi satu proses per koneksi maka OS akan menghabiskan sebagian besar waktunya untuk beralih konteks atau proses kelaparan untuk waktu CPU.

The masalah C10K halaman memiliki diskusi yang sangat baik dari masalah ini.


3
Sedikit jawaban yang beragam. OP tampaknya mengacu pada skenario kasus terbaik, dan termasuk bagaimana akan bermanfaat, daripada menemukan kasus terburuk dan kemudian merujuk ke artikel yang mungkin memiliki solusi. Mencatat kemacetan disk berguna. Menggunakan Asynchronous IO, jumlah klien bersamaan yang sangat tinggi dapat dicapai.
Todd

Bagaimana Anda bisa mengatakan bahwa tidak ada batasan perangkat lunak nyata karena ukuran port itu sendiri 16 bit yang membuat maks tidak ada port yang tersedia setiap saat pada maks 65.5K. Saya yakin jawaban Anda salah.
आनंद

Mesin Anda dapat memiliki lebih dari 1 IP sehingga lebih dari 2 ^ 16 port tersedia.
Arman Ordookhani

8

Untuk menambahkan dua sen saya ke percakapan, sebuah proses dapat secara bersamaan membuka sejumlah soket yang terhubung sama dengan nomor ini (dalam sistem tipe Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Nomor ini dapat dimodifikasi dengan cepat (tentu saja hanya oleh pengguna root)

echo 1024> / proc / sys / net / core / somaxconn

Tetapi sepenuhnya tergantung pada proses server, perangkat keras mesin dan jaringan, jumlah sebenarnya dari soket yang dapat dihubungkan sebelum sistem crash


1
Meskipun mungkin benar untuk Linux, ini mengacu pada batas virtual, bukan tolok ukur kemungkinan. Jawaban ini agak spesifik sesuai dengan keinginan saya, dan tidak memberikan angka atau indikasi jumlah koneksi bersamaan. Terlepas dari upaya Anda, itu tidak terlalu berguna. Mungkin Anda dapat menjawab sendiri pertanyaan: "Mengapa saya tidak dapat server lebih dari X koneksi TCP bersamaan di Linux"
Todd

2
Sejauh yang saya tahu ini salah . somaxconn adalah jumlah maksimum koneksi antri pada soket terbuka (yaitu nilai maksimum parameter backlog listen(int socket, int backlog). Ini tidak terkait dengan jumlah soket yang dapat dibuka oleh suatu proses.
Timmmm

8

Sepertinya jawabannya adalah setidaknya 12 juta jika Anda memiliki server yang besar, perangkat lunak server Anda dioptimalkan untuk itu, Anda memiliki cukup klien. Jika Anda menguji dari satu klien ke satu server, jumlah nomor port pada klien akan menjadi salah satu batas sumber daya yang jelas (Setiap sambungan TCP ditentukan oleh kombinasi unik dari IP dan nomor port di sumber dan tujuan).

(Anda perlu menjalankan banyak klien karena jika tidak, Anda mencapai batas 64K pada nomor port terlebih dahulu)

Ketika sampai pada itu, ini adalah contoh klasik dari kecerdasan bahwa "perbedaan antara teori dan praktek jauh lebih besar dalam praktek daripada dalam teori" - dalam prakteknya mencapai angka yang lebih tinggi tampaknya merupakan siklus a. mengusulkan konfigurasi / arsitektur / perubahan kode tertentu, b. mengujinya sampai Anda mencapai batas, c. Apakah saya sudah selesai? Jika tidak maka d. mencari tahu apa faktor pembatasnya, e. kembali ke langkah a (bilas dan ulangi).

Berikut adalah contoh dengan 2 juta koneksi TCP ke kotak besar (128GB RAM dan 40 core) menjalankan Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - mereka berakhir up membutuhkan 50 atau lebih server yang cukup signifikan hanya untuk menyediakan beban klien (klien awal mereka yang lebih kecil dimaksimalkan hingga awal, misalnya "memaksimalkan kotak 4core / 15gb kami @ 450k klien").

Berikut adalah referensi lain untuk pergi kali ini di 10 juta: http://goroutines.com/10m .

Tampaknya ini berbasis java dan 12 juta koneksi: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/


Tautan baru yang bagus, dengan pemahaman yang benar tentang pertanyaan. Saya suka saran umum untuk hit-barrier -> perbaiki penghalang. Setiap orang memiliki situasi spesifik yang berbeda, tetapi setidaknya mereka memiliki indikasi di sini tentang apa yang dapat dicapai secara ekonomi / praktis. Seseorang seharusnya tidak menjanjikan 100 juta pelanggan per server dalam waktu dekat.
Todd

5

Perhatikan bahwa HTTP biasanya tidak membuat koneksi TCP terbuka lebih lama dari yang dibutuhkan untuk mengirimkan halaman ke klien; dan biasanya membutuhkan lebih banyak waktu bagi pengguna untuk membaca halaman web daripada yang diperlukan untuk mengunduh halaman ... saat pengguna melihat halaman, dia tidak menambahkan beban ke server sama sekali.

Jadi jumlah orang yang dapat melihat situs web Anda secara bersamaan jauh lebih besar daripada jumlah koneksi TCP yang dapat dilayani secara bersamaan.


12
Ini sama sekali tidak menjawab pertanyaan itu. Terlepas dari keakuratan apa yang Anda katakan, masih akan ada sejumlah koneksi TCP bersamaan pada waktu tertentu, berapa maksimumnya? Inilah inti dari pertanyaannya.
Todd

3
Jika Anda memiliki sesuatu yang berharga untuk dikontribusikan, Todd, silakan lakukan.
Jeremy Friesner

8
Saya sudah mendapat Jawaban pada tanggal 28 Maret, Anda pasti melewatkannya. Di dunia modern Aplikasi Halaman Tunggal dengan polling panjang dan koneksi soket web, HTTP tidak selalu berumur pendek. Tetapi bahkan jika itu berumur pendek masih ada jumlah maksimum koneksi bersamaan. Mencoba menjelaskan pertanyaan bukanlah jawaban IMO. Jawaban ini akan lebih baik ditempatkan sebagai komentar pada pertanyaan, ini pasti berguna, tetapi pertanyaannya berkaitan dengan "koneksi soket", bukan "orang". Pertanyaan tentang rasio (pengguna: koneksi aktif) harus menjadi pertanyaan terpisah jika diinginkan.
Todd

1
Keep Alive on HTTP Koneksi TCP telah ada dan diminta oleh browser sejak milenium terakhir - terserah server jika memungkinkan koneksi untuk tetap hidup dan berapa periode waktu tunggu yang menganggur. Mengizinkan Keep Alive mengurangi latensi sekelompok permintaan (mis. Halaman html dan aset terkait), tetapi meningkatkan penggunaan sumber daya di server.
iheggie

1

dalam kasus protokol IPv4, server dengan satu alamat IP yang mendengarkan pada satu port hanya dapat menangani 2 ^ 32 alamat IP x 2 ^ 16 port sehingga 2 ^ 48 soket unik. Jika Anda berbicara tentang server sebagai mesin fisik, dan Anda dapat menggunakan semua 2 ^ 16 port, maka maksimum 2 ^ 48 x 2 ^ 16 = 2 ^ 64 soket TCP / IP unik untuk satu alamat IP. Harap dicatat bahwa beberapa port dicadangkan untuk OS, jadi angka ini akan lebih rendah. Untuk menyimpulkan:

1 IP dan 1 port -> 2 ^ 48 soket

1 IP dan semua port -> 2 ^ 64 soket

semua soket IPv4 unik di alam semesta -> 2 ^ 96 soket


0

Ada dua diskusi berbeda di sini: Pertama adalah berapa banyak orang yang dapat terhubung ke server Anda. Yang ini telah dijawab dengan memadai oleh orang lain, jadi saya tidak akan membahasnya.

Lainnya adalah berapa banyak port yang dapat didengarkan oleh server Anda? Saya yakin dari sinilah angka 64K itu berasal. Sebenarnya, protokol TCP menggunakan pengenal 16-bit untuk sebuah port, yang diterjemahkan menjadi 65536 (sedikit lebih dari 64K). Ini berarti bahwa Anda dapat memiliki banyak "pendengar" yang berbeda di server per Alamat IP.


demi keuntungan Anda, saya telah menambahkan bagian tambahan pada jawaban saya yang membahas kesalahpahaman Anda. Juga pertanyaan ini berkaitan dengan "koneksi soket" bukan "orang", yang merupakan perbedaan penting dalam konteks pertanyaan ini.
Todd

Jika kita berbicara tentang satu mesin server tunggal dan satu router tunggal, saya pikir jawaban ini benar. Tapi @Todd membahas sekumpulan mesin server, yang dapat disambungkan oleh pengguna ke salah satu dari mereka secara acak melalui penyeimbang beban.
Amr

@amr itu salah. Jawaban saya adalah tentang satu mesin. The "Webfarm?" Ada bagian untuk kontras dan saran untuk melangkah lebih jauh dan menyimpulkan bahwa penyeimbang beban tidak diperlukan dengan arsitektur yang baik. Anda belum membaca jawaban saya secara menyeluruh.
Todd

0

Saya pikir jumlah koneksi soket bersamaan yang dapat ditangani satu server web sangat bergantung pada jumlah sumber daya yang dikonsumsi setiap koneksi dan jumlah total sumber daya yang tersedia di server, kecuali konfigurasi pembatas sumber daya server web lainnya.

Sebagai ilustrasi, jika setiap koneksi soket menggunakan 1MB sumber daya server dan server memiliki 16GB RAM yang tersedia (secara teoritis), ini berarti itu hanya dapat menangani koneksi bersamaan (16GB / 1MB). Saya pikir sesederhana itu ... SANGAT!

Jadi, terlepas dari bagaimana server web menangani koneksi, setiap koneksi pada akhirnya akan menghabiskan beberapa sumber daya.

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.