TCP の RFC:RFC 793 - Transmission Control Protocol を見ると、TCP ヘッダーが送信元/宛先ポート フィールドで 16 ビットに制限されているため、答えはノーのようです。
IPv6 は物事を改善しますか?
いいえ。IPv6 は、128 ビットに対して 32 ビットと、はるかに大きな IP アドレス空間を提供しますが、ポート番号の 16 ビットの TCP パケット制限を改善しようとはしません。興味深いことに、IPv6 の RFC:インターネット プロトコル バージョン 6 (IPv6) 仕様では、IP フィールドを拡張する必要がありました。
<ブロック引用>TCP が IPv6 で実行される場合、RFC 2460 に従って、チェックサムの計算に使用される方法が変更されます:
<ブロック引用>チェックサム計算で IP ヘッダーからのアドレスを含むトランスポートまたはその他の上位層プロトコルは、32 ビット IPv4 アドレスの代わりに 128 ビット IPv6 アドレスを含めるために、IPv6 で使用するために変更する必要があります。
ポートを増やすにはどうすればよいでしょうか?
1 つのアプローチは、より多くのインターフェイスを使用して追加の IP アドレスをスタックすることです。システムに複数の NIC がある場合、これは簡単ですが、NIC が 1 つだけの場合でも、必要に応じて仮想インターフェイス (エイリアス) を使用してより多くの 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:ifconfig 後のライフ
参考文献
- OpenWrt Wiki » ドキュメント » ネットワーク » Linux ネットワーク インターフェース
- iproute2 の便利なコマンド
- Linux Advanced Routing &Traffic Control HOWTO
- Linux での複数のデフォルト ルート / パブリック ゲートウェイ IP
- iproute2 チート シート - Daniil Baturin の Web サイト
<ブロック引用>
65,535 を超えるポートを提供するように Linux システムをセットアップすることは可能ですか?
いいえ。
<ブロック引用>その意図は、特定のシステムでリッスンする 65,000 を超えるデーモンを持つことです。
次に必要なもの:
-
iptablesトラフィック コンテンツでリダイレクトする構成または -
単一のポートで受信接続を受け入れ、「背後にある」適切なデーモンにルーティングする「サービス ブローカ サービス」または「マルチプレクサ サービス」。標準プロトコルを変更せずに通過させたい場合は、IDS またはレイヤー 7 ファイアウォールが分析する方法で、このマルチプレクサ サービスにプロトコル スニッフィング/認識を実装する必要がある場合があります。大多数のプロトコルで完全に可能です。
2 番目の項目によると、必要に応じて、2^16 を超える「ポート」を処理するようにこのサービスを設計できます。実行中の 2^16+ リスナーの負荷と比較して、パフォーマンスへの影響は最小限になると確信しています。
Linux のデーモンは、ファイルシステムに存在する UNIX ソケットをリッスンできるため、「マルチプレクサ サービス」は外部ポート <-> 内部 UNIX ソケットの内部マッピングを維持できます。最新のファイルシステムでは、inode を使い果たす前に、カーネル プロセスの制限 (32K バイトのプロセス?) に達する可能性があります。
良い答えがないからといって、私が協力したかったのです。
これを行う 1 つの方法は、ポート拡張を指定する IP オプションを追加することです。オプションは、IP ヘッダーのオプション部分に収まるように設計する必要があり、不明なホップによってスキップされます。
このオプションとその情報情報を使用して、ソース、宛先、または両方のポート番号を拡張します。
いずれにせよ、オプションを追加するだけでは、既存のソフトウェアで制限が自動的に機能するわけではありません。オプションがどのように実装されていても、オプションを利用するには書き直す必要があります。既存のソフトウェアとファイアウォールは、パケットを無視するか、通常どおりに処理します。送信元および宛先ポート フィールドの値を使用します。
要するに、これは簡単なことではなく、単一の再利用可能なリスナーとパケットのペイロードに含まれるデータを使用して行う方がよいでしょう。
ソフトウェアでポートの再利用をより簡単に許可することもできます。これにより、複数のクライアント接続にサーバーのポートを再利用することで、この制限を克服することができます。
たとえば、Rtsp は、SessionId ヘッダーを IP パケットのペイロード内のさまざまな他のヘッダーと組み合わせて使用して、要求が発行された接続を特定し、それに応じて動作することができます。メッセージの配信元のソケットが、セッションが対応するソケットのリモート アドレスと同じでない場合は、処理のために新しいソケットでセッションを更新できるようにするか、メッセージを拒否するか、その他のさまざまなアクションを実行できます。アプリケーションによって異なります。
HTTP サーバーは、これまたは他のタイプのサーバーも実行できます。
ポートの再利用を許可する際に覚えておくべき重要なことは、送信元 IP アドレスも考慮する必要があるということです。