QUIC 특장점
- QUIC은 UDP 위에 새로운 계층을 추가함으로써 신뢰성을 제공한다. 추가된 계층은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공한다.
QUIC connection
- QUIC 연결은 두 QUIC 엔드포인트 사이의 대화이다
- QUIC의 연결 설정은 버전 협상, 암호화, 전송 핸드쉐이크로 구성되어 있으므로 연결 설정의 지연시간을 줄여준다.
- QUIC의 연결을 통해 실제 데이터를 보내려면 하나 이상의 스트림을 만들어서 사용해야 한다
QUIC connection ID
- 각 연결은 연결 식별자나 연결 ID를 가지므로 이를 통해 연결을 식별함
- 엔드포인트가 자유롭게 연결 ID를 선택하며, 각 엔드포인트는 엔드포인트의 피어가 사용할 연결 ID를 선택함
- 연결 ID의 주요 기능은 하위 프로토콜 계층에서 주소가 변경되더라도 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것이다.
stream based transport
- QUIC은 하나의 연결로 다수의 병렬 스트림을 전송하며, 스트림 간에 영향을 주지 않고 데이터를 동시에 전송한다
- 스트림은 62비트 정수의 스트림 ID 식별자로 구분한다
- 스트림은 순서대로 전달되고 신뢰할 수 있지만 서로 다른 스트림은 순서 없이 전달될 수 있다
- QUIC은 연결과 스트림 모두에서 흐름 제어를 제공한다
- QUIC을 사용하는 상위 계층을 통해서 스트림에 대한 우선 순위를 요청받아, 이를 토대로 정보 교환을 할 수 있다
Secure Communication
- QUIC은 일반 텍스트 버전이 없고, QUIC 연결과 협상하려면 TLS 1.3을 사용해서 암호화 및 보안을 수행해야 한다
- 이전 버전의 TLS와 비교해서 TLS 1.3에 몇몇 장점이 있지만 QUICdl TLS 1.3을 사용한 주된 이유는 핸드쉐이크에 더 적은 라운드 트립이 필요하도록 바뀌었기 때문으로, 프로토콜 지연을 줄여준다.
- TLS를 기본으로 사용하므로, 웹 사용자가 기대하고 원하는 HTTPS의 모든 보안 속성을 지원한다.
Reduced Latency
- QUIC는 0-RTT, 1-RTT 핸드쉐이크를 제공하는데 이는 새로운 연결을 협상하고 설정하는데 걸리는 시간을 줄여준다.
- QUIC은 추가로 더 많은 데이터를 허용하는 early data를 처음부터 지원한다
- 기존에 존재하는 연결이 끝나기를 먼저 기다릴 필요 없이 같은 호스트로의 또 다른 논리 연결도 동시에 처리될 수 있다
HTTPS:// URLs
- HTTP/3는 HTTPS:// URL을 사용한다
- 새로운 URL 체계를 만들지 않고, 기존 체계를 유지한다
TLS 필수화에 따른 초기 연결 경우
- 이전에 방문한 적이 없는 HTTPS:// URL에 대한 새로운 첫 연결은 아마도 TCP를 통해 수행될 것이다.
- 최신 클라이언트와 서버는 아마도 첫 핸드쉐이크에서 HTTP/2를 협상할 것이다. 연결이 설정되고 클라이언트의 HTTP 요청에 서버가 응답할 때 서버는 HTTP/3의 지원과 선호도에 관해 클라이언트에게 알려줄 수 있다
HTTP/3 Frame
- HTTP/3는 연결 설정 후, 한정된 타입의 프레임을 송수신한다
- HEADERS: 압축된 HTTP 헤더를 보낸다
- DATA: 바이너리 데이터 콘텐츠를 보낸다
- GOAWAY: 연결을 종료한다
QPACK Headers
- HRADERS 프레임은 QPACK에 의해 압축되며, 이는 HTTP/2의 HPACK과 유사하다
- QUIC의 스트림이 독립적으로 송수신함에 따라 이에 맞춰서 개선된 것으로 이해하면 된다
우선순위 제어
- HTTP/3 스트림 프레임 중에는 PRIORITY라는 프레임이 있으며, 이 프레임은 HTTP/2에서 동작한 방식과 비슷하게 스트림의 우선순위와 의존성을 설정하는 데 사용한다
- PRIORITY 프레임은 특정 스트림이 다른 스트림에 의존하도록 설정할 수 있고 해당 스트림에 가중치를 설정할 수 있다.
- 종속된 스트림은 의존하는 스트림이 모두 닫혔을 때만 리소스가 할당받아야 하고 아니면 진행될 수 없다
- 스트림 가중치는 1부터 256사이의 값을 가지며 같은 부모를 가진 스트림은 반드시 가중치에 따라 리소스를 할당받아야 한다
서버푸시
- 서버 푸시는 클라이언트 쪽에서 서버 푸시에 동의했을 때만 발생할 수 있다. HTTP/3에서는 클라이언트가 최대 푸시 스트림의 ID가 무엇인지 서버에게 알려주어 클라이언트가 얼마나 많은 푸시를 받을지를 제한하며, 이 제한을 초과하면 연결 오류가 발생한다
- 클라이언트가 요청하지는 않았지만 어쨌든 서버가 전달해야 하는 추가 리소스가 있다고 판단하면, 서버가 요청에 푸시로 응답한 것처럼 보이는 PUSH_PROMISE 프레임을 보낼 수 있다. 그 다음 실제 응답은 새로운 스트림을 통해 보낸다
- 클라이언트가 미리 푸시를 받을 수 있다고 말했더라도, 클라이언트가 적합하다고 판단하면 푸시된 개별 스트림을 언제든 취소할 수 있다. 그리고 서버에 CANCEL_PUSH 프레임을 보낸다
HTTP/2와 HTTP/3의 유사점
- 스트림 제공
- 서버 푸시를 지원
- 헤더 압축을 제공
- 스트림을 이용해서 하나의 연결을 통해 멀티플랙싱을 제공
- 스트림에 우선순위를 정한다
HTTP/2와 HTTP/3의 차이점
- QUIC의 0-RTT 핸드쉐이크 덕에 HTTP/3에서는 이른 데이터 지원이 더 낫게 잘 동작한다. TCP의 Fast Open과 TLS는 더 적은 데이터를 보내지만, 종종 문제점에 직면한다
- HTTP/3는 QUIC 덕에 TCP + TLS보다 훨씬 더 빠른 핸드쉐이크를 제공한다
- HTTP/3에는 안전하지 않거나 암호화되지 않은 버전이 없다. 인터넷에서 드물기는 하지만 HTTP/2는 HTTPS 없이 구현하고 사용할 수 있다
- HTTP/2가 ALPN 확장을 이용하여 즉시 TLS 핸드쉐이크 협상을 완료할 수 있는 반면 HTTP/3는 QUIC을 사용하므로 클라이언트에 이 사실을 알리기 위해 Alt-Svc 헤더 응답이 먼저 있어야 한다
개발 공부중입니다