Daily Dev Q&A: TCP vs UDP

Topic (오늘의 주제)

TCP (신뢰성) vs UDP (속도)

Why (왜 사용하는가? 왜 중요한가?)

• 실무: 서비스의 성격에 따라 데이터의 정확성이 중요한지(금융, 메일), 실시간성이 중요한지(스트리밍, 게임)를 판단하여 적절한 프로토콜을 선택해야 합니다.
• 구조적 의미: OSI 7계층 중 **전송 계층(Transport Layer)**에서 데이터를 목적지까지 어떻게 보낼 것인가(꼼꼼하게 vs 빠르게)에 대한 두 가지 핵심 전략입니다.
• 면접 의도: 두 프로토콜의 명확한 **장단점(Trade-off)**을 이해하고 있는지, 그리고 최근 웹 기술(HTTP/3)이 왜 UDP를 기반으로 발전하고 있는지 설명할 수 있는지 확인합니다.

Core Concept (핵심 개념 정리)

비교 항목	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
연결 방식	연결 지향형 (Connection-oriented) (3-way handshake로 연결 후 통신)	비연결형 (Connectionless) (연결 없이 그냥 던짐)
신뢰성	높음 (데이터 순서 보장, 유실 시 재전송)	낮음 (데이터 유실 가능, 순서 뒤바뀔 수 있음)
전송 속도	느림 (흐름 제어, 혼잡 제어, 패킷 확인 과정 때문)	빠름 (확인 절차 없이 연속 전송)
전송 단위	Segment (세그먼트)	Datagram (데이터그램)
헤더 크기	큼 (가변적, 최소 20 Bytes) - 무거움	작음 (고정 8 Bytes) - 가벼움
사용 예시	웹(HTTP), 이메일, 파일 전송 (데이터 깨지면 안 됨)	실시간 스트리밍, 온라인 게임, DNS, VoIP

Interview Answer Version (면접 답변식 요약)

"TCP와 UDP는 전송 계층의 프로토콜로, 가장 큰 차이는 신뢰성과 속도의 트레이드오프입니다.

TCP는 3-way handshake로 연결을 맺고 데이터의 순서와 유실을 관리하여 신뢰성을 보장하지만, 확인 과정 때문에 속도가 상대적으로 느립니다. 주로 웹이나 파일 전송에 쓰입니다.

반면 UDP는 연결 과정 없이 데이터를 던지는 방식으로, 신뢰성은 낮지만 오버헤드가 적어 속도가 매우 빠릅니다. 따라서 데이터가 일부 유실되어도 괜찮은 실시간 스트리밍이나 온라인 게임에 주로 사용됩니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. HTTP/3와 UDP (QUIC)

• 전통적으로 웹(HTTP/1.1, HTTP/2)은 TCP를 썼습니다. 하지만 TCP의 무거운 구조와 Head-of-Line Blocking(앞 패킷이 막히면 뒤도 다 막힘) 문제를 해결하기 위해, 구글이 주도한 **HTTP/3(QUIC)**는 UDP를 기반으로 만들어졌습니다.
• 핵심: "UDP는 신뢰성이 없다"는 말은 반만 맞습니다. UDP 자체는 신뢰성이 없지만, 애플리케이션 계층(QUIC)에서 신뢰성 로직을 직접 구현하여 속도와 신뢰성을 모두 잡으려 노력 중입니다.

2. DNS는 왜 UDP를 쓸까?

• DNS 조회는 요청 내용이 작고(도메인 주소), 빨리 답을 받아야 하므로 **UDP(53번 포트)**를 기본으로 씁니다.
• 하지만 응답 데이터가 512바이트를 넘어가거나(Zone Transfer 등), 신뢰성이 중요할 때는 TCP를 사용하기도 합니다.

3. 게임 개발 시의 선택

• MMORPG의 채팅, 아이템 거래: TCP (아이템 사라지면 안 됨).
• FPS 게임의 캐릭터 이동, 총알 발사: UDP (패킷 하나 늦게 도착하느니 버리는 게 나음. 반응속도가 생명).

예상 꼬리질문 정리

1. Q: TCP의 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)의 차이는?
   • 핵심 키워드: 흐름 제어는 '수신자'가 처리할 수 있는 속도에 맞추는 것(Sliding Window), 혼잡 제어는 '네트워크' 망 자체의 혼잡도를 고려해 속도를 조절하는 것(Slow Start).
2. Q: UDP에서 신뢰성을 보장하려면 어떻게 해야 하나요?
   • 핵심 키워드: 전송 계층(UDP)에서는 불가능하므로, **애플리케이션 계층(코드 레벨)**에서 패킷 순서 번호를 매기고 재전송 요청 로직(ARQ)을 직접 구현해야 합니다. (QUIC이 이 방식)
3. Q: TCP의 Head-of-Line Blocking 문제가 무엇인가요?
   • 핵심 키워드: 패킷이 순서대로 도착해야 하므로, 앞의 패킷 하나가 유실되면 뒤의 정상 패킷들도 처리가 지연되는 현상입니다. HTTP/3가 UDP를 선택한 주된 이유입니다.