vsock 사양을 읽는 동안 다음 인용문을 발견했습니다.
소켓 주소는 32비트 CID(컨텍스트 식별자)와 32비트 포트 번호의 조합으로 정의됩니다.
원천:http://man7.org/linux/man-pages/man7/vsock.7.html
65535보다 높은 포트번호는 16비트 값이기 때문에 사용할 수 없을 것 같습니다. vsock이 32비트 포트 번호를 사용하는 이유를 아는 사람이 있습니까? 내가 뭐 놓친 거 없니?
답변1
나는 이 기능에 익숙하지 않지만 매뉴얼 페이지를 읽은 후에는 TCP 및 UDP와 매우 비슷해 보이지만 동일하지는 않다고 생각합니다. 따라서 TCP/UDP 포트 제한이 적용되지 않습니다. TCP 및 UDP의 주소 계열은 입니다 AF_INET.
답변2
버클리 소켓에서 "포트 번호" 개념은 항상 특정 주소 계열에만 적용됩니다. AF_INET(IPv4)와 AF_INET6(IPv6) 모두 16비트 포트 번호를 사용합니다. 이는 TCP/IP 프로토콜 스택의 표준이기 때문입니다. 포트 번호는 네트워크 계층(IP)이 아닌 전송 계층 프로토콜(TCP/UDP/SCTP/DCCP/등)에 속하지만 원칙적으로 누군가가 16비트가 아닌 포트 번호(8)를 사용하는 것을 막을 수는 없습니다. -비트 포트 번호, 32비트 포트 번호, 가변 길이 포트 번호, 포트 번호 없음 개념) 전송 프로토콜은 IP 네트워크에서 실행됩니다. 모두), IP를 통해 직접 실행되는 널리 사용되는 거의 모든 전송 프로토콜은 16비트 포트를 사용합니다. 16비트가 아닌 포트 번호를 사용하는 특이한 IP 기반 프로토콜에 대한 지원을 버클리 소켓에 추가하려는 경우 AF_INET사용자 정의 프로토콜 번호( )와 함께 표준 주소 계열( , )을 사용하지 못할 수도 있습니다. 사용자 정의 주소 계열(이를 방지하기 위한 몇 가지 방법이 있지만 이러한 방법은 아마도 좋은 생각이 아닐 것입니다.)AF_INET6IPPROTO_WHATEVER
그러나 16비트 포트 번호 AF_INET와 AF_INET616비트 포트 번호가 모두 다른 많은 주소 계열에 있지만 다른 많은 주소 계열은 그렇지 않습니다. 의 정의는 struct sockaddr각 주소군에 따라 다릅니다. 일부 다른 주소 패밀리에는 포트 번호가 있고 일부는 다른 이름을 가진 동등 개념이 있으며 일부는 실제 동등 개념이 없습니다. 포트 번호(또는 동등한 포트 번호)가 있는 주소 계열에서는 16비트일 필요가 없습니다.
예를 들어 AF_IB(Infiniband)에는 이러한 포트 번호가 없지만 대략적인 값은 서비스 ID(64비트)입니다. TCP/IP와 마찬가지로 AF_IPX16비트 포트 번호가 사용됩니다(Linux는 4.18에서 IPX 지원을 중단했고 그보다 오래 전에 SPX 지원을 중단했습니다.) AF_X25포트 번호에 대한 개념은 전혀 없으며 네트워크 주소(X.121)만 있습니다. X.25를 통해 여러 서비스를 지원하는 방법은 여러 X.121 네트워크 주소를 호스트에 할당하거나(각 서비스당 하나씩) 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/는 AF_OSI메인라인 Linux에는 등장한 적이 없지만 4.4BSD, 일부 상업용 Unix 및 일부 메인프레임/미니컴퓨터 운영 체제에 포함되어 있습니다. 최근 Linux 커널에는 이제 하나가 있지만 struct sockaddr_iso이는 기존 OSI 프로토콜 스택과는 아무런 관련이 없습니다. 이것이 실제로 Bluetooth 주소를 동기화하는 데 사용되는 것입니다.
TIPC(Transparent Inter-Process Communication)는 컴퓨터 클러스터의 노드 간 통신을 위해 설계된 프로토콜이며 지원은 Linux 커널에 포함되어 있습니다. TIPC는 UDP/IP를 통해 실행되거나 이더넷이나 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_in로AF_INET0.0.0.0:0