구글의 비표준 개방형 네트워크 프로토콜인 SPDY에 기반한다.
HTTP2가 되었다고 기존 HTTP의 의미 체계나 표준이 바뀌는 것이 아닌, 확장의 개념으로 받아들여야 한다.
모든 핵심 개념은 그대로 유지 되고 있다. (HTTP 메서드, 상태 코드, URI, 헤더필드 등이 동일하게 호환 된다.)
탄생 배경
HTTP 1.x 에서의 문제점을 적어보자면,
- 동시성을 실현하기 위해 필요한 여러개의 커넥션
- 요청 및 응답 헤더를 압축하지 않음으로써 생기는 불필요한 네트워크 트래픽
- 효율적인 리소스 우선 순위를 지정을 허용치 않으므로써 생길 수 있는 TCP 연결 문제
뭐 크게 치명적인 문제들은 아니라고 한다.
하지만 웹 애플리케이션이 더 널리 사용되고, 복잡해지고, 중요해짐에 따른 개발자와 사용자의 부담이 늘어날 것은 당연할 것이다.
이러한 이유 때문에 고안되었다고 한다
주요 목표 및 기능
- 전체 요청을 통한 지연 시간 최소화
- 응답 다중화
- HTTP 헤더 필드의 효율적 압축 (프로토콜의 오버헤드를 최소화)
- 요청 우선 순위 지정이 가능하다
- 서버 푸시를 지원한다. (필요한 리소스를 미리 푸시하여, 응답 시간을 최소화 한다.)
기존 HTTP 1.1 메시지는 평문(Plain Text)을 사용하고, 개행을 통해 본문과 헤더를 구분 하였다면, HTTP2에서는 바이너리 포맷으로 인코딩 된 메시지와 프레임으로 구성 된다.
- 프레이밍 작업은 서버 혹은 클라이언트(브라우저) 단에서 이루어 지기 때문에, 큰 변경사항은 고려하지 않아도 된다.
- 바이너리 프레이밍, 멀티 플렉싱을 통해 연결을 여러개 맺지 않고도 병렬 처리가 가능하다 (기존 HOL 문제 해결)
- HOL (Head of line) 이란 ?
- 파이프 라이닝의 문제
- 먼저 받은 요청이 끝나지 않으면, 작업이 이루어지지 않는다.
- 모던 브라우저는 파이프라이닝의 사용을 막아 두었다.
- 여러개의 커넥션을 통해 데이터를 가져오는 방식으로 성능을 개선하고 있다.
스트림, 메시지 및 프레임
새로운 바이너리 프레이밍이 도입됨에 따른 클라이언트와 서버 간의 데이터 교환 방식이 바뀌었다.
- 스트림
- 구성 된 연결 내에서 전달되는 바이트는 양방향의 흐름, 하나 이상의 메시지 전달이 가능하다
- 메시지
- 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스 (집합)
- 프레임
HTTP2에서 통신의 최소 단위, 각각의 단위에는 하나의 프레임 헤더가 포함 된다. 프레임 헤더는 최소한으로 어떤 스트림에 속하는 프레임인지 식별을 가능케 한다.
요청 및 응답 다중화
HTTP/1.x에서는 클라이언트가 병렬 요청을 하려는 경우, 여러개의 TCP 연결이 이루어져야 한다.
여기서 생길 수 있는 문제점들을 나열해보면,
- 연결당 한번에 하나의 응답
- 기본 TCP 연결의 비효율적 사용을 초래
반면 HTTP/2에서는 이러한 제한을 없애고, 전체 요청 및 응답 다중화를 지원 한다. 클라이언트와 서버가 HTTP 메시지를 독립 된 프레임으로 세분화 하고, 인터리빙 하여, 다른 쪽에서 다시 조립을 하도록 허용한다.
- 여러 요청을 병렬로 인터리빙 할 수 있다.
- 여러 응답을 병렬로 인터리빙 할 수 있다.
- 단일 연결을 통해서도 여러 요청과 응답을 병렬로 전달 할 수 있다.
따라서 HTTP/2의 바이너리 프레이밍 계층을 사용함으로써 볼 수 있는 효과는,
- HOL 차단 해결
- 여러개의 연결이 없어도 요청 및 병렬 처리가 가능해진다는 점
- 애플리케이션이 더 빠르고 단순해지며, 배포 비용 절감의 효과
스트림 우선순위 지정
HTTP 메시지가 많은 개별 프레임으로 분할과, 여러 스트림의 프레임을 다중화 하는 것이 가능해짐에 따라 전달 순서 또한 중요한 성능 고려사항이 되었다.
이를 용이하게 하기 위해 HTTP/2 표준에서는 각 스트림이 연관된 가중치와 종속성을 갖도록 허용하고 있다.
- 각 스트림에 1 ~ 256 사이 정수 가중치가 할당 될 수 있다.
- 각 스트림에 다른 스트림에 대한 명시적 종속성이 부여 될 수 있다.
스트림의 종속성 및 가중치를 조합하여 우선순위 지정 트리 를 구성하여 통신 할 수 있다. 이 트리가 나타내는 것은 클라이언트가 선호하는 응답 수신 방식을 나타낸다.
이후 서버가 이 정보를 통해 CPU, 메모리 및 기타 리소스의 할당을 제어함으로써 스트림 처리의 우선순위를 지정한다.
응답 데이터가 있는 경우, 서버는 우선순위가 높은 응답이 클라이언트에 최적으로 전달되도록 대역폭을 할당한다.
출처당 하나의 연결
바이너리 프레이밍 메커니즘이 적용되면, 여러개의 TCP 연결이 필요없어진다.
모든 HTTP/2 연결은 영구적이고 출처당 하나의 연결만 필요하게 된다.
HTTP 전송은 수명이 짧고 폭주하는 반면 TCP는 수명이 긴 대량 데이터 전송에 최적화되어 있다.
HTTP/2에서는 동일한 연결을 재사용하여 각 TCP 연결을 더 효율적으로 사용할 수 있으며 또한 전반적인 프로토콜 오버헤드를 대폭 줄일 수 있다.
또한 더 적은 수의 연결을 사용하므로 클라이언트나 서버의 메모리 부담이 더 줄게 될 것이다.
그에 따라 전체적인 웹 애플리케이션 운영 비용이 절감되는 효과를 볼 수 있다.
커넥션의 수가 적다보니, HTTPS 배포 성능의 개선에도 특히 도움이 된다.
커넥션 수가 적으면 값비싼 TLS 핸드셰이킹이 줄고, 세션 재사용률이 향상되며 클라이언트나 서버의 리소스가 감소한다.
서버 푸시
HTTP/2의 또 다른 강력한 기능.
서버는 단일 클라이언트의 요청에 대해 여러 응답을 보낼 수 있다. 즉, 서버는 원래 요청에 대한 응답 뿐만이 아닌 서버가 추가적인 리소스를 클라이언트에 푸시 할 수 있다.
예시로 어떤 페이지 요청시 js, css, 이미지 파일등을 서버가 미리 푸시해 줄 수 있다. 서버가 필요한 리소스를 이미 파악하고 있으며 이를 바로 전송해준다.
헤더 압축
HTTP 전송에서는 전송되는 리소스와 그를 설명해주는 헤더를 전달한다.
HTTP/1.x의 경우 이 메타데이터는 항상 일반 텍스트로 전송되고, 전송당 500~800바이트의 오버헤드가 추가되며, HTTP 쿠키를 사용할 경우 수 KB가 추가되기도 한다.
이 오버헤드를 줄이고 성능을 개선하기 위해 HTTP/2에서는 HPACK 압축 형식을 사용하여 요청 및 응답 헤더 메타데이터를 압축한다.
위의 내용들 보다 좀 더 자세한 내용과 설명이 필요하다면,
https://developers.google.com/web/fundamentals/performance/http2?hl=ko
를 참고해 보길 바란다.
아주 자세하게 잘 정리 되어 있다 !
