HTTP/1.1 과 HTTP/2 의 차이점

이번 포스팅의 주제는 HTTP /1.1과 HTTP/2의 차이점에 대해 중점적으로 다뤄 보려고 합니다.

둘의 차이점을 정리하기 전에 HTTP/2로 발전의 필요성에 대해 먼저 언급하고 가겠습니다.

1. Latency(지연 시간) 감소
2. 네트워크 통신에 필요한 데이터량 감소
3. 서버에서 클라이언트로 먼저 데이터를 보낼 수 있는 방법

HTTP/1.1 에서 HTTP/2 로이 발전하게 된 요인들은 위에서 언급한 것처럼 3가지 가 있습니다. HTTP/1.1 에서는 어떤 문제점이 있었고 HTTP/2는 어떻게 이 문제를 해결했는지에 대해서 이제부터 정리해 보겠습니다.

HTTP/1.1

HTTP/1.x 의 가장 큰 특징은 하나의 연결당 한개의 응답만 보낼 수 있도록 설계되어 있다는 것입니다.

HTTP/1.x의 이런 특징 때문에 성능 저하, 비효율성 의 문제가 생겼습니다.

기본적으로 http는 TCP 연결 기반 위에서 동작하는 프로토콜입니다. 때문에 신뢰성 확보를 위해 연결을 맺고 끊는 데 있어서 "Hand Shake"가 이뤄 집니다.

또한 HTTP는 기본적으로 비연결성 프로토콜 이기 때문에 한 번 연결로 한 번의 요청과 응답을 하고 응답이 끝나면 연결을 끊어 버립니다. 이는 곧 성능 저하로 이어지는데, HTTP의 특성 때문에 한 번의 연결을 맺고 끊을 때마다 매번 핸드 셰이크를 하기 대문에 비연결성 프로토콜에서는 오버헤드가 발생 하게 됩니다.

그래서 HTTP/1.1에서는 이런 문제에 대한 설루션으로 "Keep Alive" 기능이 추가 되어 한 번 맺었던 연결을 끊지 않고 지속적으로 유지하여 불필요한 핸드 셰이크를 줄여 성능을 줄일 수 있게 되었습니다.

또한 현대의 웹 서비스 들은 Plain Text보다 점점 미디어들이 추가 되고 상태(쿠키, 세션)등을 유지하려는 기술들이 요구되다 보니 성능 개선이 반드시 필요하게 되었습니다.

HTTP/1.1에서 성능 개선을 위해 추가적으로 "파이프라이닝" 기술을 도입 했습니다. 이는 하나의 커넥션(연결)에 연속적으로 요청을 보내고 순차적으로 응답을 받는 방식으로 지연시간을 줄이는 방법입니다.

하지만 파이프라이닝에는 치명적인 단점이 존재하는데, 순차적으로 데이터를 요청하고 받아야 하다 보니 선 요청이 끝나지 않으면 그 뒤에 있는 요청의 처리가 빨리 끝나도 먼저 온 요청이 끝날 때까지 기다려야 하는 문제가 발생합니다. 이를 "HOL(Head of Line) Blocking" 이라고 합니다. 때문에 현대의 브라우저는 파이프라이닝을 사용하지 못하도록 막아 놓았습니다.

그래서 HTTP/1.1에선 클라이언트가 요청을 병렬로 하기 위해서는 다수의 커넥션을 두고 데이터를 가져오는 방식으로 성능을 개선했습니다.

HTTP/2

HTTP/1.1에서 다중 병렬 처리(여러 개의 응답 처리)를 하기 위해서는 여러 개의 TCP 연결을 생성해야 만 했습니다.
왜냐하면 http/1.x의 delivery model의 특징인 "하나의 연결당 한개의 응답만 보낼 수 있도록 설계" 했기 때문입니다.

이는 연결 지향형 TCP를 효율적으로 사용한 방법이 아니었기 때문에 개선의 필요성을 느끼게 되었습니다.

HTTP/2에서는 이런 문제를 해결하고자 바이너리 프레이밍 계층(binary framing layer)을 추가했습니다. 이 새로운 바이너리 프레이밍 계층은 (1) http 메시지를 독립적인 개별 프레임으로 나누고 (2) 이들을 상호 배치해 (3) 목적지에 도착했을 때 재조립하는 방식입니다.

1. Multiplexing

먼저 구체적인 바이너리 프레이밍 계층의 방법에 대해 정리 하기 전에 개념에 대한 정리를 하겠습니다.

스트림(Stream) : 생성된 하나의 커넥션에 대한 양방향 흐름, 하나의 스트림에 한 개 이상의 요청/응답 메시지가 오갈 수 있다.

메시지 : 논리적 요청/응답 메시지에 매칭되는 프레임의 시퀀스, 각 메시지는 프레임을 붙여 전달됨.

프레임 : 커뮤니케이션 단위중 가장 작은 단위

 

기존 레이어 구조와 새로 추가된 Binary Framing Layey, 기존 http/1.1은 plain tex에 헤더와 바디를 나누는 기준이 모호했지만 http/2는 이런 방식을 버리고 헤더와 데이터 부분을 프레임이라는 단위로 묶었다. 

 

하나의 스트림 안에 한 개 이상의 요청/응답 메시지가 오갈 수 있고, 각 메시지는 프로임 단위로 붙어 상대방측으로 전달된다.

바이너리 프레이밍 계층에서는 HTTP 메시지(요청 / 응답) 들을 프레임 단위로 잘라서 전송하고
이 프레임들을 특정 스트림에 속하는 메시지와 연결합니다.

이 모든 프로세서는 한 개의 TCP 커넥션 상에서 발생하는 데 이를 "Multiplexing"이라고 합니다.


2. 헤더 압축

Http/1.1 에선 헤더가 Plain Text(순서 문자형 데이터)였습니다. 즉, 사람이 그냥 눈으로 읽을 수 있는 글자들이었는데 이 Text의 헤더의 용량은 매 요청마다 약 500~ 800 바이트 정도가 된다고 합니다. 여기에 만약 상태(쿠키 / 세션) 등이 더 있다면 KB 단위로 증가할 정도로 사이즈가 컸습니다. 웹이 점점 발전할수록 서버에 요청하는 건수는 많아지고, 때문에 이 무거운 헤더들이 점점 더 큰 부담으로 다가올 수밖에 없던 것이죠.

HTTP는 이러한 큰 헤더의 용량 문제를 해결 하기 위해 "헤더 압축 (Header Compress) 하는 방식을 도입했습니다. HTTP/2 에선 HPACK이라는 압축 형식을 사용해서 요청 및 응답 데이터를 압축 합니다.


3. 서버 푸시

서버 푸시란 클라이언트의 요청이 한개 였음에도 불구하고 여러 개의 응답을 보낼 수 있는 서버의 기능을 뜻합니다.

그럼 이런 기능이 왜 필요한 걸까요??

그것은 "효율성" 때문입니다. 예를 들어 유저가 웹 사이트에 접속해 index.html이라는 파일을 받고 그 파일을 읽어 감에 따라 추가적으로 css, js 파일들이 필요하다면 그 추가 리소스에 대한 요청을 또 보내게 됩니다.

이런 비효율성의 문제를 해결하고자 서버는 "서버 푸시" 기능을 통해 추가로 더 필요한 리소스를 미리 응답으로 줌으로써, 불필요한 통신량을 미리 예방할 수 있게 됩니다.


정리하자면 HTTP/1.1의 문제를 해결하고자 HTTP/2와 다른 기능이 새로 추가 되었다고 정리할 수 있습니다.

1. Latency(지연 시간) 감소 => Multiplexing
2. 네트워크 통신에 필요한 데이터양 감소 => 헤더 압축
3. 서버에서 클라이언트로 먼저 데이터를 보낼 수 있는 방법 => 서버 푸시


참고 자료

https://seo-tory.tistory.com/82

HTTP/1.1 vs. HTTP/2

https://www.whatap.io/ko/blog/38/

HTTP/2 알아보기 - 1편 | 와탭 블로그