システム上の65536 +1接続
ネットワーク内のすべてのシステムに65536ポートがあり、すべての接続または送受信でこれらのいずれかが使用されます。
私の質問は：65536 + 1がある場合はどうなりますか接続？！
私はそれが通常の方法で発生しないことを知っていますが、オペレーティングシステムがそれをどのように処理するか知りたいです。
システムは65536を超える同時接続を処理できることに注意してください。それらはnotを実行するため、必ずしもそれぞれが個別のポートを使用するためです。
TCP接続またはUDPフローは、4タプルによって定義されます。
(source IP address, source port, destination IP address, destination port)
したがって、IPアドレスが1つだけのWebサーバーマシンと、ポート80でのみリッスンする単一のHTTPサーバーソフトウェアパッケージがある場合でも、理論的には65536接続を処理できますそれに接続するクライアントIPアドレスごとに。つまり、クライアントIPアドレス1からの64Ki接続と、クライアントIPアドレス2からの64Ki接続などです。
したがって、プロトコルは、最初の近似で2をサポートします。48 単一のIPv4アドレス上の単一のTCPまたはUDPポートへの接続/フロー。 TCPとUDPの両方、およびIPv4のアドレス空間とIPv6の宇宙的/コミカルな大きなアドレス空間の両方を検討すると、プロトコル自体が同時接続数の制限の原因になる可能性は低いことがわかりますホストが処理できる接続。
同様に、TCPまたはUDPプロトコルには、クライアントマシンが単一のIPアドレスで単一の送信元ポートを使用して、さまざまなサーバーアドレスおよびポートへの複数の送信接続を確立しないようにするものはありません。特定のOSのネットワーキングAPIはこれを容易にできない場合がありますが、たとえば、由緒ある古い「[BSD]ソケット」APIはTCPとUDPの1つのAPIにすぎないことを覚えておくことが重要です。 TCPとUDPには、従来のソケットAPIで公開されていない機能がある場合があります。
そのため、特定のホストが処理できる同時TCP接続またはUDPフローの数は、ポート番号ではなく、RAMスペースや追跡に必要なCPU時間などのシステムリソースによって制限されますそれらすべての接続とサービスを提供します。また、OSの実装固有の詳細により、人為的な制限が課される場合があります。たとえば、Unixの「すべてがファイルである」という哲学では、TCP接続またはUDPフローごとにファイル記述子が存在する場合があります。 Unixカーネルが追跡できるファイル記述子の数に制限がある場合、そのファイル記述子の制限は、カーネルが処理できる同時TCP接続またはUDPフローの数に対する人為的な制限です。