2 min. 읽기

HTTP/2: 최신 웹 성능에 대한 완벽한 가이드

하이퍼텍스트 전송 프로토콜은 처음부터 극적으로 발전해 왔으며, HTTP/2는 월드와이드웹에서 데이터를 전송하는 방식에 있어 가장 중요한 도약 중 하나입니다. 지난 몇 년 동안 웹 페이지 로딩 속도가 빨라졌다면 HTTP/2가 배후에서 작동하고 있을 가능성이 높습니다.

이 가이드는 HTTP/2의 핵심 메커니즘과 성능 이점부터 실제 배포 단계까지 HTTP/2에대해 알아야 할 모든 것을 상세히 설명합니다. 웹 서버를 최적화하려는 개발자이든 단순히 최신 웹사이트의 작동 원리가 궁금한 개발자이든, 여기에서 실행 가능한 인사이트를 찾을 수 있습니다.

빠른 답변: HTTP/2란 무엇이며 왜 중요한가?

HTTP/2는 인터넷 엔지니어링 태스크포스에서 RFC 7540(2015년 5월)으로 표준화한 하이퍼텍스트 전송 프로토콜 버전 1.1의 주요 개정판입니다. 기존 HTTP 시맨틱과의 완벽한 하위 호환성을 유지하면서 지연 시간을 줄이고, 네트워크 리소스 활용도를 개선하며, 웹 페이지를 훨씬 빠르게 로드하는데 중점을 두고 있습니다.

2026년에는 HTTP/2 채택이 거의 보편화될 것입니다. W3Techs 데이터에 따르면, 상위 웹사이트의 1/3 이상이 HTTP/2를 적극적으로 사용하고 있으며, 대부분의 주요 CDN(Cloudflare, AWS CloudFront, Fastly)은 HTTPS 트래픽에 대해 기본적으로 HT TP/2를 활성화합니다. 최신 웹 서버를 통해 HTTPS로 사이트를 운영하는 경우, 추가 설정 없이도 이미 HTTP/2의 이점을 누리고 있을 가능성이 높습니다.

이 프로토콜은 HTTP 1.1의 성능 병목 현상을 해결하는 몇 가지 주요 기능을 도입했습니다:

  • 멀티플렉싱: 다중화: 여러 데이터 스트림이 단일 TCP 연결을 통해 동시에 이동합니다.
  • 헤더 압축(HPACK): 중복된 HTTP 헤더 메타데이터를 획기적으로 줄여주는 헤더 필드 압축을 소개합니다.
  • 바이너리 프레이밍 레이어: 텍스트 기반 명령을 효율적인 바이너리 메시지 프레이밍으로 대체하는 완전히 일반적인 프레임 레이어입니다.
  • 서버 푸시: 브라우저가 명시적으로 리소스를 요청하기 전에 선제적으로 리소스 제공
  • 스트림 우선순위 지정: 서버에 어떤 리소스가 가장 중요한지 알려주는 클라이언트 힌트

실제로 이것이 의미하는 바는 다음과 같습니다:

  • 특히 리소스가 많은 사이트에서 페이지 로드 속도 향상
  • 오리진당 필요한 TCP 연결 수 감소
  • 지연 시간이 긴 모바일 네트워크에서 성능 향상
  • 전반적으로 네트워크 활용도 향상

HTTP/0.9에서 HTTP/2로: 짧은 역사

HTTP 프로토콜은 1991년 팀 버너스 리가 HTML 문서를 가져오는 간단한 메커니즘으로 HTTP/0.9를 도입한 이래로 많은 발전을 거듭해왔습니다. 1996년 헤더와 상태 코드가 추가된 HTTP/1.0이 등장했고, 1997년 RFC 2068에서 표준화된 HTTP/1.1은 이후 1999년 RFC 2616에서 개선되었습니다. 거의 20년 동안 HTTP/1.1은 웹에서 클라이언트-서버 통신의 중추 역할을 했습니다.

하지만 웹은 극적으로 변화했습니다. 최신 웹 페이지는 단순한 문서에서 수십 개의 자바스크립트 번들, CSS 파일, 이미지, API 호출을 로드하는 복잡한 애플리케이션으로 바뀌었습니다. 광대역 연결과 강력한 하드웨어에도 불구하고 HTTP/1.1의 아키텍처는 병목 현상을 일으켰습니다:

  • 회선 차단 헤드: 각 TCP 연결은 한 번에 하나의 요청만 처리할 수 있어 리소스가 대기열에 대기하면서 불필요한 네트워크 트래픽을 발생시켰습니다.
  • 연결 오버헤드: 데스크톱 웹 브라우저와 모바일 웹 브라우저는 일반적으로 이 제한을 해결하기 위해 오리진당 6~8개의 병렬 TCP 연결을 열었습니다.
  • 중복 헤더: 모든 HTTP 요청이 동일한 상세 헤더(쿠키, 사용자 에이전트, 수락 헤더)를 반복적으로 전송합니다.

구글은 이러한 문제를 인식하고 2009년에 SPDY 프로젝트를 시작했습니다. 2010년경 Chrome에 처음 구현된 SPDY는 몇 가지 혁신을 도입했습니다:

  • 텍스트 기반 프로토콜 대신 바이너리 프레이밍
  • 단일 연결을 통한 여러 요청 다중화
  • 오버헤드 감소를 위한 헤더 압축
  • 중요 리소스에 대한 스트림 우선순위 지정

IETF HTTP 워킹 그룹은 SPDY의 잠재력을 보고 2012년에 이를 HTTP/2의 출발점으로 채택했습니다. ietf HTTP 워킹 그룹의 광범위한 작업 끝에 2015년 5월에 RFC 7540(HTTP/2)과 RFC 7541(HPACK)이 발표되었습니다.

브라우저 도입이 빠르게 진행되었습니다:

  • Chrome은 Chrome 51(2016년 5월)부터 HTTP/2를 위해 SPDY를 더 이상 지원하지 않습니다.
  • 버전 36(2015년 2월)에 HTTP/2 지원이 추가된 Firefox
  • Safari는 버전 9(2015년 9월)로 이어졌습니다.
  • Microsoft Edge는 초기 릴리스부터 HTTP/2 지원과 함께 제공되었습니다.
  • Internet Explorer 11도 Windows 8.1 이상에서 HTTP/2를 지원하게 되었습니다.

HTTP/1.1과의 설계 목표 및 주요 차이점

HTTP/2는 HTTP/1.1 시맨틱과 완벽한 호환성을 유지합니다. GET 및 POST와 같은 메서드는 동일하게 작동합니다. 상태 코드는 변경되지 않습니다. URI와 HTTP 헤더 필드도 동일한 규칙을 따릅니다. 달라지는 것은 이 데이터가 와이어를 통해 이동하는 방식, 즉 실제 부하 속도를 결정하는 전송 계층 메커니즘입니다.

프로토콜의 설계 목표는 분명했습니다:

목표HTTP/2가 이를 달성하는 방법
지연 시간 단축멀티플렉싱으로 HTTP 수준의 헤드 오브 라인 차단 제거
더 나은 연결 사용단일 TCP 연결이 오리진에 대한 모든 요청을 처리합니다.
헤더 오버헤드 잘라내기HPACK 압축은 이전에 전송된 헤더 값을 축소합니다.
모바일 성능 향상연결 수가 적고 헤더가 작을수록 지연 시간이 긴 네트워크에 유리합니다.

이 설계의 장점은 애플리케이션 수준에서 이전 버전과의 호환성입니다. 기존 웹 애플리케이션 코드(라우트, 핸들러, 응답 로직)는 변경할 필요가 없습니다. 클라이언트 및 서버 스택만 HTTP/2를 지원해야만 이점을 누릴 수 있습니다.

이는 개발자가 수동으로 구현해야 했던 HTTP/1.1의 해결 방법과 크게 대조됩니다:

  • 도메인 샤딩: 여러 도메인에 자산을 분산하여 더 많은 연결 열기
  • 자산 연결: 요청을 줄이기 위한 CSS 및 JavaScript 파일 번들링
  • 이미지 스프라이트: 여러 이미지를 단일 파일로 결합하기
  • 인라이닝: HTML에 직접 CSS 및 자바스크립트 삽입하기

이러한 해킹을 대체하는 HTTP/2의 핵심 메커니즘:

  • 바이너리 프레이밍 레이어: 프레임으로 분할된 메시지는 이진 프로토콜 단위로 데이터를 효율적으로 전달합니다.
  • 멀티플렉싱 스트림: 동일한 연결에서 여러 개의 동시 교환이 발생합니다.
  • HPACK 헤더 압축: 동적 테이블이 헤더를 추적하여 중복성을 제거합니다.
  • 서버 푸시: 서버가 클라이언트에 필요한 리소스를 선제적으로 전송합니다.
  • 스트림 우선순위 지정: 클라이언트는 스트림 종속성 가중치를 통해 어떤 리소스가 가장 중요한지 신호를 보냅니다.

바이너리 프레이밍, 스트림, 메시지 및 멀티플렉싱

HTTP/2의 핵심은 HTTP/1.1의 텍스트 기반 형식에서 근본적으로 벗어난 바이너리 프레임 계층입니다. 모든 HTTP 메시지는 길이, 유형, 플래그, 스트림 식별자를 포함하는 9바이트 프레임 헤더와 선택적 페이로드 데이터로 구성된 일관된 프레임 레이아웃을 가진 바이너리 프레임으로 나뉩니다.

계층 구조를 이해하려면 세 가지 개념을 파악해야 합니다:

스트림은 단일 연결 내에서 독립적인 양방향 채널입니다. 각 스트림에는 고유한 31비트 식별자가 있습니다. 클라이언트는 홀수 ID(1, 3, 5…)로 스트림을 시작하고, 서버는 푸시와 같이 서버가 시작한 스트림에 짝수 ID(2, 4, 6…)를 사용합니다. 예기치 않은 스트림 식별자는 오류를 트리거합니다. 최대 동시 스트림 설정은 동시에 활성화할 수 있는 스트림 수를 제어합니다.

메시지는 완전한 HTTP 요청 또는 응답을 나타냅니다. 완전한 헤더 블록은 하나 이상의 프레임으로 구성되며 응답에는 본문에 대한 여러 데이터 프레임이 포함될 수 있습니다. 수신자는 헤더 블록 조각을 발견하면 이를 재조립하여 전체 메시지를 재구성합니다.

프레임은 전선에서 가장 작은 단위입니다. 일반적인 프레임 및 오류 유형은 다음과 같습니다:

  • 데이터 프레임: 요청/응답 본문 콘텐츠 전달
  • HEADERS 프레임: 헤더 블록 조각이라고 하는 여러 프레임에 걸쳐 분할된 HTTP 헤더 필드를 포함합니다.
  • 설정: 구성을 위한 연결 제어 메시지
  • WINDOW_UPDATE: 흐름 제어 창 조정
  • PUSH_PROMISE: 서버 푸시 발표
  • RST_STREAM: 오류 코드가 있는 스트림을 종료합니다.
  • GOAWAY: 정상적으로 연결 종료 시작

멀티플렉싱을 통해 마법이 일어납니다. 동시에 열려 있는 여러 스트림의 프레임을 단일 TCP 연결을 통해 인터리빙할 수 있기 때문에(필요에 따라 엔드포인트가 프레임을 인터리빙) 기다릴 필요가 없습니다. 수신기는 스트림 식별자별로 프레임을 재조립합니다.

일반적인 웹 페이지를 로드하는 경우를 생각해 보세요:

  • index.html (10 KB)
  • styles.css (25 KB)
  • app.js (100 KB)
  • 로고.png (15 KB)
  • hero-image.jpg (200 KB)

HTTP/1.1에서는 브라우저에서 여러 연결을 열어 병렬로 가져오기 때문에 여전히 한계에 부딪힙니다. HTTP/2에서는 다섯 가지 리소스가 모두 하나의 연결을 통해 여러 데이터 스트림으로 동시에 전송됩니다. 서로 다른 스트림의 데이터 프레임이 인터리빙되며 클라이언트와 서버 모두 전체 연결을 효율적으로 관리합니다.

이렇게 하면 여러 개의 TCP 연결이 필요하지 않으므로 연결 흐름 제어 창 오버헤드가 줄어들고 웹 성능이 크게 향상됩니다.

HPACK을 사용한 헤더 압축

RFC 7541(2015년 5월 HTTP/2와 함께 발표)에 정의된 HPACK은 HTTP/2를 위해 특별히 설계된 헤더 압축을 제공합니다. 이는 HTTP/1.1 헤더가 장황하고 완전히 압축되지 않아 모든 요청에서 불필요한 네트워크 트래픽을 유발했기 때문에 중요합니다.

일반적인 HTTP 요청의 헤더를 생각해 보세요:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...

이러한 헤더는 요청당 700-800바이트를 초과하는 경우가 많습니다. 쿠키를 사용하면 몇 킬로바이트까지 늘어날 수 있습니다. 페이지당 수십 개의 요청을 곱하면 상당한 대역폭이 낭비되며, 특히 모바일 네트워크에서는 문제가 심각합니다.

HPACK은 세 가지 메커니즘을 통해 헤더를 압축합니다:

  1. 정적 테이블: 전송이 필요 없는 61개의 사전 정의된 공통 헤더 필드/값 쌍(예: :method: GET 또는 :status: 200)
  2. 동적 테이블: 클라이언트와 서버가 함께 구축하는 연결별 테이블로, 이전에 전송된 헤더 값을 저장하여 재사용할 수 있습니다.
  3. 허프만 코딩: 문자열 값은 미리 정의된 허프만 테이블을 사용하여 인코딩되어 텍스트 표현이 축소됩니다.

그 결과는 극적입니다. 첫 번째 요청이 동적 테이블에 공통 헤더를 설정한 후에는 후속 요청에서 인덱스 참조만 전송할 수 있습니다. 킬로바이트로 시작했던 헤더가 수십 바이트로 줄어듭니다.

HPACK은 SPDY의 DEFLATE와 같은 초기 압축 체계에 영향을 미쳤던 CRIME 및 BREACH와 같은 보안 취약점을 피하기 위해 특별히 설계되었습니다. 정적 허프만 코드와 신중한 테이블 관리를 통해 HPACK은 공격자가 압축률 분석을 사용하여 공격자와 피해자의 혼합 데이터에서 비밀을 추출하지 못하도록 방지합니다.

한 가지 주목할 점은 HPACK은 HTTP 헤더에서만 작동한다는 점입니다. 응답 본문은 헤더 압축과는 완전히 별개로 HTTP 계층에서 여전히 gzip 또는 Brotli와 같은 표준 콘텐츠 인코딩 메커니즘을 사용합니다.

서버 푸시 및 스트림 우선순위 지정

HTTP/2는 HTTP/1.1의 해결 방법을 대체하기 위해 설계된 두 가지 최적화 기능, 즉 사전 리소스 전송을 위한 서버 푸시와 지능적인 리소스 주문을 위한 스트림 우선순위 지정을 도입했습니다.

서버 푸시

서버 푸시를 사용하면 웹 서버가 명시적으로 요청되기 전에 리소스를 클라이언트에 보낼 수 있습니다. 이 메커니즘은 PUSH_PROMISE 프레임을 통해 작동합니다:

  • 클라이언트 요청 /index.html
  • 서버는 HTML로 응답하지만 /styles.css 및 /app.js를 푸시할 것임을 알리는 PUSH_PROMISE 프레임도 보냅니다.
  • 서버는 이러한 리소스를 새 서버 시작 스트림으로 전송합니다(스트림 식별자는 더 낮은 값의 스트림 식별자 할당 규칙에 따라 짝수를 사용합니다).
  • 브라우저는 HTML 구문 분석이 리소스가 필요하다는 것을 발견하기 전에 리소스를 수신합니다.

이렇게 하면 왕복 요금이 발생하지 않습니다. 대신:

  1. HTML 요청 → HTML 수신
  2. HTML 구문 분석, 필요한 CSS 발견 → CSS 요청
  3. CSS 구문 분석, 필요한 글꼴 찾기 → 글꼴 요청하기

서버 푸시는 2-3단계를 1단계로 축소합니다.

그러나 서버 푸시는 실제로는 문제가 있는 것으로 입증되었습니다:

  • 브라우저에 이미 리소스가 캐시되어 있어 푸시가 낭비될 수 있습니다.
  • 잘못 구성된 서버는 너무 공격적으로 푸시하여 대역폭을 낭비합니다.
  • 캐시 다이제스트 메커니즘은 널리 채택되지 않았습니다.
  • 현재 많은 CDN과 브라우저에서 기본적으로 푸시를 제한하거나 비활성화합니다.

클라이언트는 연결 서문에서 SETTINGS_ENABLE_PUSH = 0으로 설정하여 푸시를 완전히 비활성화할 수 있습니다. 클라이언트 연결 서문에서 푸시를 즉시 비활성화하면 서버 연결 서문은 승인 및 규정 준수로 구성됩니다.

스트림 우선순위 지정

스트림 우선순위 지정은 클라이언트가 리소스의 중요도를 알려 서버가 대역폭을 효과적으로 할당할 수 있도록 도와줍니다. 메커니즘은

  • 가중치: 1~256 사이의 값으로 상대적 중요성을 나타냅니다.
  • 종속성: 스트림은 다른 스트림에 종속될 수 있으며, 스트림 종속성 선언을 통해 종속성 트리를 형성합니다.

실제 사례:

  • HTML 스트림(가중치 256, 종속성 없음) – 최고 우선순위
  • CSS 스트림(가중치 200, HTML에 따라 다름) – 높은 우선 순위
  • 접힌 이미지(가중치 100, CSS에 따라 다름)
  • 애널리틱스 자바스크립트(가중치 16, HTML에 따라 다름) – 낮은 우선순위

이렇게 하면 중요한 렌더링 경로 리소스가 먼저 도착하므로 총 전송 시간이 비슷하게 유지되더라도 체감 부하 속도가 향상됩니다.

중요한 주의 사항:

  • 우선순위 지정은 권고 사항이며 필수는 아닙니다.
  • 서버 구현에 따라 우선순위를 적용하는 방식은 매우 다양합니다.
  • 중개자(프록시, CDN)가 프레임을 재주문할 수 있습니다.
  • 튜닝에는 가정이 아닌 실제 트래픽으로 테스트해야 합니다.

광고된 동시 스트림 제한은 한 번에 활성 우선순위를 가질 수 있는 스트림의 수에 영향을 줍니다.

흐름 제어, 오류 처리 및 보안 고려 사항

HTTP/2는 자체적인 흐름 제어 및 오류 처리를 TCP 이상으로 구현하여 애플리케이션 계층의 인텔리전스가 전송 계층의 기본값보다 성능이 뛰어난 시나리오를 해결합니다.

흐름 제어

흐름 제어는 빠른 발신자가 느린 수신자를 압도하는 것을 방지합니다. HTTP/2는 WINDOW_UPDATE 프레임과 함께 크레딧 기반 시스템을 사용합니다:

  • 각 스트림에는 자체 수신기 흐름 제어 창이 있습니다.
  • 연결에는 연결 흐름 제어 창도 있습니다.
  • 기본 창 크기: 65,535바이트(64KB)
  • 발신자는 수신자의 사용 가능한 창을 초과하는 데이터 프레임을 전송할 수 없습니다.
  • 수신자는 더 많은 크레딧을 부여하기 위해 WINDOW_UPDATE 프레임을 보냅니다.

주요 특징

  • 흐름 제어는 홉 단위(각 발신자/수신자 쌍 간에 적용)로 이루어집니다.
  • 비활성화할 수 없습니다.
  • 데이터 프레임만 창에 포함되며 다른 필수 프레임 데이터는 포함되지 않습니다.
  • 스트림 흐름 제어와 연결 흐름 제어는 모두 독립적으로 작동합니다.

이렇게 하면 하나의 빠른 스트림이 연결 리소스를 독점하는 것을 방지할 수 있으며, 프록시 또는 CDN이 클라이언트와 오리진 사이에 위치할 때 특히 중요합니다.

오류 처리

HTTP/2는 세분화된 오류 시그널링을 제공합니다:

  • 스트림 수준 오류: RST_STREAM은 다른 스트림에 영향을 주지 않고 한 스트림을 즉시 종료하며, PROTOCOL_ERROR 또는 FLOW_CONTROL_ERROR와 같은 오류 코드를 전달합니다.
  • 연결 수준 오류: GOAWAY는 연결을 정상적으로 종료하여 기내 요청을 완료하는 동시에 새로운 요청을 방지합니다.

이 프로토콜은 다음을 포함한 오류 코드 레지스트리를 정의합니다:

  • PROTOCOL_ERROR (0x1): 일반 프로토콜 위반
  • FLOW_CONTROL_ERROR (0x3): 흐름 제어 규칙을 위반했습니다.
  • 프레임 크기 오류(0x6): 프레임이 설정_최대_프레임 크기를 초과했습니다.
  • INADEQUATE_SECURITY (0xc): 전송 계층 보안 구성이 불충분합니다.

보안 고려 사항

RFC 7540은 기술적으로 암호화를 요구하지 않지만, 모든 주요 웹 브라우저는 TLS(전송 계층 보안)를 통한 HTTP/2를 요구합니다. 따라서 TLS 1.2+가 사실상 기준이 됩니다:

  • 연결은 ALPN(애플리케이션 계층 프로토콜 협상)을 포함한 TLS 핸드셰이크로 시작됩니다.
  • ALPN 확장자는 HTTP/2의 “h2” 식별자를 협상합니다.
  • 서버는 사양에 의해 블랙리스트에 오른 약한 암호 집합을 피해야 합니다.
  • RC4 또는 기타 더 이상 사용되지 않는 알고리즘을 사용하는 암호 제품군은 INADEQUATE_SECURITY 오류를 트리거합니다.

개인정보 보호 고려 사항에는 다음이 포함됩니다:

  • 설정 및 우선 순위 패턴은 클라이언트를 지문으로 인식할 수 있습니다.
  • 오리진당 단일 연결은 모든 사용자 활동을 해당 오리진과 연관시킵니다.
  • 바이너리 프로토콜은 트래픽을 숨기지만 네트워크 관찰자로부터 트래픽을 숨기지는 않습니다.

TCP 헤드오브라인 차단

HTTP/2는 멀티플렉싱을 통해 HTTP 수준의 헤드 오브 라인 차단을 해결하지만, TCP 수준의 차단은 여전히 남아 있습니다. TCP 패킷이 손실되면 데이터가 성공적으로 도착한 스트림을 포함하여 재전송이 완료될 때까지 해당 연결의 모든 스트림이 정지됩니다.

이러한 한계 때문에 진정한 스트림 독립성을 제공하기 위해 QUIC(UDP 기반)을 통해 실행되는 HTTP/3이 탄생했습니다. 한 스트림에 영향을 미치는 패킷 손실이 다른 스트림을 차단하지 않습니다.

실무에서 HTTP/2 배포 및 사용

2026년에 HTTP/2를 활성화하는 것은 간단합니다. 대부분의 최신 웹 서버와 CDN은 기본적으로 HTTPS를 통해 바로 지원합니다. HTTP 업그레이드 메커니즘은 협상을 투명하게 처리합니다.

클라이언트 측 요구 사항

사용자는 특별한 조치를 취할 필요가 없습니다:

  • 모든 최신 데스크톱 웹 브라우저(Chrome, Firefox, Safari, Edge)는 기본적으로 HTTP/2를 지원합니다.
  • 모바일 웹 브라우저(Android용 Chrome, iOS용 Safari)가 완벽하게 지원됩니다.
  • 최신 브라우저 버전을 유지하여 호환성 보장
  • HTTP/2는 사용 가능한 경우 자동으로 협상합니다.

서버 측 구성

Apache HTTP 서버(2.4.17+):

  • mod_http2 모듈(이전 mod_spdy가 아닌)을 활성화합니다.
  • TLS 가상 호스트에 프로토콜 h2 http/1.1 추가하기
  • OpenSSL 버전이 ALPN을 지원하는지 확인

Nginx(1.9.5+):

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... rest of configuration
}

IIS(Windows Server 2016+):

  • TLS 1.2+를 사용하는 HTTPS의 경우 기본적으로 HTTP/2가 활성화됩니다.
  • 추가 구성이 필요하지 않습니다.

CDN 제공업체:

  • Cloudflare: 모든 요금제에서 기본적으로 HTTP/2 활성화
  • AWS CloudFront: HTTPS 배포에 기본적으로 활성화됨
  • 빠르게: 기본적으로 지원 및 활성화됨

확인 및 문제 해결

이 체크리스트를 통해 HTTP/2가 작동하는지 확인합니다:

  • 브라우저 개발자 도구: 네트워크 탭을 열고 프로토콜 열을 활성화한 다음 “h2″를 찾습니다.
  • 명령줄: curl –http2 -I https://example.com 응답으로 HTTP/2를 표시합니다.
  • 온라인 도구: HTTP/2 테스트 서비스 구성 확인
  • 중개자를 확인하세요: CDN 또는 리버스 프록시는 오리진 서버뿐만 아니라 HTTP/2도 지원해야 합니다.

HTTP/2를 방해하는 일반적인 문제:

  • OpenSSL 버전이 너무 오래되어 ALPN 지원 불가
  • TLS 1.0/1.1 전용 구성
  • 폴백을 트리거하는 약한 암호 제품군
  • 잘못 설정된 프록시 제거 HTTP/2 지원

HTTP/2와 그 이후

HTTP/3(RFC 9114, 2022년 발표)가 배포되기 시작하더라도 HTTP/2는 여전히 최신 웹 통신의 지배적인 프로토콜로 남아 있습니다. HTTP/3는 QUIC을 통해 실행되어 TCP 헤드오브라인 차단을 해결하지만, HTTP/2의 단일 TCP 연결 모델은 계속해서 대부분의 웹 트래픽에 효과적으로 서비스를 제공합니다.

대부분의 사이트에서 HTTP/2는 최소한의 설정 작업으로 상당한 웹 성능 향상을 제공합니다. 지금 바로 HTTP/2를 통한 프레임 교환을 시작하면 데스크톱이든 모바일이든 사용자가 더 빠르고 효율적인 페이지 로딩을 경험할 수 있습니다.

주요 내용

  • HTTP/2는 멀티플렉싱을 통해 웹 성능을 혁신적으로 개선하여 단일 연결에서 여러 개의 동시 교환을 가능하게 합니다.
  • HPACK 헤더 압축은 중복 헤더 전송을 제거하여 특히 모바일 사용자에게 유리합니다.
  • 서버 푸시 및 스트림 우선순위 지정은 리소스 전송을 최적화하지만 구현 방식은 다양합니다.
  • 흐름 제어로 여러 스트림에서 리소스 고갈 방지
  • 최신 서버에서는 배포가 간단하며, 주로 HTTPS 구성이 필요합니다.
  • 모든 주요 브라우저는 HTTP/2를 지원하므로 최종 사용자가 원활하게 도입할 수 있습니다.

다음 단계

웹 서버에서 HTTP/2를 확인하지 않았다면 지금이 바로 그 때입니다. 브라우저의 개발자 도구를 열고 사이트를 로드한 다음 프로토콜 열을 확인하세요. ‘h2’ 대신 ‘http/1.1’이 표시되면 서버 구성을 검토하세요. 성능 향상을 위한 상당한 개선이 필요한 상태입니다.

이미 HTTP/2를 실행하고 있다면 서버의 HTTP/2 연결 메트릭을 모니터링하는 것을 고려해 보세요. 실제 트래픽에서 여러 개의 동시 스트림이 어떻게 작동하는지 이해하면 사용자가 문제를 알아채기 전에 최적화 기회를 파악하는 데 도움이 됩니다.