Firefox dự định ngừng hỗ trợ HTTP/2 Push

 (groups.google.com)
1 điểm bởi GN⁺ 2024-09-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Firefox sẽ vô hiệu hóa HTTP/2 Push trên mọi nền tảng trong vài ngày tới do mức độ sử dụng thấp và gánh nặng tương thích ngày càng tăng, đồng thời tạm thời vẫn giữ mã triển khai trong cây mã nguồn
  • Trong hệ sinh thái trình duyệt, hỗ trợ này đã suy giảm từ trước; Chrome 106 đã tắt nó vào tháng 9/2022, và phiên bản Safari mới nhất cũng từ chối push stream trong thử nghiệm cục bộ
  • Chrome cho biết lý do là HTTP/2 Push có mức sử dụng thấp, đồng thời khuyến nghị các phương án thay thế là rel="preload" và 103 Early Hints
  • Firefox trước đây vẫn duy trì hỗ trợ vì chi phí bảo trì không quá lớn, nhưng trong vài tháng gần đây, các lỗi tương thích web chỉ xảy ra trên Firefox đã xuất hiện do HTTP/2 Push
  • Khi máy chủ và website dùng push nhưng bỏ qua việc kiểm thử trên Firefox, một số trang có thể chỉ không hoạt động trên Firefox

Kế hoạch vô hiệu hóa HTTP/2 Push của Firefox

  • Firefox dự định vô hiệu hóa HTTP/2 Push trên mọi nền tảng
  • Việc loại bỏ đang được theo dõi tại Bugzilla: 1915848 - Pref off HTTP/2 push
  • Hiện tại sẽ tắt bằng preference, còn mã triển khai sẽ vẫn được giữ lại trong cây mã nguồn một thời gian
  • Việc loại bỏ hoàn toàn nhiều khả năng sẽ diễn ra trước nhánh ESR 140 vào mùa xuân năm sau

Tình trạng hỗ trợ theo trình duyệt và lý do vô hiệu hóa

  • Chrome

    • Chrome 106 đã vô hiệu hóa HTTP/2 Push vào tháng 9/2022
    • Có thể xem trạng thái liên quan tại Chrome Platform Status
    • Chrome nêu lý do là mức sử dụng thấp và khuyến nghị rel="preload" cùng 103 Early Hints như các phương án thay thế

  • Safari

    • Chưa xác nhận được tài liệu deprecation chính thức, nhưng phiên bản hiện tại từ chối push stream trong thử nghiệm cục bộ dùng máy chủ Node.js

  • Firefox

    • Firefox trong thời gian qua vẫn tiếp tục hỗ trợ HTTP/2 Push vì gánh nặng duy trì không lớn
    • Tuy nhiên trong vài tháng gần đây đã phát sinh các vấn đề tương thích web chỉ ảnh hưởng đến Firefox do HTTP/2 Push
      • Một trường hợp liên quan là bug 1915830
      • Khi máy chủ và website sử dụng push nhưng không kiểm thử trên Firefox, trang có thể chỉ bị treo trên Firefox; ví dụ là bug 1913100

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-08
Ý kiến trên Hacker News

  • Thật khó chịu là ngay cả sau “phát hiện đột ngột” rằng HTTP/2 Push rốt cuộc không ổn, vẫn chẳng có lời xin lỗi nào dành cho những người từ lâu đã giải thích vì sao nó sẽ không ổn nhưng bị phớt lờ.
    Suốt nhiều năm đã có bầu không khí kiểu: những người thông minh hơn ở Google nói là cần, vậy hãy nhét nó vào đặc tả; trong khi lẽ ra phải tiếp cận đặc tả một cách thận trọng hơn nhiều. Nên thôi kiểu liên tục đưa vào những mục tiêu mở rộng mang tính suy đoán mà một bộ phận Google cho là hay.

    • Việc cải thiện HTTP và hiệu năng web có vẻ không còn nhiều ý nghĩa. Chúng ta đã có đủ băng thông để stream video 1080p, độ trễ đủ thấp để chơi game thời gian thực, và CPU mạnh hơn 1000 lần so với khi tôi lần đầu lên mạng.
      Thứ làm trình duyệt chậm đi chủ yếu chỉ là quảng cáo, tracker và đủ thứ linh tinh đè nặng lên các website; và thứ dùng để sửa chuyện đó không phải phát minh của Google mà là uBlock Origin. Những thứ Google đang nhét vào các chuẩn web dạo này trông không giống để phục vụ lập trình viên bình thường, mà giống để chèn thêm quảng cáo hoặc tiết kiệm 0,1% chi phí trung tâm dữ liệu hơn.
    • Từ lâu, khi nói rằng với việc dùng web không đồ họa, chẳng hạn tra cứu thông tin nhanh và không tương tác, HTTP/1.1 pipelining đem lại cảm giác thỏa mãn hơn HTTP/2, tôi thường bị downvote và nhận những câu trả lời mỉa mai trên HN.
      HTTP/2 trông giống một ví dụ về việc một công ty tiếp tục kiểm soát quyền truy cập www, một tài nguyên công cộng, theo lợi ích của chính họ. Dùng Chrome thì nó sẽ thử HTTP/2, và cũng chính công ty đó kiểm soát công cụ tìm kiếm, phần cứng, trình duyệt, giờ là cả giao thức mạng. Có thể xem HTTP/2 thực chất là HTTP/Chrome.
    • Hãy thông cảm rằng những người đó thật sự cần tài liệu thăng chức hằng năm.
    • Đúng quá sớm thì cũng như sai.

  • Tôi chưa từng thấy các lời giải thích được đưa ra cho việc HTTP/2 Push thất bại là thuyết phục. Google thường trỏ tới bài của Jake Archibald, nhưng bài đó có vẻ giống liệt kê việc triển khai trên trình duyệt tệ đến mức nào hơn là lý do bản thân giao thức không hoạt động.
    Trình duyệt vốn đã hỗ trợ liên kết preload, và thứ này về cơ bản đáng ra phải đóng vai trò giống như header Push. Tôi cũng thắc mắc liệu các khó khăn triển khai năm 2017 như cache hay header xác thực có thật sự không thể tái sử dụng mã xử lý preload hiện có hay không.
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Header Preload không thể được xem là “về cơ bản giống” HTTP/2 Push. Kết quả có thể tương tự, nhưng cách hoạt động thì khác; ngoài điểm rất hời hợt là cùng dùng từ “Preload”, chúng khá khác nhau.
      HTTP/2 Push là cách máy chủ chủ động đẩy những tài nguyên mà nó cho rằng client cần, nhằm giảm một lượt round trip; mục tiêu là giảm độ trễ bằng cách gửi tài nguyên tách khỏi pipeline DOM→render. Header Preload là cách máy chủ cho biết các tài nguyên cần tải song song cùng phần thân, để trình duyệt lấy chúng trước khi parse hoặc đánh giá JS. 103 Early Hints gửi các gợi ý Preload trước khi việc tạo phản hồi hoàn tất, trước byte đầu tiên của phần thân, đẩy bước fetch lên sớm hơn nữa.
      Khác biệt cốt lõi nằm ở chỗ server-driven hay client-driven, đi cùng phần thân hay trước byte đầu tiên. Lý do đơn giản nhất khiến HTTP/2 Push yếu trong việc đạt mục tiêu là cache. Trình duyệt không yêu cầu tài nguyên mà nó đã có, nhưng máy chủ không biết trong cache của client có gì. Push có rủi ro lớn gửi tài nguyên không cần thiết, còn 103/Preload nếu sai thì chỉ lãng phí vài byte header vô dụng, nên dễ triển khai và chi phí thấp.
    • Hiểu biết của tôi về đặc tả Push cũng đã han gỉ chẳng kém gì chính đặc tả. Tôi đã quên mất rằng máy chủ thực sự đẩy toàn bộ nội dung mà nó dự đoán client sẽ cần, và nhầm tưởng rằng trong yêu cầu chỉ có các header ám chỉ phụ thuộc, giống như liên kết preload.
    • Vì lý do bảo mật, các tài nguyên được đẩy phải được xử lý như trường hợp đặc biệt cho đến khi trang lấy chúng, và một trong các điều đó là cần một cache riêng.
    • Điều đặc biệt buồn cười ở cái cớ loại bỏ Push là ngay từ đầu các lập trình viên gần như chưa bao giờ có cơ hội tận dụng Push đúng nghĩa. Họ không thể thấy các Push đi vào, cũng không thể phản ứng với chúng.
      https://github.com/whatwg/fetch/issues/51
      Có vẻ vẫn còn nhiều cơ hội ngay cả trong use case phân phối nội dung mà mọi người tập trung vào. Cũng không có nhiều thử nghiệm công khai, và rất ít người có thể tiếp cận thư viện hay điểm khởi đầu để thử nghiệm xem nên Push thứ gì.

  • Với khởi động 0-RTT của HTTP/3, có thể lấy lại một phần tốc độ, và với 103 Early Hints, trình duyệt có thể preload tài nguyên sớm. Tổ hợp này còn có ưu điểm là tương thích ngược về mặt ngữ nghĩa với HTTP/1. Nó cũng dễ xử lý hơn trong reverse proxy hoặc load balancer.

  • Thấy HTTP/2 Push cuối cùng biến mất cũng hơi tiếc. Ý tưởng rất gọn gàng, nhưng framework áp dụng kém; đây là một tính năng đáng lẽ nên được chú ý nhiều hơn.
    Phía .NET rốt cuộc không bao giờ phát hành, còn nginx có một mức triển khai cơ bản. Việc thiếu cache digest cũng liên tục cản trở. Chrome đã loại bỏ nó một phần với lý do kiểu “dù sao cũng chẳng ai nhận ra đâu”, và có vẻ việc thiết kế lại mọi thứ trên UDP, thứ lúc nào cũng hoạt động tuyệt vời qua NAT, quan trọng hơn.

    • Tôi chưa từng gặp vấn đề với UDP và NAT, nhưng nếu điều đó khiến mọi người khó chịu và thúc đẩy chuyển sang IPv6 thì tôi sẽ lặng lẽ mỉm cười.

  • Khi tôi nói chuyện với Mike Belshe trước khi HTTP/2 được chuẩn hóa, đã có xu hướng muốn bỏ tính năng này khỏi H2 vì lợi ích của nó khó hiện thực hóa, lại có nhiều vấn đề và cạm bẫy.
    Một trong những vấn đề lớn nhất là Push quá mức: gửi những thứ đã có trong cache trình duyệt, hoặc gửi quá nhiều nội dung không quan trọng. Thực tế tôi từng thấy những trường hợp rất tệ, trong đó Push làm trang tải chậm hơn. Cũng từng có đề xuất để trình duyệt cho máy chủ biết trong cache cục bộ có gì, nhưng vấp phải nhiều vấn đề. HTTP Early Hints và Resource Hints phần lớn đã thay thế nhu cầu H2 Push, đồng thời dễ triển khai hơn nhiều, tránh các lượt fetch không cần thiết và cũng dễ hiểu hơn.

  • Cũng có thể diễn giải rằng “nếu máy chủ web và website dùng Push mà không kiểm thử trên Firefox, site có thể chỉ bị đứng trên Firefox”, nhưng cũng có cách hiểu khác
    Trong khi các trình duyệt khác từ chối HTTP/2 Push và âm thầm bỏ qua, Firefox lại vấp khá nặng ở một số điều kiện biên. Chẳng hạn nội dung là “có vẻ Firefox đặt lại kết nối khi gặp chữ hoa trong tên header”

    • Cách diễn giải đó không thật phù hợp. Các trình duyệt khác không triển khai đặc tả, còn Firefox triển khai đặc tả. Đặc tả nói rất rõ phải xử lý vi phạm này như thế nào, và chính các triển khai máy chủ web và website như vậy mới bị lỗi. Nếu đã kiểm thử bằng client tuân thủ đặc tả thì lẽ ra đã biết là nó hỏng
    • Bài viết nói rất rõ. Firefox tiếp tục hỗ trợ vì chi phí hỗ trợ HTTP/2 Push cho đến gần đây không lớn, nhưng trong vài tháng gần đây, các lỗi tương thích web chỉ ảnh hưởng đến Firefox đã phát sinh thông qua HTTP/2 Push
      Bài viết này dường như mô tả đúng biện pháp đó: từ chối H2 Push và âm thầm bỏ qua như các trình duyệt khác, chứ không có vẻ như đang che giấu điều gì
    • Điều ngược lại cũng hoàn toàn có thể xảy ra. Một đặc tả mới chỉ được triển khai trên một trình duyệt, thường là Chrome phát hành trước ở trạng thái chưa hoàn chỉnh, rồi máy chủ triển khai sai theo đó và gây ra cùng một vấn đề

  • Tôi thắc mắc vì sao Push không được chấp nhận rộng rãi hơn. Bất chấp những khiếm khuyết lớn, đây từng là một trong những lý do chính khiến HTTP/2 được xem là tính năng có thể thay đổi cuộc chơi
    Không rõ là do thiếu hỗ trợ từ trình duyệt, hay do không hợp với CDN

    • Lý do Server Push không được triển khai ở quy mô lớn là vì nó có thể gây hại. Máy chủ đẩy vào các tài nguyên mà client có thể cần, nhưng các tài nguyên đó cũng có thể đã nằm trong cache của client
      Trong trường hợp sau, đặc biệt trên di động, nó trở thành gánh nặng có hại. Máy chủ không bao giờ có thể biết chính xác tài nguyên đó có thật sự cần cho client hay không. Early Hints có lẽ tốt hơn, vì nếu máy chủ nhanh chóng báo cho biết các tài nguyên cần thiết, client có thể quyết định sẽ tải về hay đã có sẵn
    • Tôi từng cân nhắc dùng rồi đổi ý. Khi có yêu cầu Index.html, thường bạn sẽ muốn đẩy kèm script.js và style.css, nhưng như vậy tức là đã gửi vài trăm kbit
      Nếu người dùng lại yêu cầu index.html, có phải gửi lại tất cả không? Rất có khả năng tài nguyên đã nằm trong cache của người dùng. Nếu không gửi thì làm sao biết nên gửi gì? Chỉ trình duyệt mới biết trong cache có gì và không có gì. Cuối cùng lựa chọn sẽ là làm lần truy cập đầu nhanh nhưng lãng phí băng thông ở các lần quay lại, hoặc để lần truy cập đầu chậm và làm lần quay lại nhanh
    • Có thể nó đúng là một tính năng thay đổi cuộc chơi, nhưng điều đó áp dụng cho các công ty cỡ Google/Amazon/Meta hoặc nhỏ hơn một chút
      Với hầu hết phần còn lại, đó là một mức tăng độ phức tạp khổng lồ và về cơ bản đã bị phớt lờ
    • Có thể hữu ích nếu xem phân tích chi tiết hơn mà Chrome đưa ra khi quyết định ngừng hỗ trợ Push
      https://developer.chrome.com/blog/removing-push/
    • Có vẻ nó đã không được cho đủ thời gian. Mãi đến năm 2015, khi RFC của HTTP/2 được hoàn tất, bản phát hành Apache đầu tiên có hỗ trợ HTTP/2 mới xuất hiện, và ngay cả năm 2017 vẫn còn bất nhất giữa các trình duyệt về cách xử lý Server Push
      Theo Wikipedia, hỗ trợ Push của nginx dường như được đưa vào khoảng năm 2018. Những thay đổi như vậy cần thời gian để đi xuống các phiên bản distro ổn định và cấu hình mặc định. Lần đầu tôi bật HTTP/2 trên máy chủ Apache của mình cũng là năm 2020, và đến năm 2024 vẫn có khả năng có các application server không hỗ trợ trực tiếp

  • … ý là trên Firefox

    • Có vẻ ở những nơi khác thì đã bị gỡ bỏ hết rồi

  • Có vẻ là các bài liên quan. Còn bài nào nữa không?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - tháng 8 năm 2022, 201 bình luận
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - tháng 7 năm 2022, 2 bình luận
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - tháng 12 năm 2020, 168 bình luận
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - tháng 11 năm 2020, 133 bình luận
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - tháng 9 năm 2020, 2 bình luận
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - tháng 1 năm 2020, 71 bình luận
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - tháng 10 năm 2018, 16 bình luận
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - tháng 2 năm 2018, 63 bình luận
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - tháng 7 năm 2017, 23 bình luận
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - tháng 5 năm 2017, 20 bình luận
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - tháng 4 năm 2017, 59 bình luận
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - tháng 3 năm 2017, 2 bình luận
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - tháng 2 năm 2017, 9 bình luận
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - tháng 8 năm 2016, 6 bình luận
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - tháng 8 năm 2016, 25 bình luận
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - tháng 8 năm 2016, 2 bình luận
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - tháng 2 năm 2016, 13 bình luận

  • Không có gì đáng ngạc nhiên. Khi gắn thêm một tính năng gần như chẳng liên quan đến mục tiêu thiết kế ban đầu lên trên một giao thức hiện có vốn được tạo ra cho một mục đích cụ thể, thường thì kết quả sẽ như thế này
    Phần lớn trường hợp nên bắt đầu từ một giao thức cấp thấp rồi điều chỉnh thẳng theo use case, và theo nghĩa đó, tôi cho rằng WebSockets đã giải quyết khá tao nhã bài toán giao tiếp hai chiều. Để giảm độ trễ khi tải các tầng file/script sâu, các thẻ rel="preload" hoặc rel="modulepreload" là một cấu trúc tuyệt vời và đơn giản

    • HTTP/2 Push hẳn đã phù hợp với đúng cùng use case như liên kết preload giúp giảm độ trễ
      Ý chính là server gửi nội dung cần tải trước qua header, để việc tải trước bắt đầu ngay cả trước khi thẻ link được truyền đi hoặc được phân tích cú pháp. Với các trang hỗ trợ streaming thì có thể kém hữu ích hơn, nhưng trong trường hợp request bị chặn cho đến khi toàn bộ trang HTML được render phía server, nó có thể đã đem lại lợi ích thấy rõ
    • HTTP/2 là một giao thức cấp thấp mới, còn HTTP Push ngay từ đầu không phải là tính năng về giao tiếp hai chiều
    • HTTP chẳng phải cũng là giao tiếp hai chiều sao?