☰

TCPは65535以上のポートを提供できますか？

tag-icon • tag-icon linux networking ip tcp ipv4
TCPは65535以上のポートを提供できますか？

65,535を超えるポートを提供するようにLinuxシステムを設定できますか？目標は、特定のシステムで65,000以上のデーモンがリッスンすることです。

明らかに使用されているポートがいくつかあるため、この理由で不可能なので、このようなタスクを実行するときにTCPが制限される場所を理解しようとするのは理論的な練習だと思います。

答え1

TCP RFCを確認してください。RFC 793 - 伝送制御プロトコル、TCPヘッダのソース/ターゲットポートフィールドが16ビットに制限されているので、答えは「いいえ」のようです。

    SS＃1

IPv6は現在の状態を改善しますか？

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

TCPがIPv6を介して実行されている場合、チェックサムを計算するために使用される方法は次のように変更されます。RFC 2460:

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

                 SS＃2

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

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

メモ:エイリアスの使用が置き換えられました。iproute2これを使用して単一のインターフェイス（例えば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 以降の寿命

引用する

答え2

65,535を超えるポートを提供するようにLinuxシステムを設定できますか？

いいえ。

目標は、特定のシステムで65,000以上のデーモンがリッスンすることです。

その後、次のものが必要です。

  • iptablesリダイレクトトラフィックコンテンツの設定または

  • 「サービスプロキシサービス」または「マルチプレクササービス」は、単一ポートからの着信接続を受け入れ、「背後にある」適切なデーモンにルーティングします。標準プロトコルを変更せずに通過させるには、ほとんどのプロトコルに対してIDSまたはレイヤ7ファイアウォール分析の形でこのマルチプレクササービスでプロトコルスニッフィング/識別を実装する必要があります。

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

Linuxのデーモンはファイルシステム上のUnixソケットをリッスンできるため、「マルチプレクササービス」は外部ポート<->内部Unixソケットの内部マッピングを維持できます。最新のファイルシステムでinodeが不足する前に、おそらくカーネルプロセス制限（32KBプロセス？）に達するでしょう。

答え3

チャイムしたい良い答えがないからです。

1 つのアプローチは、ポート拡張を指定する IP オプションを追加することです。このオプションはIPヘッダーのオプション部分に合わせて設計する必要があり、不明なホップではスキップされます。

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

いずれにせよ、これらの制限はオプションを追加するだけでは既存のソフトウェアでは自動的に機能しません。実装方法にかかわらず、オプションを利用するには書き直す必要があり、既存のソフトウェアとファイアウォールはパケットを無視するか、次のように処理します。 source ポートフィールドと宛先ポートフィールドの値。

つまり、これは簡単ではなく、再利用可能な単一のリスナーとパケットペイロードに含まれるデータを使用して実行するのが最善です。

また、ソフトウェアでポートの再利用を容易にすることができます。これは、複数のクライアント接続でサーバーポートを再利用することでこれらの制限を克服するのに役立ちます。

たとえば、Rtsp は、IP パケット ペイロードの他のさまざまなヘッダーと SessionId ヘッダーを使用して、要求する接続を決定し、それに応じてアクションを実行できます。たとえば、メッセージを転送するソケットがソケットの他のソケットと異なる場合、リモートセッションが対応するアドレスは、処理のために新しいソケットでセッションを更新したり、メッセージを拒否したり、アプリケーションに応じてさまざまなその他の操作を実行したりすることができます。できます。

HTTPサーバーはこれを行うことも、他の種類のサーバーも実行できます。

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

関連情報