한 기계 안에서 어느 프로세스로 - 포트

IP 주소는 패킷을 기계까지 데려다준다. 그런데 그 기계 안에선 웹 서버도, DB도, SSH도 함께 돈다. 도착한 패킷이 그중 어느 프로그램으로 가야 하나. 그 답이 포트다.

기계엔 닿았는데 어느 프로그램인가

IP 주소로 패킷이 목적지 기계에 도착했다. 하지만 기계 한 대는 여러 프로그램을 동시에 돌린다 - 웹 서버, 데이터베이스, 원격 접속 등. 패킷이 “이 기계로”까지는 왔는데, 그 안의 누구에게 줘야 할지가 안 정해졌다.

편지로 치면 IP는 “이 건물”까지고, 건물 안엔 사무실이 여럿이다. 어느 호실인지가 더 필요하다. 그 호실 번호가 포트(port) 다.

포트: 기계 안의 문 번호

포트는 기계 안의 프로그램을 가리키는 번호(0~65535)다. 웹 서버는 80번 문에서, DB는 다른 문에서 손님을 기다린다. 패킷 겉면엔 IP뿐 아니라 포트 번호도 적혀 있어, 도착한 기계는 그 번호를 보고 맞는 프로그램에게 넘긴다.

plaintext

203.0.113.45 : 443
└────IP────┘   └포트┘
 어느 기계      그 안 어느 프로그램

IP가 “어느 기계”라면 포트는 “그 안 어느 프로세스”다. 이 둘이 있어야 패킷이 최종 목적지까지 간다.

IP와 포트가 한 쌍이다

그래서 통신의 한쪽 끝은 IP + 포트 한 쌍으로 정해진다. 이 쌍을 소켓 주소라 부른다. 연결은 양쪽 끝의 이 쌍으로 성립한다.

plaintext

내 기계 (203.0.113.9 : 51000)  ⇄  서버 (203.0.113.45 : 443)

내 쪽도 포트가 있다는 점을 눈여겨보자 - 내가 보낸 요청의 응답이 내 기계의 어느 프로그램(브라우저) 으로 돌아와야 하니, 내 쪽도 임시 포트를 하나 잡는다. 양쪽 IP·포트 네 값이 이 대화 하나를 유일하게 식별한다.

잘 알려진 포트

아무 번호나 쓰면 손님이 어느 문으로 갈지 모른다. 그래서 흔한 서비스엔 약속된 번호가 있다.

plaintext

80    HTTP        443   HTTPS
22    SSH         5432  PostgreSQL

브라우저가 https://example.com을 열면 말 안 해도 443번으로 간다 - HTTPS의 약속된 포트라서다. 이 약속 덕에 주소에 포트를 안 적어도 통한다. 다른 포트를 쓰면 example.com:8080처럼 직접 적어줘야 한다.

포트로 프로세스를 찾는다

포트가 어떻게 실제 프로그램에 이어지나. 여기서 OS 시리즈와 만난다. 프로그램이 “이 포트에서 손님을 받겠다”고 하면(bind·listen), OS는 그 포트로 오는 걸 그 프로그램의 소켓으로 연결한다. 그 소켓은 파일 디스크립터 하나다.

plaintext

패킷 (…:443 도착)  →  OS가 443을 듣는 프로세스를 찾음  →  그 프로세스의 소켓(fd)로 전달

즉 포트는 네트워크와 프로세스를 잇는 접점이다. 네트워크 쪽에선 포트 번호, 프로세스 쪽에선 소켓 fd - 같은 연결의 양쪽 이름이다. 연결이 fd라던 그 밑바닥이 여기서 네트워크와 맞물린다.

한 포트는 한 프로세스가 듣는다

한 기계에서 같은 포트를 두 프로그램이 동시에 들을 수는 없다. 한 문을 두 사람이 지킬 수 없는 것과 같다. 그래서 웹 서버 두 개를 같은 포트로 띄우려 하면 뒤엣것이 실패한다.

이게 그 익숙한 “port already in use” 오류다. 이미 그 포트를 잡은 프로세스가 있다는 뜻이다. 앞서 죽은 프로세스가 포트를 아직 안 놓았거나, 다른 프로그램이 쓰고 있거나다. 해결은 그 포트를 쓰는 프로세스를 찾아 정리하거나, 다른 포트를 쓰는 것이다.

방화벽은 포트를 막는다

포트는 외부에서 들어오는 문이라, 보안의 요지다. 방화벽은 “어느 포트를 열고 어느 포트를 막을지”로 동작한다 - 웹은 80·443만 열고 나머지는 닫는 식이다.

열린 포트는 곧 공격 표면이다. 안 쓰는 포트를 열어두면 그만큼 두드릴 문이 는다. 그래서 “필요한 포트만 열라”가 기본이다 - DB 포트가 인터넷에 열려 있으면 누구나 문을 두드릴 수 있다.

실무에서: 포트를 만나는 자리

8080인데 443으로 온다 - reverse-proxy 글의 그 상황이다. 앱은 8080에서 듣고, 앞단이 443(HTTPS)으로 받아 8080으로 넘긴다. 포트를 넘기는 이 중계가 프록시의 일이다.
포트 충돌 - “port already in use”면 그 포트를 이미 쓰는 프로세스를 찾는다. 개발 중 서버를 여러 번 띄우다 자주 만난다.
컨테이너 포트 매핑 - 컨테이너는 안의 포트와 밖의 포트를 따로 두고 이어준다(예: 안 8080 ↔ 밖 80). 안팎 포트가 헷갈리면 “떴는데 접속이 안 되는” 일이 생긴다.

정리

IP는 기계까지, 포트는 그 안의 어느 프로세스까지 - 패킷 겉면의 포트 번호로 맞는 프로그램에 전달된다.
통신의 한쪽 끝은 IP + 포트 한 쌍(소켓 주소)이고, 양쪽 네 값이 대화 하나를 유일하게 식별한다.
포트는 프로세스의 소켓(fd)으로 이어진다 - 네트워크와 프로세스를 잇는 접점이다.
한 포트는 한 프로세스만 듣고(“port already in use”), 방화벽은 포트 단위로 문을 여닫는다.

다음 글은 그 포트로 이어진 두 끝이 안 끊기고 순서대로 데이터를 주고받게 하는 - TCP로 간다.