[10장] HTTP/2.0

10.1 HTTP/2.0의 등장 배경

• HTTP/1.1의 메시지 포맷은 구현의 단순성, 접근성에 주안성을 두고 최적화
• HTTP/1.1 특징 & 문제
  • 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만 받음
  • 회전 지연(latency) 문제. 응답 받아야만 다음 요청을 보낼 수 있음
  • 해결을 위한 병렬 커넥션, 파이프라인 커넥션이 도입으로는 부족
• 해결 노력
  • HTTP-NG 프로젝트
  • WAKA 프로토콜 제안
  • S+M(Speed+Mobility) 프로토콜 개발
  • SPDY(스피디)
  • → SPDY의 초안을 가져와 HTTP/2.0 만들기 시작

---

10.2 개요

• HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작
  • TCP 초기화는 클라이언트가 함
  • 요청과 응답은 정의된(<=16383byte) 한 개 이상의 프레임에 담김
  • HTTP 헤더는 압축되어 담김
  • 프레임들에 담김 요청과 응답은 스트림을 통해 보내짐
  • 하나의 커넥션 위에 여러 개의 스트림이 동시에 만들어질 수 있음
    → 여러 개의 요청/응답 동시 처리 가능
• 기존 웹 애플리케이션들과 호환성을 최대한 유지하기 위해 요청/응답 메시지 의미를 HTTP/1.1과 같도록 유지

---

HTTP/1.1과의 차이점

10.3.1 프레임

• HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송
• 모든 프레임은 8바이트 크기의 헤더로 시작
• 뒤이어 최대 16383바이트 크기의 페이로드가 옴

프레임 헤더의 각 필드

• R
  • 예약된 2비트 필드. 값의 의미 정의 안됨. 반드시 0. 받는 쪽에서는 이 값 무시해야 함
• 길이
  • 페이로드의 길이를 나타내는 14비트 무부호 정수. 프레임 헤더에 포함되지 않는 길이
• 종류
  • 프레임의 종류
• 플래그
  • 8비트 플래그. 값의 의미는 플래그 종류에 따름
• R
  • 예약된 1비트 비트. 첫 번째 R과 마찬가지로 의미 정의 안됨.
• 스트림 식별자
  • 31비트 스트림 식별자. 특별히 0은 커넥션 전체와 연관된 프레임을 의미

10.3.2 스트림과 멀티플렉싱

• 스트림은 HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스
• 한 쌍의 HTTP 요청과 응답은 하나의 스트림을 통해 이루어짐
• HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있음
• 스트림은 우선순위도 가질 수 있음
• HTTP/2.0 커넥션에서 한번 사용한 스트림 식별자는 다시 사용할 수 없음
  • 이때 스트림에 할당할 수 있는 식별자가 고갈될 수 있음
  • 커넥션을 다시 맺으면 해결됨

10.3.3 헤더 압축

• HTTP/1.1에서 헤더는 아무런 압축 없이 전송
• 웹페이지 하나를 보기 위한 요청의 개수가 많아져 헤더의 크기가 문제가 됨
• 이를 개선하기 위해 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송
• HPACK 명세에 정의된 헤더 압축 방법으로 압축된 뒤 헤더 블록 조각들로 쪼개 전송
• 받는 쪽에서는 이 조각들을 이은 뒤 압축을 풀어 원래의 헤더 집합으로 복원
• 압축, 해제 시 압축 콘텍스트를 사용

10.3.4 서버 푸쉬

• HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 함
• 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용
• 리소스를 푸쉬하려는 서버는 먼저 클라이언트에게 자원을 푸쉬할 것임을 PUSH_PROMISE 프레임으로 미리 알림
• 해당 프레임 스트림은 예약됨(원격) 상태가 됨
• 이 상태에서 클라이언트는 RST_STREAM 프레임을 보내어 푸쉬 거절 가능

---

10.4 알려진 보안 이슈

10.4.1 중재자 캡슐화 공격

• HTTP/2.0 메시지를 중간의 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성 있음
• HTTP/1.1과는 달리 HTTP/2.0은 헤더 필드의 이름과 값을 바이너리로 인코딩
• 다행히 HTTP/1.1 메시지를 번역하는 과정에서 번역 문제가 발생하지는 않음

10.4.2 긴 커넥션 유지로 인한 개인정보 누출 우려

• HTTP/2.0은 사용자가 요청을 보낼 때의 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두
• 개인 정보 유출에 악용될 가능성 있음
• 이는 HTTP가 현재 갖고 있는 문제이기도 하지만, 짧게 유지되는 커넥션에서는 위험이 적음

---