☰

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

그렇다면 어떻게 더 많은 포트를 얻을 수 있습니까?

한 가지 접근 방식은 더 많은 인터페이스를 사용하여 추가 IP 주소를 쌓는 것입니다. 시스템에 여러 개의 NIC가 있으면 더 쉽지만 NIC가 하나만 있어도 가상 인터페이스(가상 인터페이스라고도 함)를 사용할 수 있습니다.별명) 필요에 따라 더 많은 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^16개 이상의 "포트"를 처리하도록 이 서비스를 설계할 수 있습니다. 2^16개 이상의 리스너를 실행하는 것과 비교하면 성능에 미치는 영향이 최소화될 것이라고 확신합니다.

Linux의 데몬은 파일 시스템에 있는 Unix 소켓을 수신할 수 있으므로 "멀티플렉서 서비스"는 외부 포트 <-> 내부 Unix 소켓의 내부 매핑을 유지할 수 있습니다. 최신 파일 시스템에서 inode가 부족해지기 전에 아마도 커널 프로세스 제한(32KB 프로세스?)에 도달하게 될 것입니다.

답변3

내가 차임하고 싶은 좋은 대답이 없기 때문입니다.

한 가지 접근 방식은 포트 확장을 지정하는 IP 옵션을 추가하는 것입니다. 이 옵션은 IP 헤더의 선택적 부분에 맞게 설계되어야 하며 알 수 없는 홉에서는 건너뜁니다.

이 옵션과 해당 정보를 사용하여 소스, 대상 또는 두 포트 번호 모두를 확장할 수 있습니다.

어쨌든 이러한 제한 사항은 옵션을 추가하는 것만으로는 기존 소프트웨어에서 자동으로 작동하지 않습니다. 구현 방법에 관계없이 옵션을 활용하려면 다시 작성해야 하며 기존 소프트웨어 및 방화벽은 패킷을 무시하거나 다음을 사용하여 평소와 같이 처리합니다. source 포트 필드와 대상 포트 필드의 값입니다.

즉, 이는 쉽지 않으며 재사용 가능한 단일 리스너와 패킷 페이로드에 포함된 데이터를 사용하여 수행하는 것이 가장 좋습니다.

또한 소프트웨어에서 포트 재사용을 더 쉽게 허용할 수 있으며, 이는 여러 클라이언트 연결에 서버 포트를 재사용하여 이러한 제한을 극복하는 데 도움이 될 수 있습니다.

예를 들어, Rtsp는 IP 패킷 페이로드의 다양한 다른 헤더와 함께 SessionId 헤더를 사용하여 요청하는 연결을 결정하고 그에 따라 조치를 취할 수 있습니다. 예를 들어 메시지를 전달하는 소켓이 소켓의 다른 소켓과 다른 경우 원격 세션이 해당하는 주소는 처리를 위해 새 소켓으로 세션을 업데이트하거나, 메시지를 거부하거나, 애플리케이션에 따라 다양한 기타 작업을 수행하도록 허용될 수 있습니다.

HTTP 서버는 이 작업을 수행하거나 다른 유형의 서버도 수행할 수 있습니다.

포트 재사용을 허용할 때 기억해야 할 핵심 사항은 소스 IP 주소도 고려해야 한다는 것입니다.

관련 정보