摘要：記錄以下資源備忘也就是本文譯文標題為意譯，原標題為，恐有不當，特此說明。譯者注翻譯本文時譯者使用的確實無法看到信息，建議使用最新金絲雀版本一探究竟。應用程序不應當依賴于服務器推送的可用性及其使用。

本文轉載自：眾成翻譯
譯者：文藺
鏈接：http://www.zcfy.cc/article/883
原文：https://blog.cloudflare.com/http-2-server-push-with-multiple-assets-per-link-header/ 

譯者在做自己的一個小工具（抓取博客的 Chrome 擴展）的時候，使用 jQuery 輔助作為 DOM 解析器，為了避免加載圖片、腳本、樣式表等無用的資源，在將字符串傳給 $ 的時候，先對字符串中的相關標簽進行了處理。

但遇到某個網站的時候，一直疑惑不解，明明已經做了替換，但通過 Chrome Devtools 能看到，部分資源還是會下載。幾經折騰，發現還是因為自己懂得太少了。

查看請求該頁面時的 header，可以看到了如下信息：

link:; rel=preload; as=style, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image, ; rel=preload; as=image

于是，大概能猜出來上述問題的原因。這有點類似如一些站點會使用的 標簽（順帶一句，截至 2016 年 7 月 17 日，caniuse 數據：China = 26.83%；Global = 44.59%）。

于是深入挖掘了一下。來看看 W3C 標準是怎么說的（同樣由譯者翻譯）：

例如，應用可以使用 preload 關鍵詞，提前、高優先級、不阻塞渲染地拉取的 CSS 資源，它會在適當的時候被使用：

例一：使用標簽

例二：使用 HTTP Header

Link: ; rel=preload; as=style

上面的例子說明，資源可以通過聲明性標記、HTTP header link 來指定，或者使用 JavaScript 預定。

記錄以下資源備忘：

https://w3c.github.io/preload/

http://caniuse.com/#search=preload

http://stackoverflow.com/questions/36641137/how-exactly-does-link-rel-preload-work

https://blog.cloudflare.com/http-2-server-push-with-multiple-assets-per-link-header/（也就是本文）

譯文標題為意譯，原標題為 HTTP/2 Server Push with multiple assets per Link header，恐有不當，特此說明。

另，為加強理解 link 報頭與 HTTP/2 Server Push 二者，譯文正文后附有 W3C preload 標準中 “Server Push (HTTP/2)” 一節譯文。或有助于讀懂本文。

注： 譯文中凡是 “link 響應頭” 的名詞，英文為 “Link header”，翻譯為“響應頭 Link 字段”或許更恰當。

四月份的時候，我們宣布為所有的 CloudFlare 網站添加了 HTTP/2 Server Push 試驗性支持。這樣做是為了讓客戶能夠在該新功能的基礎上進行迭代。

CC BY 2.0 image by https://www.flickr.com/photos/mryipyop/

我們的 Server Push 實現，利用了 HTTP Link 報頭，這在 W3C Preload 工作草案中有詳細描述。

同樣，我們還展示了，如何在 PHP 代碼 中實現 Server Push，許多人已經開始測試、使用該特性了。

然而，我們的初始版本有很嚴格的限制：使用 Server Push，則每個 link 報頭中，最多只能指定一個資源，另外，很多 CMS 和 Web 開發平臺都不允許存在多個 link 報頭。

現在該問題已得到解決，多個資源可以通過單個 link 報頭推送。修改是實時生效的，如果你的瀏覽器支持 HTTP/2 的話，你正在閱讀的本文就使用了該方式推送資源。

當 CloudFlare 讀到源服務器（origin web server）的 link 報頭時，它從中移除其中已通過 Server Push 推送給瀏覽器的資源。這樣一來，要 debug link 和 Server Push 問題就困難了，所以我們又加上了一個叫做 Cf-H2-Pushed 的報頭，它包含已經推送過的資源。

舉個例子。打開最近的這篇博客，源服務器就會發送以下報頭：

Cache-Control: public, max-age=0
Content-Encoding: gzip
Content-Length: 33640
Content-Type: text/html; charset=utf-8
Date: Wed, 29 Jun 2016 16:09:37 GMT
Expires: Wed, 29 Jun 2016 16:10:07 GMT
Link: ; rel=preload; as=style,; rel=preload; as=script,; rel=preload; as=image,; rel=preload; as=image,; rel=preload; as=script,; rel=preload; as=script,; rel=preload; as=script
Vary: Accept-Encoding
X-Ghost-Cache-Status:From Cache
X-Powered-By: Express

CloudFlare 決定使用使用 HTTP/2 Server Push 推送這些資源：

 `/assets/css/screen.css?v=5fc240c512`,
 `/content/images/2016/06/Timeouts-001.png`,
 `/content/images/2016/06/Timeouts-002.png`,
 `/assets/js/jquery.fitvids.js?v=5fc240c512`

響應通過 CloudFlare 的時候，這些資源將從 link 報頭終移除，通過 Server Push 推送，并被添加到 Cf-H2-Pushed 報頭中：

cache-control:public, max-age=30
cf-cache-status:EXPIRED
cf-h2-pushed:,,,
content-encoding:gzip
content-type:text/html; charset=utf-8
date:Wed, 29 Jun 2016 16:09:37 GMT
expires:Wed, 29 Jun 2016 16:10:07 GMT
link:; rel=preload; as=script,; rel=preload; as=script,; rel=preload; as=script
server:cloudflare-nginx
status:200 OK
vary:Accept-Encoding
x-ghost-cache-status:From Cache
x-powered-by:Express 

在 Google Chrome 金絲雀版本（Google Chrome Canary）的開發者視圖中可以看得很清楚。（譯者注：翻譯本文時譯者使用的 Chrome 51.0.2704.106 m (64-bit) 確實無法看到 Push 信息，建議使用最新金絲雀版本一探究竟。）

如果你在使用 Server Push，請和我們聯系。推送不同類型的資源（圖片 vs 樣式表 vs 腳本）、解決最佳的推送數量（目前我們支持 每頁最多 50 條資源），我們對相關經驗十分感興趣。

原文地址： https://w3c.github.io/preload/#server-push-http-2

HTTP/2 ([RFC7540]) 允許服務器先發制人地向客戶端發送（“推送”）響應。推送的響應（pushed response）在語義上（semantically）與服務器對請求的響應（server responding to a request）是等價的，而且類似于預加載的響應（preloaded response）；它會被瀏覽器保存，在匹配到應用啟動的其他請求的時候被執行。像這樣的，從應用角度來看，使用預加載和服務器推送的請求，并無差別。

服務器可能會為應用定義的那些有權限的 preload link 資源啟用服務器推送。對那些聲明的 preload link 資源來說，啟用服務器推送消除了客戶端和服務器之間的請求往返。可選地，如果某個通過 link 報頭(RFC5988)聲明的資源不希望使用服務器推送，開發者*可以使用 nopush 目標屬性(RFC5988] section 5.4) 向服務器提供一個選擇性退出的信號。示例如下：

例三
Link: ; rel=preload; as=style; nopush
Link: ; rel=preload; as=script
Note
上面的示例，向一個可以使用 HTTP/2 推送的服務器提示， /app/style.css 不應被推送（例如，來源方可能有額外信息顯示其已經存在于緩存中），而  /app/script.js 應當可以作為服務器推送的候選資源。

為 preload link 啟用服務器推送是一個可選的優化項。比方說，服務器可能不會啟用推送，如果它認為響應在客戶端緩存中可以拿到：客戶端會處理預加載指令，檢查相關緩存，如果找不到資源則會發送請求。另外，服務器可能因為運維問題而不會啟用推送，比如說可用服務器資源或者其他考量。最后，服務器推送的啟用取決于協議的 HTTP/2 連接設置：客戶端可能會限制或完全禁用服務器推送的使用。應用程序不應當依賴于服務器推送的可用性及其使用。