TCP vs. UDP: 신뢰성 vs. 속도

브라우저가 이 페이지를 불러올 때, 눈에 보이지 않는 일이 벌어집니다. 두 컴퓨터가 대화를 시작하기로 합의합니다. 서로 악수를 나눕니다. 모든 문장의 수신을 확인합니다. 서로를 기다립니다.

화상 통화 중에는 다른 일이 벌어집니다. 한 컴퓨터가 그냥 말을 시작합니다. 악수 없이. 확인 없이. 말이 사라지면, 그냥 사라집니다.

이것이 바로 TCP와 UDP입니다. 인터넷 트래픽의 거의 전부를 담당하는 두 프로토콜이죠. 이 둘은 경쟁자가 아닙니다. 서로 다른 질문에 대한 답입니다.

신뢰에 관한 두 가지 철학

TCP(전송 제어 프로토콜)는 묻습니다: "받았어?"

UDP(사용자 데이터그램 프로토콜)는 말합니다: "받았으면 좋겠는데."

이것이 근본적인 차이입니다. TCP는 연결을 맺고, 모든 패킷을 추적하며, 확인 응답을 요구하고, 유실된 것은 무엇이든 재전송합니다. UDP는 그냥 데이터를 보내고 넘어갑니다.

이렇게 생각해보세요. TCP는 전화 통화입니다. 연결을 맺고, 상대방이 듣고 있다는 걸 알며, 상대방이 뭔가를 놓치면 다시 말해달라고 요청합니다. UDP는 북적이는 방에서 소리치는 것입니다. 할 말을 하고, 전달되길 바랍니다. 전달되지 않아도, 이미 다음으로 넘어가 있습니다.

TCP가 전달을 보장하는 방법

TCP가 데이터를 단 1바이트라도 전송하기 전에, 3방향 핸드셰이크라는 절차를 수행합니다.

1. SYN: "당신과 얘기하고 싶습니다."
2. SYN-ACK: "들립니다. 저도 얘기하고 싶네요."
3. ACK: "좋습니다. 시작하죠."

이 교환이 끝난 후에야 데이터가 흐르기 시작합니다. 그리고 일단 시작되면, TCP는 모든 것을 집요하게 추적합니다.

모든 데이터 덩어리에 순서 번호가 부여됩니다. 수신자는 확인 응답을 돌려보냅니다. "11000바이트 받았습니다. 10012000바이트 받았습니다." 확인 응답이 타임아웃 내에 도착하지 않으면, TCP는 데이터가 유실됐다고 판단하고 다시 전송합니다.

이로 인해 거의 마법 같은 보장이 생깁니다.

• 신뢰성: 유실된 패킷은 자동으로 재전송됩니다
• 순서 보장: 패킷이 뒤섞여 도착하더라도 TCP가 올바르게 재조립합니다
• 흐름 제어: 빠른 송신자가 느린 수신자를 압도하지 않습니다
• 혼잡 제어: TCP는 네트워크 혼잡을 감지하고 속도를 줄입니다

그 대가는? 오버헤드. 지연. 모든 확인 응답은 왕복입니다. 패킷이 유실될 때마다 기다리고 재시도해야 합니다. 3방향 핸드셰이크만으로도 데이터가 움직이기 전에 지연이 발생합니다.

UDP가 속도를 달성하는 방법

UDP에는 기능이 거의 없습니다. 그게 핵심입니다.

연결 설정 없음. 확인 응답 없음. 재전송 없음. 순서 보장 없음. 흐름 제어 없음. UDP를 사용하는 애플리케이션은 즉시 데이터 전송을 시작할 수 있습니다.

UDP 헤더는 8바이트입니다. TCP는 최소 20바이트입니다. UDP에는 정확히 네 가지 필드만 있습니다. 출발지 포트, 목적지 포트, 길이, 그리고 체크섬. 그게 전부입니다.

각 UDP 데이터그램은 독립적입니다. 쏘고 잊어버리기입니다. 송신자는 데이터가 도착했는지 알 수 없습니다. 수신자에게는 누락된 데이터를 요청할 메커니즘이 없습니다. 패킷이 순서 없이 도착하면, 그건 애플리케이션이 해결할 문제입니다.

이 단순함은 곧바로 성능으로 이어집니다.

• 전송 전 핸드셰이크 지연 없음
• 확인 응답을 기다리는 왕복 대기 없음
• 패킷이 사라져도 재전송 지연 없음
• 유지해야 할 연결 상태 없음

UDP는 네트워크가 허용하는 만큼 빠릅니다.

TCP가 필요한 경우

데이터가 온전하고 순서대로 도착해야 할 때, 즉 유실이나 손상이 무언가를 망가뜨릴 때 TCP를 선택하세요.

웹 페이지: HTML 파일에서 1바이트가 누락되면 페이지 전체 구조가 망가질 수 있습니다. 스타일을 적용할 HTML보다 먼저 도착한 CSS 규칙은 쓸모가 없습니다.

이메일: 패킷이 유실되면 문장이 중간에 사라집니다. 아니면 단락 전체가. 아니면 첨부 파일이. TCP는 이메일 클라이언트가 메시지를 보여주기 전에 전체 메시지가 도착하도록 보장합니다.

파일 다운로드: 소프트웨어를 다운로드할 때는 모든 바이트가 필요합니다. 손상된 실행 파일은 실행되지 않습니다.

금융 거래: 뱅킹 앱이 돈을 이체할 때는 요청이 도착했고 확인이 돌아왔다는 절대적인 확신이 필요합니다.

API 요청: 애플리케이션은 명확하게 알아야 합니다. 요청이 성공했는가, 실패했는가?

TCP가 이 모든 것을 자동으로 처리합니다. 애플리케이션은 그냥 데이터를 보내고 도착을 신뢰하면 됩니다.

UDP가 필요한 경우

완벽함보다 속도가 중요할 때, 즉 오래된 데이터가 누락된 데이터보다 나쁠 때 UDP를 선택하세요.

온라인 게임: 플레이어 위치를 담은 패킷이 유실되더라도, 수 밀리초 후에 도착하는 다음 패킷에 어차피 새 위치가 담겨 있습니다. 오래된 좌표를 재전송하기 위해 게임을 멈추면 플레이할 수 없게 됩니다. 플레이어는 가끔 발생하는 끊김은 참을 수 있지만, 입력 지연은 참을 수 없습니다.

화상 통화: 비디오 프레임이 하나 유실되면 순간적인 화면 깨짐이 발생합니다. 하지만 재전송은 의미가 없습니다. 도착할 때쯤이면 대화는 이미 200밀리초 앞으로 나아가 있습니다. 나쁜 프레임을 건너뛰고 대화를 계속하는 편이 낫습니다.

라이브 스트리밍: 같은 원칙입니다. 오래된 콘텐츠의 완벽한 재생보다 현재 콘텐츠의 부드러운 재생이 낫습니다.

DNS 조회: 컴퓨터가 "google.com"을 조회할 때, 쿼리와 응답은 각각 단일 패킷에 들어갑니다. UDP의 속도는 더 빠른 조회를 의미합니다. 패킷이 유실되면 그냥 재시도하면 됩니다. 그래도 TCP 핸드셰이크보다 빠릅니다.

실시간 센서: 온도 측정값이 유실되더라도, 어차피 몇 초 후의 다음 측정값이 더 최신입니다. 오래된 센서 데이터의 보장된 전달은 쓸모없는 정보의 보장된 전달입니다.

패턴: 가장 최신 데이터만이 의미 있는 데이터일 때 UDP가 이깁니다.

혼합된 현실

실제 시스템은 종종 둘 다 사용합니다.

동영상 스트리밍 서비스는 제어 메시지("일시 정지", "건너뛰기", "화질 변경")에는 TCP를 사용합니다. 해당 명령들은 반드시 도착해야 하기 때문입니다. 하지만 실제 비디오 프레임에는 UDP를 사용합니다. 여기서는 부드러운 재생이 완벽한 프레임보다 중요합니다.

현대 프로토콜들은 때로 UDP 위에 맞춤형 신뢰성을 구축합니다. 현대 웹의 많은 부분을 담당하는 프로토콜인 QUIC은 UDP를 기반으로 사용하지만, 선택적 신뢰성과 정교한 혼잡 제어를 추가합니다. TCP의 고정된 동작으로는 불가능한 방식으로 웹 트래픽 패턴에 최적화할 수 있습니다.

이는 중요한 사실을 드러냅니다. TCP vs. UDP는 단순한 양자택일이 아닙니다. 때로는 "UDP, 더하기 실제로 필요한 신뢰성 기능만"이 답입니다.

열악한 환경에서의 성능

완벽한 네트워크, 즉 낮은 지연과 패킷 손실이 없는 환경에서는 TCP와 UDP의 성능이 비슷합니다. 오버헤드 차이는 무시할 수 있을 정도입니다.

하지만 네트워크는 완벽하지 않습니다. 지연이 증가할수록 TCP의 확인 응답 왕복이 쌓입니다. 왕복 시간이 600ms인 위성 링크에서는 패킷이 유실될 때마다 600ms의 지연이 추가되는 재전송이 발생합니다. TCP의 혼잡 제어는 처리량을 극적으로 제한할 수 있습니다. 전달을 보장하는 프로토콜이 지연도 보장하기 시작합니다.

UDP는 네트워크 상태에 관계없이 일관된 성능을 유지합니다. 기다리지 않습니다. 물러서지 않습니다. 그냥 계속 보냅니다.

반대 측면: UDP를 사용하는 애플리케이션은 패킷 손실을 직접 처리해야 합니다. 그것은 TCP가 흡수했을 복잡성입니다. 그 트레이드오프가 타당한지는 전적으로 무엇을 만드느냐에 달려 있습니다.

핵심 트레이드오프

TCP는 속도를 확실성과 맞바꿉니다. UDP는 확실성을 속도와 맞바꿉니다.

TCP는 데이터가 온전하고 순서대로 도착함을 보장합니다. 그 대가는 프로토콜의 오버헤드, 지연, 복잡성입니다. 그 이점은 애플리케이션의 단순성입니다. 그냥 데이터를 보내고 프로토콜을 신뢰하면 됩니다.

UDP는 거의 아무것도 보장하지 않습니다. 그 대가는 애플리케이션의 복잡성입니다. 손실을 우아하게 처리해야 합니다. 그 이점은 순수한 속도와 필요한 만큼만 신뢰성을 구현할 수 있는 자유입니다.

어느 쪽이 더 낫다고 할 수 없습니다. 둘은 서로 다른 질문에 대한 답입니다.

파일을 다운로드할 때 질문은 이렇습니다. "모든 바이트가 도착했는가?" TCP가 그 답을 줍니다.

화상 통화 중일 때 질문은 이렇습니다. "지금 무슨 일이 일어나고 있는가?" UDP가 그 답을 줍니다.

애플리케이션이 실제로 어떤 질문을 하고 있는지 아는 것, 그것이 모든 결정의 핵심입니다.

TCP와 UDP에 관한 자주 묻는 질문

게임이나 화상 통화에 TCP를 사용할 수 있나요?

사용할 수 있지만, 경험이 나빠지는 경우가 많습니다. TCP의 재전송 지연은 실시간 상호작용을 느리게 만드는 지연을 추가합니다. 화상 통화에서 패킷이 유실되면 TCP는 충실하게 재전송하겠지만, 도착할 때쯤이면 이미 대화가 진행되고 있습니다. 과거의 프레임을 표시했다가 다시 앞으로 건너뛰게 됩니다. UDP는 최신 상태를 유지하는 대가로 가끔 발생하는 끊김을 받아들입니다.

왜 UDP에는 신뢰성 옵션이 없나요?

그렇게 되면 목적이 사라집니다. UDP의 가치는 단순함과 최소한의 오버헤드입니다. 신뢰성이 필요하다면 UDP 위에 필요한 신뢰성을 정확히 구축할 수 있습니다. QUIC 같은 프로토콜이 하는 일이 바로 그것입니다. 모두에게 맞는 신뢰성을 제공하는 것이 TCP입니다. UDP는 맞춤형으로 구축할 수 있는 기반을 제공합니다.

UDP 패킷이 순서 없이 도착하면 어떻게 되나요?

그건 애플리케이션이 해결해야 할 문제입니다. UDP는 순서 번호를 추적하거나 재정렬하지 않습니다. 애플리케이션에 순서가 필요하다면, 직접 순서 번호를 추가하고 코드에서 재정렬을 처리해야 합니다. 많은 실시간 애플리케이션은 도착하는 순서대로 패킷을 처리합니다. 패킷 5가 패킷 4보다 먼저 도착하면, 어차피 더 최신 데이터이므로 패킷 5의 데이터를 사용합니다.

한 프로토콜이 다른 것보다 더 안전한가요?

TCP도 UDP도 자체적으로는 암호화나 인증을 제공하지 않습니다. 보안은 TLS와 같이 그 위에 구축된 계층에서 옵니다. 다만 TCP의 연결 지향적 특성은 3방향 핸드셰이크가 양방향 통신을 요구하기 때문에 IP 스푸핑 같은 일부 공격을 약간 더 어렵게 만듭니다. UDP의 비연결적 특성은 공격자가 출발지 주소를 위조하는 특정 반사 공격에 더 취약합니다.