2.1 HTTP/1.1和當前的萬維網

在第1章，我們了解到HTTP是一種請求-響應協議，最初設計用于請求單個純文本內容，在請求完成后會終止連接。HTTP/1.0引入了其他媒體類型，例如支持圖像。HTTP/1.1確保在默認情況下開啟持久連接（假設網頁需要更多請求）。

這些是很好的改進，但是自上次修訂HTTP（1997年的HTTP/1.1版。盡管正式規范已經修訂了幾次，如第1章所述，在撰寫本書時還在進行修訂）以來互聯網發生了很大變化。如圖2.1所示，通過HTTP Archive趨勢網站（https://httparchive.org/reports/state-of-the-web），可以看到過去8年中網站的增長情況。忽略2017年5月左右的輕微下跌，那時HTTP Archive的測算出了點問題[1]。

可以看到，普通網站請求80～90個資源，下載近1.8 MB的數據（通過網絡傳輸的數據量，包括使用gzip或類似應用程序壓縮的文本資源）。未壓縮的網站現在超過3MB，這導致移動設備等低性能設備的其他問題。

計算這個平均值的樣本差異很大。例如，查看美國的Alexa排名前10的網站[3]，會看到表2.1中顯示的結果。

該表顯示，某些網站（如Wikipedia和Google）經過大幅優化后，需要加載的資源很少，但其他網站則需要加載數百個資源、數MB的數據。因此，查看網站的這些平均統計數據的價值之前一直受到質疑[4]。但無論如何，很明顯，資源增多、數據量增大是一個趨勢。網站的增長主要是因為媒體越來越豐富，例如，圖像和視頻在大多數網站上都很常見。此外，網站變得越來越復雜，需要多個框架和依賴項才能正確顯示其內容。

網頁最初都是靜態的頁面，但隨著Web的動態性變好，網頁開始在服務端動態生成，例如使用CGI（Common Gateway Interface，公共網關接口）或Java Servlet/Java Server Page（JSP）動態生成。隨后，從服務端生成完整頁面變成只生成基本HTML頁面，其他由客戶端JavaScript進行AJAX（Asynchronous JavaScript and XML）調用。這些AJAX調用向Web服務器發出額外請求，以更改網頁內容，而無須重新加載整頁或要求在服務端動態生成基本映像。你可以看看網絡搜索的變化。在網絡發展的早期，在搜索引擎出現之前，網站和網頁目錄是在網絡上查找信息的主要方式，它們是靜態的，偶爾才更新。然后第一個搜索引擎出現了，其允許用戶提交搜索表單并從服務器返回結果（服務端生成的動態頁面）。如今，大多數搜索網站會在你發出“搜索”命令之前在下拉菜單中提出建議。Google更進一步，在用戶輸入時即顯示結果（但它在2017年夏天撤銷了這一功能，因為越來越多的搜索轉移到移動設備，這種功能變得沒那么必要了）。

除了搜索引擎之外，各種網頁也大量使用AJAX請求，從加載新帖子的社交媒體網站到隨時更新的新聞網站。所有這些額外的媒體和AJAX請求使得網站化身為更有趣的網絡應用。然而，HTTP協議在設計之初并未考慮到資源的這種巨量增長，協議的簡單性設計不可避免地遇到了一些根本上的性能問題。

2.1.1 HTTP/1.1根本的性能問題

例如一個有一些文本和兩個圖像的簡單網頁。假設一個請求需要50 ms才能通過互聯網傳輸到Web服務器，并且該網站是靜態的（因此Web服務器從文件服務器中提取文件并將其發回，比如說，在10 ms內）。同樣，Web瀏覽器需要10 ms來處理圖像并發送下一個請求。這些數字是假設的。如果你有一個動態創建頁面的內容管理系統（CMS）（例如WordPress，其基于PHP來處理頁面），10 ms的服務器時間可能不準確，具體取決于服務器上正在進行的運算和數據庫操作。此外，與HTML頁面相比，圖像可能很大并且發送時間更長。在本章的后面我們會看到一些真實的例子，但是對于這個簡單的例子，HTTP的流程如圖2.2所示。

方框表示客戶端或服務端的處理，箭頭表示網絡流量。在這個假設的例子中，最明顯的是，來回發送消息需要花費多少時間。在繪制整個頁面所需的360 ms中，僅花費60 ms來處理客戶端或瀏覽器端的請求。總共需300 ms，或者說超過80％的時間用于等待消息在網絡上傳送。在此期間，Web瀏覽器和Web服務器都沒有做太多事情，這段時間被浪費了，這是HTTP協議的一個主要問題。在120 ms處，瀏覽器請求圖像1之后，它知道需要圖像2，但是在發送請求之前，它需要等待連接空閑，要等到240 ms之后。這個過程效率很低，不過有很多方法解決，稍后你會看到。例如，大多數瀏覽器都會打開多個連接。關鍵是基本的HTTP協議效率很低。

大多數網站不可能只由兩個圖像組成，圖2.2中所顯示的性能問題，隨著需要下載資源數量的增加會變得更嚴重。如果有一些較小的資源，相對于網絡傳輸時間，客戶端和服務器只花很少的時間去處理，這個問題會更明顯。

現代互聯網最大的問題之一是延遲而不是帶寬。延遲是將單個消息發送到服務器所需的時間，而帶寬是指用戶可以在這些消息中下載多少內容。較新的技術一直在增加帶寬（有助于解決網站內容增加的問題），但并不改善延遲問題（可以防止請求數量增加）。延遲受物理（光速）上的限制。通過光纖傳輸的數據，傳輸速度非常接近光速；無論技術有多大改進，速度都只能提升一點點。

Google的Mike Belshe做了一些實驗[5]，表明增加帶寬的收益已經開始衰減。我們現在可以流式傳輸高清視頻，但網速并沒改觀太多，即使是快速的連接，網站也需要幾秒鐘才能加載完。如果解決不了HTTP/1.1的根本性能問題，互聯網就無法繼續增長。在發送和接收HTTP消息時浪費了太多時間，盡管這些消息可能很小。

2.1.2 HTTP/1.1管道化

如第1章所述，HTTP/1.1嘗試引入管道化，從而在收到響應之前并發發出請求，實現并行發送請求。初始的HTML仍然需要單獨請求，但是當瀏覽器知道它需要兩個圖像時，它可以先后連續發出兩個請求。如圖2.3所示，在這個簡單的示例中，使用管道化操作可以縮短100 ms時間，也就是1/3的時間。

管道化技術應該會對HTTP帶來巨大的性能改善，但由于多種原因，它很難實現，易于出錯，并且沒有獲得Web瀏覽器和Web服務器的良好支持[6]。因此，它很少被使用。沒有一個主流的Web瀏覽器支持管道化技術[7]。

即使管道化技術得到了更好的支持，它仍然需要按照請求的順序返回響應。如果圖像2可用，但必須從另一臺服務器獲取圖像1，則圖像2的響應會等待，即使應該可以立即發送圖像2。此問題被稱為隊頭（HOL）阻塞問題，在其他網絡協議及HTTP中很常見。我們在第9章討論TCP隊頭阻塞問題。

2.1.3 網絡性能瀑布流圖

圖2.2和圖2.3中所示的請求和響應流通常以瀑布圖的形式顯示，左側是資源名，右側是使用時間。對于大量的資源，瀑布圖比圖2.2和2.3中的流程圖更容易閱讀。圖2.4顯示了我們假想的示例網站的瀑布圖，圖2.5顯示了使用管道化技術的相同網站的情況。

在這兩個示例中，第一條垂直線表示可以渲染初始頁面的時間（稱為開始繪制時間或開始渲染時間），第二條垂直線表示頁面何時加載完成。瀏覽器通常會在下載圖像之前嘗試繪制頁面，并在稍后填充圖像，因此圖像下載通常在這兩個時間之間。這兩個例子都很簡單，但實際應用會復雜得多，本章后面給出了一些案例。

可以使用各種工具，包括WebPagetest[8]和Web瀏覽器開發者工具（在第1章簡單介紹過）生成瀑布圖，這樣查看Web性能非常方便。大多數工具會將每個資源的總時間分解為不同部分，例如DNS查找和TCP連接時間，如圖2.6所示。

此圖提供了比簡單瀑布圖更多的信息。它將每個請求分成幾個部分，包括：

? DNS查詢

? 網絡連接時間

? HTTPS（或SSL）協商時間

? 請求的資源分類（并且還將資源負載分成兩部分，用于請求的顏色較淺，用于響應的顏色較深）

? 加載頁面各個階段的各種垂直線

? 其他圖表，顯示CPU使用率、網絡帶寬，以及瀏覽器工作在哪個主線程中

這些信息對于分析網站的性能非常有用。本書會大量使用瀑布圖解釋相關概念。