학습 목표
전송 계층이 호스트 간(IP) 이 아니라 프로세스 간 통신을 담당함을 설명할 수 있다.
포트 번호와 소켓(IP + port) 주소로 앱을 구분하는 방식을 설명할 수 있다.
멀티플렉싱·역다중화(demux) 로 한 호스트의 여러 앱이 동시에 네트워크를 쓰는 원리를 설명할 수 있다.
ss, lsof 출력에서 포트·LISTEN·프로세스 관계를 읽을 수 있다.
문제 상황
ping 93.184.216.34는 되는데curl https://93.184.216.34는 Connection refused다- IP까지는 갔지만 어느 프로그램이 받을지 정해지지 않았을 수 있다
- 한 서버에서 nginx(443)·DNS(53)·SSH(22) 가 동시에 떠 있다
- 패킷은 같은 IP로 오는데 어떤 프로세스로 넘기는지 모른다
- 클라이언트는 매 연결마다 49152 같은 큰 포트를 쓴다
- well-known과 ephemeral 차이가 불명확하다
- DNS·HTTP는 애플리케이션 계층인데 UDP/TCP 이야기가 나온다
- 앱과 전송 계층 경계, 소켓 API 위치가 헷갈린다
DNS로 IP를 얻었다. 이제 같은 IP를 쓰는 여러 프로세스 중 누구와 대화할지 — 전송 계층이 정한다.
1. 호스트 간 vs 프로세스 간
네트워크 계층(IP) 은 호스트(머신) 까지 패킷을 전달한다. 한 서버 안에는 웹·DB·에이전트 등 여러 프로세스가 동시에 떠 있다.
| 계층 | 전달 단위 | 식별자 |
|---|---|---|
| 네트워크 | 호스트 간 | IP 주소 |
| 전송 | 프로세스 간 | IP + 포트 (소켓) |
- 소켓(socket) —
(source IP, source port, dest IP, dest port, protocol)로 한 통신 종단 식별 - 애플리케이션은
socket()·bind()·connect()로 전송 서비스를 요청 — OS 커널이 실제 UDP/TCP 처리 - IP만 맞고 포트에 LISTEN 중인 프로세스가 없으면 ICMP port unreachable 또는 Connection refused
2. 포트 번호
포트는 16비트(0~65535). 같은 IP 위에서 서비스·프로세스를 구분한다.
| 범위 | 이름 | 용도 |
|---|---|---|
| 0~1023 | Well-known | HTTP 80, HTTPS 443, SSH 22, DNS 53 등 — 관례·IANA |
| 1024~49151 | Registered | 특정 앱 등록 (덜 고정적) |
| 49152~65535 | Dynamic / ephemeral | 클라이언트 임시 출발 포트 — OS가 할당 |
# well-known 포트에서 LISTEN 중인 프로세스
ss -tlnp | head -20
# Local Address:Port 0.0.0.0:443 users:(("nginx",...))- 클라이언트는 보통 ephemeral 포트 →
192.168.1.10:52341→93.184.216.34:443 - 서버는 well-known(또는 고정) 포트에서
listen— 여러 클라이언트 연결 구분은 (클라 IP, 클라 port) 쌍 - 포트 충돌 — 같은 IP:port에 두 프로세스가
bind불가 (SO_REUSEADDR 등 옵션은 별도)
3. 멀티플렉싱과 역다중화
한 호스트는 동시에 DNS 질의, HTTPS, gRPC 등 여러 앱 트래픽을 주고받는다. 전송 계층은 헤더의 포트·프로토콜로 어느 소켓에 넘길지 결정한다.
송신( multiplexing )
- 여러 소켓(앱) → 전송 계층 → IP 하나로 나가는 패킷들에 각각 포트 부여
수신( demultiplexing )
- IP에서 올라온 세그먼트/데이터그램 → 목적지 포트(·프로토콜·연결 4-tuple)로 해당 소켓에 전달
| 프로토콜 | demux 키 (개념) |
|---|---|
| UDP | dest IP, dest port (연결 없음) |
| TCP | dest IP, dest port, src IP, src port — 연결별 큐 |
- 잘못된 demux → 다른 앱에 데이터 유입(버그)·또는 드롭
- NAT는 (내부 IP, port) ↔ (공인 IP, port) 매핑 테이블로 demux 확장 — 이후 편
4. 전송 계층이 제공하는 서비스 (개요)
애플리케이션은 로직에 맞는 전송 서비스를 고른다. 구현체는 주로 TCP와 UDP다.
| TCP | UDP | |
|---|---|---|
| 연결 | 연결 지향 (handshake) | 비연결 |
| 신뢰성 | 순서·재전송·오류 검출 | Best-effort |
| 오버헤드 | 헤더·상태·혼잡 제어 | 가벼움 |
| 흔한 사용 | HTTP/HTTPS, SSH, DB | DNS, VoIP, QUIC 기반 |
- 데이터 무손실·순서가 중요하면 TCP — 다음 편들에서 handshake·신뢰성 상세
- 지연·단순 질의면 UDP — DNS는 짧은 질의·응답
- TLS는 TCP 위(또는 QUIC) — 전송과 암호화는 별 층
5. OS·소켓과의 연계
전송 계층은 커널 안에서 동작한다. 애플리케이션은 소켓 API로만 접근한다.
Application Transport (kernel) Network
───────────── ────────────────── ────────
socket() bind() → port · socket table → IP routing
send() recv() → TCP/UDP segments → datagrams
listen() accept()→ connection queue# 프로세스가 연 연결 (TCP)
ss -tnp | grep ESTAB | head -5
# UDP 53을 연 프로세스
ss -ulnp | grep ':53'- LISTEN — 연결 요청 대기 (TCP 서버)
- ESTABLISHED — TCP 연결 성립 후
- OS 시리즈의 시스템 콜·파일 디스크립터 관점과 연결 — 소켓도 fd
6. 정리
- IP는 호스트까지, 전송 계층은 프로세스(포트) 까지 전달한다
- 소켓 = IP + port (+ protocol) — 멀티플렉싱·demux의 기준
- Well-known vs ephemeral 포트 — 서비스 고정 vs 클라이언트 임시
- TCP·UDP는 서비스 특성이 다른 전송 프로토콜 — 다음 편부터 각각 심화
다음에 다룰 것
- UDP
- 비연결, 헤더 구조, DNS·QUIC 등 사용 사례
해당 내용은 Computer Networking: A Top-Down Approach, 8/E (James Kurose, Keith Ross) 의 내용을 기반으로 합니다.