[Network] HTTP1.1, HTTP2.0, HTTP3.0의 차이점

ㅁ 들어가며

  인터넷을 통해 연결되는 수많은 디바이스들이 있다. 웹서비스를 비롯하여 많은 IOT 기기들을 연결하기 위해 클라이언트와 서버는 수많은 통신을 해야한다. 회사 동료와 HTTP2에 대해서 이야기 나누면서 HTTP1.1의 한계성과 HTTP2의 multiplexing 개념을 알게 되었다. 그리고 HTTP2는 과연 비동기 통신라고 말할 수 있을 지 함께 고민했었다. 그래서 이를 글로 정리하면서 HTTP3에 대해서도 알게 되어 함께 정리하였다.

 

ㅁ 성능 개선의 필요성

 HTTP(Hypertext Transfer Protocol)는 웹에서 클라이언트와 서버 간의 통신을 위한 핵심 프로토콜이다. HTTP1.1은 1997년에 도입되어 오랫동안 사용되었지만, 웹의 복잡성이 증가함에 따라 한계점이 드러났다. 이 시기에는 모뎀을 사용하였고, 네트워크 전송 속도가 빠르지 않았다. 그래서 네트워크 자원이 한정되어 있었기 때문에 HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화하였다. 이를 개선하기 위해 2015년 HTTP2.0이 등장했다.

 

ㅁ Multiplexed Streams

https://jaehoney.tistory.com/281

HTTP1.1에서는 하나의 TCP 연결로 한 번에 하나의 요청만 처리할 수 있었다. 이로 인해 여러 리소스를 동시에 요청할 때 성능 저하가 발생했다.

HTTP2.0은 이 문제를 해결하기 위해 multiplexing을 도입했다. 하나의 TCP 연결로 여러 요청을 동시에 처리할 수 있게 되어, 네트워크 효율성이 크게 향상되었다.

 

ㅁ Binary Protocol

  HTTP1.1은 텍스트 기반 프로토콜이었지만, HTTP2.0은 바이너리 프로토콜을 사용한다. 이는 데이터 파싱과 전송 속도를 개선하고 오류 발생 가능성을 줄인다.

 

ㅁ Header Compression(변경되는 값만 전송)

  HTTP2.0은 HPACK이라는 헤더 압축 방식을 사용한다. 이 방식은 중복되는 헤더 필드를 제거하고, 변경되는 값만 전송함으로써 오버헤드를 줄인다. 이 방식은 중복되는 헤더 필드는 인덱스만 전송하고, 변경되는 값은 Huffman 인코딩을 사용하여 압축한 후 전송한다. 이를 통해 헤더 크기를 크게 줄일 수 있다

 

ㅁ Server Push

  HTTP2.0에서는 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 보낼 수 있다. 이를 통해 클라이언트의 요청 횟수를 줄이고 페이지 로드 시간을 단축할 수 있다.

 

ㅁ 연결 관리

HTTP1.1에서는 여러 리소스를 요청할 때 각각의 요청에 대해 새로운 TCP 연결을 생성했다. 이는 불필요한 오버헤드를 발생시키고 성능을 저하시켰다.

HTTP2.0은 하나의 TCP 연결 내에서 여러 스트림을 사용하여 다중화된 요청과 응답을 처리한다. 이를 통해 연결 설정에 따른 지연을 줄이고 네트워크 리소스를 효율적으로 사용할 수 있게 되었다.

 

ㅁ HOL블로킹이란?

HTTP1.1에서는 하나의 TCP 연결에서 여러 요청을 순차적으로 처리해야 했다. 이로 인해 앞선 요청의 처리가 지연되면 뒤따르는 모든 요청이 블로킹되는 HOL(Head-of-Line)블로킹 문제가 발생했다.

HTTP2.0은 스트림 다중화를 통해 HOL 블로킹 문제를 해결했다. 여러 요청을 병렬로 처리할 수 있게 되어, 특정 요청의 지연이 다른 요청에 영향을 미치지 않게 되었다.

ㅁ 우선순위 지정

HTTP1.1 에서는 서버가 클라이언트의 요청이 없는 리소스를 전송할 수가 없었다.

HTTP2.0에서는 스트림에 우선순위를 부여할 수 있다. 이를 통해 중요한 리소스를 먼저 처리하고, 클라이언트에게 전달할 수 있다. 예를 들어, HTML 문서나 CSS 파일과 같은 중요한 리소스에 높은 우선순위를 부여하여 페이지 렌더링 속도를 향상시킬 수 있다. 

   index.html을 요청하면 페이지에 포함되어 있는 리소스 요청이 오기 전에 미리 푸시해서 불필요한 요청에 대한 오버헤드를 줄일 수 있다.

ㅁ 보안

HTTP2.0은 TLS(Transport Layer Security)를 기본적으로 사용하도록 설계되었다. 이는 모든 통신이 암호화되어 보안성이 향상됨을 의미한다. 반면 HTTP1.1은 기본적으로 암호화를 제공하지 않았으며, HTTPS를 통해 별도로 암호화를 구현해야 한다.

 

ㅁ Downchannel Stream과 HTTP2.0

Downchannel stream은 서버에서 클라이언트로의 단방향 통신 채널을 의미한다. HTTP2.0의 Server Push 기능과 밀접한 관련이 있다.

HTTP2.0에서 서버는 클라이언트의 요청 없이도 리소스를 미리 전송할 수 있다. 이때 서버는 downchannel stream을 통해 클라이언트에게 리소스를 푸시한다. 이 기능은 웹 애플리케이션의 성능을 크게 향상시킬 수 있다.

예를 들어, 클라이언트가 HTML 페이지를 요청했을 때, 서버는 해당 페이지에 필요한 CSS, JavaScript, 이미지 파일 등을 미리 파악하고 downchannel stream을 통해 클라이언트에게 전송할 수 있다. 이로 인해 클라이언트는 추가적인 요청 없이 필요한 리소스를 즉시 사용할 수 있게 되어 페이지 로딩 시간이 단축된다.

Downchannel stream은 HTTP2.0의 양방향 통신 기능을 활용한 것으로, 실시간 업데이트나 서버 이벤트 알림 등에도 활용될 수 있다. 이는 웹 애플리케이션의 반응성과 사용자 경험을 크게 개선할 수 있는 중요한 기능이다.

  Kakao AI Service Agent에서는 다양한 Device의 인공지능을 서비스를 제공하기 위해, Event Channel과 Down Channel은 HTTP/2를 통해 하나의 물리적 연결을 맺으며, 한 개의 통신 채널을 통해서 둘 이상의 데이터를 전송하는데 사용되는 기술인 Multiplexing(멀티플렉싱)을 이용하고 있다.

 

ㅁ HTTP2.0는 비동기 처리인가?

  문득 HTTP2.0는 비동기처리 방식과 비슷한 점이 많았다. 하지만 HTTP는 사실 모두 동기다. 로직상 비동기처럼 보이지만 결국 요청에 대한 응답을 받아 처리한다. 

 

ㅇ 멀티플렉싱이지만 TCP

 단일 TCP 연결 내에서 여러 요청과 응답을 동시에 처리할 수 있는 멀티플렉싱은 비동기처리처럼 보이지만, TCP 통신이기 때문에 제어권은 유지되어 있는 상태이다.

기존의 요청메세지를 작은 프레임으로 쪼개, 하나의 논리적인 스트림(요청하고 응답하는 하나의 데이터 양방향 흐름)을 여러개의 프레임으로 분리 시켰다. 위 그림에서 스트림 1,3,5 총 3개의 스트림이 동시에 병렬적으로 하나의 연결안에서 이루어지는 것을 알 수 있다. 이로써 응답 다중화 (멀티플렉싱)을 가능하게 하고 위에서 언급 되었던 HOL block 문제를 해결 할 수 있다.

 

 ㅇ 스트림

  HTTP2.0은 요청과 응답을 스트림 단위로 처리하여 병렬처리가 가능하기 때문에 다른 요청의 지연이 다른 요청에 영향을 주지 않는다.

 

ㅇ 서버 푸시

   클라이언트의 요청 없이도 서버가 리소스를 보낼 수 있다. 불필요한 요청 없이 속도는 빠르지만, 비동기 통신도 엄연히 요청이 있어야 한다. 

 

  HTTP2.0은 여전히 요청-응답 모델을 기반으로 하며, 완전한 비동기 프로토콜은 아니다. 대신 동기식 프로토콜을 효율적으로 사용하여 비동기와 유사한 효과를 얻는 다고 생각한다. 다시 말해 비동기 통신처럼 성능을 크게 향상시키지만 비동기 통신의 완전 조건을 가지지 않는다. 비동기라면 제어권이 넘어간 상태인 UDP 통신이 더 맞을 것이다.

 

ㅁ HTTP3.0

 QUIC은 UDP를 채택해 TCP의 성능을 개선하려는 기술이다. TCP는 오래된 프로토콜로 성능보다는 기능에 초점이 맞춰져 있었다. 구글은 TCP의 한계를 극복하고 최적화하기 위해 QUIC(Quick UDP Internet Connections) 기반의 HTTP/3을 고안했다. QUIC은 UDP를 채택해 TCP의 성능을 개선하려는 기술이다. 전달 속도의 향상과 더불어 클라이언트와 서버의 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 QUIC의 주요 특징이다.

 

ㅁ 마무리

  HTTP2.0은 HTTP1.1의 한계를 극복하고 현대 웹의 요구사항에 맞춰 설계된 프로토콜이다.네트워크 자원이 확장되고, 전송 속도도 빨라지면서 인터넷 트래픽은 더 많아지고, 빨라져야만 했다. 멀티플렉싱, 헤더 압축, 서버 푸시 등의 기능을 통해 웹 성능을 크게 향상시켰다. 또한 downchannel stream을 활용한 서버 푸시 기능은 웹 애플리케이션의 효율성을 한층 더 높였다.

  그러나 HTTP2.0도 완벽한 해결책은 아니다. TCP 기반의 프로토콜이기 때문에 여전히 네트워크 지연 문제에서 자유롭지 못하다고 생각한다. 이를 해결하기 위해 UDP 기반의 HTTP3.0이 개발되고 있으며, 이는 더욱 빠르고 안정적인 웹 경험을 제공할 것으로 기대된다. 

  웹 개발자와 DevOps 엔지니어는 이러한 프로토콜의 변화를 이해하고, 적절히 활용함으로써 더 나은 웹 서비스를 제공할 수 있을 것이다. 상화엥 따라 HTTP2.0와 HTTP3.0 도입을 고려할 줄 알아야겠다.

 

ㅁ 함께 보면 좋은 사이트

ㅇ https://www.youtube.com/watch?v=UMwQjFzTQXw

 

ㅇ HTTP 0.9에서 HTTP 3.0까지

ㅇ HTTP/3와 QUIC 요약정리

ㅇ HTTP/1.1과 HTTP/2.0, 그리고 간단한 HTTP/3.0

ㅇ [FE] HTTP/2 - HyperText Transfer Protocol (Version 2) 을 자세히 알아보자
ㅇ Network - HTTP 1.1과 HTTP 2.0의 차이