[HTTP 완벽 가이드] 10. HTTP/2.0

HTTP/2.0에서 회전 지연(RTT, Round Trip Time) 회피 방법

HTTP/2.0은 스트림(Stream) 개념을 추가하고, 헤더 압축(HPACK) 및 서버 푸시(Server Push) 기능을 통해 HTTP/1.1에서 발생하는 회전 지연(RTT) 문제를 효과적으로 해결하였다.

 

1. 스트림(Stream)과 다중화(Multiplexing)

스트림이란?

• HTTP/2.0에서는 하나의 TCP 커넥션 내에서 여러 개의 요청과 응답을 동시에 주고받을 수 있도록 스트림(Stream) 개념을 도입했다.
• 각 스트림은 고유한 번호(31비트 부호 없는 정수) 를 가지며, 한 번 사용한 스트림 번호는 재사용할 수 없다.
• 스트림에는 우선순위(priority) 를 설정할 수 있지만, 이는 필수 사항이 아니다.

다중화(Multiplexing)

• HTTP/1.1에서는 한 TCP 커넥션에서 하나의 요청-응답만 가능했지만,HTTP/2.0은 한 커넥션에서 여러 개의 스트림을 동시에 처리할 수 있다.
• 즉, 병렬적으로 요청을 전송하고 응답을 받을 수 있어 RTT를 줄이고 성능을 향상시킨다.

TCP 패킷 절약

• HTTP/2.0의 스트림 생성은 상대방의 협상 없이 즉시 가능하기 때문에,TCP 패킷을 주고받느라 시간을 낭비하지 않아도 된다.
• 따라서 기존 HTTP/1.1에서 발생하던 HOL(Head-of-Line) Blocking 문제를 줄일 수 있다.

 

 

2. 헤더 압축(HPACK)

HTTP 헤더 증가 문제

• HTTP 요청이 증가하면서 헤더 크기가 커지는 문제가 발생했다.
• HTTP/1.1에서는 헤더가 중복되거나 불필요한 정보까지 포함되어 대역폭을 낭비했다.

HPACK 압축 알고리즘

• HTTP/2.0은 HPACK(Header Compression for HTTP/2) 명세를 사용하여 헤더를 압축한다.
• 압축된 헤더는 헤더 블록 조각(Header Block Fragments) 형태로 전송된다.

압축 컨텍스트(Context)와 헤더 처리

• HPACK에서는 압축 컨텍스트(Context)를 사용하여 이전 헤더를 저장하고 재사용할 수 있다.
• 단, 헤더를 수신할 때마다 압축 컨텍스트가 변경되므로, 사용하지 않는 헤더라도 무조건 압축을 풀어야 한다.
• 이를 통해 대역폭을 절약하고, 불필요한 데이터 전송을 방지할 수 있다.

 

 

3. 서버 푸시(Server Push)

서버 푸시란?

• 클라이언트의 요청 없이도 서버가 리소스를 미리 전송하는 HTTP/2.0 기능이다.
• 기존 HTTP 요청-응답 패턴에서는 클라이언트가 먼저 요청을 보내야 서버가 응답했지만,서버 푸시는 서버가 미리 예측하여 필요한 리소스를 전송할 수 있다.

PUSH_PROMISE 프레임

• 서버는 PUSH_PROMISE 프레임을 사용하여 클라이언트에게 푸시할 리소스를 알린다.
• 클라이언트는 이를 확인하고 이미 캐시된 리소스인지 판단한 후 중복 요청을 방지할 수 있다.
• 이후 서버는 일반적인 DATA 프레임을 사용하여 해당 리소스를 전송한다.

예제 시나리오

클라이언트가 index.html을 요청할 때, 서버가 CSS, JavaScript, 이미지 등을 미리 전송하여 성능을 최적화할 수 있다.

Client: GET /index.html
Server: PUSH_PROMISE (style.css, script.js, logo.png)
Server: DATA (index.html, style.css, script.js, logo.png)

 

서버 푸시의 장점

왕복(RTT) 지연 감소

• 클라이언트가 CSS, JS, 이미지 등을 개별적으로 요청하기 전에 서버가 미리 전송하여 로드 시간을 단축할 수 있다.

네트워크 효율성 증가

• HTTP/2.0의 다중화(Multiplexing) 기능과 결합하면 병렬로 여러 리소스를 전송할 수 있어 성능이 크게 향상된다.

페이지 로딩 속도 개선

• 브라우저가 필요할 리소스를 미리 제공받아 렌더링 속도가 빨라진다.

서버 푸시 제어 방법

• 클라이언트는 SETTINGS_ENABLE_PUSH = 0 설정을 통해 서버 푸시를 비활성화할 수 있다.
• 또한, 특정 푸시 스트림을 거부하려면 RST_STREAM 프레임을 사용하여 중단할 수 있다.

서버 푸시의 보안 고려 사항: 동일 출처 정책(Same-Origin Policy)

• 서버 푸시는 반드시 동일한 출처(origin)에서 전송된 리소스만 허용해야 한다.
• 클라이언트는 서버가 푸시한 리소스의 출처를 검증하여 보안 취약점을 방지해야 한다.

 

 

결론: HTTP/2.0이 RTT를 줄인 핵심 요소

기능 | 설명 | 주요 효과 -- | -- | -- 스트림 & 다중화(Multiplexing) | 하나의 TCP 연결에서 여러 개의 요청과 응답을 동시에 처리 | RTT 감소, HOL Blocking 방지 헤더 압축(HPACK) | 중복된 헤더 데이터 압축 | 대역폭 절약, 불필요한 데이터 전송 감소 서버 푸시(Server Push) | 클라이언트 요청 없이 서버가 리소스를 미리 전송 | 요청 지연 방지, 페이지 로딩 속도 향상

 

 

💡 추가적으로 알아두면 좋은 개념

HTTP/3.0에서의 변화

• HTTP/3.0에서는 TCP 대신 QUIC 프로토콜을 사용하여 HOL Blocking 문제를 더욱 효과적으로 해결함.
• UDP 기반의 전송 방식을 채택하여 연결 지연을 최소화함.

HTTP/2.0과 WebSocket의 차이

• WebSocket은 서버와 클라이언트 간 양방향 실시간 통신을 지원하는 반면, HTTP/2.0은 주로 요청-응답 최적화에 초점을 맞춘 프로토콜이다.
• WebSocket은 상태를 유지(Stateful)하는 반면, HTTP/2.0은 여전히 Stateless한 특성을 유지한다.

 

 

셀프 테스트 문제

1.HTTP/2.0은 어떻게 회전지연을 피했는지 생각나는대로 설명해보시오.

• HTTP/2.0은 스트림이라는 개념을 추가하여, 한 TCP 커넥션에서 여러 개의 요청을 보낼 수 있다.
• 한 커넥션에서는 여러 개의 스트림을 만들 수 있으며, 스트림에서는 우선순위도 가질 수 있다(의무사항 아님) 또한 한 번 사용한 스트림의 번호는 사용할 수 없다. 스트림의 번호는 부호 없는 31비트의 정수로 이루어져 있다. 만일 주어진 스트림의 번호의 한계치를 넘어설 경우 커넥션을 초기화하는 방식으로 해결할 수 있다.
• 또한 이 스트림은 상대방의 협상을 구하지않고 만들기에 TCP 패킷을 주고받느라 시간을 낭비하지않아도 된다.

2.헤더의 압축의 필요성이 부각된 이유와 압축하는 과정에 대해서 간략하게 설명해주세요

• 요청 증가로 인한 헤더의 압축의 필요성이 부각됨
• 압축 방법: HPACK 명세에 정의된 헤더 압축 방법으로 압축된 뒤, 헤더 블록 조각들로 쪼개져 전송된다.

3.서버 푸시를 위해 서버는 클라이언트에게 이 프레임을 보내는데, 이 프레임의 이름은?

• PUSH_PROMISE