腦殘式網路編程入門(四):快速理解HTTP/2的伺服器推送

腦殘式網路編程入門(四):快速理解HTTP/2的伺服器推送

來自專欄即時通訊技術分享4 人贊了文章

本文原作者阮一峰,作者博客:ruanyifeng.com

1、前言

新一代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資料頁:http2.github.io/

網路編程學習交流:

- 即時通訊開發交流3群:185926912[推薦]

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

(本文同步發佈於:52im.net/thread-1795-1-

2、系列文章

本文是系列文章中的第4篇,本系列大綱如下:

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

《腦殘式網路編程入門(二):我們在讀寫Socket時,究竟在讀寫什麼?》

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

《腦殘式網路編程入門(四):快速理解HTTP/2的伺服器推送(Server Push)》(本文)

3、傳統的網頁請求方式

下面是一個非常簡單的 HTML 網頁文件index.html:

<!DOCTYPE html>

<html>

<head>

<link rel="stylesheet" href="style.css">

</head>

<body>

<h1>hello world</h1>

<img src="example.png">

</body>

</html>

這個網頁包含一張樣式表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秒,用戶體驗就會非常不好。

4、傳統方式的改進

一種解決辦法就是:把外部資源合併在網頁文件裡面,減少 HTTP 請求。比如,把樣式表的內容寫在標籤之中,把圖片改成 Base64 編碼的 Data URL。

另一種方法就是資源的預載入(preload):網頁預先告訴瀏覽器,立即下載某些資源。比如,上例可以寫成下面這樣:

對於上例來說,preload命令並沒有什麼幫助。但是,如果前一個網頁就使用這個命令,預載入後一個網頁需要的資源,那麼用戶打開後一個網頁時,就會感覺速度飛快。

這兩種方法都有缺點:

第一種方法雖然減少了 HTTP 請求,但是把不同類型的代碼合併在一個文件里,違反了分工原則;

第二種方法只是提前了下載時間,並沒有減少 HTTP 請求。

5、伺服器推送的概念

HTTP/2的伺服器推送技術(server push)指的是,還沒有收到瀏覽器的請求,伺服器就把各種資源推送給瀏覽器。

比如:瀏覽器只請求了index.html,但是伺服器把index.html、style.css、example.png全部發送給瀏覽器。這樣的話,只需要一輪 HTTP 通信,瀏覽器就得到了全部資源,提高了性能。

6、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

7、Apache 伺服器上的實現

Apache 也類似,可以在配置文件httpd.conf或者.htaccess裡面打開伺服器推送:

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

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

8、伺服器推送的另一種實現方法:後端實現

上面的伺服器推送,需要寫在伺服器的配置文件裡面。這顯然很不方便,每次修改都要重啟服務,而且應用與伺服器的配置不應該混在一起。

伺服器推送還有另一個實現方法,就是後端應用產生 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 upstream;

http2_push_preload on;

}

}

如果伺服器或者瀏覽器不支持 HTTP/2,那麼瀏覽器就會按照 preload 來處理這個頭信息,預載入指定的資源文件。

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

9、緩存問題

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

一種解決辦法是,只對第一次訪問的用戶開啟伺服器推送。

下面是 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";

}

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

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

可以看到,提升程度也不是特別多,大概是幾百毫秒。而且,也不建議一次推送太多資源,這樣反而會拖累性能,因為瀏覽器不得不處理所有推送過來的資源。只推送 CSS 樣式表可能是一個比較好的選擇。

(本文同步發佈於:52im.net/thread-1795-1-

附錄:更多網路編程文章精選

如果您覺得《腦殘式網路編程入門》系列文章過於基礎,您可直接閱讀以下系列:

《網路編程懶人入門(一):快速理解網路通信協議(上篇)》

《網路編程懶人入門(二):快速理解網路通信協議(下篇)》

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

《網路編程懶人入門(四):快速理解TCP和UDP的差異》

《網路編程懶人入門(五):快速理解為什麼說UDP有時比TCP更有優勢》

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

《不為人知的網路編程》系列文章為高階必讀,該系列目錄如下:

《不為人知的網路編程(一):淺析TCP協議中的疑難雜症(上篇)》

《不為人知的網路編程(二):淺析TCP協議中的疑難雜症(下篇)》

《不為人知的網路編程(三):關閉TCP連接時為什麼會TIME_WAIT、CLOSE_WAIT》

《不為人知的網路編程(四):深入研究分析TCP的異常關閉》

《不為人知的網路編程(五):UDP的連接性和負載均衡》

《不為人知的網路編程(六):深入地理解UDP協議並用好它》

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

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

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

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

(本文同步發佈於:52im.net/thread-1795-1-


推薦閱讀:

【科技】恐懼竟然能夠聞得到?
關於小米港股IPO的一些科普
發展狀況:2018年5月第三周技術總結
分享逗比本人的第一桶金
小程序增長五部曲:100天實現2000萬流水

TAG:科技 | 計算機科學 |