🌐 아직도 모호한 TCP / UDP 개념 ❓ 쉽게 이해하자

...

HTTP / IP / TCP / UDP 는 모두 프로토콜

프로토콜은 클라이언트와 서버가 정보를 교환할 수 있도록 하는 메시지 형식 대한 규칙 이라고 보면 된다.

수신 호스트가 전송 받은 메시지를 이해하려면 설계된 규칙에 따라 작성된 데이터 형식이어야 한다는 말이다.

예를들어 HTTP 메세지 헤더도 결국 일종의 규칙이며, IP의 숫자도 규칙이라고 말할 수 있다. 만일 규칙을 깨는 256.256.256.256 와 같은 형식은 존재하지도 않는 아이피이며 작동하지도 않는다.

HTTP와 IP 프로토콜에 대해서 배우게되면 바로 그다음 접해보는 프로토콜 쌍둥이가 바로 TCP / UDP 일 것이다.

다만 이 TCP와 UDP에 대해서 귀가 아플정도로 들어봤겠지만 아무리 들어도 개념이 애매하게 느껴진다.

왜냐하면 HTTP 같은 경우 브라우저의 개발자 도구의 네트워크 탭에서 HTTP 메세지의 헤더(header)로 어떠한 구조로 메세지를 주고 받는지 눈으로 결과값을 확인할 수 있으며, 또한 IP 같은 경우 192.168.10.1 같이 숫자로 이루어져 무언가 주소값을 나타내고 있다는 것임을 알수 있고, 브라우저에 아이피로 접속하면 해당 홈페이지로 이동해 어떠한 네트워킹 동작이 일어나고 있음을 직감할 수 있기 때문이다.

그러나 TCP / UDP는 3 HandShake니 신뢰성니 뭐니 지겹게 개념 단어와 표, 그림은 봐왔지만, 실질적인 통신 결과와 같은 눈으로 보이는게 없어 순 이론 덩어리로 느껴 백날백번 들어도 잘 와닿지 않는게 현실이다. 그렇다고 와이어샤크(Wireshark) 같은 전문 툴을 쓰기에는 메뉴도 복잡하고 원하는 패킷을 필터링하기도 힘들기 때문에 꺼려지는 것도 사실이다.

사실 TCP만 해도 굉장히 오래된 역사를 지닌 프로토콜이라 이에 대한 이론도 몇백장이 넘어갈정도로 굉장히 방대하다. 따라서 이번 포스팅에서는 TCP와 UDP에 대한 이론덩어리 개념을 친숙하게 접근하여 살펴보고, 시각적으로 빠르게 개념을 다지고 넘어가는 것을 목표로 한다.

그리고 상대적으로 빈약하게 배우는 UDP에 대해서 최신 기술인 HTTP 3.0를 소개하며 왜 각광을 받았는지에 대해 좀더 자세히 알아보도록 하는 시간을 가질 것이다.

TCP - 전송 제어 프로토콜

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

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

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

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

📦 TCP의 안전 포장

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

인터넷 통신을 택배 수하물로 비유하자면, IP는 단순히 배달 주소지라고 하면 TCP는 이 배달지로 문제없이 전송되도록 택배 스티커와 같은 여러 부가 정보들을 가미한 것이라고 보면 된다. 단순히 목적지 뿐만 아니라 순서, 검증, 전송 제어 정보가 들어있어 IP 주소지로만 물품을 배달하기엔 불안정한 부분들을 확실하게 커버하여 배달품이 목적지까지 안전하게 도착하도록 보증한다.

전송 데이터가 포장되는 과정을 나열해보면 아래 그림과 같다.

다만 이부분은 OSI 7 Layer와 더불어 TCP/IP 4계층 에 대해 알고 있어야 이해가 가능하지만, 이 포스팅에서 네트워킹 까지 자세히 다루기에는 무리가 있어 그림으로 간단하게 표현하였다.

전송데이터를 TCP 포장한다.
포장한 전송데이터를 IP 포장한다
포장한 전송데이터를 이더넷 포장한다
인터넷을 통해 상대 컴퓨터 서버에 도달하여 포장된걸 하나씩 풀며 전송데이터를 받게 된다

TCP — https://medium.com/@i01029407043/http-%EC%9B%B9-%EA%B8%B0%EB%B3%B8-%EC%A7%80%EC%8B%9D-1-37000d83705b

✅ TCP의 꼼꼼한 통신 확인

TCP는 신뢰성 프로토콜 답게, 배달 하기전에 목적지가 무사한지 미리 확인하고 배달 끝나고도 또 확인도 해주는 굉장히 친절한 프로토콜이다. 통신을 시작할 때와 종료할 때 서로 준비가 되어있는지를 반드시 미리 먼저 물어보고 패킷을 전송할 순서를 정하고 나서야 본격적인 통신을 시작하기 때문이다.

이러한 과정이 우리가 지겹도록 들은 3 Way Handshake 와 4 Way Handshake 과정이다.

둘다 똑같은 핸드쉐이크(Handshake)지만, 3 Way는 통신을 시작할때, 4 Way는 통신을 마칠때 거치는 과정이라는 차이만 있을 뿐이다.

한마디로 한번 통신하는데 Handshake를 두번 해서 신뢰가 두텁다 못해 과하게 신뢰성을 보장한다고 생각하면 된다.

아래 그림을 보면 클라이언트가 처음 서버와 통신을 하기 위해 TCP 연결을 생성할 때 SYN와 ACK이라는 패킷을 주고 받고, 통신을 종료하는 과정에선 FIN이라는 패킷을 주고 받고 있는 걸 확인 할 수 있다.

단어가 생소하다고 해서 어렵게 생각하지말고 그냥 내가 너 한테 전송하였다는 인증 도장 정도로 생각하면 된다.

즉, 패킷 내부에 들어있는 인증 플래그 값들을 확인하여 클라이언트와 서버가 서로 보낸 패킷의 순서와 패킷을 제대로 받았는 지를 검증하는 것이다.

🚩 Flag 종류

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() 한다는 것을 알게되고 CLOSE_WAIT 상태로 바꾼 후 ACK 플래그를 전송한다.
만일 서버에서 클라이언트로 보낼 남은 데이터가 있을 경우 이때 나머지를 모두 전송시킨다.
ACK를 받은 클라이언트는 FIN_WAIT2로 변환되고, 이때 서버는 CLOSE() 함수를 호출하고 FIN 플래그를 클라이언트에게 보낸다.
서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK 플래그를 보낸 후 TIME_WAIT 상태로 전환된다.
이 후 모든것이 끝나면 CLOSED 상태로 변환된다.

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

백날 그림으로 봐도 실제 통신 과정을 직접 경험하지 않으면 시간이 지나면 금세 까먹게 된다. 최고의 기억은 직접 고생해서 경험하는 법이다.

TCP 핸드쉐이크 과정을 살펴보기 위해 우리는 Linux의 명령어를 이용하여 확인할 예정이다. 물론 와이어샤크(WireShark)라는 훌륭한 무료 소프트웨어가 있지만, 메뉴도 복잡하고 원하는 패킷을 필터링하기도 힘들기 때문에 입문이 쉽지 않기 때문에 리눅스 터미널을 이용하는 방법을 택했다.

🐧 리눅스 tcpdump 명령어

tcpdump는 Linux 환경에서 Client와 Server가 주고받는 네트워크 패킷을 TCP Layer에서 캡쳐하여 메세지를 확인할 수 있는 명령어이다. UDP도 확인 가능하다.

먼저 ~~tcpdump~~ 명령어를 리눅스에 설치해준다.

# 우분투 설치
$ apt install tcpdump

# CentOS 설치
$ yum install tcpdump

그리고 다음 명령어를 실행한다.

# 인터넷 통신을 하는 모든 프로토콜을 감지
$ tcpdump -i any -nn port 80

명령어를 실행하면 위와 같이 인터넷 통신을 감지하는 상태가 된다.

이번에는 새로운 터미널을 하나 더 만들고, 다음과 같이 리눅스의 ~~netcat(nc)~~ 명령어로 데이터 통신을 행한다.

# "Hello World" 라는 데이터를 TCP로 naver.com 에 80번 포트로 전송
$ echo "Hello World" | nc naver.com 80

새로운 터미널에서 데이터를 보내게되면, 기존 tcpdump 명령어를 실행하 Listen 상태였던 터미널에서 통신을 받아 로그를 띄우게 된다.

먼저 10.0.2.15:57744은 클라이언트 아이피 이고, 223.130.200.104:80는 서버 아이피 이다.

각 라인의 첫번째 필드는 보낸 놈 > 받은 놈을 의미하고 있다. 그리고 옆에 ~~Flags [S]~~ 라는 것이 붙어있는데, 대괄호 안의 대문자는 위에서 살펴본 플래그를 의미한다.

Flag	이름
S	SYN
S.	SYN-ACK
.	ACK
P	PSH
F	FIN

지금 위의 상태는 하나의 TCP 연결 및 데이터 전송과 종료 전체의 통신 과정을 행한 상태이다.

이제 각각 명령어 로그 어느 부분이 어느 핸드쉐이크인지 살펴보자.

🤝 3-way handshake 과정

클라이언트(10.0.2.15) → 서버(223.130.200.104) : SYN
서버(223.130.200.104) → 클라이언트(10.0.2.15) : SYN ACK
클라이언트(10.0.2.15) → 서버(223.130.200.104) : ACK

seq 번호는 순서 번호로서 패킷의 전달 순서를 식별하는데 사용되는 값이다.
운영체제의 의해서 랜덤하게 생성되서 SYN 패킷에 담겨 보내진다. 그리고 이를 받은 서버에는 동기화에 대한 답신으로 seq 번호를 +1 증가시키고 ack에 담아 응답한다.

✉️ 데이터 통신 과정

클라이언트(10.0.2.15) → 서버(223.130.200.104) : PSH ACK
서버(223.130.200.104) → 클라이언트(10.0.2.15) : ACK

🤝 4-way handshake 과정

그림상에서는 클라이언트가 먼저 종료 신호를 보냈지만, 리눅스 상에서는 서버가 먼저 종료 신호를 보낸 거꾸로된 상황이다. 그래서 처음에 FIN ACK가 같이 응답해왔고, 또한 ACK와 FIN을 보내는 과정이 하나로 합쳐졌다.

서버(223.130.200.104) → 클라이언트(10.0.2.15) : FIN ACK
클라이언트(10.0.2.15) → 서버(223.130.200.104) : FIN ACK
서버(223.130.200.104) → 클라이언트(10.0.2.15) : ACK

🕹️ TCP의 전송 제어 기법

TCP(Transmission Control Protocol)는 단어 그대로 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있다. 만약 TCP가 없었더라면 개발자가 일일히 데이터를 어떤 단위로 보낼 것인지 정의해야하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에, 덕분에 우리는 온전히 상위의 동작에만 집중할 수 있는 것이다.

보통 TCP의 전송 제어 방법은 다음 3가지로 정리 된다.

이 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 와 TCP를 비교하는데 있어 아래와 같은 표를 많이 인용해왔을 것이다.

표를 보면 대략 TCP는 신뢰성이 높고 느리다 와 UDP는 신뢰성이 낮고 빠르다 정도로 정리가 된다.

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

아무래도 클라이언트와 서버가 서로 신뢰성있는 통신을 할 수 있도록 TCP는 핸드쉐이크 과정을 거치게 되는데, 위에서 살펴본것 처럼 데이터 하나를 전송하기 위한 밑작업들이 많았었다.

그렇지만 인터넷 기술이 발전하면서 전송해야하는 데이터도 단순 텍스트를 넘어서 동영상이나 음악과 같은 멀티미디어도 전송하면서 데이터의 크기가 점점 커져가며 동시에 빠른 통신이 필요해 졌다. 그래서 HTTP 2.0 에서는 한번 연결된 TCP 회선을 길게 유지하고 데이터도 스트림이라는 특수한 형태로 보내는 식으로 극복을 했지만, TCP 자체가 가지는 근본적인 특징때문에 결과적으로 속도 한계가 있었다. (즉, 너무 헤비해서 더이상 속도를 뽑아 낼수가 없음)

반면, UDP(User Datagram Protocol)는 단어에서도 알 수 있듯이 데이터그램 방식을 사용하는 프로토콜이기 때문에 애초에 각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용한다.

데이터그램 방식은 패킷의 목적지만 정해져있다면 중간 경로는 어딜 타든 신경쓰지 않기 때문에 핸드쉐이크 과정 같은 연결 설정이 필요 없게 된다. 즉, UDP는 신뢰성을 확보하기 위해 거치던 TCP의 과정을 거치지 않기 때문에 속도가 더 빠를 수 밖에 없다는 것이다. 그래서 UDP는 실시간 영상 스트리밍과 같은 고용량 데이터를 다루는 곳에 이용된다.

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

UDP가 왜 TCP 보다 빠른지는 리눅스 명령어를 통해서도 한눈에 이해할 수 있다.

기존 ~~netcat~~ 명령어에 -u 옵션을 주게 되면 UDP로 데이터를 송신 하게 되는데, 수신측 로그를 보면 진짜 딸랑 한줄이 끝이다. 잘받았다는 응답 패킷 없이 무지성으로 보내기만 하는 것이다.

# "Hello World" 라는 데이터를 -u 옵션(UDP로) naver.com 에 80번 포트로 전송
$ echo "Hello World" | nc -u naver.com 80

🔍 TCP 헤더와 UDP 헤더 크기 차이

TCP가 신뢰성있는 연결과 혼잡 제어 등을 위해 얼마나 많은 기능을 가지고 있는 지는 TCP와 UDP의 헤더를 비교 해보면 대각이 나온다.

📄 TCP 헤더 구성

TCP의 경우 워낙 오래 전에 설계되기도 했고, 이런 저런 기능이 워낙 많이 포함된 프로토콜이다보니 이미 헤더가 거의 풀방이다.

Source Port : 데이터를 생성한 애플리케이션에서 사용하는 포트번호
Destination Port : 목적지 애플리케이션이 사용하는 포트 번호
Sequence Number 필드 : 세그먼트 순서를 맞추기 위한 필드
Acknowledgement Number 필드 : 다음 세그먼트 수신 준비 및 모든 데이터 수신 확인 역할
Data Offset 필드 : TCP 헤더의 크기 ( 5~15 : 5*32<160bit> ~ 15*32<480bit> )
Reserved 필드 : 차후의 사용을 위한 예약된 필드
Control Flags (SYN, ACK, FIN ...등) : 긴급, 혼잡, 확인, 수신 거부 등의 기능
Window size 필드 : 수신자가 한번에 받을 수 있는 데이터의 양. 송신자는 Window size만큼 ACK를 기다리지 않고 데이터를 전송. ACK가 계속 왔다갔다 하지 않아도 된다
Checksum : 세그먼트 내용의 유효성과 손상 여부 검사

📄 UDP 헤더 구성

반면 UDP는 데이터 전송 자체에만 초점을 맞추고 설계되었기 때문에 헤더에 들어있는게 없다. (그래서 하얀 도화지 같다는 비유가 생긴 것이다)

UDP의 헤더에는 출발지와 도착지, 패킷의 길이, 체크섬 밖에 없다.

Source Port : 데이터를 생성한 애플리케이션에서 사용하는 포트번호
Destination Port : 목적지 애플리케이션이 사용하는 포트 번호
checksum : 중복 검사의 한 형태로, 오류 정정을 통해 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법. (TCP의 체크섬과는 다르게 UDP의 체크섬은 사용해도 되고 안해도 되는 옵션)

TCP를 버리고 UDP를 선택한 HTTP 3.0

학부에서는 아무래도 TCP는 인터넷 통신에서 필수적으로 쓰이는 녀석이라 자세히 배우고, UDP는 빠르다 정도로 간단히 배우고 휙 넘어가버리는 모양인데, 이제는 그럴수가 없다. 위의 제목에서와 같이 HTTP/3 에서는 TCP를 버리고 UDP를 채택했기 때문이다.

[WEB] 🌐 HTTP 3.0 통신 기술 - 자신있게 이해하기

HTTP / 3.0 HTTP 2.0 의 등장과 함께 기존의 프로토콜 데이터 체계를 프레임과 스트림 개념으로 재구축한 결과 기존 보다 혁신적으로 성능이 향상되게 되었다. 하지만 여전히 HTTP는 TCP 기반 위에서 동

inpa.tistory.com

2022년 11월 15일 한국 최초로 네이버도 HTTP/3을 도입하였다고 한다.

http-udp — https://n.news.naver.com/mnews/article/022/0003754517?sid=101

💬 TCP는 구조상 한계로 개선해도 여전히 느리다

사실 TCP는 인류가 지금과 같이 엄청난 속도로 발전할 것이라곤 상상 할 수 없는 시기에 만들어졌다. TCP가 만들어지던 시절에 클라이언트와 서버가 동시 다발적으로 여러 개 파일의 데이터 패킷을 교환할 것이라고 상상하지 못했기 때문이다.

그래서 모바일 기기와 같이 네트워크 환경을 바꾸어가면서 서버와 클라이언트가 소통할 수 있을 것이라고 생각하지 못했다. 그 때문에 와이파이를 바꾸면 다시 새로운 커넥션을 맺어야 되서 끊김 현상이 일어나는 것이다.

또한 TCP를 사용한 통신에선 패킷은 신뢰성을 위해 무조건 순서대로 처리되어야 한다. 또한 패킷이 처리되는 순서 또한 정해져있으므로 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수도 없다. 만일 중간에 패킷이 손실되어 수신 측이 패킷을 제대로 받지 못했으면 다시 보내야 한다.

이렇게 패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목이 발생하게 되는데, 이러한 현상을HOLB(Head of line Blocking)라고 부른다.

이 HOLB는 TCP 설계도상 어쩔수 없이 발생하는 문제이기 때문에 HTTP/1.1 뿐만 아니라 HTTP/2도 가지고 있는 아주 고질적인 문제였다.

따라서 이런 고질적인 문제들을 해결하기 위해 HTTP/3는 TCP를 버리고 UDP를 선택하였다.

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

앞서 신뢰성 대신 속도를 택한 UDP는 스트리밍과 같은 서비스에서 사용된다고 소개한 바가 있다. 방송이나 동영상은 중간에 끊길지언정 바로바로 데이터를 빠르게 송출하는것이 더 중요하기 때문이다.

하지만 기본적으로 인터넷은 클라이언트와 서버 간의 정확한 패킷 통신이 필요하기 때문에 신뢰성이 보장받아야 한다. 왜 HTTP가 TCP를 기반으로 했는지 그 이유이다.

많이들 착각하는 것이 빠른건 알겠는데 UDP는 신뢰성이 없기 때문에 사용성이 적다고 이해하는 것이다. 하지만 이는 명확하지 않다.

UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐이다. UDP의 진짜 장점은 커스터마이징이 가능하다는 점이다.

즉, UDP 자체는 헤더에 들은게 없어 신뢰성이 낮고 제어 기능도 없지만, 이후 개발자가 애플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수도 있다는 말이다.

💬 UDP를 개조한 QUIC 프로토콜

QUIC(Quick UDP Internet Connections)는 UDP를 기반으로 TCP + TLS + HTTP 의 기능을 모두 구현하는 프로토콜이다. 따라서 HTTP 3.0이 UDP를 이용하였다라는 말은 정확히 말하면 UDP 기반으로 만들어진 QUIC 프로토콜을 채택하였다라는 뜻이다.

QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3 Way Handshake 과정을 거치지 않아도 된다.

클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라고 하는데, TCP는 연결을 생성하기 위해 기본적으로 1 RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 하려고 한다면 TLS의 자체 핸드쉐이크까지 더해져 총 3 RTT가 필요하다.

반면 QUIC은 첫 연결 설정에 1 RTT만 소요된다.

TCP 핸드쉐이크 과정을 거치지 않으며 TLS 자체를 내포하고 있기 때문에, 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문이다. 그리고 한번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가, 다음 연결 때는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시키기 때문에 0 RTT만으로 바로 통신을 시작할 수도 있다.

이밖에도 패킷 손실 감지에 걸리는 시간 단축되었으며, 클라이언트의 IP가 바뀌어도 연결이 유지되어 모바일에서 와이파이를 바꾸어도 끊김이 없어지게 되었다.

# 참고자료

https://www.crocus.co.kr/1362

https://evan-moon.github.io/2019/11/22/tcp-flow-control-error-control/

https://evan-moon.github.io/2019/10/08/what-is-http3/

https://evan-moon.github.io/2019/11/10/header-of-tcp/#%ED%8C%A8%ED%82%B7-%EA%B5%90%ED%99%98-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EB%AC%B8%EC%A0%9C%EC%A0%90

https://blog.cloudflare.com/ko-kr/http3-the-past-present-and-future-ko-kr/

https://devopedia.org/quic