HTTP/1.1에서 HTTP/2로
Introduction
오늘 다뤄볼 주제는 HTTP/2다.
전반적인 내용은 HTTP/2 in action이란 책에서 대부분 참고하였으며, 위 포스트는 책에 대한 정리 정도로 보아도 좋다.
지금 내가 듣고 있는 노래는 Chet Baker - Blue Room이다.
HTTP
Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes.
간단한 HTTP의 정의만 소개하겠다. 물론 HTTP 자세한 명세는 이 포스트의 주제를 관통하기 때문에 중요할 수 있지만, 워낙 질 좋은 자료들이 많아 굳이 언급할 이유가 없다고 생각한다.
웹서버와 웹 브라우저 사이의 통신을 담당하는 HTTP는 처음에 개발된 의도와는 다르지만, 다양한 데이터를 전송가능하며 이러한 편리함과 단순성이 HTTP를 이 자리에 올려놓았다.
하지만, 그만큼 단순함과 편리성에 의해 희생되는 부분도 적지 않았다. 특히, 기존 HTTP의 비효율적인 통신 방식은 개선해야할 성능 이슈가 되었다. 근본적인 문제인 요청과 응답 사이에 대기시간, 사람이 읽을 수 있는(Human readable) 텍스트를 전송하는 과정에서 생기는 오버헤드 등 해결해야했던 문제가 산더미다.
물론, 여러가지 우회적인 테크닉을 통해 많은 성능 개선을 이뤄냈지만 근본적인 문제점은 해결되지 않았다.
이번 포스트에서 해볼 이야기는 왜 HTTP/2가 나왔으며 기존의 문제들을 어떻게 해결했는지다.
기존 HTTP의 문제점
왜
HTTP/2가 이러한 방식으로 구현되었는가?
위 질문에 대답하기 위해선 기존의 문제점을 꼬집어봐야 한다. 기존의 문제점을 이해하는 게 추후 등장할 HTTP/2 나아가 HTTP/3 등의 구현에도 큰 영향을 미칠 것이다.
주로 언급되며 고질적인 문제들에 대해 알아보자.
대기시간
HTTP 프로토콜은 요청과 응답이 반드시 존재한다. HTTP는 한 TCP 커넥션 당 하나의 요청만을 제공하며, 초기에는 일회성으로 사용 후 삭제하는 형태였다.
앞서 말했듯이 요청과 응답이 반드시 존재해야하는 상황에서 클라이언트는 이미지 하나를 요청한 후 다음 이미지를 요청하기 위해 서버의 응답을 기다려야(물론 우회할 방법이 있다) 한다. 이러한 절차지향적인 작업은 많은 대기시간을 만들며 주요 성능 저하 원인으로 꼽힌다.
HOL
HOL(Head of Line) 블록킹 문제는 여러 네트워크 통신에서 나타나는 고질적인 문제이며, HTTP도 피해갈 수 없었다.
특정 이미지를 순차적으로 받는 상황에서 맨 처음 이미지의 응답이 서버에서 오지 않는다면 순차적인 구조에 의해 뒤 대기열을 처리할 수 없고, 이로 인해 나타나는 성능상 이슈이다.
헤더 구조의 문제점
무거운 헤더 구조는 사람이 읽을 수 있는 많은 메타정보가 저장되어 있다. 여기서 문제점은 이 큰 헤더의 반복적인 사용이다.
특정 헤더는 값이 변하지 않고 계속해서 사용되지만, 클라이언트는 해당 응답을 재사용하지 못하고 계속해서 서버에 새로이 전송되는 값을 확인한다.
개선을 위한 우회 방법
앞서 설명했던 문제점을 우회하기 위해 사용되는 테크닉을 몇 가지 소개해보겠다.
설명하기전 짚고 넘어갈 점은 이러한 테크닉이 HTTP/2에 등장으로 반드시 안티패턴이 되는 건 아니라는 것이다. 자세한 설명은 추후 포스트에서 하겠지만, 어쩌면 지속적으로 유용할 수 있는 패턴들이 더러있다.
파이프라이닝
파이프라이닝은 응답을 수신하기 전 동시적인 요청을 보내 요청을 병렬 적으로 보낼 수 있도록 고안한 방법이다.
이러한 방식은 성능 개선을 크게 도울 수 있었겠지만, 아쉽게도 여러 문제를 일으키기 쉬워 거의 사용되지 못했다.
HTTP Pipelining Issues
Anecdotal evidence suggests there are a number of reasons why clients don’t use HTTP pipelining by default. Briefly, they are:
- Balking Servers - server implementations can stall pipelined requests, or close their connection when the client attempts to pipeline. This is one of the most commonly cited problems.
- Confused Servers - a few server implementations can respond to pipelined requests in the wrong order. Even fewer might corrupt the actual responses. Because this has security implications (consider multiple users behind such a proxy, or multiple tabs in a browser), this is very concerning.
- Head-of-Line Blocking - Clients don’t have enough information about what is useful to pipeline. A given response may take an inordinate amount of time to generate, and/or be large enough to block subsequent responses. Clients who pipeline may face worse performance if they stack requests behind such an expensive request.
사용되었다고 해도 고질적인 HOL 블록킹 문제는 여전히 남아있다.
여러 HTTP 연결 및 도메인 샤딩
파이프라이닝과 다르게, 여러 HTTP 연결을 이용 시 각자 독립적인 연결로 취급된다.
이러한 방식은 HOL 블록킹 문제를 없애 대부분의 브라우저가 지원한다. 브라우저는 도메인당 최대 6개까지 연결을 지원하는데, 더 많은 요청을 위해 사용되는 게 바로 도메인 샤딩이다.
도메인 샤딩이 물론 병렬화의 정도를 증가시키는 것에 큰 목적이 있지만, 그 외에도 css 파일과 같은 정적 리소스에는 필요없는 쿠키 등을 추가적으로 발생시키지 않도록 쿠키 없는 도메인을 만들어 HTTP 헤더를 감소시킬 수 있다.
요청수를 줄이기 위한 이미지 스프라이팅
근본적인 해결책을 강구하는 방법 중 하나는 바로 실제 요청 수를 줄이는 것이다.
이것만큼 확실한 방법이 어디있겠는가. 이러한 방식을 지향하기 위해 나온 것이 이미지 스프라이팅이다.
여러 이미지 리소스를 하나에 묶어 큰 파일로 사용하는 것이다.
다만, 이러한 방식이 항상 좋다고는 할 수 없다. 예를들어 위와 같은 큰 파일에 하나정도의 이미지만을 사용함에도 큰 파일이 다운로드 되어야 하며, 새로운 스프라이트 파일이 업로드 된다면 또 다시 이미지 위치 추적을 위해 css파일을 재작성해야 한다.
이 기법은 사용하지 않는 이미지를 처리하여 네트워크 계층과 처리의 측면에서 모두 비효율적이다.
HTTP/1.1에서 HTTP/2로
SPDY
HTTP/2의 기원은 SPDY 프로토콜 부터 시작한다. SPDY의 주된 목적은 HTTP/1.1의 한계를 다루고자 고안되었으며 아래와 같은 중요한 개념을 도입했다.
- 다중화된 스트림: 요청 및 응답은 단일 TCP 연결을 사용하며, 분리된 스트림 구룹으로 나눠진다.
- 요청 우선순위 지정: 모든 요청을 동시에 보내는 것으로 새로운 성능 문제를 발생시키지 않기 위해 우선순위를 도입했다.
- 헤더 압축: HTTP 본문 뿐만 아니라 이제 헤더도 압축한다.
HTTP/2
SPDY는 이론적인 방식이 아니라 주요 사이트에서 동작하는 예제로 성능 향상을 꾀할 수 있음을 증명했다.
이러한 성능 향상을 기반으로 SPDY는 HTTP/2의 기반이 되었으며 프로토콜 세부 사항은 RFC 7450에서 공식 승인됐다.
결론
오늘은 HTTP/2가 어떤 이유로 고안되었으며 그 과정에 대해 알아보았다.
자세한 프로토콜 세부사항은 다음 포스트에서 다뤄보려 한다.
Reference
- https://developer.mozilla.org/en-US/docs/Web/HTTP
- HTTP/2 IN ACTION by Barry Pollard(Author), 임혜연 옮김
- https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x
- https://kooku.netlify.app/web/http1.1-vs-http2/