web-dev-qa-db-ja.com

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

Linuxシステムをセットアップして65,535を超えるポートを提供することは可能ですか？意図は、特定のシステムで65,000を超えるデーモンをリッスンすることです。

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

linuxnetworkingiptcpipv4
53
slm

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

ss #1

IPv6は物事を改善しますか？

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

TCPがIPv6で実行される場合、チェックサムを計算するために使用される方法は RFC 246 に従って変更されます：

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

ss #2

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

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

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

例

$ 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：Life after ifconfig

参考文献

86
slm

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

いいえ。

意図は、特定のシステムで65,000を超えるデーモンをリッスンすることです。

次に必要なもの：

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

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

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

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

6
LawrenceC

良い答えがなかったからといって、チャイムしたかった。

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

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

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

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

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

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

Httpサーバーは、これまたは他のタイプのサーバーも実行できます。

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

2
Jay