2019년 10월 31일 목요일

QUIC 프로토콜

QUIC 프로토콜 요약

  • Google은 2014년도 부터 QUIC을 사용하고 있음
  • HTTPS를 대체하기 위한 UDP 기반의 암호화된 전송 프로토콜
  • QUIC은 이미 Chrome Browser에서 동작하고 있음
  • QUIC은 Web을 더 빠르게 만듦, 특히 느린 연결에서
  • QUIC의 주요 기능은 빠른 연결 맺기, 스트림 기반의 멀티플렉싱, 향상된 손실 보구, Head-of-line blocking 제거
  • QUIC은 모바일 환경에서 강점을 발휘함

HTTPS 보다 나은 점

  • 서비스가 레이턴시(latency)에 민감하다면 QUIC이 도움이 된다. 연결을 맺는 방법 때문에 그렇다.
  • Web client가 TCP + TLS 조합을 사용한다면, 서버와 클라이언트가 연결을 맺기 위해 2~3번의 라운드트립 데이터 전송이 필요하다.
  • QUIC을 사용하면 이러한 라운드트립(round trip)이 없어진다.
  • 얼마나 빨라질까? 
    • 구글 검색 같이 잘 만들어진 사이트는 미리 연결을 맺는다. 이것만 보면 QUIC의 빠른 연결 맺음의 잇점이 크게 드러나지 않는다. 하지만, QUIC을 사용하면 평균 페이지 로드 시간을 8% 감소 하고, 레이턴시가 높은(좋지 않은) 환경에서는 13% 이상의 시간 단축을 보였다.
  • 암호화는 QUIC 프로토콜의 기본적인 스펙이다. (AEAD알고리즘 : AES-GCM, ChaCha20 과 같은)
  • HTTP/2와 같이 QUIC은 하나의 연결로 여러 개의 스트림을 멀티플렉싱 할 수 있다.
  • HTTP/2는 하나의 커넥션으로 여러 HTTP 요청을 동시에 처리할 수 있다.
    • 하지만, TCP 연결을 사용하는 한 조금의 패킷이라도 손실이 된다면 전체 스트림이 블록킹 되는 현상이 발생하게 된다. 이 현상을 Head-of-line blocking 문제라고 부른다.
  • QUIC은 다르다. UDP Packet 의 손실은 여러 스트림 중 해당 패킷을 처리 하는 스트림에만 영향을 미친다. QUIC은 불안정한 네트워크 상황에서도 하나의 요청에서 발생한 문제가 다른 요청에 영향을 미치지 않는다.
  • QUIC은 Wifi <<>> Cellular 간 마이그레이션시에도 잘 동작하는 것을 기본 스펙으로 지향한다.

GCP Loadbalancer에서의 사용

  • 로드밸런서에만 QUIC protocol을 설정해주면 백엔드 서버는 기존 HTTP/1.1을 그대로 사용해도 무방하다.
  • 클라이언트의 경우에도 QUIC 프로토콜로 메시지 전송하지 않은 경우는 HTTPS로 처리한다.
  • Cronet(https://developer.android.com/guide/topics/connectivity/cronet/) 을 이용하면 클라이언트에서 사용이 가능하다.

읽어볼만한 자료

게시:
라벨: ,