10. QUIC & HTTP/3

Notice

Recent Posts

Recent Comments

Link

프로젝트 유튜브 영상들

« 2024/11 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

Tags more

Archives

Today

Total

관리 메뉴

센로그

10. QUIC & HTTP/3 본문

CS/풀스택서비스네트워킹

10. QUIC & HTTP/3

seeyoun 2023. 12. 8. 11:44

◆ QUIC 이란?

TCP를 대체하는 범용 목적으로 개발된 4계층 통신 프로토콜로, UDP위에서 동작한다.

게임, 스트리밍 미디어, VoIP서비스에 자주 쓰이며, 지연시간이 적은 인터넷 전송 프로토콜임.
HTTP/3는 HTTP(Hypertext Transfer Protocol)의 세 번째 메이저 버전으로, 기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜이다.

"바로 옆에 있는 애한테 보내는건데, 설마 이게 TCP 혼잡 제어나 오류 제어 할만큼 그렇게나 오류가 많을까? 그건 아닌 것 같은데." 라는 컨셉에서 시작함.

그러다가 수많은 사람들이 개량해나가면서, 근거리 서버 to 서버 에서만이 아닌, 충분히 멀리 떨어진 경우에도 장점이 있도록 발전함.

2021년에 표준화까지 완료함.

◆ QUIC & HTTP/3 출현 배경

화석화 탈피
- 새로운 네트워크 기술들은 계속 변화하고 발전해 나가고 있지만, 네트워크 중간에 있는 미들 박스(주로 라우터)들은 신기술을 따라잡을 만큼 자주 업그레이드되거나 개발되지 않는다. 고착화 되어있음.
- 이런 애들이 중간에서 신기술을 인식 못하고 막아버리는 등 문제가 발생할 수 있으니, 이를 방지하고자 중간에 있는 애들은 아무것도 모르게 암호화해서 보내자! 는 것

근데 교수님 피셜 사실 이건 좀 작위적인 이유 같다고 하심.
그냥 TCP의 문제점, 개선된 HTTP 이것이 QUIC과 HTTP/3로 나온 거라고 생각하면 될 듯.

TCP의 현대 사회에 어울리지 않는 동작
TCP가 구닥다리 인터넷을 통해서 정보를 주고받을 때에는 굉장히 핵심적인 기술이었으나, 현재 네트워크가 빨라지고 나니 그렇지 않다라는 것.
- Slow Start 및 AIMD
  시작할 때 속도가 매우 느리고(Slow Start), Loss 발생 시 성능을 너무 확 떨어뜨림.(AIMD)
- HoL Blocking
  맨 앞 하나에 문제가 발생하면 전체가 지연됨.

문제점들이 많이 보이고 너무 느림.

이런 TCP의 문제점을 보완하고, 신뢰성도 가져가고자 한 기술이 바로 QUIC이다.

QUIC은 UDP 기반으로 만들어진 것이지만, 에러 검출 및 복구나 혼잡 제어도 하고, 우선 순위도 제공하며, 암호화도 한다.

이런 멋찐 프로토콜인 QUIC에 대해서 알아보자!!!!

◆ QUIC 장점

UDP based NEW Transport Protocol
- QUIC은 UDP를 기반으로 하여 새롭게 만들어진 전송 프로토콜임.
- QUIC은 UDP 위에 새로운 계층을 추가함으로써 신뢰성을 제공함.
  추가된 계층은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공함
  - 4계층 UDP 위에 올리는 것이지만, QUIC 역시 4계층이라는 점 유의할 것!
- QUIC은 (TCP와 같은) 범용의 전송 프로토콜로써 다른 애플리케이션 프로토콜이 그 위에서 사용할 수 있음
  - 첫 애플리케이션 계층 프로토콜은 HTTP/3 임
  - 전송 계층은 연결 레벨과 스트림 레을 지원함
Connection based Transport
- QUIC Connection (=연결)
  - QUIC 연결은 두 QUIC 엔드포인트 사이의 대화임
  - QUIC의 연결 설정은 버전 협상, 암호화, 전송 핸드쉐이크로 구성되어 있으므로 연결 설정의 지연시간을 줄여줌
  - QUIC의 연결을 통해 실제 데이터를 보내려면 하나 이상의 스트림을 만들어서 사용해야 함
- QUIC Connection ID
  - 각 커넥션 마다 ID를 줄 수가 있다. 이를 연결 ID라고 하며, 이를 통해 커넥션을 식별함
  - 엔드포인트가 자유롭게 연결 ID를 선택하며, 각 엔드포인트는 엔드포인트의 피어가 사용할 연결 ID를 선택함
  - 연결 ID의 주요 기능은 하위 프로토콜 계층(UDP, IP 혹은 그 아래 계층)에서 주소가 변경되더라도 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것임. IP 주소와 연결 ID는 독립적이기 때문에 이게 가능함. (IP 주소가 변경되더라도 연결 ID만 유지한다면 서비스가 끊어지지 않는다.)
    - Connection Migration: 연결 ID를 이용하면 TCP에서는 불가능했던 IP 주소와 네트워크 인터페이스 사이에서 연결 마이그레이션 할 수 있음.
    - 예를 들면 사용자가 다운로드를 진행하면서 기기를 들고 WiFi가 지원되는 곳으로 이동했을 때, 셀룰러 네트워크 연결에서 더 빠른 WiFi 연결로 변경되는 것이 이 마이그레이션을 통해 가능함
    - 마찬가지로 WiFi를 이용할 수 없게 되었을 때 셀룰러 연결을 통해 다운로드를 진행할 수 있음

Stream based Transport
- QUIC은 하나의 연결로 다수의 병렬 스트림을 전송하며, 스트림 간에 영향을 주지 않고 데이터를 동시에 전송함
- 스트림은 62비트 정수의 스트림 ID 식별자로 구분함
  - 그만큼 많은 스트림 동시 사용 가능!!
  - 한 스트림은 순서대로 전달되고 신뢰할 수 있지만 서로 다른 스트림은 순서 없이 전달될 수 있음
- QUIC은 연결 레벨과 스트림 레벨 모두에서 흐름 제어를 제공함. 에러 검출도 함.
- QUIC을 사용하는 상위 계층을 통해서 스트림에 대한 우선 순위를 요청받아, 이를 토대로 정보 교환을 할 수 있음
Independent Streams avoid HoL Blocking
- 본질적으로 UDP 베이스인 만큼, 앞에서 에러가 났다고 해서 뒤에 애들이 막히는 일은 없다.
Secure Communiction
- QUIC은 일반 텍스트 버전이 없고, QUIC 연결과 협상하려면 TLS 1.3을 사용해서 암호화 및 보안을 수행해야 함
  - 이전 버전의 TLS와 비교해서 TLS 1.3에 몇몇 장점이 있지만 QUIC이 TLS 1.3을 사용한 주된 이유는 핸드쉐이크에 더 적은 라운드 트립이 필요하도록 바뀌었기 때문으로, 프로토콜 지연을 줄여줌
- TLS를 기본으로 사용하므로, 웹 사용자가 기대하고 원하는 HTTPS의 모든 보안 속성을 지원함
Reduced {Signaling} Latency
- QUIC는 0-RTT, 1-RTT 핸드쉐이크를 제공하는데 이는 새로운 연결을 협상하고 설정하는데 걸리는 시간을 줄여줌
  - 1-RTT(Round Trip Time): 내가 보내고 다시 받는 과정이 한번 있음
  - 0-RTT: 보내고 나서 다시 받는 과정을 기다릴 필요가 없음
  - 따라서 3-way handshake 방식인 TCP에 비해 연결을 위해 주고받는 메시지 개수가 적고, 그만큼 더 연결하는 데 걸리는 시간이 적다.
- QUIC은 추가로 더 많은 데이터를 허용하는 "이른 데이터(early data)"를 처음부터 지원함
  - 기존에 존재하는 연결이 끝나기를 먼저 기다릴 필요 없이 같은 호스트로의 또 다른 논리 연결도 동시에 처리될 수 있음. 연결 설정을 하면서도 데이터를 보낼 수 있으니 이런 걸 이른 데이터라고 함.
- 일반적인 TCP/TLS vs QUIC
  - 기본적으로 1-RTT 만에 접속지원
  - 왼쪽 그림은 TCP + TLS인데, TCP와 TLS 각각이 핸드쉐이크를 한 후에야 HTTP Request 가능.
    오른쪽은 QUIC인데, "어차피 QUIC은 TLS 필수로 쓰니까 그냥 연결 설정 한번에 하자!" 하고 합친 것임. 프로토콜 내에 TLS를 포함해서 한번에 연결한 것. 따로따로 할 때보다 시간이 훨씬 줄어듦.
- 가속화된 TCP/TLS vs QUIC
  - 새로운 연결을 설정하는데 필요한 시간을 줄이려고 이전에 서버에 연결했던 클라이언트는 해당 연결의 특정 파라미터를 캐시함.
    - 이로 인해 두번째 연결 부터는 서버에 0-RTT 만에 접속할 수 있음
  - 이로 인해서 클라이언트는 핸드쉐이크가 완료되기를 기다리지 않고 바로 데이터를 보낼 수 있음 (0-RTT)
    오른쪽 그림처럼, 연결 설정 시작할 때 데이터도 같이 쏴버리는 거임.

※ Connection Migration 과정

TCP는 양 endpoint의 port, ip로 구성된 four-tuple로 커넥션을 식별하기 때문에 클라이언트의 IP가 바뀌면 커넥션이 끊긴다. 그래서 새로 연결을 하는 동안 지연이 발생함.

반면 QUIC의 endpoint는 자기 자신의 Connection ID (Source Connection ID)와 Peer의 Connection ID(Destination Connection ID) 로 식별한다.
Connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다. 이는 TCP와 달리 새로 연결을 생성할 때 거쳐야하는 핸드쉐이크 과정을 생략할 수 있다.

연결 과정은 다음과 같다.
ㆍ클라이언트가 연결 시도를 할 때 초기 패킷(Initial Packet)에 Connection ID를 보낸다.
ㆍ서버가 Connection ID를 선택하여 응답하면 이를 Destination Connection ID로 사용한다.
(Connection ID는 프로토콜 구현자에 의해 랜덤으로 생성된다.)
ㆍ만약 중간에 네트워크가 변경되면, 클라이언트가 변경된 IP를 서버에 알려 주고, 변경된 IP로 패킷이 잘 가는지 검증한 뒤 커넥션 이동이 완료된다. TCP와 달리 새로 연결할 필요가 없다.

◆ HTTP/3 Alt-svc

HTTP/3에서도 기존 URL 체계는 유지한다. https:// 를 사용함.

주소창에 URL 입력해서 들어가는 방식은 똑같다는 뜻.

그러면 클라가 HTTP 서버에 연결 설정을 할 때, 1.1/2/3 중에 뭘 써야할 지 어떻게 정할까?

→ Alternative Service (Alt-svc)

이전에 방문한 적이 없는 HTTPS:// URL에 대한 새로운 첫 연결은 아마도 TCP를 통해 수행될 것임. 1.1이나 2를 사용한 연결일 것이기 때문.
최신 클라이언트와 서버는 아마도 첫 핸드쉐이크에서 HTTP/2를 협상할 것임. 연결이 설정되고 클라이언트의 HTTP 요청에 서버가 응답할 때 서버는 HTTP/3의 지원과 선호도에 관해 클라이언트에게 알려줄 수 있음
초기 연결이 HTTP/2나 HTTP/1을 사용하더라도 서버는 다시 연결해서 HTTP/3를 시도할 수 있다고 클라이언트에게 알려줄 수 있음
- Alt-Svc: h3=“:50781"를 응답에 포함 하면, 다음과 같은 의미를 내포함.
  - "나 alternative한 서비스가 되는데, HTTP/3이 지원이 돼. 너 관심 있으면 포트 넘버 50,781로 나한테 재접속해볼래? 그때는 UDP를 써야하고 QUIC 써야 해."

그렇게 해서 QUIC으로 가는 경우가 있고, 이렇게 한번 연결한 경우 그 다음 연결시에는 연결했던 기록이 남으므로 바로 HTTP/3로 접속하게 된다.

◆ HTTP/2와 HTTP/3 유사점

HTTP/3 는 전체적으로 HTTP/2와 비슷하게 동작한다. 세부적인 제어 동작이 일부 다를 뿐.

스트림 단위로 통신한다.
- 당연히 여러 스트림을 멀티플렉싱해서 동시에 보내기도 가능하다.
HTTP/3에서도 HTTP/2 때와 같이 프레임을 헤더/데이터 프레임으로 나눈다.
- 추가된 게 있는데, 연결 종료하는 메시지 GOAWAY가 추가되었다.
데이터가 크다면 여러 프레임으로 나누어서 보낸다.
또한 헤더 압축도 제공한다. 단 HPACK이 아닌 QPACK을 사용함.
우선 순위도 지정해줄 수 있다.
- 종속 관계면 상위 리퀘스트가 먼저 처리되고,
- 같은 부모를 가진 대등한 관계이면 각각의 가중치에 따라 리소스를 할당받는다.
서버 푸시도 지원한다.
- PUSH_PROMISE를 통해 서버 푸시를 예고함.
- 푸시를 캔슬하는 기능도 추가됨. CANCEL_PUSH

◆ HTTP/2와 HTTP/3 차이점

QUIC의 0-RTT 핸드쉐이크 덕에 HTTP/3에서는 이른 데이터 지원이 더 낫게 잘 동작함. 연결 설정이 빠름.
TCP의 Fast Open과 TLS는 더 적은 데이터를 보내지만, 종종 문제점에 직면함
- HTTP/3는 QUIC덕에 TCP + TLS보다 훨씬 더 빠른 핸드쉐이크를 제공함
HTTP/3에는 안전하지 않거나 암호화되지 않은 버전이 없음.
인터넷에서 드물기는 하지만 HTTP/2는 TLS 없이 구현하고 사용할 수 있음 (암호화 필수가 표준이 아니므로)
HTTP/2가 ALPN 확장을 이용하여 즉시 TLS 핸드쉐이크 협상을 완료할 수 있는 반면,
HTTP/3는 QUIC을 사용하므로 클라이언트 에 이 사실을 알리기 위해 Alt-Svc: 헤더 응답이 먼저 있어야 함