TCP, UDP와 포트

포트 번호는 16비트라서 0부터 65535까지입니다. HTTPS를 쓰는 웹 서버는 443번 포트에서 기다립니다.

문제 두 개로 시작합니다. 영상 통화 중에 친구 목소리의 작은 조각 하나가 오는 길에 사라졌습니다. 내 앱은 그 조각을 다시 보내 달라고 해야 할까요? 이번에는 수행평가 자료 파일을 내려받는데, 파일 조각 하나가 사라졌습니다. 질문은 같습니다. 두 답을 먼저 정하고 나서 읽어 내려가세요.

사라진 조각 둘, 답도 둘

통화는 「아니요」, 파일은 「예」라고 답했다면 이미 두 전송 방식 가운데 하나씩을 고른 겁니다. 0.5초 늦게 온 소리 조각은 쓸모가 없습니다. 대화는 벌써 다음으로 넘어갔으니 그 조각은 건너뛰고 다음 조각을 트는 편이 낫습니다. 반면 조각 하나가 빠진 파일은 망가진 파일이라, 기다려서라도 그 조각을 받아야 합니다. 인터넷은 두 경우에 맞는 전송 방식을 따로 둡니다. 기다렸다가 다시 보내는 TCP와, 보내고 끝내는 UDP입니다. 그런데 둘 중 무엇을 쓰든 그 전에 패킷이 컴퓨터 안의 알맞은 프로그램을 찾아가야 합니다.

패킷을 받을 프로그램은 포트가 정합니다

IP 주소는 패킷을 알맞은 컴퓨터까지 데려다 줍니다. 하지만 컴퓨터 한 대에서는 여러 프로그램이 동시에 돌아갑니다. 탭 여러 개를 연 브라우저, 메신저, 음악 앱이 한꺼번에 켜져 있습니다. TCP 헤더와 UDP 헤더에는 모두 보내는 포트와 받는 포트가 있고, 둘 다 0부터 65535까지의 16비트 숫자입니다. 이 포트 번호가 패킷이 어느 프로그램 몫인지 알려 줍니다. 서버 프로그램은 약속된 포트에서 기다립니다. 평범한 HTTP는 80, HTTPS는 443, DNS는 53, 메일 서버끼리 주고받는 메일은 25입니다. RFC 6335는 이 범위를 셋으로 나눕니다. 0부터 1023은 시스템 포트, 1024부터 49151은 사용자 포트, 49152부터 65535는 동적 포트입니다. 내 컴퓨터는 대화를 하나 시작할 때마다 임시로 쓸 보내는 포트를 고르는데, 흔히 동적 범위에서 고릅니다. 198.51.100.20:443처럼 주소와 포트를 붙여 쓰면 대화의 한쪽 끝을 정확히 하나로 가리킬 수 있습니다. 아파트 동 주소(IP 주소)와 호수(포트)를 함께 적어야 택배가 제 집 문 앞에 닿는 것과 비슷합니다.

TCP는 바이트마다 도착을 확인합니다

TCP(RFC 9293)는 믿을 수 없는 패킷 흐름을 바이트가 차례로 흐르는 전화선 비슷한 것으로 바꿉니다. 먼저 양쪽이 세 방향 핸드셰이크로 연결을 맺습니다. 클라이언트가 SYN을 보내고, 서버가 SYN-ACK로 답하고, 클라이언트가 ACK로 받습니다. 그다음부터는 바이트마다 순서 번호가 붙습니다. 받는 쪽은 어디까지 받았는지 확인 응답(ACK)으로 알리고, 순서가 뒤바뀐 조각은 제자리에 끼워 넣습니다. 보낸 쪽은 제한 시간 안에 ACK가 오지 않으면 그 데이터를 다시 보냅니다. RFC 6298은 첫 제한 시간을 1초로 두고, 그 뒤로는 실제로 잰 왕복 시간에 맞춰 고치게 했습니다. 패킷이 사라지는 것을 보면 TCP는 보내는 속도도 늦춥니다. 붐비는 연결 하나에 데이터가 몰려 넘치지 않게 하려는 장치입니다. 수행평가 파일이 한 바이트도 빠지지 않고 도착하는 것은 이 덕분입니다.

UDP는 보내고 잊습니다

UDP(RFC 768, 1980)는 하는 일이 훨씬 적습니다. 헤더가 8바이트뿐이고, 그 안에는 포트 두 개와 길이, 검사합만 있습니다. 핸드셰이크도, 순서 번호도, 다시 보내기도 없습니다. 첫 번째 문제의 영상 통화에는 이쪽이 딱 맞습니다. 짧은 DNS 질문도 UDP를 씁니다. 질문 하나, 답 하나를 주고받는 데 핸드셰이크까지 하면 오히려 느려지기 때문입니다. HTTP/3 밑에서 전송을 맡는 QUIC도 UDP 위에서 돌아가며, 다시 보내기 기능은 자기가 직접 얹습니다.

불러오는 중

끌어서 돌리고, 휠이나 두 손가락으로 확대하세요.

손실이 25%로 맞춰져 있습니다. TCP에서는 패킷마다 초록색 ACK가 돌아오고, 하나가 빠지면 노트북이 제한 시간을 기다린 뒤 그 패킷을 다시 보냅니다(보라색). 그래서 서버는 언제나 메시지 전체를 받습니다. UDP로 바꿔 다시 보내면 사라진 패킷 자리가 점으로 남습니다. 이 모형에서는 ACK가 사라지지 않고 패킷마다 ACK를 따로 보내지만, 실제 TCP는 누적 ACK를 보냅니다.

숫자 네 개가 탭 두 개를 구별합니다

TCP 연결 하나는 숫자 네 개로 정해집니다. 보내는 주소, 보내는 포트, 받는 주소, 받는 포트입니다. 그래서 443번 포트에서 기다리는 서버 하나가 브라우저 수천 개와 동시에 이야기해도 섞이지 않습니다. 내 노트북에서 같은 사이트를 탭 두 개로 열어도 마찬가지입니다. 탭마다 연결의 보내는 포트가 다르기 때문입니다. 시뮬레이터에서 패킷 하나를 눌러 헤더를 읽어 보세요. 공유기 앞에서는 보내는 쪽이 192.168.0.12의 51000번 포트입니다. 공유기를 지나면 NAT가 두 숫자를 다 바꿔 놓고, 공유기는 무엇을 무엇으로 바꿨는지 기억해 두었다가 답장을 맞는 탭으로 돌려보냅니다.

	TCP	UDP
연결 맺기	세 방향 핸드셰이크	없음
사라진 데이터	제한 시간 뒤 다시 보냄	그대로 사라짐
순서	순서 번호로 되돌림	보장하지 않음
헤더	20바이트 이상	8바이트
흔한 쓰임	웹 페이지, 이메일, 파일 내려받기	DNS 질문, 음성·영상 통화, 게임, QUIC

포트 443	HTTPS
포트 80	암호화하지 않은 HTTP
포트 53	DNS
포트 25	메일 서버 사이의 이메일(SMTP)
SYN, SYN-ACK, ACK	TCP 세 방향 핸드셰이크
ACK	확인 응답: "여기까지 받았습니다"

가장 큰 포트 번호는 무엇입니까?
웹 서버는 HTTPS에 몇 번 포트를 씁니까?
DNS는 몇 번 포트를 씁니까?
브라우저가 보내는 포트로 50000을 씁니다. RFC 6335의 어느 범위입니까?
- 동적 (49152~65535)
- 시스템 (0~1023)
- 사용자 (1024~49151)
- 쓸 수 없는 포트
TCP 핸드셰이크를 순서대로 놓으세요.
UDP 헤더는 몇 바이트입니까?
왕복 시간을 아직 재지 못했을 때 RFC 6298이 정한 첫 재전송 제한 시간은 몇 초입니까?
손실이 25%일 때 TCP는 사라진 패킷을 어떻게 처리합니까?
- 제한 시간 뒤 다시 보낸다
- 건너뛴다
- 메시지 전체를 처음부터 다시 보낸다
- 바로 연결을 끊는다
영상 통화가 UDP를 자주 쓰는 이유는 무엇입니까?
- 늦게 온 소리는 쓸모가 없어서 다시 보내기를 기다려도 소용없다
- UDP가 통화를 암호화한다
- UDP는 패킷을 잃지 않는다
- TCP는 소리를 실을 수 없다
포트 번호는 모두 몇 가지입니까?

자주 하는 실수

「UDP는 데이터를 흘리는 불량 TCP다.」 UDP는 늦게 온 데이터가 쓸모없거나 질문 하나, 답 하나면 되는 경우에 일부러 고르는 방식입니다. 통화, 게임, DNS가 그렇습니다. QUIC은 UDP 위에 신뢰성을 직접 쌓기까지 합니다. 통화에서 다시 보내기를 기다리면 소리가 끊겨 오히려 듣기 나빠집니다.
「포트는 컴퓨터 뒤에 있는 꽂는 구멍이다.」 이름만 같습니다. TCP와 UDP의 포트는 패킷 헤더에 적힌 0~65535의 16비트 숫자이고, 꽂는 구멍이 아니라 프로그램을 가리킵니다. 컴퓨터 뒤의 구멍은 USB 포트, 랜 포트처럼 따로 부르는 이름이 있습니다.
「패킷 하나가 사라지면 TCP는 파일 전체를 처음부터 다시 보낸다.」 제한 시간이 지나면 사라진 부분만 다시 보냅니다. 순서 번호와 ACK를 보면 어느 부분이 아직 확인되지 않았는지 알 수 있고, 나머지는 받는 쪽에 이미 있습니다.

선생님 메모TCP, UDP라는 이름을 말하기 전에 두 문제부터 물어보세요. 늦게 온 소리 조각은 버려도 된다는 결론을 학생이 스스로 내리고 나면, 두 이름은 이미 내린 선택에 붙이는 이름표가 됩니다. 핸드셰이크는 몸으로 해 보면 빨리 익힙니다. 양 끝에 한 명씩 서고, 가운데 한 명이 SYN, SYN-ACK, ACK라고 적은 카드를 차례로 나릅니다. 막히는 곳은 연결을 정하는 숫자 네 개입니다. 같은 사이트를 연 탭 두 개의 연결을 나란히 적어 두고, 보내는 포트만 다르다는 것을 학생이 찾게 하세요. 혼자 공부한다면 80, 443, 53 같은 포트 번호를 플래시카드로 먼저 외워 두면 뒤 단원이 편합니다.

핵심 정리

포트(16비트, 0~65535)는 프로그램을 고릅니다. 80은 HTTP, 443은 HTTPS, 53은 DNS입니다.
TCP: 핸드셰이크(SYN, SYN-ACK, ACK), 순서 번호, ACK, 제한 시간 뒤 다시 보내기.
UDP: 8바이트 헤더, 핸드셰이크와 다시 보내기 없음. 늦은 데이터가 쓸모없을 때 알맞습니다.
QUIC(HTTP/3)은 UDP 위에서 돌며 신뢰성을 스스로 더합니다.

이 과정의 출처 (28)

(checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
RFC 792 ICMP (Time Exceeded)
RFC 801 NCP/TCP transition plan (1 January 1983)
RFC 894 Ethernet (1500-byte payload)
RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
RFC 1122 (127.0.0.0/8 loopback)
RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
RFC 8446 TLS 1.3 (one round-trip handshake)
RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
RFC 9293 TCP (three-way handshake, sequence numbers)
IANA: ip-parameters registry (recommended default TTL 64)
IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
"What is a URL?", "HTTP response status codes" (developer.mozilla.org)
Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
"What is HTTP/3?" (cloudflare.com/learning)
Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
historyofinformation.com and Wikipedia ARPANET (Kline)
Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

확인한 날: 2026-10-17