4. 대역폭 vs 지연 시간
https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
4
5. TCP
● 널리 사용되고 있음: 네트워크 상의 미들박스의 존재
● 고착화(Ossification) 문제 - 추가 확장이 어려움
● 여러가지 추가 확장과 기법이 존재 - 혼잡 제어, 유실 복
구 기법이나 fast open 과 같은 신기능 구현 여부도 플랫
폼마다 버전마다 약간씩 다름
5
10. UDP 기반 프로토콜을 만드는 이유
- 커널 구현이 아니고 사용자 프로그램에서 구현이 가능 -
호환성이 좋고 테스트하기 쉬움
- UDP을 인터넷 프로토콜 개발의 기반으로
- 인터넷에서 UDP는 이미 동작하고 있음
- UDP상에서 새로운 프로토콜을 만들자!
- 루트/관리자 권한이 필요하지 않음
- RFC8085의 가이드라인 참조
10
11. QUIC + HTTP3
11
QUIC
- TLS 1.3 기반으로 암호화 기본
- 속도 (적은 수의 왕복, 0-RTT등)
- 혼잡 제어, 유실 복구, 흐름 제어 기능
- Head-Of-Line Blocking 이 없음 (한 패킷 유실이 다른 스트림을 멈추지 않음
)
- 연결 이전 (e.g. LTE -> Wifi)
HTTP/3
- HoLB를 없애기 위해 QPACK 으로 헤더 압축
- 프레임 단위 구조 (HTTP/2와 유사하나 동일하지는 않음)
- 1:1 QUIC 스트림 : HTTP/3 요청/응답
14. 14
HEADERS HEADERS DATA
스트림 #1 (GET)
HEADERS HEADERS DATA
스트림 #2 (POST)
HEADERS HEADERS DATA
스트림 #3
HEADERS HEADERS DATA
스트림 #4
QUIC 연결 안의 HTTP/3 요청 (간단 버전)
DATA
QUIC 연결
15. 현재
● 구글 QUIC
○ 구글이 2010년 초에 QUIC 프로젝트를 시작
● IETF QUIC
○ IETF 표준화 작업 중
○ https://quicwg.org/
○ 2020/4/15 기준 Draft 27 버전
15
23. TCP
● Everyone use it, even in the middleboxes you don’t
know it exists
● Ossification - difficult to extend/deploy
● Many extensions and techniques - every device in the
Internet may have different implementations and
options (congestion control algorithms, loss recovery
techniques, fast open, etc etc…)
23
28. Why UDP-based transport?
- Userland implementation is possible - more portable
and easy to test
- UDP as a placeholder for a new Internet protocol
- It works on the Internet already
- Implement your own on top of UDP!
- No root/admin privilege is required
- RFC8085
28
29. QUIC + HTTP3
29
QUIC
- Secure by default (TLS 1.3)
- Faster (Less round trip, 0-RTT)
- Congestion control, loss recovery and flow control
- No Head-Of-Line blocking
- Connection Migration (e.g. User moved from LTE to Wifi)
HTTP/3
- Header compression by QPACK (for no HoLB)
- Frames (similar to HTTP/2 but not same)
- 1:1 QUIC Stream : HTTP/3 Request/response
32. 32
HEADERS HEADERS DATA
Stream #1 (GET)
HEADERS HEADERS DATA
Stream #2 (POST)
HEADERS HEADERS DATA
Stream #3
HEADERS HEADERS DATA
Stream #4
HTTP/3 in a QUIC connection (simplified)
DATA
A QUIC Connection
33. Where we are
● Google QUIC
○ Google started QUIC early 2010
● IETF QUIC
○ IETF Standardization in progress
○ https://quicwg.org/
○ Draft 27 as of today (2020/4/15)
33