요약

  • RFC 7540은 HTTP/2 서버가 PUSH_PROMISE로 다음에 필요할 법한 자원을 미리 알리고 보내도록 했다. 클라이언트는 이를 끄거나 개별 흐름을 거절할 수 있었다.
  • RFC 9113은 2022년에도 Server Push를 유지하면서 잘못된 예측이 성능을 떨어뜨리는 이유를 적었다. Chrome 106 변경 공지는 밀어 보낸 흐름의 수신·보관·사용 기능을 제거했다고 밝혔다.

요청보다 먼저 도착한 답

브라우저가 HTML 문서를 요청하면 서버는 그 문서에 연결된 스타일 파일을 이미 볼 수 있다. 브라우저가 문서를 읽고 다시 요청하기 전에 파일을 보내면 네트워크 왕복 시간을 아낄 수 있다. 2015년 HTTP/2 명세의 Server Push는 이 순서를 허용했다. 서버가 클라이언트의 다음 요청을 대신 만들어 PUSH_PROMISE로 알리고 별도의 흐름에 응답을 실어 보냈다.

제약도 분명했다. 선제 전송은 실제 클라이언트 요청과 연결되어야 했고, 안전하고 캐시에 넣을 수 있는 자원이어야 했다. 서버가 그 출처를 대신할 권한도 필요했다. 브라우저는 SETTINGS_ENABLE_PUSH=0을 보내거나 원하지 않는 흐름을 취소할 수 있었다. 서버가 먼저 제안할 수 있다는 허가는 브라우저의 필요를 정확히 안다는 보증이 아니었다.

브라우저에는 이미 파일이 캐시에 있을 수 있다. 콘텐츠 협상으로 다른 버전이 필요할 수도 있다. 이용자가 페이지를 떠나면 보내 놓은 파일은 쓰이지 않는다. 불필요한 데이터는 실제로 요청한 응답과 같은 통로를 다툰다. 잘 맞춘 예측은 기다림을 줄이지만, 틀린 예측은 빠른 배달을 늦출 수 있다.

표준이 남겨 둔 경고

2022년 6월의 RFC 9113은 Server Push 장을 삭제하지 않았다. 스타일 파일이나 스크립트를 미리 보내 한 차례 왕복을 줄일 수 있다는 목적을 다시 설명했다. 동시에 서버가 캐시 상태, 콘텐츠 협상, 이용자 행동을 고려해야 한다고 적었다. 예측을 잘못하면 더 중요한 응답이 필요로 하는 대역폭을 차지해 성능이 떨어질 수 있다. 클라이언트의 비활성화 설정도 유지됐다.

규격은 교환 방법을 정할 수 있지만 브라우저 팀이 계속 수신 코드를 유지해야 하는 이유까지 만들어 주지는 않는다. 밀어 넣은 흐름을 처리하려면 메모리, 캐시 조정, 우선순위 관리가 필요하다. 그 작업에 비해 체감 이익이 작아지면 기능의 운명은 문서보다 제품 결정에 좌우된다.

Chrome은 2022년 8월 106 버전에서 HTTP/2 Server Push를 기본으로 끄겠다고 예고했다. 안정적인 속도 향상을 얻기 어렵고 경우에 따라 성능이 나빠졌다는 설명을 붙였다. Chrome 106의 제거 공지는 조치를 구체적으로 적었다. 서버가 보낸 HTTP/2 push 흐름을 받아 메모리에 두고 사용하는 능력을 없앴다. 개정 표준은 허용을 유지했고 브라우저는 받는 일을 멈췄다.

파일 대신 힌트를 보내다

Chrome은 제거 설명에서 103 Early Hints와 사전 로드를 대안으로 들었다. 힌트는 필요할 법한 자원을 일찍 알려 주고, 브라우저가 캐시를 살펴 실제로 요청할지 결정하게 한다. Server Push와의 차이는 선명하다. 전자는 서버가 완성된 응답을 먼저 보내는 방식이었고, 대안은 브라우저에게 결정을 남겼다.

2015년에는 서버가 먼저 움직일 수 있는 길이 생겼다. 2022년 표준은 그 길의 함정을 기록했고 Chrome은 수신 창구를 닫았다. HTTP/2 자체는 계속 쓰였고 Server Push 규정도 남았다. 실제 브라우저가 더는 파일을 열지 않는다는 사실이 이 기능의 역사를 갈랐다.