성능 및 효율성: HTTP/3 작업

HTTP/3는 HTTP/2에 뒤이어 뜨거운 관심을 받고 있으며, 아직 그 자체가 매우 젊습니다. HTTP/1.1에서 HTTP/2로 이동하는 데 16년이 걸렸다는 점을 감안할 때 HTTP/3에 대해 정말로 관심을 가져야 하는 사람이 있을까요?

짧은 대답: 예, 중요하며 이에 대한 속도를 높여야 합니다. HTTP/2가 ASCII에서 바이너리로 전환하여 HTTP/1.1에서 중요한 변경을 한 것과 같습니다. HTTP/3는 이번에도 기본 전송을 TCP에서 UDP로 전환하여 중요한 변경을 수행합니다.

HTTP/3는 아직 공식 사양이 초안인 설계 단계에 있지만 이미 배포 중이며 오늘 네트워크에서 실행 중인 버전을 찾을 수 있는 좋은 기회가 있습니다.

그러나 HTTP/3이 작동하는 방식에 의해 제기되는 몇 가지 새로운 딜레마가 있습니다. 또한, 이점은 무엇입니까? 그리고 네트워크 엔지니어, 시스템 관리자 및 개발자가 알아야 할 사항은 무엇입니까?

주요 이슈: 성능 및 효율성

사이트 및 앱 개발자는 일반적으로 자신의 창작물이 실제로 사용된다는 의도로 빌드합니다. 때때로 청중 기반은 한정되어 있지만 종종 아이디어는 가능한 한 많은 사용자를 확보하는 것입니다. 당연히 웹사이트가 인기를 끌수록 더 많은 수익을 올릴 수 있습니다.

웹사이트 로드 시간이 100밀리초 지연되면 전환율이 7% 감소할 수 있습니다.

Akamai 온라인 소매 실적 보고서: 밀리초가 중요합니다(2017)

다시 말해, 하루 매출이 $40,000인 전자 상거래 사이트는 이러한 지연으로 인해 연간 백만 달러의 손실을 입게 됩니다.

사이트의 성능이 사이트의 인기를 높이는 데 절대적으로 중요하다는 것도 비밀이 아닙니다. 온라인 쇼핑 연구에서는 이탈률 증가와 로딩 시간 연장, 쇼핑 경험 중 쇼핑 충성도와 웹사이트 성능 간의 연관성을 계속해서 찾고 있습니다.

연구 결과:

• 소비자의 47%는 웹 페이지가 2초 이내에 로드될 것으로 기대합니다.
• 40%의 사람들은 로드하는 데 3초 이상 걸리는 웹사이트를 포기합니다.

그리고 그것은 10여 년 전 온라인 쇼핑객의 인내심의 상태였습니다. 따라서 성능이 중요하며 HTTP/2와 HTTP/3은 모두 더 나은 웹사이트 성능을 의미합니다.

HTTP/2? ...그게 뭐야?

HTTP/2 프로토콜을 잘 이해하는 것은 HTTP/3를 이해하는 데 중요합니다. 우선, 왜 HTTP/2가 필요했을까요?

HTTP/2는 웹에서 가장 큰 성능 문제가 대기 시간 이라고 보고한 연구 결과 SPDY라는 Google 프로젝트로 시작되었습니다. 저자는 "더 많은 대역폭은 (많이) 중요하지 않습니다"라고 결론지었습니다.

배관과 인터넷을 비유하자면 인터넷의 대역폭 을 수도관의 지름과 같다고 생각할 수 있습니다. 더 큰 파이프는 더 많은 양의 물을 운반하므로 두 지점 사이에 더 많은 물을 전달할 수 있습니다.

동시에 파이프가 아무리 크더라도 파이프가 비어 있고 한 지점에서 다른 지점으로 물을 얻으려면 물이 파이프를 통해 이동하는 데 시간이 걸립니다. 인터넷 용어로 물이 파이프의 한쪽 끝에서 다른 쪽 끝으로 이동하고 다시 돌아오는 데 걸리는 시간을 왕복 시간 또는 RTT 라고 합니다.

마이크 벨시

이 연구에서는 페이지 로드 시간을 줄이는 것이 목표였습니다. 1Mbps에서 2Mbps로 이동하면 페이지 로드 시간이 절반으로 줄어들기 때문에 대역폭을 늘리면 초기에 도움이 되는 것으로 나타났습니다. 그러나 이점은 매우 빠르게 안정됩니다.

반대로 지연 시간을 줄이면 지속적인 이점이 있으며 최상의 결과를 얻을 수 있습니다.

HTTP HOL: Head-of-line 차단 문제

HTTP/1 프로토콜 내에서 대기 시간의 주요 원인은 헤드 오브 라인 차단 문제입니다. 웹 페이지(거의 항상)에는 CSS, JavaScript, 글꼴, 이미지, AJAX/XMR 등 여러 리소스가 필요합니다. 이는 웹 브라우저가 서버에 여러 요청을 해야 한다는 것을 의미합니다. 그러나 페이지가 유용해지기 위해 모든 리소스가 필요한 것은 아닙니다.

HTTP/1.0에서는 브라우저가 다음 요청을 시작하기 전에 응답을 완전히 수신하는 것을 포함하여 요청을 완전히 완료해야 했습니다. 모든 것은 순서대로 이루어져야 했습니다. 각 요청은 요청 행을 차단하므로 이름이 지정됩니다.

HOL 차단 문제를 보완하기 위해 웹 브라우저는 단일 서버에 여러 개의 동시 연결을 만듭니다. 그러나 그들은 이 동작을 임의로 제한해야 했습니다. 서버, 워크스테이션 및 네트워크는 너무 많은 연결로 과부하될 수 있습니다.

HTTP/1.1은 이 문제를 해결하는 데 도움이 되는 몇 가지 개선 사항을 도입했습니다. 주요 기능은 파이프라이닝 으로 웹 브라우저가 이전 요청이 완료될 때까지 기다릴 필요 없이 새 요청을 시작할 수 있도록 합니다. 이를 통해 대기 시간이 짧은 환경에서 로딩 시간이 크게 향상되었습니다.

그러나 여전히 모든 응답이 만들어진 순서대로 순차적으로 도착해야 하므로 라인의 선두는 여전히 차단됩니다. 놀랍게도 많은 서버가 여전히 이 기능을 활용하지 않습니다.

흥미롭게도 HTTP/1.1은 또한 keep-alive 를 도입하여 브라우저가 각 HTTP 요청에 대해 새 TCP 연결을 생성하는 오버헤드를 피할 수 있도록 했습니다. 이것은 TCP에서 파생된 성능 문제를 해결하기 위한 초기 시도였습니다. 너무 비효율적이어서 대부분의 성능 전문가들은 비활성 연결이 너무 많은 서버를 방해하기 때문에 실제로 권장하지 않습니다. 아래에서 TCP와 이 문제가 HTTP/2에 의해 어떻게 수정되었는지 자세히 살펴보겠습니다.

HTTP/2의 HTTP HOL 차단 솔루션

HTTP/2는 단일 연결을 통한 요청-응답 다중화 를 도입했습니다. 브라우저는 언제든지 새 요청을 시작할 수 있을 뿐만 아니라 응답을 원하는 순서로 수신할 수 있습니다. 차단은 애플리케이션 수준에서 완전히 제거됩니다.

직접적인 결과로 이것은 HTTP/2에 정통한 웹 서버가 효율성을 극대화할 수 있음을 의미합니다. 자세한 내용은 나중에 설명합니다.

요청-응답 다중화는 HTTP/2의 헤드라인 기능이지만 몇 가지 다른 중요한 기능을 포함합니다. 독자들은 그것들이 모두 어느 정도 관련되어 있음을 알 수 있습니다.

HTTP/2 바이너리 프레이밍

HTTP/2는 HTTP 프로토콜 표준을 비효율적인 사람이 읽을 수 있는 ASCII 요청-응답 모델에서 효율적인 바이너리 프레이밍 으로 전환합니다. 더 이상 단순한 요청과 응답이 아닙니다.

HTTP/2를 사용하면 브라우저는 각각 여러 프레임으로 구성된 여러 메시지가 있는 양방향 스트림을 통해 서버와 통신합니다.

HTTP/2 HPACK(헤더 압축)

HPACK 형식을 사용하는 HTTP/2의 새로운 헤더 압축 은 대부분의 사이트에서 엄청난 대역폭을 절약합니다. 이는 대부분의 헤더가 연결 내에서 전송된 요청에 대해 동일하기 때문입니다.

Cloudflare는 HPACK만으로도 상당한 대역폭 절감 효과를 보고합니다.

• 인그레스 헤더에 대한 76% 압축
• 총 수신 트래픽 53% 감소
• 이그레스 헤더에 대한 69% 압축
• 총 송신 트래픽 1.4% ~ 15% 감소

물론 더 적은 대역폭을 사용한다는 것은 일반적으로 더 빠른 웹사이트를 의미합니다.

HTTP/2 스트림 우선 순위 지정 및 서버 푸시

HTTP/2의 멀티플렉싱을 통해 서버가 효율성을 극대화할 수 있는 이유가 여기에 있습니다. 멀티플렉싱은 느린 리소스(예: 큰 이미지, 데이터베이스 생성 JSON 등)보다 더 빠른 리소스(예: 메모리 캐시 JavaScript)를 제공하는 데 도움이 됩니다. 그러나 HTTP/2의 스트림 우선 순위 지정 을 통해 추가 성능 향상도 가능합니다.

스트림 우선 순위 지정은 리소스를 많이 사용하는 다른 요청이 완료될 때까지 기다릴 필요 없이 거의 준비된 페이지 측면을 완전히 완료하는 데 도움이 됩니다. 이것은 가중치 종속성 트리를 통해 수행됩니다. 이 트리는 서비스에 가장 많은 시스템 리소스를 할당해야 하는 응답을 서버에 알리는 데 사용됩니다.

이것은 프로그레시브 웹 애플리케이션(PWA)에 특히 중요합니다. 예를 들어 페이지에 4개의 JavaScript 파일이 있다고 가정합니다. 2개는 페이지 기능용이고 2개는 광고용입니다. 최악의 시나리오는 기능 JS의 절반과 광고 JS의 절반을 로드한 다음 나머지 JS를 로드하기 전에 큰 이미지를 로드하는 것입니다. 이 경우 모든 것이 가장 느린 리소스를 기다려야 하기 때문에 페이지의 아무 것도 처음에는 작동하지 않습니다.

스트림 우선 순위 지정을 통해 웹 브라우저는 광고 JavaScript 파일을 보내기 전에 두 페이지 기능 JS 파일을 모두 보내도록 서버에 지시할 수 있습니다. 이렇게 하면 사용자가 페이지의 기능을 사용하기 전에 광고가 완전히 로드될 때까지 기다릴 필요가 없습니다. 전체 로딩 시간은 개선되지 않았지만 체감 성능은 크게 향상되었습니다. 불행히도 웹 브라우저 내에서 이러한 동작은 웹 개발자가 지정하는 것이 아니라 여전히 대부분 알고리즘의 문제입니다.

같은 맥락에서 HTTP/2의 서버 푸시 기능을 사용하면 서버가 아직 요청하지 않은 요청에 대해 브라우저에 응답을 보낼 수 있습니다! 서버는 서버가 곧 요청할 것임을 알고 있는 브라우저 리소스에 미리 로드하여 대역폭을 효율적으로 사용하여 전송 간격을 활용할 수 있습니다. 여기서 희망의 일부는 리소스를 부풀려 로드하는 데 더 오래 걸리는 리소스 인라인 방식을 제거하는 것입니다.

불행히도, 이 두 기능 모두 웹 개발자가 실제로 성공하려면 많은 신중한 구성이 필요합니다. 단순히 활성화하는 것만으로는 충분하지 않습니다.

HTTP/2는 분명히 많은 잠재적인 이점을 제공합니다. 그 중 일부는 다른 것보다 활용하기에 저렴합니다. 그들은 현실 세계에서 어떻게 지내고 있습니까?

HTTP 대 HTTP/2 채택

SPDY는 2009년에 만들어졌습니다. HTTP/2는 2015년에 표준화되었습니다. SPDY는 코드의 불안정한 개발 분기의 이름이 되었고 HTTP/2가 최종 버전이 되었습니다. 그 결과 SPDY는 더 이상 사용되지 않으며 HTTP/2는 일반적으로 모든 사람이 따르는 표준입니다.

표준화 후 HTTP/2(또는 "h2")의 채택은 상위 1,000개 웹사이트의 약 40%로 빠르게 증가했습니다. 이는 대부분 고객을 대신하여 지원을 배포하는 대규모 호스팅 및 클라우드 제공업체에 의해 주도되었습니다. 불행히도 몇 년 후, HTTP/2 채택이 느려졌고 인터넷의 대부분은 여전히 ​​HTTP/1에 있습니다.

HTTP/2 일반 텍스트 모드에 대한 브라우저 지원 부족

암호화를 표준의 필수 부분으로 만들기 위해 HTTP/2에 대한 많은 요청이 있었습니다. 대신 표준은 암호화(h2) 모드와 일반 텍스트(h2c) 모드를 모두 정의했습니다. 따라서 HTTP/2는 HTTP/1을 완전히 대체할 수 있습니다.

표준에도 불구하고 현재의 모든 웹 브라우저는 암호화된 연결을 통해서만 HTTP/2를 지원하며 의도적으로 일반 텍스트 모드를 구현하지 않습니다. 대신 브라우저는 HTTP/1 이전 버전과의 호환성 모드에 의존하여 안전하지 않은 서버에 액세스합니다. 이것은 기본적으로 웹을 안전하게 만드는 이데올로기적 추진의 직접적인 결과입니다.

왜 HTTP/3인가? 그리고 어떻게 다른가요?

HTTP 헤드 오브 라인 차단 문제가 이제 HTTP/2로 수정됨에 따라 프로토콜 개발자는 다음으로 큰 대기 시간 드라이버인 TCP 헤드 오브 라인 차단 문제에 관심을 돌렸습니다.

전송 제어 프로토콜(TCP)

IP(인터넷 프로토콜) 네트워크는 컴퓨터가 서로 패킷을 보내는 개념을 기반으로 합니다. 패킷은 상단에 일부 주소 지정 정보가 첨부된 데이터일 뿐입니다.

그러나 응용 프로그램은 일반적으로 데이터 스트림 을 처리해야 합니다. 이러한 환상을 달성하기 위해 TCP(전송 제어 프로토콜)는 데이터 스트림이 흐를 수 있는 파이프 를 애플리케이션에 제공합니다. 대부분의 파이프와 마찬가지로 데이터가 파이프에 들어오는 것과 동일한 순서로 파이프를 빠져나가는 것을 보장하며, 이를 "선입 선출"(FIFO)이라고도 합니다. 이러한 특성으로 인해 TCP는 매우 유용하고 널리 채택되었습니다.

TCP가 제공하는 데이터 전달의 일부로 TCP는 다양한 상황을 처리할 수 있어야 합니다. 가장 복잡한 문제 중 하나는 네트워크에 과부하가 걸렸을 때 모든 사람에게 상황을 악화시키지 않으면서 모든 데이터를 전달하는 방법입니다. 이를 위한 알고리즘을 혼잡 제어 라고 하며 인터넷 사양에서 지속적으로 발전하는 부분입니다. 혼잡 제어가 충분하지 않으면 인터넷이 중단됩니다.

86년 10월 인터넷은 '혼잡 붕괴'의 연속이 된 첫 번째 사건을 겪었습니다. 이 기간 동안 LBL에서 UC Berkeley(400야드와 3개의 IMP 홉으로 분리된 사이트)까지의 데이터 처리량은 32Kbps에서 40bps로 떨어졌습니다.

V. 제이콥슨 (1988)

바로 여기에서 TCP head-of-line 차단 문제가 발생합니다.

TCP HOL 차단 문제

TCP 혼잡 제어는 패킷 손실이 감지될 때마다 사용되는 패킷에 대한 백오프 및 재전송 메커니즘을 구현하여 작동합니다. 백오프는 네트워크를 안정시키는 데 도움이 됩니다. 재전송은 데이터가 최종적으로 전달되도록 합니다.

이것은 TCP 데이터가 순서 없이 목적지에 도착할 수 있고 스트림으로 재조립하기 전에 패킷을 재정렬하는 것은 수신 당사자의 책임임을 의미합니다. 불행히도 이것은 하나의 손실된 패킷으로 인해 서버가 재전송을 기다리는 동안 전체 TCP 스트림이 일시 중지될 수 있음을 의미합니다. 따라서 라인의 헤드가 차단됩니다.

Google의 또 다른 프로젝트는 QUIC라는 프로토콜을 도입하여 이 문제를 해결하는 것을 목표로 했습니다.

QUIC 프로토콜은 TCP 대신 UDP 위에 구축되었으며 QUIC는 HTTP/3의 기반을 형성하고 있습니다.

UDP 란 무엇입니까?

UDP(사용자 데이터그램 프로토콜)는 TCP의 대안입니다. 스트림의 환상이나 TCP가 제공하는 것과 동일한 보장을 제공하지 않습니다. 대신 데이터를 패킷에 넣고 다른 컴퓨터에 주소를 지정하여 보낼 수 있는 쉬운 방법을 제공합니다. 신뢰할 수 없고 순서 가 없으며 어떤 형태의 혼잡 제어도 제공되지 않습니다 .

그 목적은 가볍고 통신을 허용하는 데 필요한 최소한의 기능을 제공하는 것입니다. 이런 식으로 응용 프로그램은 자체 보증을 구현할 수 있습니다. 이것은 종종 실시간 애플리케이션에서 매우 유용합니다. 예를 들어, 전화 통화에서 사용자는 일반적으로 데이터의 100%를 결국 받는 것보다 90%의 데이터를 즉시 받는 것을 선호합니다.

HTTP/3의 TCP HOL 솔루션

TCP HOL 차단 문제를 해결하려면 모든 데이터의 전달을 보장하고 네트워크 혼잡 붕괴를 방지해야 하므로 UDP로 전환하는 것 이상이 필요했습니다. QUIC 프로토콜은 최적화된 HTTP over UDP 유형 환경을 제공하여 이 모든 작업을 수행하도록 설계되었습니다.

QUIC가 스트림 관리, 바이너리 프레이밍 등의 제어를 인수함에 따라 QUIC 위에서 실행할 때 HTTP/2가 수행할 작업이 많지 않습니다. 이것은 QUIC + HTTP의 새로운 조합이 HTTP/3으로 표준화되는 추진 요인의 일부입니다.

참고: 프로토콜이 개발 중이고 수년간 프로덕션 환경에 배포되었기 때문에 QUIC에는 여러 버전이 있습니다. GQUIC라는 Google 전용 버전도 있습니다. 따라서 이전 QUIC 프로토콜과 새로운 HTTP/3 표준을 구별하는 것이 중요합니다.

상시 암호화

HTTP/3에는 TLS에서 많이 차용하지만 직접 사용하지 않는 암호화가 포함됩니다. HTTP/3의 주요 구현 과제 중 하나는 새로 필요한 기능을 추가하기 위해 수정해야 하는 TLS/SSL 라이브러리입니다.

이 변경은 HTTP/3가 암호화하는 항목이 HTTPS와 다르기 때문입니다. 이전 HTTPS 프로토콜을 사용하면 데이터 자체만 TLS로 보호되므로 많은 전송 메타데이터가 표시됩니다. HTTP/3에서는 데이터와 전송 프로토콜이 모두 보호됩니다. 이것은 보안 기능처럼 들릴 수 있으며 실제로 그렇습니다. 그러나 이것은 HTTP/2에 존재하는 많은 오버헤드를 피하기 위해 이런 방식으로 수행됩니다. 따라서 전송 프로토콜과 데이터를 암호화하면 실제로 프로토콜의 성능이 향상됩니다.

네트워킹 인프라에 대한 HTTP/3의 영향

HTTP/3는 논쟁의 여지가 없습니다. 주요 관심사는 네트워킹 인프라에 관한 것입니다.

클라이언트 측 HTTP/3

클라이언트 측에서는 UDP 트래픽이 속도 제한 및/또는 차단되는 것이 매우 일반적입니다. 이러한 제한을 HTTP/3에 적용하면 프로토콜의 요점이 무효화됩니다.

둘째, HTTP가 모니터링 및/또는 가로채는 것이 매우 일반적입니다. HTTPS 트래픽이 있는 경우에도 네트워크는 프로토콜의 일반 텍스트 전송 요소를 정기적으로 관찰하여 특정 네트워크 또는 특정 지역 내에서 특정 웹사이트에 대한 액세스를 방지하기 위해 연결을 끊어야 하는지 결정합니다. 일부 국가에서는 특정 서비스 제공업체에 대해 법으로 의무화하기도 합니다. HTTP/3의 필수 암호화는 이것을 불가능하게 합니다.

정부 차원의 필터링만 있는 것은 아닙니다. 많은 대학, 공공 도서관, 학교 및 부모가 걱정하는 가정에서는 특정 웹사이트에 대한 액세스를 차단하거나 최소한 방문한 사이트에 대한 로그를 유지하는 쪽을 적극적으로 선택합니다. HTTP/3의 필수 암호화는 이것을 불가능하게 합니다.

현재 제한된 필터링 이 가능하다는 점은 주목할 가치가 있습니다. 이는 웹 사이트의 호스트 이름은 전달하지만 경로, 쿼리 매개변수 등은 전달하지 않는 SNI(서버 이름 표시) 필드가 여전히 암호화되지 않았기 때문입니다. 그러나 이는 최근 TLS 표준에 추가된 ESNI(암호화된 SNI)의 도입으로 가까운 장래에 바뀔 예정이다.

서버 측 HTTP/3

서버 측에서는 트래픽을 예상하지 않는 모든 포트와 프로토콜을 차단하는 것이 가장 좋습니다. 즉, 서버 관리자는 이제 기존 TCP 443 규칙에 의존하는 대신 HTTP/3용 UDP 443을 열어야 합니다.

둘째, 네트워크 인프라는 TCP 세션을 고정 상태로 만들 수 있습니다. 즉, 라우팅 우선 순위가 변경되더라도 항상 동일한 서버로 라우팅됩니다. HTTP/3가 세션이 없는 UDP를 통해 실행됨에 따라 고정 라우팅을 지원하기 위해 암호화되지 않은 상태로 남겨진 HTTP/3 관련 연결 ID를 추적하기 위해 네트워크 인프라를 업데이트해야 합니다.

셋째, 남용을 감지하고, 일반적인 보안 문제를 모니터링하고, 맬웨어와 바이러스의 확산을 감지 및 방지하기 위해 HTTP를 검사하는 것은 매우 일반적입니다. HTTP/3의 암호화로 인해 이것은 불가능합니다. 그러나 장치가 HTTP/3 지원을 구현한다고 가정하면 가로채는 장치에 보안 키 사본이 있는 옵션은 여전히 ​​가능합니다.

마지막으로 많은 관리자가 더 많은 SSL 인증서를 관리해야 하는 것에 반대하지만 Let's Encrypt와 같은 서비스를 사용할 수 있게 된 지금은 문제가 덜합니다.

이러한 문제를 해결하기 위해 널리 받아들여지고 잘 알려진 솔루션이 나오기 전까지는 많은 대형 네트워크가 단순히 HTTP/3을 차단할 것이라고 생각합니다.

웹 개발에 대한 HTTP/3의 영향

이 부분에서는 크게 걱정할 것이 없습니다. HTTP/2의 스트림 우선 순위 지정 및 서버 푸시 기능은 여전히 ​​HTTP/3에 있습니다. 웹 개발자가 사이트 성능을 실제로 최적화하려면 이러한 기능에 익숙해지는 것이 좋습니다.

지금 HTTP/3 사용하기

Google Chrome 또는 오픈 소스 Chromium 브라우저 사용자는 이미 HTTP/3을 사용하도록 설정되어 있습니다. HTTP/3 서버의 프로덕션 품질 릴리스는 아직 한참 멀었습니다. 이 글을 쓰는 시점에서 사양이 완전히 확정되지 않았습니다. 그러나 한편으로는 사용할 수 있는 도구가 많이 있으며 Google과 Cloudflare는 이미 프로덕션 환경에 대한 지원을 추진했습니다.

그것을 시도하는 가장 간단한 방법은 Docker에서 Caddy를 사용하는 것입니다. 이를 위해서는 SSL 인증서가 필요하므로 공개적으로 액세스할 수 있는 IP 주소를 사용하면 작업이 쉬워집니다. 단계는 다음과 같습니다.

1. DNS 설정. 인터넷에 있는 작동 중인 호스트 이름을 가져옵니다(예: yourhostname.example.com IN A 192.0.2.1 ).
2. 캐디파일 생성. 다음 행을 포함해야 합니다.

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. 캐디 실행: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —또는 Docker 외부, caddy --quic .
2. QUIC가 활성화된 크롬 실행: chromium --enable-quic
3. (선택 사항) 프로토콜 표시기 확장 설치.
4. 파일 브라우저가 표시되어야 하는 QUIC 지원 서버 로 이동합니다.

개발자는 다음과 같은 유용한 도구를 사용하여 서버를 테스트할 수도 있습니다.

• Keycdn의 HTTP/2 테스트
• LiteSpeed의 HTTP3Check
• Qualys의 SSL 서버 테스트

읽어 주셔서 감사합니다!