개요

인터넷 기술 표준화를 주관하는 IETF(Internet Engineering Task Force) WG(Working Group)에서는 HTTP-over-QUIC의 정식 이름은 HTTP/3입니다.에 의견을 모았다.(설이 씨가 지적한 내용을 수정했다)
그런데 이 QUIC와 HTTP/3은 도대체 무엇일까요?
나는 우리 엔지니어들에게 웹 페이지의 관계를 고려해 보았다.
이 기사는 이상한 문서이기 때문에'잡동사니'라고 적힌 부분은 제 개인적인 의견으로 가볍게 틀어주세요.
추기
번역했습니다HTTP/3 자세히 알아보기!나는 대충 이해한 후에 이 책을 보는 것이 비교적 좋다고 생각한다.

QUIC·HTTP/3은 무엇입니까?

QUIC

QUIC는 Google 엔지니어가 제안한 사양을 시작으로 제작된 새로운 전송층 프로토콜입니다.
기존에는 gQUIC(Google의 규격·실현)와 IETF QUIC(IETF의 QUIC 규격) 두 가지가 있었지만, 올해 중순 구글이 IETF의 QUIC에 규격을 통합한다는 발표를 해 당분간 gQUIC의 주장을 무시해도 괜찮다.(기타)
목적과 기능은 여러 방면에 관련되어 있는데 대체로 다음과 같은 몇 가지 방면으로 나뉜다.

1. 로컬 사용자 암호화

QUIC에서 TLS1을 암호화하려면그 규격에 포함된 3을 사용했다.
구체적으로 TLS는 인증 부분과 키 교환 제공 알고리즘을 제공하고 실제 암호화는 QUIC 층에서 제어한다.
기존 TLS12에서 TLS 1. 암호화 채널 설정에 3RTT(Round Trip Time)를 사용합니다.3은 0-1RTT 연결이기 때문에 비용이 적고 암호화 통신을 더 일찍 할 수 있다.
TLS1.3의 0-RTT, 이 일대와 이 일대에 대해 자세히 알고 싶습니다.

2. UDP에서 작업

TCP에 다음과 같은 잠재적인 문제가 있습니다.

연결을 구축하려면 3-way handshake가 필요하기 때문에 데이터 제공이 시작될 때까지 비용이 많이 든다

데이터의 재발급 처리, 혼잡 제어가 있지만 순서대로 그룹에 도착해야 하기 때문에 데이터 전송의 효율이 떨어진다

원래 TCP 자체가 낡았다

QUIC는 이 문제를 해결하기 위해 UDP의 QUIC층에서 혼잡 통신을 복용하는 등 제어를 한다.말하자면 UDP에 내가 생각했던 오늘의 새로운 TCP를 다시 설치한 것 같다.

HTTP/3is Ha

HTTP/3은 HTTP-over-QUIC, 즉 QUIC 프로토콜에서 HTTP(HTTP/2API)를 실행하는 규격입니다.
나도 잘못한 시기가 있다. 그러나 QUIC는 HTTP/3이 아니기 때문에 IETF QUIC는 완전한 전송 프로토콜로서의 입장이 있는 것 같고 HTTP층은 따로 존재한다.
그러나 실제 실시에서 더욱 선진적인 gQUIC에 HTTP/2의 API가 포함된 것은 실시의 보급률을 감안하면 HTTP/3≈QUIC도 큰 괴리가 없을 것이다.(기타)
QUIC의 프로토콜 오버뷰는 다음 이미지 형식입니다.( Image credit )

HTTP/2에는 기존 HTTP/1.1 문제를 해결하는 Hol Blocking의 중요한 구조와 데이터 전송량을 줄이기 위한 다양한 구조가 들어가 있으니 꼭 조사해 봐야 한다.
TLS1.3. UDP+QUIC, HTTP/2를 통해 3단조 통신 비용을 개선했다. CDN 등으로 가져오면 인터넷상의 업무 전체에 큰 변화가 있을 것이라고 생각한다.(LINE과 Akamai 등이 실적 보고를 했다는 보도도 있어 참고만 한다.)

상세히 보기

우선 HTTP/3 자세히 알아보기 읽어보고 전체적인 상황을 이해하면 된다.
더 자세히 알고 싶으면 IETF의 초안 문서!

영어가 어려워요. 일본어로 해주세요.

몇몇 사람이 일본어로 QUIC 관련 정보를 공개했다.저쪽 트위터와 블로그를 팔로우할 수 있어요.

설이의 블로그: https://asnokaze.hatenablog.com/

눈의 트위터: https://twitter.com/flano_yuki

대진 선생의 블로그: https://jovi0608.hatenablog.com/

대진 씨의 트위터: https://twitter.com/jovi0608

대진 선생의 슬라이드: https://speakerdeck.com/shigeki

tatsuhiro-t의 Qita:https://qiita.com/tatsuhiro-t

카주호의 트위터: https://twitter.com/kazuho

kazuho의 슬라이드: https://speakerdeck.com/kazuho

mozaic.fm: https://mozaic.fm/

HTTP/2 학습회의 connepass:https://http2study.connpass.com/

차세대 웹 회의의 connepass: https://nextwebconf.connpass.com/

Fukabori.fm #1: https://fukabori.fm/episode/1

노골적인 블로그 홍보: https://inductor.hatenablog.com/

영향 범위는?

지금은 별다른 언급이 없지만, 연말 WG 움직임도 큰 폭으로 규격을 정하는 방향으로 흘러갈 것으로 보인다.
아마 내년에 정식 스타일로 나올 거예요.
어플을 만드시는 분들께 직접적인 영향이 있을지는 모르겠지만.
웹(HTTP/3)의 컨텍스트로서 브라우저의 대응 상황은 매우 큰 관계가 있습니다.
로컬 애플리케이션과 다른 프로토콜의 QUIC 대응에 있어 다양한 OS의 커널 수준에서 모듈 대응이 중요하다고 생각합니다.
트위터에서 커널 레벨에 의존하지 않기 위해 UDP를 사용한다는 말이 나오자 취소한 것이다.

QUIC의 설치 상태는?

웹 서버라면
TLS1에서 QUIC까지.3이 필수조건인 만큼 케이디의 대응은 미뤄진 것 같다.
나는 내 관측 범위 내에서 이 점을 주목할 것이다.
https://github.com/mholt/caddy/issues/2080
https://github.com/h2o/h2o/pull/1846

최후

QUIC 좋아요.