HTTP/3은 하이퍼텍스트 전송 프로토콜의 세번째 버전이며, TCP에서 벗어나 성능과 보안 향상을 제공하는 새 전송 프로토콜 QUIC으로 이전하는 큰 변화를 시도하고 있습니다.
Cloudflare의 2019년 창립기념일 주간에 Cloudflare 엣지 네트워크에서 QUIC과 HTTP/3 지원을 시작 하였다는 뉴스를 발표한 바 있습니다. Google Chrome 과 Mozilla Firefox 라는 두 선도적인 브라우저 벤더와 파트너도 모두를 위해 웹을 빠르고 안전하게 하려는 우리의 노력에 참여 하였습니다. 새 표준을 개발하는데 큰 부분을 차지하는 것은 상호 운용성입니다. 여기에는 여러 사람들이 작성된 명세서를 분석, 구현 및 테스트하여 정확하고 명확하며 실제 구현 가능한지를 검증하게 됩니다.
당시 발표에서는 Chrome Canary가 실험적인 HTTP/3 지원을 하고 있었고 Firefox Nightly의 발표를 기다리고 있었습니다. 이제 Firefox가 HTTP/3 을 지원하므로, 이 기능을 설정하고 직접 테스트해 볼 수 있도록 하는 방법을 알려 드리고자 합니다.
내 사이트에 HTTP/3 을 설정하는 법
Cloudflare 대시보드에 가서 “Network” 탭에서 수동으로 설정할 필요가 있습니다.
Firefox Nightly를 HTTP/3 클라이언트로 사용하기
Firefox Nightly는 HTTP/3 을 실험적으로 지원하고 있습니다. 지금까지의 경험으로는 상당히 안정적이었습니다만 기술적인 문제가 있을 수 있으므로 HTTP/3 을 설정하고 실험하기 전에 미리 결정을 해 두시기 바랍니다. 결심 하셨다면 최신의 Firefox Nightly 빌드를 설치할 필요가 있습니다. 그리고 나서 Firefox 를 실행하여 “about:config” 페이지로 이동, “network.http.http3.enabled”를 true로 설정하여 HTTP/3 을 지원하도록 합니다. 다른 설정 가능한 파라미터들이 있습니다만 기본값으로 충분합니다.
about:config 에서 “http3” 검색어를 입력하여 검색 가능
HTTP/3 설정이 되었으면 여러분의 웹 사이트에 방문하여 테스트해 보도록 합시다. HTTP/3으로 통신하고 있는지 검사하는 쉬운 방법은 Developer Tools 를 실행하여 “Network” 탭의 “Protocol” 열을 보는 것입니다 (윈도와 리눅스의 Developer Tools 는 Ctrl+Shift+I 키보드 입력으로 바로 부를 수 있고, macOS에서는 Command+Option+I 입니다). 이 “Protocol” 열은 기본적으로 표시되고 있지 않을 수 있으므로 열 이름에서 오른쪽 클릭을 해서 다음과 같이 “Protocol” 이 체크되어 있는지 확인하기 바랍니다.
그리고 나서 페이지를 다시 읽어 “HTTP/3”이 표시되고 있는지 확인 합니다.
혹시 기술적인 문제가 있다면 HTTP/3 이 바로 보이지 않을 수도 있습니다. HTTP/3 을 사이트에 설정하는 경우 우리는 alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400 헤더를 해당 도메인의 모든 응답에 추가 합니다. 클라이언트는 이 내용을 보고 난 뒤 그 다음 요청시에 HTTP/3을 시도할 지 결정합니다. 따라서 페이지를 다시 읽어들여야 할 필요가 있으며 로컬 브라우저 캐시 (“Disable cache” 체크박스를 체크 하거나 Shift+F5를 눌러서)를 건너 뛰고 있는지도 확인해야 합니다. 그렇지 않으면 처음에 읽어들인 리소스에 사용된 프로토콜을 그대로 보게 될 수 있습니다. 마지막으로 Firefox는 “about:networking” 페이지에서 방문한 사이트 목록과 읽어들인 데 사용한 HTTP 버전을 볼 수 있습니다. 예를 들이 이 블로그의 경우는 다음과 같습니다.
about:networking에서 방문한 사이트의 목록과 사용된 연결 특성을 열람
종종 브라우저는 기존의 HTTP 연결을 그대로 사용하며 HTTP/3 연결을 새로 시도하지 않을 수 있습니다. 이유를 일반적으로 쉽게 알아내기 어려울 수 있으므로 제일 좋은 방법 중 하나는 어플리케이션을 종료시키고 다시 시작하는 것입니다. 마지막으로, 서비스 워커에서 네트워크를 통해 읽어들인 리소스가 HTTP/1.1을 사용하는 것으로 나타날 수 있는데 이건 실제로 로컬 서비스 워커의 캐시에서 읽어들인 것입니다. 이런 경우에 HTTP/3 이 사용되는 것 까지 보고 싶다면 서비스 워커 등록을 해지해야 할 수 있습니다. 네트워크에서 어떤 일이 일어 나는지 잘 알지 못한다면 독립적으로 검사해 보는 방법이 유용할 수 있는데, 가령 Wireshark로 패킷을 캡처 해서 분석해 보는 것입니다.
향후의 전망
QUIC 워킹 그룹은 개발중인 표준 안정성의 중요한 마일스톤 중 하나인 “워킹 그룹 최종 요청”을 발표하였습니다.
3년 반 이상의 실질적인 토론을 거친 후 QUIC 프로토콜 초안에 대한 845개의 모든 설계 이슈는 동의를 얻었거나 해결 방안을 찾았습니다. 이를 통해 프로토콜은 매우 크게 변화 하였습니다. 이제 더 안전하고 여러가지 구현이 존재하며 상호 운영 가능한 것이 입증 되었습니다. 의장과 편집자는 모두 표준화 단계에 들어갈 준비가 되었다고 생각 합니다.
향후 몇달간 명세서가 안정화되는 것을 지켜볼 것이며, 각 구현체가 QUIC과 HTTP/3 지원을 개선하는 것을 기대하며 최종적으로는 각 업체에서 안정 버전을 릴리즈할 것을 기대 합니다. 더 나은 인터넷을 같이 만들기 위해 Mozilla 와 같은 산업계 파트너와 같이 일하는 것을 기쁘게 생각 합니다.
시간이 있다면 우리의 가이드 문서를 통해서 Chrome Canary 나 curl 과 같은 다른 구현체도 시험해 보시기 바랍니다. 호환성을 확보함에 따라 구현체는 성능을 개선하는 방향으로 나아갈 것입니다. Cloudflare는 HTTP/3 과 HTTP/2를 비교하고 혼잡 제어 모듈에 CUBIC과 HyStart++을 추가하여 성능 개선 작업을 하는 등 자체적인 노력을 계속 하고 있습니다.