26.01.19 TCP와 UDP의 차이점을 설명해보기

TCP ( Transmission Control Protocol )

TCP는 연결 지향형 프로토콜이다. 데이터를 보내기 전에 송신 측과 수신 측이 서로 연결을 확인하는 과정을 거치며, 데이터가 정확하게 전달되었는지 끝까지 책임지는 방식이다. 

상대방과 전화를 연결하여 서로 목소리를 확인하며 대화하는 것과 같다고 생각하면 된다.

 

UDP (User Datagram Protocol)

UDP는 비연결 지향형 프로토콜이다. 연결 확인 과정 없이 데이터를 일방적으로 던지는 방식이며, 데이터의 수신 여부나 순서를 보장하지 않는다.

주소만 적어서 던지는 편지나 전단지 배포와 같다.

 

장단점

구분	TCP	UDP
장점	높은 신뢰성: 데이터 손실 시 재전송 요청. 순서 보장: 보낸 순서대로 데이터 도착. 흐름/혼잡 제어: 네트워크 상태에 따라 속도 조절.	빠른 속도: 연결 과정 및 확인 절차가 없음. 적은 오버헤드: 헤더가 가볍고 단순함. 실시간성: 지연 시간이 짧음.
단점	느린 속도: 연결 설정(Handshake) 및 확인 응답 필요. 높은 리소스: 데이터 체크를 위해 CPU/메모리 더 사용.	낮은 신뢰성: 데이터 유실 가능성 존재. 순서 미보장: 데이터가 뒤섞여 도착할 수 있음.

 

차이점 

항목	TCP	UDP
연결방법	3-way Handshake (연결 설정)	연결 과정 없음
데이터 경계	바이트 스트림 (경계 구분 없음)	데이터그램 (경계 구분 있음)
수신 확인	ACK 응답을 통해 확인	확인 안 함
전송 순서	보장됨 (Sequence Number 사용)	보장 안 됨
주요 사례	HTTP/HTTPS(웹), FTP(파일 전송), 이메일	스트리밍(YouTube), 온라인 게임, VoIP(화상전화)

 

연결 방법 ( 3-way Handshake(TCP) vs Connectionless(UDP) )

통신을 시작하기 전, 상대방과 "준비됐니?"라고 묻는 절차의 유무 차이

• TCP (3-way Handshake): 데이터를 보내기 전, 세 단계를 거쳐 논리적인 연결 통로를 만든다.
  1. SYN: 클라이언트가 서버에 "연결하고 싶어"라고 요청(번호 부여)을 보낸다.
  2. SYN+ACK: 서버가 요청을 받고 "그래, 나도 준비됐어"라고 응답하며 자신의 번호를 보낸다.
  3. ACK: 클라이언트가 "확인했어, 이제 보낼게"라고 최종 응답을 보낸다.
  목적: 양측의 송수신 준비 상태를 확인하고, 데이터 순서를 맞추기 위한 시작 번호를 동기화한다.
• UDP (Connectionless): 연결 설정 과정이 아예 없다. 서버가 떠 있는지, 받을 준비가 됐는지 확인하지 않고 바로 데이터를 송신한다.
  • 결과: 연결 설정에 드는 지연 시간(Latency)이 없어 매우 빠릅니다.

 

데이터 경계 ( Byte Stream vs Datagram )

데이터를 '어떤 단위'로 취급하느냐의 차이

 

• TCP (Byte Stream): 데이터를 끊기지 않는 연속적인 흐름(물줄기)으로 본다.
  • 발신자가 100바이트를 한 번에 보내도, 수신자는 50바이트씩 두 번에 나눠 읽을 수 있다.
  • 데이터 간의 경계가 없으므로, 애플리케이션 계층에서 데이터를 어디까지 읽을지 직접 구분(Delimiting)해야 한다.
• UDP (Datagram): 데이터를 독립적인 패킷(편지봉투) 단위로 취급한다.
  • 발신자가 100바이트 패킷 하나를 보내면, 수신자도 반드시 100바이트 패킷 하나로 받아야 한다.
  • 보낸 단위 그대로 받기 때문에 데이터의 경계가 명확히 보존된다.

 

수신 확인 ( ACK vs No Acknowledgement )

상대방이 데이터를 잘 받았는지 확인하는 '피드백' 절차

• TCP (ACK 응답): 수신측은 패킷을 받을 때마다 "N번 패킷 잘 받았어"라는 ACK(Acknowledgement) 신호를 보낸다.
  • 만약 일정 시간 동안 ACK가 오지 않으면, 송신 측은 데이터가 유실된 것으로 간주하고 재전송(Retransmission)한다.
  • 이 과정 덕분에 데이터의 무결성(Integrity)이 보장된다.(데이터가 전송 도중 탈취당할 경우 또는 인잭션으로 다른 데이터가 삽입되었을 경우 등을 방지)

• UDP (확인 안 함): 일단 보내면 끝이다. 상대방이 받았는지, 중간에 사라졌는지 관심을 두지 않는다.
  • 피드백을 기다리지 않으므로 네트워크 부하가 적고 전송 속도가 빠르다.

 

전송 순서 (Sequence Number vs Unordered)

여러 개의 패킷을 보냈을 때 도착 순서를 바로잡는 능력

 

• TCP (Sequence Number): 각 패킷에 순서 번호(Sequence Number)를 부여한다.
  • 네트워크 경로에 따라 1번보다 2번 패킷이 먼저 도착할 수도 있다.
    TCP는 수신 측에서 번호를 보고 원래 순서대로 재조립하여 사용자에게 전달한다.
• UDP (보장 안 됨): 번호 개념이 없거나 순서를 제어하지 않는다.
  • 먼저 보낸 패킷이 나중에 도착하더라도 도착한 순서 그대로 애플리케이션에 넘겨준다.
    순서가 중요한 데이터라면 UDP 사용 시 개발자가 직접 정렬 로직을 짜야한다.

 

면접 답변식 요약

TCP는 '신뢰할 수 있는 연결'을 위해 3-way Handshake로 통로를 열고, 번호를 매겨 순서를 맞추며, ACK 응답이 없으면 다시 보내는 철저한 관리자형 프로토콜입니다.

반면, UDP는 '빠른 전송'을 최우선으로 하여 연결 절차 없이 데이터를 패킷 단위로 던집니다. 확인 절차가 없어 일부 데이터가 유실될 수 있지만, 실시간성이 중요한 환경에서 최고의 성능을 발휘합니다.

 

번외 1) OSI 7 계층과 역할

TCP와 UDP는 OSI 7 계층 중 4계층인 '전송 계층(Transport Layer)'에 속한다.

• 전송 계층의 역할: 송신 프로세스와 수신 프로세스 간의 종단 간(End-to-End) 통신을 관리한다.
  • 하위 계층(IP 등)이 데이터를 목적지 컴퓨터까지 배달한다면, 전송 계층은 그 데이터를 어떤 프로그램(Port)에게 전달할지 결정하고 통신의 신뢰성을 관리한다.

 

번외 2) 각 패킷 구조

TCP 패킷 구조

• Source / Destination Port (16-bit): 데이터를 보내는 프로그램과 받는 프로그램의 통로 번호(포트)이다. (예: 웹은 80 또는 443)
• Sequence Number (32-bit): 전송되는 데이터 패킷의 순서 번호이다. 수신 측에서는 이 번호를 보고 흩어진 패킷을 순서대로 재조립한다.
• Acknowledgement Number (32-bit): 수신 측이 "몇 번 번호까지 잘 받았다"라고 응답할 때 사용하는 확인 번호이다. TCP 신뢰성의 핵심이다.
• Header Length (4-bit): TCP 헤더의 전체 길이를 나타낸다.
• Flags (8-bit): 현재 패킷의 성격을 나타내는 표시 등이 있다.
  • SYN: 연결 요청
  • ACK: 수신 확인 응답
  • FIN: 연결 종료 요청 등이 여기에 포함
• Window (16-bit): 한 번에 받을 수 있는 데이터의 양(버퍼 크기)을 알려주어 흐름 제어(Flow Control)를 수행한다.
• Checksum: 전송 중에 데이터가 깨지거나 변형되지 않았는지 확인하는 검사용 코드이다.
• Urgent Pointer: 긴급하게 처리해야 할 데이터의 위치를 가리킨다.

UDP 패킷 구조

• Source / Destination Port (16-bit): 데이터를 보내는 프로그램과 받는 프로그램의 통로 번호(포트)이다. (예: 웹은 80 또는 443)
• Length(16-bit):  UDP 헤더와 데이터를 합친 전체 길이를 나타낸다.
• Checksum: 전송 중 데이터가 손상되지 않았는지 확인하는 최소한의 검사 도구입니다. (선택 사항이며, 검사하는 도구일 뿐 복구하는 기능은 없다.)
  • 주의할 점: IPv4 환경에서 UDP의 Checksum은 선택 사항(Optional)이다. 즉, 실시간성과 성능을 극대화하려면, Checksum을 모두 0으로 채워 검사 과정을 아예 생략하면 된다. (Checksum은 CPU 자원을 사용하기 때문) 하지만,  IPv6에서는 UDP Checksum이 필수이다. -> 가장 큰 이유는 IPv6 헤더에서 '헤더 체크섬(Header Checksum)' 필드가 삭제되었기 때문.