QUIC HTTP/3 내용 정리

QUIC

• 새로운 transport layer
• udp위에 동작하지만 tcp에 상응하는 transport layer
• 운영체제 밖에서 동작

현대 통신 프로토콜 패러다임

• 리눅스 커널 바깥으로 유연하게 프로그래밍할 수 있게
• PowerShift from Standard to Opensource
• Out of TCP

QUIC은 TCP를 대체하는 범용 목적의 전송 계층 통신 프로토콜로서 당초 처음에 이름을 낼때 Quick UDP Internet Connections로 제안 → IETF에서 QUIC으로 지정.

QUIC 은 UDP 베이스로 tls로 반드시 보안을 제공하도록 했고 에러 검출 및 복구, 흐름 제어에 대한 내용이 들어감. 하지만 기존 tcp와 관련해서만 기술이 발전 하다보니 tls와 친화력이 없어서 성능적으로 문제가 있었고 관련 기술이 부족했음.

QUIC & HTTP/3 출현 배경

• 화석화 탈피 - 미들박스인 라우터가 자주 개발되지 않음. 새로운 기술에 대한 적용을 못함 → 프로토콜 고착화(ossification) → 고착화를 방지하는 효과적인 방법은 미들박스가 지나가는 프로토콜에서 많은 것을 볼 수 없도록 통신을 최대한 암호화하는 것! (암호화는 안정된 네트워크 경험을 사용자에게 줌. 브라우저와 서버 레벨에서 암호화를 함.)
• tcp 문제
  • slow start - 속도를 너무 높일 수 없음.
  • loss - 올라갔다가 확 떨어지고. loss가 발생했을 때 성능이 확 떨어짐.(congestion control)
  • tcp의 head of line blocking문제 발생 → 앞쪽 패킷이 에러가 나면 뒤에 서비스도 문제가 생김. http2의 경우 tcp 연결 한개로 병렬 전송하지만 1.1은 여러 개의 tcp을 뚫어서 병렬 연결하기 때문에 효율은 오히려 1.1이 이런면에서 나음.
  • flow control : 버퍼 사이즈 너무 작다

QUIC은 TCP랑 유사하게 congestion control과 loss recovery를 함. 그리고 TLS를 필수로 하는데 성공했고 그래서 모든 HTTP3 연결은 암호화되어 있음. ⇒ tcp을 대신하는 UDP based 새로운 transport 프로토콜임

범용의 트랜스포트 프로토콜로 다른 애플리케이션 protocol이 그 위에서 사용될 수 있고 첫 application layer protocol이 HTTP/3임.

QUIC의 장점

1. UDP based new transport protocol

• QUIC은 TCP랑 유사하게 congestion control과 loss recovery를 함. 그리고 TLS를 필수로 하는데 성공했고 그래서 모든 HTTP3 연결은 암호화되어 있음. ⇒ tcp을 대신하는 UDP based 새로운 transport 프로토콜임
• UDP 위에 새로운 계층을 추가함으로써 신뢰성을 제공하고 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공
• 범용의 트랜스포트 프로토콜로 다른 애플리케이션 protocol이 그 위에서 사용될 수 있고 첫 application layer protocol이 HTTP/3임.

 

2. Connection based Transport

QUIC Connection

• quic도 connection 개념이 존재. 왼쪽과 오른쪽 엔드포인트 사이에 논리적인 선을 만듦.
• tcp처럼 handshake로 연결 설정을 가지며 연결 설정의 지연시간을 줄임.
• 연결 설정은 버전 협상, 암호화, 전송 handshake로 구성.
• quic의 연결을 통해 실제 데이터를 보내려면 하나 이상의 스트림을 만들어서 사용해야함.

QUIC Connection ID

• ip주소와 connection id는 서로 독립적임. 보통 tcp에서는 소켓번호로 ip주소+포트 번호를 쓰는데 QUIC에서는 독립적으로 connection id를 사용하기 때문에 ip주소가 바뀌어도 연결이 유지됨.
• 따라서 만약 클라이언트 id가 커넥션을 계속 유지한다면 이동하면서 세션 끊기는 것에 대한 부담이 없음.

 

3. Stream based Transport

⇒ QUIC은 하나의 연결로 다수의 병렬 스트림을 전송하며, 스트림 간에 영향을 주지 않고 데이터를 동시에 전송. HTTP2의 하나로 뭉쳐있던 것들이 나와서 QUIC이 되고 나와서 HTTP3가 됨. QUIC은 연결과 스트림 레벨에서 흐름제어와 에러검출을 하고 우선순위도 처리함.

 

4. Independant streams avoid HOL blocking

상호독립적인 stream들 덕분에 HOL blocking문제를 해결. 즉, udp based라서 앞에 있는 것들이 안가진다고 뒤에 있는 것들이 안가지지 않음

 

5. Secure Communication

QUIC의 연결 설정 과정이 TLS1.3과 밀결합되어 있음. 원래 TCP TLS는 서로 독립적이라서 따로 따로 뚫지만 QUIC 은 새로 만들때 그냥 같이 써야해서 같이한다.

QUIC이 TLS1.3을 사용한 주된 이유는 handshake에 더 적은 라운드 트립이 필요하도록 바뀌었기 때문으로 프로토콜 지연을 줄여주는 효과가 있음.

TLS를 기본으로 사용하므로 , 웹 사용자가 기대하고 원하는 HTTPS의 모든 보안 속성을 지원

 

6. Reduced Signaling latency

QUIC은 0-RTT, 1-RTT(round trip time - 내가 보내고 다시 응답을 받는 시간, 1같은 경우는 내가 보냈으면 하나를 받아야한다는 의미.) handshake를 제공 → 새로운 연결을 협상하고 설정하는데 걸리는 시간을 줄여줌.

QUIC은 연결 설정을 하면서도 데이터를 보내는 얼리 데이터(early data)도 지원

기존의 경우엔 tcp연결과 tls연결이 따로 해서 시간이 많이 걸리지만 quic은 같이 설정하기 때문에 연결 설정 지연이 줄어들음.

QUIC은 연결 설정 시에도 상대방과 관련된 보안과 관련된 정보를 한번 연결해놨던걸 cache에 저장하고 다시 재연결을 했을때 안바뀌었으면 과거에 가지고 있는 연결로 재활용해서 연결설정하자마자 그냥 데이터도 같이 쏴버린다 → 이런 경우 0RTT가 나옴.

HTTP/3는 기존 url 체계를 유지함(https://url)

https로 요청을 하게 되면 최신 클라이언트와 서버는 아마 첫 handshake로 tcp인 http/2로 협상(or HTTP/1)을 하게 됨 → 연결이 설정되고 클라이언트의 HTTP 요청에 서버가 응답할때 서버는 Alt-Svc: h3=”:50781”를 통해 50781 UDP포트에서 HTTP/3를 사용할 수 있음을 client에게 같이 알려줌. → 이후 클라이언트가 QUIC연결을 설정하려고 시도하고 성공하면 이후 HTTP3로 통신.

HTTP/3 frame

HTTP/3도 마찬가지로 스트림을 쪼개서 프레임으로 데이터를 보내고 header도 압축된 HTTP 헤더를 보내는데 여기서는 QPACK에 의해 압축해서 보냄. 데이터도 마찬가지로 보내고 여기에서 GOAWAY라는 연결을 종료하는 메시지가 새로 등장.

우선순위 제어

HTTP/3 스트림 프레임 중에는 우선순위를 설정하는 PRIORITY라는 프레임이 있고 HTTP2에서도 비슷하게 동작. 이 프레임은 특정 스트림이 다른 스트림에 의존하도록 설정할 수 있고 가중치를 설정 가능.

상하종속관계면 상위에 있는 애가 먼저 처리되고 같은 부모를 가진 경우 각각의 가중치 별로 리소스를 할당. 세부적인 동작의 일부에만 차이가 있을뿐 컨셉은 그대로 유지!

서버 푸쉬

이것도 세부적인 입장에선 다르지만 대체적으로 비슷. 클라이언트가 최대 푸시 스트림의 id가 무엇인지 서버에게 알려주어서 얼마나 많은 푸시를 받을지를 제한.

서버는 PUSH_PROMISE라는 프레임을 보내서 서버푸쉬를 함. 클라이언트는 받지 않을 경우 CANCEL_PUSH프레임을 보냄.

QUIC의 단점

• Non socket API
  • quic은 커널 안에 있지 않고 그 위에 존재. 그래서 표준 api가 없음. 그래서 quic 라이브러리를 누가 구현했는지에 따라서 달라짐. 애플리케이션을 어떤 부분에서 하나의 라이브러리에 락인 시키고 다른 라이브러리로 바꾸지 못함(많은 작업들이 필요).
• Kernel & Code optimization
  • 현재 udp 코드는 최적화가 되어있지 않음 → 그래서 실질적으로 같은 정보를 주고 받을 때 linux의 udp부분이 tcp부분보다 느림. → 리눅스 커널 안에 있는 udp코드 수준이 tcp보다 떨어짐. 지금까지 tcp만 썼기 때문에.
  • 네트워크 성능은 빨라졌는데 cpu사양이 일반보다 2배정도 더 필요함.