✍ HTTP/2

HTTP/2는 2015년에 발표된 새로운 HTTP 프로토콜이며 2020년 기준 가장 많이 쓰이는 프로토콜이다. 이전의 HTTP 1.1과는 다르게 데이터 전송 방식이 개선되어 웹 페이지 로딩 시간이 단축되고, 보안성도 향상되는 등 다양한 기능이 추가되었습니다.

📝 HTTP/2의 특징

HTTP/2가 HTTP 1.X번의 버전보다 어떤 점이 나아졌고 어떤 기술들이 새로 접목되었는지 살펴보자.

✏️ 멀티플렉싱 (다중화)

멀티플렉싱은 여러 개의 데이터 스트림을 하나의 TCP 연결에서 동시에 처리할 수 있는 기술입니다. 이전 버전에서는 하나의 요청에 대한 응답이 완료될 때까지 다른 요청을 처리할 수 없었기 때문에, 다수의 요청이 동시에 이루어지는 경우 대기 시간이 발생하거나 네트워크 병목 현상이 발생할 수 있었습니다 (HOL BLOCKING).

=> 쉽게 말하자면, 자바스크립트에서 함수를 비동기적으로 처리하는 것과 비슷한 개념이라고 생각하면 된다.

단순히 멀티플렉싱 기술을 사용했다고 넘어가기엔 멀티플렉싱 기술은 간단하지 않고 다양한 방버이 있기에 이번 게시글에서는 간단히 어떤 멀티플렉싱 기술들이 있고 HTTP2/에는 그 중 어떤 기술이 사용되었는지만 살펴보자.

1. FDM (Frequency Division Multiplexing): 여러 개의 신호를 서로 다른 주파수 대역으로 분할하여 전송하는 방식입니다. 즉, 주파수를 기준으로 신호를 구분합니다.

2. TDM (Time Division Multiplexing): 여러 개의 신호를 시간 단위로 쪼개서 교대로 전송하는 방식입니다. 즉, 시간을 기준으로 신호를 구분합니다.

3. CDM (Code Division Multiplexing): 여러 개의 신호를 서로 다른 코드로 구분하여 전송하는 방식입니다. 즉, 코드를 기준으로 신호를 구분합니다.

4. WDM (Wavelength Division Multiplexing): 여러 개의 신호를 서로 다른 파장으로 분할하여 전송하는 방식입니다. 즉, 파장을 기준으로 신호를 구분합니다.

HTTP/2는 이 4가지 멀티플렉싱 기술 중 TDM과 WDM을 사용합니다. TDM은 시간을 기준으로 데이터를 분할하고 전송하는 방식이며, WDM은 파장을 기준으로 데이터를 분할하고 전송하는 방식입니다. 이 두 가지 기술을 조합하여 HTTP/2는 멀티플렉싱을 구현합니다.

✏️ 헤더 압축

기존 HTTP 1.X 버전에서는 헤더의 크기가 크다는 점이 문제로 있었다. 헤더의 크기가 커지게 되면 다음과 같은 문제가 발생하게 됩니다.

1. 헤더의 크기가 크다면 요청과 응답 메시지 전송에 소요되는 대역폭이 증가하는데 이는 네트워크 지연 및 메시지 처리 속도가 늦어지는 원인이 될 수 있습니다.

2. HTTP/1.1에서는 하나의 도메인에서 여러 개의 리소스를 요청할 때, 매번 도메인 이름을 포함한 헤더 정보를 함께 전송하는데 이러한 요청은 캐시 불가능(caching-ineligible)하며, 불필요한 데이터 전송이 발생하게 됩니다.

기술이 발전하면서 이러한 문제는 HTTP/2의 헤더 압축이라는 기술로 인해 해소가 되었다.

헤더 압축은 헤더 정보를 인코딩하여 전송하고, 수신 측에서 디코딩하여 원래의 헤더 정보를 추출하는 방식으로 동작합니다. 이를 통해 네트워크 대역폭을 절약하고, 전송 속도를 높일 수 있습니다.

헤더 압축을 하는 방식으로는 허프만 코딩 압축 알고리즘을 사용하는데 간단하게 짚고 넘어가보자면 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리이다.

✏️ Server Push (서버 푸시)

이전 HTTP/1.x에서는 클라이언트의 요청에 따라 서버가 응답을 보내는 방식으로 진행되었는데 이 방식은 클라이언트의 요청에 대한 응답만을 보내기 때문에, 필요한 리소스가 클라이언트에게 전달되지 않을 수 있고, 추가적인 요청이 필요한 상황이 다수 발생하게 되었다. 또한, 클라이언트가 리소스를 요청하면서 발생하는 지연 시간도 문제가 되었기 때문에 이를 해결하기 위해 새로운 방식인 Server Push가 등장하게 되었다.

서버 푸시란, 클라이언트의 요청에 대한 응답으로 요청한 리소스 이외에도 클라이언트가 아직 요청하지 않은 리소스를 미리 전송하는 것을 뜻한다.

서버 푸시로 인해 여러가지 사항들이 개선되었는데 간단하게 알아보자

1. 대기 시간 감소: 서버 푸시를 통해 서버는 클라이언트의 요청을 기다리지 않고 사전에 리소스를 클라이언트에 보낼 수 있게 되었고, 페이지를 표시하는 데 필요한 리소스를 클라이언트에서 이미 사용할 수 있으므로 웹 페이지 로드 대기 시간 또한 크게 줄 일 수 있게 되었습니다.

2. 요청/응답 싸이클 감소: 서버 푸시가 없으면 클라이언트는 각 리소스를 개별적으로 요청해야 하므로 서버로 요청과 응답 싸이클을 여러 번 왕복해야 하지만 서버 푸시를 사용하면 서버가 단일 요청으로 여러 리소스를 보낼 수 있으므로 페이지를 로드하는 데 필요한 왕복 횟수가 줄어듭니다.

3. 성능 향상: 서버 푸시는 페이지를 로드하는 데 필요한 요청 수를 줄이고 각 리소스를 로드하는 데 필요한 시간을 줄임으로써 웹 사이트의 전반적인 성능을 향상시킬 수 있습니다.

4. 더 나은 리소스 우선 순위 지정: 서버 푸시를 사용하면 서버는 클라이언트에 먼저 보내야 하는 리소스의 우선 순위를 지정하여 가장 중요한 리소스를 클라이언트에서 최대한 빨리 사용할 수 있도록 합니다.

2023년 3월 기준 아직까지 대중적으로는 HTTP2의 사용도가 많은 것으로 나와있지만 점점 감소하는 추세이고 HTTP3/은 성장세를 미세하게 보이고 있다.

📝 HTTP/2의 문제점

1. 호환성: 모든 웹 서버와 클라이언트가 HTTP/2와 완전히 호환되는 것은 아닙니다. 이전 시스템 및 응용 프로그램은 이를 지원하지 않을 수 있으므로 채택이 제한될 수 있습니다.

2. 복잡성: HTTP/2의 구현은 HTTP/1.1보다 복잡할 수 있으므로 개발자가 작업하기가 더 어려울 수 있습니다.

3. 자원 사용: HTTP/2의 멀티플렉싱 기능은 특히 동시 요청 수가 많은 트래픽이 많은 사이트에서 자원 집약적일 수 있습니다. 이로 인해 메모리 및 CPU 사용량이 증가하고 병목 현상이 발생할 수 있습니다.

4. TLS 종속성: HTTP/2는 보안을 위해 TLS(HTTPS) 암호화를 사용해야 하므로 구현에 추가 오버헤드와 복잡성이 추가될 수 있습니다.

5. 중개자 문제: 프록시 및 방화벽과 같은 일부 중개자는 HTTP/2를 완전히 지원하지 않거나 호환되지 않을 수 있으며 이로 인해 성능, 안정성 및 보안 문제가 발생할 수 있습니다.

✍ HTTP/3

HTTP/3는 2020년 9월에 출시하였으며 웹 통신의 성능과 보안을 개선하도록 설계된 최신 버전의 HTTP입니다. HTTP/2의 후속 제품이며 Google에서 개발한 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 합니다.

=> 여기서 QUIC(QUICK UDP INTERNET CONNECTIONS)이란 HTTP/1 및 HTTP/2에서 사용하는 TCP(Transmission Control Protocol)보다 간단하고 빠른 프로토콜인 UDP(User Datagram Protocol)를 기반으로 합니다. QUIC는 암호화, 병목 현상 제어 및 패킷 재전송과 같은 UDP 연결의 안정성과 보안을 개선하기 위해 기능 조합을 사용합니다.

📝 HTTP/3의 특징

1. 전송 프로토콜: HTTP/3는 대기 시간을 줄이고 보안을 개선하도록 설계된 QUIC(빠른 UDP 인터넷 연결) 전송 프로토콜을 사용합니다.

2. UDP 기반: TCP 프로토콜을 기반으로 하는 HTTP/1 및 HTTP/2와 달리 HTTP/3은 UDP(User Datagram Protocol)를 기반으로 합니다. 이를 통해 더 빠른 연결 설정이 가능하고 HOL(head-of-line) 차단 위험이 줄어듭니다.

3. 멀티플렉싱(다중화_: HTTP/3은 HTTP/2와 유사한 다중화 접근 방식을 사용하여 단일 연결을 통해 여러 요청을 보낼 수 있습니다. 그러나 QUIC의 스트림 및 패킷 레벨 멀티플렉싱으로 인해 구현이 더 효율적입니다.

4. 연결 마이그레이션: HTTP/3에서는 진행 중인 요청을 방해하지 않고 하나의 IP 주소 또는 네트워크 경로에서 다른 연결로 마이그레이션하는 것이 가능합니다.

5. 향상된 보안: HTTP/3는 내장 암호화를 사용하고 클라이언트가 연결 즉시 요청을 보낼 수 있도록 하는 0-RTT(Zero Round Trip Time) 재개와 같은 보안 기능을 포함합니다.

6. 서버 푸시: HTTP/2와 마찬가지로 HTTP/3은 서버 푸시를 지원하여 서버가 요청을 기다리지 않고 클라이언트에 리소스를 보낼 수 있습니다.

사실 3.0부터는 아직까진 나에게는 미지의 영역이라는 생각이 든다. 그렇기에 개념적으로 우선 특징들만 파악해보고 직접 회사에 입사해 서비스를 런칭 그리고 운영해보면서 자세히 알아가고 싶다.