HTTP1.1, HTTP2 그리고 QUIC

 

✔️ HTTP란?

. Hyper Text Transfer Protocol의 준말로, 하이퍼 미디어 문서를 전송하기 위한 애플리케이션 레이어 프로토콜

. 하이퍼 미디어 문서? 웹상에서 돌아다니는 정보들

. Application 레이어는 최상층에 위치하고 있다.  

. 따라서 데이터를 주고 받기 위해서는, 아래의 하위 계층들을 다 지나갔다 와야한다.

 

➕ TCP vs. UDP

. TCP는 연결형 → 데이터를 주고 받기 전 연결을 확인하는 과정을 거친다(3 Way-Handshake).

. UDP는 비연결형 → 일단 데이터 보내고 받았으면 오케이!

 

 

---

 

✔️ HTTP 1.1

. 전송 계층 프로토콜 TCP를 사용

. http1.0의 문제를 해결하기 위해 출시

. http2.0의 출시 전까지 약 15년간 주로 사용됨

 

 

⚠️ HTTP/1.0의 문제점?

. 한 연결에 하나의 요청과 응답이 왔다갔다 한다. → html 연결 한번, 이미지 연결 한번, css 연결 한번... → 비효율!

 

 

📌 HTTP/1.1의 해결 방법?

. 지속적인 연결을 기본으로 채택 → 연결 한번에 html,이미지,css 한번에 받아버려!

. 파이프라이닝 도입 → 요청을 한번에 보내고, 응답도 차례로 한번에 받는다.

 

 

⚠️ HTTP/1.1의 여전한 문제점 2가지

① HOL Blocking

. 파이프라이닝으로 인해 발생하는 문제.

. TCP이기 때문에, 순서상으로 앞에서 지연이 발생하면 뒤쪽에 빠르게 처리할 수 있는 응답이 있음에도 불구하고, blocked 되었다가 처리된 후 이후 순서를 처리하는 현상 발생.

② 중복 헤더

. HTTP 헤더에는 중복되는 정보가 많은데, 계속 똑같이 보내주는 현상 발

 

 

---

✔️ HTTP/2.0

. 2015년 등장

① 바이너리 프레이밍

. HTTP/1.1은 텍스트로 왔다갔다 했으나, 2.0부터는 바이너리로 인코딩을 해서 처리속도 개선.

② 요청응답 Multiplexing

. 응답이 큰 경우 여러 개의 프레임으로 쪼개서, 멀티플렉싱이 가능해지도록 만들어서 HOL Blocking 을 해결.

➕부가설
A가 원래는 10의 크기만큼 있다고 가정, B와 C는 2의 크기만큼 있다고 가정
→ 1.0에서는 A가 10이 전부 전송될 때까지 B와 C는 대기
→ 2.0에서는 아래처럼 쪼개서 전송하기 때문에, 클라이언트 입장에서는 B와 C가 먼저 완료되고, 이 정보를 미리 처리할 수 있게 됨! (A1전송-B1전송-C1전송-A2전송-A3전송-C2전송-B2전송)
→ 이후 크기가 큰 A의 전송이 완료되면 그때 A를 처리!   

 

③ Compression Header 

.어떤 정보를 사전에 미리 받았는지 정적 테이블에 미리 캐싱을 해놓는다. → 필요하고 안 겹치는 정보만 빼서 전송. 거기다 허프만 코딩 이라는 방법을 통해 인코딩을 해서 그 크기를 더 줄여줌. (1.0에 비해 85% 감소)

 

 

⚠️ HTTP/2.0의 남은 고질병

. TCP에서 동작을 한다는 큰 문제점. (TCP의 데이터 요청 간 순서를 보장하기 위함 때문에 나타나는 병목 현상)

. TCP는 신뢰성을 중요시하는 프로토콜 방식이기 때문에, 마찬가지로 HOL Blocking 문제가 발생한다.

→ C가 유실 된 경우, 뒤쪽의 AACB 모두 지연된다.

. 즉, TCP 요청 자체를 병렬적으로 처리하는 것은 불가능한 것.

 

---

 

✔️ QUIC

. TCP 자체가 문제라 이건 HTTP로 해결 못한다고 생각 → 구글에서 전송계층 프로토콜을 새로 만듬 = QUIC

. QUIC는 UDP 위에서 동작하는 전송계층 프로토콜

 

📌 TCP HOL Blocking 해결 방법

. 요청별로 다른 스트림을 쓰도록 나누었다.

📌 그 외 지연 개선 방안

① TCP연결과 기존 HTTPS를 쓰기 위해 사용되던 TLS 연결을 한번에 합쳐버림.

 

② Connection ID 사용

. 기존 TCP는 IP와 포트 번호로 Client를 구분함 → 인터넷 권역이 바뀌면 IP/포트번호가 바뀌면서 연결 작업이 다시 진행된다.

. QUIC는 인터넷 권역이 변경되더라도, 이 패킷에 Connection ID를 헤더에 같이 실어서 보냄 → 이 정보로 불필요한 연결 작업을 최소화 한다. 또한 이 정보를 캐싱해서 다음 요청부터는 연결과정 없이 한번에 보낼 수 있도록 함.

 

 

📝QUIC의 순서 보장

. UDP 기반의 QUIC가 데이터 순서를 보장하는 방법은 스트림의 우선순위!

. QUIC는 독립된 스트림에 대해 0~256까지의 8비트 우선순위 값을 지정할 수 있다. 만약 먼저 전송해야하는 데이터에 대해서는 우선순위를 높게 설정하여 먼저 전송될 수 있도록 할 수 있다.

(ex. 용량이 큰 데이터는 우선순위를 낮게 설정하여 나중에 전송하도록 하거나, 빠른 렌더링이 필요한 이미지의 경우 텍스트파일보다 더 높은 우선순위를 부여하여 전송)

. 또한 QUIC 역시 패킷마다 일련번호가 부여되며, 수신자는 데이터 조각의 순서를 파악하고 데이터를 올바른 순서로 형성하는 것이 가능

📝 QUIC의 신뢰성 보장

. TCP의 Fast Retransmit 및 Selective Acknowledgement와 유사한 방식 사용

. 단패킷 손실 시 재전송하는 과정도 스트림마다 독립적으로 진행 → 다른 요청의 딜레이 없이 해당 스트림만 재전송하므로 TCP 대비 더욱 빠른 재전송 가능.

. 기존 패킷 손실을 감지하기 위한 RTO보다 더욱 빠르게 감지하는 TLD를 통해 손실 감지하도록 설계함.

RTO, TLD
기존 TCP는 Retransmission Timeout(RTO)라는 기능을 통해 패킷 손실을 감지하고 재전송 한다.
RTO는 일정 시간 동안 수신측으로부터 ACK를 받지 못하는 경우, 해당 패킷을 재전송하는 방식이다.

반면, QUIC는 Time Loss Detection(TLD) 기능을 사용한다. 일정 시간 동안 수신측으로부처 ACK신호를 받지 못한 경우, 해당 패킷을 재전송 하는 것을 기다리는 것이 아닌, 다른 패킷을 우선적으로 전송함으로써 패킷 손실을 회피한다.

RTO와 TLD의 가장 큰 차이는 속도이다. 재전송에서도 에러가 나는 경우를 포함한다면, RTO는 수백밀리초 이상의 시간이 소요되는 반면, TLD는 일반적으로 수십 밀리초 이하의 시간이 소요된다.

 

📝 QUIC 의 멀티플렉싱

QUIC 역시 한번의 연결에서 여러 데이터 스트림을 전송하는 것이 가능하다. 단 TCP와 달리 모든 스트림을 한 번에 전송하는 것이 아닌, 각각의 독립적인 스트림으로 분할하여 전송한다. 이를 통해 사전 요청에서 지연이 발생하더라도, 후위의 요청이 지연되는 문제가 없어지게 된다.

📝 QUIC 0-RTT (zero round trip time)

클라이언트가 이전에 연결한 적이 있는 서버에 다시 연결할 때, 인증과정을 생략하고 바로 데이터를 전송하는 것이 가능하며, 기존 TCP와 다르게 클라이언트-서버 연결과 TLS/SSL 을 따로따로 처리하는 것이 아닌 한번에 처리하는 것이 가능해졌다.

0-RTT의 경우 ticket 이라는 데이터를 사용한다. 기존 로그인 시 사용하는 Token의 개념과 유사하며, 클라이언트와 서버가 서로 교환한 대칭키를 포함하여, 보안 알고리즘과 유효기간이 포함된 티켓을 생성하여 지니게 된다. 만약 일정기한내 동일한 서버에 요청을 보내는 경우, ticket을 대신 확인함으로써 인증과정을 생략하는 것이 가능하다.

만약 티켓이 유효하지 않는 경우는 다시 TLS/SSL 인증을 수행하고 새로운 대칭키를 생성한 다음 다시 새로운 티켓을 발급한다.

📝 QUIC 0-RTT, 1-RTT, 2-RTT

연결 설정에 필요한 왕복시간을 의미한다.

0-RTT는 클라이언트가 이전에 연결한 적이 있는 서버에 재접속할 때 사용된다. 이 경우, 클라이언트는 저장된 티켓을 사용하여 서버에 데이터를 전송한다.

1-RTT는 QUIC의 기본 연결 설정 방식이다. 클라이언트와 서버 간에 1회의 왕복시간이 소요된다. 서버에 연결 요청을 보내고 서버가 이를 받아들이고 응답을 보내는 과정이 이루어진다.

2-RTT는 기존 TCP와 유사한 방식으로 연결설정을 수행한다. 클라이언트와 서버 간에 2회의 왕복시간이 소요된다. 클러이언트가 연결 요청을 보내고, 서버가 이를 받아들인 후, 클라이언트에게 응답을 보내는 과정이 이루어진다.

2-RTT의 경우 추가적인 보안 검증이 필요한 상황에서 사용된다. 대표적으로 0-RTT의 티켓 값이 유효하지 않는 경우가 있다. 또한 0-RTT 의 경우 보안상의 이유로 일부 프로토콜에서 사용이 제한되는 경우가 사용하는데, 이러한 경우 1-RTT 나 2-RTT를 사용한다.

일반적으로 3-way handshake 한번에 1-RTT 정도의 연결이 든다. 다만 QUIC은 암호화의 병렬 전송을 통해 연결 설정을 높이고, TCP 에 비해 여러번 연결설정이 이루어지지 않기 때문에, 대부분의 네트워크 환경에서 QUIC가 TCP보다 더욱 빠른 성능을 제공하는 것은 사실이다.

 

⚠️ QUIC 의 단점

대표적으로 호환성 문제가 있다. QUIC는 새로운 프로토콜이기에, 기존의 네트워크 인프라와의 호환성 문제가 발생할 수 있다. 특히 기존의 방화벽, 로드 밸런서, 프록시 서버 등의 네트워크 장비들이 QUIC 트래픽을 인식하고 처리하기 어려울 수 있다. 또한 기존 TCP 대비 문제 사례나 커뮤니티가 적어, 인프라 환경을 유지 보수하는 데 있어 복잡성이 증가할 수 있다.

또한 ticket의 사용이 문제가 될 수 있다. TLS/SSL 보다 빠른 연결 설정을 제공하나, ticket에 의한 보안 및 개인정보 문제가 발생할 수 있다. 이를 위한 ticket 자체에 추가적인 보안 설정을 하는 경우도 많다.

 

✨ 활용처

. google, youtube, facebook에서는 QUIC를 지원하고 있다.