인터넷에서 데이터가 전달될 때 IP 주소만으로 통신이 완성되는 것은 아니다.
IP는 데이터를 어느 장비까지 전달할지를 담당하지만, 실제 애플리케이션 사이에서 데이터를 어떤 방식으로 주고받을 것인지는 전송 계층 프로토콜이 담당한다.
대표적인 전송 계층 프로토콜이 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)다.
TCP는 연결을 설정하고 데이터가 순서대로 전달되도록 관리하며 손실된 데이터를 다시 전송하는 기능을 제공한다.
UDP는 이러한 기능을 최소화하고 애플리케이션이 데이터를 빠르고 단순하게 전달할 수 있도록 한다.
TCP → 연결과 신뢰성을 관리하는 전송 방식
UDP → 최소한의 기능으로 데이터그램을 전달하는 전송 방식
하지만 이를 단순히 “TCP는 느리고 UDP는 빠르다”라고 이해하면 실제 네트워크 구조를 정확하게 설명하기 어렵다.
TCP와 UDP는 전송 계층에서 동작한다
애플리케이션 → TCP 또는 UDP → IP → 네트워크 인터페이스 → 실제 네트워크
TCP와 UDP는 포트 번호를 사용해 하나의 컴퓨터 안에서도 어느 애플리케이션으로 데이터를 전달해야 하는지 구분한다.
TCP는 통신 전에 연결을 설정한다
TCP는 연결 지향형(Connection-oriented) 프로토콜이다.
데이터를 본격적으로 전송하기 전에 송신자와 수신자가 통신 가능한 상태인지 확인하고 연결을 설정한다.
Client → SYN → Server
Client ← SYN-ACK ← Server
Client → ACK → Server
이 과정을 일반적으로 3-Way Handshake라고 한다.
TCP는 데이터가 순서대로 전달되도록 관리한다
네트워크에서 데이터는 항상 보낸 순서대로 도착하는 것은 아니다.
TCP는 Sequence Number를 이용해 데이터의 순서를 확인하고 올바른 흐름으로 재구성할 수 있다.
전송: 1 → 2 → 3 → 4
도착: 1 → 3 → 2 → 4
TCP는 순서 정보를 바탕으로 이를 다시 정상적인 데이터 흐름으로 구성한다.
TCP는 손실된 데이터를 재전송한다
TCP는 ACK와 순서 정보를 이용해 데이터가 정상적으로 전달되었는지 확인한다.
필요한 데이터가 전달되지 않았다고 판단하면 다시 전송할 수 있으며 이를 Retransmission이라고 한다.
이 때문에 파일이나 웹 문서처럼 일부 데이터가 빠져서는 안 되는 통신에 TCP가 적합하다.
TCP는 바이트 스트림 형태로 데이터를 전달한다
TCP는 애플리케이션에 데이터를 연속된 바이트 스트림(Byte Stream) 형태로 제공한다.
애플리케이션이 여러 번 데이터를 전송했더라도 수신 측이 정확히 같은 단위로 읽는다는 보장은 없다.
TCP가 보장하는 것은 개별 메시지의 경계가 아니라 신뢰할 수 있는 순서 있는 바이트 흐름이다.
TCP에는 흐름 제어 기능이 있다
송신자가 데이터를 빠르게 보내는데 수신자가 이를 처리하지 못하면 문제가 발생할 수 있다.
TCP는 수신 측의 처리 능력을 고려해 전송량을 조절하는 흐름 제어(Flow Control)를 제공한다.
TCP는 네트워크 혼잡도 고려한다
TCP에는 네트워크 자체의 혼잡 상태를 고려하는 혼잡 제어(Congestion Control) 메커니즘도 사용된다.
TCP가 제공하는 신뢰성은 연결 관리, 순서 제어, 재전송, 흐름 제어와 혼잡 제어 등이 함께 동작한 결과다.
UDP는 연결 설정 없이 데이터그램을 전송한다
UDP는 TCP와 달리 통신 전에 연결 설정 과정을 수행하지 않는다.
송신자 → UDP Datagram → 수신자
RFC 768은 UDP를 최소한의 프로토콜 메커니즘으로 메시지를 전달하기 위한 데이터그램 방식으로 정의한다.
UDP 헤더에는 기본적으로 Source Port, Destination Port, Length, Checksum이 포함되며 기본 크기는 8바이트다.
UDP 자체는 데이터 전달을 보장하지 않는다
UDP 데이터그램은 네트워크에서 손실되거나 중복될 수 있으며 전송 순서와 다른 순서로 도착할 수도 있다.
UDP 자체에서는 TCP와 같은 연결 설정, ACK 기반 전달 확인, 재전송, 순서 재정렬과 같은 기능을 기본적으로 제공하지 않는다.
따라서 이러한 기능이 필요한 경우 애플리케이션이나 상위 프로토콜에서 구현해야 한다.
UDP는 메시지 경계를 유지한다
TCP가 바이트 스트림을 제공하는 것과 달리 UDP는 데이터그램 단위의 메시지 구조를 유지한다.
애플리케이션이 하나의 UDP 데이터그램을 전송하면 수신 측에서도 하나의 데이터그램 단위로 처리한다.
UDP를 사용한다고 항상 더 빠른 것은 아니다
UDP는 구조가 단순해 기본적인 프로토콜 오버헤드가 작지만 모든 환경에서 TCP보다 빠르다고 단정할 수는 없다.
UDP 위에서 신뢰성, 순서 제어, 재전송, 혼잡 제어 등을 직접 구현한다면 별도의 처리가 필요하다.
프로토콜 선택은 단순한 속도 경쟁보다 애플리케이션이 어떤 전달 특성을 필요로 하는가를 기준으로 판단해야 한다.
실시간 통신에서는 늦은 데이터가 의미 없을 수 있다
음성이나 실시간 영상에서는 일부 데이터가 손실되는 것보다 지나치게 늦게 도착하는 것이 더 문제가 될 수 있다.
이러한 환경에서는 손실된 모든 데이터를 반드시 다시 받는 것보다 일정한 시간 안에 데이터를 계속 전달하는 것이 중요할 수 있다.
이 때문에 실시간 미디어 전송 프로토콜에서 UDP를 기반으로 사용하는 경우가 많다.
DNS에서도 UDP와 TCP를 모두 사용할 수 있다
일반적인 DNS 질의와 응답에서는 UDP가 사용될 수 있지만 DNS가 항상 UDP만 사용하는 것은 아니다.
상황과 DNS 프로토콜 동작에 따라 TCP도 사용될 수 있다.
따라서 특정 애플리케이션 프로토콜을 단순히 TCP 또는 UDP 하나로만 암기하기보다 실제 사용 구조를 확인하는 것이 좋다.
웹 통신도 이제 TCP만 사용하는 것은 아니다
HTTP/1.1과 HTTP/2는 TCP를 기반으로 동작하지만 HTTP/3에서는 QUIC을 사용한다.
QUIC은 UDP 위에서 동작한다.
하지만 QUIC은 UDP의 신뢰성 없는 특성을 그대로 사용하는 것이 아니라 연결 관리, 손실 탐지, 흐름 제어, 보안 통신 등의 기능을 상위 프로토콜에서 구현한다.
UDP를 사용한다고 반드시 신뢰성이 없는 애플리케이션이 되는 것은 아니다.
TCP와 UDP의 차이는 표로 비교하면 명확하다
| 구분 | TCP | UDP |
|---|---|---|
| 통신 방식 | 연결 지향 | 데이터그램 방식 |
| 연결 설정 | 필요 | 기본적으로 불필요 |
| 전달 확인 | 지원 | 기본적으로 지원하지 않음 |
| 재전송 | 지원 | 기본적으로 지원하지 않음 |
| 순서 보장 | 지원 | 기본적으로 보장하지 않음 |
| 데이터 형태 | 바이트 스트림 | 데이터그램 |
| 흐름 제어 | 지원 | 기본 제공하지 않음 |
| 혼잡 제어 | TCP 메커니즘 사용 | 상위 계층에서 고려 필요 |
| 기본 헤더 크기 | 최소 20바이트 | 8바이트 |
| 대표적인 활용 | 웹·파일·원격접속 등 | 실시간 미디어·일부 DNS·QUIC 기반 통신 등 |
포트 번호는 TCP와 UDP에서 각각 관리된다
TCP와 UDP는 모두 포트 번호를 사용하지만 서로 별개의 전송 계층 공간에서 사용된다.
방화벽 정책에서도 포트 번호만이 아니라 TCP인지 UDP인지 함께 확인해야 한다.
TCP 53
UDP 53
두 정책은 서로 다른 네트워크 통신을 의미한다.
방화벽에서는 TCP와 UDP의 상태 추적 방식에도 차이가 있다
TCP는 연결 설정과 종료 과정이 존재하기 때문에 Stateful Firewall이 연결 상태를 비교적 명확하게 추적할 수 있다.
UDP에는 TCP와 같은 연결 설정 과정이 없기 때문에 방화벽에서는 주소와 포트, 시간 정보를 이용해 논리적인 흐름을 관리할 수 있다.
UDP 애플리케이션도 혼잡 제어를 고려해야 한다
UDP에 TCP의 혼잡 제어가 내장되어 있지 않다고 해서 애플리케이션이 원하는 만큼 데이터를 전송해도 된다는 의미는 아니다.
IETF의 RFC 8085는 인터넷에서 UDP를 사용하는 애플리케이션과 프로토콜 역시 네트워크 혼잡 붕괴를 막고 다른 트래픽과 공정하게 자원을 사용하도록 적절한 혼잡 제어 메커니즘을 적용해야 한다고 권고한다.
TCP와 UDP 선택은 데이터 특성에서 시작한다
애플리케이션을 설계할 때는 다음과 같은 질문을 확인할 필요가 있다.
데이터가 일부 손실되어도 되는가.
순서가 반드시 보장되어야 하는가.
손실된 데이터를 다시 받아야 하는가.
실시간성이 중요한가.
애플리케이션에서 별도의 신뢰성 제어를 구현할 수 있는가.
연결 상태를 유지해야 하는가.
프로토콜 선택은 어느 것이 더 빠른가가 아니라 데이터와 서비스가 요구하는 통신 특성이 무엇인가에서 시작해야 한다.
TCP와 UDP는 서로 경쟁하는 프로토콜이 아니다
TCP는 애플리케이션이 복잡한 신뢰성 제어를 직접 구현하지 않아도 안정적인 바이트 스트림을 제공한다.
UDP는 최소한의 전송 기능을 제공해 애플리케이션이나 상위 프로토콜이 필요한 동작을 직접 설계할 수 있도록 한다.
TCP → 연결 설정 → 순서 관리 → 전달 확인 → 손실 시 재전송 → 흐름·혼잡 제어 → 신뢰성 있는 바이트 스트림
UDP → 별도의 연결 설정 없이 데이터그램 전달 → 메시지 경계 유지 → 필요한 신뢰성과 제어 기능은 상위 계층에서 구현 가능
결국 TCP와 UDP를 이해하는 핵심은 어느 것이 더 빠른지를 외우는 것이 아니다.
네트워크에서 애플리케이션이 요구하는 신뢰성, 지연시간, 데이터 순서와 제어 기능을 어떤 계층에서 구현할 것인지 이해하는 것이 중요하다.