Firefox, HTTP/2 Push 지원 중단 의도

 (groups.google.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Firefox는 낮은 활용도와 호환성 부담이 커진 HTTP/2 Push를 모든 플랫폼에서 며칠 내 비활성화하고, 구현 코드는 당분간 트리에 남겨둘 예정임
  • 브라우저 생태계에서는 이미 지원이 줄어들었고, Chrome 106은 2022년 9월 이를 껐으며 Safari 최신 버전도 로컬 테스트에서 push stream을 거부함
  • Chrome은 HTTP/2 Push의 낮은 사용량을 이유로 들며, 대체 수단으로 rel="preload" 와 103 Early Hints를 권장했음
  • Firefox는 유지 비용이 크지 않아 지원을 이어왔지만, 최근 몇 달간 HTTP/2 Push 때문에 Firefox에서만 발생하는 웹 호환성 버그가 나타남
  • 서버와 웹사이트가 push를 쓰면서 Firefox 테스트를 생략하면, 특정 사이트가 Firefox에서만 동작하지 않을 수 있음

Firefox의 HTTP/2 Push 비활성화 계획

  • Firefox는 모든 플랫폼에서 HTTP/2 Push를 비활성화할 예정임
  • 제거 작업은 Bugzilla의 1915848 - Pref off HTTP/2 push에서 추적됨
  • 지금은 preference로 끄고, 구현 코드는 당분간 트리에 남겨둠
  • 완전 제거는 내년 봄 ESR 140 브랜치 이전에 이뤄질 가능성이 높음

브라우저별 지원 상태와 비활성화 이유

  • Chrome

    • Chrome 106은 2022년 9월 HTTP/2 Push를 비활성화함
    • 관련 상태는 Chrome Platform Status에서 확인할 수 있음
    • Chrome은 낮은 사용량을 이유로 들었고, 대체 수단으로 rel="preload"와 103 Early Hints를 권장함

  • Safari

    • 공식적인 deprecation 자료는 확인하지 못했지만, 현재 버전은 Node.js 서버를 이용한 로컬 테스트에서 push stream을 거부함

  • Firefox

    • Firefox는 그동안 유지 부담이 크지 않아 HTTP/2 Push 지원을 계속해 왔음
    • 최근 몇 달간 HTTP/2 Push로 인해 Firefox에만 영향을 주는 웹 호환성 문제가 발생함
      • 관련 사례로 bug 1915830이 있음
      • 서버와 웹사이트가 push를 사용하면서 Firefox에서 테스트하지 않으면 Firefox에서만 사이트가 멈출 수 있으며, 예시로 bug 1913100이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • HTTP/2 Push가 결국 안 된다는 “갑작스러운 발견”이 나온 뒤에도, 예전부터 왜 안 될지 설명하다가 무시당했던 사람들에게 아무 사과도 없는 게 짜증남
    Google의 더 똑똑한 사람들이 필요하다고 하니 명세에 밀어 넣자던 분위기가 몇 년이나 있었고, 명세에는 훨씬 보수적으로 접근해야 함. Google 일부가 좋다고 생각한 추측성 확장 목표를 계속 넣는 식은 그만둬야 함

    • HTTP와 웹 성능을 개선한다는 게 별 의미 없어 보임. 이미 1080p 동영상 스트리밍이 가능할 만큼 대역폭이 있고, 실시간 게임을 할 만큼 지연도 낮으며, 처음 온라인에 접속했을 때보다 CPU는 1000배 강력함
      브라우저를 느리게 만드는 건 대부분 사이트를 짓누르는 광고, 추적기, 잡동사니뿐이고, 그걸 고치는 데 쓰는 건 Google 발명품이 아니라 uBlock Origin임. 요즘 Google이 웹 표준에 밀어 넣는 것들은 평범한 개발자를 위한 게 아니라 광고를 더 넣거나 데이터센터 비용 0.1%를 아끼기 위한 것처럼 보임
    • 예전부터 비그래픽 웹 사용, 예컨대 빠르고 비상호작용적인 정보 검색에는 HTTP/2보다 HTTP/1.1 파이프라이닝이 더 만족스러웠다고 말하면 HN에서 다운보트와 비꼬는 답을 받곤 했음
      HTTP/2는 한 회사가 자기 이익에 맞춰 공공 자원인 www 접근을 계속 통제하려는 사례처럼 보임. Chrome을 쓰면 HTTP/2를 시도하게 되고, 같은 회사가 검색 엔진, 하드웨어, 브라우저, 이제는 네트워크 프로토콜까지 통제함. HTTP/2는 사실상 HTTP/Chrome이라고 봐도 됨
    • 그 사람들에게는 연간 승진 자료가 정말 필요했던 거라고 이해해 달라
    • 너무 일찍 맞힌 건 틀린 것과 같음

  • HTTP/2 Push가 실패한 이유로 제시된 설명들이 설득력 있게 느껴진 적이 없음. Google은 보통 Jake Archibald의 글을 가리키지만, 그 글은 프로토콜 자체가 안 되는 이유라기보다 브라우저 구현이 얼마나 부실했는지를 나열하는 쪽에 가까워 보임
    브라우저는 이미 preload 링크를 지원하고, 이는 Push 헤더와 사실상 같은 역할을 해야 함. 캐싱이나 인증 헤더 같은 2017년 구현의 난점도 기존 preload 처리 코드를 재사용할 수 없었는지 의문임
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload 헤더는 HTTP/2 Push와 “사실상 같다”고 볼 수 없음. 결과가 비슷할 수는 있지만 동작 방식은 다르고, “Preload”라는 단어를 쓴다는 아주 피상적인 부분을 빼면 꽤 다름
      HTTP/2 Push는 서버가 클라이언트에 필요하다고 판단한 리소스를 선제적으로 밀어 넣어 왕복 1회를 줄이는 방식이고, DOM→렌더 파이프라인과 별개로 리소스를 보내 지연을 줄이는 게 목표임. Preload 헤더는 서버가 본문과 함께 병렬 로드할 리소스를 알려 줘 파싱이나 JS 평가 전에 가져오게 하는 방식임. 103 Early Hints는 응답 생성이 끝나기 전, 본문 첫 바이트보다 앞서 Preload 힌트를 보내 가져오기 단계를 더 앞당김
      핵심 차이는 서버 주도냐 클라이언트 주도냐, 본문과 함께냐 첫 바이트 이전이냐에 있음. HTTP/2 Push가 목표 달성에 약한 가장 단순한 이유는 캐시 때문임. 브라우저는 이미 가진 리소스를 요청하지 않지만, 서버는 클라이언트 캐시에 무엇이 있는지 모름. Push는 필요 없는 리소스를 보낼 위험이 크고, 103/Preload는 틀려도 쓸모없는 헤더 몇 바이트 정도가 낭비될 뿐이라 구현도 쉽고 비용도 낮음
    • Push 명세에 대한 이해가 명세만큼이나 녹슬어 있었음. 서버가 클라이언트에 필요하다고 예상한 전체 콘텐츠를 실제로 밀어 넣는다는 점을 잊고 있었고, preload 링크처럼 의존성을 암시하는 헤더만 요청에 포함되는 것으로 착각했음
    • 보안상 밀어 넣은 리소스는 페이지가 가져가기 전까지 특수한 경우로 다뤄야 하고, 그중 하나로 별도 캐시가 필요함
    • Push 제거의 핑계가 특히 우스운 건 개발자들이 애초에 Push를 제대로 활용할 기회를 거의 얻지 못했기 때문임. 들어오는 Push를 볼 수도 없고, 그에 반응할 수도 없었음
      https://github.com/whatwg/fetch/issues/51
      모두가 집중하던 콘텐츠 전달 사용 사례에도 아직 기회가 많았던 것 같음. 공개적으로 보이는 시도도 많지 않았고, 어떤 것을 Push해야 할지 실험해 볼 라이브러리나 출발점에 접근할 수 있었던 사람도 거의 없었음

  • HTTP/3 0-RTT 시작으로 일부 속도를 되찾고, 103 Early Hints로 브라우저가 자산을 일찍 미리 불러오게 할 수 있음. 이 조합은 HTTP/1과 의미적으로 하위 호환된다는 장점도 있음. 역방향 프록시나 로드 밸런서에서도 다루기 쉬움

  • HTTP/2 Push가 결국 사라지는 걸 보니 조금 아쉬움. 아이디어는 깔끔했지만 프레임워크 채택이 부진했고, 더 많은 관심을 받았다면 좋았을 기능임
    .NET 쪽은 끝내 내보내지 않았고, nginx에는 기본 구현 정도가 있었음. 캐시 다이제스트가 없었던 것도 계속 발목을 잡았음. Chrome은 “어차피 아무도 눈치 못 챌 것”이라는 식의 이유를 일부 들어 제거했고, NAT에서 늘 훌륭하게 동작하는 UDP로 모든 걸 재설계하는 일이 더 중요했던 모양임

    • UDP와 NAT로 문제를 겪어 본 적은 없지만, 그게 사람들을 짜증나게 해서 IPv6 이전을 유도한다면 조용히 웃고 있겠음

  • HTTP/2가 표준화되기 전 Mike Belshe와 이야기했을 때도, 이미 이 기능은 이점 실현이 어렵고 문제와 함정이 많아서 H2에서 빼려는 분위기가 있었음
    가장 큰 문제 중 하나는 브라우저 캐시에 이미 있는 것을 보내거나, 중요하지 않은 콘텐츠를 너무 많이 보내는 과도한 Push였음. 실제로 Push 때문에 페이지 로드가 더 느려진 아주 나쁜 사례도 봤음. 브라우저가 로컬 캐시에 무엇이 있는지 서버에 알려 주는 제안도 있었지만 여러 문제에 부딪힘. HTTP Early Hints와 Resource Hints가 H2 Push의 필요를 대체로 없앴고, 구현이 훨씬 쉽고 불필요한 가져오기를 피하며 이해하기도 쉬움

  • “웹서버와 웹사이트가 Push를 쓰면서 Firefox에서 테스트하지 않으면 Firefox에서만 사이트가 멈출 수 있다”는 해석도 가능하지만, 다른 해석도 가능함
    다른 브라우저는 HTTP/2 Push를 거부하고 조용히 무시하는 반면, Firefox는 일부 경계 조건에서 크게 넘어짐. 예컨대 “Firefox가 헤더 이름의 대문자를 만나 연결을 재설정하는 것 같다”는 내용임

    • 그 해석은 잘 맞지 않음. 다른 브라우저가 명세를 구현하지 않은 것이고, Firefox는 명세를 구현함. 명세는 이 위반을 어떻게 처리해야 하는지 매우 명확하며, 그런 웹서버와 웹사이트 구현이 깨진 것임. 명세 준수 클라이언트로 테스트했다면 깨졌다는 걸 알 수 있었을 것임
    • 글에서 분명히 말하고 있음. Firefox는 HTTP/2 Push 지원 비용이 최근까지 크지 않아 계속 지원했지만, 최근 몇 달 사이 Firefox에만 영향을 주는 웹 호환성 버그가 HTTP/2 Push를 통해 발생했음
      이 글은 다른 브라우저처럼 H2 Push를 거부하고 조용히 무시하겠다는 바로 그 조치를 설명하는 것으로 보이며, 뭔가 숨기는 것 같지는 않음
    • 반대로도 얼마든지 일어날 수 있었음. 새 명세가 한 브라우저에만 구현되고, 보통은 Chrome이 먼저 불완전하게 내보내는 경우가 많으며, 서버가 그것을 잘못 구현해서 같은 문제가 생기는 식임

  • Push가 왜 더 널리 채택되지 않았는지 궁금함. 큰 결함에도 불구하고 HTTP/2가 판도를 바꿀 기능으로 여겨진 큰 이유 중 하나였음
    브라우저 지원 부족이었는지, 아니면 CDN과 잘 맞지 않았던 건지 모르겠음

    • 서버 Push가 대규모로 배포되지 않은 이유는 해로울 수 있기 때문임. 서버는 클라이언트가 필요할 수도 있는 자산을 밀어 넣지만, 그 자산이 이미 클라이언트 캐시에 있을 수도 있음
      후자의 경우 특히 모바일에서는 해로운 부담이 됨. 서버는 그 자산이 실제로 클라이언트에 필요한지 절대 정확히 알 수 없음. Early Hints가 아마 더 낫고, 서버가 필요한 자산을 빠르게 알려 주면 클라이언트가 가져올지, 이미 있는지 판단할 수 있음
    • 사용을 검토했다가 마음을 바꿨음. Index.html 요청이 들어오면 보통 script.js와 style.css를 밀어 넣고 싶을 텐데, 그러면 수백 kbit를 보낸 셈이 됨
      사용자가 다시 index.html을 요청하면 또 전부 보내야 할까? 리소스는 이미 사용자 캐시에 있을 가능성이 큼. 보내지 않는다면 무엇을 보내야 할지 어떻게 알 수 있을까? 캐시에 무엇이 있고 없는지는 브라우저만 앎. 결국 첫 방문은 빠르게 하지만 재방문에서 대역폭을 낭비하거나, 첫 방문은 느리게 두고 재방문을 빠르게 하는 선택지가 됨
    • 판도를 바꾸는 기능이긴 했을 수 있지만, 그건 Google/Amazon/Meta 규모이거나 약간 작은 정도의 회사에 해당함
      그 외 대부분에게는 거대한 복잡도 증가였고, 사실상 무시됐음
    • Chrome이 Push 지원을 중단하기로 했을 때 낸 더 자세한 분석을 보면 도움이 될 수 있음
      https://developer.chrome.com/blog/removing-push/
    • 충분한 시간이 주어지지 않았던 것 같음. HTTP/2 RFC가 마무리된 2015년에야 HTTP/2 지원을 포함한 첫 Apache 릴리스가 나왔고, 2017년에도 서버 Push 처리 방식에 브라우저 간 불일치가 있었음
      nginx의 Push 지원은 위키백과 기준으로 2018년쯤 들어간 것으로 보임. 이런 변화가 안정 배포판 버전과 기본 설정까지 내려오는 데는 시간이 필요함. 내 Apache 서버에서 처음 HTTP/2를 켠 것도 2020년이었고, 2024년에도 직접 지원하지 않는 애플리케이션 서버가 있을 가능성이 큼

  • … Firefox에서 말임

    • 이미 다른 곳에서는 다 제거된 것 같음

  • 관련 글로 보임. 더 있을까?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - 2022년 8월, 댓글 201개
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - 2022년 7월, 댓글 2개
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - 2020년 12월, 댓글 168개
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - 2020년 11월, 댓글 133개
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - 2020년 9월, 댓글 2개
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - 2020년 1월, 댓글 71개
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - 2018년 10월, 댓글 16개
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - 2018년 2월, 댓글 63개
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - 2017년 7월, 댓글 23개
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - 2017년 5월, 댓글 20개
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - 2017년 4월, 댓글 59개
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - 2017년 3월, 댓글 2개
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - 2017년 2월, 댓글 9개
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - 2016년 8월, 댓글 6개
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - 2016년 8월, 댓글 25개
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - 2016년 8월, 댓글 2개
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - 2016년 2월, 댓글 13개

  • 놀랍지 않음. 특정 목적을 위해 만든 기존 프로토콜 위에 원래 설계 목표와 거의 관련 없는 기능을 덧붙이면 보통 이렇게 됨
    대부분은 낮은 수준의 프로토콜에서 시작해 바로 사용 사례에 맞추는 편이 낫고, 그런 면에서 WebSockets가 양방향 통신 문제를 이미 우아하게 풀었다고 봄. 깊은 파일/스크립트 계층을 로드할 때 지연을 줄이는 데는 rel="preload"나 rel="modulepreload" 태그가 훌륭하고 단순한 구조임

    • HTTP/2 Push는 지연을 줄인 preload 링크와 정확히 같은 사용 사례에 맞았을 것임
      요지는 서버가 미리 불러와야 할 콘텐츠를 헤더로 보내서, 링크 태그가 전송되거나 파싱되기 전부터 미리 불러오게 하는 것이었음. 스트리밍을 지원하는 페이지에는 덜 유용하겠지만, 전체 HTML 페이지가 서버 쪽에서 렌더링될 때까지 요청이 멈춰 있는 경우에는 눈에 띄는 이득이 있었을 수 있음
    • HTTP/2는 새로운 낮은 수준 프로토콜이었고, HTTP Push는 애초에 양방향 통신에 관한 기능이 아니었음
    • HTTP도 양방향 통신 아닌가?
답변달기