UDP를 통한 HTTP - QUIC 프로토콜을 효과적으로 활용

QUIC(빠른 UDP 인터넷 연결)는 TCP, TLS 및 HTTP/2의 모든 기능을 지원하고 대부분의 문제를 해결하는 UDP 기반 프로토콜입니다. 이는 종종 새로운 또는 "실험적" 프로토콜이라고 불리지만 실험 단계보다 오래 지속되었습니다. 개발은 7년 이상 진행되었습니다. 이 기간 동안 프로토콜은 표준이 되지 못했지만 여전히 널리 보급되었습니다. 예를 들어, QUIC는 Google 및 Facebook과 같은 거대 기업에서 모바일 네트워크의 트래픽 속도를 높이고 지연을 줄이기 위해 사용되며 IETF는 이 프로토콜 포크를 HTTP/3 표준의 기초로 선언했습니다(HTTP/2가 44.8%에 불과 사이트).

개념

QUIC은 원래 저손실 유선 네트워크용으로 설계된 레거시 TCP를 대체하기 위해 개발되었습니다. TCP는 패킷을 순서대로 전달하기 때문에 한 패킷이 손실되면 전체 대기열이 중지됩니다(헤드 오브 라인 차단) 이는 연결의 품질과 안정성에 부정적인 영향을 미칩니다. 막대한 손실을 피하기 위해 셀룰러 네트워크는 대규모 버퍼를 사용하는데, 이는 결국 프로토콜의 중복성과 거짓 부정 응답으로 이어집니다(버퍼블로트). 또한 TCP는 연결을 설정하는 데 많은 시간을 소비합니다. SYN/ACK 및 TLS 요청은 별도로 처리되므로 QUIC처럼 한 번의 왕복이 아닌 세 번의 왕복이 필요합니다.

QUIC는 TCP 대체와 TLS 1.3 구현을 결합하므로 모든 연결은 항상 암호화되며 이러한 트래픽을 해독하는 것은 HTTPS를 통해 진행되는 경우보다 쉽지 않습니다. 또한 QUIC는 TCP 스택을 완전히 교체하려면 애플리케이션 수준에서 구현됩니다. 영원.

HTTP/2의 멀티플렉싱 지원에도 불구하고 패킷을 순서대로 전달해야 하기 때문에 HOL 차단 문제가 남아 있었습니다. QUIC는 UDP 위에 구현되므로 원칙적으로 차단이 없으며, 패킷이 영원히 손실되는 것을 방지하기 위해 번호가 매겨져 있고 "이웃"의 일부를 포함할 수 있어 중복성을 제공합니다. 또한 QUIC는 단일 연결 내에서 다양한 유형의 요청을 위해 모놀리식 대기열을 여러 스레드로 분할합니다. 따라서 패킷이 손실되면 하나의 대기열(예: 특정 파일 전송)에만 문제가 발생할 수 있습니다.

사용

처음에 QUIC은 Google 내에서 개발되었으며 주로 회사 내에서 사용하도록 맞춤화되었습니다. 2013년에는 표준화를 위해 IETF로 이관되었으며(아직 진행 중), 이제는 누구나 부족한 부분을 제안하여 프로토콜 개발에 참여할 수 있습니다. IETF 작업 그룹은 새로운 표준이 승인되고 혁신이 논의되는 연례 회의를 조직합니다. 이 QUIC 구현은 주요 구현으로 간주되며 이를 기반으로 HTTP/3 표준이 인증됩니다.

지금까지 HTTP/3을 기본 프로토콜로 포함시키는 것에 대한 논의는 없습니다. 아직 완성되지 않았고 거의 지원되지 않기 때문입니다.

그러나 QUIC는 Uber에서 성공적으로 수행된 애플리케이션과 서버 간의 전송으로 구현될 수 있습니다.

QUIC 도입에 대한 Uber의 의견

QUIC를 성공적으로 내장하고 열악한 연결 환경에서 애플리케이션 성능을 향상시키기 위해 이전 스택(TLS/TCP를 통한 HTTP/2)을 QUIC 프로토콜로 교체했습니다. 우리는 네트워크 라이브러리를 사용했습니다 크로넷 으로 크롬 프로젝트, 여기에는 원래 Google 버전의 프로토콜인 gQUIC가 포함되어 있습니다. 이 구현은 최신 IETF 사양을 따르도록 지속적으로 개선되고 있습니다.

우리는 먼저 Cronet을 Android 앱에 통합하여 QUIC에 대한 지원을 추가했습니다. 마이그레이션 비용을 최대한 줄이는 방식으로 통합이 수행되었습니다. 라이브러리를 사용했던 기존 네트워킹 스택을 완전히 교체하는 대신 알았어Http, 우리는 OkHttp API 프레임워크 아래에 Cronet을 통합했습니다. 이런 방식으로 통합을 수행함으로써 우리는 네트워크 호출(에서 사용되는)에 대한 변경을 방지했습니다. 개조) API 수준에서.

Android 기기의 접근 방식과 유사하게 iOS의 Uber 앱에 Cronet을 구현하여 네트워크에서 HTTP 트래픽을 가로채었습니다. API사용 NSURL프로토콜. iOS Foundation에서 제공하는 이 추상화는 프로토콜별 URL 데이터를 처리하고 상당한 마이그레이션 비용 없이 Cronet을 iOS 애플리케이션에 통합할 수 있도록 보장합니다.

에서 가져온 이 번역 Uber 기사

백엔드에서는 Google Cloud lb를 통해 QUIC 연결을 포착했습니다. 프로토콜을 지원합니다 2018년 중반부터.

Google Cloud가 Google에서 개발한 프로토콜과 잘 작동한다는 것은 놀라운 일이 아니지만 대안은 무엇입니까?

Nginx에

얼마 전 CloudFlare 건너려고 했는데 Quiche 도구를 사용하는 nginx(기본적으로 HTTP/3을 지원하지 않음) 구현은 설치 튜토리얼과 함께 제공되는 단일 .patch 파일로 제공됩니다.

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

필요한 경우 여기에서 모듈을 연결할 수 있습니다.

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

이제 남은 것은 HTTP/3 지원을 활성화하는 것입니다.

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

일반 브라우저에서는 아직 HTTP/3을 통해 연결할 수 없지만 다음을 사용할 수 있습니다. 크롬 카나리아 그리고 플래그와 함께 실행 --enable-quic, 서버나 quic.rocks 사이트 등으로 이동하여 개발자 도구에서 연결 유형을 확인하세요.

HTTP/3 대신에 작성되었습니다. http2+quic/99, 하지만 본질적으로 같은 것입니다.

기타 기술

• QUIC도 지원 LiteSpeed (훌륭한 팡파르와 함께 HTTP/3을 통해 Facebook에 연결됨) 및 프로그레시브 캐디. Apache는 아직 할 수 없지만 작업이 진행 중입니다. 본격적으로.
• 21월 XNUMX일 업데이트됨 WebRTC 표준 초안
• 바로 얼마 전 마이크로소프트가 문을 열었습니다. msquic 구현 코드, 아직 IETF 표준의 모든 기능을 사용할 수는 없지만 이는 이미 큰 혁신입니다.

결론

QUIC에 대한 관심은 불안정하지만 증가하고 있으며 이를 표준화하기 위한 작업이 진행 중입니다. 프로토콜의 새로운 구현은 거의 매달 나타나며, 매년 점점 더 많은 개발자가 QUIC가 미래라고 확신하고 있습니다. TCP 스택의 향후 버전에 이 프로토콜을 포함시키는 것도 가능합니다. 이는 조만간 전체 인터넷이 더욱 안정적이고 빠른 연결로 전환될 것임을 의미합니다.

이제 이미 인프라에 대한 QUIC 상호 작용을 구성하거나 브라우저에 제공할 수도 있습니다. 모두 프로토콜에 대한 지원을 추가할 계획이며 caniuse에 대한 슬픈 통계는 더욱 밝아질 것입니다.

출처 : habr.com