Skip to content

[HTTP] HTTP 2.0.md

Latest commit

 

History

History
52 lines (45 loc) · 4.81 KB

[HTTP] HTTP 2.0.md

File metadata and controls

52 lines (45 loc) · 4.81 KB

HTTP/2.0의 등장 배경

  • HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화 되었다.
  • 커넥션 하나를 통해 요청 하나를 보내고 그에 대한 응답 하나만을 받는 HTTP의 메시지 교환방식은 응답을 받아야만 그다음 요청을 보낼 수 있기 때문에 심각한 회전 지연(latency)를 피할 수 없었다.
  • 병렬커넥션이나 파이프라인 커넥션을 도입했지만 근본적인 해결책은 되지 못함
  • 구글의 SPDY를 기반으로 HTTP/2.0 설계
  • SPDY는 헤더를 압축하여 대역폭을 절약했고, 하나의 TCP 커넥션에 여러 요청을 동시에 보내 회전 지연을 줄이는 것이 가능했으며, 클라이언트가 요청을 보내지 않아도 서버가 능동적으로 리소스를 푸시하는 기능도 갖추고 있다.
  • HTTP/2.0 Spec

HTTP/1.1과의 차이점

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

  • 스트림과 멀티플렉싱
    • 스트림은 HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스
    • HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다.
    • 스트림은 우선순위를 가질 수 있다.
    • 모든 스트림은 31비트의 무부호 정수로 된 고유한 식별자를 갖는다.
    • 스트림이 클라이언트에 의해 초기화되었다면 홀수, 서버라면 짝수여야 한다.
    • 서버와 클라이언트는 스트림을 상대방과 협상 없이 일방적으로 만든다. 이는 협상을 위해 TCP 패킷을 주고 받느라 시간을 낭비하지 않아도 됨을 의미한다.

  • 헤더 압축
    • SPDY에서는 deflate 알고리즘으로 헤더를 압축 했으나 HTTP 쿠키를 노리는 취약점 공격에 취약 해진다는 보안 문제가 있기 때문에 HTTP/2.0에서는 HPACK 명세에 따라 헤더를 압축한다.

  • 서버 푸시
    • HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다.
    • 리소스를 푸시하려는 서버는 먼저 클라이언트에게 자원을 푸시할 것임을 PUSH_PROMISE 프레임을 보내어 미리 알려주어야 한다.
    • 서버가 푸시하려고 하는 자원을 클라이언트가 별도로 또 요청하게 되는 상황을 피하기 위함.
    • 서버 푸시를 사용할 때 주의 사항
      • 서버 푸시를 사용하기로 했더라도, 중간의 프락시가 서버로부터 받은 추가 리소스를 클라이언트에게 전달하지 않을 수 있으며, 반대로 아무런 추가 리소스를 서버로부터 받지 않았음에도 클라이언트에게 추가 리소스를 전달할 수 있다.
      • 서버는 오직 안전하고, 캐시 가능하고, 본문을 포함하지 않는 요청에 대해서만 푸시할 수 있다.
      • 푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야 한다.
      • 클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책에 따라 검사해야 한다.
      • 서버 푸시를 끄고 싶다면 SETTINGS_ENABLE_PUSH를 0으로 설정하면 된다.

알려진 보안 이슈

  • 중개자 캡슐화 공격(Intermediary Encapsulation Attacks)
    • HTTP/2.0의 메시지를 중간의 프락시(중개자)가 HTTP/1.1메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다.
    • HTTP/1.1과는 달리 HTTP/2.0은 헤더 필드의 이름과 값을 바이너리로 인코딩한다. 이는 HTTP/2.0이 헤더 필드로 어떤 문자열(줄바꿈 문자열 조차 허용된다)이든 사용할 수 있게 해준다. 이는 정상적인 HTTP/2.0 요청이나 응답이, 불법적이거나 위조된 HTTP/1.1 메시지로 번역되는 것을 유발할 수 있다.
    • HTTP/1.1 메시지를 HTTP/2.0 메시지로 번역하는 과정에서는 이런 문제가 발생하지 않는다.

  • 긴 커넥션 유지로 인한 개인정보 누출 우려
    • HTTP/2.0은 사용자가 요청을 보낼 때의 회전 지연을 주이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두에 두고 있다보니 개인 정보의 유출에 악용될 가능성이 있다.
    • 예를 들어 어떤 사용자가 브라우저를 사용할 때, 그 사용자는 이전에 그 브라우저를 사용했던 사용자가 무엇을 했는지 알아낼 가능성이 있다.
    • 현재 HTTP가 갖고 있는 문제이기도 하지만, 짧게 유지되는 커넥션에서는 위험이 적다.