테마
TCP와 UDP
IP(Internet Protocol, 인터넷 프로토콜)는 패킷(packet)을 목적지 호스트(host)까지만 데려다준다. 그 호스트 안의 어느 프로그램에게 줄지, 잃어버린 데이터를 어떻게 할지는 전송 계층(transport layer)이 정한다. 전송 계층의 두 프로토콜(protocol) 중 TCP(Transmission Control Protocol, 전송 제어 프로토콜)는 연결을 맺고 순서와 누락을 챙기며, UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 그런 절차 없이 가볍게 보낸다.
포트와 소켓
전송 계층은 한 호스트에서 동시에 네트워크를 쓰는 여러 프로그램, 즉 프로세스(process)를 포트(port)라는 16비트 번호로 구분한다. 포트는 0부터 65535까지이며 세 구간으로 나뉜다. 0~1023은 표준 서비스가 쓰는 잘 알려진 포트(well-known port)로, 원격 접속용 SSH(Secure Shell, 보안 셸)는 22, DNS(Domain Name System, 도메인 이름 시스템)는 53, HTTP는 80, 암호화한 HTTP인 HTTPS(HTTP Secure, 보안 HTTP)는 443을 쓴다. 1024~49151은 특정 서비스용으로 등록해 쓰는 등록 포트, 49152~65535는 등록 없이 임시로 쓰는 동적 포트다.
서버는 정해진 포트에서 연결을 기다리고, 클라이언트는 보통 운영체제가 임시로 골라 준 포트에서 연결을 건다. 이때 프로그램이 운영체제에 여는 통신 끝점이 소켓(socket)이며, 리눅스에서는 소켓도 파일처럼 파일 디스크립터(file descriptor)로 가리킨다. TCP 연결 하나는 출발지 IP 주소·출발지 포트·목적지 IP 주소·목적지 포트의 조합으로 구분되므로, 클라이언트 쪽 주소나 포트가 하나라도 다르면 다른 연결이다. 그래서 서버는 443 포트 하나로 수많은 연결을 동시에 받는다.
TCP와 UDP 비교
TCP는 데이터를 보내기 전에 상대와 연결을 맺고, 보내는 바이트마다 순서 번호(sequence number)를 매겨 받는 쪽이 순서를 맞추게 하며, 잃어버린 데이터는 재전송(retransmission)한다. 흐름 제어(flow control)와 혼잡 제어(congestion control)도 한다(TCP의 신뢰성과 혼잡 제어). UDP는 이런 기능 없이 포트 번호 등을 담은 짧은 헤더(header)만 붙인 데이터그램(datagram)을 바로 내보낸다.
| 기준 | TCP | UDP |
|---|---|---|
| 연결 | 연결을 맺고 시작 | 연결 없이 바로 보냄 |
| 신뢰성 | 잃으면 재전송 | 보장하지 않음 |
| 순서 | 보낸 순서대로 전달 | 보장하지 않음 |
| 흐름·혼잡 제어 | 있음 | 없음 |
| 데이터 경계 | 경계 없는 바이트 흐름 | 데이터그램 단위로 유지 |
| 헤더 크기 | 최소 20바이트 | 8바이트 |
| 속도 | 준비·확인 비용이 있음 | 가볍고 지연이 적음 |
TCP는 데이터를 이어진 바이트 흐름으로 다뤄 한 번에 보낸 두 메시지가 붙거나 나뉘어 읽힐 수 있지만, UDP는 보낸 데이터그램이 받는 쪽에서도 한 덩어리로 읽힌다.
UDP는 다시 받는 것보다 빠른 것이 중요한 곳에 쓴다. DNS 조회는 짧은 질문과 답 한 번이라 주로 UDP를 쓰고, 응답이 크거나, 네임 서버(name server)끼리 DNS 정보 전체를 복사할 때는 TCP를 쓴다. 실시간 음성·영상 통화와 온라인 게임은 늦게 온 데이터가 쓸모없으므로 다시 받지 않고 건너뛴다. 웹에서는 HTTP/1.1과 HTTP/2가 TCP 위에서, HTTP/3는 UDP 위에 QUIC(UDP 위에서 연결 관리·재전송·암호화를 직접 하는 전송 프로토콜)을 얹어 동작한다.
연결 수립: 3-way 핸드셰이크
TCP가 데이터를 보내기 전에 메시지 세 번으로 연결을 맺는 절차를 3-way 핸드셰이크(three-way handshake)라고 한다. 각 메시지는 TCP의 전송 단위인 세그먼트(segment)이고, 헤더의 1비트 표시인 플래그(flag) 중 어느 것이 켜졌는지로 종류를 나타낸다.
다이어그램 로딩…
- 클라이언트가 SYN(Synchronize, 연결 요청) 플래그를 켜고, 자기 초기 순서 번호(initial sequence number) x를 담아 보낸다.
- 서버는 ACK(Acknowledgement, 확인 응답) 번호 x+1로 "다음엔 x+1을 기다린다"를 알리고(SYN이 순서 번호 하나를 차지한다), 같은 세그먼트에 SYN과 자기 초기 순서 번호 y를 싣는다.
- 클라이언트가 y+1로 ACK를 보내면 양쪽 모두 연결 수립(ESTABLISHED) 상태가 된다.
세 번이 필요한 이유는 양쪽이 각자 초기 순서 번호를 알리고 상대에게 확인받아야 하기 때문이다. 원래 필요한 SYN 두 번과 ACK 두 번 중 서버의 ACK와 SYN을 한 세그먼트에 합쳐 세 번이 되며, 두 번으로 끝내면 서버는 자기 순서 번호가 클라이언트에 닿았는지 모른다. 또 RFC(Request for Comments, 인터넷 표준 문서) 9293은 늦게 도착한 옛 SYN으로 엉뚱한 연결이 열리는 것을 막는 것을 주된 이유로 든다. 세 번째 단계에서 클라이언트가 옛 SYN에 대한 응답을 받으면 연결을 끊는 RST(Reset, 연결 재설정) 세그먼트로 거절할 수 있어서다.
이어지는 내용은 TCP와 UDP 2에서 다룬다.
면접 포인트
- "TCP와 UDP의 차이는?" → 연결형·신뢰성·순서·흐름/혼잡 제어 vs 비연결·보장 없음·가벼움. 헤더 최소 20바이트 vs 8바이트.
- "서버는 포트 하나로 어떻게 여러 연결을 받나요?" → 연결은 출발지 IP·출발지 포트·목적지 IP·목적지 포트 조합으로 구분된다. 클라이언트 쪽이 하나라도 다르면 다른 연결.
- "3-way 핸드셰이크를 설명하고, 왜 세 번인가요?" → SYN → SYN+ACK → ACK. 양쪽 초기 순서 번호를 서로 알리고 확인받기 위해. 옛 SYN으로 엉뚱한 연결이 열리는 것도 막는다.
- "HTTP/3는 TCP인가요?" → 아니다. UDP 위의 QUIC이다.