QUIC란

[ 설명 ]
- QUIC(Quick UDP Internet Connections)는 Google이 설계하고 IETF가 RFC 9000으로 표준화한
	전송 계층 프로토콜
- TCP + TLS + HTTP/2의 한계를 근본적으로 해결하기 위해 UDP 위에서 동작

등장 배경

- TCP의 구조적 문제부터 짚어보면, TCP는 커널 레벨에서 동작하기 때문에 프로토콜 개선이 
	OS 업데이트에 묶여 있고, 미들박스(방화벽, NAT, 로드밸런서)들이 TCP 헤더를 파싱하고
	조작하는 관행이 굳어져서 프로토콜 확장이 사실상 불가능

- TCP + TLS 조합은 핸드셰이크만 최소 2~3 RTT가 필요하고, 하나의 TCP 연결 위에 멀티플렉싱하는
	HTTP/2는 패킷이 하나가 유실되면 모든 스트림이 블록킹되는 HOL 문제도 존재

핵심 아키텍처

UDP 위의 유저스페이스 프로토콜

[ 설명 ]
- QUIC는 UDP 기반으로 하여 새롭게 만들어진 전송 프로토콜

- QUIC는 UDP 위에 새로운 계층을 추가함으로써 신뢰성을 제공
	- 추가된 계층은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 흐름 제어 등 기능 제공

- 4계층 UDP 위에 이지만 QUIC도 4계층

TLS 1.3 내장

- QUIC는 TLS 1.3을 프로토콜 내부에 통합

- TCP처럼 전송 핸드셰이크 따로, TLS 핸드셰이크 따로가 아님

- QUIC는 
		클라이언트 → 서버: Initial (QUIC 연결 요청 + TLS ClientHello)
		서버 → 클라이언트: Initial (QUIC 연결 수락 + TLS ServerHello + 인증서)
		-- 1 RTT에 연결 + 암호화 동시 완료 --

- 재접속 시에는 PSK로 0-RTT 가능
	- 여기서 주의할 점은 replay attack에 취약
	- 공격자가 0-RTT 패킷을 캡쳐해서 그대로 다시 보내면 서버가 또 처리 가능
	- 그래서 0-RTT에는 GET 같은 멱등한 요청만 보내는 게 원칙

• TLS v1.3 연결

  TLS / mTLS

[ 0-RTT에 대한 추가 설명 ]
- 0-RTT는 재연결 시 요청을 말함.
- 그래서 실제 동작 흐름은:
		클라이언트 -> 서버 : ClientHello + PSK + 0-RTT 데이터(GET /index.html)
		서버 -> 클라이언트 : ServerHello + handshake 완료
		--- 1-RTT 완료, 안전한 채널 ---
		클라이언트 -> 서버 : POST /api/orders(여기서 전달)

스트림 멀티플렉싱과 HoL Blocking 해결

- QUIC의 가장 중요한 설계 결정은 스트림 독립성

- TCP에서는 바이트 스트림이 하나이므로 중간 패킷 유실 시 뒤따르는 모든 데이터가 대기해야 함

- QUIC는 하나의 연결 안에 독립적인 스트림을 여러 개 만들고, 각 스트림의 순서 보장은
	해당 스트림 내에서만 적용