65536 +1システム上の接続

ネットワーク内のすべてのシステムに65536個のポートがあり、すべての接続または送受信がそれらのいずれかを使用します。

私の質問は、65536 + 1の接続がある場合はどうなりますか？！

私はそれが通常の方法では起こらないことを知っていますが、オペレーティングシステムがそれをどのように扱うか知りたいです。

システムは、それぞれが個別のポートを使用する必要はないため、65536を超える同時接続を処理できることに注意してください。

TCP接続またはUDPフローは、4タプルによって定義されます。

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

したがって、単一のIPアドレスを持つWebサーバーマシンと、ポート80のみでリッスンする単一のHTTPサーバーソフトウェアパッケージがある場合でも、理論的には、接続するクライアントIPアドレスごとに 65536接続を処理できます。したがって、クライアントIPアドレス1からの64Ki接続、およびクライアントIPアドレス2からの64Ki接続など

したがって、プロトコルは、最初の概算では、単一のIPv4アドレス上の単一のTCPまたはUDPポートへの2 ⁴⁸接続/フローをサポートします。TCPとUDPの両方、およびIPv4のアドレス空間とIPv6の宇宙的/コミカルに大きなアドレス空間の両方を検討すると、プロトコル自体がホストの同時接続数の制限の原因になりそうにないことがわかります。処理できます。

同様に、TCPまたはUDPプロトコルには、クライアントマシンが単一のIPアドレスの単一のソースポートを使用してさまざまなサーバーアドレスとポートに複数の発信接続を行うことを妨げるものはありません。時々、与えられたOSのネットワーキングAPIはこれを簡単にしないかもしれませんが、例えば、由緒ある古い「[BSD] Sockets」APIはTCPとUDPの1つのAPIにすぎないことを覚えておくことが重要です。TCPとUDPには、従来のSockets APIで公開されていない機能がある場合があります。

したがって、特定のホストが処理できる同時TCP接続またはUDPフローの数は、ポート番号ではなく、すべての接続を追跡してすべてを処理するために必要なRAMスペースやCPU時間などのシステムリソースによって制限されます。また、OSの実装固有の詳細によって、人為的な制限が課される場合があります。たとえば、Unixの「すべてはファイルです」という哲学では、すべてのTCP接続またはUDPフローに対してファイル記述子が存在する場合があります。Unixカーネルが追跡できるファイル記述子の数に制限がある場合、そのファイル記述子の制限は、カーネルが処理できる同時TCP接続またはUDPフローの数に対する人為的な制限です。