블로그 | CTO 사무실

QUIC가 인터넷을 삼킬 것이다

F5 썸네일
F5
2021년 2월 22일 게시


QUIC(약어가 아님)는 독특한 괴물이지만 인터넷의 오랜 문제를 해결하고 TCP, TLS, SCTP, IPSec, HTTP/2가 제공하는 대부분의 가치를 포착하는 새로운 전송 프로토콜로 생각하는 것이 가장 좋습니다. TCP/TLS 대신 UDP/QUIC에서 작동하도록 설계된 HTTP/3이라는 새로운 버전의 HTTP가 있습니다.

Google은 2014년 초에 자사 브라우저와 웹 서버에 QUIC을 통한 HTTP의 초기 버전을 배포했습니다. IETF 표준화 과정은 2016년에 시작되었습니다. 많은 진화와 데이터 수집을 거쳐 2021년 초에 첫 번째 RFC가 발표될 예정입니다. F5를 포함한 몇몇 주요 인터넷 회사는 QUIC를 사용하는 제품을 출시했거나 자사 인프라에 QUIC를 구축했습니다. 2020년 10월 현재 Facebook 트래픽의 75%가 HTTP/3와 QUIC를 통해 이루어졌습니다.

이러한 초기 배포와 IETF에서 QUIC을 기반으로 한 새로운 표준에 대한 열의는 이것이 인터넷을 통한 최첨단 애플리케이션을 위한 중요하고, 아마도 지배적인 기반이 될 것임을 시사합니다.

기술 개요—왜 QUIC인가?

빠른 레이어
그림 1. QUIC은 많은 기존 프로토콜의 기능을 가져왔습니다.

그림 1은 QUIC가 무엇을 하는지에 대한 개념을 독자에게 제공합니다. 그러나 이 기능 분해는 업계의 초기 채택자가 QUIC로 이동하는 이유를 명확히 하지 못합니다.

  1. 지연 시간 단축. 웹과 같은 데이터 전송은 세 계층의 핸드셰이크 지연 시간에 의해 결정됩니다. 즉, TCP용 하나, TLS용 하나, HTTP 요청/응답용 하나입니다. 최근 TCP/TLS의 발전으로 이를 원칙적으로 한 번의 왕복으로 줄일 수 있지만 실제로는 거의 작동하지 않습니다. QUIC은 이 왕복을 한 번, 최대 두 번으로 줄일 수 있습니다.

  2. 스트림. HTTP/2와 마찬가지로 QUIC은 동일한 연결을 통해 전달되는 개념적으로 구별되는 데이터의 독립성을 높이기 위해 애플리케이션에 여러 바이트 스트림을 제공합니다. 운송 수단에서 이런 일을 하면 독립성이 더 커질 뿐입니다. 스트림은 자연스럽게 스트리밍 비디오 전송의 요구에 부합하며, 주요 인터넷 콘텐츠 제공업체는 QUIC를 통해 스트리밍을 제공하기 위해 노력하고 있습니다.

  3. 더 나은 손실 대응. QUIC의 설계는 패킷 손실을 감지하고 복구하는 TCP의 기능을 개선합니다. 게다가 단일의 순서대로 된 바이트 스트림 대신 다중화된 스트림을 제공함으로써 하나의 객체를 포함하는 패킷이 손실되더라도 다른 객체의 전달이 지연되지 않습니다.

  4. 멀티호밍. MPTCP와 SCTP와 마찬가지로 QUIC 연결은 각 엔드포인트에 대해 여러 IP 주소와 연관될 수 있습니다. 이러한 프로토콜과 달리 QUIC은 익숙하지 않은 프로토콜 번호와 TCP 헤더 옵션을 사용하지 않고도 인터넷을 통과할 가능성이 높습니다.

  5. 보안 및 개인정보 보호. QUIC은 그 위가 아닌 전송 계층에 암호화를 적용합니다. UDP 페이로드 전체가 인증되므로 중개자에 의한 투명한 수정이 방지되며 거의 모든 전송 정보가 암호화됩니다. 이것의 결과는 그 자체로 백서입니다. 말할 것도 없이, 이를 통해 개인 정보 보호 속성이 크게 향상되고 TCP가 제공하는 공격 표면이 사실상 없어진다는 것입니다. IPSec과 달리 이는 현재 웹 규모로 실행되고 있습니다. 또한 다음으로 이어집니다.

  6. 확장성 TCP는 개발자가 제한된 확장 공간을 남겨두었고, 미들박스가 기존 TCP 동작을 강제하기 때문에 변경하기 어렵습니다. QUIC은 명시적 버전 관리와 중간 상자에 대한 불투명성을 결합하여 전송에 있어서 추가적인 혁신을 허용합니다. 이를 통해 향후 사용 사례에 대한 지원이 가능해지고 궁극적으로 TCP에 비해 대량 전송 용량이 향상됩니다.

관성 외에도 일부 애플리케이션이 QUIC로 이동하지 않는 데에는 두 가지 이유가 있습니다.

  • 복잡성: 단일 바이트 스트림만 필요하고 암호화에 관심이 없는 애플리케이션은 이러한 기능과 관련된 추가적인 작업 부하가 필요하지 않습니다.

  • 중간상자: 인터넷 경로 중 상당수는 UDP를 허용하지 않습니다. HTTP/3는 이러한 경로에 대해 TCP 폴백을 사용하도록 설계되었지만 궁극적으로 주요 웹사이트(Google, Facebook 등)의 성능에 영향을 미쳐 해당 장치가 쓸모없게 될 가능성이 높습니다. 다만 국가가 감시를 요구하는 경우는 예외입니다.

인터넷을 먹어치우고 있다

Google Chrome, Google 앱 클라이언트 및 Facebook 앱은 이미 HTTP/3를 지원합니다. Safari, Edge, Firefox 구현에서는 이 기능을 지원하지만 (지금은) 기본적으로 꺼져 있습니다.

서버 측에서는 Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly, Akamai가 구현 및/또는 배포를 완료했거나 출시에 가깝습니다. 최근 유럽의 주요 ISP가 패킷의 20%가 QUIC라고 보고했습니다. 2021년 2월 현재 웹사이트의 약 5%가 HTTP/3를 사용 하지만 RFC가 게시되면 이 수치가 증가할 것으로 예상합니다.

게다가, 표준화 기구에서는 QUIC을 HTTP 사용 사례를 넘어 확장하기 위해 많은 노력을 기울이고 있습니다. IETF의 초안 표준은 DNS, 웹소켓, SIP, 그리고 QUIC를 통한 TCP와 UDP 터널을 제안합니다. QUIC은 5G 아키텍처에 완전히 통합되기에는 약간 늦었지만, 서비스 제공자에게 QUIC의 관심과 적용 가능성은 분명합니다. 마지막으로, HTTP/2와 HTTP/3의 상위 API는 매우 유사하므로 HTTP/2 위에서 실행되는 모든 프로토콜이나 애플리케이션은 TCP 대신 HTTP/3 및 QUIC에서 실행되도록 쉽게 이식될 수 있습니다.

위협과 기회

QUIC와 HTTP/3는 다양한 시장을 형성할 것입니다 . 고성능 웹사이트와 애플리케이션은 생태계가 완전히 성숙되면 HTTP/3 및 QUIC으로 전환할 강력한 동기가 있으며, 고객들이 HTTP/2를 배포했을 때와 비슷한 속도로 HTTP/3 지원을 요구할 것으로 예상합니다.

QUIC 기반 인터넷에서 보안 제품은 근본적으로 재평가되어야 합니다. TLS 세션 키에 대한 접근 없이 패킷 검사는 훨씬 더 어렵고, 이는 일반적으로 도메인의 개인 키를 소유한 경우에만 가능합니다. 이는 단일 기능 장치 시리즈보다는 애플리케이션 수준 프록시와 통합된 보안 솔루션의 가치를 향상시킵니다.

게다가, 기존의 DDoS 방어수단 도 정비가 필요합니다. 패킷 식별 및 검사가 더 어려워졌을 뿐만 아니라 TCP syncookies가 중개자가 쉽게 스푸핑할 수 없는 "재시도 패킷"으로 대체되었습니다. 서버가 재시도 패킷 생성 및 검증의 부담을 덜도록 조정할 수 있는 표준적인 방법이 있지만, 이를 위해서는 개발 노력이 필요합니다.

기존의 4계층 부하 분산은 주소나 포트를 변경하는 흐름을 자기 자신에게 연결한 다음 동일한 서버로 라우팅할 수 없으므로 QUIC 주소 마이그레이션을 중단시킵니다. 이 문제를 조정하고 극복할 수 있는 표준은 존재하지만 투자가 필요합니다.

IETF의 MASQUE 작업 그룹은 차세대 VPN 방식 의 기반이 될 수 있는 QUIC을 통한 일반화된 트래픽 터널링을 연구하고 있습니다. QUIC의 속성은 TCP를 통한 TLS보다 임의의 흐름을 다중화하는 데 훨씬 더 뛰어납니다. 이러한 터널은 IPSec 터널을 웹 스케일 암호화로 대체하여 일부 서비스 공급자의 사용 사례를 개선하고 , 명시적 클라이언트 동의를 받아 모바일 링크 유형에 대한 QUIC 연결을 최적화하는 방법도 제공할 수 있습니다.

QUIC에는 새로운 네트워크 측정 및 분석 도구가 필요합니다. TCP 지연 및 손실을 측정할 수 있는 시스템은 이러한 신호를 사용할 수 없지만, 네트워크에 명시적인 지연 신호 가 있고 다른 신호가 발생할 수도 있습니다. 암호화 뒤에 숨겨진 전송 정보가 많아질수록 패킷 캡처는 그다지 유용하지 않습니다. 그러나 많은 QUIC 구현체가 따르는 새로운 표준 로깅 형식이 등장하고 있으며, 사람들은 이를 활용하여 분석 도구를 구축하고 있습니다.

F5는 개발 상황을 면밀히 주시하고 있습니다.

F5 직원은 수년간 IETF의 표준화 활동을 모니터링하고 고객에게 도움이 될 것이라고 생각되는 분야에 기여해 왔습니다. BIG-IP는 TMOS v15.1.0.1 이후의 공개 릴리스를 포함하여 처음부터 QUIC 및 HTTP/3의 초안 릴리스를 추적해 왔습니다. NGINX에는 HTTP/3 알파 릴리스 가 있으며, 곧 메인라인에 통합될 예정입니다.

우리는 이 분야의 동향을 계속 지켜보고 이러한 프로토콜이 제공하는 새로운 기능을 반영하는 새롭고 흥미로운 제품을 구축할 것입니다.

결론

QUIC은 업계에서 폭넓은 지지를 받고 있으며, 인터넷을 통해 비즈니스 가치를 제공하는 대부분 애플리케이션의 기반이 될 수 있는 잠재력을 갖추고 있습니다. 인터넷을 통해 애플리케이션을 제공하는 모든 사람은 이러한 프로토콜이 가져오는 새로운 위협과 기회를 반영하기 위해 운영을 어떻게 변경해야 할지 생각해야 합니다.