HTTP/2.0
HTTP/2.0에 대해서 만들기 시작한 배경, HTTP/1.1과의 주요 차이점, 현재까지 알려진 보안 이슈에 대해 다루겠습니다.
HTTP/2.0의 등장 배경
HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화 되었습니다. 그러다 보니 성능은 어느 정도 희생시키지 않을 수 없었습니다. 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 HTTP의 메시지 교환 방식은 단순하여 좋지만, 응답을 받아야만 그 요청을 보낼 수 있기 때문에 심각한 회전 지연을 피할 수 없었습니다. 물론 이를 해결하기 위해 병렬 커넥션이나 파이프라인 커넥션이 도입되었지만 근본적인 해결책은 되지 못했습니다. 그래서 HTTP/2.0가 등장하게 되었습니다.
개요
HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작합니다. 이때 TCP 커넥션을 초기화하는 것은 클라이언트입니다. HTTP/2.0 요청과 응답은 길이가 정의된 한 개 이상의 프레임에 담기고 HTTP 헤더는 압축되어 담깁니다. 이들은 스트림을 통해 보내지게 되는데 이 스트림에 대한 흐름 제어와 우선순위 부여 기능도 제공합니다.
또한 서버 푸시를 도입하여 서버는 클라이언트에게 필요하다고 생각하는 리소스라면 그에 대한 요청을 명시적으로 받지 않더라도 능동적으로 클라이언트에게 보내줄 수 있습니다. 그리고 기존 웹 애플리케이션들과 호환성을 최대한 유지하기 위해 요청과 응답 메시지의 의미를 HTTP/1.1과 같도록 유지하고 있습니다.
HTTP/1.1과의 차이점
프레임
HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송됩니다. 모든 프레임은 8바이트 크기의 헤더로 시작하며, 뒤이어 최대 16383바이트 크기의 페이로드가 옵니다.
스트림과 멀티플렉싱
스트림은 HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스입니다. 한 쌍의 HTTP 요청과 응답은 하나의 스트림을 통해 이루어집니다. 클라이언트는 새 스트림을 만들어 그를 통해 HTTP 요청을 보내고 요청을 받은 서버는 그 요청과 같은 스트림으로 응답을 보냅니다. 그리고 나면 스트림이 닫히게 됩니다.
HTTP/1.1에서는 한 TCP 커넥션을 통해 요청을 보냈을 때, 그에 대한 응답이 도착하고 나서야 같은 TCP 커넥션으로 다시 요청을 보낼 수 있지만 HTTP/2.0 에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있습니다. 또한 스트림은 우선순위도 가질 수 있어 중요한 리소스에 대해 우선순위를 부여할 수 있습니다.
헤더 압축
HTTP/1.1에서 헤더는 아무런 압축 없이 그대로 전송되었지만 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송합니다.
서버 푸시
HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해줍니다. 이 기능은 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용합니다.
알려진 보안 이슈
중개자 캡슐화 공격
HTTP/2.0 메시지를 중간에 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있습니다. HTTP/2.0는 헤더 필드의 이름과 값을 바이너리로 인코딩 하는데, 이는 HTTP/2.0이 헤더 필드로 어떤 문자열이든 사용할 수 있게 해줍니다.
긴 커넥션 유지로 인한 개인정보 누출 우려
HTTP/2.0은 사용자가 요청을 보낼 때의 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두해 두고 있습니다. 이는 개인 정보의 유출에 악용될 가능성이 있습니다.