[Chapter5] HTTP2 푸시의 구현

HTTP/2 IN ACTION을 공부하며 정리한 글입니다.
틀린 부분은 지적해주시면 감사드리겠습니다 😀

HTTP2 서버 푸시

기존 HTTP/1.1은 단일 요청-응답 프로토콜이므로, 요청과 응답의 반복(Round Trip)으로 왕복 지연이 발생하게 된다. 하지만, HTTP/2의 경우 서버 푸시를 이용해서, 이를 방지할 수 있다.

 

서버 푸시란, 클라이언트가 A에 대해 요청을 하고, 서버가 A에 대한 응답과 또 다른 응답을 클라이언트에게 푸시하는 것을 의미한다. 즉, 1요청 -> n응답의 구조가 되는 것이다.

왜 필요할까?

브라우저는 첫 페이지를 다운로드한 다음, 추가 리소스가 참조된 것을 보고 리소스를 서버에 요청하게 된다. 이미지는 초기 페인트 시간(Initial paint time)을 지연시키지 않지만, 어떤 리소스는 페이지 렌더링에 중요해, 해당 리소스가 다운로드 되기 전까지 페이지 렌더링을 시도하지 않게 된다.

 

이러한 이슈는, 하나의 Round Trip이 추가되는 것이므로, 웹 브라우징을 느리게 만든다. 이럴 때, 서버 푸시를 이용하면, index.html을 요청할 때, 또 다른 리소스를 함께 푸시할 수 있기 때문에 웹 브라우징이 더 빨라질 수 있다.

 

단, 클라이언트가 사용하지 않거나 캐시하고 있는 리소스를 과다하게 푸시하면 로드 시간을 저해할 수 있으며, 양방향 흐름인, 웹소켓이나 SSE(Server-Sent Event; 서버 송신 이벤트)와는 다르다. 여전히 클라이언트가 요청해야지 리소스를 푸시할 수 있다.

HTTP/2가 브라우저에서 동작하는 방식

브라우저가 페이지 렌더링 중 필요한 리소스를 요청할 때, 가장 먼저 확인하는 곳은 브라우저의 캐시(디스크 또는 메모리 캐시)이다. 이 캐시에서 리소스를 찾을 수 있다면, HTTP 요청 없이 캐시된 리소스를 그대로 사용한다.

 

서버가 HTTP/2 서버 푸시를 통해 리소스를 미리 전송하면, 해당 리소스는 브라우저의 일반 캐시가 아닌, HTTP/2 Push Cache(푸시 캐시)라는 일시적인 별도 메모리 공간에 저장된다. 이 Push Cache는 브라우저가 해당 리소스를 명시적으로 요청할 때만 활용되며, 브라우저가 일반 캐시에서 리소스를 찾지 못한 경우에만 Push Cache를 참조한다.

 

즉, 푸시 캐시는 브라우저가 리소스를 탐색하는 우선순위상 첫 위치가 아니다. 브라우저에 따라 구현은 조금씩 다르지만, 일반적으로는 기존 HTTP 캐시가 우선이며, 그 다음에 Push Cache가 고려된다.

 

따라서, 이미 브라우저 캐시에 있는 리소스를 푸시하게 되면, Push Cache에 들어가긴 하지만 사용되지 않고 버려질 수 있다. 이 경우 네트워크 자원이 낭비되므로, 서버 푸시를 할 때는 캐시된 리소스를 고려하여 신중하게 선택해야 한다.

 

서버 푸시에 대한 플로우를 보면 다음과 같다.

1. 클라이언트가 index.html에 대한 요청을 보냄
2. 서버는 index.html을 응답하면서, PUSH_PROMISE 프레임을 보냄
   • /style.css, script.js도 함께 보내겠다는 프레임임
3. 브라우저가 해당 리소스를 요청하진 않았지만, 서버는 위 두 개에 대한 푸시 리소스를 보냄
4. 브라우저는 PUSH_PROMISE를 보고 HTTP/2 푸시 캐시에 해당 리소스를 임시 저장함
5. 브라우저가 /style.css가 실제로 필요해지면, 푸시 캐시를 먼저 확인함
   • 푸시 캐시에 있을 경우, 해당 리소스를 사용