HTTP/2登場，邁向新的紀元

前一回提到了，引領風騷十幾年的HTTP/1.1，即使有著主宰江湖的地位，但仍有若干眾所皆知的缺點。若能改進，則對整體網路的運作及應用，都能帶來大幅的改變。

SPDY與HTTP/2的淵源

做為網路世界的大腕，向來致力提升網路使用品質及體驗的Google，於 2009 年發表了一個名為SPDY的通訊協定，此一協定乃是基於TCP層之上的協定，其目標便是放在加強安全性及降低網頁的載入時間。不論是Google的Chrome或是Chromium，都支援自家所設計的SPDY通訊協定，之後包括Firefox、Opera，以及微軟的IE，都陸續提供了對SPDY的支援。

但即使如此，SPDY仍舊是非標準化的通訊協定，倘若SPDY要對網頁的存取加速起作用，不僅需要瀏覽器端的支援，同時也會需要伺服器端同樣的支援才行。

也正因如此，才會有積極推動HTTP/2標準化的動作。就在日前，主管Internet 通訊協定標準的IEFT宣布核準了HTTP/2的草案，這意謂著HTTP/2標準化的動作已近尾聲，它即將成為官方標準。

HTTP/2正是擷取SPDY協定主要精神及內容，而產生出來的下一代HTTP協定。在IETF宣布核準草案之後，Google隨即宣布將準備淘汰SPDY，改採HTTP/2，因為二者的重複性質很高。同時，另一個具有影響力的大公司──微軟，也宣布IE將支援HTTP/2。這代表了網路世界即將進入新時代。

從SPDY到HTTP/2，主要瞄準的即是HTTP/1.1的缺點，我們在前一回已概略介紹。而SPDY及HTTP/2是透過什麼樣的機制，來解決這些問題呢？

本質上，HTTP/1.1的單一連線中所用的「請求（request）－回應（response）」的通訊模式，是HTTP協定先天上的致命傷，因為，此一通訊模式造成了同時間存取多個檔案資源，必須同時建立多個連線，而且，每個連線在伺服器端完成回應處理前，都會有延遲，致使客戶端必須等待，也降低了連線傳輸的使用率。要改良HTTP，勢必要先從這一點著手。

因此，整個HTTP/2的主要精神，便是設計新的傳輸方式，首先，HTTP/2將原先以若干個文字行做為請求及回應開頭的方式，予以改變，而是轉而使用一個全二進位的格式來傳輸請求及內容。這讓HTTP/2足以帶來許多改進。

以二進位格式來傳輸，並可採取多連線複用

首先，HTTP原先含有文字行的格式處理上較為麻煩，剖析起來效率也較差，改用二進位格式，可以讓客戶端及伺服器端更好處理格式、效率也更好。

再者，在這個二進位化的新格式中，就更容易允許多連線的複用（multiplexing）。

多連線的複用是什麼意思呢？

在原先的HTTP/1.1中，每個HTTP連線都是基於一個TCP連線，但在同一個TCP連線中只能同時傳輸一個「請求－回應」，必須等待前一個請求的回應完成之後，才能重新在同一個TCP連線，傳輸下一個請求。但是，在HTTP/2的多連線複用機制下，便可以在一個實際的TCP連線，同時傳輸多個請求及和各請求相匹配的回應內容，在前一個請求尚未接收或接收完回應內容時，客戶端即可在同一TCP連線，發送其他的請求至伺服器端。

多連線的複用可以帶來諸多好處。

首先，每個客戶端針對伺服器，只需要建立一個TCP連線即可，不像過去，甚至需要管理一個小型的連線池（Connection Pool），可以省去一些資源。而資源的節省對伺服器來說，更明顯了，因為，過去每個客戶端都可能同時建立多個連線至伺服器端，必須佔用多份連線資源，在HTTP/2底下，都可以化約成一個。對於大規模的網站來說，單一伺服器所能服務的客戶端數目，有可能因此而提升。

更重要的是，在TCP連線的建立階段當中，因為具有 3-Way Handshaking ，以及「緩起步（Slow Start）」的特性，所以，會是相當耗時的。

而過去，HTTP協定傾向於產生短生命期的TCP連線，形同花了大把功夫建立了連線，卻用不了太久就予以切斷，因此而影響到其效能表現。再者，因為TCP做流量控制及擁塞控制的特性，多個TCP連線同時混在一起傳輸，也會影響到其演算法對單位時間內最適傳輸量的估算。

在採用多連線複用的設計之後，上述的問題可以獲得改善。

因為多個連線共用同一個TCP連線，因此，花一次建立連線的成本，可以套用在持續的多個TCP連線之上。在多連線複用的機制下，當某一個請求所匹配的回應尚未開始傳輸前，仍然可以傳輸其他請求及回應，因此，該TCP連線不會持續閒置。

從上述的說明不難發現，這個多連線複用的機制是效率改善的關鍵。而使用二進位的傳輸格式，也可以節省所傳輸的資料量，增加效率。

加入了特殊快取機制──由伺服器端主動推送至用戶端

HTTP/2還有一些其他的改進，像是對標頭的壓縮可以減少傳輸的資料量，自然而然可以提升傳輸的效能。此外，HTTP/2還引進了「伺服器推送（Server Push）」的機制。

所謂的「伺服器推送」，指的即是伺服器端可以預先將部份網頁中需要的內容，推送至客戶端的快取儲存空間中，讓資料傳輸更快。

一個網頁的內容，通常由一個HTML為主體，再搭配其他的元素，像是圖像、CSS檔案、或JavaScript 程式。在過去的HTTP中，瀏覽器載入網頁的典型模式會像是：先發出請求取回HTML的內容，接著剖析，並依據HTML的內容，再發出多個請求，分別取得該HTML中需要的其他檔案。但是，很多檔案的存取，其實是在伺服器端，就足以明白瀏覽器端所需要的部分，而上述的典型模式，就會造成了載入網頁整體內容的時間延遲。

為此，HTTP/2設計了伺服器推送的機制，讓伺服器可以在瀏覽器請求取得HTML內容時，也將其餘的檔案一併回傳予瀏覽器，並儲存於快取空間中，以利在接下來可能發生的其他請求時，便可直接自快取空間取得，而毋需再重新發送請求了。

相容於既有環境

在過去，針對HTTP/1.1的缺點，開發者也想出了一些Hacks 或是小技巧，在HTTP/2問世之後，可能都沒有存在的必要，像是批次型的REST API，讓你得以將多個API的呼叫，包裝在一次的連線請求中，以減少建立連線時造成的額外負擔。有了HTTP/2之後，這些方法就不再需要了，因為透過多連線複用，已經可以得到相同、甚至更好的效果。

在這份介紹的最後，必須提到很重要的一點就是，HTTP/2雖然是在新的傳輸協定之上運作，但是它本身並沒有改變HTTP/1.1的語義（semantics），也就是說，像狀態碼（status code）、方法（method）以及標頭（header）的意義，都維持不變。這意謂著，HTTP/2只會影響到瀏覽器及伺服器的實作，對於應用層次之上的程式來說，都不會受到影響。

HTTP/2協定包括了兩份文件，一份是協定本身，另一份則是HPACK，其中，HPACK所規範的是，HTTP的標頭如何進行壓縮，這也能降低HTTP標頭在傳輸時的流量耗用。

現在，整個網路界都在積極準備，邁向HTTP的新紀元，我們也期待HTTP/2能更快為網路世界做出貢獻。