HTTP/2.0 (HyperText Transfer Protocol 2.0)
HTTP/1.1의 메시지 포맷은 구현이 쉽고 디버깅이 용이하다는 장점이 있었으나, 웹 환경이 복잡해짐에 따라 성능상의 한계가 드러났다.
- 커넥션 하나당 하나의 요청과 응답만 처리할 수 있는 구조: HOL(Head of Line) Blocking 문제 발생
- 하나의 요청이 지연되면 뒤따르는 모든 요청이 지연
- 병렬 커넥션으로 이를 완화하려 했으나, TCP 커넥션 수가 많아지며 오히려 네트워크 혼잡과 지연 증가
- 헤더의 비효율성: 중복되는 헤더 필드가 많아 네트워크 오버헤드 증가
위 문제를 해결하기 위해 2015년에 HTTP/2.0이 표준화되었다.
핵심 목표와 특징
섹션 제목: “핵심 목표와 특징”기존 HTTP/1.1의 의미(Method, Status Code, Header 등)는 유지하면서 데이터 전송 방식을 획기적으로 개선하여 지연 시간(Latency)을 줄이고 성능을 극대화하는 것을 목표로 설계되었다.
- 바이너리 프레이밍 계층(Binary Framing Layer)
- 텍스트가 아닌 바이너리 단위로 데이터를 전송
- 파싱 속도가 빠르고 오류 발생 가능성이 낮음
- 멀티플렉싱(Multiplexing)
- 단일 커넥션에서 여러 요청과 응답을 동시에 주고받음
- HTTP/1.1의 HOL Blocking 문제 해결
- 서버 푸시(Server Push)
- 클라이언트가 요청하지 않은 리소스(CSS, JS 등)를 서버가 미리 전송 가능
- 헤더 압축(Header Compression)
- HPACK 알고리즘을 사용하여 중복되는 헤더를 압축 전송
- HTTP/1.1 호환성
- 기존 웹 애플리케이션들과 호환성을 최대한 유지하기 요청/응답 메시지의 의미를 최대한 같도록 유지
HTTP/1.1과의 차이점
섹션 제목: “HTTP/1.1과의 차이점”HTTP/2.0 역시 TCP 커넥션 위에서 동작하지만, HTTP/1.1과는 구조적으로 큰 차이가 있다.
flowchart TD subgraph HTTP1 [HTTP/1.1] H1_MSG[Text Message<br>Header + Body] end
subgraph HTTP2 [HTTP/2.0] H2_L1[Binary Framing Layer] H2_F1[Frame: Headers] H2_F2[Frame: Data] H2_L1 --> H2_F1 H2_L1 --> H2_F2 end가장 큰 변화는 애플리케이션 계층과 전송 계층 사이에 바이너리 프레이밍 계층이 추가된 것이다.
1. 프레임(Frame)과 바이너리 포맷
섹션 제목: “1. 프레임(Frame)과 바이너리 포맷”HTTP/2 통신의 최소 단위는 프레임으로, 기존의 줄바꿈으로 구분되던 텍스트 메시지가 잘게 쪼개져 바이너리 프레임으로 변환된다.
+-----------------------------------------------+| R | Length(24) | Type(8) | Flag(8) |+---------------+-------------------------------+|R| Stream Identifier(31) |+-----------------------------------------------+| Stream Payload |+-----------------------------------------------+- R(1bit): 예약된 필드 (항상 0)
- Length(24bit): 페이로드의 길이 (헤더 제외)
- Type(8bit): 프레임의 종류
- Flags(8bit): 프레임별 옵션 플래그
- Stream Identifier (31bit): 스트림 ID. 어떤 스트림에 속한 프레임인지 식별
2. 스트림(Stream)과 멀티플렉싱
섹션 제목: “2. 스트림(Stream)과 멀티플렉싱”스트림은 구성된 연결 내에서 전달되는 바이트의 양방향 흐름으로, 하나 이상의 메시지가 포함될 수 있다.
- 동작 방식
- HTTP 메시지(요청/응답)를 여러 개의 프레임으로 분해
- 각 프레임에 스트림 ID를 부여하여 전송
- 수신 측에서는 스트림 ID를 보고 프레임을 다시 조립하여 메시지 복원
- 효과
- 하나의 TCP 커넥션으로 수십 개의 요청과 응답을 동시에 처리 가능
- 특정 요청이 느려져도 다른 요청에 영향을 주지 않음(HOL Blocking 해결)
- 특정 스트림에 우선순위 지정 가능
3. 서버 푸시 (Server Push)
섹션 제목: “3. 서버 푸시 (Server Push)”클라이언트가 HTML을 요청했을 때, 해당 페이지 렌더링에 필요한 CSS나 JavaScript 파일을 서버가 알아서 함께 보내는 기능이다.
- 클라이언트:
GET /index.html요청 - 서버:
/index.html응답 + (Push Promise) +/style.css+/app.js전송 - 효과: 클라이언트의 추가 요청 대기 시간을 제거하여 로딩 속도 향상
보안 이슈
섹션 제목: “보안 이슈”중개자 캡슐화 공격
섹션 제목: “중개자 캡슐화 공격”HTTP/2 메시지를 프록시가 HTTP/1.1로 변환하여 백엔드 서버로 전달할 때 발생할 수 있는 보안 취약점이다.
- 원인: HTTP/2는 헤더 필드에 바이너리 데이터를 포함할 수 있는데, 이를 텍스트 기반인 HTTP/1.1로 변환하는 과정에서 유효성 검증이 미흡하면 개행 문자 등이 삽입되어 메시지 경계가 모호해질 수 있음
- 결과: 공격자가 요청을 밀어넣어 다른 사용자의 응답을 가로채거나 캐시를 오염시킬 수 있음
긴 커넥션 유지로 인한 개인정보 누출
섹션 제목: “긴 커넥션 유지로 인한 개인정보 누출”단일 커넥션을 오래 유지하는 특성 때문에 개인 정보 누출 위험이 있어, 브라우저 벤더들은 이에 대응하기 위해 커넥션 유지 정책을 조정하기도 한다.