[Network] 14. 한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 4. 이름을 주소로 바꾸고 대화를 시작하기

ㅁ 들어가며

DNS를 통해 Server의 IP 주소를 알아냈다.

 

example.com → Server IP Address

 

IP 주소를 알면 패킷을 어느 컴퓨터까지 보낼지는 정할 수 있다.

 

하지만 한 컴퓨터에서는 여러 프로그램이 동시에 네트워크를 사용한다.

Server 한 대
├─ Web Server
├─ SSH Server
├─ DNS Server
└─ Database Server

 

패킷이 Server의 Network Interface에 도착한 뒤 운영체제는 데이터를 어느 프로그램에 전달해야 할까?

IP 주소만으로는 컴퓨터 안의 수신 프로그램을 구분할 수 없다.

그래서 TCP와 UDP Header에는 Port Number가 있다.

 

IP 주소가 건물을 찾는 주소라면 Port Number는 그 안에서 서비스를 접수하는 창구 번호다.

 

그러나 Port를 프로그램에 붙은 고정 번호라고만 이해하면

같은 Web Server가 수천 명의 Client 연결을 동시에 처리하는 이유를 설명할 수 없다.

 

이번 글에서는 Transport Layer, Port Number, Socket, Listen, Ephemeral Port, 4-Tuple, 5-Tuple을 통해

운영체제가 여러 프로그램과 연결을 어떻게 구분하는지 살펴본다.

---

ㅁ IP 주소가 건물이라면 Port는 창구다

하나의 우체국 건물 안에 여러 창구가 있다고 생각해 보자.

우체국 주소: 서울시 어느 거리 10

1번 창구: 일반 우편
2번 창구: 국제 우편
3번 창구: 소포
4번 창구: 등기

 

건물 주소만 적으면 우편물은 우체국까지 도착할 수 있다.

그러나 어느 업무 창구에서 처리해야 할지는 알 수 없다.

 

네트워크에서도 IP Layer는 패킷을 목적지 Host까지 전달한다.

그 안의 TCP 또는 UDP는 Destination Port를 보고 해당 데이터를 기다리는 Socket으로 전달한다.

이 과정을 Demultiplexing이라고 한다.

 

반대로 여러 Application의 데이터를 Transport Layer가 Port 정보와 함께

네트워크로 내보내는 것을 Multiplexing 관점으로 볼 수 있다.

송신 Host
여러 Application → Socket/Port → TCP·UDP → IP

수신 Host
IP → TCP·UDP → Destination Port/Socket → 해당 Application

 

Port는 네트워크 패킷이 Host 안의 올바른 통신 끝점으로 전달되게 하는 식별자다.

---

ㅁ TCP Port와 UDP Port는 같은 공간일까?

Port Number는 TCP와 UDP Header에 각각 존재하는 16비트 값이다.

표현 가능한 범위는 다음과 같다.

0 ~ 65535

TCP와 UDP는 서로 다른 Transport Protocol이므로 Port 공간도 별도로 구분된다.

따라서 한 Host에서 다음 두 Socket이 동시에 존재할 수 있다.

TCP Port 53
UDP Port 53

DNS Server가 UDP 53과 TCP 53을 모두 사용하는 것이 대표적인 예다.

Firewall Rule에서도 Protocol을 생략하고 “Port 53을 허용한다”고만 생각하면 한쪽만 허용하거나 필요 이상의 트래픽을 열 수 있다.

UDP/53과 TCP/53은 서로 다른 Endpoint다.

Port Number만으로 통신을 완전히 식별할 수 없는 첫 번째 이유다.

---

ㅁ Port 번호는 누가 정할까?

IANA의 Service Name and Transport Protocol Port Number Registry에서는 Port 범위를 다음과 같이 구분한다.

범위	이름	일반적인 용도
0~1023	System Ports 또는 Well-Known Ports	널리 알려진 표준 Service
1024~49151	User Ports 또는 Registered Ports	등록된 Application과 일반 Service
49152~65535	Dynamic/Private Ports	동적으로 선택하거나 사적으로 사용

 

대표적으로 잘 알려진 Port는 다음과 같다.

 

Service	Transport	기본 Port
SSH	TCP	22
DNS	UDP/TCP	53
HTTP	TCP	80
HTTPS (HTTP/1.1·HTTP/2)	TCP	443
HTTP/3 (QUIC)	UDP	443

하지만 Port Number가 그 Application을 강제로 보장하는 것은 아니다.

• Web Server를 TCP 8080에서 실행할 수 있다.
• TCP 443에서 HTTPS가 아닌 임의의 Protocol을 실행할 수도 있다.
• 아무 Process도 TCP 80에서 기다리지 않을 수 있다.

Port는 관례와 설정으로 Service에 연결된다.

TCP 443이 열려 있음 ≠ 반드시 올바른 HTTPS Service

 

실제 Protocol이 맞는지는 Application Layer의 대화까지 확인해야 한다.

---

ㅁ URL에 Port를 적지 않아도 되는 이유는 무엇일까?

브라우저에 다음 주소를 입력한다.

https://example.com/

 

URL에 Port가 보이지 않지만 https Scheme에는 기본 Port 443이 정의되어 있다.

HTTP/1.1과 HTTP/2는 일반적으로 TCP 443을 사용하고, HTTP/3는 QUIC을 통해 UDP 443을 사용한다.

http://example.com/  → 기본 Port 80
https://example.com/ → 기본 Port 443

 

다른 Port를 사용하려면 URL에 명시할 수 있다.

https://example.com:8443/

 

DNS는 example.com의 IP 주소를 찾는다.

일반적인 A/AAAA 조회가 Service Port까지 알려 주는 것은 아니다.

DNS   : 어느 Host IP로 갈 것인가?
Scheme와 설정: 어느 Transport와 Port를 사용할 것인가?

Service Discovery를 위해 SRV, HTTPS 같은 DNS Record Type을 활용하는 경우도 있지만

일반적인 URL 연결의 기본 Port 선택과는 구분해서 이해해야 한다.

---

ㅁ Server는 창구를 어떻게 열까?

Server Application이 TCP 8080에서 Client를 기다리는 과정을 단순화해 보자.

1. Socket을 만든다.
2. Local IP Address와 Port 8080에 Bind한다.
3. TCP Socket을 Listen 상태로 만든다.
4. Client의 연결 요청을 Accept한다.

 

ㅇ Socket을 만든다

Application은 운영체제에 사용할 Address Family와 Transport Protocol에 맞는 Socket을 요청한다.

Socket은 Application이 Network Stack과 데이터를 주고받는 운영체제 객체 또는 통신 끝점으로 이해할 수 있다.

 

ㅇ Bind한다

어느 Local Address와 Port에서 데이터를 받을지 연결한다.

127.0.0.1:8080
192.168.10.20:8080
0.0.0.0:8080

이 세 설정은 의미가 다르다.

 

ㅇ Listen한다

TCP Server는 해당 Socket을 Client의 연결 요청을 받을 수 있는 Listening 상태로 둔다.

Port가 방화벽에서 허용되어 있어도 Listen하는 Socket이 없다면 Application은 연결을 받을 수 없다.

---

ㅁ 127.0.0.1과 0.0.0.0은 무엇이 다를까?

Server가 어느 Local Address에 Bind했는지는 외부 접근 가능성에 영향을 준다.

 

ㅇ 127.0.0.1:8080

IPv4 Loopback Address에만 Bind한다.

같은 Host 안에서는 접속할 수 있지만 다른 컴퓨터에서 Server의 LAN IP로 접속할 수 없다.

같은 Host → 127.0.0.1:8080 가능
외부 Host → 192.168.10.20:8080 불가

 

ㅇ 192.168.10.20:8080

특정 Interface의 주소에 Bind한다.

그 주소로 들어오는 연결은 받을 수 있지만 다른 Local IP로 들어오는 연결은 별개다.

 

ㅇ 0.0.0.0:8080

일반적으로 Host의 모든 IPv4 Local Address에서 Port 8080을 받는 Wildcard Bind를 뜻한다.

IPv6의 :: Wildcard Bind와 IPv4 동시 처리 관계는 운영체제와 IPV6_V6ONLY 설정에 따라 다를 수 있다.

“Process가 실행 중이다”라는 사실만으로 외부에서 접속할 수 있다고 판단하면 안 된다.

 

다음 세 조건을 나누어 확인해야 한다.

Process가 실행 중인가?
원하는 IP와 Port에 Listen하는가?
경로와 Firewall이 외부 연결을 허용하는가?

---

ㅁ Client도 Port가 필요할까?

Client는 Server의 Destination Port를 알고 접속한다.

Server: 203.0.113.20:443

 

그렇다면 Server가 응답을 돌려줄 Client의 창구도 필요하다.

Client 운영체제는 연결을 시작할 때 사용 가능한 임시 Source Port를 선택한다.

이를 Ephemeral Port라고 한다.

Client: 192.0.2.10:53124
Server: 203.0.113.20:443

 

요청 Segment의 주소는 다음과 같다.

Source Port      : 53124
Destination Port : 443

 

Server의 응답에서는 방향이 바뀐다.

Source Port      : 443
Destination Port : 53124

Client Port 덕분에 운영체제는 돌아온 데이터를 연결을 시작한 Browser Socket에 전달할 수 있다.

 

Ephemeral Port의 실제 할당 범위와 선택 알고리즘은 운영체제와 설정에 따라 다르다.

IANA Dynamic/Private 범위가 49152~65535라고 해서 모든 운영체제가 반드시 그 범위만 사용하는 것은 아니다.

Linux에서는 다음 값으로 로컬 Ephemeral Port 범위를 확인할 수 있다.

sysctl net.ipv4.ip_local_port_range

---

ㅁ Server Port 하나로 여러 Client를 받을 수 있을까?

수천 명의 Client가 모두 같은 Web Server의 TCP 443에 연결할 수 있다.

Port 443 하나뿐인데 운영체제는 각 연결을 어떻게 구분할까?

 

TCP 연결은 다음 네 값을 함께 사용해 구분할 수 있다.

Source IP
Source Port
Destination IP
Destination Port

이를 4-Tuple이라고 한다.

 

세 Client가 같은 Server에 접속하는 예를 보자.

192.0.2.10:51001 → 203.0.113.20:443
192.0.2.11:51002 → 203.0.113.20:443
192.0.2.12:51003 → 203.0.113.20:443

Destination IP와 Port는 같지만 Source IP 또는 Source Port가 다르므로 서로 다른 연결이다.

 

Transport Protocol까지 포함하면 흔히 5-Tuple이라고 한다.

Protocol
Source IP
Source Port
Destination IP
Destination Port

TCP, 192.0.2.10, 51001, 203.0.113.20, 443
TCP, 192.0.2.11, 51002, 203.0.113.20, 443

Firewall, NAT, Load Balancer도 Flow를 구분할 때 이 5-Tuple을 중요한 기준으로 사용한다.

하나의 Listening Port가 하나의 연결만 의미하지 않는다.

Listening Socket은 새로운 연결 요청을 받는 창구이고,

Accept된 각 TCP 연결은 서로 다른 4-Tuple을 가진 연결 Socket으로 관리된다.

---

ㅁ Listening Socket과 연결 Socket은 어떻게 다를까?

TCP Server의 상태를 단순화하면 두 종류의 Socket을 볼 수 있다.

 

ㅇ Listening Socket

Local Address : 0.0.0.0:443
State         : LISTEN

새로운 Client의 연결 요청을 받기 위한 Socket이다. 아직 특정 Remote IP와 Port 하나에 연결되지 않았다.

 

ㅇ Established Socket

Local  : 203.0.113.20:443
Remote : 192.0.2.10:51001
State  : ESTABLISHED

특정 Client와 연결된 통신 Socket이다.

다른 Client가 접속하면 같은 Local Port 443을 사용하면서 Remote Endpoint가 다른 Established Socket이 추가된다.

LISTEN 0.0.0.0:443
├─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.10:51001
├─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.11:51002
└─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.12:51003

이 구조가 Server Port 하나로 많은 Client 연결을 동시에 처리할 수 있게 한다.

---

ㅁ Port는 Process ID일까?

Port Number와 Process ID는 다른 개념이다.

• 하나의 Process가 여러 Port에 Listen할 수 있다.
• Process가 재시작되면 PID가 바뀌어도 같은 Port에 다시 Bind할 수 있다.
• 하나의 Process가 여러 Socket과 연결을 가질 수 있다.
• 운영체제 기능과 설정에 따라 여러 Worker가 같은 Port를 공유할 수도 있다.

운영체제는 Socket과 Process의 관계를 관리한다.

Port는 Network Stack이 데이터를 전달할 Endpoint를 찾는 정보이지 운영체제 Process 자체의 고유 번호가 아니다.

Port가 사용 중이라는 오류가 발생하면 같은 Local Address, Port, Protocol 조합에 이미 충돌하는 Bind가 있는지 확인해야 한다.

SO_REUSEADDR, SO_REUSEPORT, Wildcard Bind 같은 옵션은

Bind 충돌과 공유 방식에 영향을 주지만 운영체제마다 세부 동작이 다를 수 있다.

---

ㅁ TCP와 UDP는 Socket을 같은 방식으로 구분할까?

TCP는 연결을 설정하고 각 연결의 상태를 관리한다.

Listening Socket에서 Accept된 연결은 4-Tuple로 구분된다.

UDP는 TCP와 같은 Handshake와 Connection State를 기본적으로 제공하지 않는다.

하나의 UDP Socket이 여러 Remote Endpoint에서 오는 Datagram을 받을 수 있다.

Application은 수신 API가 제공하는 Source IP와 Source Port를 보고 누구에게 응답할지 결정할 수 있다.

UDP Socket도 운영체제 API에서 connect할 수 있지만 이는 TCP Handshake를 만든다는 뜻이 아니다.

기본 Remote Endpoint를 지정하고 다른 Source의 Datagram 처리나 오류 전달 방식을 제한하는 로컬 Socket 설정에 가깝다.

TCP Socket : 연결 상태와 Byte Stream을 관리
UDP Socket : 독립적인 Datagram 송수신 Endpoint

Port Number는 두 Protocol에 모두 있지만 통신 의미는 다르다.

---

ㅁ Port가 닫혀 있으면 어떤 응답이 올까?

Host까지 IP Packet이 정상적으로 도착했지만 Destination Port에서 기다리는 Application이 없을 수 있다.

 

ㅇ TCP Port에 Listener가 없음

운영체제는 일반적으로 TCP RST로 연결을 거절할 수 있다.

Client에서는 다음과 같은 즉시 오류가 보일 수 있다.

Connection refused

이는 Server Host까지의 경로가 살아 있고 해당 Port에 Listener가 없다는 강한 단서가 될 수 있다.

 

ㅇ Firewall이 Packet을 조용히 Drop

Client의 SYN이 폐기되고 오류 응답도 없다면 재전송 뒤 Timeout이 발생할 수 있다.

Connection timed out

 

ㅇ UDP Port에 Listener가 없음

운영체제는 ICMP Destination Unreachable, Port Unreachable을 보낼 수 있다.

하지만 ICMP 정책과 Application API에 따라 Client가 이를 바로 확인하지 못할 수 있다.

 

오류 메시지는 환경과 정책에 따라 달라질 수 있다.

Refused  : Host 응답은 왔지만 TCP Listener가 없을 가능성
Timeout  : 경로, Firewall, Server 무응답 등 여러 가능성

 

Port 상태만으로 전체 Application의 정상 동작까지 보장되지는 않는다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
우체국 건물 주소	IP Address	Network에서 Host 또는 Interface를 식별하는 주소
건물 안 업무 창구 번호	Port Number	Host 안의 Transport Endpoint를 구분하는 16비트 값
창구를 열고 기다림	Bind / Listen	Local Address와 Port에서 연결 요청을 받을 준비
사용자가 잠시 배정받은 답장 창구	Ephemeral Port	Client가 연결 Source에 동적으로 사용하는 Port
창구와 Application을 잇는 접점	Socket	Application과 Network Stack 사이의 통신 Endpoint
여러 창구의 우편을 한 운송망에 실음	Multiplexing	여러 Application Traffic을 Transport/IP로 전달
도착 우편을 알맞은 창구로 분류	Demultiplexing	Header 정보를 보고 올바른 Socket에 전달
보내는 곳과 받는 곳의 네 주소	4-Tuple	Source/Destination IP와 Port로 TCP 연결 구분
운송 방식까지 포함한 주소표	5-Tuple	Protocol과 Source/Destination IP·Port로 Flow 구분

 

Application 연결 준비의 흐름은 다음처럼 정리할 수 있다.

1. DNS로 Server IP Address를 찾는다.
2. Scheme과 Application 설정으로 Transport Protocol과 Destination Port를 정한다.
3. Client OS가 Source IP와 Ephemeral Port를 선택한다.
4. Server의 Listening Socket에 연결을 시도한다.
5. 운영체제가 5-Tuple을 기준으로 Traffic을 해당 Socket에 전달한다.

---

ㅁ 직접 Port와 Socket을 관찰해 보기

Linux에서 Listening TCP Socket을 확인한다.

ss -lnt

 

주요 옵션은 다음과 같다.

-l : Listening Socket
-n : Service Name 대신 숫자로 표시
-t : TCP

 

UDP Listening Endpoint를 확인한다.

ss -lnu

 

Process 정보까지 보려면 권한이 필요할 수 있다.

sudo ss -lntup

 

현재 TCP 연결의 Local과 Peer Address를 본다.

ss -tn

 

macOS에서는 lsof로 Listening TCP Socket을 확인할 수 있다.

lsof -nP -iTCP -sTCP:LISTEN

 

간단한 TCP Listener를 개인 환경에서 열어 볼 수 있다. nc 구현에 따라 옵션 문법이 다를 수 있다.

첫 번째 Terminal:

nc -l 8080

두 번째 Terminal:

nc -v 127.0.0.1 8080

연결한 상태에서 ss -tn 또는 lsof -nP -iTCP:8080을 실행해 다음을 확인한다.

• Server의 Listening Port 8080
• Client가 선택한 Ephemeral Port
• Local Address와 Peer Address가 뒤바뀐 양쪽 Socket

TCP 1024 미만의 System Port에 Bind하려면 운영체제에서 높은 권한이 필요할 수 있다.

관찰 실습에는 일반 사용자로 열 수 있는 8080 같은 높은 Port를 사용한다.

 

공유 Server에서 임의의 Listener를 열면 정책 위반이나 Port 충돌이 생길 수 있으므로 개인 개발 환경에서만 수행한다.

---

ㅁ 핵심 정리

• IP Address만으로는 Host 안의 여러 Application을 구분할 수 없어 Transport Port가 필요하다.
• TCP와 UDP Port는 각각 16비트이며 Protocol별로 별도의 Endpoint 공간을 갖는다.
• Port 범위는 System 01023, User 102449151, Dynamic/Private 49152~65535로 등록상 구분된다.
• Well-Known Port는 관례이며 그 Port에서 실제로 어떤 Application Protocol이 동작하는지 보장하지 않는다.
• Server는 Local Address와 Port에 Bind하고 TCP에서는 Listen해 연결 요청을 기다린다.
• Loopback, 특정 IP, Wildcard Address 중 어디에 Bind했는지에 따라 접근 범위가 달라진다.
• Client는 응답을 받을 Source Endpoint에 Ephemeral Port를 사용한다.
• 같은 Server Port의 여러 TCP 연결은 Source/Destination IP와 Port의 4-Tuple로 구분된다.
• Protocol까지 포함한 5-Tuple은 Firewall, NAT, Load Balancer의 Flow 구분에도 사용된다.
• Port는 Process ID가 아니며 Socket과 Process의 관계는 운영체제가 관리한다.
• TCP Refused와 Timeout은 실패한 단계가 다를 수 있다.

 

핵심 용어: Transport Layer, Port Number, TCP Port, UDP Port, Well-Known Port, Registered Port, Dynamic/Private Port, Ephemeral Port, Socket, Bind, Listen, Accept, Loopback, Wildcard Address, Multiplexing, Demultiplexing, 4-Tuple, 5-Tuple, LISTEN, ESTABLISHED, RST

 

Port는 프로그램의 이름표가 아니다. 하나의 Host에서 수많은 통신 흐름을 올바른 Socket으로 나누기 위한 Transport Layer의 창구 번호다.

---

ㅁ 다음 이야기

IP Address와 Port Number를 정하면 어느 Host의 어떤 Application과 통신할지 표현할 수 있다.

이제 데이터를 어떤 규칙으로 보낼지 선택해야 한다.

모든 메시지에 연결 준비, 순서 확인, 수령 확인과 재전송이 필요할까? 아니면 일부 메시지는 빠르게 보내고 Application이 필요한 신뢰성을 직접 결정하는 편이 나을까?

다음 글에서는 「모든 편지에 수령 확인이 필요할까?」라는 질문을 통해 TCP와 UDP의 Header, Byte Stream과 Datagram, Reliability, Ordering, Overhead를 비교한다.