TCP와 UDP의 차이

TCP는 데이터 전송을 시작하기 전에 논리적인 연결을 수립하는 연결 지향 프로토콜이다. 이 과정을 3방향 핸드셰이크라고 부른다. 먼저 송신 측이 SYN 플래그가 설정된 패킷을 보내 연결을 요청하면, 수신 측은 SYN과 ACK 플래그가 모두 설정된 패킷으로 응답한다. 마지막으로 송신 측이 ACK 패킷을 보내면 연결이 성립된다. 이렇게 세 단계를 거쳐 양단 간에 안정적인 통신 경로가 설정된 후에야 실제 데이터 전송이 이루어진다.

연결이 수립되면, TCP는 이 연결을 통해 데이터를 순서대로 전송하고, 전송이 완료되면 연결을 종료한다. 연결 종료 역시 FIN과 ACK 패킷을 교환하는 4단계의 과정을 거친다. 이 연결 지향적인 특성은 통신하는 두 호스트 사이에 가상의 전용 회선이 만들어진 것과 같은 상태를 제공하여, 데이터가 정해진 경로로 순차적으로 도달할 수 있는 기반을 마련한다.

TCP는 데이터 전송의 신뢰성을 보장하기 위해 여러 메커니즘을 사용한다. 가장 핵심적인 기능은 확인응답과 재전송이다. 송신 측은 데이터를 세그먼트 단위로 나누어 보내고, 수신 측이 이를 성공적으로 받으면 ACK 패킷을 보내 응답한다. 송신 측은 일정 시간 내에 ACK를 받지 못하면 해당 데이터를 다시 전송한다. 이 과정을 통해 패킷 손실이 발생하더라도 최종적으로 데이터가 올바르게 전달되도록 한다.

또한, TCP는 데이터의 순서를 보장한다. 네트워크를 통해 도착하는 패킷의 순서가 뒤섞일 수 있기 때문에, 각 세그먼트에는 시퀀스 번호가 부여된다. 수신 측은 이 번호를 기준으로 데이터를 올바른 순서로 재조립하여 상위 계층에 전달한다. 이를 통해 송신한 순서와 동일하게 데이터가 수신된다.

데이터의 무결성 검사도 신뢰성 보장의 중요한 요소이다. TCP 헤더에는 체크섬 필드가 포함되어 있어, 전송 중 데이터에 오류가 발생했는지 검사할 수 있다. 수신 측은 체크섬 계산을 통해 오류를 발견하면 해당 세그먼트를 폐기하며, 송신 측의 재전송을 유발한다. 이러한 확인응답, 순서 보장, 오류 검사의 조합을 통해 TCP는 종단 간 신뢰성 있는 바이트 스트림 전송 서비스를 제공한다.

TCP는 데이터 전송의 안정성과 효율성을 높이기 위해 흐름 제어와 혼잡 제어 메커니즘을 구현한다. 흐름 제어는 데이터를 보내는 송신자와 받는 수신자 간의 처리 속도 차이를 해결한다. 수신자는 자신의 버퍼 상태를 고려해 수신 가능한 데이터 양을 윈도우 크기로 알려주고, 송신자는 이 크기만큼만 데이터를 전송한다. 이를 통해 수신자의 버퍼 오버플로우를 방지하고 데이터 손실을 막는다.

혼잡 제어는 네트워크 자체의 혼잡을 피하는 데 목적이 있다. 네트워크에 너무 많은 데이터가 몰려 패킷 손실이 발생하면, TCP는 이를 네트워크 혼잡의 신호로 간주한다. 대표적인 알고리즘으로는 슬로우 스타트, 혼잡 회피, 빠른 재전송, 빠른 회복 등이 있다. 이들은 패킷 손실을 감지하면 전송 속도를 급격히 낮춘 후 점진적으로 회복하는 방식으로 동작한다.

두 메커니즘은 서로 다른 계층의 문제를 해결하지만 상호 보완적으로 작동한다. 흐름 제어는 종단 간의 문제를, 혼잡 제어는 네트워크 경로의 문제를 관리한다. TCP의 혼잡 제어 알고리즘은 지속적으로 발전해 왔으며, TCP Tahoe, TCP Reno, CUBIC TCP 등 다양한 변종이 존재한다[1].

UDP는 비연결형 프로토콜이다. 이는 데이터를 전송하기 전에 TCP와 같은 사전 연결 설정 과정을 거치지 않음을 의미한다. 송신 측은 수신 측의 상태나 준비 여부를 확인하지 않고, 즉시 데이터그램을 생성하여 네트워크로 전송한다. 따라서 3-way handshake와 같은 연결 설정 절차가 없어 통신 시작 지연이 발생하지 않는다.

이러한 특성으로 인해 각 데이터그램은 독립적인 단위로 취급된다. 패킷은 서로 다른 경로로 전송될 수 있으며, 송신 순서와 도착 순서가 일치하지 않을 수 있다. 통신 세션의 상태를 유지할 필요가 없으므로 서버 측의 리소스 소모가 적고, 단일 서버로 많은 수의 클라이언트 요청을 동시에 처리하는 데 유리하다.

비연결성은 속도와 단순함을 우선시하는 대신, 패킷 손실이나 순서 뒤바뀜에 대한 책임을 애플리케이션 계층에 맡긴다. 신뢰성보다는 실시간성이 중요한 환경에서 이점을 발휘한다.

UDP는 데이터 전송의 신뢰성을 보장하지 않는 프로토콜이다. 이는 데이터그램이 목적지에 성공적으로 도착했는지, 올바른 순서로 도착했는지, 중복되지 않았는지를 확인하는 메커니즘이 기본적으로 존재하지 않음을 의미한다. 송신자는 데이터를 보내기만 할 뿐, 수신자가 이를 제대로 받았는지에 대한 확인 응답(ACK)을 기다리지 않는다. 따라서 패킷이 네트워크 상에서 손실되거나 순서가 바뀌어 도착하더라도 프로토콜 자체는 이를 복구하거나 재전송하지 않는다.

이러한 특성은 데이터의 정확한 전달보다는 전송의 지연 없음과 속도가 더 중요한 애플리케이션에서 유리하게 작용한다. 예를 들어, 실시간 통신 프로토콜이나 스트리밍 서비스에서 가끔 발생하는 데이터 손실은 사용자 경험에 치명적이지 않을 수 있다. 오히려 손실된 패킷을 재전송하기 위해 발생하는 지연이 더 큰 문제가 될 수 있다. 신뢰성 미보장은 애플리케이션 계층에서 필요한 경우 자체적인 오류 검사 및 복구 메커니즘을 구현할 수 있는 유연성을 제공한다.

결과적으로, UDP를 사용하는 애플리케이션은 네트워크로부터 '최선의 노력(Best-Effort)' 전송 서비스만을 제공받는다. 전송의 신뢰성이 필요하다면, 애플리케이션 개발자가 체크섬을 활용한 기본적인 오류 검사 이상의 로직을 직접 설계하고 구현해야 한다.

UDP 헤더는 매우 단순하고 고정된 8바이트 크기를 가집니다. 헤더는 출발지 포트(16비트), 목적지 포트(16비트), 길이(16비트), 체크섬(16비트)의 네 가지 필드로만 구성됩니다. 길이 필드는 UDP 헤더와 데이터를 합친 전체 데이터그램의 길이를 바이트 단위로 나타냅니다. 체크섬 필드는 헤더와 데이터의 오류 검출을 위해 사용되지만, 선택 사항이며 값이 0일 경우 검사를 수행하지 않을 수 있습니다.

이러한 간결한 구조는 처리 오버헤드를 최소화합니다. 송신 측에서는 데이터에 간단한 헤더를 붙여 바로 전송할 수 있고, 수신 측에서는 헤더를 빠르게 분석하여 애플리케이션에 데이터를 전달합니다. TCP와 달리 연결 설정/해제, 순서 번호, 확인 응답, 혼잡 제어 정보 등을 위한 추가 필드가 전혀 없습니다.

결과적으로 UDP는 매우 낮은 프로토콜 오버헤드를 특징으로 합니다. 이는 네트워크 대역폭 사용 효율을 높이고, 패킷 처리에 필요한 계산량과 지연 시간을 줄입니다. 그러나 이는 신뢰성과 순서 보장을 포기한 대가입니다. 데이터그램은 손실되거나 중복되거나 순서가 바뀌어 도착할 수 있으며, 프로토콜 자체는 이러한 문제를 해결하지 않습니다.

이 낮은 오버헤드는 실시간性或 빠른 응답이 중요한 애플리케이션에서 결정적인 장점으로 작용합니다.

TCP는 데이터 전송 전에 3방향 핸드셰이크 과정을 통해 논리적인 연결을 수립하는 연결 지향 프로토콜이다. 이 과정에서 발신자와 수신자는 연결 파라미터를 협상하고 초기 시퀀스 번호를 교환하여 안정적인 통신 채널을 확보한다. 연결이 설정된 후에만 데이터의 순차적이고 신뢰할 수 있는 전송이 이루어진다. 전송이 완료되면 4방향 핸드셰이크를 통해 연결을 정상적으로 종료한다.

반면, UDP는 사전 연결 설정 과정 없이 데이터그램을 즉시 전송하는 비연결형 프로토콜이다. 발신자는 수신자의 상태나 가용성을 확인하지 않고 목적지 IP 주소와 포트 번호만을 지정하여 데이터를 보낸다. 이는 각 데이터 패킷이 독립적으로 취급됨을 의미하며, 이전이나 이후 패킷과의 관계를 유지하지 않는다.

두 방식의 차이는 통신의 신뢰성과 오버헤드에 직접적인 영향을 미친다. TCP의 연결 설정 및 해제 과정은 추가적인 패킷 교환과 상태 정보 유지를 필요로 하여 지연과 자원 소모를 발생시킨다. UDP는 이러한 오버헤드가 없어 지연이 매우 짧고 자원 사용이 효율적이지만, 패킷 손실이나 순서 뒤바뀜에 대한 기본적인 보장이 없다.

TCP는 데이터 전송의 신뢰성을 보장하기 위해 여러 메커니즘을 사용한다. 송신 측은 데이터를 패킷으로 분할하여 전송하고, 각 패킷에 시퀀스 번호를 부여한다. 수신 측은 이 번호를 확인하여 패킷의 순서를 재조립하고, 누락된 패킷이 있는지 검사한다. 모든 패킷의 정상 수신을 확인하면 ACK(Acknowledgement) 패킷을 송신 측에 보낸다. 송신 측은 ACK를 받지 못한 패킷에 대해서는 재전송(Retransmission)을 수행한다. 이 과정을 통해 데이터의 정확한 순서와 완전한 전달을 보증한다.

반면, UDP는 이러한 신뢰성 보장 메커니즘을 제공하지 않는다. UDP는 데이터를 데이터그램 형태로 전송하며, 패킷의 순서 확인, 도착 확인, 손실된 패킷의 재전송을 수행하지 않는다. 데이터그램은 독립적으로 전송되며, 네트워크 상황에 따라 순서가 바뀌어 도착하거나 아예 유실될 수도 있다. 이는 신뢰성보다는 전송의 신속성을 우선시하는 설계 철학에서 비롯된다.

결과적으로, 애플리케이션 계층에서 데이터의 완전한 무결성이 필수적인 경우(예: 파일 전송, 웹 페이지 로딩)에는 TCP를 사용한다. 반면, 약간의 데이터 손실이 허용되거나 실시간성이 더 중요한 경우(예: 실시간 동영상 스트리밍, VoIP)에는 UDP가 선호된다. UDP를 사용하는 애플리케이션은 필요시 자체적으로 간단한 오류 검사나 순서 복구 로직을 구현할 수 있다.

TCP는 3방향 핸드셰이크를 통한 연결 설정과 해제, 확인응답, 재전송, 흐름 제어, 혼잡 제어 등의 메커니즘으로 인해 상당한 오버헤드가 발생한다. 각 데이터 패킷의 전송 상태를 추적하고 신뢰성을 보장하기 위한 추가적인 제어 정보의 교환은 네트워크 대역폭을 더 소모하며, 처리 지연을 유발한다. 특히 네트워크 상태가 불안정하거나 패킷 손실이 빈번할 경우, 재전송으로 인한 지연은 전체 전송 속도를 더욱 저하시킨다.

반면, UDP는 이러한 연결 설정이나 신뢰성 보장 절차가 없기 때문에 전송 효율성이 매우 높다. 애플리케이션에서 데이터를 데이터그램 형태로 바로 전송하며, 수신 측의 확인응답을 기다리지 않는다. 이로 인해 헤더 오버헤드가 작고[2], 전송 지연이 매우 낮아 실시간성이 요구되는 환경에 유리하다.

다음 표는 두 프로토콜의 전송 특성을 비교한 것이다.

따라서, 애플리케이션의 요구사항이 절대적인 데이터 정확성이라면 TCP를 선택해야 하지만, 빠른 전송 속도와 낮은 지연이 더 중요하다면 UDP가 효율적인 선택이 된다. UDP 기반 애플리케이션은 필요한 경우 애플리케이션 계층에서 자체적인 신뢰성 메커니즘을 구현하여 효율성과 일정 수준의 신뢰성을 동시에 확보하기도 한다.

TCP 헤더의 크기는 최소 20바이트이며, 옵션 필드가 포함되면 최대 60바이트까지 확장될 수 있다. 헤더에는 시퀀스 번호, 확인 응답 번호, 윈도우 크기, 체크섬 등 연결 관리와 신뢰성 보장을 위한 다양한 정보가 포함되어 있다. 이로 인해 각 패킷 전송 시 상대적으로 큰 오버헤드가 발생한다.

반면, UDP 헤더는 매우 간단하여 고정적으로 8바이트만을 사용한다. 헤더 필드는 출발지 포트, 목적지 포트, 길이, 체크섬으로만 구성되어 있다. 이로 인해 UDP는 데이터 자체를 전송하는 데 더 많은 대역폭을 할당할 수 있으며, 헤더 처리에 필요한 연산량도 적다.

두 프로토콜의 헤더 구조 차이는 전송 효율성에 직접적인 영향을 미친다. 작은 크기의 데이터를 빈번히 교환해야 하는 애플리케이션에서는 UDP의 낮은 오버헤드가 큰 장점이 된다. 예를 들어, DNS 쿼리나 VoIP에서 한 번의 요청에 수십 바이트의 데이터만 필요할 경우, TCP의 20바이트 헤더는 상당한 비효율을 초래한다.

다음은 두 프로토콜의 헤더 필드를 비교한 표이다.

TCP는 데이터의 정확한 전달과 순서 보장이 중요한 애플리케이션에서 널리 사용된다. 대표적인 예로 월드 와이드 웹을 구성하는 HTTP와 HTTPS가 있다. 웹 브라우저가 서버로부터 HTML, 이미지, 스크립트 파일 등을 다운로드받을 때는 데이터의 일부가 손실되거나 순서가 뒤섞이면 웹 페이지가 정상적으로 표시되지 않기 때문에 TCP를 기반으로 한다. 이메일 전송을 위한 SMTP와 파일 전송을 위한 FTP 역시 데이터의 완전한 전송이 필수적이므로 TCP를 사용한다.

원격 접속과 터미널 세션 관리에도 TCP가 적합하다. 텔넷이나 보안이 강화된 SSH는 사용자의 모든 키 입력과 서버의 응답이 순서대로 정확하게 전달되어야 하므로 TCP를 프로토콜 기반으로 채택한다. 데이터베이스 시스템에서 클라이언트와 서버 간의 통신, 예를 들어 MySQL이나 PostgreSQL의 연결도 대부분 TCP를 통해 이루어진다. 이는 쿼리와 그 결과셋과 같은 중요한 데이터가 유실 없이 교환되어야 하기 때문이다.

또한, 많은 메신저 애플리케이션의 텍스트 채팅 기능이나 온라인 게임의 로그인, 인벤토리 동기화, 결제 정보 전송과 같이 신뢰성이 절대적으로 요구되는 제어 채널에도 TCP가 활용된다. 이러한 모든 예시는 3-way 핸드셰이크를 통한 연결 수립, 재전송 메커니즘, 그리고 순서 번호를 통한 데이터 정렬 등 TCP가 제공하는 신뢰성 보장 기능에 의존한다.

UDP는 신속한 데이터 전송이 중요하고, 일부 데이터 손실이 허용되거나 애플리케이션 계층에서 신뢰성을 처리할 수 있는 서비스에 널리 사용된다. 대표적인 사용 예는 다음과 같다.

실시간 멀티미디어 스트리밍 서비스는 UDP의 주요 적용 분야이다. VoIP(Voice over IP) 통화, 화상 회의, 실시간 방송 서비스 등이 여기에 해당한다. 이러한 서비스는 낮은 지연 시간과 연속적인 데이터 흐름이 최우선이며, 일부 패킷 손실은 사용자 경험에 큰 영향을 미치지 않는다. 예를 들어, 통화 중 일부 음성 패킷이 손실되더라도 잡음이나 끊김으로 인식될 뿐 통화 자체는 유지된다. TCP의 재전송 및 확인 응답 메커니즘은 이러한 실시간성에 오히려 방해가 될 수 있다.

DNS(Domain Name System) 쿼리는 UDP를 사용하는 대표적인 예이다. 사용자가 웹 주소를 입력하면, DNS 서버에 짧은 질의 메시지를 보내고 빠른 응답을 기대한다. 이 과정은 매우 간단하고 빠르게 완료되어야 하며, 질의와 응답이 단일 패킷으로 처리되는 경우가 많다. 만약 응답이 손실되면, 클라이언트는 간단히 요청을 재전송하면 되므로 TCP의 복잡한 연결 설정 절차는 불필요한 오버헤드를 초래한다.

온라인 게임과 같은 대화형 애플리케이션도 UDP를 선호한다. 게임에서 플레이어의 위치, 동작 정보는 매우 빠르게 업데이트되어야 하며, 최신 상태 정보가 이전 상태 정보보다 중요하다. TCP가 손실된 과거의 위치 패킷을 재전송하는 것은 게임 플레이에 무의미하거나 해로울 수 있다. 대신, 게임 클라이언트는 UDP를 기반으로 하여 자체적인 신뢰성 메커니즘(중요한 상태 변경 정보만 확인)을 구현하는 경우가 많다.

또한 트리밍이나 SNMP와 같은 네트워크 관리 프로토콜, DHCP를 통한 IP 주소 할당 과정도 UDP를 사용한다. 이들은 네트워크를 통해 주기적으로 또는 필요 시 제어 메시지를 교환하는데, UDP의 단순함과 빠른 전송이 적합하다.

애플리케이션의 요구사항은 TCP와 UDP 중 어떤 전송 계층 프로토콜을 선택할지 결정하는 가장 중요한 기준이 된다. 애플리케이션이 데이터의 정확한 전달을 최우선으로 하는지, 아니면 낮은 지연 시간과 빠른 전송 속도를 더 중요하게 여기는지에 따라 선택이 달라진다.

데이터의 완전한 신뢰성이 필수적인 애플리케이션은 TCP를 선택한다. 예를 들어, 이메일, FTP 파일 다운로드, 웹 페이지 로딩(HTTP/HTTPS) 등에서는 데이터의 일부가 손실되거나 순서가 뒤바뀌면 서비스의 의미가 훼손된다. 이러한 애플리케이션은 TCP가 제공하는 확인응답, 재전송, 순서 보장 등의 메커니즘에 의존한다.

반면, 실시간성이 중요한 애플리케이션은 데이터의 일부 손실을 감수하더라도 UDP를 선호한다. VoIP 통화, 실시간 스트리밍 비디오, 온라인 게임과 같은 서비스에서는 패킷 하나의 손실을 위해 재전송을 기다리는 것보다, 약간의 품질 저하를 무시하고 다음 데이터를 계속 전송하는 것이 전체적인 사용자 경험에 더 유리하다. 또한 DNS 쿼리와 같이 요청과 응답이 매우 짧은 트랜잭션 형태인 경우, TCP의 3-way 핸드셰이크 연결 설정 오버헤드는 불필요한 지연을 초래하므로 UDP가 효율적이다.

네트워크 환경은 TCP와 UDP 중 어떤 전송 계층 프로토콜을 선택할지 결정하는 중요한 요소이다. 네트워크의 상태와 특성은 각 프로토콜의 성능에 직접적인 영향을 미친다.

패킷 손실률이 높거나 지연 시간이 불안정한 네트워크 환경에서는 TCP의 신뢰성 보장 메커니즘이 필수적이다. TCP는 손실된 데이터를 재전송하고 순서를 재조정하여 애플리케이션에 완전한 데이터 스트림을 제공한다. 반면, 이러한 환경에서 UDP를 사용하면 데이터의 유실이나 순서 뒤바뀜이 그대로 애플리케이션에 전달되어 서비스 품질이 크게 저하될 수 있다. 네트워크 대역폭이 제한적이거나 혼잡이 빈번한 경우에도 TCP의 혼잡 제어 알고리즘이 네트워크를 보호하는 데 도움을 준다.

지연에 매우 민감하거나 실시간성이 요구되는 환경, 예를 들어 낮은 대역폭과 낮은 지연 시간을 동시에 요구하는 무선 네트워크나 특정 VoIP 환경에서는 UDP가 더 적합할 수 있다. UDP의 낮은 오버헤드와 연결 설정 지연이 없음은 제한된 자원 내에서 빠른 반응을 가능하게 한다. 또한 멀티캐스트나 브로드캐스트 전송이 필요한 네트워크 환경에서는 UDP가 일반적으로 사용된다[3]. 네트워크 토폴로지가 자주 변경되는 애드혹 네트워크에서도 비연결형인 UDP가 더 유연하게 동작할 수 있다.

포트(Port)는 네트워크 통신에서 특정 프로세스나 애플리케이션을 식별하기 위한 논리적인 단위이다. IP 주소가 특정 컴퓨터나 호스트를 식별한다면, 포트 번호는 그 호스트 내에서 실행 중인 개별 서비스나 프로그램을 구분하는 역할을 한다. 이는 한 호스트에서 여러 네트워크 서비스가 동시에 실행될 수 있도록 하는 핵심 메커니즘이다.

포트 번호는 0부터 65535까지의 16비트 정수 범위를 가진다. 이 범위는 크게 세 가지로 구분된다.

• 잘 알려진 포트 (Well-Known Ports, 0-1023): HTTP(80), FTP(21), SSH(22), DNS(53) 등 주요 시스템 서비스에 할당된다.

• 등록된 포트 (Registered Ports, 1024-49151): 일반 사용자 애플리케이션이 공식적으로 등록하여 사용한다.

• 동적/사설 포트 (Dynamic/Private Ports, 49152-65535): 클라이언트 측에서 임시 연결에 사용되며, 일반적으로 자동으로 할당된다.

TCP와 UDP는 각각 독립적인 포트 공간을 사용한다. 즉, TCP의 80번 포트와 UDP의 80번 포트는 서로 다른 통신 채널로 간주된다. 소켓(Socket)은 IP 주소와 포트 번호의 조합으로 정의되며, 이는 네트워크 통신의 종착점을 고유하게 지정한다. 예를 들어, 웹 서버는 클라이언트의 요청을 받기 위해 TCP 80번 포트를 열어두고 대기(listen)한다.

소켓은 네트워크 상에서 동작하는 프로세스 간의 통신 엔드포인트를 말한다. 운영체제가 제공하는 네트워크 프로그래밍 인터페이스의 일종으로, IP 주소와 포트 번호의 조합을 통해 특정 프로세스를 식별한다. 소켓을 생성하고 연결함으로써 TCP나 UDP와 같은 전송 계층 프로토콜을 사용한 데이터 교환이 가능해진다.

소켓은 사용하는 프로토콜과 통신 방식에 따라 여러 유형으로 구분된다. 가장 일반적인 구분은 스트림 소켓과 데이터그램 소켓이다. 스트림 소켓은 TCP 프로토콜을 사용하며, 연결 지향적이고 신뢰성 있는 양방향 통신 채널을 제공한다. 반면 데이터그램 소켓은 UDP 프로토콜을 사용하며, 비연결적이고 개별 패킷 단위의 통신을 지원한다.

소켓 프로그래밍의 일반적인 절차는 다음과 같다. 서버 측은 소켓 생성, 특정 포트에 바인딩, 연결 요청 대기, 클라이언트 연결 수락, 데이터 송수신의 단계를 거친다. 클라이언트 측은 소켓 생성 후 서버의 IP 주소와 포트 번호를 지정하여 직접 연결을 시도한다. TCP 소켓과 UDP 소켓은 이 연결 설정 과정에서 명확한 차이를 보인다.

소켓 인터페이스는 BSD 소켓을 기원으로 하여 대부분의 현대 운영체제에 표준으로 채택되었다. 이를 통해 애플리케이션 개발자는 하위 네트워크 계층의 복잡한细节을 추상화하고, 비교적 일관된 방식으로 네트워크 통신 기능을 구현할 수 있다.