利用可能なメモリ、帯域幅、CPU、そしてもちろんネットワーク接続によって課せられる制限があります。しかし、それらは多くの場合、垂直方向にスケーリングできます。Linux に他に制限要因はありますか? カーネルを変更せずにそれらを克服できますか? 何もなければ、制限要因はギガビット イーサネットになるのではないかと思います。しかし、効率的なプロトコルの場合、それを圧倒するには 50K の同時接続が必要になる可能性があります。私がそんなに高くなる前に、他の何かが壊れるでしょうか？
ソフトウェア udp および/または tcp/ip ロード バランサーが必要だと考えています。残念ながら、http プロトコルを除いて、オープンソース コミュニティにはそのようなものは存在しないようです。しかし、epoll を使用してこれを作成することは、私の能力を超えているわけではありません。スケールに合わせるには多くの微調整が必要になると思いますが、それは段階的に行うことができる作業であり、私はそのための優れたプログラマーになるでしょう.
おそらく問題が発生するパラメータの 1 つは、ジッターです。ボックスあたりの接続数をスケーリングすると、間違いなく、そのシステムのすべてのリソースに負担がかかります。その結果、転送機能のジッター特性が低下する可能性があります。
ターゲットの要件によっては、それが問題になる場合とそうでない場合があります。主に伸縮性のあるトラフィック (ジッターやレイテンシーの影響をあまり受けないトラフィック)をサポートする予定であれば、問題ありません。非弾力的なトラフィックの割合が高い場合(インタラクティブな音声/ビデオなど)、これはより大きな問題になる可能性があります。
もちろん、この場合はいつでもオーバー エンジニアできます ;-)
クライアントごとに 1 つのソケットを開いたままにするサーバーを使用する場合は、10,000 以上のクライアントからの受信データを効率的にチェックできるように慎重に設計する必要があります。これは 10k 問題として知られています。
最新の Linux カーネルは、10k をはるかに超える接続 (通常は少なくとも 100k) を処理できます。多くのクライアントが頻繁に接続および切断する場合に、多くのリソースを使用して閉じたり古いソケットを使用したりするのを避けるために、特に多くの TCP タイムアウト (TCP を使用している場合) を調整する必要がある場合があります。
netfilter の conntrack モジュールを使用している場合は、その数の接続を追跡するために調整が必要になる場合があります (これは tcp/udp ソケットとは無関係です)。
ロード バランシングには多くのテクノロジがありますが、最もよく知られているのは、実サーバーのクラスターのフロント エンドとして機能する LVS (Linux Virtual Server) です。処理できる接続数はわかりませんが、本番環境では少なくとも 50k で使用していると思います。
あなたの質問には、ハードウェアの制限によってのみ制限されています。これが Linux システムの設計哲学でした。あなたはあなたの制限要因が何であるかを正確に説明しています.
HAProxy ソフトウェア ロード バランサを試します。