WWDC 21 - Accelerate networking with HTTP/3 and QUIC

---

• 세션보면서 정리한 내용입니다. 해석이 잘못된 경우가 있을수있으니 발견하시면 댓글로 남겨주시면 감사하겠습니다🙏🏻

---

 

 

요약

• 서버가 HTTP/3를 지원만한다면 iOS15, macOS Monterey 에서는 URLSession을 이용만하면 자동적으로 HTTP/3를 이용할수있다! 
• HTTP/3 는 연결성립시간을 단축시키며, 독립적인스트림으로, 패킷손실에대해 유연핳게 대응할수있다. 
• QUIC 기존 TCP개념을 기반으로하며, TCP 1.3 security를 사용한다.
• 서버가 HTTP/3를 지원하는지는 Xcode13에서 Instrument  - Networking 을통해 알수있다. 
• Network.framework에서 QUIC 지원을한다. 

 

 

 

 

---

 

 

iOS 15에서부터는 HTTP3, QUIC지원을한다. 

 

 

QUIC은 HTTP3가 사용하는, 새로운 transport protocol이다. 

 

어떻게 urlsession에서 HTTP3를 사용할수있는지,

서버는 어떻게 HTTP3를 지원하는지 알아보자.

 

QUIC을 사용하는 API를 알아보자.

 

 

 

리소스를가져오고싶다.

연결을 셋하고,

요청을보내고,

서버가처리하는것을기다리고,

서버가 응답한다.

 

만약 이첫번째요청이완료되기전에 다른리소스를요청하면 또 똑같이 반복한다.

세번쨰요청도마찬가지다.

 

즉, 아래와같이 이루어지는데, 연결을 셋업하는데 시간이많이소요된다.

 

HTTP1.1

 

그러므로, 연결을재활용하면어떨까? 

아래와같이 연결은 한번셋한채로 요청이가능하다.

• 하지만 단점은 요청은 이전응답이 완료된이후에만 보낼수있다. 
• 이것이 head-of-line blocking 이다.
  • 그래서, 이를 극복하기위해 많은 병렬연결을 사용했다.
    • 이는 서버와클라이언트에게 비효율적인네트워킹을 유발한다는 단점이있다.

 

 

HTTP2

head-of-line-blocking을 극복했다. 

• 한연결에 멀티스트림을 이용했다.
• 기존의 낭비되는시간들을 줄임으로써, 하나의연결에 효율성을 더 증가시켰다. 
• 아래와같이, 이후의요청의 응답이 더 먼저올수도있게됐다.

 

HTTP3

연결을 셋업하는과정이 훨씬빨라졌다.

이뿐만아니라, 사용되는 스트림들이 모두 독립적이다.

• HTTP/2는 하나의 TCP연결에 각 스트림들이 공유되어지는 반면!

 

 

• 네트워크에상에서는 패킷이 손실된다. 특히나, 무선네트워크에서는 빈번히발생한다.
• 이러한 경우에, HTTP/2에서는 패킷손실이 많은 스트림에게 영향을 미칠수있다.  하나의TCP연결에 스트림들이 모두 공유되어지기때문이다. 
• HTTP/3는 각 스트림들이 독립적이여서 문제가있는 스트림만 손실되어진다.  그러므로 다른 스트림에속한 데이터는 전달되어질수있다.

 

즉, HTTP/3는 연결을 더 빠르게해주며, 패킷손실에대해 더 유연하게 대처할수있다.

이러한 개선점이 가능한이유는, QUIC transport protocol에 기반한다.

 

 

 

 

---

QUIC - 퀵 

Internet Engineering Task Force(국제인터넷표준화기구)에 의해 표준화된 새로운 믿을수있는 transport protocol이다. 

TCP의 같은개념을 기반으로하지만 end-to-end encryption, multiplexced streams, authentication을 제공한다.

 

QUIC의 security는 TLS 1.3프로토콜기반에 만들어진다. 

• 👍TLS1.3에 기반하여, secure handshake를 수행한다. 그러므로, TCP의 3-way-handshake를 요구하지않는다.
  • 그러므로, handshake시간을 single round trip ( 왓다갓다? ) 로 줄일수있다. 
  • 👍즉, 연결보장하는데 시간이 단축된다!

👍mutiple stream은 QUIC의 핵심개념이며, 이것을통해, head-of-line blocking을 겪지않게된다.

 

 

👍손실복구에 더 낫다는 장점이있다.

A QUIC endpoint is able to communicate more complex information about packets it has received to the other endpoint and is not encumbered by TCP's limits, so QUIC connections experience improved loss recovery. 

 

👍또한 connection migration을 지원하여,  session을 다시만드는것없이, connection이 매끄럽게 다른 네트워크인터페이스로 옮겨질수있다.  

• 예를들어, cellular에서, wi-fi로. 

 

 

 

 

어떻게 앱애서 HTTP/3를 사용할수있을까?

 

iOS 15, macOS Monterey는 HTTP3를 default로 지원하기때문에, 앱에서 URLSession을 사용한다면 앱을바꿀필요가없다!!!

• 그러므로, 서버만 HTTP/3를 지원만한다면 가능하다!

 

HTTP/3 Draft 29와, 곧있을 HTTP/3 RFC도 지원한다!

 

 

 

 

 

 

 

---

 

그럼 어떻게 앱이 HTTP/3를 사용하고있는지 어떻게알수있을까? 

 

 

 

xcode13부터는, 새로운 instrument를 소개하는데, networking profiling template 에서, HTTP traffic을 검사할수있다.

URLSession을 이용하여, 그래서이를통해서, 앱이 HTTP/3를사용한는지, 이전버전을사용하는지알수있다. 

• 앱을 런칭하고, 시작하고, 

 

 

record를 누르고,

 

agree한다음, 시작된다.

 

앱이시작되고, 통신한다.

 

 

 

그후,  Instrument는 앱,도메인당 모든 HTTP처리를 보여준다. 

 

그리고 원하는 때에 Pause를 누른다.

 

 

 

OPtion-click으로 열고, domain을 선택한다.

 

 

List - HTTP Transactions으로 바꿔준다.

 

첫번째요청을 오른쪽으로보다보면, HTTP Version을 보여준다.

• 오잉? HTTP/2를사용하네? 왜지? 

 

 

오른쪽을보면 더 자세하게볼수있는데, 응답헤더를보면, Alt-Svc 헤더가있다. 

• h3=“:443”, 
• 이를통해, 서버는 HTTP/3지원을 advertise하기위해 HTTP Alternative Services 를 사용하고있다라고알수있다.

 

 

 

 

 

Alt-Svc HTTP 헤더에의해 HTTP/3를 알리고있따. 

• 이러한방식은 HTTP 서버가 HTTP/3지원을 알리는데 흔한방식이다. 
• 이정보는 나중의연결을위해 기억되어진다. 
• 이러한 방식을 service discovery이다. 

 

🔥URLSession won't use HTTP/3 unless it was advertised. 

In this example, HTTP/3 was advertised through the Alt-Svc HTTP header. 

It's common for HTTP servers to advertise support for HTTP/3, using this header. This information is remembered for future connections, and we call this "service discovery." Now let's record the app again.

 

다시 record하고 확인해보니, 오이?! HTTP3 로 됌!!

• 서버가 HTTP/3지원한다는것을 기억하고있기때문에, 이제는 HTTP/3를 사용한느 것이다. 
• HTTP/3 service discovery is transparent to your app.  

 

 

 

👍🔥Discovery of HTTP/3 server support happens in two ways. The recommended approach is to configure your DNS server to advertise support for HTTP/3 through the HTTPS resource record. Simply configure the application layer protocol to advertise HTTP/3 using the h3 string. You should also configure your server to add a new header that advertises HTTP/3 using Alternative Services. Your server should send a Alt-Svc header that advertises HTTP/3. This includes the port number and the max-age of the service, in seconds. The advantage of the DNS record is that since the information is in DNS, an HTTP/3 connection can be established the very first time your app tries to contact to your server. When you know that your server supports HTTP/3, and you would like to speed up the discovery process, you can use the assumesHTTP3Capable property. This allows the HTTP stack to assume that you have an HTTP/3 server but does not guarantee that HTTP/3 will be used. Networks may still block HTTP/3, or your server may not actually support HTTP/3. In that case, we'll fall back to HTTP/2.

 

 

 

 

HTTP는 클라이언트가 리소스에대해 우선순위를 지정할수있도록 허락해준다.  

이를통해 서버는 우선순위가더 높은 리소스를 더 빠르게 보내줄수있또록해준다.

• 예를들어, 웹브라우저같은경우, 웹페이지렌더링을 먼저우선순위처리한다면 유저경험이 더 증가되어질수있게된다.
• 이러한우선순위는 HTTP/2에서부터 지원한다.
  • 하지만, 복잡성때문에 종종 무시되어지는데, 이러한이유로 기존 우선순위모델은 HTTP/3에서 삭제됐다.
    • 보다 간단하게, 새로운 우선순위모델이 HTTP/3에서등장했고, HTTP 헤더에 의존한다. 
    • 0부터 7까지 값을가진다. 그리고 incremental delivery 를 할것인지 정할수있다.  ( i ) 
      • 그러므로, 우선순위는 URLSession은 기존처럼 priority를 지정하면된다.  ( default는 3 ) 
    • URLSesssion에서 incremental delivery 를 가능하게하고싶다면 prefersIncrementalDelivery 프로퍼티를 이용하면된다
      • URLsession은 API에따라 incremental delivery를 추론한다?  - async 메소드인경우
    • 만약, 다른리소스들이 다운로드되기전에 특정리소스를 처리할수없는경우에는 preferIncrementalDelivery를 false해야한다.

• dynamic reprioritization을 지원한다.  
  • 즉, 요청이 보내진이후에 변할수있는? 처음에는 낮은우선순위로요청했다가, 나중에 우선순위가 높아질수있다.

 

 

 

 

 

 

 

 

 

 

---

QUIC기반으로 커스텀네크워킹하자.

( 여기서부터는 잘 모르겠어서 캡처로만 남겼습니다 ) 

 

 

QUIC에서 스트림은 endpoint에의해 생성되어질수있다.

• 다른스트림에 끼어져서, 동시적으로 데이터를 보낼수있다.
• TCP에의해 만들어진 전통적인 스트림과 비슷한 상태를 갖고있다.

TLS 1.3 security에 만들어졌고, 네트워크조건변화에 유연하게 반응할수있다.

 

아래일때는 QUIC을 사용해야한다! 

 

 

iOS15, macOS Monterey( 몬퉤레이) 에서 NWPorotcolQUIC을 지원한다!

 

 

작년에 여러개커넥션있는 상황에 대응하기위한  ConnectionGroup을 소개했는데, 

QUIC또한, NWMultiplexGroup를통해 지원한다.