[http 완벽 가이드] 10장 HTTP/2.0

 

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

10장 HTTP/2.0

1. HTTP/2.0의 등장 배경

• HTTP/1.1은 커넥션을 하나를 두고 요청보내야만 응답을 받고 응답을 받고 요청을 보내는 구조를 가지고 있다.
• 이는 심각한 회전 지연을 피할 수 없었다.
• 이 문제를 회피하기 위해 병렬 커넥션이나 파이프라인 커넥션이 도입 되었지만 성능 개선에 대한 근본적인 해결책은 되지 못했다.
• 이에 구글은 SPDY라는 프로토콜을 개발했고 이는 헤더 압축과 한개의 커넥션으로 여러 요청을 동시에 보낸다는 점이 강점으로 HTTP보다 훨씬 빨랐다
• 이에 HTTP 작업 그룹은 SPDY를 기반으로 HTTP/2.0 프로토콜을 설계하기로 결정하였다.

2. 개요

• HTTP 2.0은 TCP 커넥션 위에서 동작한다.
• 요청과 응답은 길이가 정의된 한개의 이상의 프레임에 담긴다.
  • 이때 헤더는 압축하여 담긴다.
• 한개의 커넥션에는 여러개의 스트림이라는 통로를 만들 수 있고
• 스트림은 한쌍의 요청과 응답을 처리한다.
• 이 스트림의 우선순위를 제어할 수 있고
• HTTP 2.0은 기존 요청 응답과 약간 다른 상호작용 모델인 서버 푸시를 도입했다.
• 기존 HTTP 1.1과의 호환성을 최대한 유지하였다.

3. HTTP 1.1 과의 차이점

3.1 프레임

• HTTP 2.0의 모든 메시지는 프레임에 담겨 전송된다.
• 프레임은 8바이트 크기의 헤더로 시작하며, 뒤이어 최대 16383 바이트 크기로 페이로드가 온다.

3.2 스트림과 멀티플렉싱

• 스트림은 HTTP 2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스다.
• HTTP1.1의 파이프라인 커넥션과 병렬 커넥션으로 안되는 회전지연의 단점을 보완했다.
• HTTP 2.0은 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다.
• 뿐만 아니라 스트림은 우선순위도 가질 수 있다.
  • 예를 들어 네트워크 대역폭이 충분하지 않아 전송이 느리다면 중요한 리소스 먼저 보낼 수 있다는 뜻
• 그러나 이 우선순위는 의무가 아니므로 요청이 우선순위대로 행해진다는 보장은 없다.
• 서버와 클라이언트는 스트림을 상대방과 협상 없이 일방적으로 만든다. 이는 스트림을 만들 때 협상을 위해 TCP 패킷을 주고받느라 시간을 낭비하지 않아도 됨을 의미한다.
• 이처럼 동시에 여러개의 스트림을 사용하면 스트림이 블록될 우려가 있다는 주장이 있다. 하지만 HTTP 2.0 은 프레임을 이용한 흐름 제어를 통해, 스트림들이 서로 간섭해서 망가지는 것을 막아준다.

3.3 헤더 압축

• HTTP 2.0 은 헤더를 압축을 해서 보낼 수 있다.
• 헤더는 HPACK 명세에 정의된 헤더 압축 방법으로 압축된 뒤 헤더블록 조각들로 쪼개져서 전송된다.
• HPACK 은 헤더를 압축하고 해제할 때 압축 콘텍스트를 사용한다.
• 압축을 풀면 압축 콘텍스트가 영향을 받아 송신 쪽은 콘텍스트가 당연히 바꼈다고 생각하기 때문에 수신 측은 항상 압축을 풀어야한다.

3.4 서버 푸시

• HTTP 2.0 은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다.
  • 예를 들어 HTML 문서를 요청 받은 서버는 그 HTML 문서가 링크하고 있는 이미지, CSS 파일 , JS 파일등의 리소스를 클라이언트에게 푸시할 수 있을 것이다.
  • 이는 리소스를 다시 요청하는 트래픽과 회전 지연을 줄여준다.
• 리소스를 푸시하려는 서버는 먼저 클라이언트에게 자원을 푸시할 것임을 PUSH_PROMISE 프레임을 보내어 미리 알려주어야 한다.
• PUSH_PROMISE 프레임은 리소스를 요청하는 응답 데이터보다 먼저 도착해야 한다.
• 리소스에 대해 중복 요청이 생성되는 것을 막기 위해 클라이언트는 서버가 어떤 리소스를 푸시할지 알아야 하고, 이러한 요구사항을 충족시키기 위해 약속했던 리소스의 HTTP 헤더만 포함된 모든 PUSH_PROMISE 프레임을 상위 요소의 응답(DATA 프레임)보다 먼저 전송한다.
• 클라이언트는 PUSH_PROMISE 프레임을 수신한 후에 RST_STREAM 프레임을 보내어 푸시를 거절할 수 있다.

4. 알려진 보안 이슈

4.1 중개자 캡슐화 공격

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

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

• HTTP 2.0 은 회전 지연을 줄이기 위해 커넥션을 오래 유지한다. 이는 개인 정보의 유출에 악용될 가능성이 있다.