맨위로가기

QUIC

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

QUIC는 TCP와 유사한 역할을 하는 차세대 전송 프로토콜로, 구글이 개발한 gQUIC을 기반으로 IETF에서 표준화가 진행되었다. TCP의 회선 선두 차단 문제를 해결하고, 연결 설정 지연 시간을 줄이며, 네트워크 환경 변화에 유연하게 대응하기 위해 UDP를 기반으로 설계되었다. QUIC는 HTTP/3, DNS-over-QUIC, SMB over QUIC 등 다양한 응용 분야에 적용되고 있으며, 구글 크롬, 파이어폭스, 사파리 등 주요 브라우저에서 지원된다. 다양한 서버 및 클라이언트 구현이 존재하며, Microsoft, Cloudflare, Facebook 등에서 도입하여 사용하고 있다.

더 읽어볼만한 페이지

  • 전송 계층 프로토콜 - 사용자 데이터그램 프로토콜
    사용자 데이터그램 프로토콜(UDP)은 연결 설정 없이 데이터를 전송하는 비연결형 전송 프로토콜로, 메시지 전달 보장은 상위 계층에 맡기지만 속도가 중요한 애플리케이션에서 널리 사용된다.
  • 전송 계층 프로토콜 - 전송 제어 프로토콜
    전송 제어 프로토콜(TCP)은 인터넷 모델의 전송 계층에서 신뢰성 있는 통신을 제공하며 순서 보장, 오류 검출, 흐름 및 혼잡 제어 기능을 수행하는 프로토콜로, 웹 브라우징 등 다양한 인터넷 응용 프로그램에서 사용되고 TCP/IP 모델의 핵심이다.
  • 컴퓨터 네트워킹 - 유니캐스트
    유니캐스트는 데이터를 단일 목적지로 전송하는 방식으로, 브로드캐스트 및 멀티캐스트와 대비되며, 개인적 또는 고유한 리소스가 필요한 네트워크 프로세스에 사용되지만, 대량 데이터 전송 시 비용이 증가하는 단점이 있다.
  • 컴퓨터 네트워킹 - 노드 (네트워크)
    노드(네트워크)는 데이터 통신에서 데이터를 주고받는 장치를 의미하며, 물리적 네트워크 노드, 인터넷 노드, 통신 네트워크 노드, 분산 시스템 노드, 네트워크 가상화 노드 등으로 분류된다.
  • 인터넷 프로토콜 - IPTV
    IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다.
  • 인터넷 프로토콜 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
QUIC
개요
이름퀵 (QUIC)
''
''
목적범용
개발자IETF, 구글
시작일2012년 10월 12일
기반IP, 일반적으로 UDP와 함께 사용
OSI 모델전송 계층
RFC9000
8999
9001
9002

2. 역사적 배경

전송 제어 프로토콜(TCP)은 인터넷 통신에서 데이터 스트림을 안정적으로 전송하는 핵심 프로토콜이다. TCP는 데이터를 네트워크 패킷으로 나누고, 각 패킷에 시퀀스 번호와 체크섬을 추가하여 손실되거나 순서가 바뀐 패킷, 오류가 있는 패킷을 감지한다.[10] 문제가 발생하면 TCP는 자동 재전송 요청(ARQ)을 통해 재전송을 요청한다.[10]

하지만 TCP는 연결에 오류가 발생하면 모든 전송을 중단하는 특성이 있다. HTTP/2처럼 하나의 연결로 여러 스트림을 전송하는 경우, 한 스트림의 오류가 다른 스트림까지 지연시키는 회선 선두 차단 현상이 발생한다.[10] 예를 들어, 웹 페이지를 로딩할 때 favicon 이미지 다운로드 중 오류가 발생하면, 해당 오류가 해결될 때까지 페이지의 나머지 부분은 대기해야 한다.[10]

또한 TCP는 프로토콜 경화 문제로 인해 개선이 어렵다. TCP 와이어 이미지가 평문으로 되어 있어 미들박스에서 보고 조작할 수 있기 때문이다. 한 측정에 따르면 인터넷 경로의 3분의 1이 TCP 메타데이터를 수정하는 중간자를 만나고, 6.5%의 경로가 중간자의 유해한 경화 효과를 경험한다. 다중 경로 TCP(MPTCP)나 TCP Fast Open과 같은 TCP 확장 기능도 미들박스의 영향을 받는다.

2. 1. Google QUIC (gQUIC)

2012년 구글에서 개발하여 IETF에 제안된 초기 QUIC 버전(gQUIC)은 IETF에서 발전, 개선된 QUIC과는 상당한 차이가 있었다. 원래 gQUIC는 범용 프로토콜로 설계되었지만, 초기에는 크롬에서 HTTP(S)를 지원하는 프로토콜로 배포되었다. 현재 IETF QUIC 프로토콜은 범용 전송 프로토콜로 발전하였다. 크롬 개발자들은 IETF QUIC의 표준화 노력을 지속적으로 추적하여 크롬에서 QUIC에 대한 최신 인터넷 표준을 채택하고 완전히 준수했다.[63]

TCP 개선은 구글의 장기적인 목표이며, QUIC의 목적은 독립적인 TCP 연결과 동등하게 만드는 것이지만, 가능한 한 레이턴시를 줄이고 (목표는 왕복 시간 없는 일반적인 연결) SPDY 지원을 추진하는 것이다. 만약 QUIC의 기능 효과가 실증된다면, TCP나 TLS의 후속 버전에 그 지견을 반영할 수 있다.

QUIC 개발 동기 중 하나는 TCP에서 단일 패킷의 지연이 SPDY 스트림 집합 전체에서 head-of-line blocking|호선 차단영어을 일으킨다는 사실이다. QUIC에서는 TCP를 사용하지 않고 다중화에 대응함으로써, 패킷의 지연이나 폐기가 발생해도 영향을 받는 것은 관계하는 스트림에 한정되도록 하고 있다.

물리적 제약 (광속 등)에 의해 정해지는 왕복 시간을 단축하는 것은 현재 과학적 지견으로는 불가능하다고 여겨지고 있으며, 그 외에 통신의 레이턴시를 줄이는 방법은 통신 거점 간의 메시지 왕복(라운드 트립) 횟수를 줄이는 것이다. QUIC에서 이루어지는 작업 대부분은 핸드셰이크 단계, 암호화 설정, 초기 데이터 요청을 포함한 새로운 연결이 왔을 때 필요한 라운드 트립을 줄이는 데 집중되어 있다. 예를 들어, 한 번 연결했던 서버에 대한 레이턴시 없는 (0-RTT) 연결 확립 (최상의 경우)을 들 수 있다.

QUIC에서는, 암호화 블록 경계나 패킷 경계를 정렬함으로써 packet loss|패킷 손실영어의 영향을 줄인다. TCP가 혼잡을 피하기 위해 congestion window|혼잡 윈도우영어를 사용하고 (TCP congestion avoidance algorithm|TCP 혼잡 회피 알고리즘영어 참조), 다중화 연결에 대응하지 않는 것에 비해, QUIC에는 검토 중이면서 현대적인 기술 집합이 있다. 테스트된 기술에는 패킷 페이싱 (대역폭 추정을 하면서)과 적극적이고 추론적인 재전송 (오류 정정이나 초기 암호화 협상과 같은 가장 중요한 패킷의 중복된 복사본을 전송)이 있다. 또한, 순방향 오류 정정과 같이, 초안 단계에서 채용되었지만, 충분한 효과를 얻지 못했기 때문에 제거된 기능도 있다.[63]

중복된 데이터 전송 (헤더 등)의 감소 및 압축은 보다 높은 수준의 애플리케이션 프로토콜 (SPDY와 같은)로 실현 가능하게 하고 있다.

2. 2. IETF 표준화

IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)는 QUIC을 범용 전송 프로토콜로 표준화하는 작업을 진행했다. IETF QUIC은 gQUIC의 기본 개념을 유지하면서, 보안 및 성능을 개선하고 다양한 응용 분야에 적용할 수 있도록 설계되었다.[63] QUIC 개발의 동기 중 하나는, TCP에서 단일 패킷의 지연이 SPDY 스트림의 집합 전체에서 head-of-line blocking|호선 차단영어을 일으킨다는 사실이다. QUIC에서는 TCP를 사용하지 않고 다중화에 대응함으로써, 패킷의 지연이나 폐기가 발생해도 영향을 받는 것은 관계하는 스트림에 한정되도록 하고 있다.

물리적인 제약 (광속 등)에 의해 정해지는 왕복 시간을 단축하는 것은 현재 과학적 지견으로는 불가능하다고 여겨지고 있으며, 그 외에 통신의 레이턴시를 줄이는 방법은 통신 거점 간의 메시지 왕복(라운드 트립) 횟수를 줄이는 것이다. QUIC에서 이루어지는 작업의 대부분은 핸드셰이크 단계, 암호화 설정, 초기 데이터의 요청을 포함한 새로운 연결이 왔을 때 필요한 라운드 트립을 줄이는 데 집중되어 있다. 예를 들어, 한 번 연결했던 서버에 대한 레이턴시 없는 (0-RTT) 연결 확립 (최상의 경우)을 들 수 있다.

QUIC에서는 암호화 블록 경계나 패킷 경계를 정렬함으로써 packet loss|패킷 손실영어의 영향을 줄인다. TCP가 혼잡을 피하기 위해 congestion window|혼잡 윈도우영어를 사용하고 (TCP congestion avoidance algorithm|TCP 혼잡 회피 알고리즘영어 참조), 다중화 연결에 대응하지 않는 것에 비해, QUIC에는 검토 중이면서 현대적인 기술의 집합이 있다. 테스트된 기술에는 패킷 페이싱 (대역폭 추정을 하면서)과 적극적이고 추론적인 재전송 (오류 정정이나 초기 암호화 협상과 같은 가장 중요한 패킷의 중복된 복사본을 전송)이 있다. 또한, 순방향 오류 정정과 같이 초안 단계에서 채용되었지만, 충분한 효과를 얻지 못했기 때문에 제거된 기능도 있다.[63]

3. 특징

QUIC는 TCP와 유사한 역할을 하지만, 연결 설정 시간을 단축하고 패킷 손실 복구를 효율적으로 수행하여 전반적인 성능을 향상시킨다.[10] 이는 주로 HTTP 트래픽의 동작에 대한 이해를 바탕으로 이루어진다.[10]

QUIC는 다음과 같은 주요 특징을 가진다.


  • '''연결 설정 단축:''' HTTPS와 같이 보안 연결이 필요한 경우, QUIC는 초기 핸드셰이크 과정에서 암호화 및 프로토콜 협상을 함께 처리하여 연결 설정 시간을 단축한다.
  • '''향상된 패킷 손실 복구:''' UDP를 기반으로 하며, 각 스트림별로 흐름 제어를 수행하여 한 스트림에서 패킷 손실이 발생해도 다른 스트림은 영향을 받지 않는다.
  • '''연결 마이그레이션:''' 연결 식별자를 사용하여 IP 주소가 변경되더라도 연결을 유지한다.
  • '''보안 강화:''' 모든 패킷을 개별적으로 암호화하여 보안을 강화한다.


QUIC는 배포 가능하고, 진화 가능하며, 경화 방지 속성을 갖도록 특별히 설계되었다. 이는 이러한 목적을 위해 와이어 이미지를 의도적으로 최소화하는 최초의 IETF 전송 프로토콜이다. 암호화된 헤더 외에도, 'greased'되어 프로토콜 불변성이 명시적으로 지정되어 있다. TCP 개선은 구글의 장기적인 목표이며, QUIC의 목적은 독립적인 TCP 연결과 동등하게 만드는 것이지만, 가능한 한 지연 시간을 줄이고 SPDY 지원을 추진하는 것이다. 만약 QUIC의 기능이 효과적임이 입증된다면, TCP나 TLS의 후속 버전에 그 지견을 반영할 수 있다.

3. 1. 연결 설정 단축

QUIC는 암호화된 HTTP 트래픽을 지원하며, TCP와 유사한 역할을 하지만 연결 설정 시 지연 시간을 줄이는 데 초점을 맞추고 있다.[10] 특히, 보안 연결이 필요한 경우에 더욱 효과적이다.

TLS 1.2를 사용한 TCP와 QUIC의 핸드셰이크 비교


QUIC는 초기 핸드셰이크 과정에서 암호화 및 프로토콜 협상을 함께 처리한다. 클라이언트가 연결을 열면, 응답 패킷에 향후 패킷 암호화에 필요한 데이터가 포함된다. 이를 통해 TCP 연결 설정 후 별도 패킷을 통해 보안 프로토콜을 협상하는 과정을 생략할 수 있다.[10] 즉, 여러 단계를 단일 요청-응답으로 결합하여 연결 설정에 필요한 왕복 시간(Round Trip Time, RTT)을 줄인다.

한 번 연결했던 서버에 대해서는 지연 없는(0-RTT) 연결 확립도 가능하다.

3. 2. 향상된 패킷 손실 복구

QUIC는 UDP를 기반으로 하며, 각 스트림별로 흐름 제어를 수행한다. 따라서 한 스트림에서 패킷 손실이 발생하더라도 다른 스트림은 영향을 받지 않고 계속 데이터를 전송할 수 있다. 이는 TCP의 회선 선두 차단 문제를 해결한다.[11] QUIC에서는 TCP를 사용하지 않고 다중화에 대응함으로써, 패킷의 지연이나 폐기가 발생해도 영향을 받는 것은 관계되는 스트림에 한정된다.

3. 3. 연결 마이그레이션

QUIC는 연결 식별자를 사용하여 클라이언트의 IP 주소가 변경되더라도 연결을 유지할 수 있도록 해준다. 각 연결은 연결 ID로 식별되는데, 통신하는 양쪽 모두 연결 ID를 생성한다. 자신이 생성하는 것을 송신자 연결 ID, 상대방이 생성하는 것을 수신자 연결 ID라고 부른다.[65] 연결 ID는 필요에 따라 변경할 수 있다.[65]

이러한 연결 ID 덕분에, TCP와 달리 IP 주소나 포트 번호가 바뀌어도 연결이 끊어지지 않는다. 예를 들어, 사용자가 Wi-Fi에서 모바일 네트워크로 전환하는 경우에도 연결이 유지된다. 이러한 IP 주소 및 포트 번호 변화에 따른 처리를 연결 마이그레이션이라고 한다.[12]

3. 4. 보안 강화

QUIC는 모든 패킷을 개별적으로 암호화하여 중간자 공격(Man-in-the-Middle Attack)을 방지하고 데이터 보안을 강화한다.[10] 이는 TCP에서는 불가능한데, TCP에서는 암호화 레코드가 바이트스트림에 있으며 프로토콜 스택은 이 스트림 내의 상위 계층 경계를 인식하지 못하기 때문이다.

4. 기술적 세부 사항

QUIC는 암호화된 HTTP 트래픽을 지원하는 맥락에서 TCP와 유사한 역할을 하지만, 연결 설정 시 지연 시간을 줄이고 여러 HTTP 스트림을 단일 연결을 통해 다중화할 때 손실 복구를 보다 효율적으로 수행한다.[10] 이는 주로 HTTP 트래픽의 동작에 대한 이해를 바탕으로 하는 두 가지 변경을 통해 이루어진다.

첫 번째는 연결 설정 중 오버헤드를 크게 줄이는 것이다. 대부분의 HTTP 연결이 TLS를 요구하므로 QUIC는 설정 키와 지원되는 프로토콜의 교환을 초기 핸드셰이크 프로세스의 일부로 만든다. 클라이언트가 연결을 열면 응답 패킷에는 향후 패킷이 암호화를 사용하는 데 필요한 데이터가 포함된다. 이를 통해 TCP 연결을 설정한 다음 추가 패킷을 통해 보안 프로토콜을 협상할 필요가 없어진다. 다른 프로토콜도 동일한 방식으로 서비스할 수 있으며, 여러 단계를 단일 요청-응답 쌍으로 결합한다. 이 데이터는 초기 설정의 후속 요청과 별도의 연결로 협상될 수 있는 향후 요청 모두에 사용될 수 있다.[10]

두 번째 변경은 TCP 대신 UDP를 기반으로 사용한다는 점이다. UDP에는 손실 복구가 포함되어 있지 않다. 대신, 각 QUIC 스트림은 개별적으로 흐름 제어되며 손실된 데이터는 UDP가 아닌 QUIC 수준에서 재전송된다. (자세한 내용은 스트림 및 혼잡 제어 섹션 참조)

QUIC는 전반적인 지연 시간과 처리량을 개선하는 다른 여러 가지 변경 사항을 포함한다. 예를 들어, 패킷은 개별적으로 암호화되므로 부분 패킷을 기다리는 암호화된 데이터가 발생하지 않는다. 이는 일반적으로 TCP에서는 불가능하다. TCP에서는 암호화 레코드가 바이트스트림에 있으며 프로토콜 스택은 이 스트림 내의 상위 계층 경계를 인식하지 못한다. 이는 상위에서 실행되는 계층에서 협상할 수 있지만 QUIC는 이 모든 것을 단일 핸드셰이크 프로세스에서 수행하는 것을 목표로 한다.

QUIC 시스템의 또 다른 목표는 사용자가 로컬 Wi-Fi 핫스팟에서 이동 통신망으로 이동하는 경우와 같이 네트워크 전환 이벤트 동안의 성능을 개선하는 것이었다. TCP에서 이러한 현상이 발생하면 기존의 모든 연결이 하나씩 시간 초과되고, 필요에 따라 다시 설정되는 긴 프로세스가 시작된다. 이 문제를 해결하기 위해 QUIC는 소스에 관계없이 서버에 대한 연결을 고유하게 식별하는 연결 식별자를 포함한다. 이를 통해 사용자의 IP 주소가 변경되더라도 원래 연결 ID가 유효하므로 이 ID를 항상 포함하는 패킷을 전송하여 연결을 간단하게 다시 설정할 수 있다.[12]

QUIC는 운영 체제 커널이 아닌 응용 프로그램 공간에서 구현된다. QUIC는 단일 응용 프로그램에서 사용하도록 설계되었으며, QUIC를 사용하는 각 응용 프로그램은 UDP에서 호스팅되는 자체 연결을 갖는다. 전반적인 HTTP/2 스택의 대부분은 이미 응용 프로그램(또는 더 일반적으로 라이브러리)에 있기 때문에, 나머지 부분을 오류 수정과 같은 라이브러리에 배치하면 HTTP/2 스택의 크기나 전반적인 복잡성에 거의 영향을 미치지 않는다.

이러한 구성은 업데이트를 위해 커널을 변경할 필요가 없으므로 향후 변경 사항을 더 쉽게 만들 수 있다. QUIC의 장기적인 목표 중 하나는 순방향 오류 수정 (FEC) 및 향상된 혼잡 제어를 위한 새로운 시스템을 추가하는 것이다.[12]

TCP에서 UDP로의 전환에 대한 한 가지 우려는 TCP가 널리 채택되었고 인터넷 인프라의 많은 "중간 상자"가 TCP에 맞춰져 있으며 UDP를 속도 제한하거나 차단한다는 것이다. 구글은 이를 특성화하기 위해 여러 탐색 실험을 수행했으며, 이 방식으로 차단된 연결이 소수에 불과하다는 것을 발견했다. 이는 신속한 TCP로의 폴백 시스템으로 이어졌다. 크롬의 네트워크 스택은 QUIC 및 기존 TCP 연결을 동시에 열어 지연 시간을 거의 줄일 수 있도록 한다.[13]

4. 1. 스트림 (Streams)

QUIC에서의 스트림은 QUIC 연결 내에서 애플리케이션 데이터를 주고받는 통신로이다. 하나의 QUIC 연결 내에서 여러 스트림을 다중화하여 각각 병렬로 데이터를 전송할 수 있다. 각 스트림은 62비트 정수 값인 스트림 ID로 구분된다. 스트림은 서버와 클라이언트 모두에서 확립될 수 있으며, 단방향 전송을 수행하는 스트림과 양방향 전송을 수행할 수 있는 스트림이 있다.[66]

QUIC의 스트림은 TCP처럼 순차적인 바이트 지향 스트림이며, 메시지 경계가 유지된다는 보장은 없다.[66]

4. 2. 데이터그램 (Datagrams)

QUIC 연결에서 애플리케이션 데이터를 주고받는 두 번째 방법은 데이터그램이다. 데이터그램은 확장으로 제기되었으며, UDP나 DTLS처럼 신뢰성이 없는 데이터 전송을 목적으로 한다.[67]

플로우 제어는 없지만, 혼잡 제어는 수행된다.[67]

4. 3. 혼잡 제어

QUIC는 UDP를 기반으로 하며, 손실 복구는 UDP가 아닌 QUIC 수준에서 이루어진다. 각 QUIC 스트림은 개별적으로 흐름이 제어되며 손실된 데이터는 QUIC 수준에서 재전송된다.[11] 즉, 한 스트림에서 오류가 발생하더라도 프로토콜 스택은 다른 스트림을 계속 서비스할 수 있다. TCP가 패킷 누락이나 손상을 인지하기 전에 많은 양의 데이터를 수신할 수 있고, 오류 수정 동안 이 데이터가 차단되거나 플러시되는 경우가 많은데, QUIC에서는 단일 다중화 스트림이 복구되는 동안 이 데이터를 자유롭게 처리할 수 있다.[11]

QUIC는 혼잡을 피하기 위해 혼잡 윈도우를 사용하는 TCP와 달리, 다중화 연결에 대응하지 않는 현대적인 기술들을 검토 중이다. 테스트된 기술에는 패킷 페이싱 (대역폭 추정을 하면서)과 적극적이고 추론적인 재전송 (오류 정정이나 초기 암호화 협상과 같은 가장 중요한 패킷의 중복된 복사본을 전송)이 있다.[63] 또한, 순방향 오류 정정과 같이 초안 단계에서 채택되었지만 충분한 효과를 얻지 못해 제거된 기능도 있다.[63]

5. 응용 분야

QUIC는 HTTP/3 외에도 다양한 분야에서 활용되고 있다. IETF는 QUIC를 안전한 네트워크 터널링[15] 및 스트리밍 미디어 전송에 적용하는 방안을 개발하고 있다.[17] XMPP는 QUIC를 실험적으로 채택했다.[18] 마이크로소프트는 SMB over QUIC를 통해 사용자 경험에 영향을 주지 않으면서 "SMB VPN"을 제공할 수 있다고 밝혔다.[19] SMB 클라이언트는 기본적으로 TCP를 사용하며, TCP 시도가 실패하거나 의도적으로 QUIC를 요구하는 경우 QUIC를 시도한다.

5. 1. HTTP/3

QUIC는 HTTP를 염두에 두고 개발되었으며, HTTP/3가 첫 번째 애플리케이션이었다.[14][15] QUIC는 TCP를 사용하지 않고 다중화에 대응함으로써, 패킷의 지연이나 폐기가 발생해도 영향을 받는 것은 관계하는 스트림에 한정되도록 하여 호선 차단(head-of-line blocking) 문제를 해결한다.

QUIC 상의 애플리케이션 계층 프로토콜로서 우선 HTTP를 이용 가능하게 하는 표준화가 진행되고 있으며,[68] QUIC를 이용하는 HTTP의 명칭은 HTTP/3가 될 예정이다.

5. 2. DNS over QUIC

DNS-over-QUIC는 QUIC를 이름 확인에 적용한 것으로, DNS-over-TLS와 유사하게 리졸버 간에 전송되는 데이터의 보안을 제공한다.[16]

5. 3. 기타 응용 분야

QUIC는 HTTP를 염두에 두고 개발되었으며, HTTP/3가 첫 번째 애플리케이션이었다.[14][15] DNS-over-QUIC는 QUIC를 이름 확인에 적용한 것으로, DNS-over-TLS와 유사하게 리졸버 간에 전송되는 데이터의 보안을 제공한다.[16] IETF는 QUIC를 안전한 네트워크 터널링[15] 및 스트리밍 미디어 전송에 적용하는 방안을 개발하고 있다.[17] XMPP는 QUIC를 사용하도록 실험적으로 채택되었다.[18] 또 다른 애플리케이션은 QUIC를 통한 SMB로, Microsoft에 따르면 사용자 경험에 영향을 미치지 않으면서 "SMB VPN"을 제공할 수 있다.[19] SMB 클라이언트는 기본적으로 TCP를 사용하며, TCP 시도가 실패하거나 의도적으로 QUIC를 요구하는 경우 QUIC를 시도한다.

DNS에서의 이용은 DNS over Dedicated QUIC Connections로 규정되어 있다.[97] 또한 마이크로소프트는 SMB를 QUIC에 대응시키고 있다.

이 외에도 SSH[98], WebRTC[99]와 같은 애플리케이션 계층 프로토콜에서도 QUIC을 이용 가능하게 하는 것을 검토하고 있다.

6. 구현 및 채택 현황

QUIC는 여러 웹 브라우저, 서버, 클라이언트 라이브러리에서 지원되고 있다.


  • 브라우저 지원:
  • 구글 크롬은 2012년부터 QUIC 코드를 실험적으로 개발하여 2013년에 출시된 크로미움 버전 29에 포함시켰으며, 현재 크로미움과 크롬에서 기본적으로 활성화되어 있다.[8][20][70]
  • 파이어폭스는 2021년 5월부터 QUIC을 지원하기 시작했다.[21][3]
  • 애플은 2020년 4월 WebKit 엔진을 통해 Safari Technology Preview 104에 QUIC에 대한 실험적 지원을 추가했고, 사파리 14에서 공식 지원을 추가하여 macOS 빅 서와 iOS 14에 포함시켰으나, 초기에는 수동으로 활성화해야 했다.[22][23][24] 이후 사파리 16에서 기본적으로 활성화되었다.[25]

  • 서버 지원:
  • 구글 서버는 QUIC를 지원하며 프로토타입 서버를 공개했다.[32]
  • 아카마이 테크놀로지스(Akamai Technologies)는 2016년 7월부터 QUIC를 지원해 왔다.[33][34]
  • quic-go[35]라는 Go 구현이 있으며, 이는 Caddy 서버에서 실험적인 QUIC 지원을 제공한다.[36]
  • 2017년 7월 11일, 라이트스피드 테크놀로지스(LiteSpeed Technologies)는 공식적으로 로드 밸런서(WebADC)[37] 및 라이트스피드 웹 서버(LiteSpeed Web Server) 제품에서 QUIC를 지원하기 시작했다.[38]
  • 2019년 10월 기준, QUIC 웹사이트의 88.6%가 라이트스피드를 사용했으며, 10.8%가 Nginx를 사용했다.[39]
  • 페이스북(Facebook)은 2018년에 이 기술을 출시했으며,[8] 클라우드플레어(Cloudflare)는 2018년부터 베타 방식으로 QUIC 지원을 제공하고 있다.[40]
  • HAProxy 로드 밸런서는 2022년 3월에 QUIC에 대한 실험적 지원을 추가했으며,[41] 2023년 3월에 프로덕션 준비가 완료되었음을 선언했다.[42]
  • 2023년 4월 기준, 전체 웹사이트의 8.9%가 QUIC를 사용하며,[43] 이는 2021년 3월의 5%에서 증가한 수치이다.
  • 마이크로소프트 윈도우 서버 2022(Microsoft Windows Server 2022)는 MsQuic을 통해 HTTP/3[44] 및 SMB over QUIC[45][1] 프로토콜을 모두 지원한다.
  • 시트릭스(Citrix)의 애플리케이션 딜리버리 컨트롤러(Citrix ADC, NetScaler)는 버전 13부터 QUIC 프록시 역할을 할 수 있다.[46][47]

  • 클라이언트 지원:
  • 구글 플레이 서비스를 통해 안드로이드 애플리케이션에서 Cronet 라이브러리를 사용하여 QUIC 및 기타 프로토콜을 지원하는 모듈을 로드할 수 있다.[26]
  • 2019년 9월 11일에 출시된 cURL 7.66 버전은 HTTP/3 (및 QUIC)를 지원한다.[27][28]
  • 2020년 10월, 페이스북은 인스타그램을 포함한 자사의 앱과 서버 인프라를 QUIC으로 성공적으로 마이그레이션했으며, 이미 인터넷 트래픽의 75%가 QUIC을 사용한다고 발표했다.[29]
  • 유튜브, Gmail을 포함한 구글의 모든 모바일 앱과 우버의 모바일 앱도 QUIC을 지원한다.[30][31]

6. 1. 브라우저 지원

구글 크롬은 2012년부터 QUIC 코드를 실험적으로 개발했으며,[8] 2013년 8월 20일에 출시된 크로미움 버전 29에 포함되었다.[20] 현재 크로미움과 크롬에서 기본적으로 활성화되어 있다.[70]

파이어폭스는 2021년 5월에 QUIC을 지원하기 시작했다.[21][3]

애플은 2020년 4월 WebKit 엔진을 통해 Safari Technology Preview 104에 QUIC에 대한 실험적 지원을 추가했다.[22] 사파리 14에서 공식 지원이 추가되었으며, macOS 빅 서와 iOS 14에 포함되었지만,[23] 이 기능은 수동으로 활성화해야 했다.[24] 이후 사파리 16에서 기본적으로 활성화되었다.[25]

6. 2. 서버 지원

구글 서버는 QUIC를 지원하며 프로토타입 서버를 공개했다.[32] 아카마이 테크놀로지스(Akamai Technologies)는 2016년 7월부터 QUIC를 지원해 왔다.[33][34] quic-go[35]라는 Go 구현이 있으며, 이는 Caddy 서버에서 실험적인 QUIC 지원을 제공한다.[36] 2017년 7월 11일, 라이트스피드 테크놀로지스(LiteSpeed Technologies)는 공식적으로 로드 밸런서(WebADC)[37] 및 라이트스피드 웹 서버(LiteSpeed Web Server) 제품에서 QUIC를 지원하기 시작했다.[38] 2019년 10월 기준, QUIC 웹사이트의 88.6%가 라이트스피드를 사용했으며, 10.8%가 Nginx를 사용했다.[39]

처음에는 구글 서버만 HTTP-over-QUIC 연결을 지원했지만, 페이스북(Facebook)도 2018년에 이 기술을 출시했으며,[8] 클라우드플레어(Cloudflare)는 2018년부터 베타 방식으로 QUIC 지원을 제공하고 있다.[40] HAProxy 로드 밸런서는 2022년 3월에 QUIC에 대한 실험적 지원을 추가했으며,[41] 2023년 3월에 프로덕션 준비가 완료되었음을 선언했다.[42] 2023년 4월 기준, 전체 웹사이트의 8.9%가 QUIC를 사용하며,[43] 이는 2021년 3월의 5%에서 증가한 수치이다.

마이크로소프트 윈도우 서버 2022(Microsoft Windows Server 2022)는 MsQuic을 통해 HTTP/3[44] 및 SMB over QUIC[45][1] 프로토콜을 모두 지원한다. 시트릭스(Citrix)의 애플리케이션 딜리버리 컨트롤러(Citrix ADC, NetScaler)는 버전 13부터 QUIC 프록시 역할을 할 수 있다.[46][47]

6. 3. 클라이언트 지원

구글 플레이 서비스를 통해 안드로이드 애플리케이션에서 Cronet 라이브러리를 사용하여 QUIC 및 기타 프로토콜을 지원하는 모듈을 로드할 수 있다.[26]

2019년 9월 11일에 출시된 cURL 7.66 버전은 HTTP/3 (및 QUIC)를 지원한다.[27][28]

2020년 10월, 페이스북은 인스타그램을 포함한 자사의 앱과 서버 인프라를 QUIC으로 성공적으로 마이그레이션했으며, 이미 인터넷 트래픽의 75%가 QUIC을 사용한다고 발표했다.[29] 유튜브, Gmail을 포함한 구글의 모든 모바일 앱과 우버의 모바일 앱도 QUIC을 지원한다.[30][31]

7. 단점

QUIC는 ACK 패킷 등 제어 정보도 암호화하기 때문에 TCP 가속과 같은 수단을 사용하여 RTT를 줄일 수 없다.[100]

8. 소스 코드

QUIC 및 gQUIC 구현 (소스 코드 형태)
구현체라이선스언어설명
ChromiumBSD 허가서C++Chrome 웹 브라우저의 소스 코드이자 gQUIC 참조 구현이다. 테스트용 독립형 gQUIC 및 QUIC 클라이언트/서버 프로그램을 포함한다. [https://chromium.googlesource.com/chromium/src/net/+/master/quic 소스 코드]. LINE의 [https://github.com/line/stellite stellite]와 Google의 cronet의 기반이기도 하다.
[https://github.com/facebookincubator/mvfst QUIC Library (mvfst)]MIT 허가서C++Facebook의 IETF QUIC 프로토콜 클라이언트/서버 구현 (C++).
[https://github.com/litespeedtech/lsquic LiteSpeed QUIC Library (lsquic)]MIT 허가서CLiteSpeed Web Server 및 [https://www.openlitespeed.org/ OpenLiteSpeed]에서 사용하는 QUIC 및 HTTP/3 구현.
[https://github.com/ngtcp2/ngtcp2 ngtcp2]MIT 허가서COpenSSL 또는 GnuTLS와 함께 작동하는 QUIC 라이브러리 (암호화 라이브러리 불문). HTTP/3에는 [https://github.com/ngtcp2/nghttp3 nghttp3] 같은 별도 라이브러리가 필요하다.
[https://github.com/cloudflare/quiche Quiche]BSD 허가서RustC/C++ 애플리케이션에서 사용하기 위한 C API를 제공한다(소켓 불문).
[https://github.com/h2o/quicly quicly]MIT 허가서C[https://h2o.examp1e.net/ H2O 웹 서버]의 QUIC 구현.
[https://github.com/quic-go/quic-go quic-go]MIT 허가서GoGo에 QUIC 지원을 제공한다.
[https://github.com/quinn-rs/quinn Quinn]아파치 라이선스 2.0, MIT 허가서RustRust로 구현된 비동기 친화적인 QUIC 구현.
[https://github.com/mozilla/neqo Neqo]아파치 라이선스 2.0, MIT 허가서Rust모질라의 구현으로, Firefox 웹 브라우저의 네트워크 라이브러리인 Necko에 통합될 예정이다.
[https://github.com/aiortc/aioquic aioquic]BSD 허가서Python클라이언트와 서버 모두에 적합한 I/O 없는 API를 제공한다.
[https://github.com/private-octopus/picoquic picoquic]MIT 허가서CIETF 사양에 맞춘 최소 QUIC 구현.
[https://pquic.org pquic]MIT 허가서CeBPF 가상 머신을 포함하는 확장 가능한 QUIC 구현 (플러그인으로 확장 동적 로드).
MsQuicMIT 허가서C마이크로소프트의 범용 QUIC 라이브러리 (크로스 플랫폼).
[https://github.com/NTAP/quant QUANT]BSD 허가서CPOSIX 플랫폼(Linux, MacOS, FreeBSD 등) 및 임베디드 시스템 지원.
[https://github.com/kazu-yamamoto/quic quic]BSD 허가서HaskellHaskell 경량 스레드 기반 QUIC 구현.
[https://github.com/netty/netty-incubator-codec-quic netty-incubator-codec-quic]아파치 라이선스 2.0Java[https://github.com/cloudflare/quiche Quiche] 구현 기반 netty의 QUIC 구현.
[https://github.com/nodejs/quic/blob/master/doc/api/quic.md nodejs-quic]MIT 라이선스NodeJsNodejs에 대한 QUIC를 구현하는 실험적인 패키지이다.
[https://github.com/aws/s2n-quic s2n-quic]아파치 라이선스 2.0Rust아마존 웹 서비스의 오픈 소스 Rust 구현
[https://github.com/swift-quic/swift-quic swift-quic]아파치 라이선스 2.0Swift[https://www.swift.org/sswg/ Swift Server Workgroup]에서 인큐베이션을 위해 제안된 Swift 구현이다.
[https://github.com/tencent/tquic TQUIC]아파치 라이선스 2.0Rust고성능, 경량, 크로스 플랫폼 QUIC 라이브러리
nginxBSD-2-조항 라이선스C오픈 소스 QUIC 서버 구현
HAProxyGNU 일반 공중 사용 허가서 버전 2C오픈 소스 QUIC 서버 구현
[https://bitbucket.org/pjtr/kwik/ kwik]GNU 약소 일반 공중 사용 허가서 버전 3JavaQUIC 프로토콜 (RFC 9000)의 클라이언트 및 서버 구현(100% Java). [https://bitbucket.org/pjtr/flupke "Flupke"] 추가 기능을 사용하여 HTTP3 (RFC 9114)를 지원한다.



QUIC 구현 소프트웨어(라이브러리) 정보는 [https://github.com/quicwg/base-drafts/wiki/Implementations Implementations · quicwg/base-drafts Wiki · GitHub]에서 확인할 수 있다.

구글 코드는 BSD 라이선스로 공개되어 있으며, 라이선스 파일에도 명시되어 있다. Chromium 프로젝트 웹사이트에서 코드 전체를 열람할 수 있으며[103], Git 저장소로도 공개되어 있다[104]。

참조

[1] 웹사이트 Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser https://redmondmag.c[...] 2022-05-08
[2] 웹사이트 Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5 https://www.windowsl[...] 2018-04-03
[3] 웹사이트 QUIC and HTTP/3 Support now in Firefox Nightly and Beta https://hacks.mozill[...] Mozilla 2021-04-16
[4] 웹사이트 Google Wants To Speed Up The Web With Its QUIC Protocol https://techcrunch.c[...] 2015-04-18
[5] 웹사이트 Google Will Propose QUIC As IETF Standard https://www.infoq.co[...] 2016-10-25
[6] 간행물 I-D Action: draft-tsvwg-quic-protocol-00.txt https://www.ietf.org[...] 2015-06-17
[7] 웹사이트 QUIC - IETF Working Group https://datatracker.[...] 2016-10-25
[8] 뉴스 HTTP-over-QUIC to be renamed HTTP/3 https://www.zdnet.co[...] 2018-11-12
[9] 웹사이트 QUIC is now RFC 9000 https://www.fastly.c[...] 2021-05-27
[10] 웹사이트 The next version of HTTP won't be using TCP https://arstechnica.[...] 2018-11-12
[11] 웹사이트 Introducing QUIC support for HTTPS load balancing https://cloudplatfor[...] 2018-06-16
[12] 논문 QUIC: A UDP-Based Multiplexed and Secure Transport https://datatracker.[...] 2021-05
[13] 웹사이트 Applicability of the QUIC Transport Protocol https://quicwg.org/o[...] 2018-10-22
[14] 웹사이트 HTTP/3 and QUIC: Past, Present, and Future https://www.akamai.c[...] Akamai 2021-06-21
[15] 웹사이트 A new era in Internet transport https://www.ietf.org[...] IETF 2021-06-03
[16] IETF DNS over Dedicated QUIC Connections 2022-05
[17] 웹사이트 What's the deal with Media Over QUIC? https://www.ietf.org[...] IETF 2024-01-25
[18] 웹사이트 XEP-0467: XMPP over QUIC https://xmpp.org/ext[...] 2022-07-13
[19] 웹사이트 SMB over QUIC https://learn.micros[...] 2023-06-27
[20] 웹사이트 How Google's QUIC Protocol Impacts Network Security and Reporting https://www.fastvue.[...] 2018-06-22
[21] 웹사이트 Cloudflare, Google Chrome, and Firefox add HTTP/3 support https://www.zdnet.co[...] 2019-09-26
[22] 웹사이트 Release Notes for Safari Technology Preview 104 https://webkit.org/b[...] 2020-04-08
[23] 웹사이트 Safari 14 Release Notes https://developer.ap[...] 2020-12-04
[24] 웹사이트 How to enable HTTP3 in Chrome / Firefox / Safari https://www.bram.us/[...] 2020-04-08
[25] 웹사이트 Examining HTTP/3 usage one year on https://blog.cloudfl[...] 2023-06-06
[26] 웹사이트 Perform network operations using Cronet https://developer.an[...] 2019-07-20
[27] 웹사이트 curl – Changes https://curl.haxx.se[...] 2019-09-30
[28] 웹사이트 curl 7.66.0 – the parallel HTTP/3 future is here {{!}} daniel.haxx.se https://daniel.haxx.[...] 2019-09-11
[29] 웹사이트 How Facebook is bringing QUIC to billions https://engineering.[...] 2020-10-21
[30] 웹사이트 How Google's QUIC Protocol Impacts Network Security and Reporting https://www.fastvue.[...] 2020-10-21
[31] 웹사이트 This is what you need to know about the new QUIC protocol https://nordvpn.com/[...] 2020-09-30
[32] 웹사이트 QUIC server https://quiche.googl[...] 2022-08-17
[33] URL QUIC support by Akamai https://community.ak[...] 2020-05-20
[34] 서적 Passive and Active Measurement
[35] 웹사이트 lucas-clemente/quic-go https://github.com/l[...] 2020-08-07
[36] 문서 QUIC support in Caddy https://github.com/m[...] 2016-07-13
[37] 웹사이트 LiteSpeed Web ADC – Load Balancer – LiteSpeed Technologies https://www.litespee[...] 2020-08-07
[38] 문서 LiteSpeed Technologies QUIC Blog Post https://blog.litespe[...] 2017-07-11
[39] 웹사이트 Distribution of Web Servers among websites that use QUIC https://w3techs.com/[...] 2020-08-07
[40] 웹사이트 Get a head start with QUIC https://blog.cloudfl[...] 2019-07-16
[41] 웹사이트 Announcing HAProxy 2.6 https://www.haproxy.[...] 2023-09-16
[42] 웹사이트 "[ANNOUNCE] haproxy-2.8.0" https://www.mail-arc[...] 2023-09-16
[43] 웹사이트 Usage Statistics of QUIC for Websites, April 2023 https://w3techs.com/[...] 2023-04-03
[44] 웹사이트 Enabling HTTP/3 support on Windows Server 2022 https://techcommunit[...] 2021-08-24
[45] 웹사이트 SMB over QUIC https://docs.microso[...] 2023-06-27
[46] 웹사이트 Policy configuration for HTTP/3 traffic | Citrix ADC 13.0 https://docs.citrix.[...]
[47] 웹사이트 Need for speed? – Just an other Citrix ADC Blog https://norz.at/?p=2[...]
[48] 웹사이트 devsisters/libquic https://github.com/d[...] 2020-08-07
[49] 웹사이트 devsisters/goquic https://github.com/d[...] 2020-08-07
[50] 웹사이트 Docker Hub https://hub.docker.c[...] 2020-08-07
[51] 웹사이트 ".NET 5 Networking Improvements" https://devblogs.mic[...] 2021-01-26
[52] 웹사이트 제3회 TCP＋TLS에 대안하는 고속 프로토콜, Google 태생의 「QUIC」의 특징과 표준화의 행방 https://internet.wat[...] 임프레스 2018-01-21
[53] 웹사이트 JPNIC News & Views vol.1647【임시호】제103회IETF보고 [제4탄] 트랜스포트 에리어 관련 보고 ～HTTP over QUIC에서 HTTP/3으로의 개칭～ https://www.nic.ad.j[...] 2021-05-29
[54] 웹사이트 Google Wants To Speed Up The Web With Its QUIC Protocol https://techcrunch.c[...] 2016-10-25
[55] 웹사이트 Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5 https://www.windowsl[...] 2020-05-08
[56] 웹사이트 How to enable HTTP3 in Chrome / Firefox / Safari https://www.bram.us/[...] 2021-05-31
[57] 웹사이트 The state of QUIC and HTTP/3 2020 https://www.fastly.c[...] 2020-10-21
[58] 웹사이트 Google Will Propose QUIC As IETF Standard https://www.infoq.co[...] 2016-10-25
[59] 간행물 I-D Action: draft-tsvwg-quic-protocol-00.txt https://www.ietf.org[...] 2015-06-17
[60] 웹사이트 QUIC - IETF Working Group https://datatracker.[...] 2016-10-25
[61] 뉴스 HTTP-over-QUIC to be renamed HTTP/3 https://www.zdnet.co[...] 2018-11-12
[62] 웹사이트 QUIC is now RFC 9000 https://www.fastly.c[...] 2021-05-29
[63] 웹사이트 QUIC의 성숙 https://www.fastly.c[...] 2021-06-08
[64] 논문 RFC 8999 Version-Independent Properties of QUIC https://www.rfc-edit[...] 2021-06-09
[65] 웹사이트 QUIC의 성숙 https://www.fastly.c[...] 2021-06-08
[66] 논문 RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport https://www.rfc-edit[...] 2021-06-03
[67] IETF RFC 9221 5.4. Congestion Control
[68] 웹사이트 TCP에 대안하는 고속 프로토콜의 표준화――QUIC【IETF100 Update Meeting】 https://internet.wat[...] 2021-06-02
[69] 뉴스 HTTP-over-QUIC to be renamed HTTP/3 https://www.zdnet.co[...] 2018-11-12
[70] 웹사이트 How Google's QUIC Protocol Impacts Network Security and Reporting https://www.fastvue.[...] 2022-04-02
[71] 웹사이트 Cloudflare, Google Chrome, and Firefox add HTTP/3 support https://www.zdnet.co[...] 2019-09-27
[72] 웹사이트 QUIC and HTTP/3 Support now in Firefox Nightly and Beta https://hacks.mozill[...] Mozilla 2021-10-11
[73] 웹사이트 Release Notes for Safari Technology Preview 104 https://webkit.org/b[...] 2020-08-07
[74] 웹사이트 Safari 14 Release Notes https://developer.ap[...] 2020-12-04
[75] 웹사이트 How to enable HTTP3 in Chrome / Firefox / Safari https://www.bram.us/[...] 2022-04-10
[76] 웹사이트 Perform network operations using Cronet https://developer.an[...] 2019-07-20
[77] 웹사이트 curl - Changes https://curl.haxx.se[...] 2019-09-30
[78] 웹사이트 curl 7.66.0 – the parallel HTTP/3 future is here {{!}} daniel.haxx.se https://daniel.haxx.[...] 2019-09-30
[79] 웹사이트 How Facebook is bringing QUIC to billions https://engineering.[...] 2020-10-23
[80] 웹사이트 How Google's QUIC Protocol Impacts Network Security and Reporting https://www.fastvue.[...] 2021-06-26
[81] 웹사이트 This is what you need to know about the new QUIC protocol https://nordvpn.com/[...] 2021-06-26
[82] 문서 https://code.google.[...]
[83] 문서 QUIC support in Caddy https://github.com/m[...] 2016-07-13
[84] 웹사이트 LiteSpeed Web ADC - Load Balancer - LiteSpeed Technologies https://www.litespee[...] 2020-08-07
[85] 웹사이트 Distribution of Web Servers among websites that use QUIC https://w3techs.com/[...] 2020-08-07
[86] 웹사이트 Get a head start with QUIC https://blog.cloudfl[...] 2019-07-16
[87] 웹사이트 Usage Statistics of QUIC for Websites, March 2021 https://w3techs.com/[...] 2021-03-04
[88] 웹사이트 Enabling HTTP/3 support on Windows Server 2022 https://techcommunit[...] 2022-04-02
[89] 웹사이트 SMB over QUIC https://docs.microso[...] 2022-04-02
[90] 웹사이트 Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser -- Redmondmag.com https://redmondmag.c[...] 2022-04-02
[91] 웹사이트 Policy configuration for HTTP/3 traffic {{!}} Citrix ADC 13.0 https://docs.citrix.[...] 2022-04-02
[92] 웹사이트 Need for speed? – Just an other Citrix ADC Blog https://norz.at/?p=2[...] 2022-04-02
[93] 웹사이트 devsisters/libquic https://github.com/d[...] 2020-08-07
[94] 웹사이트 devsisters/goquic https://github.com/d[...] 2020-08-07
[95] 웹사이트 Docker Hub https://hub.docker.c[...] 2020-08-07
[96] 웹사이트 .NET 5 Networking Improvements https://devblogs.mic[...] 2021-01-26
[97] 웹사이트 Windows Server 2022正式版がひっそりとリリース。セキュアコアサーバ搭載、SMB over QUICでVPN不要のファイルアクセスなど https://www.publicke[...] 2022-05-20
[98] 웹사이트 draft-bider-ssh-quic-09 https://datatracker.[...] 2022-04-02
[99] 웹사이트 WebRTC over QUIC https://voluntas.med[...] 2021-05-30
[100] 웹사이트 QUICの暗号化と鍵の導出について https://asnokaze.hat[...] 2021-10-25
[101] 웹사이트 HTTP/3が必要な理由（3ページ目） https://xtech.nikkei[...] 2021-06-10
[102] 간행물 RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport https://www.rfc-edit[...] 2021-06-10
[103] 문서 chrome Index of /trunk/src/net/quic https://src.chromium[...]
[104] 문서 quic - chromium/src/net - Git at Google https://chromium.goo[...]
[105] IETF QUIC: A UDP-Based Multiplexed and Secure Transport 국제 인터넷 표준화 기구
[106] 웹인용 Connecting on the QUIC https://lwn.net/Arti[...] Linux Weekly News 2013-07-16
[107] 웹인용 QUIC: Design Document and Specification Rationale https://docs.google.[...] Jim Roskind, Chromium Contributor
[108] 웹인용 First Chromium Code Landing: CL 11125002: Add QuicFramer and friends. https://chromiumcode[...] 2012-10-16
[109] 웹인용 Experimenting with QUIC https://blog.chromiu[...] Chromium Official Blog 2013-07-16
[110] 웹인용 QUIC, Google wants to make the web faster https://plus.google.[...] François Beaufort, Chromium Evangelist
[111] 웹인용 QUIC: next generation multiplexed transport over UDP https://www.youtube.[...] YouTube 2014-04-04
[112] 웹인용 QUIC: IETF-88 TSV Area Presentation http://www.ietf.org/[...] Jim Roskind, Google 2013-11-07
[113] 웹인용 HTTP/3 protocol https://caniuse.com/[...]
[114] 웹인용 Google Wants To Speed Up The Web With Its QUIC Protocol https://techcrunch.c[...] 2016-10-25
[115] 웹인용 Google Will Propose QUIC As IETF Standard https://www.infoq.co[...] 2016-10-25
[116] 메일링 I-D Action: draft-tsvwg-quic-protocol-00.txt https://www.ietf.org[...] 2015-06-17
[117] 웹인용 QUIC - IETF Working Group https://datatracker.[...] 2016-10-25
[118] 뉴스 HTTP-over-QUIC to be renamed HTTP/3 https://www.zdnet.co[...] 2018-11-12


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com