GitHubAboutDocsTech-Log

HTTP/2.0

HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 초점을 맞추어 설계되었기 때문에 성능상의 문제가 발생하게 됐다. 커넥션 하나당 하나의 요청과 응답만 처리할 수 있기 때문에, 요청과 응답이 많아지는 경우 회전 지연(latency)가 커지게 됐고, 병렬 커넥션이나 파이프라인 커넥션이 도입되었지만 근본적 해결책은 되지 못했다. 때문에 효율성 측면의 향상을 위해 HTTP/2.0이 등장했다.

개요

  1. HTTP/2.0 역시 TCP 커넥션 위에서 동작

  2. 요청과 응답 방식

    • 길이가 정의된 한 개 이상의 프레임에 담기며, 헤더는 압축되어 전송

    • 이러한 프레임들을 스트림을 통해 전송

    • 하나의 스트림은 한 쌍의 요청과 응답을 처리

    • 하나의 커넥션 위에 여러 개의 스트림이 동시에 생성 가능하여, 여러 개의 요청과 응답을 동시에 처리 가능(우선 순위 부여 기능도 제공)

  3. 서버 푸시 기능

    • 클라이언트가 요청한 리소스 외에도 서버가 클라이언트에게 보낼 수 있는 기능

  4. HTTP/1.1 호환성

    • 기존 웹 애플리케이션들과 호환성을 최대한 유지하기 요청/응답 메시지의 의미를 최대한 같도록 유지

HTTP/1.1과의 차이점

프레임

HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송하며 구조는 아래와 같다.

+-----------------------------------------------+
| R |       Length(14)      | Type(8) | Flag(8) |
+---------------+-------------------------------+
|R|   Stream Identifier(31)                     |
+-----------------------------------------------+
| Stream Payload                                |
+-----------------------------------------------+

  • R: 예약된 2비트 필드

    • 값의 의미가 정의되어 있지 않음

    • 반드시 0으로 설정

    • 받는 쪽에서는 이 값을 무시

  • Length: 프레임 페이로드의 길이를 나타냄

    • 14비트 무부호 정수(unsigned integer)로 표현

    • 표현된 길이에 프레임 헤더는 미포함

  • Type: 프레임의 종류

  • Flag: 프레임의 특성을 나타내는 8비트 필드

    • 각 프레임마다 사용하는 플래그의 종류가 다름

  • R: 예약된 1비트 필드

    • 첫 번째 R과 마찬가지로 값의 의미가 정의되어 있지 않음

    • 반드시 0으로 설정

    • 받는 쪽에서는 이 값을 무시

  • Stream Identifier: 31비트 스트림 식별자

    • 0은 특별하게 커넥션 전체와 연관된 프레임을 의미

위 프레임을 아래 총 10가지로 정의하고 있으며, 페이로드의 형식이나 내용은 프레임의 종류에 따라 달라진다. (DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION)

스트림과 멀티플렉싱

스트림이란 하나의 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스로, 한 쌍의 요청과 응답은 하나의 스트림을 통해 이루어지게된다. 스트림을 통한 통신은 아래와 같이 진행된다.

  1. 클라이언트가 스트림을 생성

  2. 해당 스트림을 통해 HTTP 요청 전송

  3. 요청을 받은 서버가 같은 스트림을 통해 HTTP 응답 전송

  4. 스트림 닫힘

HTTP/1.1에서는 한 TCP 커넥션을 통해 요청을 보냈을 때 응답이 도착해야 같은 TCP 커넥션으로 다음 요청을 보낼 수 있었다. 하지만 HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있기 때문에, 하나의 커넥션으로 여러 개의 요청과 응답을 동시에 처리할 수 있다. 추가적으로 스트림 사이에 우선 순위를 부여할 수 있기 때문에, 중요한 요청에 더 높은 우선 순위를 부여하여 더 빠르게 응답을 받을 수 있다.

헤더 압축

HTTP/1.1에서는 헤더를 압축 없이 보냈으나, HTTP/2.0에서는 헤더를 압축하여 전송한다. 현대 웹페이지에서는 하나의 페이지를 구성하기 위해 여러 개의 리소스를 요청하게 되는데, 이 때 헤더를 압축하지 않으면 많은 양의 데이터가 전송되게 된다.

보안 이슈

중개자 캡슐화 공격(Intermediary Encapsulation Attack)

HTTP/2.0 메시지를 중간에 프락시(중개자)가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질된 가능성이 있다. HTTP/2.0은 헤더 필드의 이름과 값을 바이너리로 인코딩하게 되는데, 이는 HTTP/2.0 헤더 필드로 어떤 문자열이든 들어올 수 있게 되어 불법적이거나 위조된 HTTP/1.1 메시지로 번역될 가능성이 있다. 반대로 HTTP/1.1 메시지를 HTTP/2.0 메시지로 변환할 때는 해당 문제가 발생하지 않는다.

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

단순히 HTTP/2.0을 사용하게 되면, 커넥션을 오래 유지하게 되어 개인정보 누출의 위험이 있다.

참고자료

Last updated

Was this helpful?