初識 HTTP/2(一)
用披薩來說明當你訂單數很大的時候 HTTP/2 是怎麼打敗 HTTP/1.1 的。
在建立網站和應用的方式上 HTTP/2 有些令人驚嘆的改變,在 HTTP/2 發布後的一年半,幾乎 10% 的網站使用了 HTTP/2。它絕對值得採用,但是這篇文章應該首先推給使用 HTTP/2 的前端開發者。這個連載的文章是指導前端開發者怎麼轉換到 HTTP/2。
本文涵蓋了 HTTP/2 對 HTTP/1.1 來說有什麼提高的內容,並且向前端開發者介紹了 HTTP/2。
再次讓我想起什麼是 HTTP ...
超文本傳輸協議,也就是 HTTP,這個協議決定了 web 內容怎麼傳輸。HTTP/1.1 在 1999 年被標準化,那時候的 web 和現在有很大的不同,表格霸佔了整個網路。樣式通常被內聯在元素中,如果網站管理員更加的細緻,他們會在頭部寫個 <style>
標籤。 JavaScript 也被丟在文檔裡面,那時候完整的網站通常也不會超過幾頁。
HTTP/1.1 預計這種情況會持續一段時間,所以它並沒有太過關注在讓一個站點可以載入大量的資源方面,因為那時候的開發者並不需要這個。因此它使用了一個非常簡單的方式來處理資源,你訪問一個資源然後伺服器去尋找它,並且返回你訪問的資源,或者告訴你這個資源不存在。這種被叫作"線頭堵塞"方式非常高效,但是當你需要多個資源的時候,這個進程會依次尋找每個資源。這意味著在你訪問第二個資源之前,伺服器必須找到你訪問的第一個資源並且載入它,或者告訴你沒找到。
大型站點的發展
在 1999 年之後的幾年裡,隨著 php 和其他像 Rails 這樣的動態語言的崛起,站點變得越來越複雜。css 文件也隨著向響應式開發的轉變而變的越來越大,因此像 Sass 這樣的可以創造一個簡單的工作環境的 CSS 編譯器就應運而生。 JavaScript 也在 web 上有了更大的作用,它允許開發者編寫複雜的應用,這曾經只是 C++ 開發人員的工作。隨著 Retina 和高清顯示屏的興起,也讓圖片變得更高清。隨著這些改變,文件大小呈現指數式的增長,使得本來是等待幾個位元組的資源變成了載入幾千位元組,甚至在某些情況下有幾兆。當你開始載入頁面的其它東西前,必須先載入數百 K 的東西,你只能樂觀的假設你的用戶有很快的網路接入。
想像 HTTP/1.1 是個過去的那種櫃檯購買式的街旁披薩店。你能自己過去並且預定一個雪碧和 2 片 Angry Hawaiian ,然後等待 3 分鐘。他們可以很容易地處理這些,實際上這是一個蓬勃發展的商業模式-定單簡單、處理迅速。
然而,一旦你決定在同樣的披薩店主辦一場小區域的季度頒獎典禮,事情就變的更複雜了。每個人都預定不同的東西,快速而雜亂無章讓等待時間直線上升。
哪裡是 HTTP/2 的舞台
HTTP/2 對前端開發者主要的承諾就是復用。意思就是資源請求能發生在同一時間,並且伺服器能馬上響應這些資源。在請求之間沒有等待,因為它們發生在同一時間。
使用同樣的比喻,HTTP/2 允許披薩店在餐館他們自己區域舉辦派對。派一個服務員接受訂單,並把所有已經準備好的訂單交付。當其他人的比薩在製作的時候,你也不需要花 30 分鐘去等待你的雪碧,它們在第一批交付的東西之中。這方式使得管理大量訂單更加簡單,並且防止人們等他們的訂單時間太長。
復用帶給我們的 web 開發的大變化是改變了文件的載入方式。幫助繞過資源載入的 HTTP/1.1 瓶頸的方式是通過連接和壓縮需要被載入的文件。所有任務運行器都默認採取這樣的操作方式,或者需要作一點小設置就行。和過去一樣,開發人員可以將圖像放在 精靈拼圖 中,這會減少了對伺服器的請求數。
改進 HTTP/1.1
將文件連接起來是個處理 HTTP1.1 的請求限制問題的非常聰明的方式,但是連接文件的主要問題是它要求用戶第一次訪問整個網站時下載所有的資源。一旦它們載入後,瀏覽器就會緩存所有的資源。這能提高用戶每次訪問網頁時的速度,但是前期負載很重,對跳出率不利。此外,他們可能為所不訪問的頁面載入資源。期望用戶訪問每個頁面以查看每個樣式,並與每個腳本進行交互是不現實的。此外,在加拿大和歐洲以及幾乎每個美國移動提供商的地方,有每月的帶寬上限。不是載入額外的 54 千位元組的內容就會超過每月的流量限制,而是讓我們假設用戶想保留這些額外的流量看 Taylor Swift 的 gif。
使用 HTTP/2 和多路復用,您可以開發一些最高效的網站,但它需要一些重新思考、甚至撤銷之前的最佳做法。重複一次,我的目的是加快 HTTP/2 的會話,使用我們新的工具,我們可以發現這些新的最佳的做法。
在我的下一篇文章,我將探索建設基於 HTTP/2 的網站的一些最好方式。
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive