vsockが16ビットではなく32ビットポート番号を使用するのはなぜですか？

私はこの機能に精通していませんが、マニュアルページを読んだ後はTCPとUDPと非常によく似ていますが、同じではないと思います。したがって、TCP / UDPポートの制限は適用されません。 TCPとUDPのアドレス系列はですAF_INET。

Berkeleyソケットでは、「ポート番号」の概念は常に特定のアドレスファミリにのみ適用されます。AF_INET（IPv4）とAF_INET6（IPv6）の両方が16ビットポート番号を使用します。これはTCP / IPプロトコルスタックの標準であるためです。ポート番号は、ネットワーク層（IP）ではなくトランスポート層プロトコル（TCP / UDP / SCTP / DCCP /など）に属しますが、原則として、誰かが16ビット以外のポート番号（8）を使用するのを防ぐことはできません。 -ビットポート番号、32ビットポート番号、可変長ポート番号、ポート番号なし概念）トランスポートプロトコルはIPネットワーク上で実行されます。すべて）、IP経由で直接実行される広く使用されているほぼすべてのトランスポートプロトコルは16ビットポートを使用します。 16ビット以外のポート番号を使用する特定のIPベースのプロトコルのサポートをBerkeleyソケットに追加したい場合は、カスタムプロトコルAF_INET番号（）で標準のアドレス系列（、）を使用できない可能性があります。カスタムアドレスファミリー（これを防ぐためのいくつかの方法がありますが、これらの方法はおそらく良い考えではありません。）AF_INET6IPPROTO_WHATEVER

ただし、16ビットポート番号AF_INETとAF_INET616ビットポート番号の両方が異なる多くのアドレス系列にありますが、他の多くのアドレス系列はそうではありません。の定義はstruct sockaddr各アドレス群によって異なります。一部の異なるアドレスファミリにはポート番号があり、一部には異なる名前を持つ同等の概念があり、一部には実際の同等の概念がありません。ポート番号（または同等のポート番号）を持つアドレスファミリでは16ビットである必要はありません。

たとえば、AF_IBInfinibandにはこれらのポート番号はありませんが、おおよその値はサービスID（64ビット）です。 TCP / IPと同様に、AF_IPX16ビットのポート番号が使用されています（Linuxは4.18でIPXのサポートを中止し、それ以前はSPXのサポートを中止しました）、ポート番号の概念はまったくAF_X25なく、ネットワークアドレス（X.121）しかありません。 X.25を介して複数のサービスをサポートする方法は、複数のX.121ネットワークアドレスをホストに割り当てるか（各サービスごとに1つ）、Berkeley Sockets層の上にある種のアプリケーションレベルの多重化を使用することです。AF_ISO（時々とも呼ばれるAF_OSI）、従来のOSI TP転送プロトコル（X.224 / ISO 8073）は、ポート番号（TSAP）が可変バイト数を持つ可能性がありますが、これは一般的な米国政府標準（GOSIP / FIPS 146）Force 2です。 -byte TSAP（TCP / IPまたはIPX / SPXなどの16ビット）。 （AF_ISO/はメインラインLinuxには登場したことはありませんが、4.4BSD、一部のAF_OSI商用Unix、および一部のメインフレーム/ミニコンピュータオペレーティングシステムに含まれています。struct sockaddr_isoこれは実際にBluetoothアドレスを同期するために使用されます。

TIPC（Transparent Inter-Process Communication）は、コンピュータクラスタのノード間通信用に設計されたプロトコルであり、サポートはLinuxカーネルに含まれています。 TIPCはUDP / IPを介して実行することも、EthernetまたはInfinibandを介して直接実行することもできます。 TIPC( AF_TIPC, struct sockaddr_tipc) には 32 ビットのポート番号があります。 UDP経由で実行している場合、32ビットTIPCポート番号は16ビットUDPポート番号とは無関係です。 UDPポート番号は、システム管理者がクラスタ内のノード間でUDPリンクを設定したときに決定されます。ソケットを使用するのに便利ですAF_TIPC。アプリケーションには表示されません。

AF_VSOCKVSOCKは、仮想マシンで実行されているソフトウェアとそのソフトウェアが実行されているハイパーバイザー間の通信用に設計されたプロトコルです。これは、IPなどのネットワークプロトコルを介さずに単一のシステムでのみ実行されるため、ポート番号を16ビットに制限する理由はありません。 32ビットアーキテクチャでは、16ビット値が32ビットで満たされていない限り、32ビット値よりもパフォーマンスが低下する傾向があります。良いパフォーマンスを得るには、32ビットで埋めなければならないからです。 32ビットに設定して起動することをお勧めします。同じロジックは64ビットアーキテクチャに対して64ビットにすることができますが、これは32ビットプラットフォームでパフォーマンスが低下する可能性があり、これは現在32ビットポートよりもVSOCKを設計する場合ははるかに重要です。すべての人のニーズを満たすのに十分であり、64ビットポート番号の制限の利点は、32ビットプラットフォームのパフォーマンスの欠点よりも大きくはありません。

注AF_VSOCK: これは、Linux カーネルでハイパーバイザー通信に使用される唯一のアドレス・ファミリーではありません。 VSOCKはVMwareによって開発されましたが、その後KVM、QEMU、およびMicrosoft Hyper-Vを含む他のベンダーによってコピーされました。 IBMのz / VMハイパーバイザー（メインフレーム用）はVSOCKを使用しません。同じ機能を実行するIUCVと呼ばれる独自のプロトコルがあります。 IUCVはVSOCKよりずっと古い。 VMwareは2008年にVSOCKをリリースしました。 IBMはIUCVの最初のバージョンをリリースしました。1980年に。私が知る限り、Linuxカーネル開発チームは、各個々のVMベンダーがハイパーバイザー通信のために独自のアドレスファミリを定義したくないので、他の誰もがAF_VSOCKVMwareが発明したアドレスファミリを使用する必要があることをすべての人に明らかにしました。 。 IBMのIUCVプロトコルはVMwareプロトコルより前のバージョンであり、アドレス指定が完全に互換性がないため、この規則から除外されます。

AF_IUCVAddress() は数値ポート番号を使用しませんが、struct sockaddr_iucv8 バイトの空白が追加された人が読める文字列に基づいています (EBCDIC では Linux ではユーザー空間では ASCII ですが、ASCII/EBCDIC 変換はカーネル内で発生します)。sockaddr_iucv実際には、先頭に32ビットアドレス番号と16ビットポート番号フィールドがあり、これらのフィールドは予約されており、常に0に設定されています。 Linuxではこれが真実であることがわかりますが、LinuxはBerkeley Sockets IUCV実装で同じことを行うIBMのメインフレームオペレーティングシステム（CMSやz / OSなど）からこれらの予約フィールドをコピーします。 IBMがこれをした理由は、エラーを減らすことだと思います。誤って（、IPv4）のみを期待するアプリケーション/ライブラリにaを渡すと、IPv4アドレスとポートのsockaddr_iucv解釈sockaddr_inAF_INET0.0.0.0:0