포트 번호 범위 (0–65535)

두 바이트. 열여섯 비트. 인터넷을 오가는 모든 패킷의 모든 포트 번호는 이 공간 안에 들어간다—1970년대에 TCP와 UDP에 새겨진 이 제약이 전체 포트 시스템의 경계를 결정한다.

열여섯 비트는 2^16개의 가능한 값을 의미한다: 정확히 65,536개의 포트, 0부터 65,535까지. 대략이 아니다. "최대"도 아니다. 영원히 정확히 그만큼이다.

왜 열여섯 비트인가?

프로토콜 설계자들은 절충점에 직면했다. 비트를 더 쓰면 포트가 늘어나지만 패킷 헤더가 커진다—초당 수십억 번씩 모든 패킷이 짊어져야 하는 오버헤드다. 비트를 줄이면 헤더는 작아지지만 네트워킹이 성장하면서 포트가 부족해질 수 있었다.

열여섯 비트는 하나의 모험이었다. 1970년대에는 65,536개로 충분하고도 남을 것 같았다. 오늘날, 하나의 서버가 수천 개의 동시 연결을 처리하는 세상에서, 그 한계는 누구도 상상했던 것보다 가깝게 느껴진다.

하지만 그 결정은 굳어버렸다. 지구상의 모든 라우터, 방화벽, 운영 체제는 포트 번호가 정확히 열여섯 비트일 것이라 기대한다. 이를 바꾸려면 TCP와 UDP 자체를 교체해야 한다—만약 그런 일이 일어난다면, 수십 년이 걸릴 전환이다.

세 가지 범위

65,536개의 포트가 모두 동등하지는 않다. IANA(Internet Assigned Numbers Authority)는 이를 세 가지 범위로 나누며, 각각 다른 규칙이 적용된다.

잘 알려진 포트(Well-Known Ports): 0–1023

예약된 포트들이다. HTTP는 80번에, HTTPS는 443번에, SSH는 22번에, DNS는 53번에, SMTP는 25번에 자리한다. 이 할당들은 공식적이고, IANA 레지스트리에 문서화되어 있으며, 전 세계적으로 인정된다.

유닉스 계열 시스템에서 이 포트들에 바인딩하려면 루트 권한이 필요하다. 이것은 임의적인 규칙이 아니다—권한의 문제다.

포트 80에서 서비스를 실행한다는 게 어떤 의미인지 생각해보자. 당신은 하나의 웹 서버라고 주장하는 것이 아니다. 이 IP 주소의 그 웹 서버라고 주장하는 것이다. 포트 80에 연결하는 사람은 누구나 합법적인 웹사이트에 도달하리라 기대한다. 권한 요건은 관리 권한을 가진 사람만이 그런 주장을 할 수 있도록 보장한다.

공식적인 잘 알려진 포트를 얻으려면 공식적인 표준화 과정이 필요하다—보통 RFC를 통해. 그냥 신청하는 것이 아니라, 당신의 프로토콜이 첫 번째 천 개 안에 영구적인 자리를 가질 자격이 있음을 증명해야 한다.

등록된 포트(Registered Ports): 1024–49151

관례적인 포트들이다. MySQL은 3306번을, PostgreSQL은 5432번을, MongoDB는 27017번을 사용한다. 이 할당들은 좀 더 가벼운 절차를 통해 IANA에 등록된다—양식을 제출하고, 서비스를 설명하고, 충돌을 피하면 된다.

여기에 바인딩하는 데 특별한 권한은 필요하지 않다. 어떤 사용자도 3306번 포트에서 서비스를 시작할 수 있다. 그래서 MySQL이 우연히 같은 포트를 선택한 개발자의 사이드 프로젝트와 충돌하는 경우가 생기기도 한다.

등록은 혼란을 방지한다. 등록이 없다면 모든 데이터베이스 벤더가 같은 포트를 기본값으로 설정할 수 있고, 모든 설치마다 수동으로 재구성해야 할 것이다. 이 관례들은 수백만 시간의 트러블슈팅을 줄여준다.

동적 포트(Dynamic Ports): 49152–65535

임시(ephemeral) 포트 범위다. 브라우저가 웹사이트에 연결할 때, 운영 체제는 이 범위에서 소스 포트를 선택한다—52847번, 61293번, 사용 가능한 것 아무거나. 포트는 해당 연결이 지속되는 동안만 존재하다가 풀로 돌아간다.

여기에는 공식 할당도, 등록도 없다. 조직 밖으로 나갈 일이 없는 내부 도구를 만들고 있다면, 이 범위에서 포트를 고르면 어떤 공식 항목과도 충돌하지 않는다.

"임시(ephemeral)"라는 용어가 핵심을 잘 담고 있다: 이 포트들은 빌리는 것이지 소유하는 것이 아니다. 운영 체제가 대여를 관리하여 활성 연결 중 두 연결이 같은 소스 포트를 공유하지 않도록 한다.

레지스트리

IANA는 서비스 이름 및 전송 프로토콜 포트 번호 레지스트리¹를 관리한다—어떤 포트가 무엇을 의미하는지에 대한 권위 있는 목록이다. 공개적으로 접근 가능하고, 정기적으로 업데이트되며, 네트워크 트래픽을 들여다보다가 6379번 포트로 연결이 들어오는 이유가 궁금할 때 유용하다(Redis다).

레지스트리는 포트 번호의 혼란을 방지한다. 중앙 조율이 없다면 할당이 끊임없이 충돌할 것이다. 레지스트리 덕분에 전 세계 관리자들이 공통된 어휘로 방화벽을 설정하고, 패킷 캡처를 읽고, 문제를 진단할 수 있다.

실무에서 알아야 할 것

1024에서의 권한 경계는 보안상의 결정이다. 루트 없이 웹 서버를 실행해야 한다면 두 가지 선택지가 있다: 1023보다 높은 포트(8080 같은)를 사용하여 사용자가 직접 포트를 입력하게 하거나, 80번에서 권한 없는 서비스로 전달하는 리버스 프록시를 앞단에 두는 것이다. 대부분의 프로덕션 배포는 두 번째를 선택한다.

포트 충돌은 진단 단서다. 애플리케이션이 "address already in use"로 실패한다면, 다른 무언가가 그 포트를 먼저 점유한 것이다. 5432번 포트라면? PostgreSQL을 확인하라. 3000번? 누군가 멈추는 것을 잊은 Node.js 개발 서버일 것이다.

방화벽은 종종 범위를 다르게 취급한다. 많은 보안 정책은 아웃바운드 트래픽에 대해 잘 알려진 포트를 제외한 모든 것을 차단한다—악성코드가 비정상적인 포트를 통해 외부와 몰래 통신하는 것을 막는 단순하지만 효과적인 방법이다.

잘 알려진 포트에서의 예상치 못한 트래픽은 경고 신호다. Telnet이 비활성화된 시스템에서 포트 23(Telnet)으로의 연결이 감지된다면? 뭔가 잘못된 것이다. 잘 알려진 포트에는 그에 걸맞은 기대가 있다.

자주 묻는 질문

65,536개의 포트 한도를 늘릴 수 있을까?

TCP와 UDP를 교체하지 않는 한 불가능하다. 16비트 포트 필드는 프로토콜 사양의 일부다—인터넷의 모든 장치는 정확히 16비트를 기대한다. 어떤 변경이든 새로운 프로토콜과 수십 년에 걸친 전환이 필요하다.

리눅스에서는 포트 80에 바인딩하는 데 루트가 필요하지만 윈도우에서는 왜 그렇지 않을까?

윈도우는 다른 보안 모델을 사용한다. 잘 알려진 포트에는 여전히 관리자 권한이 필요하지만, 윈도우에는 유닉스의 루트/비루트 구분이 없다. 근본적인 원칙은 같다: 권한 있는 포트에는 권한 있는 사용자가 필요하다.

등록된 포트를 다른 용도로 사용하면 어떻게 될까?

등록을 강제하는 것은 없다. 바인딩할 수 있는 어떤 포트에서든 어떤 서비스든 실행할 수 있다. 하지만 관례를 무시하면 혼란을 초래한다—누군가 네트워크를 점검할 때 3306번 포트는 MySQL이라고 당연히 가정할 것이다.

임시 포트는 왜 49152번에서 시작할까?

1024–49151 범위는 등록된 서비스를 위해 예약되어 있다. 49152번에서 임시 포트를 시작하면 브라우저가 무작위로 할당한 소스 포트가 이미 의미가 정해진 포트와 충돌하지 않는다. 이 간격이 두 영역을 분리해준다.

출처