Webサーバーはいくつのソケット接続を処理できますか？

共有、仮想、または専用のホスティングを取得する場合、サーバー/マシンが一度に64,000のTCP接続しか処理できない場所を読んだとしましょう。これは本当ですか？帯域幅に関係なく、どのタイプのホスティングでもいくつ処理できますか？HTTPはTCPで動作すると想定しています。

これは、64,000ユーザーしかWebサイトに接続できないことを意味しますか？さらにサービスを提供したい場合は、Webファームに移動する必要がありますか？

要するに、何百万もの同時アクティブTCP接続と、拡張HTTP要求によって達成できるはずです。これにより、適切なプラットフォームの適切な構成で期待できる最大のパフォーマンスがわかります。

今日、ASP.NETを使用するIISが100の同時接続をサポートするかどうかが心配でした（私の更新を見て、古いASP.Net Monoバージョンで1秒あたり約10kの応答を期待してください）。この質問/答えを見たとき、私は自分自身に答えるのに抵抗することができませんでした。ここでの質問に対する多くの答えは完全に間違っています。

最良の場合

この質問への答えは、無数の変数と可能なダウンストリーム構成から切り離すための最も単純なサーバー構成にのみ関係する必要があります。

したがって、私の答えとして次のシナリオを検討してください。

1. キープアライブパケットを除いて、TCPセッションのトラフィックはありません（そうでない場合、対応する量のネットワーク帯域幅と他のコンピューターリソースが明らかに必要になります）
2. プールからの要求ごとのハードウェアスレッドではなく、非同期ソケットとプログラミングを使用するように設計されたソフトウェア。（つまり、IIS、Node.js、Nginx ...非同期設計のアプリケーションソフトウェアを備えた[Apacheではなく] Webサーバー）
3. 優れたパフォーマンス/ドルのCPU / Ram。今日、恣意的に、8GBのRAMを搭載したi7（4コア）としましょう。
4. 適合するファイアウォール/ルーター。
5. 仮想制限/ガバナーなし-つまり Linux somaxconn、IIS web.config ...
6. 他の遅いハードウェアに依存しない-ハードディスクからの読み取りはありません。これは、ネットワークIOではなく、最も一般的な特徴とボトルネックになるためです。

詳細な回答

同期スレッドバウンド設計は、非同期IO実装に比べてパフォーマンスが最も悪くなる傾向があります。

WhatsAppは、単一のUnixフレーバーOSマシンでhttps://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/で 100万のWITHトラフィックを獲得します。

そして最後に、これは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は非同期を考慮して設計されています。少なくともPromiseを使用する必要があります。ECMAScript7が登場したら、async/を使用してくださいawait。C＃/。Netはすでにnode.jsのような完全な非同期サポートを持っています。OSとプラットフォームが何であれ、非同期は非常にうまく機能することが期待されます。そして、どんな言語を選んでも、「非同期」というキーワードを探してください。現代の言語のほとんどは、それが何らかのアドオンであっても、ある程度のサポートがあります。

WebFarmへ？

特定の状況に対する制限が何であれ、はい、Webファームはスケーリングに対する1つの優れたソリューションです。これを実現するための多くのアーキテクチャがあります。1つはロードバランサーを使用しています（ホスティングプロバイダーはこれらを提供できますが、帯域幅の上限に加えてこれらにも制限があります）。ただし、このオプションはお勧めしません。長時間の接続を使用する単一ページアプリケーションの場合、代わりに、クライアントアプリケーションが起動時にランダムに選択し、アプリケーションの存続期間にわたって再利用するサーバーのオープンリストを用意します。これにより、単一障害点（ロードバランサー）が取り除かれ、複数のデータセンター全体のスケーリングが可能になるため、より多くの帯域幅を利用できます。

神話の破壊-64Kポート

「64,000」に関する質問コンポーネントに対処するために、これは誤解です。サーバーは65535より多くのクライアントに接続できます。/networkengineering/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は1.5Mの同時接続をアドバタイズします-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は他のOSよりも制限されていますが、マシンが持つことができるアクティブな接続の数に実際のソフトウェア制限はありません。問題はリソースの1つになります。たとえば、単一のマシンが64,000の同時接続をサポートしたいとします。サーバーが接続ごとに1MBのRAMを使用する場合、64GBのRAMが必要になります。各クライアントがファイルを読み取る必要がある場合、ディスクまたはストレージアレイのアクセス負荷は、これらのデバイスが処理できるよりもはるかに大きくなります。サーバーが接続ごとに1つのプロセスをフォークする必要がある場合、OSはその時間の大部分をコンテキストの切り替えまたはCPU時間の枯渇プロセスに費やします。

C10K問題のページでは、この問題の非常に優れた議論を持っています。

私の2セントを会話に追加するために、プロセスは、この数に等しい接続されたソケットの数を同時に開くことができます（Linuxタイプのシステムの場合）/ proc / sys / net / core / somaxconn

猫/ proc / sys / net / core / somaxconn

この数はオンザフライで変更できます（もちろんrootユーザーのみが変更できます）

エコー1024> / proc / sys / net / core / somaxconn

ただし、サーバープロセス、マシンとネットワークのハードウェア、システムをクラッシュさせる前に接続できる実際のソケット数に完全に依存します。

強力なサーバーがあり、サーバーソフトウェアが最適化されており、十分なクライアントがある場合、答えは少なくとも1200万です。1つのクライアントから1つのサーバーにテストする場合、クライアントのポート番号の数は明らかなリソース制限の1つになります（各TCP接続は、送信元と宛先のIPとポート番号の一意の組み合わせによって定義されます）。

（複数のクライアントを実行する必要があります。そうしないと、最初にポート番号の64K制限に達します）

つまり、これは「理論と実際の違いは、理論よりも実際の方がはるかに大きい」という典型的な例です。実際には、より高い数値を達成することは、aのサイクルのようです。特定の構成/アーキテクチャ/コードの変更を提案する、b。限界に達するまでテストします。終わった？そうでない場合、d。制限要因を突き止める、e。ステップa（すすぎと繰り返し）に戻ります。

ここではフェニックスを実行しているがっしりした体格のボックス（128ギガバイトのRAMおよび40コア）の上に200万TCP接続の一例であるhttp://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections -彼らが終了クライアントの負荷を提供するためだけに50台ほどのかなり重要なサーバーが必要です（最初の小さいクライアントは早期に最大になりました。たとえば、「4コア/ 15 GBボックスで最大の450Kクライアント」）。

今回は1000万回というもう1つのリファレンスを示します。http : //goroutines.com/10m。

これはJavaベースで1200万の接続であるようです：https：//mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

HTTPは通常、ページをクライアントに送信するのにかかる時間よりも長くTCP接続を開いたままにしないことに注意してください。通常、ユーザーがWebページをダウンロードするよりも、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ソケット

ここでは2つの異なる議論があります。1つは、サーバーに接続できる人数です。これは他の人から適切に回答されているので、ここでは説明しません。

他に、サーバーがリッスンできるポートの数はいくつですか？私はこれが64Kの数字の由来だと思います。実際には、TCPプロトコルはポートに16ビットの識別子を使用し、これは65536（64Kより少し多い）に変換されます。これは、IPアドレスごとにサーバー上にその多くの異なる「リスナー」を持つことができることを意味します。

1つのWebサーバーが処理できる同時ソケット接続の数は、各接続が消費するリソースの量と、他のWebサーバーのリソース制限構成を除いてサーバーで使用可能なリソースの合計量に大きく依存すると思います。

たとえば、すべてのソケット接続が1 MBのサーバーリソースを消費し、サーバーが（理論的には）16 GBのRAMを利用できる場合、これは（16 GB / 1 MB）の同時接続しか処理できないことを意味します。とても簡単だと思います...本当に！

したがって、Webサーバーが接続を処理する方法に関係なく、すべての接続は最終的にいくつかのリソースを消費します。