1.1

1.2

1.2.1

1.2.2

1.2.3

1.2.4

1.2.5

1.2.6

1.3

1.3.1

1.3.2

1.3.3

1.4

1.4.1

1.4.2

1.4.3

1.4.4

1.4.5

1.4.6

1.4.7

1.4.8

1.4.9

1.5

1.5.1

1.5.2

1.5.3

1.5.4

1.5.5

1.5.6

1.5.7

1.6

1.6.1

1.6.2

1.6.3

1.6.4

1.6.5

1.6.6

1.7

1.8

차례

Introduction

왜QUIC인가

HTTP/2를기억하는가?

TCPHOL(headofline)블로킹

TCPorUDP

고착화(Ossification)

안전

감소된지연시간

과정

IETF

HTTP/2에서의경험

상태

프로토콜기능

UDP

신뢰성

스트림

순서에맞는전송

빠른핸드쉐이크

TLS1.3

전송계층과애플리케이션계층

QUIC을통한HTTP/3

QUIC을통한HTTP가아닌프로토콜

QUIC의동작방식

연결

TLS을사용하는연결

스트림

0-RTT

스핀비트

사용자영역

API

HTTP/3

HTTPS://URL

Alt-svc로부트스트랩하기

QUIC스트림과HTTP/3

우선순위정하기

서버푸시

HTTP/3과HTTP/2의비교

일반적인비판

명세

2

1.9QUICv2

3

HTTP/3해설

이책은2018년3월에작성하기시작했다.HTTP/3와그기반프로토콜인QUIC이왜,어떻게동작하는지와프로토콜의상세내용,그구현체등을설명할계획이다.

이책은완전히무료이므로돕고자하는사람은누구나참여해서같이만들수있다.

사전요구사항

이책의독자는TCP/IP네트워크,HTTP의기본,웹을어느정도이해하고있다고가정한다.HTTP/2에대해서더알고싶다면

http2explained를읽어보기를권장한다.

저자

이책은DanielStenberg가시작해서만들어졌다.Daniel은세계에서가장널리사용되는HTTP클라이언트소프트웨어인curl을만든사람이자curl의리드개발자다.Daniel은20년넘게HTTP와인터넷프로토콜로일했고http2explained의저자이기도하다.

홈페이지

이책의홈페이지는daniel.haxx.se/http3-explained다.

도움요청

이문서에서실수,누락,오류,속보이는거짓말등을발견한다면해당문단의수정버전과함께보내주면수정하고도움준사람에

게적절한크레딧을줄예정이다.이문서가점점나아지기를기대한다.

가능하면이책의github페이지에이슈를생성하거나풀리퀘스트를제출해주기바란다.

라이센스

이문서와모든내용은CreativeCommons저작자표시4.0국제라이센스하에배포된다.

Introduction

4

왜QUIC인가

QUIC은약어가아니라이름이다.영어단어"quick"과똑같이발음한다.

QUIC은많은부분에서HTTP같은프로토콜에적합하다.TCP와TLS에서동작하는HTTP/2의단점으로알려진문제를해결하면

서안정적이고안전한새전송프로토콜로볼수있다.

QUIC은HTTP전송에만국한되지않는다.최종사용자에게웹과데이터를더빨리전달하려는바람이초기이새로운전송프로토

콜을만들게된가장큰이유이자원동력이다.

그러면새로운전송프로토콜은왜만들고왜UDP상에서동작하게했는가?

왜QUIC인가

5

HTTP/2를기억하는가?HTTP/2명세인RFC7540는2015년5월에발행되었고이후인터넷과월드와이드웹에널리구현되고배포되었다.

2018년초상위1,000개의웹사이트중거의40%가HTTP/2로동작하고있으며Firefox가보낸모든HTTPS요청의70%정도가

HTTP/2응답을받았고주요모든브라우저와서버,프락시가이를지원하고있다.

HTTP/2는HTTP/1의수많은결점을수정했고HTTP의두번째버전을도입함으로써사용자들이수많은우회법을사용하지않게

되었다.그중일부는웹개발자에게상당한부담이었다.

HTTP/2의주요기능중하나인멀티플렉싱을사용하여같은물리TCP연결을통해다수의논리스트림을보낼수있게된것이다.이는많은것을더좋고빠르게만들었다.또한,혼잡제어작업을훨씬낫게해주어사용자가TCP를훨씬잘사용하게되면서대역

폭을적절하게가득채워서사용해TCP연결을더오래유지되도록만들었다.이는이전보다더자주최대속도를낼수있기때문

에좋아진것이다.헤더압축은대역폭을적게사용하게끔해준다.

이전에는브라우저가호스트당6개의TCP연결을사용했지만,HTTP/2를사용하면보통하나의TCP연결을사용한다.사실

HTTP/2에서연결병합과"desharding"기술을사용하면연결수를훨씬더줄일수도있다.

HTTP/2는클라이언트가다음요청을보내기전에첫요청이끝나기를기다려야하는HTTPHOL(headofline)블로킹문제를고쳤다.

HTTP/2를기억하는가?

6

TCPHOL(headofline)블로킹

HTTP/2는TCP를사용하며이전HTTP버전을사용할때보다더적은TCP연결을사용한다.TCP는신뢰할수있는전송프로토

콜이고기본적으로두머신간의가상체인으로생각해도된다.네트워크의한쪽끝에넣은것이최종적으로다른쪽끝에같은순서

로나올것이다.(아니면연결이끊어진다.)

HTTP/2를사용하는일반적인브라우저는TCP연결한개로수십,수백개의병렬전송을한다.

HTTP/2로통신하는두엔드포인트사이네트워크어딘가에서하나의패킷이빠지거나없어진다면없어진패킷을다시전송하고목적지를찾는동안전체TCP연결이중단되게된다.즉,TCP는"체인"이기때문에한링크가갑자기사라지면그링크이후에와야

하는모든것들이기다려야한다는뜻이다.

체인메타포를사용해서이연결을통해두스트림을보내는경우를그린그림을보자.빨간색스트림과녹색스트림이있다.

이는TCP에기반을둔headofline블로킹이된다!

패킷손실률이증가하면HTTP/2의성능도저하된다.테스트를통해패킷손실률이2%(상기하자면,이는끔찍한네트워크품질이

다)일때HTTP/1사용자가더나은것으로입증했다.그이유는HTTP/1은보통손실된패킷을분배하는데6개의TCP연결을갖고

있어서손실된패킷이없는다른연결은계속사용할수있기때문이다.

TCP를사용하는한이이슈를고치는것은(가능할수도있지만)쉽지않다.

차단을피하는독립스트림

QUIC에는두엔드포인트간에연결을안전하게하고데이터전달을신뢰할수있게하는연결설정이있다.

이연결을통해두가지다른스트림을설정했을때이들을독립적으로다루므로스트림중하나에서어떤링크가사라지더라도해당스트림만(특정체인)멈추고재전송될없어진링크를기다란다.

다음은두엔드포인트간에노란색과파란색스트림을보내는그림이다.

TCPHOL(headofline)블로킹

7

TCPHOL(headofline)블로킹

8

TCP혹은UDPTCP에서head-of-line블로킹을해결할수없다면이론적으로네트워크스택에서UDP와TCP옆에새로운전송프로토콜을만들

수있다.아니면RFC4960에서IETF가표준화하고여러가지원하는특성이있는전송프로토콜인SCTP를사용할수도있다.

하지만,최근수년간새로운전송프로토콜을만들려는노력은인터넷에서그것을배포하는어려움때문에완전히멈춰있다.새프로토콜배포는그프로토콜이도달해야하는사용자와서버사이에있는TCP와UDP만허용하는방화벽,NAT,라우터등의미들박

스에의해방해받고있다.다른전송프로토콜의도입은UDP또는TCP가아닌경우이를악의적이거나뭔가잘못되었다고판단하

고차단해버리는박스들에의해차단되므로연결의N%가실패한다.노력을기울이기에N%실패율은너무높다고여겨진다.

게다가보통네트워크스택의전송프로토콜계층에서뭔가를바꾼다는것은보통운영체제커널에서구현한프로토콜을말한다.새로운운영체제커널을갱신하고배포하는것은상당한노력이필요한느린과정이다.IETF가표준화한수많은TCP개선사항도광범위하게지원되지않아서널리배포되거나사용되지않고있다.

왜SCTP-over-UDP가아닌가

SCTP는스트림을가진신뢰성있는전송프로토콜이고WebRTC처럼UDP위에서이프로토콜을사용하는기존의구현체도있다.

다음의몇가지이유로QUIC의대체재로충분하지않다고생각했다.

SCTP는스트림에대해head-of-line블로킹문제를고치지못한다

SCTP는연결을설정할때스트림의수를결정해야한다

SCTP에는견고한TLS/보안에대한언급이없다

SCTP는4단계핸드쉐이크(4-wayhandshake)를사용하고QUIC은0-RTT를제공한다

QUIC는TCP같은바이트스트림(bytestream)이고SCTP는메시지기반이다

QUIC연결은IP주소사이에서마이그레이션을할수있지만SCTP는할수없다

자세한차이점이알고싶다면AComparisonbetweenSCTPandQUIC을참고하라.

TCPorUDP

9

고착화(Ossification)인터넷은네트워크의네트워크다.이네트워크의네트워크가의도대로동작하게하는장비가인터넷여러곳에설치되어있다.우리

는이러한기기(네트워크에분포된박스)를미들박스라고부른다.이박스는전통적인네트워크데이터전송의주요요소인두엔드

포인트사이에있다.

박스는여러가지다른목적이있지만무언가동작하게하려면이박스가해당위치에있어야한다고누군가생각했기때문에곳곳

에깔린것이라생각한다.

미들박스는네트워크사이에서IP패킷을라우팅하고,악성트래픽을차단하고,NAT(NetworkAddressTranslation)역할을하고,성능을향상시키고,통과하는트래픽을감시하는등의역할을한다.

이러한박스는의무를다하려면자신들이모니터링하고수정하는네트워크및프로토콜에대해반드시알아야한다.박스는이런목적으로소프트웨어를실행한다.그소프트웨어를항상자주업그레이드하는것은아니다.

박스는인터넷이유지되도록연결하는구성요소이지만종종최신기술을따라잡지못하는경우가있다.보통네트워크중간영역은

전세계의클라이언트나서버같은엣지만큼빠르게바뀌지않는다.

어떤프로토콜을검사하기를원하는지,그리고어떤것이괜찮고안괜찮은지알고있는박스들은과거에배포되었고그당시의프로

토콜기능셋을가지고있다.이전에는몰랐던새로운기능이나동작의변경사항이추가되면박스가이를잘못된것이나허용하지

않는것으로판단할위험이있다.그래서이러한트래픽은사용자가해당기능을사용하고싶지않을정도로지연되거나중단될수있다.

이를"프로토콜고착화(ossification)"라고부른다.

TCP를변경하는것도고착화문제를겪는다.클라이언트와원격서버사이에있는박스중일부는알지못하는새로운TCP옵션을

발견하고이옵션이무엇인지몰라서해당연결을차단해버릴것이다.프로토콜의상세내용을탐지하도록허용한경우시스템은프로토콜이보통어떻게동작하는지배우게되고시간이지나면프로토콜을변경할수없게된다.

유일하게고착화를"방지하는데"효과적인방법은미들박스가지나가는프로토콜에서많은것을볼수없도록통신을최대한암호

화하는것이다.

고착화(Ossification)

10

안전

QUIC은항상안전하다.이프로토콜에는일반텍스트버전이없으므로QUIC연결과협상하려면TLS1.3을사용해서암호화및보안을수행해야한다.위에서언급했다시피,이는다른차단이나특별한처리같은고착화문제를방지할뿐만아니라QUIC이웹사용자가기대하고원하는HTTPS의모든보안속성을가지게만든다.

암호화프로토콜협상이이뤄지기전초기핸드쉐이크패킷에일반텍스트메시지가아주조금있다.

안전

11

더이른데이터

QUIC는0-RTT,1-RTT핸드쉐이크둘다제공하는데이는새로운연결을협상하고설정하는데걸리는시간을줄여준다.TCP의3단계핸드쉐이크(3-wayhandshake)와비교해보면된다.

여기에추가로QUIC은더많은데이터를허용하는"이른데이터(earlydata)"를처음부터지원하고이는TCPFastOpen보다더쉽게사용할수있다.

스트림개념을사용해서기존에존재하는연결이끝나기를먼저기다릴필요없이같은호스트로의또다른논리연결도동시에처리될수있다.

문제가있는TCPFastOpenTCPFastOpen는2014년12월RFC7413로발행되었고이명세는이미전달된첫번째TCPSYN패킷에서버로보낼데이터를

전달하는방법을설명한다.

현실에서이기능의실제지원은시간이걸렸고2018년인오늘날까지도문제로가득하다.TCP스택을구현하는사람이문제를이미겪었으므로애플리케이션이이기능의이점을취하려고시도했다.이를활성화하기위해OS버전이무엇인지알아야할뿐만아니라문제가발생하면그레이스풀하게철회하고문제를다루는방법을찾아내야한다.여러네트워크가TFO트래픽을방해하는것으로밝혀졌고이러한TCP핸드쉐이크를적극적으로망쳤다.

감소된지연시간

12

과정

Google의JimRoskind가초기QUIC프로토콜을설계하고2012년처음구현했으며Google의실험을확대한2013년전세계에

공개적으로발표했다.

그당시에는QUIC이"QuickUDPInternetConnections"의약자라고주장했었지만,이후에는없어졌다.

Google이프로토콜을구현하고이어서널리사용되는자신들의브라우저(Chrome)와서버사이드서비스(Google검색,gmail,youtube등)에배포했다.Google은프로토콜버전을꽤빠르게올리면서이개념이시간이지남에따라엄청난수의사용자에게신뢰할수있게동작한다는것을증명했다.

2015년6월표준화를위해QUIC의첫번째인터넷드래프트버전을IETF에제출했지만2016년후반이되어서야QUIC워킹그룹

이승인되어시작되었다.하지만이후바로많은단체의엄청난관심을받으면서시작되었다.

2017년Google의QUIC엔지니어가인용한수치에따르면전체인터넷통신량의약7%가이미QUIC을사용한다고한다.이는

QUIC프로토콜의Google버전이다.

과정

13

IETFIETF에서프로토콜을표준화하려고만든QUIC워킹그룹은QUIC프로토콜이"단순히"HTTP가아닌다른프로토콜을전송할수있어야한다고빠르게결정했다.Google-QUIC은오로지HTTP만전송했고실제로HTTP/2프레임문법을사용해서HTTP/2프레

임을효과적으로전송했다.

IETF-QUIC은Google-QUIC이사용한"커스텀"접근방법이아니라TLS1.3의암호화와보안을기반으로두어야한다고도발표했

다.

HTTP보다더많이보내야한다는요구를만족시키기위해IETFQUIC프로토콜아키텍처를두가지별도의계층인전송QUIC과"HTTPoverQUIC"계층(후자는종종"hq"라고도한다)으로분할했다.

무해할것처럼들렸던이계층분할로인해IETF-QUIC은원래의Google-QUIC과많이달라졌다.

하지만워킹그룹은곧적절하게집중해서제때QUIC버전1을제공할수있도록HTTP를제공하는데집중하고HTTP가아닌전송은나중작업으로남겨두기로했다.

2018년3월이책의작업을시작할때QUIC버전1의최종명세를2018년11월에발표할계획이었다.이는나중에2019년7월로

연기되었다.

IETF-QUIC작업이진행되는동안Google팀은IETF버전의세부내용을받아들였고IETF버전이만들어질방향으로Google버전의프로토콜을천천히발전시켰다.Google은자사의브라우저와서비스에서QUIC의Google버전을계속해서사용하고있다.

개발중인대부분의새로운구현은IETF버전에집중하고Google버전과는호환되지않는다.

IETF

14

HTTP/2에서의경험

HTTP/2명세RFC7540는2015년5월발행되었는데이는QUIC이처음으로IETF에들어오기바로한달전이다.

HTTP/2에서유선으로HTTP를통한HTTP를변경할기반이마련되었고HTTP/2를만든워킹그룹이버전1에서버전2로가는것보다새로운HTTP버전으로가는걸돕는것이훨씬빠르다고생각하게되었다.(약16년)

HTTP/2를겪으면서사용자와소프트웨어스택은HTTP는더는텍스트기반프로토콜이라고만가정할수없다고생각하게되었다.

HTTP-over-QUIC은2018년11월에HTTP/3로개명되었다.

HTTP/2에서의경험

15

상태

QUIC워킹그룹은2016년후반부터프로토콜을제정하는일에열심히노력했고현재계획은2019년7월에완료하는것이다.

2018년11월까지도HTTP/3의아직대규모연동테스트를진행하지않았다.기존에두개의구현체가있는데둘다브라우저나인기있는공개서버소프트웨어와의테스트를하지않았다.

QUIC워킹그룹의위키페이지에나열된15개정도의서로다른QUIC구현체가있지만이들모두최신명세드래프트개정판과연동되지않는다.

QUIC을구현하는것은쉽지않고프로토콜은오늘날까지도계속진화하며변하고있다.

서버

지금까지Apache나nginx에서공개적으로QUIC을지원한다는발표는없다.

클라이언트

아직대형브라우저벤더중아무도QUIC이나HTTP/3의IETF버전을실행할수있는버전을제공하거나발표하지않았다.

수년간GoogleChrome은Google자체의QUIC버전의구현체를포함해서배포했지만이는IETFQUIC프로토콜과연동되지않고그HTTP구현체는HTTP/3와도다르다.

구현방해물

QUIC은뭔가새로운것을발명하지않고신뢰할수있는기존프로토콜을사용하고자TLS1.3을암호화와보안계층의기반으로

사용하기로했다.하지만이작업을하면서워킹그룹은QUIC에서TLS의사용을실제로간소화하기로발표했다.즉,프로토콜은

"TLS레코드"는사용하지않고"TLS메시지"만사용해야한다.

이것이무해한변화처럼들릴수있지만수많은QUIC스택구현자들에게는커다란걸림돌이되었다.TLS1.3을지원하는기존

TLS라이브러리는이기능을공개하거나QUIC이접근할수있는API가충분치않다.더큰조직에서온몇몇QUIC구현자들은자신들의TLS스택에도동시에작업을하고있지만모두가그런것은아니다.

예시로중량급지배적오픈소스인OpenSSL은이에대한API가전혀없고근래에제공할의사를밝힌적이없다.(2018년11월기준)

이는QUIC스택이다른TLS라이브러리(별도로수정한OpenSSL빌드)를사용하거나향후OpenSSL버전을수정할필요가있기

때문에결국배포상의걸림돌이다.

커널과CPU부하

Google과Facebook은QUIC의대규모배포가TLS에서HTTP/2로서비스할때보다같은트래픽기준으로거의2배의CPU가필요하다고얘기했다.

이는다음과같은이유때문이다.

본질적으로Linux의UDP부분은TCP스택만큼최적화되어있지않다.이는전통적으로지금처럼고속전송에사용해오지않았기때문이다.

하드웨어가TCP와TLS의부담을덜어주고있지만UDP에대해서그렇게하는경우는드물고기본적으로QUIC에대해서는

아예존재하지않는다.

시간이지나면성능및필요한CPU가개선될것이라고생각한다.

상태

16

상태

17

프로토콜기능

고수준에서QUIC프로토콜을보자.

아래그림은HTTP를전송할때HTTP/2네트워크스택을왼쪽에QUIC네트워크스택을오른쪽에보여준다.

프로토콜기능

18

UDP상의전송프로토콜

QUIC은UDP위에구현한전송프로토콜이다.우리가임의로네트워크트래픽을보면QUIC이UDP패킷으로나타나는것을볼것이다.

UDP에기반을둔QUIC은UDP포트번호를사용해서주어진IP주소의특정네트워크서비스를식별한다.

현재알려진모든QUIC구현체는사용자영역에있으므로커널영역의구현체보다훨씬빠른발전이가능하다.

동작할것인가?(DNS에사용되는)53포트가아닌포트의UDP트래픽을차단하는기업용및기타네트워크설정이있다.또다른설정은여러방법으로이러한데이터를제한하기때문에QUIC은TCP에기반을둔프로토콜보다성능이더좋지않다.이때문에,몇몇운영자가

해야할일에는끝이없다.

가까운미래에QUIC기반의모든전송은아마도그레이스풀하게(TCP기반의)다른대안프로토콜로전환될수있어야한다.Google엔지니어는측정한실패비율이낮은한자릿수라고얘기했다.

나아질것인가?QUIC이인터넷세상에가치를더할수있다고증명한다면사람들은사용하기를원할것이고그들의네트워크에서동작하길원할

것이다.그러면회사들은자신들의장애물을재고하기시작할것이다.수년간QUIC개발은진척이있었으며,인터넷에서QUIC연결을설정하고사용하는성공률이증가하고있다.

UDP

19

신뢰할수있는데이터전송

UDP가데이터전송의신뢰성을보장하지않지만,QUIC은UDP위에새로운계층을추가함으로써신뢰성을제공한다.추가된계층은TCP에존재하는패킷재전송,혼잡제어,속도조정및다른기능들을제공한다.

한엔드포인트로부터QUIC을통해전송된데이터는연결이유지되는한다른엔드포인트에서수신할수있다.

신뢰성

20

연결내의다중스트림

QUIC은SCTP,SSH,HTTP/2와마찬가지로물리연결내에서논리적스트림을나눌수있다.하나의연결로다수의병렬스트림으

로다른스트림에영향을주지않고데이터를동시에전송할수있다.

두엔드포인트사이에연결협상이이뤄지는방식은TCP연결이동작하는방식과비슷하다.QUIC연결은UDP포트와IP주소로

이루어져있지만일단연결을만들고나면"connectionID"로연결된다.

만들어진연결을통해양쪽에서스트림을만들어다른쪽으로데이터를보낼수있다.스트림은순서대로전달되고신뢰할수있지

만서로다른스트림은순서없이전달될수있다.

QUIC은연결과스트림모두에서흐름제어를제공한다.

더자세한내용은연결과스트림부분을참고하라.

스트림

21

순서에맞는전송

QUIC은스트림의순서있는전송을보장하지만스트림사이에서는(순서를)보장하지않는다.스트림은순서대로데이터를전송하

고유지하지만,각스트림은애플리케이션이보낸것과는다른순서대로목적지에도착할수있다!

스트림A와B가서버에서클라이언트로이동하는예를생각해보자.스트림A를먼저시작하고이어서스트림B를시작했다.QUIC에서잃어버린패킷은해당패킷이속한스트림에만영향을준다.스트림A는패킷을잃어버렸지만스트림B는잃어버리지않았다

면스트림A의잃어버린패킷을다시전송하는동안스트림B는계속해서전송하면서완료될수있다.이는HTTP/2에서는불가능

했다.

다음은하나의연결을통해두QUIC앤드포인트사이에보내진노란색스트림과파란색스트림의그림이다.이두스트림은독립적

이고다른순서로도착할것이지만각스트림은신뢰할수있게애플리케이션에순서대로전달된다.

순서에맞는전송

22

빠른핸드쉐이크

QUIC은0-RTT와1-RTT연결설정을둘다지원한다.즉,최선의상황에서는새로운연결을설정할때추가적인라운드트립이전혀필요치않는다.둘중가장빠른0-RTT핸드쉐이크는호스트에이미이전연결이구성되어있고해당연결의시크릿이캐시되어

있을때만동작한다.

초기데이터

QUIC은클라이언트가이미0-RTT핸드쉐이크에데이터를넣을수있다.이기능으로데이터를피어에최대한빨리전달할수있으

므로서버가더빨리응답하고데이터를돌려줄수있다.

빠른핸드쉐이크

23

TLS1.3QUIC에서사용하는전송보안은TLS1.3(RFC8446)이며암호화하지않은QUIC연결은절대로존재하지않는다.

이전버전의TLS와비교해서TLS1.3에몇몇장점이있지만QUIC이TLS1.3을사용한주된이유는핸드쉐이크에더적은라운드

트립이필요하도록바뀌었기때문이다.이는프로토콜지연을줄여준다.

QUIC의Google레거시버전은커스텀암호화를사용했다.

TLS1.3

24

전송계층과애플리케이션계층

IETFQUIC프로토콜은전송프로토콜로써다른애플리케이션프로토콜이그위에서사용할수있다.첫애플리케이션계층프로토

콜은HTTP/3(h3)다.

전송계층은연결과스트림을지원한다.

레거시Google버전QUIC은전송과HTTP가하나로합쳐져있어서(IETFQUIC)보다더특수한목적의send-http/2-frames-over-udp프로토콜이었다.

전송계층과애플리케이션계층

25

QUIC을통한HTTP/3HTTP/3라고부르는HTTP계층은HTTP형태의전송을한다.그중에는HPACK이라부르는HTTP/2헤더압축과비슷한QPACK을사용한HTTP헤더압축도있다.

HPACK알고리즘은순차적인스트림전달에의존하는데QUIC은스트림을순서없이전달할수있으므로HPACK을수정하지않고는HTTP/3에서재사용할수없다.HPACK을QUIC에맞게수정한것을QPACK이라볼수있다.

QUIC을통한HTTP/3

26

QUIC을통한HTTP가아닌프로토콜

QUIC을통해HTTP가아닌프로토콜을보내는작업은QUIC버전1출시이후로연기되었다.

QUIC을통한HTTP가아닌프로토콜

27

QUIC의동작방식

이번장에서는QUIC전송프로토콜의기본적인구성요소가어떻게동작하는지를설명한다.QUIC스택을직접구현하고자한다면

이책의설명을통해전반적인내용을이해할수는있지만,세부내용은IETF의인터넷드래프트와RFC를참고하기바란다.

1.연결을설정한다.2.여기에는TLS보안이포함되어있다.3.스트림을사용한다.

QUIC의동작방식

28

연결

QUIC연결은두QUIC엔드포인트사이의대화이다.QUIC의연결설정은버전협상,암호화,전송핸드쉐이크로구성되어있으므

로연결설정의지연시간을줄여준다.

이러한연결을통해실제데이터를보내려면하나이상의스트림을만들어서사용해야한다.

연결ID각연결은연결식별자나연결ID를가지므로이를통해연결을식별한다.엔드포인트가자유롭게연결ID를선택한다.각엔드포인

트는엔드포인트의피어가사용할연결ID를선택한다.

이연결ID의주요기능은하위프로토콜계층(UDP,IP혹은그아래계층)에서주소가변경되더라도QUIC연결의패킷이잘못된

엔드포인트로전달되지않도록보장하는것이다.

연결ID를이용하면TCP에서는불가능했던방법으로IP주소와네트워크인터페이스사이에서연결이마이그레이션할수있다.예를들면사용자가자신의기기를들고wifi가지원되는곳으로이동했을때다운로드를진행하면서셀룰러네트워크연결에서더빠른wifi연결로변경되는것이이마이그레이션을통해가능하다.마찬가지로wifi를이용할수없게되었을때셀룰러연결을통해

다운로드를진행할수있다.

포트번호

QUIC이UDP위에만들어졌으므로들어오는연결을구분하기위해16비트포트번호필드를사용한다.

버전협상

클라이언트는QUIC연결요청에서어떤QUIC프로토콜버전으로통신하고싶은지서버에게알려주고서버는클라이언트가선택

할수있도록지원하는버전목록을응답한다.

연결

29

TLS을사용하는연결

초기패킷이연결을설정하자마자초기화하는쪽에서보안계층핸드쉐이크의설정을시작하는암호화프레임을보낸다.보안계층

은TLS1.3보안을사용한다.

QUIC연결에서에는반드시TLS를사용해야한다.QUIC프로토콜은프로토콜고착화를방지하기위해미들박스가조작하기어렵

게설계되었다.

TLS을사용하는연결

30

스트림

QUIC스트림은경량이면서순서가있는바이트스트림추상화를제공한다.

QUIC에는두가지기본스트림타입이있다.

단방향스트림은한쪽으로데이터를전달한다.즉,스트림을시작한쪽에서피어로전달된다.

양방향스트림은양쪽으로데이터를보낼수있다.

두엔드포인트가두타입의스트림을모두만들수있고스트림은다른스트림과상호배치된데이터를동시에보낼수있고취소할

수도있다.

QUIC연결을통해데이터를보낼때하나이상의스트림을사용한다.

흐름제어

스트림은개별적으로흐름제어가되므로엔드포인트가메모리사용을제한할수있고백프레셔(backpressure)를적용할수도있다.스트림의생성도흐름제어가되고각피어는일정시간동안받고자하는최대스트림ID를정의할수있다.

스트림식별자

스트림ID라고부르는부호없는62비트정수로스트림을식별한다.스트림ID의최하위2비트를스트림(단방향이나양방향이나)의타입과스트림을시작한쪽을식별하는데사용한다.

스트림ID의최하위비트(0x1)는누가스트림을시작했는지를식별한다.클라이언트는짝수의스트림(최하위비트가0으로설정된

스트림)을초기화하고서버는홀수의스트림(최하위비트가1으로설정된스트림)을초기화한다.

스트림ID의두번째하위비트(0x2)는단방향스트림과양방향스트림을구분한다.단방향스트림을항상이비트를1로설정하고

양방향스트림은이비트를0으로설정한다.

스트림동시성

QUIC에서는임의의스트림이다수동시에동작할수있다.엔드포인드는최대스트림ID를제한해서동시에받아들이는활성스트

림의수를제한한다.

엔드포인트마다최대스트림ID를설정하고설정을받는피어에만적용된다.

데이터보내기와받기

엔드포인트는스트림을사용해서데이터를보내고받고이는스트림의원래목적이다.스트림은순서가맞는바이트스트림추상화

다.하지만별도의스트림은원래순서대로전달되지않는다.

스트림의우선순위

스트림에할당된리소스의우선순위가제대로설정되면스트림멀티플렉싱은애플리케이션성능에상당한영향을준다.HTTP/2같은멀티플렉싱을지원하는다른프로토콜의경험에서상당히긍적적인성능효과를보여주는효율적인우선순위전략을볼수있다.

QUIC자체에서우선순위를결정하는정보를교환하는프레임을제공하지는않는다.대신QUIC을사용하는애플리케이션에서우선순위정보를받는데의존한다.QUIC을사용하는프로토콜은애플리케이션의의미에적합한우선순위스키마를정의할수있다.

QUIC을통해HTTP/3을사용할때우선순위는HTTP계층에서동작한다.

스트림

31

스트림

32

0-RTT새로운연결을설정하는데필요한시간을줄이려고이전에서버에연결했던클라이언트는해당연결의특정파라미터를캐시한뒤이어서서버와0-RTT연결을설정할수있다.이로인해서클라이언트는핸드쉐이크가완료되기를기다리지않고바로데이터를보낼수있다.

0-RTT

33

스핀비트(SpinBit)QUIC워킹그룹에서수백개의이메일을주고받고수십시간의토론을걸친가장긴설계토론중하나가단일비트즉,스핀비트

(SpinBit)에관한것이다.

이스핀비트를지지하는사람들은두QUIC엔드포인트사이에있는운영자나사람들이지연시간을측정할필요가있다고주장한

다.

이기능을반대하는사람들은잠재적인정보유출을좋아하지않았다.

비트회전시키기

클라이언트와서버두엔드포인트는각QUIC연결에대해0또는1의스핀값을유지하면서해당연결에적절한값으로스핀비트

를설정해서패킷을보낸다.

양측은한라운드트립동안같은값으로설정된스핀비트를가진패킷을보내고이후이값을토글한다.이로인해비트필드에0과1의파동이나타나고관찰자가이를모니터링할수있다.

발송자가애플리케이션도아니고제약된흐름제어도아닌경우에만이측정을할수있고네트워크에서패킷의순서가재정리될때도데이터에잡음이낄수있다.

스핀비트

34

사용자영역

사용자영역에서전송프로토콜을구현하면클라이언트와서버가새로운버전을배포하기위해운영체제커널을업데이트할필요가

없어서비교적쉽게프로토콜을발전시킬수있으므로프로토콜을빠르게반복할수있다.

미래에운영체제커널에서구현되거나제공하지않도록막는것은QUIC에아무것도없으므로누군가좋은방법을찾아야한다.

많은구현체

사용자영역에서새로운전송프로토콜을구현하는한가지명백한효과는다수의독립적인구현체를볼수있다는것이다.

예견할수있는미래에다른애플리케이션은다른HTTP/3와QUIC구현체를포함할(또는계층위에서)것이다.

사용자영역

35

APITCP와TCP를사용하는프로그램의성공요소중하나는표준화된소켓API이다.소켓API는기능이잘정의되어있고이API를사용하면TCP가똑같이동작하므로다수의다른운영체제사이에서프로그램을이동시킬수있다.

QUIC은그렇지않다.QUIC에는표준API가없다.

QUIC에서는기존라이브러리구현체중하나를선택하고그API를따라야한다.이는애플리케이션을어떤부분에서하나의라이

브러리에"락인(lockedin)"시킨다.다른라이브러리로바꾼다는것은다른API를뜻하므로많은작업이필요할것이다.

또한QUIC이보통사용자영역에서구현되므로소켓API를쉽게확장할수없고기존의TCP나UDP기능과비슷하게보일수없다.QUIC을사용한다는것은소켓API와는다른API를사용한다는것을의미한다.

API

36

HTTP/3이전에얘기했듯이QUIC을통해전송하는첫주요프로토콜은HTTP다.

완전히새로운방법으로유선을통해HTTP를전송하려고HTTP/2를도입한것처럼HTTP/3는다시한번네트워크를통해HTTP를전송하는새로운방법을도입한다.

HTTP는여전히이전과같은개념과패러다임을유지한다.헤더와보디가있고요청과응답이있고동사,쿠키,캐시가있다.통신

상대측으로비트를보내는방법이HTTP/3에서주된변경점이다.

QUIC을통해HTTP를보내기위해변경이필요했고그결과물을HTTP/3라고부른다.QUIC이제공하는특성이TCP의특성과는

다르므로변경이필요했다.변경사항은다음과같다.

QUIC에서전송자체에서스트림을제공하지만HTTP/2에서는HTTP계층에서스트림이제공된다.

스트림이서로독립적이므로HTTP/2에서사용된헤더압축프로토콜을headofline블로킹문제를발생시키지않으면서사용

할수없다.

QUIC스트림은HTTP/2스트림과는다소다르다.HTTP/3부분에서자세히설명할것이다.

HTTP/3

37

HTTPS://URLHTTP/3는HTTPS://URL을사용해서실행될것이다.세상은이러한URL로가득차있고새로운프로토콜에또다른URL스킴을

도입하는것은실용적이지도않고완전히불합리하다고여겨졌다.HTTP/2에새로운스킴이필요없었듯이HTTP/3에도필요없다.

하지만HTTP/2가유선으로HTTP를전송하는완전히새로운방법이지만HTTP/1이그랬듯이여전히TLS와TCP에기반을두고

있었기에HTTP/3상황에서복잡성을추가하게되었다.HTTP/3가QUIC을통해수행된다는점은몇가지중요한관점에서변경이

발생했다.

레거시,평문,HTTP://URL은지금그대로유지될것이지만더안전한전송을하는미래로나아갈수록점점덜사용될것이다.이러한URL에대한요청은HTTP/3를사용하도록업그레이드되지않을것이다.현실에서이러한것들이HTTP/2로업그레이드하는

경우는거의없지만다른이유때문이다.

초기연결

이전에방문한적이없는HTTPS://URL에대한새로운첫연결은아마도TCP를통해수행될것이다.(추가로QUIC을통한병렬

연결시도가있을수있다.)호스트가QUIC을지원하지않는레거시서버일수도있고중간에있는미들박스가QUIC연결이성공

적으로이뤄지지않도록하는장애물일수도있다.

최신클라이언트와서버는아마도첫핸드쉐이크에서HTTP/2를협상할것이다.연결이설정되고클라이언트의HTTP요청에서버

가응답할때서버는HTTP/3의지원과선호도에관해클라이언트에게알려줄수있다.

HTTPS://URL

38

Alt-svc대체서비스헤더(Alt-svc:)와이에대응되는ALT-SVCHTTP/2프레임이QUIC이나HTTP/3를위해특별히만들어진것은아니다.서버가클라이언트에게"봐라.이포트에서이프로토콜로이호스트에서같은서비스를운영하고있다."라고말할수있도록이미

설계되고만들어진메커니즘의일부이다.자세한내용은RFC7838를참고해라.

이러한Alt-svc응답을받은클라이언트는(이를지원하고원하는경우)주어진다른호스트에지정된프로토콜로백그라운드에서

병렬연결을하도록권고받는다.성공적으로전환된다면초기연결대신새로운연결을통해서해당작업을수행한다.

초기연결이HTTP/2나HTTP/1을사용하더라도서버는다시연결해서HTTP/3를시도할수있다고클라이언트에게알려줄수있다.이는같은호스트일수도있고요청한내용을제공하는방법을아는다른호스트일수도있다.이러한Alt-svc응답에서제공된

정보에는만료타이머가있어서,클라이언트가일정시간동안제안받은대체프로토콜로직접대체호스트에이어진연결과요청을

할수있다.

예시

HTTP서버는응답에Alt-Svc:헤더를다음과같이포함한다.

Alt-Svc:h3=":50781"

이는해당응답을얻는데사용한것과같은호스트이름의50781UDP포트에서HTTP/3를사용할수있음을나타낸다.

그다음클라이언트는해당목적지에QUIC연결을설정하려고시도하고연결이성공하면초기HTTP버전대신이러한출처와계속해서통신한다.

Alt-svc로부트스트랩하기

39

QUIC스트림과HTTP/3HTTP/2가TCP를기반으로전체적인스트림과멀티플렉싱개념을설계해야했던반면HTTP/3는QUIC을위해만들어졌으므로

QUIC스트림이가진이점을최대한활용한다.

HTTP/3를통해수행되는HTTP요청은특정스트림세트를사용한다.

HTTP/3프레임

HTTP/3는QUIC스트림을설정하고반대쪽끝으로프레임세트를보내는것을의미한다.HTTP/3에는몇가지알려진프레임이고정되어있다.이중가장중요한것은다음과같다.

HEADERS,압축된HTTP헤더를보내라.DATA,바이너리데이터콘텐츠를보내라.GOAWAY,이연결을종료해라.

HTTP요청

클라이언트는클라이언트가초기화한양방향QUIC스트림으로HTTP요청을보낸다.

단일HEADERS프레임으로구성된요청은하나또는두개의다른프레임,즉일련의DATA프레임과뒤이어오는것들을위한최종HEADERS프레임이따라올수있다.

요청을보낸후클라이언트는전송용스트림을닫는다.

HTTP응답

서버는양방향스트림으로해당HTTP응답을돌려보낸다.여기에는HEADERS프레임과일련의DATA프레임이있고뒤따라오는

HEADERS프레임이있을수있다.

QPACK헤더

HEADERS프레임은QPACK알고리즘으로압축된HTTP헤더를담고있다.QPACK은HPACK이라고부르는HTTP/2의압축과

형식면에서비슷하지만,순서가맞지않게전송된스트림에서동작하도록수정되었다.

QPACK자체는두엔드포인트사이에서추가적인두개의단방향QUIC스트림을사용한다.이스트림은양방향으로동적테이블

정보를전달하는데사용된다.

QUIC스트림과HTTP/3

40

HTTP/3우선순위정하기

HTTP/3스트림프레임중에는PRIORITY라는프레임이있다.이프레임은HTTP/2에서동작한방식과비슷하게스트림의우선순

위와의존성을설정하는데사용한다.

이프레임은특정스트림이다른스트림에의존하도록설정할수있고해당스트림에"가중치"를설정할수있다.

종속된스트림은의존하는스트림이모두닫혔을때만리소스가할당받아야하고아니면진행될수없다.

스트림가중치는1부터256사이의값을가지며같은부모를가진스트림은반드시가중치에따라리소스를할당받아야한다.

우선순위정하기

41

HTTP/3서버푸시

HTTP/3서버푸시는HTTP/2에서설명된내용(RFC7540)과비슷하지만다른메커니즘을사용한다.

서버푸시는클라이언트가보낸적이없는요청에대한효율적인응답이다!

서버푸시는클라이언트쪽에서서버푸시에동의했을때만발생할수있다.HTTP/3에서는클라이언트가최대푸시스트림의ID가무엇인지서버에게알려주어클라이언트가얼마나많은푸시를받을지를제한한다.이제한을초과하면연결오류가발생할것이다.

클라이언트가요청하지는않았지만어쨌든서버가받아야하는추가리소스가있다고판단하면,(요청스트림을통해)서버가요청

에푸시로응답한것처럼보이는PUSH_PROMISE프레임을보낼수있다.그다음실제응답은새로운스트림을통해보낸다.

클라이언트가미리푸시를받을수있다고말했더라도,클라이언트가적합하다고판단하면푸시된개별스트림을언제든취소할수있다.그리고서버에CANCEL_PUSH프레임을보낸다.

문제점

이기능은HTTP/2개발에서처음논의된이후HTTP/2프로토콜이나오고인터넷에배포된뒤,이기능을유용하게만들기위해셀수없이다양한방법으로논의되고,싫어하게했으며,두들겨맞았다.

라운드트립의절반을줄일수있지만,여전히대역폭을사용하기때문에푸시는결코"공짜"가아니다.실제로리소스가푸시되어야

하는지아닌지를서버측에서확실하게알기가어렵거나불가능하다.

서버푸시

42

HTTP/3과HTTP/2의비교

HTTP/3는자체적으로스트림을다루는전송프로토콜인QUIC을위해설계되었다.

HTTP/2는TCP를위해설계되었으므로HTTP계층에서스트림을다룬다.

유사점

이두프로토콜을사실상같은기능을제공한다.

두프로토콜은스트림을제공한다.

두프로토콜은서버푸시를지원한다

두프로토콜은헤더압축을제공한다.QPACK과HPACK은설계상비슷하다.

두프로토콜은스트림을이용해서하나의연결을통해멀티플랙싱을제공한다.

두프로토콜은스트림에우선순위를정한다.

차이점

세부내용에차이점이있는데주로HTTP/3의QUIC사용때문에생긴다.

QUIC의0-RTT핸드쉐이크덕에HTTP/3에서는이른데이터지원이더낫게잘동작한다.TCPFastOpen과TLS는더적은

데이터를보내지만,종종문제점에직면한다.

HTTP/3는QUIC덕에TCP+TLS보다훨씬더빠른핸드쉐이크를제공한다.

HTTP/3에는안전하지않거나암호화되지않은버전이없다.인터넷에서드물기는하지만HTTP/2는HTTPS없이구현하고

사용할수있다.

HTTP/2가ALPN확장을이용하여즉시TLS핸드쉐이크협상을완료할수있는반면HTTP/3는QUIC을사용하므로클라이

언트에이사실을알리기위해Alt-Svc:헤더응답이먼저있어야한다.

HTTP/3과HTTP/2의비교

43

일반적인비판

UDP는절대동작하지않을것이다

(DNS에서사용하는)53포트가아닌UDP트래픽이최근에는주로공격에사용되기때문에많은기업,운영자,조직에서차단하거

나속도를제한하고있다.특히기존의UDP프로토콜과잘알려진서버구현체중일부는증폭공격에대한취약점이있으므로공격

자가무고한대상피해자에게대량의트래픽을보낼수있다.

QUIC에서는초기패킷이최소1200바이트여야한다는조건과서버가클라이언트로부터응답패킷을받지않으면요청크기의3배이상은절대보내면안된다는프로토콜의제약사항으로증폭공격을완화하는기능이들어있다.

커널에서UDP는느리다

이는적어도2018년현재까지사실로보인다.물론앞으로어떻게발전할것인지,수년간UDP의전송성능이개발자의관심사가

아니었다는결과가간단히어느정도인지말할수없다.

대부분클라이언트는이"느림"을결코알아채지못했다.

QUIC은CPU를너무많이사용한다

위에서얘기한"UDP는느리다"와비슷하게이또한부분적으로는TCP와TLS가세계적으로더오랫동안성숙하고개선되고하드

웨어의지원을받았기때문이다.

시간이지나면개선되리라기대할근거는있다.문제는추가적인CPU사용이배포자에게얼마나영향을끼치는가이다.

그냥구글이다

전혀그렇지않다.Google이대규모인터넷환경에서증명을마친후IETF에초기명세를가져왔다.UDP를통한이방식의프로토

콜배포는실제로잘동작한다.

그이후많은회사와조직의사람들이벤더중립적조직인IETF에서독립적으로표준전송프로토콜을작업했다.물론이작업에

Google직원도참여했지만,인터넷전송프로토콜의상태를향상하려는Mozilla,Fastly,Cloudflare,Akamai,Microsoft,Facebook,Apple등많은회사의직원들도참여했다.

개선된부분이너무적다

이것은정말비판이아니라의견일뿐이다.어쩌면HTTP/2가나온지얼마안되었기때문에개선된부분이너무적을수도있다.

HTTP/3는패킷손실이많은네트워크에서훨씬더잘동작할것이고,더빠른핸드쉐이크를제공하므로체감지연시간과실제지연

시간을모두개선할것이다.하지만,사람들이자신의서버와서비스에HTTP/3지원을추가하고싶을정도로장점이충분할까?시간과미래의성능측정으로분명히알수있을것이다!

일반적인비판

44

명세

다음은QUIC과HTTP/3의여러부분및구성요소의공식드래프트최신버전이다.

불변

QUIC의버전독립적인프로퍼티

전송

QUIC:UDP에기반을둔멀티플랙싱보안전송

복구

QUIC손실탐지와혼잡제어

TLSTransportLayerSecurity(TLS)를사용해서QUIC안전하게하기

HTTPQUIC을통한HypertextTransferProtocol(HTTP)

QPACKQPACK:QUIC을통한HTTP의헤더압축

명세

45

QUICv2핵심QUIC프로토콜에가장집중해서제때출시할수있도록핵심프로토콜의일부로원래계획되어있던몇가지기능을연기했고

QUIC2나그뒤후속QUIC버전에포함할예정이다.

하지만이문서의작성자가잘못된예측을할수도있으므로버전2에어떤기능이들어가고어떤기능이안들어갈지정확하게얘기할수는없다.그래도버전1에서명시적으로제거되어"나중에작업"하기로해서버전2에포함될가능성이있는기능은얘기할

수있다.

순방향오류정정(ForwardErrorCorrection)순방향오류정정(FEC)은데이터전송에서오류제어를하는방법으로송신기는중복데이터를전송하고받는쪽에서는식별할수있는오류가없는데이터의부분만을인식한다.

Google이원래의QUIC작업에서이를실험했지만,실험결과가좋지않아서후에다시제거되었다.이기능은QUICv2의토론주제이지만너무큰불이익이없고유용한기능이라는것을실제로누군가증명해야할것이다.

다중경로

다중경로는리소스사용을최대화하고중복을늘리기위해전송자체가다중네트워크경로를사용하는것을의미한다.

SCTP지지자는SCTP에는이미다중경로기능이있고오늘날의TCP도그렇다고말할것이다.

신뢰할수없는데이터

"신뢰할수없는"스트림을선택사항으로제공해서UDP방식의애플리케이션도QUIC이대체할수있게하는것이논의되었다.

HTTP가아닌프로토콜도입

QUIC을통한DNS는QUICv1과HTTP/3가출시되면관심을끌수있는HTTP가아닌프로토콜로초기에언급된것중하나이다.하지만이새로운전송을세상에내놓으면거기서끝이라고상상할수없다.

QUICv2

46