[Network] HTTP 1.1 & 2.0 & 3.0

1. HTTP 1.0

• POST 메소드의 추가로 클라이언트의 정보를 전달할 수 있게 됐다.
• HTML 뿐 아니라 동영상 등 다양한 정보를 주고 받을 수 있게 됐다.

단기 커넥션

RFC 2626(인터넷 연구, 개발 공동체 작업문서. 한번 부여된 문서의 번호는 수정되거나 중복 번호가 매겨지는 일이 없다.)에 의하면 서버는 반드시 응답을 요청 순서에 맞춰 전달해야 한다는 HTTP 프로토콜 규칙에 의해 HTTP Request는 연속적으로 발생하고 순차적으로 처리된다. 이로 인해 요청때마다 TCP 연결을 생성하게 되고 이 때문에 성능 제약이 발생한다.

2. HTTP 1.1

• GET, POST 메소드 이외에 PUT, DELETE 메소드가 추가됐다.
• HTTP 1.0의 단기 커넥션 문제를 해결하기 위해 영속적 커넥션(Persistent Connection), HTTP 파이프라이닝 기법이 등장했다.

영속적 커넥션(Persistent Connection)

한번 생성된 TCP 연결을 서버가 keep-alive 헤더에 시간을 설정함으로써 일정 시간 지속적으로 열어둠으로써 HTTP Request를 여러개 받아낼 수 있도록 하는 연결 방식이다. 그러나 사용량이 적음에도 연결을 유지하는 것은 리소스 낭비이다.

HTTP 파이프라이닝

순차적인 응답을 처리하기 위해 여러 요청들에 대한 응답처리를 뒤로 미루는 방식이다. 그러나 우선적인 메시지의 응답처리가 미뤄지는 경우가 생기고 결국 Head Of Line Blocking(HOL)이라는 응답 지연 문제를 발생시킨다.

도메인 샤딩

도메인을 여러개로 분리하면서 여러 요청들에 대한 응답 처리가 가능하도록 분산시키는 방식이다. 하지만 몇개의 도메인이 최적인지 결정하는 것은 쉽지 않은 문제이고 오히려 HTTP 2.0의 특징인 헤더 압축, 우선순위 전송, 서버 푸시 기능을 방해한다. 또한 DNS Lookup 에 소요되는 시간, 각각의 Connection을 유지하는 비용들이 필요해진다. 그러면서 최초 로드 시간이 오래 걸리게 된다. 이후 캐싱을 사용하여 로드 시간이 단축되겠지만 결정적으로 HTTP 2.0 핵심 기술의 저해요소이므로 되도록 사용하지 않는다.

3. HTTP 2.0

HTTP 1.1 의 메시지 포맷은 구현의 단순성, 접근성에 두고 최적화됐다. 커넥션 하나를 통해 요청을 보고 그에 대해 응답 하나만을 받는 메시지 교환 방식은 단순하지만 응답을 받아야만 그 다음 요청을 받을 수 있기 때문에 회전 지연을 피할 수 없었다.

 

단순 텍스트 방식의 프로토콜 메시지에서 이진 포맷을 사용하여 경량화하고자한 첫 시도이다. 요청과 응답은 길이가 정의된 (최대 16383 (2^14 - 1) 바이트) 한 개의 프레임 안에 담겨져 스트림을 통해 보내진다. 한 개의 스트림이 한 쌍의 요청, 응답을 처리하고 스트림은 한 개의 커넥션에 여러개가 만들어질 수 있어 여러개의 요청, 응답을 처리하는 것이 가능하다. 또한 이런 스트림에 대한 흐름 제어, 우선순위 부여 기능도 제공한다. 그리고 요청-응답과는 약간 다른 새로운 상호 작용인 서버 푸시 기능을 도입했는데 이를 통해 서버는 클라이언트에게 필요하다고 생각되는 리소스라면 그에 대한 요청을 명시적으로 받지 않더라도 능동적으로 클라이언트에게 보낸다.

 

이전 HTTP 1.1에 대한 개선을 프레임, 스트림, 멀티플렉싱, 헤더 압축, 서버 푸시와 같은 기술의 도입으로 이뤄냈다. 또한 이러한 기술들로 인해 하나의 페이지에서 수십, 수백번의 요청을 보내는 오늘날, 회전지연과 대역폭 양쪽 모두에 대한 문제점을 개선할 수 있게 됐다.

 

프레임

HTTP 2.0에서 모든 메시지는 프레임에 담겨 전송된다. 모든 프레임은 8바이트 크기의 헤더로 시작되고 위이어 최대 16383 바이크 크기의 페이로드로 구성 되어있다.

 

스트림과 멀티플렉싱

HTTP 1.1에서는 한 TCP 커넥션을 통해 요청을 보내면 그에 대한 응답이 도착해야 같은 커넥션으로 다시 요청을 보낼수 있었다. 그러면서 발생하게 되는 회전 지연에 대응하기 위해 여러 커넥션을 무한정 만들수는 없기 때문에 개선 사항이 필요했다.

HTTP 2.0에서 한 쌍의 요청-응답은 하나의 스트림을 통해 이뤄진다. 클라이언트는 새 스트림을 만들어 그를 통해 HTTP 요청을 보내고 요청을 받은 서버는 그 요청과 같은 스트림으로 응답을 보내고 스트림이 닫히게 된다.

이러한 스트림이 하나의 커넥션에 여러개가 동시에 열릴 수 있다. 또한 이런 스트림은 우선순위를 가질 수 있다. 이로 인해 여러개의 요청에 대한 작업을 원활히 수행할 수 있다.

 

헤더 압축

HTTP 2.0 에서는 HTTP 메시지의 헤더를 압축하여 전송한다. 클라이언트와 서버 사이에 가상 테이블을 만들어 동일하고 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식으로 중복을 제거한다.

가상 테이블은 정적 테이블과 동적 테이블로 나눌 수 있는데, 정적 테이블에는 미리 정의된 자주 사용되는 헤더 필드를 저장하고 동적 테이블에는 클라이언트와 서버가 주고 받은 값들을 업데이트 한다. 또한 헤더 압축 알고리즘인 HPACK을 사용해 허프만 알고리즘 방식으로 헤더를 압축한다.

서버 푸시

HTTP 2.0은 서버가 하나의 요청에 대해 응답으로 여러개의 리소스를 보낼 수 있도록 한다. 이 기능은 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에 유용하다.

예를 들어, HTML 문서를 요청 받은 서버는 HTML 문서가 링크하고 있는 이미지, CSS 파일, JS 파일 등의 리소스를 클라이언트에게 푸시할 수 있다. 이는 클라이언트가 HTML 문서를 파싱하여 필요한 리소스를 다시 요청하면서 발생하는 트래픽과 회전 지연을 줄여준다.

 

이러한 HTTP 2.0에도 취약점은 존재한다. 중개자 캡슐화 공격이나 긴 커넥션 유지로 인한 개인정보 노출 우려와 같은 보안 이슈들이 대표적 예이다.

4. HTTP 3.0

HTTP 2.0이 HTTP 1.x 의 단점을 보완하고 새 기능을 추가해 웹 성능을 개선하는데 목적이었다면 HTTP 3.0은 기능을 추가하기 보다는 HTTP 가 작동하는 TCP 가 가지는 원초적인 단점을 보완하는데 중점을 두고 있다. 기본적으로 HTTP 2.0이 가진 장점은 모두 지니고 있다.

HTTP 3.0을 이해하기 위해서는 구글이 개발한 QUIC의 이해가 필요하다. HTTP 3.0은 TCP가 가지는 단점을 개선하기 위해 고안된 프로토콜이다. 그래서 QUIC는 UDP를 채택하여 TCP의 성능 개선을 꾀했다. 상대적으로 전달 속도가 빠른 UDP의 전달 속도를 통해 속도 향상과 더불어 클라이언트와 서버의 연결 수를 최소화하여 대역폭을 예상하고 패킷 혼잡을 피하는 것이 주요 특징이다.

QUIC는 이전에 클라이언트가 한 번이라도 접속했다면 별도의 정보 교환 없이 바로 데이터를 보내는 기술을 소개한다. 이 기능을 Zero RTT(Round Trip Time)이라고 한다. 아직 실험단계이지만 상용화 된다면 가장 획기적인 기능이라고 소개된다.