[📌] 러닝 HTTP/2

책 정보

• Learning HTTP/2
• O'REILLY
• 스티븐 루딘, 하비에르 가르사 지음, 강재준 옮김
• 한빛미디어

독서기간

• 1차: 2020-05-16-토 ~ 2020-07-02-목

목차

Chapter 1 HTTP의 진화
Chapter 2. HTTP/2 맛보기
Chapter 3. 웹을 파헤치는 이유와 방법
Chapter 4. HTTP/2로의 전환
Chapter 5. HTTP/2 프로토콜
Chapter 6. HTTP/2 성능
Chapter 7. HTTP/2 구현
Chapter 8. HTTP/2 디버깅하기
Chapter 9. 다음은 무엇인가

Chapter 1. HTTP의 진화

Chapter 2. HTTP/2 맛보기

Chapter 3. 웹을 파헤치는 이유와 방법

"우리가 가고 있는 곳 (즉, HTTP/2)을 이해하려면,
우리가 현재 있는 곳,
우리가 직면한 문제,
우리가 현재 그 문제를 다루고 잇는 방법을
먼저 이해하는 것이 중요하다."

3.1 오늘날의 성능 문제

웹 페이지를 가져와 렌더링하는 데 필요한 여러 단계뿐 아니라
단계마다 내재된 문제를 이해하는 것은
웹사이트와 상호 작용하는 사용자를 불편하지 않게 하는 데 가장 중요한 부분이다.

3.1.1 웹페이지 요청의 구조

개체를 반입(fetching)하는 로직과 페이지를 파싱(parsing)/렌더링하는 로직으로 나누어 생각하는 웹피이지의 요청 절차

<개체 요청/반입 흐름>
1. 가져올 URL을 대기열에 넣는다
2. URL 내의 호스트이름의 IP주소를 조회한다
3. 호스트로 TCP 연결을 연다
4. 요청에 HTTPS라면, TLS 핸드셰이크를 완료한다
5. 기준 페이지 URL에 대한 요청을 전송한다

<개체 응답/페이지 렌더링 흐름>
6. 응답을 수신한다
7. 기준 HTML이라면, HTML을 파싱하여 우선순위에 따라 페이지의 개체들을 반입을 시작한다
8. 페이지의 필수 개체를 수신했다면, 화면 렌더링을 시작한다
9. 추가 개체를 수신하면, 끝날 때까지 파싱과 렌더링을 계속한다

어느 단계든 최적화하거나, 제거하는 일이 "웹 성능 튜닝"이라는 예술에 핵심점인 부분이다.

3.1.2 중요 성능

1) 네트워크 수준의 지표

• 지연 시간
• 대역폭
• DNS lookup
• 연결 시간
• TLS 협상 시간

2) 서버 자체의 내용이나 성능에 좀 더 의존적인 지표

• TTFB(Time to First Byte)
• 콘텐츠 다운로드 시간 (TTLB, Time to Last Byte)
• 렌더링 시작 시간
• 문서 오나성 시간(=페이지 로딩 시간)

3) 인터넷 성능상의 병목을 유발하는 요소들

• 바이트 수의 증가
• 개체 수의 증가
• 복잡도의 증가
• 호스트 수의 증가
• TCP 소켓 수의 증가

3.1.3 HTTP/1의 문제점

1) HOL 블로킹 (Head of Line blocking)
HOL 블로킹: 여러 요청이나 응답 중 어디엔가 문제가 발생하면 그 요청/응답을 뒤다르는 다른 모든 것들은 막혀버림. 이런 현상을 HOL 블로킹이라고 함
요즘 브라우저는 특정 호스트에 최대 6개의 연결을 열고, 각 연결로 요청을 전송해 어느 정도 병렬처리가 가능함

2) TCP의 비효율적 사용

• congestion window
• slow start

3) 비대한 메시지 헤더

4) 제한적인 우선순위
요청들의 우선순위를 지정하기 위한 옵션은 매우 제한적

5) 서드파티 개체

• 서드파티 개체: 현대 웹 페이지에서 요청되는 것 중에 웹 서버의 제어 범위에서 완전히 벗어나 있는 것들

3.2 웹 성능 기법

• 웹 사이트의 성능은 "전환율, 사용자 참여율, 브랜드 인지도"측면에서 중요!
• 2010년 구글 검색엔제에서 url순위를 산출하는 주요 파라미터에 성능을 추가함
• 브라우저 시간의 대부분은 호스팅인프라에서 가져온 초기 콘텐츠(보통 html)를 표시하기보다는, 모든 콘텐츠를 가져와 클라이언트에서 페이지를 렌더링하는 데 소요됨
• 웹 개발자들은 클라이언트의 네트워크 지연을 줄이고, 페이지 렌더링 시간을 최적화하는 방식으로 성능을 개선하는 데 점점 더 많은 관심을 기울이고 있음!

3.2.1 웹 성능 모범 사례

1) DNS 조회를 최적화하라

• 고유한 도메인/호스트이름의 수를 제한
• 조회 지연 시간 단축
• 초기 html이나 응답에 대해 DNS 프리패치를 활용
  이를 통해 dns의 고정적인 오버헤드를 최소화

  DNS prefetch
  is an attempt to resolve domain names before resources get requested. This could be a file loaded later or link target a user tries to follow.
  https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch

2) TCP 연결을 최적화하라

• preconnect를 활용
• 조기 종료 사용 (CDN 사용~)
• 최신 TLS 모범사례를 실행 (https://istlsfastyet.com/)

3) 리다이렉션을 피하라
특별한 상황을 제외하고는 대게는 리다이렉션을 할 만한 '타당한' 이유가 없다

• CDN을 활용하여 클라우드 대신 '클라우드에서' 리다이렉션을 수행
• 동일한 호스트 리다이렉션이라면, 리다이렉션을 사용하지 말고, 웹 서버에서 'Rewrite Rules'를 사용하여 사용자를 원하는 자원으로 연결

4) 클라이언트에 캐싱하라
가장 빠른 요청은 아무것도 요청하지 않는 것이다.
개체를 얼마나 오랫동안 캐싱할지를 브라우저에 알려주는 지시자가 바로 TTL(Time To Live)

• 이미지 또는 버전이 관리되는 콘텐츠와 소위 정적 콘텐츠는 영구적으로 클라이언트에 캐싱할 수 있음
  클라이언트 캐싱 TTL은 'Cache-Control' HTTP 헤더의 'max-age'(초) 키를 사용하거나 'Expires'헤더를 사용해 설정할 수 있음

5) 네트워크 경계에 캐싱하라
네트워크의 경계에 캐싱하면 모든 사용자가 클라우드 내의 공유 캐시의 혜택을 얻을 수 있으므로,
더 빠른 사용자 경험을 제공하고 서비스 인프라에서 많은 양의 트래픽을 덜어낼 수 있음

• 캐싱할 수 있는 자원의 종류:
  • 여러 사용자 간 공유 가능한 자원
  • 어느 정도 노후도를 수용할 수 있는 자원

6) 조건부 캐싱
조건부 캐싱: '그 개체가 변경되었으면 보내달라, 그렇지 않으면 그냥 동일하다고 알려달라'고 요청하는 기능

• 조건부 캐싱을 사용하는 방법:
  * If-Modified-Since를 요청헤더에 포함하기
  • ETag(개체를 고유하게 식별하는 엔티티 태그)를 요청헤더에 포함하기

7) 압축과 축소화
텍스트 형태의 모든 콘텐츠(HTML, JS, CSS, SVG, XML, JSON, 폰트)는 압축/축소화 가능
압축방식에는 gzip, deflate, Brotli가 있음

8) CSS/JS 차단을 피하라

9) 이미지를 최적화하라

• 이미지 최적화: 최소한의 바이트 수만으로 원하는 시각 품질을 달성하는 것
• 이미지 오버로딩: 이미지의 원본 크기가 브라우저의 창 크기를 넘거나 이미지 해상도가 디바이스 화면의 한계를 넘어, 브라우저에 의해 이미지의 크기가 자동으로 줄어든느 것

3.2.2 안티패턴

HTTP/2는 호스트마다 하나의 연결만 연다!

HTTP/2 웹사이트에서는 더 이상 적용되지 않는 인기 있는 방법들:

• 스프라이팅과 자원 통합/인라이닝

  • 스프라이팅: 이미지 여러 개를 큰 이미지 하나로 통합하여 여러 개의 이미지 요소를 단 한번만 요청할 수 있게 하는 것

• 샤딩

  • 샤딩: 호스트이름마다 다수의 연결을 열어 콘텐츠를 병렬로 내려받는 브라우저의 기능을 활용하는 것

• 쿠키 없는 도메인

  • http/1에서는 헤더 압축이 안되어서 쿠키에 의존하지 않는 자원을 위해 쿠키 없는 도메인을 만드는 것이 합리적인 권고 사항이었음
  • http/2에서는 헤더를 압축가능
  • 이미 알려진 정보를 전송하지 않기 위해 양 단에 '헤더 이력'을 저장

3.3 요약

• http2는 http1의 성능이슈를 개선하기 위하여 등장!

Chapter 4. HTTP/2로의 전환

웹사이트를 HTTP/2로 전환하기 전에 고려해야 할 몇가지:

• 브라우저의 h2 지원
• TLS(HTTPS)로의 전환
• 웹사이트의 h2 최적화(h1용 설정 제거)
• 웹사이트의 서드파티 개체
• 기존 클라이언트를 위한 지원 유지

4.1 브라우저 지원

이 책의 집필 시점 기준으로, 약 80%의 웹브라우저가 h2를 어느 정도 지원하고 있음
h2를 지원하지 않는 브라우저에서는 프로토콜 협상 절차가 무시되므로,
h2로 통신하지 않는 브라우저는 쉽게 다시 h1으로 되돌아와 인프라에 접속할 것임!

4.2 TLS로의 전환

모든 주요 브라우저가 TLS(HTTPS 요청)로만 h2에 접속!
그래서! TLS를 지원하지 않으면 할 수 있는 것이 아무것도 없다!

TLS 전환을 위해 고려해야하는 항목들(6):

(1) 웹 서버를 파악하라
(2) 인증서를 확보하라
(3) 개인키를 보호하라
(4) 증가하는 서버 부하에 대비하라

• 대칭 암호의 최적화는 부하를 줄이는 데 많은 도움이 되었지만, 임시키교환의 사용은 반대로 부하를 증가시킴
• 처음시작할 때 고려해야할 몇 가지 모범사례:
  연결을 가능한 한 길게 유지(TLS의 가장 비싼부분은 핸드셰이크 시간!)
  세션 티켓을 사용! (클라이언트는 이전의 핸드셰이크에서 얻은 값비싼 암호 계산값을 재사용하여 서버에 다시 연결할 수 있음!)
  * 암호화 지원을 내장한 칩셋을 사용
  (5) 변화를 주시하라
  최신 서버/https의 보안 취약점 파악하기
  (6) 웹사이트를 주기적으로 점검하라

TLS는 필수인가?

HTTP/2는 규격상 TLS가 필요 없으며, 평문으로 프로토콜을 협상하는 기능을 제공하지만!
어떤 주요 브라우저도 TLS없이는 h2를 지원하지 않고 있음!
그 이유:

• 1) 웹소켓과 SPDY를 시험한 결과, 80 포트를 통해 upgrade 헤더를 사용하면 프락시 차단 등의 원인으로 인해 높은 오류율을 보임!
• 2) 안전과 개인 정보 보호를 위해 모든 것을 암호화해야 한다는 믿음이 증가

4.3 HTTP/1.1 최적화 제거하기

h2에서는 요청의 구조화가 훨씬 더 최적화됨!
결합을 하지 않아야 요청 오버헤드가 적어지고 개별파일에 대한 더 세밀한 브라우저 캐싱을 할 수 있음!

4.4 서드파티

4.5 기존 클라이언트의 지원

4.6 요약

h2로의 전환은 다른 중요한 변경과 동일하게 다루어야 한다!
시험하고, 시험하고, 또 시험해야 한다!

Chapter 5. HTTP/2 프로토콜

5.1 HTTP/2의 계층

• 프레이밍 계층 : h2 다중화 기능의 핵심! 프레이밍 계층의 목적은 다름 아닌 HTTP를 주고받기 위함!!
• 데이터 계층(=http 계층) : 전통적인 http 및 관련
• HTTP/2는 이전에 애플리케이션 내에서 수행되던 상당수의 HTTP/1.1 임시 방편을 실행취소하고 이러한 문제를 전송 계층 내에서 해결할 수 있도록 함으로써 애플리케이션을 더 빠르고, 단순하고, 강력하게 만들어줌

h2만의 특성(4):

• 바이너리 프로토콜: h2 프레이밍 계층은 바이너리 프레임 형식의 프로토콜
• 헤더 압축
• 다중화 : 요청과 응답이 뒤섞여 있음
• 암호화
• HTTP/2의 주요 목표는 전체 요청을 통해 지연시간을 줄이고, 응답 다중화를 지원하며, HTTP 헤더 필드의 효율적 압축을 통해 프로토콜 오버헤드를 최소화하고, 요청 우선순위 지정을 추가하며, 서버 푸시를 지원하는 것!
• HTTP/2는 클라이언트와 서버 간에 데이터 서식(프레임)이 지정되는 방식과 데이터가 전송되는 방식을 수정
• 클라이언트와 서버는 전체 프로세스를 관리하며 애플리케이션의 복잡성을 새 바이너리 프레이밍 계층 내에 숨김. 따라서 기존의 모든 애플리케이션을 수정 없이 전달할 수 있음

5.2 연결

• 연결: 클라이언트가 개시한 TCP/IP 소켓으로 정의, HTTP 요청을 전송할 엔티티를 의미
• 상태를 저장하지 않는 h1과는 달리, h2는 h2 위에서 흐르는 모든 프레임과 스트림이 연관된 연결 수준의 요소들을 함께 묶음
• 클라이언트 엔드포인트가 h2로 통신한다는 사실을 서버에 다시 한번 더 알려주기 위해, 클라이언트는 "연결 전문"이라는 마법의 옥텟 스트림을 연결의 첫 번째 데이터로 전송

HTTP/2 두 가지 탐색 메터니즘:

(1) 연결이 암호화되지 않은 경우, 클라이언트 upgrade 헤더를 활용해 h2로 통신하려는 요구를 전달
(2) HTTP Alternative Services(Alt-Svc)를 사용

5.3 프레임

5.4 스트림

5.4.1 메시지

HTTP/1과 HTTP/2 메시지 간의 차이점

(1) 모든 것이 다 헤더다
(2) 청크 분할 인코딩이 필요 없다
(3) 101 응답이 필요 없다

5.4.2 흐름제어

5.4.3 우선순위

5.5 서버 푸시

• HTTP/2의 서버 푸시 기능의 목표: 개체가 요청되기 전에 브라우저의 캐시에 미리 가져다 두는 것!

5.5.1 개체 푸시하기

5.5.2 푸시할 대상 선정하기

5.6 헤더 압축(HPACK)

5.7 전송 절차

5.7.1 간단한 GET

5.8 요약

질문!:

• http 2.0는 stateless가 아닌가
  https://developers.google.com/web/fundamentals/performance/http2?hl=ko

Chapter 6. HTTP/2 성능

실제 HTTP/2 성능에 가장 큰 영향을 미치는 여러 요소들.

6.1 클라이언트 구현

브라우저마다 서로 다른 특성들이 있음

6.2 지연 시간

• 왕복시간(RTT): 패킷이 수신자에게 도착했다가 송신자에게 되돌아오는 데 필요한 시간
• 지연시간에 미치는 요일 2가지: 두 지점 사이의 거리, 사용하는 전송 매체의 속도
• 지연 시간을 줄이는 유일한 방법은 양 끝점을 더 가까이 두는 것(또는 더 빠른 전송 매체를 개발)

6.3 패킷 손실

• 높은 패킷 손실률은 h2로 전송되는 페이지에 악영향을 미침!
• 이는 h2가 단 하나의 TCP 연결만 술비하고, 손실/혼잡이 있을 때마다 TCP 프로토콜이 TCP 윈도우 사이즈를 줄이기 때문!

6.4 서버 푸시

6.5 TTFB(Time To First Byte)

6.6 서드파티

6.7 HTTP/2 안티패턴

h1 성능 패턴 중 일부는 h2에서는 안티패턴이 됨

6.7.1 도메인 샤딩

샤딩은 호스트이름마다 다수의 연결(최대 6개)을 열어 콘텐츠를 동시에 내려받고
h1의 순차적 특성을 극복하는 브라우저의 기능을 활용하는 것을 목표로 함
=> h2에서는 연결 병합과 샤딩 모두 사용하지 않는 것이 가장 좋다

6.7.2 인라이닝

인라이닝(inlining)은 외부 자원을 불러오는 데 필요한 추가적인 연결과 왕복을 줄이려는 목적으로 자바스크립트, CSS, 이미지를 HTML 페이지 안에 삽입하는 것을 의미
=> 대게 h2에서는 인라이닝을 피하는 것이 좋지만 때로는 도움이 되는 경우도 있음

6.7.3 결합 (concatenating)

결합이란 크기가 작은 파일 여러 개를 큰 파일 하나로 통합하는 것을 말함

6.7.4 쿠키 없는 도메인

쿠기가 없는 도메인을 위해서는 별도의 호스트를 사용해야 하며, 이는 더 많은 연결을 열어야 함을 의미.
=> h2에서는 헤더에 쿠기가 있어도 압축이 가능하니! 오키도키!

6.7.5 스프라이팅

스프라이팅은 크기가 작은 개체들을 여러 번 요청하는 일을 피하기 위한 또 다른 기법.
=> h2에서는 다중화와 헤더 압축을 통해 많은 요청 오버헤드를 제거할 수 있기 때문에 스프라이팅은 사용하지 않는 것이 좋음! 하지만 스프라이팅이 도움이 되는 경우가 여전히 있을 수 있음

6.7.6 프리패치 (prefetch)

프리패치란 캐싱할 수 있는 개체를 가능한 시점에 미리 내려받아 두도록 브라우저에 알려주는 웹성능 최적화 기법.
=> 서버푸시가 도입된 h2에서는 별 쓸모가 없음
프리패치가 서버푸시보다 나은 점은 개체가 캐시에 이미 있는 경우에 개체를 요청하는 데 필요한 시간과 대역폭을 낭비하지 않는다는 점!
h2의 서버 푸시가 프리패치를 대체한다기보다는 서로 부족한 부분을 보완한다고 생각하는 것이 좋다!

6.8 실세계의 성능

6.8.1 성능 측정 방법

• 조건:
  • 테스트 위치
  • 브라우저
  • 연결
  • 테스트 실행

6.8.2 연구 1: www.facebook.com

6.8.3 연구 2: www.yahoo.com

6.9 요약

중요한 것은 어떻게 해서 성능이 개선되고
어떤 경우에는 성능이 개선되지 않는지 그 이유를 이해하는 것!
성능 개선을 위한 다른 모든 노력과 마찬가지로 코딩하고, 테스트하고, 분석하고, 최적화하는 과정이 반복될 것임!

Chapter 7. HTTP/2 구현

7.1 데스크톱 웹 브라우저

7.1.1 필수적인 TLS

7.1.2 HTTP/2 비활성화

7.1.3 서버 푸시

7.1.4 연결 병합

7.1.5 디버깅 도구

7.1.6 베타 채널

7.2 모바일 브라우저

7.3 모바일 앱 지원

7.4 서버, 프락시, 캐시

7.5 콘텐츠 전송 네트워크

7.6 요약

Chapter 8. HTTP/2 디버깅하기

8.1 웹 브라우저 개발자 도구

8.1.1 크롬 개발자 도구

• net-internals : 하지만 http2 최신버전에서는 없....ㅠㅠ
• 서버 푸시 시각화
• 크롬 세션키 로깅

8.1.2 파이어폭스 개발자 도구

• HTTP 세션 로깅
• 파이어폭스 세션키 로깅

8.1.3 iOS에서 찰스 프락시를 사용해 h2 디버깅하기

• iOS 시뮬레이터
• iOS 디바이스

8.1.4 안드로이드에서 h2 디버깅하기

8.2 웹페이지 테스트

8.3 OpenSSL

8.3.1 OpenSSL 명령어

8.4 nghttp2

8.4.1 nghttp 사용하기

8.5 curl

8.5.1 curl 사용하기

• 페이지 로딩 시간 측정하기

8.6 h2i

8.7 와이어샤크

8.8 요약

Chapter 9. 다음은 무엇인가?

급속한 변화의 근원과 그 이면의 개념을 이해하려면,
HTTP의 토대가 되는 stack에 대한 배경지식을 갖는 것이 중요!

9.1 TCP인가, UDP인가

• 현대의 OS 대부분은 TCP 스택이 커널에 포함되어 있음
• UDP로 쓰려는 이유는 제어권을 위함!
• "TCP인가, UDP인가"가 아니라, "커널 공간인가, 사용자 공간인가"임!

9.2 QUIC (Quic UDP Internet Connection)

• HTTP/2의 약점은 TCP 구현에 의존적이라는 것
• QUIC는 사용자 공간에 상주하는 UDP 기반의 전송 프로토콜 위헤 HTTP/2를 두며, 프로토콜로서의 완전한 면모를 갖추기 위해 암호와 인증 등의 기능을 포함함!
• QUIC의 특징
  • 비순차 패킷 처리
  • 유연한 혼잡 제어
  • 낮은 연결 수립 오버헤드
  • 전송 정보의 인증 => QUIC는 패킷헤더 인증
  • 연결 이동 => QUIC는 클라이언트가 이동할 때도 연결을 보존하려고 노력함

9.3 TLS 1.3

• TLS (Transport Layer Security)
• 암호화 및 인증 계층

9.4 HTTP/3

9.5 요약

느낀점

• "TCP인가, UDP인가"가 아니라, "커널 공간인가, 사용자 공간인가"임!
• UDP는 단순히 tcp처럼 3-way handshake 및 전송완료 여부등을 체크하지 않아서 빠르다는 장점이 있다고만 생각했는데! tcp는 커널에 포함되어 있어 사용자가 커스텀해서 사용하기 어렵기 때문에 udp를 사용한다는 관점을 생각지못했다! 신선하다!

Reference

• Oreilly, Learning HTTP/2 스티븐 루딘, 하비에르 가르사 지음, 강재준 옮김
• https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch
• https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/
• http://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/
• https://stackoverflow.com/questions/53488601/what-is-difference-between-https-and-http-2
• https://www.ssl.com/article/an-introduction-to-http2/
• https://developers.google.com/web/fundamentals/performance/http2?hl=ko
• https://hpbn.co/brief-history-of-http/