TCP 그리고 UDP

JINJIN·2024년 4월 24일

network

Network

목록 보기

2/2

TCP 그리고 UDP 프로토콜은 무엇일까요? 🙄

프로토콜에 대하여

프로토콜을 쉽게 설명하면 클라이언트와 서버가 정보를 교환할 수 있도록 하는 메시지 형식 대한 규칙이라고 말할 수 있습니다.

인터넷에서 데이터가 어떻게 안전하고 효율적으로 전달되는지에 대한 이해는 HTTP, IP, TCP, UDP와 같은 주요 프로토콜의 역할을 파악하는 것에서 시작됩니다. 이 프로토콜들은 디지털 통신의 핵심 요소로, 각각 다른 층에서 작동하여 네트워크 통신을 가능하게 합니다.

HTTP 프로토콜에 대한 포스팅
HTTP 프로토콜에 대해서는 지난 포스팅에서 다루었습니다. 이번에는 TCP/UDP 쌍둥이 프로토콜에 대해서 알아보겠습니다!

TCP - 전송 제어 프로토콜

TCP(Transmission Control Protocol)는 연결 지향적인 프로토콜로, 데이터 전송 전에 통신을 위한 연결을 설정합니다. 이 연결을 통해 데이터는 순차적이고 신뢰성 있는 전송이 보장됩니다.

IP(Internet Protocol)가 인터넷 프로토콜로서 복잡한 인터넷망 속에서 클라이언트와 서버 간에 통신할 수 있게 IP 주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것이라면,

TCP는 IP 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해, 패킷 전송을 제어하여 신뢰성을 보증하는 프로토콜로 보면 됩니다.

IP와 TCP 둘 다 프로토콜이지만 이 둘을 동일시로 보면 안 됩니다. 이 둘은 별개의 규칙입니다.

IP 규칙에 쓰여 있는 대로 목적지까지 다다랐으면, TCP 규칙에 쓰여 있는 대로 올바르게 도착했는지 정확히 누구에게 전달돼야 하는지 하나하나 따진다고 생각하면 됩니다. 그래서 은행 업무나 메일과 같은 반드시 수신자가 정보를 받아야 하는 신뢰성 있는 통신이 필요할 때 사용됩니다.

📦 TCP의 안전 포장

아직도 TCP에 대해 잘 와닿지 않는다면 이런 식으로 접근해보는 것도 좋습니다.

인터넷 통신을 택배 수하물로 비유하자면, IP는 단순히 배달 주소지라고 하면 TCP는 이 배달지로 문제없이 전송되도록 택배 스티커와 같은 여러 부가 정보들을 가미한 것이라고 보면 됩니다.

단순히 목적지뿐만 아니라 순서, 검증, 전송 제어 정보가 들어있어 IP 주소지로만 물품을 배달하기엔 불안정한 부분들을 확실하게 커버하여 배달품이 목적지까지 안전하게 도착하도록 보증합니다.

✅ TCP의 꼼꼼한 통신 확인

TCP는 신뢰성 있는 프로토콜로서, 전송 전후로 목적지의 상태를 확인하고, 배달이 끝난 후에도 다시 확인을 진행하는 매우 세심한 프로토콜입니다. 통신을 시작하거나 종료하기 전에 상대방의 준비 상태를 반드시 확인하고, 패킷의 전송 순서를 확정한 후에야 본격적으로 데이터 교환을 시작합니다. 이런 절차는 3-Way Handshake와 4-Way Handshake 과정을 통해 이루어집니다.

3-Way Handshake는 통신을 시작할 때, 4-Way Handshake는 통신을 마칠 때 사용됩니다. 이 두 과정은 동일한 Handshake 절차이지만, 하나는 통신을 개시할 때, 다른 하나는 종료할 때 실행된다는 점에서 차이가 있습니다. 간단히 말해, TCP는 한 번의 통신에 두 번의 Handshake를 수행하여 신뢰성을 극대화합니다.

아래 그림을 참고하시면 이해가 더 쉬울 것입니다. 클라이언트가 서버와 처음으로 통신을 시작하려 할 때, TCP 연결을 생성하기 위해 SYN와 ACK이라는 패킷을 주고받습니다. 통신을 종료할 때는 FIN이라는 패킷을 사용합니다. 이러한 용어가 다소 생소하게 느껴질 수 있지만, 간단히 이를 '전송 확인 도장' 정도로 이해하시면 됩니다. 즉, 패킷 내부에 포함된 플래그 값을 통해 클라이언트와 서버가 패킷의 순서와 올바른 수신을 확인하는 과정입니다.

이렇게 TCP는 데이터 전송의 정확성과 완전성을 확보하기 위한 다양한 메커니즘을 갖추고 있으며, 이로 인해 네트워크 통신에서 광범위하게 활용됩니다.

FLAG	설명
SYN	접속요청을 할 때 보내는 패킷. TCP 접속 시에 가장 먼저 보내는 패킷입니다.
ACK	상대방으로부터 패킷을 받은 뒤에, 잘 받았다고 알려주는 패킷. 다른 플래그와 같이 출력되는 경우도 있습니다.
PSH	데이터를 즉시 목적지로 보내라는 의미입니다.
FIN	접속종료를 위한 플래그. 이 패킷을 보내는 곳이 현재 접속하고 있는 곳과 접속을 끊고자 할 때 사용합니다.

🤝 3-way handshake 과정

클라이언트는 접속을 요청하는 SYN 패킷을 전송하고, 클라이언트는 응답을 기다리는 동안 SYN_SENT 상태로 전환됩니다.
LISTEN 상태에 있던 서버는 클라이언트의 SYN 요청을 받고, 요청을 수락하는 ACK 패킷과 자신의 SYN 패킷을 클라이언트에게 전송합니다. 이는 서버 또한 클라이언트와 양방향 통신을 설정해야 하기 때문입니다. 서버는 이후 SYN_RCVD(SYN_RECEIVED) 상태로 전환되어, 클라이언트로부터의 ACK 패킷을 기다리게 됩니다.
클라이언트는 서버에게 ACK 패킷을 보내고, 이 패킷이 서버에 도착하면 양쪽 모두 ESTABLISHED 상태가 되어 데이터 통신이 가능해집니다.

✉️ 데이터 통신 과정

ESTABLISHED 상태에서 클라이언트는 서버에 데이터를 전송합니다.
서버는 데이터를 정상적으로 수신하였다는 사실을 클라이언트에 알리기 위해 ACK 플래그가 포함된 응답을 보냅니다.
클라이언트가 서버로부터 ACK 응답을 받지 못하면, 데이터가 제대로 전송되지 않았다고 판단하고 해당 데이터를 재전송합니다.

4-way handshake 과정

서버와 클라이언트 사이에 TCP 연결이 확립된 상태에서, 클라이언트가 접속 해제를 위해 close() 함수를 호출하면 FIN 플래그가 서버로 전송됩니다. 이때 클라이언트는 FIN_WAIT1 상태로 전환됩니다.
서버는 클라이언트의 접속 해제 요청을 인지하고, 남아 있는 데이터가 있을 경우 이를 모두 전송한 뒤, CLOSE_WAIT 상태로 전환합니다. 그 후, 클라이언트에게 ACK 플래그를 보내 접속 해제 요청을 확인합니다.
ACK를 수신한 클라이언트는 FIN_WAIT2 상태로 변경되며, 이 시점에서 서버는 자신의 close() 함수를 호출하여 클라이언트에게 FIN 플래그를 전송합니다.
클라이언트가 서버로부터의 연결 해제 신호를 수신하면, 서버에게 ACK 플래그를 보내고 TIME_WAIT 상태로 전환됩니다. 이 상태에서 일정 시간이 지난 후, 클라이언트는 최종적으로 CLOSED 상태가 됩니다.

🕹️ TCP의 전송 제어 기법

TCP(Transmission Control Protocol)는 이름에서 알 수 있듯이, 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있습니다. 만약 TCP가 없었다면, 개발자들은 데이터를 어떤 단위로 보낼지 직접 정의해야 했을 것이며, 패킷이 유실될 경우에 필요한 예외 처리를 직접 설계해야만 했을 것입니다. 이러한 부담으로부터 자유로워진 덕분에, 우리는 응용 프로그램 개발에 더욱 집중할 수 있게 되었습니다.

TCP의 전송 제어 기능은 주로 다음 세 가지 주요 메커니즘으로 정리됩니다.

📵 흐름 제어(Flow Control)

수신자가 처리할 수 있는 데이터 속도가 다르므로, 송신 측은 수신 측의 데이터 처리 속도를 파악하고 얼마나 빠르게 어느 정도의 데이터를 전송할지 제어
슬라이딩 윈도우(Sliding Window) 방식을 사용
Window 라는 데이터를 담는 공간을 동적으로 조절하여 데이터량을 조절

📵 오류 제어(Error Control)

통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처
Go Bank N 기법과 Selective Repeat(선택적인 재전송) 기법을 사용

Go Bank N 기법
어느 데이터로부터 오류가 발생했는지 파악하여, 그 부분만 다시 순서대로 보내 제어합니다.

Selective Repeat 기법
오류가 발생한 데이터만 재전송하고 그전에 받았던 순서가 잘못된 데이터 버퍼를 재정렬하여 제어합니다.

📵 혼잡 제어(Congestion Control)

네트워크가 불안정하여 데이터가 원활히 통신이 안 되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴할 수도 있다. 따라서 네트워크 혼잡 상태가 감지되면 송신 측의 전송 데이터 크기를 조절하여 전송량을 조절
TCP에는 Tahoe, Reno, New Reno, Cubic, Elastic-TCP 등 다양한 혼잡 제어 기법이 존재합니다.

UDP - 사용자 데이터그램 프로토콜

UDP(User Datagram Protocol)는 비연결형 프로토콜로, 연결 설정 없이 데이터를 전송합니다.

보통 UDP와 TCP를 비교하는 데 있어 아래와 같은 표를 많이 인용해왔을 것입니다.
표를 보면 대략 TCP는 신뢰성이 높고 느리다는 것과 UDP는 신뢰성이 낮고 빠르다 정도로 정리할 수 있습니다..

비교	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환	가상 회선 방식	데이터그램 방식
전송 순서 보장	보장함	보장하지 않음
신뢰성	높음	낮음
전송 속도	느림	빠름

클라이언트와 서버가 서로 신뢰성 있는 통신을 할 수 있도록, TCP는 핸드셰이크 과정을 거치게 됩니다. 이러한 과정은 데이터를 전송하기 전에 필수적인 밑작업을 포함하고 있습니다.

그러나 인터넷 기술이 발전하면서 전송해야 할 데이터가 단순 텍스트를 넘어 동영상이나 음악과 같은 멀티미디어로 확장되었고, 데이터의 크기가 점점 커지면서 더욱 빠른 통신이 필요해졌습니다. 이에 HTTP 2.0은 한 번 연결된 TCP 회선을 오랫동안 유지하며 데이터를 스트림 형태로 전송하는 방식으로 이를 극복하려 하였지만, TCP의 근본적인 특성으로 인해 속도의 한계를 경험하게 되었습니다.

반면, UDP는 데이터그램 방식을 사용하는 프로토콜로, 각 패킷이 독립적으로 운영되므로 패킷 간 순서가 존재하지 않습니다.

데이터그램 방식은 패킷의 목적지만 명확하면 중간 경로에 크게 신경 쓰지 않아도 되기 때문에, 핸드셰이크와 같은 연결 설정 과정이 필요 없습니다. 따라서 UDP는 TCP가 신뢰성을 확보하기 위해 거치는 과정을 생략함으로써 속도가 더 빨라질 수 있습니다. 이러한 특성 때문에 UDP는 실시간 영상 스트리밍과 같은 고용량 데이터 처리에 주로 사용됩니다.

👀 UDP 통신 과정 시각적으로 보기

UDP가 왜 TCP 보다 빠른지는 아래 그림을 통해서 한눈에 이해할 수 있습니다.
UDP는 TCP의 핸드셰이크 과정을 생략하여 신뢰성은 떨어지지만 더 빠른 전송 속도를 가질 수 있었습니다.

💬 UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐

앞서 언급드린 바와 같이, 신뢰성보다는 속도를 우선시하는 UDP는 스트리밍과 같은 서비스에서 자주 사용됩니다. 방송이나 동영상 서비스의 경우, 중간에 데이터가 일부 끊기더라도 실시간으로 데이터를 빠르게 전송하는 것이 더 중요하기 때문입니다.

하지만 기본적으로 인터넷에서는 클라이언트와 서버 간의 정확한 패킷 통신이 필요하며, 이 때문에 신뢰성이 보장되는 것이 중요합니다. 이것이 HTTP가 TCP를 기반으로 한 주된 이유입니다.

많은 분들이 UDP를 사용하지 않는 이유로 '신뢰성이 없다'고 오해하시는 경우가 있습니다. 하지만 이는 정확한 표현이 아닙니다.

UDP는 신뢰성이 없는 것이 아니라, 기본적으로 신뢰성을 제공하지 않는 구조로 설계되었습니다. UDP의 가장 큰 장점은 커스터마이징이 가능하다는 점입니다.

즉, UDP 자체는 헤더에 기능이 제한적이어서 기본적으로는 신뢰성이 낮고 제어 기능이 부족하지만, 개발자가 애플리케이션 레벨에서 어떻게 구현하느냐에 따라 TCP와 유사한 수준의 기능을 제공할 수 있습니다.