腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)

本文原做者阮一峯，做者博客：ruanyifeng.com。

一、前言

新一代HTTP/2 協議的主要目的是爲了提升網頁性能（有關HTTP/2的介紹，請見《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》）。

HTTP/2之前版的頭信息（header）是直接傳輸文本，如今是壓縮後傳輸。原來是同一個 TCP 鏈接裏面，上一個迴應（response）發送完了，服務器才能發送下一個，如今能夠多個迴應一塊兒發送。

服務器推送（server push）是 HTTP/2 協議裏面惟一一個須要開發者本身配置的功能。其餘功能都是服務器和瀏覽器自動實現，不須要開發者關心。

本文詳細介紹新一代HTTP/2服務器推送技術（server push）的原理和配置方法等，更多資料請見IETF的http標準工做組維護的HTTP/2資料頁：https://http2.github.io/。

 

網絡編程學習交流：

- 即時通信開發交流3羣：185926912[推薦]

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

（本文同步發佈於：http://www.52im.net/thread-1795-1-1.html）

二、系列文章

本文是系列文章中的第4篇，本系列大綱以下：

《腦殘式網絡編程入門(一)：跟着動畫來學TCP三次握手和四次揮手》

《腦殘式網絡編程入門(二)：咱們在讀寫Socket時，究竟在讀寫什麼？》

《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》

《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》（本文）

三、傳統的網頁請求方式

下面是一個很是簡單的 HTML 網頁文件index.html：

 

hello world  

 

 

這個網頁包含一張樣式表style.css和一個圖片文件example.png。爲了渲染這個網頁，瀏覽器會發出三個請求。

第一個請求是index.html：

GET /index.html HTTP/1.1

服務器收到這個請求，就把index.html發送給瀏覽器。

瀏覽器發現裏面包含了樣式表和圖片，因而再發出兩個請求：

GET /style.css HTTP/1.1

GET /example.png HTTP/1.1

這就是傳統的網頁請求方式，它有兩個問題：

一是至少須要兩輪 HTTP 通訊；

二是收到樣式文件以前，網頁都會顯示一片空白，這個階段一旦超過2秒，用戶體驗就會很是很差。

四、傳統方式的改進

一種解決辦法就是：把外部資源合併在網頁文件裏面，減小 HTTP 請求。好比，把樣式表的內容寫在標籤之中，把圖片改爲 Base64 編碼的 Data URL。

另外一種方法就是資源的預加載（preload）：網頁預先告訴瀏覽器，當即下載某些資源。好比，上例能夠寫成下面這樣：

對於上例來講，preload命令並無什麼幫助。可是，若是前一個網頁就使用這個命令，預加載後一個網頁須要的資源，那麼用戶打開後一個網頁時，就會感受速度飛快。

這兩種方法都有缺點：

第一種方法雖然減小了 HTTP 請求，可是把不一樣類型的代碼合併在一個文件裏，違反了分工原則；

第二種方法只是提早了下載時間，並無減小 HTTP 請求。

五、服務器推送的概念

HTTP/2的服務器推送技術（server push）指的是，尚未收到瀏覽器的請求，服務器就把各類資源推送給瀏覽器。

好比：瀏覽器只請求了index.html，可是服務器把index.html、style.css、example.png所有發送給瀏覽器。這樣的話，只須要一輪 HTTP 通訊，瀏覽器就獲得了所有資源，提升了性能。

六、Nginx對HTTP/2服務端器推送技術的支持和實現

 

Nginx 從 1.13.9 版開始，支持服務器推送。我在《Nginx 容器教程》一文中已經介紹並作好了 Nginx 容器，接着就來體驗一下。

首先，進入工做目錄，把原來的首頁刪除：

$ cd nginx-docker-demo

$ rm html/index.html

而後，新建html/index.html文件，寫入本文第一節的網頁源碼。

另外，html子目錄下面，還要新建兩個文件example.png和style.css。前者能夠隨便找一張 PNG 圖片，後者要在裏面寫一些樣式：

h1{

  color: red;

}

最後，打開配置文件conf/conf.d/default.conf，將 443 端口的部分改爲下面的樣子：

server {

    listen 443 ssl http2;

    server_name  localhost;

 

    ssl                      on;

    ssl_certificate          /etc/nginx/certs/example.crt;

    ssl_certificate_key      /etc/nginx/certs/example.key;

 

    ssl_session_timeout  5m;

 

    ssl_ciphers HIGH:!aNULL:!MD5;

    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

    ssl_prefer_server_ciphers   on;

 

    location / {

      root   /usr/share/nginx/html;

      index  index.html index.htm;

      http2_push /style.css;

      http2_push /example.png;

    }

}

其實就是最後多了兩行http2_push命令。它的意思是，若是用戶請求根路徑/，就推送style.css和example.png。

如今能夠啓動容器了：

$ docker container run \

  --rm\

  --name mynginx \

  --volume "$PWD/html":/usr/share/nginx/html\

  --volume "$PWD/conf":/etc/nginx\

  -p 127.0.0.2:8080:80 \

  -p 127.0.0.2:8081:443 \

  -d \

  nginx

打開瀏覽器，訪問 https://127.0.0.2:8081 。瀏覽器會提示證書不安全，不去管它，繼續訪問，就能看到網頁了。

網頁上看不出來服務器推送，必須打開"開發者工具"，切換到 Network 面板，就能夠看到其實只發出了一次請求，style.css和example.png都是推送過來的：

 

查看完畢，關閉容器：

$ docker container stop mynginx

七、Apache 服務器上的實現

Apache 也相似，能夠在配置文件httpd.conf或者.htaccess裏面打開服務器推送：

 

    Header add Link "; rel=preload; as=style"

    Header add Link "; rel=preload; as=image"

八、服務器推送的另外一種實現方法：後端實現

上面的服務器推送，須要寫在服務器的配置文件裏面。這顯然很不方便，每次修改都要重啓服務，並且應用與服務器的配置不該該混在一塊兒。

服務器推送還有另外一個實現方法，就是後端應用產生 HTTP 迴應的頭信息Link命令。

服務器發現有這個頭信息，就會進行服務器推送：

Link: ; rel=preload; as=style

若是要推送多個資源，就寫成下面這樣。

若是要推送多個資源，就寫成下面這樣：

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

能夠參考 Go、Node、PHP 的實現範例。

這時，Nginx 的配置改爲下面這樣：

server {

    listen 443 ssl http2;

    # ...

    root /var/www/html;

    location = / {

        proxy_pass http://upstream;

        http2_push_preload on;

    }

}

若是服務器或者瀏覽器不支持 HTTP/2，那麼瀏覽器就會按照 preload 來處理這個頭信息，預加載指定的資源文件。

事實上，這個頭信息就是 preload 標準提出的，它的語法和as屬性的值都寫在了標準裏面。

九、緩存問題

服務器推送有一個很麻煩的問題。所要推送的資源文件，若是瀏覽器已經有緩存，推送就是浪費帶寬。即便推送的文件版本更新，瀏覽器也會優先使用本地緩存。

一種解決辦法是，只對第一次訪問的用戶開啓服務器推送。

下面是 Nginx 官方給出的示例，根據 Cookie 判斷是否爲第一次訪問：

server {

    listen 443 ssl http2 default_server;

    ssl_certificate ssl/certificate.pem;

    ssl_certificate_key ssl/key.pem;

    root /var/www/html;

    http2_push_preload on;

    location = /demo.html {

        add_header Set-Cookie "session=1";

        add_header Link $resources;

    }

}

map $http_cookie $resources {

    "~*session=1""";

    default "; as=style; rel=preload";

}

十、使用HTTP/2服務端推送帶來的性能提高

服務器推送能夠提升性能。網上測評的結果是，打開這項功能，比不打開時的 HTTP/2 快了8%，比將資源都嵌入網頁的 HTTP/1 快了5%。

 

能夠看到，提高程度也不是特別多，大概是幾百毫秒。並且，也不建議一次推送太多資源，這樣反而會拖累性能，由於瀏覽器不得不處理全部推送過來的資源。只推送 CSS 樣式表多是一個比較好的選擇。

（本文同步發佈於：http://www.52im.net/thread-1795-1-1.html）

附錄：更多網絡編程文章精選

若是您以爲《腦殘式網絡編程入門》系列文章過於基礎，您可直接閱讀如下系列：

《網絡編程懶人入門(一)：快速理解網絡通訊協議（上篇）》

《網絡編程懶人入門(二)：快速理解網絡通訊協議（下篇）》

《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》

《網絡編程懶人入門(四)：快速理解TCP和UDP的差別》

《網絡編程懶人入門(五)：快速理解爲何說UDP有時比TCP更有優點》

《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》

《鮮爲人知的網絡編程》系列文章爲高階必讀，該系列目錄以下：

《鮮爲人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》

《鮮爲人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》

《鮮爲人知的網絡編程(三)：關閉TCP鏈接時爲何會TIME_WAIT、CLOSE_WAIT》

《鮮爲人知的網絡編程(四)：深刻研究分析TCP的異常關閉》

《鮮爲人知的網絡編程(五)：UDP的鏈接性和負載均衡》

《鮮爲人知的網絡編程(六)：深刻地理解UDP協議並用好它》

關於移動端網絡特性及優化手段的總結性文章請見：

《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》

《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》

《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》

（本文同步發佈於：http://www.52im.net/thread-1795-1-1.html）