HTTP/3 -> 왜 TCP가 아닌 UDP를 사용할까

HTTP/3

 

HTTP의 3번째 메이저 버전으로 HTTP/2의 차기 버전, 2022년 6월 6일 표준화됨

 

 

HTTP 3에서는 기존 TCP 방식이 아닌 UDP 방식 사용

공부할 때는 TCP방식이 더 신뢰성 있고 좋은 거라고 배웠는데 왜 이번에 UDP방식으로 돌아 갔을까?

 

 

UDP 방식의 장점인 속도 때문이다.

거기에 구글이 QUIC 방식이 더해져서 신뢰성도 확보할 수 있게 됐다. 

 

QUIC은 TCP가 가지고 있는 문제들을 해결하고 레이턴시의 한계를 뛰어넘고자 구글이 개발한 UDP 기반의 프로토콜,

TCP의 핸드쉐이크 과정을 최적화하는 것에 초점을 맞추어 설계되었고, UDP를 사용함으로써 이를 실현해냄

 

 

구글에서 UDP방식을 선택한 이유

 

UDP의 장점은 바로 커스터마이징이 용이하다는 것

 

TCP의 경우 워낙 오래 전에 설계되기도 했고, 이런 저런 기능이 워낙 많이 포함된 프로토콜이다보니 이미 헤더가 거의 풀방이라 실질적으로 사용자가 커스텀 가능한 자리가 없음

 

반면 UDP는 데이터 전송 자체에만 초점을 맞추고 설계되었기 때문에 헤더에 진짜 아무 것도 없다.

 

즉, UDP 프로토콜 자체는 TCP보다 신뢰성이 낮기도 하고 흐름 제어도 안되지만, 이후 개발자가 어플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수도 있다는 것

 

QUIC 장점

 

클라이언트의 IP가 바뀌어도 연결이 유지됨

 

TCP의 경우 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어져 버린다.

 

연결이 끊어졌으니 다시 연결을 생성하기 위해 결국 눈물나는 3 Way Handshake 과정을 다시 거쳐야한다는 것이고, 이 과정에서 다시 레이턴시가 발생

 

게다가 요즘에는 모바일로 인터넷을 사용하는 경우가 많기 때문에 Wi-fi에서 셀룰러로 전환되거나 그 반대의 경우, 혹은 다른 Wi-fi로 연결되는 경우와 같이 클라이언트의 IP가 변경되는 일이 굉장히 잦아서 이 문제가 더 눈에 띈다.

 

반면 QUIC은 Connection ID를 사용하여 서버와 연결을 생성

 

Connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.

 

이는 새로 연결을 생성할 때 거쳐야하는 핸드쉐이크 과정을 생략할 수 있다는 의미이다.

 

연결 설정 시 레이턴시 감소

 

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

 

클라이언트가 서버에 어떤 신호를 한번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다는 것