HTTP/2 프레이밍과 스트림 다중화

HTTP/2(RFC 9113)는 HTTP 의미를 유지하면서 메시지를 바이너리 프레임으로 나누어 전달합니다. 프레임의 유형·길이·플래그·스트림 식별자가 프레임 헤더에 실리고, HEADERS와 DATA 등 여러 프레임이 스트림 단위로 교차될 수 있습니다. 바이너리 프레이밍은 전송 형식을 구조화한 것이며 애플리케이션의 HTTP 의미가 사라지거나 입력 검증이 불필요해지는 것은 아닙니다.

하나의 연결에서 여러 스트림을 다중화하면 HTTP/1.1 응답 순서 대기 문제를 줄이고 연결 재사용을 높일 수 있습니다. 다만 일반적인 HTTP/2는 TCP 위에서 동작하므로 패킷 손실에 따른 TCP 재전송 지연이 같은 연결의 여러 스트림에 영향을 줄 수 있습니다. HPACK은 헤더 필드를 압축하지만 실제 성능은 콘텐츠, 서버·클라이언트 구현, TLS, 프록시, 회선 품질에 따라 달라집니다.

전문가 관점: 다중화의 이점과 TCP의 남은 제약

Cloudflare 기술 저자 Ryan Hodson은 HTTP/2 도입 당시 웹 최적화 관점에서 여러 요청을 한 TCP 연결에서 병렬로 진행하는 다중화와 반복 헤더 압축의 이점을 설명했습니다. 이는 2015년의 실무 해설이며 모든 사이트에서 성능 향상을 보장하지 않습니다. IETF RFC 9113에 따르면 HTTP/2 프레임은 스트림 ID로 구분되므로 HTTP/1.1 파이프라이닝의 응답 순서 대기를 줄이지만, 모든 스트림이 TCP 바이트 스트림을 공유합니다. 패킷 손실로 TCP가 재전송을 기다리면 그 연결의 뒤쪽 프레임도 지연될 수 있습니다.

바이너리 프레이밍은 보안·속도를 자동 보증하지 않음

HTTP/2는 9바이트 프레임 헤더, HEADERS/DATA 등의 프레임, HPACK 헤더 압축을 정의합니다. 바이너리 인코딩은 파싱 구조를 명확하게 하지만 인젝션 취약점을 원천 차단하거나 파싱 성능을 반드시 높이지는 않습니다. 애플리케이션 계층의 HTTP 의미와 입력 검증은 계속 필요합니다. RFC 9218 우선순위 체계는 클라이언트와 서버가 urgency·incremental 힌트를 교환하는 확장 방식이며, 서버가 반드시 그 순서대로 자원을 배정한다는 보장은 아닙니다. 실제 체감 성능은 서버 구현, 콘텐츠, 연결 상태, 중간 장비 및 우선순위 지원 여부로 측정하세요.

참고 문헌 및 자료 출처