HTTP/2

HTTP/1.1은 1999년 표준화된 이후 웹의 근간을 이루어왔으나, 현대 웹 애플리케이션의 복잡성과 높은 성능 요구사항 앞에서 여러 구조적 한계를 드러냈다.

가장 큰 문제는 HOL 블로킹이다. HTTP/1.1은 기본적으로 하나의 TCP 연결 당 한 번에 하나의 요청과 응답만을 처리할 수 있다. 여러 자원을 병렬로 받기 위해 브라우저는 동일한 도메인에 대해 여러 개의 TCP 연결을 동시에 생성하는 방법을 사용했으나, 이는 연결 수에 제한이 있고 각 연결의 설정 및 유지에 따른 오버헤드가 크다. 또한, 하나의 연결에서 앞선 요청의 응답이 지연되면 뒤따르는 모든 요청이 대기해야 하는 현상이 발생하여 전체 페이지 로딩 시간이 길어졌다.

두 번째 한계는 비효율적인 헤더 전송 방식이다. HTTP/1.1은 텍스트 기반의 프로토콜로, 매 요청마다 반복되고 장황한 헤더 정보를 평문으로 전송한다. 특히 쿠키 정보가 포함되면 헤더의 크기가 크게 증가하며, 이는 매 요청마다 중복되어 네트워크 대역폭을 낭비하고 지연을 유발하는 주요 원인이 되었다.

세 번째로, 클라이언트 주도적인 통신 모델이 문제가 되었다. 서버는 클라이언트가 요청한 리소스만을 보낼 수 있으며, 클라이언트가 해당 리소스의 존재를 미리 알지 못하면 요청 자체를 할 수 없다. 이는 예를 들어, 서버가 HTML 문서를 분석한 후 해당 문서 렌더링에 필요한 CSS나 자바스크립트 파일을 클라이언트의 추가 요청 없이 미리 보낼 수 없음을 의미한다. 이로 인해 불필요한 왕복 지연이 발생한다.

이러한 한계들은 웹 페이지가 점점 더 많은 수의 리소스(이미지, 스크립트, 스타일시트 등)로 구성되면서 성능 병목 현상을 심화시켰고, 이를 해결하기 위한 다양한 우회 기술(도메인 샤딩, 이미지 스프라이트, 코드 압축 등)이 등장했으나 근본적인 해결책이 되지 못했다. 이러한 배경에서 HTTP/2는 프로토콜 자체의 구조적 개선을 통해 성능 문제를 근본적으로 해결하고자 설계되었다.

HTTP/2의 주요 설계 목표는 HTTP/1.1의 한계를 극복하여 웹 페이지 로딩 속도를 개선하고 네트워크 자원 사용 효율을 높이는 것이었다. 구체적인 성능 개선 목표는 다음과 같다.

첫 번째 목표는 지연 시간을 줄이는 것이었다. HTTP/1.1에서는 하나의 TCP 연결 당 한 번에 하나의 요청-응답만 처리할 수 있어, 여러 자원을 받기 위해선 순차적 요청이나 다수의 병렬 연결이 필요했다. 이로 인한 헤드 오브 라인 블로킹 문제가 지연을 유발했다. HTTP/2는 단일 연결 내에서 여러 요청과 응답을 동시에 처리할 수 있도록 하여 이 문제를 해결하고자 했다.

두 번째 목표는 프로토콜 오버헤드를 최소화하는 것이었다. 텍스트 기반의 HTTP/1.1과 달리 바이너리 프레이밍 계층을 도입하여 메시지를 파싱하고 전송하는 효율을 높였다. 또한, HPACK 알고리즘을 통한 헤더 압축을 의무화하여 반복되고 장황한 HTTP 헤더로 인한 오버헤드를 상당히 줄였다.

마지막으로, 서버가 클라이언트의 요청을 미리 예측하여 자원을 능동적으로 제공할 수 있는 서버 푸시 기능을 도입했다. 이는 클라이언트가 추가 요청을 보내기 전에 필요한 자원(예: CSS 파일, 자바스크립트 파일)을 먼저 전송함으로써 왕복 횟수를 줄이고 전체 로딩 시간을 단축하는 데 기여했다.

HTTP/2의 핵심 변화는 텍스트 기반의 HTTP/1.1 프로토콜을 바이너리(이진) 프로토콜로 전환한 데 있다. HTTP/1.1은 사람이 읽을 수 있는 텍스트 형식으로 메시지를 구성했지만, HTTP/2는 효율적인 기계 처리를 위해 설계된 바이너리 프레이밍 계층을 도입했다. 이 계층은 모든 통신을 더 작고 관리하기 쉬운 단위인 프레임으로 나누어 캡슐화한다.

바이너리 프레이밍은 프로토콜의 효율성과 강건성을 크게 향상시킨다. 텍스트 파싱은 모호성과 오류가 발생하기 쉬운 반면, 바이너리 형식의 프레임은 구문 분석이 빠르고 명확하다. 또한 프레임은 HTTP/2 연결 내에서 여러 요청과 응답이 뒤섞이는 다중화를 가능하게 하는 기본 단위가 된다. 각 프레임에는 해당 프레임이 속한 논리적 스트림을 식별하는 스트림 식별자가 포함되어 있어, 단일 TCP 연결을 통해 여러 스트림의 프레임이 인터리빙되어 전송될 수 있다.

다음은 HTTP/2에서 정의된 주요 프레임 유형의 예시이다.

이러한 구조적 변화로 인해 HTTP/2는 HTTP/1.1의 줄바꿈으로 구분된 텍스트 명령을 처리할 때 발생하던 성능 오버헤드와 보안 문제(예: 요청 스머글링)를 제거했다. 최종적으로 애플리케이션 계층에 보여지는 HTTP 세맨틱스(요청, 응답, 헤더, 본문 등)는 변경되지 않지만, 그 아래에서 데이터가 전송되는 방식은 근본적으로 달라졌다.

HTTP/2는 HTTP/1.1의 텍스트 기반 프로토콜에서 벗어나, 효율적인 전송을 위해 바이너리 프레이밍 계층을 도입했다. 이 계층은 통신의 기본 단위를 재정의하며, 스트림, 메시지, 프레임이라는 세 가지 핵심 개념으로 구성된다.

가장 작은 단위는 프레임이다. 프레임은 바이너리 형식으로 인코딩되며, 특정 유형의 정보를 담는다. 주요 프레임 유형은 다음과 같다.

이러한 프레임들이 모여 하나의 완전한 요청 또는 응답, 즉 메시지를 형성한다. 예를 들어, 하나의 HTTP 요청 메시지는 일반적으로 하나의 HEADERS 프레임과, 필요에 따라 여러 개의 DATA 프레임으로 구성된다.

스트림은 단일 TCP 연결 내에서 독립적인 양방향 통신 채널이다. 각 스트림은 고유한 식별자를 가지며, 하나 이상의 메시지를 교환하는 데 사용된다. 하나의 TCP 연결 안에는 여러 개의 스트림이 동시에 존재하고, 각 스트림의 프레임들은 인터리빙되어 전송된다. 이 구조가 요청/응답 다중화를 가능하게 하는 기반이 된다.

HTTP/1.1에서는 헤더 필드가 평문으로 반복적으로 전송되어 오버헤드가 컸다. 특히 웹 페이지 하나를 로드하는 데 수십에서 수백 개의 요청이 발생하는 현대 웹 환경에서, 중복된 헤더 데이터는 상당한 대역폭 낭비와 지연을 초래했다. HTTP/2는 이러한 비효율성을 해결하기 위해 HPACK이라는 헤더 압축 방식을 명세의 일부로 채택했다.

HPACK은 허프만 코딩과 정적/동적 테이블을 조합한 압축 방식이다. 자주 사용되는 헤더 필드(예: :method: GET, :path: /index.html)는 사전에 정의된 정적 테이블에 미리 등록되어 있다. 통신 과정에서 새롭게 등장하거나 변경된 헤더 필드는 동적 테이블에 추가되며, 이후 동일한 헤더는 테이블 내 인덱스 참조만으로 효율적으로 표현할 수 있다. 이 방식은 헤더의 중복을 제거하고 필드 이름과 값을 압축하여 전송 데이터 크기를 크게 줄인다.

HPACK은 보안 취약점으로 알려진 CRIME 공격에 대응하기 위해 설계되었다. 이전에 사용되던 DEFLATE 기반 압축은 선택적 평문 공격에 취약했으나, HPACK은 압축 컨텍스트를 송신자와 수신자 간에 명시적으로 동기화하고 허프만 코딩 테이블을 고정시킴으로써 이러한 공격 경로를 차단한다. 따라서 압축 효율을 유지하면서도 보안성을 강화한 것이 특징이다.

HPACK의 동작은 다음과 같은 원리로 요약된다.

1. 인덱싱: 헤더 필드를 정적 또는 동적 테이블의 인덱스 번호로 참조한다.

2. 리터럴 표현: 테이블에 없는 새로운 헤더는 허프만 인코딩된 리터럴 값으로 전송하며, 필요시 동적 테이블에 추가할 수 있다.

3. 테이블 관리: 동적 테이블의 크기는 제한되어 있으며, 새로운 항목이 추가될 때 가장 오래된 항목을 제거하는 FIFO 방식으로 관리된다.

이러한 설계로 인해 HTTP/2 연결에서는 동일한 헤더 필드가 반복될 경우 처음 한 번만 전송하고 이후에는 매우 작은 크기의 인덱스 참조로 대체할 수 있어, 특히 많은 수의 작은 요청을 처리할 때 네트워크 성능이 현저히 개선된다.

서버 푸시는 HTTP/2의 핵심 기능 중 하나로, 클라이언트의 요청을 기다리지 않고 서버가 능동적으로 리소스를 클라이언트에 전송할 수 있는 메커니즘이다. 이는 웹 페이지 로딩 성능을 개선하기 위해 설계되었다. 전통적인 HTTP/1.1에서는 클라이언트가 HTML 문서를 수신하고 파싱한 후, 필요한 CSS, JavaScript, 이미지 파일 등을 발견할 때마다 추가적인 요청을 보내야 했다. 서버 푸시는 이러한 추가 요청-응답 사이클을 사전에 제거함으로써 지연 시간을 줄인다.

동작 방식은 다음과 같다. 클라이언트가 주요 리소스(예: index.html)를 요청하면, 서버는 해당 요청에 대한 응답과 함께, 클라이언트가 향후 필요로 할 것으로 예상되는 추가 리소스(예: style.css, app.js)를 별도의 가상 "푸시된" 응답으로 함께 전송한다. 이때, 서버는 PUSH_PROMISE 프레임을 먼저 보내어 어떤 리소스를 푸시할 것인지 클라이언트에 알린다. 클라이언트는 이 푸시된 리소스를 자신의 캐시에 저장해 두고, 이후 실제로 해당 리소스가 필요해지면 캐시에서 즉시 사용할 수 있다.

서버 푸시를 효과적으로 활용하려면 신중한 전략이 필요하다. 과도하게 많은 리소스를 푸시하면 네트워크 대역폭을 낭비하고, 오히려 성능을 저하시킬 수 있다. 또한, 클라이언트가 이미 캐시에 가지고 있는 리소스를 중복으로 푸시하는 것을 방지해야 한다. 이를 위해 서버는 클라이언트의 캐시 상태를 고려하거나, 스마트한 휴리스틱을 적용하여 푸시할 리소스를 결정한다. 모든 주요 웹 브라우저와 서버는 이 기능을 지원하지만, 구현의 복잡성과 최적화의 어려움으로 인해 보편적으로 광범위하게 채택되지는 않았다.

이 기능은 HTTP/3에서도 개념적으로 계승되었으나, 구현 방식과 세부 사항은 프로토콜에 따라 다르다. 서버 푸시는 특히 높은 지연 시간(레이턴시)을 가진 네트워크 환경에서 페이지 로드 시간을 단축하는 데 잠재력이 큰 기술로 평가받는다.

HTTP/2의 요청/응답 다중화는 HTTP/1.1의 핵심적인 병목 현상을 해결하는 가장 중요한 기능 중 하나이다. 이 기능은 단일 TCP 연결 내에서 여러 개의 요청과 응답을 동시에 주고받을 수 있게 하여, HTTP/1.1의 순차적 처리 방식에서 발생하는 문제들을 극복한다.

HTTP/1.1에서는 기본적으로 하나의 연결에서 한 번에 하나의 요청과 응답만 처리할 수 있다. 여러 자원을 요청해야 할 경우, 파이프라이닝 기술이 존재했지만 헤드 오브 라인 블로킹 문제로 인해 실질적인 성능 향상이 제한적이었다[2]. 반면, HTTP/2의 다중화는 각 요청과 응답을 독립적인 스트림으로 분할하고, 이를 작은 단위의 프레임으로 쪼갠 뒤, 단일 연결 안에서 프레임들을 인터리빙하여 동시에 전송한다. 이로 인해 하나의 큰 응답이 지연되더라도 다른 스트림의 작은 응답들은 먼저 도착하여 처리될 수 있다.

이 메커니즘의 동작 방식은 다음과 같이 요약할 수 있다.

다중화의 주요 이점은 지연 시간 감소와 연결 효율성 향상이다. 웹 페이지는 일반적으로 HTML, CSS, 자바스크립트, 이미지 등 수십 개의 자원으로 구성된다. HTTP/1.1 환경에서는 이러한 자원을 병렬로 받기 위해 여러 개의 TCP 연결을 동시에 열어야 했지만, 이는 연결 설정 오버헤드와 운영체제 자원 소모를 초래했다. HTTP/2의 다중화는 하나의 영구 연결만으로 모든 자원을 효율적으로 전송할 수 있게 하여, 연결 수를 줄이면서도 실제 성능은 크게 향상시킨다.

ALPN은 TLS 핸드셰이크 과정 내에서 애플리케이션 계층 프로토콜을 협상하기 위한 확장 기능이다. 이전의 NPN을 대체하여 표준화되었다. 클라이언트가 지원하는 프로토콜 목록을 ClientHello 메시지에 포함하여 전송하면, 서버는 그 목록에서 선택한 프로토콜을 ServerHello 메시지에 담아 응답한다. 이 협상은 암호화된 연결이 수립되기 전에 완료되므로 별도의 통신 라운드트립이 필요하지 않다.

HTTP/2를 암호화된 연결(HTTPS) 위에서 사용할 때, ALPN은 프로토콜 업그레이드 메커니즘을 대체하는 핵심 수단이다. 이를 통해 클라이언트와 서버는 단일 핸드셰이크 내에서 암호화 파라미터와 함께 사용할 애플리케이션 프로토콜(예: http/1.1 또는 h2)을 효율적으로 결정한다. 이는 HTTP/1.1에서 Upgrade: h2c 헤더를 사용하는 평문 연결 업그레이드 방식보다 훨씬 효율적이다.

주요 브라우저와 서버 구현체는 대부분 HTTP/2 over TLS를 사용할 때 ALPN을 필수적으로 지원한다. ALPN 협상이 실패하면, 일반적으로 양측은 이전 버전인 HTTP/1.1으로 폴백하여 통신을 진행한다.

HTTP/2 명세 자체는 암호화 사용을 의무화하지 않는다. 그러나 주요 웹 브라우저와 서버 구현체들은 보안과 프라이버시를 강화하기 위해 TLS를 통한 암호화된 연결 위에서만 HTTP/2를 사용하는 방향으로 사실상의 표준을 정립했다.

이러한 경향은 주로 브라우저 벤더들에 의해 주도되었다. 구글 크롬과 모질라 파이어폭스는 초기부터 평문(HTTP) 연결에서의 HTTP/2 지원을 중단하고, TLS를 사용하는 HTTPS 연결에서만 HTTP/2를 지원하기로 결정했다[3]. 이로 인해 대중적인 웹 환경에서 HTTP/2는 TLS와 밀접하게 결합된 프로토콜로 인식되게 되었다.

이 관계는 HTTP/3에서 더욱 강화되어, QUIC 전송 프로토콜 자체에 TLS 1.3이 통합되었다. 결과적으로 현대 웹의 성능 프로토콜 진화는 보안을 전제 조건으로 삼고 진행되고 있다고 볼 수 있다.

스트림 우선순위 지정은 HTTP/2가 HTTP/1.1의 단순한 선입선출 방식에서 벗어나, 클라이언트가 서버에 여러 요청의 상대적 중요도를 알려줄 수 있게 하는 기능이다. 클라이언트는 각 스트림에 가중치(1부터 256 사이의 정수)와 종속성을 부여하여 응답이 전송되는 순서에 영향을 줄 수 있다.

이 메커니즘은 웹 페이지 로딩 성능을 최적화하는 데 목적이 있다. 예를 들어, 메인 HTML 문서는 높은 우선순위를, 이미지는 낮은 우선순위를 부여하여 사용자가 콘텐츠를 빠르게 볼 수 있도록 한다. 또는, 중요한 자바스크립트 파일이 먼저 로드된 후에야 다른 리소스가 필요하다면, 해당 파일을 부모 스트림으로 지정하고 다른 리소스를 그에 종속시킬 수 있다.

그러나 이 우선순위 힌트는 서버에 대한 '요청'일 뿐 반드시 지켜져야 하는 '명령'은 아니다. 서버는 자원 상황이나 내부 정책에 따라 우선순위를 재조정하거나 무시할 수도 있다. 이로 인해 클라이언트의 의도와 실제 서버의 응답 순서가 일치하지 않는 경우가 발생할 수 있다[5].

HTTP/2의 흐름 제어는 스트림과 전체 연결 수준에서 데이터 흐름을 관리하여 수신자의 처리 능력을 초과하는 데이터 전송을 방지하는 메커니즘이다. 이는 TCP의 흐름 제어와 유사한 개념이지만, 애플리케이션 계층에서 구현되어 더 세밀한 제어를 가능하게 한다. 각 스트림은 독립적인 흐름 제어 창을 가지며, 연결 자체에도 별도의 창이 존재한다.

흐름 제어는 WINDOW_UPDATE 프레임을 통해 동작한다. 수신자는 초기 창 크기를 설정하고, 데이터를 소비하면서 송신자에게 WINDOW_UPDATE 프레임을 보내어 추가 데이터를 수신할 수 있는 용량(창 크기)을 알린다. 이를 통해 리소스가 제한된 클라이언트가 대량의 데이터를 수신하도록 강제당하는 상황을 방지하고, 메모리 부족을 예방할 수 있다. 흐름 제어는 송신자가 수신자의 처리 속도를 따라가지 못하도록 방지하는 혼잡 제어와는 목적이 다르다.

흐름 제어 창의 크기는 설정에 따라 조정될 수 있다. 클라이언트와 서버는 SETTINGS 프레임을 교환하여 초기 흐름 제어 창 크기를 협상할 수 있다. 또한, 특정 스트림이나 전체 연결에 대해 WINDOW_UPDATE 프레임을 보내어 동적으로 창 크기를 증가시킬 수 있다. 이 메커니즘은 특히 서버 푸시 시나리오에서 유용하게 작동한다. 서버가 클라이언트가 요청하지 않은 리소스를 푸시하기 전에, 클라이언트의 수용 여부와 능력을 이 흐름 제어를 통해 확인할 수 있기 때문이다.

이러한 세분화된 흐름 제어는 HTTP/1.1의 선입선출(FIFO) 방식의 큐 모델에서는 제공할 수 없었던 기능이다. HTTP/1.1에서는 단일 연결 내에서 요청과 응답이 순차적으로 처리되기 때문에, 느린 응답 하나가 뒤따르는 모든 응답을 막는 Head-of-line 블로킹 문제가 발생할 수 있었다. HTTP/2의 흐름 제어는 다중화된 스트림 환경에서 각 데이터 흐름을 효율적으로 관리함으로써 이러한 문제를 완화하고 자원을 보다 공정하게 배분하는 데 기여한다.

HTTP/2는 2015년 표준화 이후 주요 웹 브라우저와 웹 서버 소프트웨어에서 빠르게 지원이 확산되었다. 초기에는 TLS 암호화를 필수로 요구하는 브라우저 구현이 있었으나, 이후 명세에 맞춰 비암호화 연결도 지원하게 되었다.

주요 브라우저의 HTTP/2 지원 현황은 다음과 같다.

서버 측에서는 Nginx가 1.9.5 버전(2015년)부터, 아파치 HTTP 서버가 2.4.17 버전(2015년)부터 공식 모듈을 통해 HTTP/2를 지원하기 시작했다. Node.js는 8.4.0 버전(2017년)부터 실험적 지원을, 10.0.0 버전부터 안정적으로 지원한다. 클라우드 플랫폼과 CDN 제공업체들도 대부분 2016년 전후로 서비스에 HTTP/2를 통합했다.

도입 시 고려사항으로는, TLS 인증서 설정이 필수는 아니지만 대부분의 최적화된 환경에서 암호화 연결을 사용한다는 점, 기존 HTTP/1.1 애플리케이션과의 호환성을 유지하면서 점진적으로 전환할 수 있다는 점, 그리고 서버 푸시와 같은 특정 기능의 구현과 활용 수준이 플랫폼에 따라 다를 수 있다는 점 등이 있다.

HTTP/2 도입은 대부분의 경우 성능 향상을 가져오지만, 특정 환경이나 구성에서는 주의 깊게 검토해야 할 사항이 존재합니다.

네트워크 환경과 프록시 서버의 호환성 문제가 주요 고려사항입니다. 특히 중간에 위치한 오래되거나 비준수적인 프록시가 바이너리 프레이밍을 처리하지 못하거나, 다중화된 스트림을 제대로 전달하지 못할 경우 연결 오류나 성능 저하를 초래할 수 있습니다. 이는 TLS 암호화를 사용할 때 더 두드러지는 문제입니다[6]. 서버 측에서는 HTTP/2를 지원하는 웹 서버 소프트웨어(예: Nginx, Apache)의 적절한 버전과 모듈 구성이 필요합니다.

애플리케이션 수준의 최적화 전략도 재평가해야 합니다. HTTP/1.1의 성능 한계를 극복하기 위해 널리 사용되던 도메인 샤딩, 이미지 스프라이트, 코드 합치기 등의 기법은 HTTP/2 환경에서는 불필요하거나 오히려 성능을 해칠 수 있습니다. 예를 들어, 불필요한 도메인 샤딩은 추가적인 TCP 연결 설정과 TLS 핸드셰이크를 유발하여 오버헤드를 증가시킵니다. 따라서 기존 최적화 기법의 효과를 측정하고 조정하는 작업이 수반되어야 합니다.