HTTP/3: 실제 배포 옵션(3부)

안녕하세요. 새로운 HTTP/3 및 QUIC 프로토콜에 대한 3부작 시리즈의 마지막 기사에 오신 것을 환영합니다! 앞의 두 부분(HTTP/3 역사 및 핵심 개념, HTTP/3 성능 기능) 이후에 새 프로토콜을 사용하기 시작하는 것이 좋은 생각이라고 확신한다면(그리고 그렇게 해야 합니다!), 이 마지막 부분에는 모든 것이 포함됩니다. 시작하려면 알아야 합니다!

먼저 새로운 프로토콜을 최적으로 사용하기 위해 페이지와 리소스에 어떤 변경이 필요한지 논의할 것입니다(쉬운 부분입니다). 다음으로 서버와 클라이언트를 설정하는 방법을 살펴보겠습니다(콘텐츠 전송 네트워크(CDN)를 사용하지 않는 한 어려운 부분입니다). 마지막으로 새로운 프로토콜의 성능 영향을 평가하는 데 사용할 수 있는 도구를 살펴보겠습니다(적어도 현재로서는 거의 불가능한 부분입니다).

페이지 및 리소스 변경

좋은 소식부터 시작하겠습니다. 이미 HTTP/2를 사용 중이라면 HTTP/3으로 이동할 때 페이지나 리소스를 변경할 필요가 없을 것입니다! . 1부와 2부에서 설명했듯이 HTTP/3은 QUIC를 통한 HTTP/2와 더 비슷하고 두 버전의 고급 기능이 동일하게 유지되기 때문입니다. 따라서 HTTP/2에 대한 변경 또는 최적화는 HTTP/3에 대해 계속 작동하며 그 반대의 경우도 마찬가지입니다.

그러나 여전히 HTTP/1.1을 사용 중이거나 HTTP/2로의 전환을 잊었거나 실제로 HTTP/2에 대해 조정한 적이 없다면 이러한 변경 사항이 무엇이고 왜 필요한지 궁금할 수 있습니다. 그러나 오늘날에도 미묘한 모범 사례를 자세히 설명하는 좋은 기사를 찾기가 어려울 것입니다. 1부의 도입부에서 언급했듯이 초기 HTTP/2 콘텐츠의 대부분은 실제로 얼마나 잘 작동할 것인지에 대해 지나치게 낙관적이었고 일부는 솔직히 큰 실수와 잘못된 조언을 가지고 있기 때문입니다. 안타깝게도 이러한 잘못된 정보의 대부분은 오늘날에도 여전히 남아 있습니다. 이것이 HTTP/3에 대한 이 시리즈를 작성하는 주된 동기 중 하나입니다. 이러한 일이 다시는 발생하지 않도록 하는 것입니다.

현재 내가 추천할 수 있는 HTTP/2에 대한 최고의 올인원 뉘앙스 소스는 Barry Pollard의 책 HTTP/2 in Action 입니다. 그러나 그것은 유료 리소스이고 여기에서 추측하는 것을 원하지 않기 때문에 HTTP/3과 어떻게 관련되는지와 함께 아래에 몇 가지 주요 요점을 나열했습니다.

1. 단일 연결

HTTP/1.1과 HTTP/2의 가장 큰 차이점은 6개에서 30개의 병렬 TCP 연결을 단일 기본 TCP 연결로 전환한 것입니다. 우리는 2부에서 혼잡 제어가 어떻게 더 많은 연결로 더 많거나 더 일찍 패킷 손실을 일으킬 수 있기 때문에 단일 연결이 여전히 다중 연결만큼 빠를 수 있는지에 대해 약간 논의했습니다(집합된 더 빠른 시작의 이점을 취소함). HTTP/3는 이 접근 방식을 계속하지만 "그냥" 하나의 TCP에서 하나의 QUIC 연결로 전환합니다. 이 차이는 그 자체로 많은 것을 하지는 않지만(주로 서버 측의 오버헤드를 줄임) 다음과 같은 대부분의 사항으로 이어집니다.

2. 서버 샤딩 및 연결 병합

단일 연결 설정으로 전환하는 것은 실제로 많은 페이지가 다른 호스트 이름과 심지어 서버(예: img1.example.com 및 img2.example.com )에 걸쳐 분할되었기 때문에 상당히 어려웠습니다. 이는 브라우저가 각 개별 호스트 이름에 대해 최대 6개의 연결만 열었기 때문에 여러 연결이 더 많은 연결을 허용했기 때문입니다! 이 HTTP/1.1 설정을 변경하지 않으면 HTTP/2는 여전히 여러 연결을 열어 우선 순위 지정(아래 참조)과 같은 다른 기능이 실제로 작동할 수 있는 정도를 줄입니다.

따라서 원래 권장 사항은 서버 샤딩을 취소하고 가능한 한 단일 서버의 리소스를 통합하는 것이었습니다. HTTP/2는 연결 병합이라고 하는 HTTP/1.1 설정에서 더 쉽게 전환할 수 있는 기능도 제공했습니다. 대략적으로 말하자면, 두 호스트 이름이 동일한 서버 IP(DNS 사용)로 확인되고 유사한 TLS 인증서를 사용하는 경우 브라우저는 두 호스트 이름에서 단일 연결을 재사용할 수 있습니다 .

실제로 연결 병합은 예를 들어 CORS와 관련된 몇 가지 미묘한 보안 문제로 인해 올바르게 수행하기가 까다로울 수 있습니다. 올바르게 설정하더라도 두 개의 개별 연결로 쉽게 끝날 수 있습니다. 문제는 그것이 항상 나쁜 것은 아니라는 것입니다. 첫째, 잘못 구현된 우선 순위 및 다중화(아래 참조)로 인해 단일 연결이 둘 이상을 사용하는 것보다 쉽게 ​​느릴 수 있습니다. 둘째, 너무 많은 연결을 사용하면 경쟁 혼잡 컨트롤러로 인해 조기 패킷 손실이 발생할 수 있습니다. 그러나 몇 개만(여전히 하나 이상) 사용하면 특히 고속 네트워크에서 정체 증가와 더 나은 성능의 균형을 잘 맞출 수 있습니다. 이러한 이유로 HTTP/2를 사용하더라도 약간의 샤딩(예: 2~4개의 연결)이 여전히 좋은 아이디어 라고 생각합니다. 사실, 대부분의 최신 HTTP/2 설정은 여전히 ​​중요한 경로에 몇 가지 추가 연결이나 타사 로드가 있기 때문에 제대로 작동한다고 생각합니다.

3. 리소스 번들링 및 인라인

HTTP/1.1에서는 연결당 활성 리소스가 하나만 있을 수 있으므로 HTTP 수준 HoL(head-of-line) 차단이 발생합니다. 연결 수는 겨우 6~30개로 제한되었기 때문에 리소스 번들링(작은 하위 리소스가 하나의 큰 리소스로 결합되는 경우)은 오랫동안 모범 사례였습니다. 우리는 오늘날에도 Webpack과 같은 번들러에서 이것을 볼 수 있습니다. 마찬가지로 리소스는 다른 리소스에 인라인되는 경우가 많았습니다(예: 중요한 CSS가 HTML에 인라인됨).

그러나 HTTP/2를 사용하면 단일 연결이 리소스를 다중화하므로 파일에 대해 더 많은 미해결 요청이 있을 수 있습니다. 이것은 원래 " 더 이상 HTTP/2용 리소스를 번들하거나 인라인할 필요가 없습니다 "로 해석되었습니다. 이 접근 방식은 각 하위 리소스를 개별적으로 캐시할 수 있고 하위 리소스 중 하나가 변경되더라도 전체 번들을 다시 다운로드할 필요가 없기 때문에 세분화된 캐싱에 더 좋다고 선전했습니다. 이것은 사실이지만 상대적으로 제한된 범위에서만 가능합니다.

예를 들어 더 많은 데이터에서 더 잘 작동하기 때문에 압축 효율성을 줄일 수 있습니다. 또한 각 추가 요청이나 파일에는 브라우저와 서버에서 처리해야 하기 때문에 고유한 오버헤드가 있습니다. 이러한 비용은 몇 개의 큰 파일에 비해 수백 개의 작은 파일에 추가될 수 있습니다. 초기 테스트에서 약 40개 파일에서 심각하게 감소하는 수익을 발견했습니다. 지금은 그 수치가 조금 더 높을 수 있지만 파일 요청은 여전히 ​​HTTP/2에서 원래 예측한 만큼 저렴하지 않습니다 . 마지막으로 리소스를 인라인하지 않으면 파일을 요청해야 하기 때문에 대기 시간 비용이 추가됩니다. 이것은 우선 순위 지정 및 서버 푸시 문제(아래 참조)와 결합되어 오늘날에도 중요한 CSS 중 일부를 인라인하는 것이 더 낫다는 것을 의미합니다. 언젠가는 리소스 번들 제안이 도움이 될 수 있지만 아직까지는 아닙니다.

물론 이 모든 것은 HTTP/3에서도 여전히 유효합니다. 그래도 사람들이 많은 작은 파일이 QUIC보다 낫다고 주장하는 것을 읽었습니다. 왜냐하면 더 많은 동시 활성 독립 스트림이 HoL 차단 제거에서 더 많은 이익을 의미하기 때문입니다(2부에서 논의한 대로). 나는 이것에 약간의 진실이 있을 수 있다고 생각하지만, 우리가 2부에서도 보았듯이 이것은 많은 매개변수를 움직이는 매우 복잡한 문제입니다. 이점이 논의된 다른 비용보다 클 것이라고 생각하지 않지만 더 많은 연구가 필요합니다. (HoL 차단을 완전히 우회하여 단일 QUIC 패킷에 맞도록 각 파일의 크기를 정확히 맞추는 것은 터무니없는 생각입니다. 이 작업을 수행하는 리소스 번들러를 구현하는 모든 스타트업에서 로열티를 받을 것입니다. ;))

4. 우선순위

단일 연결에서 여러 파일을 다운로드할 수 있으려면 어떻게든 파일을 다중화해야 합니다. 2부에서 논의한 것처럼 HTTP/2에서 이 멀티플렉싱은 우선 순위 지정 시스템을 사용하여 조정됩니다. 이것이 바로 동일한 연결에서 가능한 한 많은 리소스를 요청하는 것이 중요한 이유입니다. 서로 간에 적절하게 우선 순위를 지정할 수 있습니다! 그러나 우리도 보았듯이 이 시스템은 매우 복잡 하여 실제로 자주 잘못 사용되거나 구현되었습니다(아래 이미지 참조). 이는 결과적으로 요청이 저렴하기 때문에 번들링 감소, 단일 연결을 최적으로 사용하기 위한 서버 샤딩 감소(위 참조)와 같은 HTTP/2에 대한 몇 가지 다른 권장 사항이 성능이 저하되었음을 의미합니다. 관행.

슬프게도 이것은 일반적인 웹 개발자인 당신이 별로 할 수 없는 일입니다. 왜냐하면 주로 브라우저와 서버 자체의 문제이기 때문입니다. 그러나 개별 파일을 너무 많이 사용하지 않고(경쟁 우선 순위에 대한 기회를 낮춤) 여전히 (제한된) 샤딩을 사용하여 문제를 완화할 수 있습니다. 또 다른 옵션은 지연 로딩, JavaScript async 및 defer 와 같은 우선 순위에 영향을 미치는 다양한 기술과 preload 와 같은 리소스 힌트를 사용하는 것입니다. 내부적으로 이들은 주로 리소스의 우선 순위를 변경하여 더 일찍 또는 나중에 보내도록 합니다. 그러나 이러한 메커니즘은 버그로 인해 어려움을 겪을 수 있습니다. 또한 많은 리소스에 preload 하여 작업 속도를 높일 것으로 기대하지 마십시오. 모든 것이 갑자기 높은 우선 순위가 되면 아무 것도 아닙니다! preload 와 같은 것을 사용하여 실제로 중요한 리소스를 지연시키는 것은 매우 쉽습니다.

2부에서도 설명했듯이 HTTP/3는 이 우선순위 시스템의 내부를 근본적으로 바꿉니다. 우리는 이것이 실제 배포에 더 적은 수의 버그와 문제가 있음을 의미하므로 적어도 이 중 일부는 해결되어야 합니다. 그러나 오늘날 이 시스템을 완전히 구현하는 HTTP/3 서버와 클라이언트가 거의 없기 때문에 아직 확신할 수 없습니다. 그럼에도 불구하고 우선 순위 지정의 기본 개념은 변경되지 않습니다 . 리소스의 우선 순위를 잘못 지정할 수 있기 때문에 내부적으로 어떤 일이 발생하는지 제대로 이해하지 않고는 preload 와 같은 기술을 사용할 수 없습니다.

5. 서버 푸시와 첫 비행

서버 푸시를 사용하면 서버가 먼저 클라이언트의 요청을 기다리지 않고 응답 데이터를 보낼 수 있습니다. 다시 말하지만, 이것은 이론상 훌륭하게 들리며 리소스를 인라인하는 대신 사용할 수 있습니다(위 참조). 그러나 2부에서 논의한 것처럼 푸시는 혼잡 제어, 캐싱, 우선 순위 지정 및 버퍼링 문제로 인해 올바르게 사용하기가 매우 어렵습니다. 전반적으로, 당신이 무엇을 하고 있는지 정말로 알지 못한다면 일반적인 웹 페이지 로딩에 사용하지 않는 것이 가장 좋습니다. 나는 여전히 (REST) ​​API가 있는 장소가 있을 수 있다고 생각합니다. 여기에서 준비된 연결에서 (JSON) 응답에 연결된 하위 리소스를 푸시할 수 있습니다. 이것은 HTTP/2와 HTTP/3 모두에 해당됩니다.

조금 일반화하기 위해 TCP + TLS 또는 QUIC를 통해 TLS 세션 재개 및 0-RTT에 대해 유사한 언급을 할 수 있다고 생각합니다. 2부에서 논의한 바와 같이 0-RTT는 페이지 로드의 첫 번째 단계를 가속화한다는 점에서 서버 푸시(일반적으로 사용됨)와 유사합니다. 그러나 이는 그 당시에 달성할 수 있는 것이 동등하게 제한됨 을 의미합니다(QUIC에서는 보안 문제로 인해 더욱 그렇습니다). 따라서 미세 최적화는 다시 말하지만 실제로 이점을 얻으려면 낮은 수준에서 미세 조정해야 하는 방법입니다. 그리고 한 때 서버 푸시를 0-RTT와 결합하려고 시도하게 되어 매우 기뻤습니다.

모든 것은 무엇을 의미합니까?

위의 모든 사항은 간단한 경험 법칙으로 귀결됩니다. 온라인에서 찾을 수 있는 일반적인 HTTP/2 권장 사항을 대부분 적용하되 극단적으로 사용하지 마십시오 .

다음은 HTTP/2 및 HTTP/3 모두에 대해 주로 유지되는 몇 가지 구체적인 사항입니다.

1. 필요한 경우 preconnect 및 dns-prefetch 를 사용하여 중요 경로에서 약 1~3개의 연결을 통해 리소스를 분할합니다(사용자가 대부분 저대역폭 네트워크에 있는 경우 제외).
2. 경로나 기능별로 또는 변경 빈도별로 하위 리소스를 논리적으로 묶습니다. 페이지당 5~10개의 JavaScript와 5~10개의 CSS 리소스가 적절해야 합니다. 중요한 CSS를 인라인하는 것은 여전히 ​​좋은 최적화가 될 수 있습니다.
3. preload 과 같은 복잡한 기능은 드물게 사용합니다.
4. HTTP/2 우선 순위를 적절하게 지원하는 서버를 사용하십시오. HTTP/2의 경우 H2O를 권장합니다. Apache와 NGINX는 대부분 괜찮지만(더 잘할 수 있지만) Node.js는 HTTP/2의 경우 피해야 합니다. HTTP/3의 경우 현재로서는 명확하지 않습니다(아래 참조).
5. HTTP/2 웹 서버에서 TLS 1.3이 활성화되어 있는지 확인하십시오.

보시다시피 HTTP/3(및 HTTP/2)에 대한 페이지 최적화는 단순하지 않지만 로켓 과학이 아닙니다. 그러나 더 어려운 것은 HTTP/3 서버, 클라이언트 및 도구를 올바르게 설정하는 것입니다.

서버 및 네트워크

지금쯤이면 이해하시겠지만 QUIC와 HTTP/3은 상당히 복잡한 프로토콜입니다. 그것들을 처음부터 구현하려면 7개 이상의 문서에 걸쳐 수백 페이지를 읽고 이해해야 합니다. 운 좋게도 여러 회사가 5년 넘게 오픈 소스 QUIC 및 HTTP/3 구현에 대해 작업하고 있으므로 선택할 수 있는 몇 가지 성숙하고 안정적인 옵션이 있습니다.

가장 중요하고 안정적인 것들은 다음과 같습니다.

그러나 이러한 구현의 많은(아마도 대부분)은 주로 HTTP/3 및 QUIC 항목을 처리합니다. 그것들은 그 자체로 완전한 웹 서버가 아닙니다 . 일반적인 서버(NGINX, Apache, Node.js)의 경우 몇 가지 이유로 인해 속도가 약간 느려졌습니다. 첫째, 처음부터 HTTP/3에 관여한 개발자는 거의 없었으며 이제는 따라잡아야 합니다. 많은 사람들이 위에 나열된 구현 중 하나를 내부적으로 라이브러리로 사용하여 이를 우회하지만 통합조차 어렵습니다.

둘째, 많은 서버가 OpenSSL과 같은 타사 TLS 라이브러리에 의존합니다. 다시 말하지만 TLS는 매우 복잡하고 안전해야 하므로 기존의 검증된 작업을 재사용하는 것이 가장 좋습니다. 그러나 QUIC는 TLS 1.3과 통합되지만 TLS 및 TCP가 상호 작용하는 방식과 매우 다른 방식으로 사용합니다 . 이는 TLS 라이브러리가 QUIC 관련 API를 제공해야 한다는 것을 의미합니다. 여기서 특히 문제는 QUIC 지원을 연기했지만 많은 서버에서 사용하는 OpenSSL입니다. 이 문제가 심각하여 Akamai는 quictls라는 OpenSSL의 QUIC 전용 포크를 시작하기로 결정했습니다. 다른 옵션과 해결 방법이 존재하지만 QUIC에 대한 TLS 1.3 지원은 여전히 ​​많은 서버의 차단기이며 한동안 그렇게 유지될 것으로 예상됩니다.

현재 HTTP/3 지원과 함께 즉시 사용할 수 있어야 하는 전체 웹 서버의 일부 목록은 다음과 같습니다.

• 아파치
  현재로서는 지원 여부가 불분명합니다. 발표된 사항이 없습니다. OpenSSL도 필요할 것입니다. (하지만 Apache Traffic Server 구현이 있다는 점에 유의하십시오.)
• NGINX
  이것은 사용자 정의 구현입니다. 이것은 비교적 새롭고 여전히 실험적입니다. 2021년 말까지 메인 라인 NGINX에 병합될 것으로 예상됩니다. 이것은 비교적 새롭고 여전히 실험적입니다. NGINX에서도 Cloudflare의 quiche 라이브러리를 실행하는 패치가 있으며 현재로서는 더 안정적일 것입니다.
• 노드.js
  이것은 내부적으로 ngtcp2 라이브러리를 사용합니다. OpenSSL 진행에 의해 차단되지만 더 빨리 작동하도록 QUIC-TLS 포크로 전환할 계획입니다.
• IIS
  현재로서는 지원 여부가 불분명하며 발표된 바가 없습니다. 그러나 내부적으로 MsQuic 라이브러리를 사용할 가능성이 높습니다.
• 하이퍼콘
  이것은 실험적 지원과 함께 aioquic을 통합합니다.
• 캐디
  이것은 완전한 지원과 함께 빠른 이동을 사용합니다.
• H2O
  이것은 전폭적인 지원으로 신속하게 사용됩니다.
• 라이트스피드
  이것은 완전한 지원과 함께 LSQUIC를 사용합니다.

몇 가지 중요한 뉘앙스에 유의하십시오.

• "완전한 지원"이라 하더라도 "생산 준비 상태"가 아닌 "현재 상태의 좋은 상태"를 의미합니다. 예를 들어, 많은 구현이 아직 연결 마이그레이션, 0-RTT, 서버 푸시 또는 HTTP/3 우선 순위를 완전히 지원하지 않습니다 .
• Tomcat과 같이 나열되지 않은 다른 서버는 (내가 아는 한) 아직 발표하지 않았습니다.
• 나열된 웹 서버 중 Litespeed, Cloudflare의 NGINX 패치 및 H2O만 QUIC 및 HTTP/3 표준화에 밀접하게 관련된 사람들이 만든 것이므로 초기에 가장 잘 작동할 가능성이 높습니다.
  

보시다시피 서버 환경은 아직 완전히 존재하지 않지만 HTTP/3 서버를 설정하기 위한 옵션은 이미 있습니다. 그러나 단순히 서버를 실행하는 것은 첫 번째 단계일 뿐입니다. 이를 구성하고 나머지 네트워크를 구성하는 것은 더 어렵습니다.

네트워크 구성

1부에서 설명했듯이 QUIC는 UDP 프로토콜 위에서 실행되어 배포가 더 쉽습니다. 그러나 이것은 주로 대부분의 네트워크 장치가 UDP를 구문 분석하고 이해할 수 있음을 의미합니다. 슬프게도 UDP가 보편적으로 허용된다는 의미는 아닙니다 . UDP는 종종 공격에 사용되며 DNS 외에 일상적인 작업에 중요하지 않기 때문에 많은(기업) 네트워크와 방화벽이 프로토콜을 거의 완전히 차단합니다. 따라서 UDP는 HTTP/3 서버에서 명시적으로 허용되어야 합니다 . QUIC는 모든 UDP 포트에서 실행할 수 있지만 포트 443(일반적으로 TCP를 통한 HTTPS에도 사용됨)이 가장 일반적일 것으로 예상합니다.

그러나 많은 네트워크 관리자는 UDP 도매를 허용하지 않을 것입니다. 대신, 그들은 특히 UDP를 통한 QUIC를 허용하기를 원할 것입니다. 문제는 우리가 보았듯이 QUIC가 거의 완전히 암호화되어 있다는 것입니다. 여기에는 패킷 번호와 같은 QUIC 수준 메타데이터는 물론 연결 종료를 나타내는 신호도 포함됩니다. TCP의 경우 방화벽은 이 모든 메타데이터를 능동적으로 추적하여 예상되는 동작을 확인합니다. (데이터를 전달하는 패킷 전에 완전한 핸드셰이크를 보았습니까? 패킷이 예상 패턴을 따르는가? 열린 연결이 몇 개 있습니까?) 1부에서 보았듯이 이것이 바로 TCP가 더 이상 실질적으로 진화할 수 없는 이유 중 하나입니다. 그러나 QUIC의 암호화로 인해 방화벽은 이러한 연결 수준 추적 논리를 훨씬 덜 수행 할 수 있으며 검사할 수 있는 몇 비트는 상대적으로 복잡합니다.

따라서 많은 방화벽 공급업체는 현재 소프트웨어를 업데이트할 수 있을 때까지 QUIC를 차단할 것을 권장합니다. 그러나 그 이후에도 방화벽 QUIC 지원은 항상 사용하던 TCP 기능보다 훨씬 적기 때문에 많은 회사에서 이를 허용하지 않을 수 있습니다.

연결 마이그레이션 기능으로 인해 이 모든 것이 훨씬 더 복잡합니다. 지금까지 살펴본 것처럼 이 기능을 사용하면 연결 ID(CID)를 사용하여 새로운 핸드셰이크를 수행할 필요 없이 새 IP 주소에서 연결을 계속할 수 있습니다. 그러나 방화벽에서는 악의적인 트래픽을 보내는 공격자가 먼저 핸드셰이크를 사용하지 않고 새 연결이 사용되는 것처럼 보일 수 있습니다. 방화벽은 사용자의 개인 정보를 보호하기 위해 시간이 지남에 따라 변경되기 때문에 QUIC CID만 사용할 수 없습니다! 따라서 서버가 CID가 필요한 방화벽과 통신 해야 할 필요가 있지만 이러한 항목은 아직 존재하지 않습니다.

대규모 설정을 위한 로드 밸런서에도 유사한 우려가 있습니다. 이러한 시스템은 많은 수의 백엔드 서버를 통해 들어오는 연결을 배포합니다. 물론 하나의 연결에 대한 트래픽은 항상 동일한 백엔드 서버로 라우팅되어야 합니다(다른 연결은 어떻게 해야 할지 모릅니다!). TCP의 경우 변경되지 않기 때문에 4-튜플을 기반으로 간단히 수행할 수 있습니다. 그러나 QUIC 연결 마이그레이션을 사용하면 더 이상 옵션이 아닙니다. 다시 말하지만, 서버와 로드 밸런서는 결정적 라우팅을 허용하기 위해 선택할 CID에 대해 어떻게든 동의해야 합니다 . 그러나 방화벽 구성과 달리 이를 설정하는 제안이 이미 있습니다(이는 널리 구현되지는 않았지만).

마지막으로, 주로 0-RTT 및 DDoS(분산 서비스 거부) 공격과 관련된 더 높은 수준의 보안 고려 사항이 있습니다. 2부에서 논의한 바와 같이 QUIC에는 이미 이러한 문제에 대한 몇 가지 완화 기능이 포함되어 있지만 이상적으로는 네트워크에서 추가 방어선도 사용합니다. 예를 들어 프록시 또는 에지 서버는 재생 공격을 방지하기 위해 특정 0-RTT 요청이 실제 백엔드에 도달하는 것을 차단할 수 있습니다. 또는 첫 번째 핸드셰이크 패킷만 보낸 다음 응답을 중지하는 반사 공격 또는 DDoS 공격(TCP에서는 SYN 플러드라고 함)을 방지하기 위해 QUIC에는 재시도 기능이 포함되어 있습니다. 이를 통해 서버는 그 동안 상태(TCP SYN 쿠키와 동일)를 유지할 필요 없이 클라이언트가 제대로 작동하는지 확인할 수 있습니다. 물론 이 재시도 프로세스는 백엔드 서버 이전의 어딘가(예: 로드 밸런서)에서 가장 잘 발생합니다. 다시 말하지만 설정하려면 추가 구성 및 통신이 필요합니다.

이는 네트워크 및 시스템 관리자가 QUIC 및 HTTP/3에 대해 갖게 될 가장 두드러진 문제일 뿐입니다. 몇 가지가 더 있는데 그 중 일부는 제가 이야기한 것입니다. 또한 이러한 문제와 가능한(부분적) 완화에 대해 논의하는 QUIC RFC에 대한 두 개의 별도 첨부 문서가 있습니다.

모든 것은 무엇을 의미합니까?

HTTP/3 및 QUIC는 많은 내부 기계에 의존하는 복잡한 프로토콜입니다. 백 엔드에 새 프로토콜을 배포할 수 있는 몇 가지 옵션이 이미 있지만 이 모든 것이 아직 황금기에 준비된 것은 아닙니다 . 그러나 가장 눈에 띄는 서버와 기본 라이브러리(예: OpenSSL)가 업데이트되려면 몇 개월에서 몇 년이 걸릴 것입니다.

그런 경우에도 프로토콜이 안전하고 최적의 방식으로 사용될 수 있도록 서버 및 기타 네트워크 중개자를 적절하게 구성하는 것은 대규모 설정에서 쉽지 않을 것입니다. 이러한 전환을 올바르게 수행하려면 우수한 개발 및 운영 팀이 필요합니다.

따라서 특히 초기 에는 대규모 호스팅 회사나 CDN에 의존 하여 프로토콜을 설정하고 구성하는 것이 가장 좋습니다. 2부에서 논의한 바와 같이 QUIC가 가장 큰 성과를 거둘 수 있는 부분이며 CDN을 사용하는 것은 수행할 수 있는 주요 성능 최적화 중 하나입니다. 저는 개인적으로 Cloudflare 또는 Fastly를 사용하는 것이 좋습니다. Cloudflare 또는 Fastly는 표준화 프로세스에 밀접하게 관련되어 있고 가장 발전되고 잘 조정된 구현을 사용할 수 있기 때문입니다.

클라이언트 및 QUIC 디스커버리

지금까지 우리는 새로운 프로토콜에 대한 서버 측 및 네트워크 내 지원을 고려했습니다. 그러나 클라이언트 측에서도 몇 가지 문제를 극복해야 합니다.

그것에 도달하기 전에 몇 가지 좋은 소식부터 시작하겠습니다. 대부분의 인기 있는 브라우저에는 이미 (실험적인) HTTP/3 지원이 있습니다! 특히, 작성 당시 지원 상태는 다음과 같습니다(caniuse.com 참조).

• Google 크롬(버전 91+) : 기본적으로 활성화되어 있습니다.
• Mozilla Firefox(버전 89+) : 기본적으로 활성화되어 있습니다.
• Microsoft Edge(버전 90+) : 기본적으로 활성화되어 있습니다(내부적으로 Chromium 사용).
• Opera(버전 77+) : 기본적으로 활성화되어 있습니다(내부적으로 Chromium 사용).
• Apple Safari(버전 14) : 수동 플래그 뒤에. 현재 기술 미리 보기에 있는 버전 15에서 기본적으로 활성화됩니다.
• 기타 브라우저 : 아직 내가 알고 있는 신호는 없습니다(Brave와 같이 내부적으로 Chromium을 사용하는 다른 브라우저에서도 이론적으로 활성화할 수 있음).

몇 가지 뉘앙스에 유의하십시오.

• 대부분의 브라우저는 점진적으로 출시되고 있으므로 모든 사용자가 처음부터 기본적으로 HTTP/3 지원을 사용하는 것은 아닙니다. 이는 간과된 단일 버그가 많은 사용자에게 영향을 미치거나 서버 배포에 과부하가 걸리는 위험을 제한하기 위해 수행됩니다. 따라서 최신 브라우저 버전에서도 기본적으로 HTTP/3을 얻지 못하고 수동으로 활성화해야 할 가능성이 적습니다.
• 서버와 마찬가지로 HTTP/3 지원이 모든 기능이 현재 구현되었거나 사용 중임을 의미하지는 않습니다. 특히, 0-RTT, 연결 마이그레이션, 서버 푸시, 동적 QPACK 헤더 압축 및 HTTP/3 우선 순위 지정이 여전히 누락되거나 비활성화되거나 드물게 사용되거나 잘못 구성될 수 있습니다.
• 브라우저 외부(예: 기본 앱)에서 클라이언트 측 HTTP/3을 사용하려면 위에 나열된 라이브러리 중 하나를 통합하거나 cURL을 사용해야 합니다. Apple은 곧 macOS 및 iOS의 내장 네트워킹 라이브러리에 기본 HTTP/3 및 QUIC 지원을 제공할 예정이며 Microsoft는 Windows 커널 및 .NET 환경에 QUIC를 추가하고 있지만 유사한 기본 지원은 (제가 아는 한) 제공되지 않았습니다. Android와 같은 다른 시스템용으로 발표되었습니다.

Alt-Svc

HTTP/3 호환 서버를 설정하고 업데이트된 브라우저를 사용 중이더라도 HTTP/3가 실제로 일관되게 사용되지 않는다는 사실에 놀랄 수 있습니다. 그 이유를 이해하기 위해 잠시 동안 귀하가 브라우저라고 가정해 보겠습니다. 사용자가 example.com (이전에 방문한 적이 없는 웹사이트)으로 이동하도록 요청했으며 DNS를 사용하여 이를 IP로 확인했습니다. 하나 이상의 QUIC 핸드셰이크 패킷을 해당 IP로 보냅니다. 이제 몇 가지 문제가 발생할 수 있습니다.

1. 서버가 QUIC를 지원하지 않을 수 있습니다.
2. 중간 네트워크 또는 방화벽 중 하나가 QUIC 및/또는 UDP를 완전히 차단할 수 있습니다.
3. 핸드셰이크 패킷은 전송 중에 손실될 수 있습니다.

그러나 이러한 문제 중 하나가 발생했는지 어떻게 알 수 있습니까? 세 가지 경우 모두 핸드셰이크 패킷에 대한 응답을 받지 못합니다. 당신이 할 수 있는 유일한 일은 응답이 올 수 있기를 바라며 기다리는 것뿐입니다. 그런 다음 약간의 대기 시간(시간 초과) 후에 HTTP/3에 실제로 문제가 있다고 결정할 수 있습니다. 이 시점에서 HTTP/2 또는 HTTP/1.1이 작동하기를 바라며 서버에 대한 TCP 연결을 열려고 시도합니다.

보시다시피, 이러한 유형의 접근 방식은 특히 많은 서버와 네트워크가 아직 QUIC를 지원하지 않는 초기 연도에 상당한 지연을 초래할 수 있습니다. 쉽지만 순진한 솔루션은 QUIC와 TCP 연결을 동시에 열고 먼저 핸드셰이크가 완료되는 것을 사용하는 것 입니다. 이 방법을 "연결 경주" 또는 "해피 안구"라고 합니다. 이것은 확실히 가능하지만 상당한 오버헤드가 있습니다. 끊어진 연결이 거의 즉시 닫히더라도 클라이언트와 서버(특히 TLS를 사용할 때) 모두에서 여전히 약간의 메모리와 CPU 시간을 차지합니다. 게다가 이 방법에는 IPv4 대 IPv6 네트워크와 이전에 논의된 재생 공격(내 이야기에서 더 자세히 설명함)과 관련된 다른 문제도 있습니다.

따라서 QUIC 및 HTTP/3의 경우 브라우저는 안전하게 플레이 하고 서버가 지원한다는 것을 알고 있는 경우에만 QUIC를 시도 하는 것을 선호합니다. 따라서 새 서버에 처음 접속할 때 브라우저는 TCP 연결을 통해 HTTP/2 또는 HTTP/1.1만 사용합니다. 그런 다음 서버는 브라우저에 후속 연결을 위해 HTTP/3도 지원함을 알릴 수 있습니다. 이것은 HTTP/2 또는 HTTP/1.1을 통해 다시 전송된 응답에 특수 HTTP 헤더를 설정하여 수행됩니다. 이 헤더를 Alt-Svc 라고 하며 "대체 서비스"를 나타냅니다. Alt-Svc 를 사용하여 특정 서비스가 다른 서버(IP 및/또는 포트)를 통해서도 도달할 수 있음을 브라우저에 알릴 수 있지만 대체 프로토콜을 표시할 수도 있습니다. 이것은 아래 그림 1에서 볼 수 있습니다.

HTTP/3 지원을 나타내는 유효한 Alt-Svc 헤더를 수신하면 브라우저는 이를 캐시 하고 그때부터 QUIC 연결 설정을 시도합니다. 일부 클라이언트는 가능한 한 빨리 이 작업을 수행하고(초기 페이지 로드 중에도 — 아래 참조), 다른 클라이언트는 기존 TCP 연결이 닫힐 때까지 대기합니다. 이것은 브라우저 가 HTTP/2 또는 HTTP/1.1을 통해 최소한 몇 가지 리소스를 먼저 다운로드한 후에만 HTTP/3을 사용 한다는 것을 의미합니다. 그렇다고 해도 순탄치만은 않다. 브라우저는 이제 서버가 HTTP/3을 지원한다는 것을 알고 있지만 중간 네트워크가 이를 차단하지 않는다는 의미는 아닙니다. 이처럼 연결 경주는 여전히 실전에서 필요하다. 따라서 네트워크가 QUIC 핸드셰이크를 충분히 지연시키는 경우 여전히 HTTP/2로 끝날 수 있습니다. 또한 QUIC 연결이 몇 번 연속으로 설정되지 않으면 일부 브라우저는 잠시 동안 HTTP/3를 시도하지 않고 Alt-Svc 캐시 항목을 잠시 거부 목록에 넣습니다. 따라서 Alt-Svc 바인딩도 비워야 하기 때문에 문제가 발생하는 경우 브라우저 캐시를 수동으로 지우는 것이 도움이 될 수 있습니다. 마지막으로 Alt-Svc 는 몇 가지 심각한 보안 위험을 내포하는 것으로 나타났습니다. 이러한 이유로 일부 브라우저는 예를 들어 어떤 포트를 사용할 수 있는지에 대한 추가 제한을 가합니다(Chrome에서 HTTP/2 및 HTTP/3 서버는 둘 다 1024 미만의 포트에 있거나 둘 다 이상의 포트에 있어야 합니다. 1024로 변경하지 않으면 Alt-Svc 가 무시됨). 이 모든 논리는 브라우저마다 다양하고 크게 발전하므로 일관된 HTTP/3 연결을 얻는 것이 어려울 수 있으며 새로운 설정을 테스트하는 것도 어렵습니다.

이 2단계 Alt-Svc 프로세스를 다소 개선하기 위한 작업이 진행 중입니다. 아이디어는 Alt-Svc 에 있는 것과 유사한 정보를 포함하는 SVCB 및 HTTPS라는 새 DNS 레코드를 사용하는 것입니다. 따라서 클라이언트는 DNS 확인 단계에서 서버가 대신 HTTP/3을 지원한다는 것을 발견할 수 있습니다. 즉, 먼저 HTTP/2 또는 HTTP/1.1을 거치지 않고 첫 페이지 로드부터 QUIC를 시도할 수 있습니다. 이것과 Alt-Svc 에 대한 자세한 정보는 HTTP/2에 대한 작년의 Web Almanac 장을 참조하십시오.

보시다시피 Alt-Svc 및 HTTP/3 검색 프로세스는 다음과 같은 이유로 이미 까다로운 QUIC 서버 배포에 복잡성 계층을 추가합니다.

• 항상 HTTP/2 및/또는 HTTP/1.1 서버 옆에 HTTP/3 서버를 배포해야 합니다.
• 응답에 올바른 Alt-Svc 헤더를 설정하도록 HTTP/2 및 HTTP/1.1 서버를 구성해야 합니다.

프로덕션 수준 설정에서 관리할 수 있어야 하지만(예를 들어 단일 Apache 또는 NGINX 인스턴스가 동시에 세 가지 HTTP 버전을 모두 지원할 가능성이 높기 때문에 ) (로컬) 테스트 세트에서는 훨씬 더 성가실 수 있습니다. ups (나는 이미 Alt-Svc 헤더를 추가하거나 엉망으로 만드는 것을 잊어 버린 내 자신을 볼 수 있습니다). 이 문제는 (현재) 브라우저 오류 로그 및 DevTools 표시기가 부족하여 더 복잡해집니다. 즉, 설정이 정확히 작동하지 않는 이유를 파악하기 어려울 수 있습니다.

추가 문제

그것으로 충분하지 않은 것처럼 또 다른 문제가 로컬 테스트를 더 어렵게 만들 것입니다. Chrome은 QUIC에 자체 서명된 TLS 인증서를 사용하는 것을 매우 어렵게 만듭니다 . 이는 회사에서 비공식 TLS 인증서를 사용하여 직원의 TLS 트래픽을 해독하는 경우가 많기 때문입니다(예: 방화벽이 암호화된 트래픽 내부를 스캔하도록 할 수 있음). 그러나 회사가 QUIC로 이를 시작한다면 프로토콜에 대해 자체적으로 가정하는 맞춤형 미들박스 구현을 다시 갖게 될 것입니다. 이로 인해 향후 프로토콜 지원이 중단될 수 있습니다. 이는 처음부터 QUIC를 광범위하게 암호화하여 방지하려고 했던 것과 정확히 일치합니다! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

모든 것은 무엇을 의미합니까?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Google Lighthouse

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog 및 qvis

위의 논의에서 알 수 있듯이 이 시점에서 Lighthouse 또는 WebPageTest를 사용하여 HTTP/3 동작을 분석하는 것은 까다로울 수 있습니다. 운 좋게도 다른 저수준 도구를 사용할 수 있습니다. 첫째, 우수한 Wireshark 도구는 QUIC에 대한 고급 지원을 제공하며 HTTP/3도 실험적으로 분석할 수 있습니다. 이를 통해 실제로 유선을 통해 이동하는 QUIC 및 HTTP/3 패킷을 관찰할 수 있습니다. 그러나 이것이 작동하려면 주어진 연결에 대한 TLS 암호 해독 키를 가져와야 합니다. 대부분의 구현(Chrome 및 Firefox 포함)에서 SSLKEYLOGFILE 환경 변수를 사용하여 추출할 수 있습니다. 이것은 어떤 경우에는 유용할 수 있지만 특히 더 긴 연결의 경우 무슨 일이 일어나고 있는지 실제로 파악하려면 많은 수동 작업이 필요할 수 있습니다. 또한 프로토콜의 내부 작동에 대한 고급 이해가 필요합니다.

운 좋게도 두 번째 옵션인 qlog 및 qvis가 있습니다. qlog는 대부분의 QUIC 구현에서 지원하는 QUIC 및 HTTP/3용 JSON 기반 로깅 형식입니다. 유선을 통해 이동하는 패킷을 보는 대신 qlog는 클라이언트와 서버에서 이 정보를 직접 캡처하여 일부 추가 정보(예: 혼잡 제어 세부 정보)를 포함할 수 있습니다. 일반적으로 QLOGDIR 환경 변수를 사용하여 서버와 클라이언트를 시작할 때 qlog 출력을 트리거할 수 있습니다. (Firefox에서는 network.http.http3.enable_qlog 기본 설정을 지정해야 합니다. Apple 장치와 Safari는 대신 QUIC_LOG_DIRECTORY 를 사용합니다. Chrome은 아직 qlog를 지원하지 않습니다.)

그런 다음 이러한 qlog 파일을 qvis.quictools.info의 qvis 도구 모음에 업로드할 수 있습니다. 여기에서 QUIC 및 HTTP/3 트래픽을 더 쉽게 해석할 수 있는 여러 고급 대화형 시각화를 얻을 수 있습니다. qvis는 또한 Wireshark 패킷 캡처( .pcap 파일) 업로드를 지원하며 Chrome의 넷로그 파일에 대한 실험적인 지원을 제공하므로 Chrome의 동작을 분석할 수도 있습니다. qlog 및 qvis에 대한 전체 자습서는 이 기사의 범위를 벗어납니다. 그러나 더 자세한 내용은 자습서 형식, 논문 및 토크쇼 형식에서도 찾을 수 있습니다. 내가 qlog 및 qvis의 주요 구현자이기 때문에 그들에 대해 직접 물어볼 수도 있습니다. ;)

그러나 여기 있는 대부분의 독자가 Wireshark 또는 qvis를 사용해야 한다는 환상은 없습니다. 이러한 도구는 매우 낮은 수준의 도구이기 때문입니다. 그러나 현재로서는 대안이 거의 없으므로 이러한 유형의 도구를 사용하지 않고 HTTP/3 성능을 광범위하게 테스트하지 않는 것이 좋습니다. 이를 통해 유선에서 무슨 일이 일어나고 있는지, 보고 있는 내용이 실제로 다음으로 설명되는지 여부를 확실히 알 수 있습니다. 다른 요인이 아닌 프로토콜의 내부.

모든 것은 무엇을 의미합니까?

지금까지 살펴본 것처럼 QUIC를 통한 HTTP/3 설정 및 사용은 복잡한 일이 될 수 있으며 많은 일이 잘못될 수 있습니다. 안타깝게도 적절한 추상화 수준에서 필요한 세부 정보를 노출하는 좋은 도구나 시각화를 사용할 수 없습니다. 이로 인해 대부분의 개발자는 현재 HTTP/3이 웹사이트에 가져올 수 있는 잠재적 이점을 평가하거나 설정이 예상대로 작동하는지 확인하기가 매우 어렵 습니다.

높은 수준의 메트릭에만 의존하는 것은 많은 요인(예: 비현실적인 네트워크 에뮬레이션, 클라이언트 또는 서버의 기능 부족, 부분적인 HTTP/3 사용 등)으로 인해 왜곡될 수 있기 때문에 매우 위험합니다. 2부에서 보았듯이 모든 것이 더 잘 작동하더라도 HTTP/2와 HTTP/3의 차이는 대부분의 경우 상대적으로 작기 때문에 상위 수준에서 필요한 정보를 얻는 것이 훨씬 더 어렵습니다. 대상 HTTP/3 지원이 없는 도구.

따라서 HTTP/2 대 HTTP/3 성능 측정을 몇 달 더 방치하고 대신 서버 측 설정이 예상대로 작동하는지 확인하는 데 집중하는 것이 좋습니다 . 이를 위해 WebPageTest를 Google 크롬의 명령줄 매개변수와 함께 사용하는 것이 가장 쉽고 잠재적인 문제에 대한 컬백(fallback)이 있습니다. 이것은 현재 내가 찾을 수 있는 가장 일관된 설정입니다.

결론 및 시사점

독자 여러분, 3부작으로 구성된 전체 시리즈를 읽고 여기까지 왔다면 경의를 표합니다 ! 몇 섹션만 읽었더라도 이 새롭고 흥미로운 프로토콜에 관심을 가져주셔서 감사합니다. 이제 이 시리즈의 주요 내용을 요약하고 향후 몇 개월 및 연도에 대한 몇 가지 주요 권장 사항을 제공하고 마지막으로 추가 리소스를 제공할 것입니다.

요약

먼저, 1부에서 우리 는 주로 새로운 기본 QUIC 전송 프로토콜 때문에 HTTP/3가 필요하다고 논의했습니다. QUIC는 TCP의 영적 계승자이며 모든 모범 사례와 TLS 1.3을 통합합니다. TCP는 유비쿼터스 배포 및 미들박스 통합으로 인해 너무 유연해져서 진화할 수 없었기 때문에 이것이 주로 필요했습니다. QUIC의 UDP 사용 및 거의 완전한 암호화는 우리가 (희망적으로) 새로운 기능을 추가하기 위해 향후 엔드포인트를 업데이트해야 한다는 것을 의미하며, 이는 더 쉬워야 합니다. 그러나 QUIC에는 몇 가지 흥미로운 새 기능도 추가되었습니다. 첫째, QUIC의 결합된 전송 및 암호화 핸드셰이크는 TCP + TLS보다 빠르며 0-RTT 기능을 잘 활용할 수 있습니다. 둘째, QUIC는 여러 개의 독립적인 바이트 스트림을 전달하고 손실 및 지연을 처리하는 방법에 대해 더 똑똑할 수 있다는 것을 알고 헤드 오브 라인 차단 문제를 완화합니다. 셋째, QUIC 연결은 연결 ID로 각 패킷에 태그를 지정하여 사용자가 다른 네트워크로 이동하는 동안 살아남을 수 있습니다(연결 마이그레이션이라고 함). 마지막으로, QUIC의 유연한 패킷 구조(프레임 사용)는 더 효율적이면서도 미래에 더 유연하고 확장 가능합니다. 결론적으로 QUIC는 차세대 전송 프로토콜이며 앞으로 수년 동안 사용되고 확장될 것이 분명합니다.

두 번째로, 2부 에서는 이러한 새로운 기능, 특히 성능에 미치는 영향에 대해 조금 비판적으로 살펴보았습니다 . 첫째, QUIC가 네트워크 과부하를 방지하기 위해 TCP와 매우 유사한 혼잡 제어 메커니즘을 사용하기 때문에 QUIC의 UDP 사용이 마술처럼 빨라지거나 느려지지 않는다는 것을 알았습니다. 둘째, 더 빠른 핸드셰이크와 0-RTT는 최적화된 TCP + TLS 스택보다 실제로 한 번만 더 빠르게 왕복할 수 있고 QUIC의 진정한 0-RTT는 다음을 제한할 수 있는 다양한 보안 문제의 영향을 받습니다. 그 유용성. 셋째, 연결 마이그레이션은 실제로 몇 가지 특정 경우에만 필요하며 정체 제어가 새 네트워크에서 처리할 수 있는 데이터의 양을 알지 못하기 때문에 전송 속도를 재설정해야 합니다. 넷째, QUIC의 head-of-line 차단 제거의 효율성은 스트림 데이터가 어떻게 다중화되고 우선 순위가 지정되는지에 따라 크게 달라집니다. 더 많은 연구가 필요하지만 패킷 손실로부터 복구하는 데 최적의 접근 방식은 웹 페이지 로딩 성능의 일반적인 사용 사례에 해로운 것처럼 보이며 그 반대의 경우도 마찬가지입니다. 다섯째, UDP API가 덜 성숙하고 QUIC가 각 패킷을 개별적으로 암호화하기 때문에 QUIC는 TCP + TLS보다 패킷 전송 속도가 느릴 수 있지만 시간이 지나면 크게 완화될 수 있습니다. 여섯째, HTTP/3 자체는 실제로 테이블에 새로운 주요 성능 기능을 제공하지 않지만 주로 알려진 HTTP/2 기능의 내부를 재작업하고 단순화합니다. 마지막으로 QUIC에서 허용하는 가장 흥미로운 성능 관련 기능(다중 경로, 신뢰할 수 없는 데이터, WebTransport, 순방향 오류 수정 등)은 핵심 QUIC 및 HTTP/3 표준의 일부가 아니라 제안된 확장입니다. 사용 가능한 시간이 더 있습니다. 결론적으로 이것은 QUIC가 고속 네트워크의 사용자에게는 성능을 크게 향상시키지 않을 것이지만 주로 느리고 덜 안정적인 네트워크의 사용자에게는 중요하다는 것을 의미합니다 .

마지막으로 이 3부에서는 QUIC 및 HTTP/3을 실제로 사용하고 배포하는 방법을 살펴보았습니다. 첫째, HTTP/2에서 배운 대부분의 모범 사례와 교훈이 HTTP/3에도 적용되어야 한다는 것을 알았습니다. 번들링 또는 인라인 전략을 변경하거나 서버 팜을 통합하거나 분할할 필요가 없습니다. 서버 푸시는 여전히 사용하기에 가장 좋은 기능은 아니며 preload 도 마찬가지로 강력한 풋건이 될 수 있습니다. 둘째, 기성 웹 서버 패키지가 완전한 HTTP/3 지원(부분적으로 TLS 라이브러리 지원 문제로 인해)을 제공하기까지 시간이 걸릴 수 있다는 점에 대해 논의했지만 얼리 어답터 및 여러 주요 CDN에는 성숙한 제품이 있습니다. 셋째, 대부분의 주요 브라우저는 기본적으로 활성화되어 있어도 (기본) HTTP/3 지원을 가지고 있습니다. 그러나 HTTP/3와 그 새로운 기능을 실제로 사용하는 방법과 시기에 큰 차이가 있으므로 동작을 이해하는 것이 어려울 수 있습니다. 넷째, Lighthouse 및 WebPageTest와 같은 널리 사용되는 도구에서 명시적인 HTTP/3 지원이 부족하여 이 문제가 악화되어 현재로서는 HTTP/3 성능을 HTTP/2 및 HTTP/1.1과 비교하기가 특히 어렵다는 점에 대해 논의했습니다. 결론적으로 HTTP/3 및 QUIC는 아직 황금 시간대에 준비되지 않았지만 곧 .

권장 사항

위의 요약에서 내가 QUIC 또는 HTTP/3 사용에 대해 강력한 주장을 하는 것처럼 보일 수 있습니다. 그러나 그것은 내가 말하고 싶은 요점과 정반대입니다.

첫째, 2부 끝에서 논의한 바와 같이, "보통" 사용자가 주요 성능 향상을 경험하지 못할 수도 있지만(목표 시장에 따라 다름), 청중의 상당 부분은 인상적인 개선을 보게 될 것 입니다. 0-RTT는 단일 왕복만 저장할 수 있지만 일부 사용자에게는 여전히 수백 밀리초가 소요될 수 있습니다. 연결 마이그레이션은 지속적으로 빠른 다운로드를 유지하지 못할 수 있지만 고속 열차에서 해당 PDF를 가져오려는 사람들에게는 확실히 도움이 될 것입니다. 케이블의 패킷 손실은 폭발적일 수 있지만 무선 링크는 QUIC의 HOL(head-of-line) 차단 제거를 통해 더 많은 이점을 얻을 수 있습니다. 더욱이 이러한 사용자는 일반적으로 제품의 최악의 성능을 경험하고 결과적으로 가장 큰 영향을 받는 사람들입니다. 그것이 왜 중요한지 궁금하다면 Chris Zacharias의 유명한 웹 성능 일화를 읽어보십시오.

둘째, QUIC 및 HTTP/3은 시간이 지남에 따라 점점 더 빨라질 것 입니다. 버전 1은 기본 프로토콜을 완료하는 데 중점을 두어 나중을 위해 고급 성능 기능을 유지합니다. 따라서 지금 프로토콜에 대한 투자를 시작하여 프로토콜과 새로운 기능을 사용할 수 있게 되었을 때 최적의 효과를 낼 수 있도록 하는 것이 좋습니다. 프로토콜의 복잡성과 배포 측면을 감안할 때 프로토콜의 단점에 대해 알 수 있는 시간을 갖는 것이 좋습니다. 아직 손을 더럽히고 싶지 않더라도 여러 주요 CDN 제공업체는 성숙한 "플립 스위치" HTTP/3 지원(특히 Cloudflare 및 Fastly)을 제공합니다. 나는 당신이 CDN을 사용하고 있다면 그것을 시도하지 않을 이유를 찾기 위해 고군분투합니다(성능에 관심이 있다면 정말로 그래야 합니다).

따라서 가능한 한 빨리 QUIC 및 HTTP/3 사용을 시작하는 것이 중요 하다고 말하지는 않겠지 만 이미 얻을 수 있는 이점이 많이 있으며 앞으로 더 늘어날 것 입니다.

추가 읽기

이것은 긴 본문이었지만 슬프게도 실제로는 QUIC 및 HTTP/3과 같은 복잡한 프로토콜의 기술적 표면만 긁는 것입니다.

아래에서 지속적인 학습을 위한 추가 리소스 목록을 기술적 깊이가 높은 순서대로 찾을 수 있습니다.

• "HTTP/3 설명", 다니엘 스텐버그
  cURL의 작성자가 작성한 이 전자책에는 프로토콜이 요약되어 있습니다.
• "실행 중인 HTTP/2", Barry Pollard
  HTTP/2에 대한 이 훌륭한 종합 책에는 재사용 가능한 조언과 HTTP/3에 대한 섹션이 있습니다.
• @programmingart, 트위터
  내 트윗은 일반적으로 QUIC, HTTP/3 및 웹 성능(뉴스 포함)에 주로 사용됩니다. 예를 들어 QUIC 기능에 대한 최근 스레드를 참조하십시오.
• "유튜브", 로빈 막스
  10개 이상의 심층 강연에서 프로토콜의 다양한 측면을 다룹니다.
• "Cloudlare 블로그"
  CDN도 사이드로 운영하는 회사의 주력 제품입니다.
• "빠르게 블로그"
  이 블로그에는 더 넓은 맥락에 포함된 기술적인 측면에 대한 훌륭한 토론이 있습니다.
• QUIC, 실제 RFC
  IETF QUIC 및 HTTP/3 RFC 문서 및 기타 공식 확장에 대한 링크를 찾을 수 있습니다.
• IIJ 엔지니어 블로그: QUIC 기능 세부 정보에 대한 훌륭한 심층 기술 설명입니다.
• HTTP/3 및 QUIC 학술 논문, Robin Marx
  내 연구 논문은 스트림 다중화 및 우선 순위 지정, 도구 및 구현 차이점을 다룹니다.
• QUIPS, EPIQ 2018 및 EPIQ 2020
  학술 워크숍의 이 문서에는 프로토콜의 보안, 성능 및 확장에 대한 심층 연구 내용이 포함되어 있습니다.

이를 통해 독자 여러분께 이 멋진 신세계에 대한 이해가 크게 향상되기를 바랍니다. 나는 항상 피드백에 열려 있으므로 이 시리즈에 대해 어떻게 생각하는지 알려주세요!