🍏 QUIC
✅ 현대 통신 프로토콜 패러다임
- Out of Kernel
- Powershift from Standard to Opensource
- Out of TCP
✅ QUIC
- UDP 위에서 돌아가는 빠른 프로토콜 + 기본적으로 에러 검출 및 복구 가능
- TCP 이후에 40년 만의 프로토콜이다
- QUIC에 HTTP/3만 올릴 수 있는 것 X
- 굉장히 많은 애플리케이션이 돌아갈 수 있다.
🍏 QUIC & HTTP/3 출현 배경
- 출현 배경 : 결국은 TCP의 문제를 퀵에서 고치고 그다음에 http2에서 했던 것들을 좀 더 하는 것이 공식적으로 이론적으로 공정하게 얘기할 수 있는 출연 배경
✅ 화석화(Ossification) 탈피
-
보안/암호화(TLS)을 강조
-
웹 브라우저와 웹 서버 사이에 있는 애들은 아무것도 몰라야 돼. 만약에 프록시가 있다 그러면 웹 브라우저 프록시 웹 서버를 제외했을 땐 아무것도 몰라야 돼요
-
구글의 브라우저 구글 서버 허가한 구글의 프록시를 제외하곤 아무도 몰라야 돼요.
암호화로 다 감싸버립니다 -
암호화
- 더욱 안정된 네트워크 경험을 사용자에게 제공 - 구글 혹은 서비스를 만든 사람이 브라우저하고 서버 레벨에서 암호화 가능 -> SKT KT와 같이 제3자가 개입을 원하지 않기 때문에 좋아함.
- 암호화를 함으로써 발생하는 성능의 저하도 감수할 정도로 남이 못 보게 하는 것이 이득이 될 수 있다는 것.
✅ TCP의 문제점
- Slow Start
- Loss가 발생했을 때 성능이 크게 저하된다.
- Flow Control 하는 buffer size가 너무 작다.
- TCP = 한 줄로 가는 서비스
- 한 줄로 가는 서비스들에 대해서 독립적으로 제어하지 못하고 주고받는 정보가 여러 애플리케이션에서 내려오더라도 하나로 묶어서 시퀀스 넘버를 할당했다. 따라서 에러가 발생하면 이후의 서비스들에 영향을 끼쳤다.
- HOL Blocking = http2가 TCP를 쓰기 때문에 여전히 완전히 해결하지는 못했다.
🍏 QUIC의 특징 & 장점
✅ UDP base New Transport Protocol
= TCP와 유사한 기능 / 신뢰성 보장
- 에러 검출 및 복구
- 속도 제어라 / 우선순위 제어
- Condition Control
- TLS 필수화 성공 = 모든 HTTP 3 연결은 암호화되어 있다
- QUIC = 4계층 / UDP = 4계층
하나의 Transport Layer에 2개의 프로토콜 존재 - HTTP/3가 QUIC 위에 올라간다
- HTTP/4는 보통 Application Layer라고 한다.
- HTTP/4는 보통 Application Layer라고 한다.
✅ Connection based Transport
QUIC Connection
- QUIC = 논리적으로 연결 설정 해제를 한다
- HTTP/2의 Logical 연결 + Stream 개념과 유사
- 대신 지연시간 감소됨
- 실제 데이터를 보내려면 하나 이상의 Stream을 만들어서 사용해야 한다.
QUIC Connection ID
대왕 장점 : IP 어드레스가 바뀌어도 Connection ID가 유지된다 = 이동 중에도 서비스가 끊어지지 않는다
- HTTP/2와 유사하게 Connection 마다 ID를 부여할 수 있다.
- IP Add와 Connection ID가 독립적
- Connection ID는 IP Add 정보를 갖지 않는다. 본인의 고유한 ID이다.
- 이전의 TCP/IP SW는 IP Add가 바뀌면 연결이 끊어졌다.
- IP 어드레스가 바뀌어도 Connection ID가 유지된다
- 밑에 애들이랑 연결 XX
- Ex) 카페 와이파이 쓰다가 카페를 벗어나서 이동통신으로 바뀐 경우 = IP Add가 바뀐다
그래도 서비스가 끊어지지 않는다.
- IP Add가 바뀌더라도 Client Server가 Connection ID를 유지한다면 이동하면서도 서비스가 끊기지 않을 수 있다.
- 이전에는 TCP Session이 끊겨서 다시 연결을 해줬어야 했다.
✅ Stream based Transport
- QUIC = 하나의 연결로 다수의 병렬 스트림을 전송하며 스트림 간에 영향을 주지 않고 데이터를 동시에 전송한다.
- HTTP/2에서 Stream 레벨에서 Multiplexing 한 것 처럼
- Stream ID : 64 bit
- 굉장히 많은 것들을 동시다발적으로 주고받을 수 있다.
- Stream 순서에 상관 없이 상호 독립적으로 주고받는다.
- 흐름 제어 / 에러검출 / 우선 순위 제어
✅ Independent Streams avoid HOL Blocking
- UDP Based
- Stream 간의 상호관계 없이 동시다발적으로 주고받을 수 있다.
- 에러가 발생해도 뒤에 있는 애들이 막히지 않는다.
✅ Secure Communication
- 원래 TCP와 TLS의 관계는 서로 독립적이다.
- TCP 연결 후에 TLS 연결 방식
- QUIC에서는 TLS의 연결 설정 과정을 함께 수행을 해요.
- 프로토콜 지연 감소
- TLS를 기본으로 사용하므로, 웹 사용자가 기대하고 원하는 HTTPS의 모든 보안 속성을 지원한다.
✅ Reduced Latency
-
Early Data 지원
연결 설정을 하면서 데이터를 보낼 수 있는 것 -
일반적 TCP/TLS vs QUIC
- QUIC은 TLS에 대한 연결 설정 과정을 QUIC의 연결 설정 과정 안에 포함했기 때문에 추가적 TLS 연결 과정이 필요 없어졌다
- 그 결과 상대방에게 메세지를 보내기 까지의 대기 시간이 줄어든다.
- 가속화된 TCP/TLS vs QUIC
- QUIC은 연결 설정 시에 상대방에 관련된 정보 보안과 관련된 정보를 가지고 있다 = 주고 받는 정보가 적어진다.
- 새로운 연결을 설정하는데 필요한 시간을 줄이려고 이전에 연결했던 클라이언트는 해당 연결의 특정 파라미터를 캐시한 뒤 이어서 서버와 0-RTT 연결을 설정한다. = 과거의 정보를 새로운 연결 시에 재활용
- 0-RTT : Client는 핸드쉐이크가 완료되기를 기다리지 않고 바로 데이터를 보낼 수 있다. 대기시간 0.
- 연결 설정을 시작하자마자 데이터를 같이 보내버리는 것 = 아주 빨라짐!
< 정리 >
- TCP 연결 설정 XX + TLS에 대한 연결 설정도 더 짧아짐 = 초기 연결 설정 시에 Signaling이 확 줄어든다.
- HTTP request가 나갈 때까지의 시간이 처음 연결 시에도 짧아졌고 재연결 시에도 상당량 짧아졌다.
- 주고받는 메시지도 줄어든다.
- 메시지가 응답이 오기 전 데이터를 쏴버릴 수도 있다.
🍏 HTTP/3
✅ HTTP/3 Frame
- HEADERS : QPACK으로 압축된 HTTP 헤더
- DATA : binary data 콘텐츠
- GOAWAY : 연결 종료하는 메세지
- Request/Response
- Data가 클 경우 여러개로 쪼개서 내려간다.
✅ 우선 순위 제어
- HTTP/2와 거의 유사
- 종속 관계면 상위에 있는 애가 먼저 처리
- 같은 부모를 가지고 있는 경우에는 가중치별로 리소스를 할당받음.
✅ HTTP/2와 HTTP/2의 유사점
- Stream 제공
- 서버 푸시 지원
- 헤더 압축 제공
- Stream을 이용해 하나의 연결을 통해 Multiplexing 제공
- Stream에 우선순위 할당
✅ HTTP/2와 HTTP/2의 차이점
- 가장 큰 장점 : 연결 설정의 지연 감소
