Webサーバーはいくつのソケット接続を処理できますか？
共有、仮想、または専用ホスティングを取得する場合、サーバー/マシンが64,000 TCP接続を一度にしか処理できない場合、これは本当ですか？帯域幅に関係なく処理できますか？HTTPはTCP上で動作すると仮定しています。
これは、64,000人のユーザーのみがWebサイトに接続でき、さらにサービスを提供したい場合、Webファームに移動する必要があることを意味しますか？
要するに、数百万のオーダーで達成できるはずです同時アクティブTCP接続および拡張HTTPリクエスト：これにより、適切な構成の適切なプラットフォームで期待できる最大のパフォーマンスがわかります。
今日、IISが100の同時接続をサポートするかどうかが心配でした（私の更新を見て、古いASP.Net Monoバージョンでは毎秒〜10k応答を期待してください）。この質問/回答を見たとき、私は自分自身に答えることに抵抗できませんでした。ここでの質問に対する多くの答えは完全に間違っています。
ベストケース
この質問に対する答えは、数え切れないほどの変数やダウンストリームで可能な構成から切り離すために、最も単純なサーバー構成にのみ関係する必要があります。
だから私の答えのために次のシナリオを検討してください：
- キープアライブパケットを除き、TCPセッションのトラフィックはありません（そうでない場合、明らかに対応する量のネットワーク帯域幅と他のコンピューターリソースが必要になります）
- プールからの要求ごとのハードウェアスレッドではなく、非同期ソケットとプログラミングを使用するように設計されたソフトウェア。 （つまり、IIS、Node.js、Nginx ...非同期設計のアプリケーションソフトウェアを使用したWebサーバー[Apacheは除く]）
- 良好なパフォーマンス/ドルCPU/Ram。今日、arbitrarily意的に、8GBのRAMを搭載したi7（4コア）としましょう。
- 適したファイアウォール/ルーター。
- 仮想制限/知事なし-すなわち。 Linux somaxconn、IIS web.config ...
- 他のより低速なハードウェアへの依存なし-ハードディスクからの読み取りはありません。これは、ネットワークIOではなく、最も一般的な分母およびボトルネックであるためです。
詳細な回答
同期スレッド限定の設計は、非同期IOの実装に比べてパフォーマンスが低下する傾向があります。
WhatsAppは、単一のUnixフレーバーOSマシンで100万のWITHトラフィックを取得します- https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ 。
そして最後に、これは http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html 、1000万個を達成する方法を詳細に検討します。多くの場合、サーバーにはハードウェアTCPオフロードエンジン、汎用CPUよりも効率的にこの特定の役割のために設計されたASICがあります。
優れたソフトウェア設計の選択肢
非同期IO設計はオペレーティングシステムとプログラミングプラットフォームによって異なります。Node.jsはasynchronousを念頭に設計されています。少なくともPromisesを使用する必要があります。 ECMAScript 7が登場すると、async/await。C＃/。Netにはすでにnode.jsのような完全な非同期サポートがあります。OSとプラットフォームが何であれ、非同期のパフォーマンスは非常に良好です。また、どの言語を選択する場合でも、「非同期」というキーワードを探してください。最新の言語のほとんどは、たとえ何らかのアドオンであったとしても、ある程度サポートされます。
WebFarm？
特定の状況に対する制限が何であれ、はい、Webファームはスケーリングに対する優れたソリューションの1つです。これを達成するための多くのアーキテクチャがあります。 1つはロードバランサーを使用しています（ホスティングプロバイダーはこれらを提供できますが、帯域幅の上限に加えてこれらにも制限があります）が、このオプションは好ましくありません。長時間実行される接続を使用する単一ページアプリケーションの場合、代わりに、クライアントアプリケーションが起動時にランダムに選択し、アプリケーションの存続期間中に再利用するサーバーのオープンリストを作成します。これにより、単一障害点（ロードバランサー）が削除され、複数のデータセンターを介したスケーリングが可能になり、帯域幅が大幅に拡大します。
神話を破る-64Kポート
「64,000」に関する質問コンポーネントに対処するために、これは誤解です。サーバーは、65535を超えるクライアントに接続できます。 https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284 を参照してください
ところで、WindowsのHttp.sysでは、複数のアプリケーションがHTTP URLスキーマの下で同じサーバーポートを共有できます。それらはそれぞれ別個のドメインバインディングを登録しますが、最終的には正しいアプリケーションへのリクエストをプロキシする単一のサーバーアプリケーションが存在します。
2019-05-30を更新
以下は、最速のHTTPライブラリの最新の比較です。 https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- テスト日：2018-06-06
- 使用ハードウェア：Dell R440 Xeon Gold + 10 GbE
- リーダーは1秒あたり700万の平文応答を持っています（接続ではなく応答）
- Golangの2番目のFasthttpは、150万の同時接続をアドバタイズします- https://github.com/valyala/fasthttp を参照してください
- 主要言語は、Rust、Go、C++、Java、C、さらにはC＃ランク（11秒あたり6.9M）です。 ScalaおよびClojureのランクはさらに下にあります。Python 29秒で毎秒2.7Mでランク付けされます。
- リストの一番下で、laravelとcakephp、Rails、aspnet-mono-ngx、symfony、zend。すべてが1秒あたり10k未満です。これらのフレームワークのほとんどは動的に構築されています。ページとかなり古い、リストの上位に機能する新しい亜種があるかもしれません。
- これはHTTPプレーンテキストであり、Websocketの専門分野ではないことを忘れないでください。ここに来る多くの人々は、websocketの同時接続に興味があるでしょう。
この質問はかなり難しいものです。マシンが持つことができるアクティブな接続の数に実際のソフトウェアの制限はありませんが、一部のOSは他のものよりも制限されています。問題はリソースの1つになります。たとえば、1台のマシンで64,000の同時接続をサポートしたいとします。サーバーが接続ごとに1MBのRAMを使用する場合、64GBのRAMが必要です。各クライアントがファイルを読み取る必要がある場合、ディスクまたはストレージアレイのアクセス負荷は、これらのデバイスが処理できるよりもはるかに大きくなりますサーバーが接続ごとに1つのプロセスを分岐する必要がある場合、OSは、コンテキストの切り替えまたはCPU時間の枯渇プロセスの大半をその時間の大半に費やします。
C10K問題 ページには、この問題に関する非常に良い議論があります。
強力なサーバーがあり、サーバーソフトウェアが最適化されていて、十分なクライアントがある場合、答えは少なくとも1200万になります。 1つのクライアントから1つのサーバーにテストする場合、クライアントのポート番号の数は明らかなリソース制限の1つになります（各TCP接続はIPとポート番号の一意の組み合わせによって定義されます発信元と宛先で）。
（それ以外の場合は最初にポート番号で64Kの制限に達するため、複数のクライアントを実行する必要があります）
結局のところ、これは「理論と実践の違いは実際には理論よりもはるかに大きい」-実際には高い数値を達成することはaのサイクルのように見えるという機知の古典的な例です。特定の構成/アーキテクチャ/コードの変更を提案するb。制限に達するまでテストします、c。終わった？そうでない場合d。制限要因が何であったかを解決する、e。ステップaに戻ります（リンスして繰り返します）。
フェニックスを実行している200万TCP=巨大なボックス（128GB RAMおよび40コア）への接続）の例 http：// www。 phoenixframework.org/blog/the-road-to-2-million-websocket-connections -クライアントの負荷を提供するためだけに50台程度のかなり重要なサーバーが必要になりました「4core/15gbボックスを45万クライアントで最大化」）。
今回のgoのもう1つのリファレンスは、1000万です： http://goroutines.com/10m 。
これはJavaベースで1200万の接続： https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with- migratorydata-websocket-server /
会話に2セントを追加するために、プロセスはこの数に等しい数の接続されたソケットを同時に開くことができます（Linuxタイプのシステムの場合）/ proc/sys/net/core/somaxconn
cat/proc/sys/net/core/somaxconn
この番号はその場で変更できます（もちろんrootユーザーのみ）
エコー1024>/proc/sys/net/core/somaxconn
ただし、サーバープロセス、マシンのハードウェア、ネットワーク、システムをクラッシュする前に接続できる実際のソケット数に完全に依存します
HTTPは通常、TCP接続をクライアントにページを送信するよりも長い間開いたままにしないことに注意してください。通常、ユーザーがWebページを読むよりもはるかに時間がかかります。ユーザーがページを表示している間、ページをダウンロードするのに時間がかかりますが、ユーザーはサーバーにまったく負荷をかけません。
そのため、Webサイトを同時に表示できる人の数は、同時に提供できるTCP接続の数よりもはるかに多くなります。
iPv4プロトコルの場合、1つのポートでリッスンする1つのIPアドレスを持つサーバーは、2 ^ 32個のIPアドレスx 2 ^ 16個のポートしか処理できないため、2 ^ 48個の一意のソケットを処理できます。サーバーを物理マシンとして話し、2 ^ 16ポートをすべて使用できる場合、1つのIPアドレスに対して最大2 ^ 48 x 2 ^ 16 = 2 ^ 64の一意のTCP/IPソケットが存在する可能性があります。一部のポートはOS用に予約されているため、この数は少なくなります。総括する：
1 IPおよび1ポート-> 2 ^ 48ソケット
1 IPおよびすべてのポート-> 2 ^ 64ソケット
ユニバースのすべての一意のIPv4ソケット-> 2 ^ 96ソケット
1つのWebサーバーが処理できる同時ソケット接続の数は、各接続が消費するリソースの量と、他のWebサーバーのリソース制限構成を除いたサーバーで使用可能なリソースの総量に大きく依存すると思います。
たとえば、すべてのソケット接続が1MBのサーバーリソースを消費し、サーバーがRAMの（理論的に）16GBを使用できる場合、これは（16GB/1MB）の同時接続しか処理できないことを意味します。私はそれがそれと同じくらい簡単だと思う...本当に！
したがって、Webサーバーが接続を処理する方法に関係なく、すべての接続は最終的に何らかのリソースを消費します。
ここには2つの異なる議論があります。1つは、サーバーに接続できるユーザーの数です。これは他の人から十分に回答されているので、それには入りません。
サーバーがリッスンできるポートはいくつですか？これが、64Kの数字の由来です。実際には、TCPプロトコルはポートに16ビットの識別子を使用し、これは65536（64Kを少し超える）に変換されます。これは、サーバー上でそのような多くの「リスナー」を使用できることを意味しますIPアドレスごと。