TCPは65535を超えるポートを提供できますか？

65,535以上のポートを提供するようにLinuxシステムをセットアップすることは可能ですか？意図は、特定のシステムでリッスンする65k以上のデーモンを持つことです。

明らかに使用されているポートがあるため、これらの理由でこれは不可能です。したがって、これは、TCPがこのようなことを行う際に制限される場所を理解しようとする理論的な演習と考えてください。

TCPのRFC：RFC 793-Transmission Control Protocolを見ると、ソース/宛先ポートフィールドのTCPヘッダーが16ビットに制限されているため、答えは「いいえ」と思われます。

IPv6は状況を改善しますか？

いいえ。IPv6は、32ビット対128ビットのはるかに大きなIPアドレス空間を提供しますが、ポート番号の16ビットのTCPパケット制限を改善する試みは行いません。興味深いことに、IPv6のRFC：インターネットプロトコル、バージョン6（IPv6）仕様、IPフィールドを拡張する必要がありました。

TCPがIPv6で実行されると、RFC 2460に従って、チェックサムの計算に使用される方法が変更されます。

チェックサムの計算にIPヘッダーからのアドレスを含むトランスポートまたはその他の上位層プロトコルは、32ビットIPv4アドレスの代わりに128ビットIPv6アドレスを含めるために、IPv6で使用するために変更する必要があります。

それでは、どうすればより多くのポートを取得できますか？

1つのアプローチは、より多くのインターフェイスを使用して追加のIPアドレスをスタックすることです。システムに複数のNICがある場合、これは簡単ですが、単一のNICでも、必要に応じて仮想インターフェイス（別名エイリアス）を使用してより多くのIPを割り当てることができます。

注：エイリアスをiproute2使用することは、eth0代わりに単一のインターフェイス（つまり）でIPアドレスをスタックするために使用できます。

例

$ sudo ip link set eth0 up
$ sudo ip addr add 192.0.2.1/24 dev eth0
$ sudo ip addr add 192.0.2.2/24 dev eth0
$ ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

ソース：iproute2：ifconfig after ifconfig

参照資料

• OpenWrt Wiki»ドキュメンテーション»ネットワーキング»Linuxネットワークインターフェイス
• iproute2を使用した便利なコマンド
• Linux Advanced Routing＆Traffic Control HOWTO
• Linuxでの複数のデフォルトルート/パブリックゲートウェイIP
• iproute2チートシート-Daniil BaturinのWebサイト

65,535以上のポートを提供するようにLinuxシステムをセットアップすることは可能ですか？

いや。

意図は、特定のシステムでリッスンする65k以上のデーモンを持つことです。

次に必要なもの：

• iptablesトラフィックコンテンツにリダイレクトする構成または

• 単一のポートで着信接続を受け入れ、「背後の」適切なデーモンにルーティングする「サービスブローカーサービス」または「マルチプレクササービス」。標準プロトコルを変更せずに渡す場合は、IDSまたはレイヤー7ファイアウォールが分析する方法で、このマルチプレクササービスにプロトコルスニッフィング/認識を実装する必要があります。ほとんどのプロトコルで完全に可能です。

2番目の項目では、本当に必要な場合、2 ^ 16を超える「ポート」を処理するようにこのサービスを設計できます。実行中の2 ^ 16 +リスナーの負荷と比較して、パフォーマンスへの影響は最小限になると確信しています。

Linuxのデーモンは、ファイルシステムに存在するUNIXソケットをリッスンできるため、「マルチプレクササービス」は外部ポート<->内部UNIXソケットの内部マッピングを維持できます。最新のファイルシステムでiノードが不足する前に、カーネルプロセスの制限（32Kバイトプロセス？）に達する可能性があります。

良い答えがなかったからといって、私はチャイムを鳴らしたかったのです。

これを行う1つの方法は、ポート拡張子を指定するIPオプションを追加することです。このオプションは、IPヘッダーのオプション部分に収まるように設計する必要があり、不明なホップによってスキップされます。

このオプションを使用すると、送信元、宛先、または両方のポート番号を拡張するための情報情報になります。

とにかくオプションを追加するだけで既存のソフトウェアで制限が自動的に機能することはありません。実装方法に関係なく、オプションを利用するように書き換える必要があります。既存のソフトウェアとファイアウォールはパケットを無視するか、通常どおりに処理します送信元および宛先ポートフィールドの値を使用します。

要するに、それは簡単ではなく、単一の再利用可能なリスナーとパケットのペイロードに含まれるデータを使用して行うほうがよいでしょう。

ソフトウェアでポートの再利用をより簡単に許可することもできます。これにより、複数のクライアント接続にサーバーのポートを再利用することで、この制限を克服できます。

たとえば、RtspはSessionIdヘッダーをIPパケットのペイロードの他のさまざまなヘッダーと組み合わせて使用​​して、要求が発行された接続を判断し、それに応じて動作できます。たとえば、メッセージの配信元のソケットがセッションが対応するリモートアドレスは、処理のために新しいソケットでセッションを更新できるようにするか、アプリケーションに応じてメッセージまたはその他のさまざまなアクションを拒否します。

Httpサーバーは、これまたは他の種類のサーバーも実行できます。

ポートの再利用を許可する際に覚えておくべき重要なことは、ソースIPアドレスも考慮する必要があるということです。

はい、できます！

たとえば、Edgehill暗号化サーバーでは、25.000.000以上のデーモンがオンラインで実行されています。