실제 작동 중인 QUIC 프로토콜: Uber가 이를 구현하여 성능을 최적화한 방법

QUIC 프로토콜은 보기에 매우 흥미롭습니다. 이것이 바로 우리가 이에 대해 글을 쓰는 것을 좋아하는 이유입니다. 그러나 QUIC에 대한 이전 출판물이 역사적(원한다면 지역 역사) 성격과 하드웨어에 더 가깝다면 오늘 우리는 다른 종류의 번역을 출판하게 되어 기쁘게 생각합니다. 우리는 2019년에 프로토콜의 실제 적용에 대해 이야기할 것입니다. 또한 우리는 소위 차고에 기반을 둔 소규모 인프라가 아니라 거의 전 세계에서 운영되는 Uber에 대해 이야기하고 있습니다. 회사의 엔지니어들이 프로덕션에서 QUIC를 사용하기로 결정한 방법, 테스트를 수행한 방법 및 프로덕션에서 출시한 후 본 내용을 아래에서 확인하세요.

사진은 클릭 가능합니다. 즐겁게 읽으세요!

Uber는 전 세계적으로 규모가 600개에 달하는 도시를 보유하고 있으며, 각 도시의 애플리케이션은 4500개 이상의 이동통신 사업자가 제공하는 무선 인터넷에 전적으로 의존하고 있습니다. 사용자는 앱이 단지 빠르기만 한 것이 아니라 실시간으로 작동하기를 기대합니다. 이를 달성하려면 Uber 앱의 지연 시간이 짧고 매우 안정적인 연결이 필요합니다. 아아, 하지만 스택 HTTP / 2 동적이며 손실이 발생하기 쉬운 무선 네트워크에서는 제대로 작동하지 않습니다. 이 경우 낮은 성능은 운영 체제 커널의 TCP 구현과 직접적인 관련이 있다는 것을 깨달았습니다.

문제를 해결하기 위해 우리는 QUIC, 전송 프로토콜의 성능을 더 효과적으로 제어할 수 있는 최신 채널 다중화 프로토콜입니다. 현재 워킹그룹 IETF QUIC를 다음과 같이 표준화합니다. HTTP / 3.

광범위한 테스트를 거친 후 우리는 애플리케이션에 QUIC를 구현하면 TCP에 비해 꼬리 지연 시간이 낮아진다는 결론을 내렸습니다. 운전자 및 승객 애플리케이션에서 HTTPS 트래픽이 10~30% 범위로 감소하는 것을 관찰했습니다. QUIC은 또한 사용자 패키지에 대한 엔드투엔드 제어 기능을 제공했습니다.

이 기사에서는 QUIC를 지원하는 스택을 사용하여 Uber 애플리케이션용 TCP를 최적화한 경험을 공유합니다.

최신 기술: TCP

오늘날 TCP는 인터넷에서 HTTPS 트래픽을 전달하는 데 가장 많이 사용되는 전송 프로토콜입니다. TCP는 안정적인 바이트 스트림을 제공하므로 네트워크 정체 및 링크 계층 손실에 대처할 수 있습니다. HTTPS 트래픽에 TCP가 널리 사용되는 이유는 전자의 편재성(거의 모든 OS에 TCP가 포함되어 있음), 대부분의 인프라(예: 로드 밸런서, HTTPS 프록시 및 CDN)에서의 가용성 및 사용 가능한 기본 기능 때문입니다. 거의 대부분의 플랫폼과 네트워크에서.

대부분의 사용자는 이동 중에도 우리 앱을 사용하며 TCP 테일 지연 시간은 실시간 HTTPS 트래픽 요구에 미치지 못했습니다. 간단히 말해서, 전 세계 사용자가 이를 경험했습니다. 그림 1은 주요 도시의 지연을 보여줍니다.

그림 1: 꼬리 지연 시간은 Uber의 주요 도시에 따라 다릅니다.

인도와 브라질 네트워크의 대기 시간은 미국과 영국보다 높았지만 꼬리 대기 시간은 평균 대기 시간보다 훨씬 높습니다. 그리고 이는 미국과 영국의 경우에도 마찬가지입니다.

TCP OTA 성능

TCP는 다음을 위해 생성되었습니다. 열광한 즉, 예측 가능성이 높은 링크에 중점을 둡니다. 하지만, 무선 전화 네트워크에는 고유한 특성과 어려움이 있습니다. 첫째, 무선 네트워크는 간섭 및 신호 감쇠로 인해 손실되기 쉽습니다. 예를 들어 Wi-Fi 네트워크는 전자레인지, 블루투스 및 기타 전파에 민감합니다. 셀룰러 네트워크는 신호 손실로 인해 어려움을 겪고 있습니다(잃어버린 길) 물체와 건물뿐만 아니라 신호의 반사/흡수로 인해 간섭 이웃에서 셀 타워. 이는 더 중요하고(4~10배) 더 다양해집니다. 왕복 시간(RTT) 유선 연결에 비해 패킷 손실이 발생합니다.

대역폭 변동 및 손실을 방지하기 위해 셀룰러 네트워크는 일반적으로 트래픽 버스트에 대해 대규모 버퍼를 사용합니다. 이로 인해 과도한 대기열이 발생하여 지연 시간이 길어질 수 있습니다. TCP는 연장된 시간 초과로 인해 이 대기열을 낭비로 간주하는 경우가 많으므로 TCP는 릴레이하여 버퍼를 채우는 경향이 있습니다. 이 문제는 다음과 같이 알려져 있습니다. 버퍼블로트 (과도한 네트워크 버퍼링, 버퍼 팽창) 그리고 이것은 매우 심각한 문제 현대 인터넷.

마지막으로 셀룰러 네트워크 성능은 이동통신사, 지역, 시간에 따라 다릅니다. 그림 2에서는 2km 범위 내의 셀 전체에서 HTTPS 트래픽의 평균 지연 시간을 수집했습니다. 인도 델리에 있는 두 개의 주요 이동통신 사업자에 대해 수집된 데이터입니다. 보시다시피 성능은 셀마다 다릅니다. 또한 한 작업자의 생산성은 두 번째 작업자의 생산성과 다릅니다. 이는 시간과 위치를 고려한 네트워크 진입 패턴, 사용자 이동성을 고려한 네트워크 인프라, 타워 ​​밀도, 네트워크 유형(LTE, 3G 등) 비율을 고려한 네트워크 인프라 등의 요인에 의해 영향을 받습니다.

그림 2. 2km 반경을 예로 사용한 지연. 인도 델리.

또한 셀룰러 네트워크의 성능은 시간이 지남에 따라 달라집니다. 그림 3은 요일별 평균 대기 시간을 보여줍니다. 우리는 또한 하루, 한 시간 내에 더 작은 규모로 차이를 관찰했습니다.

그림 3. 꼬리 지연은 날짜별로 크게 다를 수 있지만 동일한 운영자에 대한 것입니다.

위의 모든 사항으로 인해 무선 네트워크에서는 TCP 성능이 비효율적으로 됩니다. 그러나 TCP에 대한 대안을 찾기 전에 우리는 다음 사항에 대한 정확한 이해를 원했습니다.

• 우리 애플리케이션에서 꼬리 지연 시간을 발생시키는 주범은 TCP입니까?
• 최신 네트워크에는 중요하고 다양한 왕복 지연(RTT)이 있습니까?
• RTT와 손실이 TCP 성능에 미치는 영향은 무엇입니까?

TCP 성능 분석

TCP 성능을 분석한 방법을 이해하기 위해 TCP가 발신자에서 수신자로 데이터를 전송하는 방법을 간단히 살펴보겠습니다. 먼저 송신자는 TCP 연결을 설정하여 XNUMX방향 통신을 수행합니다. 악수: 송신자는 SYN 패킷을 보내고 수신자로부터 SYN-ACK 패킷을 기다린 후 ACK 패킷을 보냅니다. 추가 두 번째 및 세 번째 패스는 TCP 연결을 설정하는 데 사용됩니다. 수신자는 안정적인 전달을 보장하기 위해 각 패킷(ACK)의 수신을 확인합니다.

패킷이나 ACK가 손실되면 보낸 사람은 시간 초과(RTO, 재전송 시간 초과). RTO는 발신자와 수신자 간의 예상 RTT 지연과 같은 다양한 요소를 기반으로 동적으로 계산됩니다.

그림 4. TCP/TLS를 통한 패킷 교환에는 재전송 메커니즘이 포함됩니다.

애플리케이션에서 TCP가 어떻게 수행되는지 확인하기 위해 다음을 사용하여 TCP 패킷을 모니터링했습니다. TCP 덤프 인도 엣지 서버에서 오는 전투 트래픽에 대해 일주일 동안. 그런 다음 다음을 사용하여 TCP 연결을 분석했습니다. TCP 추적. 또한, 실제 트래픽을 최대한 모방하여 에뮬레이트된 트래픽을 테스트 서버로 보내는 Android 애플리케이션을 만들었습니다. 이 애플리케이션이 설치된 스마트폰은 여러 직원에게 배포되었으며 직원들은 며칠에 걸쳐 로그를 수집했습니다.

두 실험의 결과는 서로 일치했습니다. 우리는 높은 RTT 지연 시간을 확인했습니다. 꼬리 값은 중앙값보다 거의 6배 더 높았습니다. 지연의 산술 평균이 1초를 초과합니다. 많은 연결이 손실되어 TCP가 전체 패킷의 3,5%를 재전송하게 되었습니다. 공항, 기차역 등 혼잡한 지역에서는 7%의 손실이 발생했습니다. 이러한 결과는 셀룰러 네트워크에 사용되는 기존 통념에 의문을 제기합니다. 고급 재전송 회로 운송 수준에서 손실을 크게 줄입니다. 다음은 "시뮬레이터" 애플리케이션의 테스트 결과입니다.

네트워크 측정항목
의미

RTT, 밀리초 [50%,75%, 95%,99%]
[350, 425, 725, 2300]

RTT 발산(초)
평균 ~1,2초

불안정한 연결에서의 패킷 손실
평균 ~3.5%(과적 영역에서는 7%)

이러한 연결 중 거의 절반에는 적어도 하나의 패킷 손실이 있었으며 대부분은 SYN 및 SYN-ACK 패킷이었습니다. 대부분의 TCP 구현에서는 SYN 패킷에 대해 1초의 RTO 값을 사용하며, 이는 후속 손실에 대해 기하급수적으로 증가합니다. TCP가 연결을 설정하는 데 더 오랜 시간이 걸리기 때문에 애플리케이션 로드 시간이 늘어날 수 있습니다.

데이터 패킷의 경우 높은 RTO 값은 무선 네트워크에서 일시적인 손실이 있는 경우 네트워크의 유용한 활용도를 크게 감소시킵니다. 우리는 평균 재전송 시간이 약 1초이고 꼬리 지연이 거의 30초라는 것을 발견했습니다. TCP 수준의 이러한 높은 대기 시간으로 인해 HTTPS 시간 초과 및 재요청이 발생하여 네트워크 대기 시간과 비효율성이 더욱 증가했습니다.

측정된 RTT의 75번째 백분위수는 약 425ms인 반면, TCP의 75번째 백분위수는 거의 3초였습니다. 이는 손실로 인해 TCP가 데이터를 성공적으로 전송하기 위해 7-10번의 패스를 사용했음을 암시합니다. 이는 비효율적인 RTO 계산, TCP가 손실에 신속하게 대응할 수 없는 결과일 수 있습니다. 최신 패키지 이는 무선 손실과 네트워크 혼잡으로 인한 손실을 구분하지 못하는 혼잡 제어 알고리즘의 비효율성과 창에서의 문제입니다. 다음은 TCP 손실 테스트 결과입니다.

TCP 패킷 손실 통계
가치

패킷 손실이 1회 이상 발생한 연결 비율
45%

연결 설정 중 손실이 발생한 연결 비율
30%

데이터 교환 중 손실이 발생한 연결 비율
76%

재전송 지연 분포(초) [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

하나의 패킷 또는 TCP 세그먼트에 대한 재전송 횟수 분포
[1,3,6,7]

QUIC의 적용

원래 Google에서 개발한 QUIC는 UDP 위에서 실행되는 다중 스레드 최신 전송 프로토콜입니다. 현재 QUIC은 표준화 과정 (우리는 이미 QUIC의 두 가지 버전이 있다고 썼습니다. 링크를 따라갈 수 있습니다 – 대략. 역자). 그림 5에서 볼 수 있듯이 QUIC는 HTTP/3 아래에 배치됩니다(사실 QUIC 위에 있는 HTTP/2는 HTTP/3이며 현재 집중적으로 표준화되고 있습니다). UDP를 사용하여 패킷을 형성함으로써 HTTPS 및 TCP 계층을 부분적으로 대체합니다. TLS가 QUIC에 완전히 내장되어 있으므로 QUIC는 보안 데이터 전송만 지원합니다.

그림 5: QUIC는 이전에 HTTP/3에서 실행되었던 TLS를 대체하여 HTTP/2에서 실행됩니다.

다음은 우리가 TCP 증폭을 위해 QUIC를 사용하게 된 이유입니다.

• 0-RTT 연결 설정. QUIC을 사용하면 이전 연결의 인증을 재사용하여 보안 핸드셰이크 횟수를 줄일 수 있습니다. 앞으로는 TLS1.3 0-RTT를 지원하지만 XNUMX방향 TCP 핸드셰이크가 여전히 필요합니다.
• HoL 차단을 극복합니다. HTTP/2는 성능을 향상시키기 위해 클라이언트당 하나의 TCP 연결을 사용하지만 이로 인해 HoL(head-of-line) 차단이 발생할 수 있습니다. QUIC은 멀티플렉싱을 단순화하고 요청을 애플리케이션에 독립적으로 전달합니다.
• 혼잡 통제. QUIC은 애플리케이션 계층에 상주하므로 네트워크 매개변수(손실 수 또는 RTT)를 기반으로 전송을 제어하는 ​​기본 전송 알고리즘을 더 쉽게 업데이트할 수 있습니다. 대부분의 TCP 구현은 알고리즘을 사용합니다. 큐빅이는 지연 시간에 민감한 트래픽에는 적합하지 않습니다. 최근에 개발된 알고리즘 BBR, 네트워크를 보다 정확하게 모델링하고 대기 시간을 최적화합니다. QUIC을 사용하면 BBR을 사용하고 이 알고리즘이 사용되는 대로 업데이트할 수 있습니다. 완벽.
• 손실 보충. QUIC는 두 개의 TLP를 호출합니다(꼬리 손실 프로브) RTO가 시작되기 전 - 손실이 매우 눈에 띄는 경우에도 마찬가지입니다. 이는 TCP 구현과 다릅니다. TLP는 빠른 보충을 트리거하기 위해 주로 마지막 패킷(또는 있는 경우 새 패킷)을 재전송합니다. 꼬리 지연 처리는 Uber가 네트워크를 운영하는 방식, 즉 짧고 산발적이며 지연 시간에 민감한 데이터 전송에 특히 유용합니다.
• 최적화된 ACK. 각 패킷에는 고유한 시퀀스 번호가 있으므로 문제가 없습니다. 구별 패킷이 재전송될 때. ACK 패킷에는 패킷을 처리하고 클라이언트 측에서 ACK를 생성하는 시간도 포함됩니다. 이러한 기능을 사용하면 QUIC이 RTT를 더 정확하게 계산할 수 있습니다. QUIC의 ACK는 최대 256개 대역을 지원합니다. NACK, 발신자가 패킷 셔플링에 대한 탄력성을 높이고 프로세스에서 더 적은 바이트를 사용하도록 돕습니다. 선택적 ACK(SACK) TCP의 경우 모든 경우에 이 문제가 해결되지는 않습니다.
• 연결 마이그레이션. QUIC 연결은 64비트 ID로 식별되므로 클라이언트가 IP 주소를 변경하는 경우 중단 없이 새 IP 주소에서 이전 연결 ID를 계속 사용할 수 있습니다. 이는 사용자가 Wi-Fi와 셀룰러 연결 간에 전환하는 모바일 애플리케이션에서 매우 일반적인 관행입니다.

QUIC의 대안

우리는 QUIC를 선택하기 전에 문제 해결을 위한 대체 접근 방식을 고려했습니다.

우리가 시도한 첫 번째 일은 TPC PoP(Points of Presence)를 배포하여 사용자에게 더 가까운 TCP 연결을 종료하는 것이었습니다. 기본적으로 PoP는 셀룰러 네트워크에 더 가까운 모바일 장치와의 TCP 연결을 종료하고 트래픽을 원래 인프라로 다시 프록시합니다. TCP를 더 가깝게 종료함으로써 잠재적으로 RTT를 줄이고 TCP가 동적 무선 환경에 더 잘 반응하도록 할 수 있습니다. 그러나 우리의 실험에 따르면 RTT와 손실의 대부분은 셀룰러 네트워크에서 발생하며 PoP를 사용해도 성능이 크게 향상되지 않는 것으로 나타났습니다.

또한 TCP 매개변수 조정도 살펴보았습니다. TCP는 서로 다른 OS 버전에 걸쳐 서로 다른 구현을 가지고 있기 때문에 이기종 에지 서버에 TCP 스택을 설정하는 것은 어려웠습니다. 이를 구현하고 다양한 네트워크 구성을 테스트하는 것은 어려웠습니다. 권한 부족으로 인해 모바일 장치에서 직접 TCP를 구성할 수 없었습니다. 더 중요한 것은 0-RTT 연결 및 개선된 RTT 예측과 같은 기능이 프로토콜 아키텍처에 매우 중요하므로 TCP만 조정하여 상당한 이점을 얻는 것은 불가능하다는 것입니다.

마지막으로 비디오 스트리밍 문제를 해결하는 여러 UDP 기반 프로토콜을 평가했습니다. 이러한 프로토콜이 우리의 경우에 도움이 되는지 확인하고 싶었습니다. 불행히도 많은 보안 설정이 심각하게 부족했으며 메타데이터 및 제어 정보에 대한 추가 TCP 연결도 필요했습니다.

우리의 연구에 따르면 QUIC는 아마도 보안과 성능을 모두 고려하면서 인터넷 트래픽 문제를 해결하는 데 도움이 될 수 있는 유일한 프로토콜일 것입니다.

QUIC를 플랫폼에 통합

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 애플리케이션에 통합할 수 있도록 보장합니다.

Google Cloud Balancer에서 QUIC 완료

백엔드 측에서 QUIC 완료는 Google Cloud 부하 분산 인프라에서 제공됩니다. Alt-svc QUIC 지원을 위한 응답 헤더. 일반적으로 밸런서는 각 HTTP 요청에 alt-svc 헤더를 추가하며 이는 이미 도메인에 대한 QUIC 지원을 검증합니다. Cronet 클라이언트가 이 헤더가 포함된 HTTP 응답을 받으면 해당 도메인에 대한 후속 HTTP 요청에 QUIC를 사용합니다. 밸런서가 QUIC를 완료하면 인프라는 HTTP2/TCP를 통해 이 작업을 데이터 센터로 명시적으로 보냅니다.

성과: 결과

출력 성능은 우리가 더 나은 프로토콜을 찾는 주된 이유입니다. 우선 우리는 스탠드를 만들었습니다. 네트워크 에뮬레이션QUIC가 다양한 네트워크 프로필에서 어떻게 작동하는지 알아보세요. 실제 네트워크에서 QUIC의 성능을 테스트하기 위해 우리는 승객 앱의 HTTP 호출과 매우 유사한 에뮬레이트된 네트워크 트래픽을 사용하여 뉴델리를 운전하면서 실험을 실행했습니다.

실험 1

실험 장비:

• OkHttp 및 Cronet 스택으로 Android 장치를 테스트하여 TCP 및 QUIC를 통한 HTTPS 트래픽을 각각 허용하는지 확인합니다.
• 동일한 유형의 HTTPS 헤더를 응답으로 보내고 클라이언트 장치를 로드하여 요청을 수신하는 Java 기반 에뮬레이션 서버
• TCP 및 QUIC 연결을 종료하기 위해 인도에 물리적으로 가까운 곳에 위치한 클라우드 프록시. TCP 종료를 위해 우리는 역방향 프록시를 사용했습니다. NGINX, QUIC용 오픈 소스 역방향 프록시를 찾는 것이 어려웠습니다. 우리는 Chromium의 기본 QUIC 스택을 사용하여 QUIC용 역방향 프록시를 직접 구축했으며 출판하다 오픈 소스로 크롬에 추가되었습니다.

그림 6. TCP 및 QUIC 로드 테스트 제품군은 OkHttp 및 Cronet이 포함된 Android 장치, 연결 종료를 위한 클라우드 프록시, 에뮬레이션 서버로 구성되었습니다.

실험 2

Google이 QUIC을 제공했을 때 구글 클라우드 로드 밸런싱, 동일한 인벤토리를 사용했지만 한 가지 수정 사항이 있었습니다. NGINX 대신 Google 로드 밸런서를 사용하여 장치에서 TCP 및 QUIC 연결을 종료하고 HTTPS 트래픽을 에뮬레이션 서버로 라우팅했습니다. 밸런서는 전 세계에 분산되어 있지만 지리적 위치 덕분에 장치에 가장 가까운 PoP 서버를 사용합니다.

그림 7. 두 번째 실험에서는 Google Cloud와 클라우드 프록시를 사용하여 TCP와 QUIC의 완료 지연 시간을 비교하고 싶었습니다.

그 결과, 몇 가지 계시가 우리를 기다리고 있었습니다.

• PoP를 통한 종료로 인해 TCP 성능이 향상되었습니다. 밸런서는 사용자에게 더 가까운 곳에서 TCP 연결을 종료하고 고도로 최적화되어 있으므로 RTT가 낮아져 TCP 성능이 향상됩니다. QUIC는 영향을 덜 받았지만 꼬리 지연 시간을 줄이는 측면에서 여전히 TCP보다 성능이 뛰어났습니다(10-30%).
• 꼬리가 영향을 받음 네트워크 홉. QUIC 프록시는 Google의 로드 밸런서보다 장치에서 더 멀리 떨어져 있지만(약 50ms 더 높은 대기 시간) 비슷한 성능을 제공했습니다. 즉, 대기 시간이 15% 감소한 반면 TCP의 20번째 백분위수는 99% 감소했습니다. 이는 라스트 마일 전환이 네트워크의 병목 현상임을 나타냅니다.

그림 8: 두 가지 실험의 결과는 QUIC가 TCP보다 훨씬 뛰어난 성능을 보인다는 것을 보여줍니다.

전투 교통

실험에서 영감을 받아 Android 및 iOS 애플리케이션에 QUIC 지원을 구현했습니다. 우리는 Uber가 운영되는 도시에서 QUIC의 영향을 확인하기 위해 A/B 테스트를 실시했습니다. 일반적으로 두 지역, 통신 사업자 및 네트워크 유형 모두에서 꼬리 지연이 크게 감소한 것을 확인했습니다.

아래 그래프는 거시 지역 및 다양한 네트워크 유형(LTE, 95G, 99G)별 꼬리(3 및 2 백분위수)의 개선 비율을 보여줍니다.

그림 9. 전투 테스트에서 QUIC는 지연 시간 측면에서 TCP보다 성능이 뛰어났습니다.

앞으로 만

아마도 이것은 시작에 불과할 것입니다. QUIC의 프로덕션 출시는 안정적인 네트워크와 불안정한 네트워크 모두에서 애플리케이션 성능을 향상시킬 수 있는 놀라운 기회를 제공했습니다. 즉:

적용 범위 증가

실제 트래픽에 대한 프로토콜 성능을 분석한 결과 약 80%의 세션이 QUIC를 성공적으로 사용하는 것으로 나타났습니다. 모든 요청을 수행했으며 세션의 15%는 QUIC와 TCP의 조합을 사용했습니다. 실제 UDP 오류와 열악한 네트워크 상태를 구별할 수 없기 때문에 Cronet 라이브러리가 TCP로 다시 시간 초과되기 때문에 이러한 조합이 발생한다고 가정합니다. 우리는 현재 QUIC의 후속 구현을 위해 노력하면서 이 문제에 대한 해결책을 찾고 있습니다.

빠른 최적화

모바일 앱의 트래픽은 지연 시간에 민감하지만 대역폭에는 민감하지 않습니다. 또한 당사 애플리케이션은 주로 셀룰러 네트워크에서 사용됩니다. 실험에 따르면 프록시를 사용하여 사용자 가까이에서 TCP 및 QUIC를 종료하더라도 꼬리 지연 시간이 여전히 높습니다. 우리는 혼잡 관리를 개선하고 QUIC 손실 복구 알고리즘의 효율성을 향상시키는 방법을 적극적으로 찾고 있습니다.

이러한 개선 사항과 기타 여러 가지 개선 사항을 통해 우리는 네트워크 및 지역에 관계없이 사용자 경험을 개선하여 전 세계적으로 편리하고 원활한 패킷 전송에 더 쉽게 접근할 수 있도록 할 계획입니다.

출처 : habr.com