HTTP/3

Rest API 설계 검색하다가, HTTP/3가 베타 중(?)이라는 소식에 정리해보는 페이지입니다. 

 

HTTP/3

HTTP/3 : HTTP(Hypertext Transfer Protocol)의 세번째 메이저 버전으로,
HTTP/1, HTTP/2 와 다르게 UDP 기반의 프로토콜(QUIC(Quick UDP Internet Connection))사용하여 통신하는 프로토콜

 

TCP(HTTP/1,2) vs UDP

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

TCP : 신뢰성이 높고 느리며 (느린 이유는 3 way Handshake를 사용하기 때문)

UDP : 신뢰성이 낮고 빠르다

 # 신뢰성 : 전송되는 데이터 패킷들의 순서, 패킷 유실 여부 등을 검사하여 송신 측이 보낸 모든 데이터가 수신 측에 온전하게 전달될 수 있느냐 ? 를 의미한다.

 

TCP는 클라-서버간의 통신에서 신뢰성을 가지기 위해 노력하지만 결국, 레이턴시가 발생할 수 밖에 없다.(TCP 표준)

 

레이턴시를 줄이기 위해서는 TCP 표준에서 벗어나는 부분을 조작해서 회선 대역폭을 늘린다 하여도 , 

전송해야하는 데이터의 크기도 점점 커지고 빛의 속도보다 빠르게 전송은 불가능하여 결국에는 한계에 도달하게 된다.

 

 

QUIC

TCP 의 레이턴시 한계를 극복하고자 구글이 개발한 UDP 기반의 프로토콜로 

TCP 핸드쉐이크 과정을 최적화하는 것에 초점을 두었다. 

 

UDP 는 데이터그램 방식의 프로토콜로 

각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용하며, 

패킷의 목적지만 정해져있다면 중간 경로는 무시하기 때문에 종단 간의 연결 설정이 필요없다. (= 핸드쉐이크가 없다)

 

그래서 왜 QUIC은 UDP를 선택했을까?

물론, TCP를 사용하다가 UDP로 바로 갈아탄다고 해도, 모든 이슈가 해결되지는 않지만 

UDP의 커스텀 기능 이용을 통한다면 기존 TCP가 가지고 있는 기능을 모두 구현할 수 있다.

UDP Header

 

데이터 전송 자체에만 초점이 맞추어 있기 때문에 출발지, 도착지, 패킷 길이, 체크섬(옵션) 만 존재(위 그림)

즉, 어떻게 개발자가 구현하냐에 따라
TCP와 비슷한 수준의 기능을 가질 수 있으며 핸드쉐이크를 사용하지 않을 수 있다는 의미와 같다. 

 

HTTP/3가 UDP를 사용하여, 기존 프로토콜보다 개선된 점 

 

1. 연결 설정 시 레이턴시 감소

클라이언트 보낸 요청 -> 서버 처리 -> 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라 하는데, 

위에서 설명한 내용과 같이 QUIC은 첫 연결 설정에서 1RTT만 소요된다. (아래 그림 참조)

TCP + TLS VS QUIC

즉, 클라이언트가 서버에 신호를 주고 서버에서 응답만 받으면 바로 본 통신이 가능하다는 말과 같다. 

첫번째 핸드쉐이크를 거칠 때
연결 설정에 필요한 정보(+(초키화 키(initial Key) 통해 통신 암호화)와 함께 데이터도 함께 보내기 때문에 가능한 일이다.
(TCP+TLS는 데이터 발송 전 신뢰성있는 연결, 암호화에 필요한 모든 정보를 교환하고 유효성 검사 후 데이터 교환)

 

2. 패킷 손실 감지에 걸리는 시간 단축

패킷 전송 -> 타임 아웃 -> 패킷 재전송 -> ACK 받음 의 통신을 진행하는데

이때 ACK가 어떤 패킷에서 온건지 확인하기 위해 QUIC는 헤더에 별도의 패킷 번호 공간을 부여하였다. 

해당 번호는 패킷의 전송 순서 자체만을 의미하고 매 전송마다 모노토믹하게 패킷 번호가 증가하기 때문에 패킷의 전송 순서를 명확하게 파악할 수 있다.

 

3. 멀티플렉싱 지원

여러 개의 스트림을 사용하여 그 중 특정 스트림의 패킷이 손실되었다고 하여도 해당 스트림에만 영향을 미치고 타 스트림에 영향을 주지않아 TCP의 단점인 HOLB(Head of Line Blocking)을 방지할 수 있다. (=HTTP/2와 동일)

 

4. 클라이언트 IP 변동되어도 연결 유지 

Connection ID를 사용하여 서버와 연결을 생성하는데, 

이때 Connection ID는 랜덤한 값일 뿐 클라이언트 IP와 전혀 무관하기 때문에 클라이언트 IP가 변경되어도 기존 연결을 지속적으로 유지할 수 있다. (=새롭게 연결을 생성할때 핸드쉐이크 과정을 생략할 수 있다는 말과 같다)

 

 

기존의 HTTP , TCP 방식에서 벗어날 용도로 쓸 수 있지만

grpc와 비교할 필요가 있을 것 같다 (비슷한 용도지 않나?)