2.4 實(shí)際案例

之前我們講過，對于多個連接，HTTP/1.1并不高效，但是情況有多糟呢？問題突出嗎？下面我們來看一些實(shí)際案例。

2.4.1 示例網(wǎng)站1: amazon.com

之前講的都是理論，現(xiàn)在看一個實(shí)際的案例。在www.webpagetest.org中輸入www.amazon.com并執(zhí)行，會看到如圖2.10所示的瀑布圖。本圖說明了HTTP/1.1的很多問題：

? 首個請求是主頁的請求，我們將其在圖2.11中放大顯示。

在發(fā)送請求之前，需要花費(fèi)時間做DNS解析（創(chuàng)建連接、進(jìn)行SSL/TLS HTTPS協(xié)商）。這個時間比較短（如圖2.11所示，只要0.1 s多一點(diǎn)），但這增加了時間。對于首個連接，沒有太多可以做的。該結(jié)果反映互聯(lián)網(wǎng)運(yùn)行的方式，如第1章所述。并且，盡管HTTPS算法和協(xié)議的提升可以減少SSL時間，但首個請求也是這些延遲的影響因素。我們能夠做的是確保服務(wù)器響應(yīng)迅速，且離用戶近，以保持?jǐn)?shù)據(jù)往返時間盡可能短。在第3章，我們會討論CDN（Content Delivery Networks，內(nèi)容分發(fā)網(wǎng)絡(luò)），它能解決這個問題。

在初始化完成之后，有一個短暫的暫停。我無法解釋暫停的原因，可能是因?yàn)殚_發(fā)者工具計(jì)時有一點(diǎn)不精確，或者是Chrome瀏覽器的問題。使用Firefox沒有遇到這個暫停。然后，瀏覽器發(fā)出第一個HTTP請求（淺色的條），下載HTML（稍深顏色的條），解析，執(zhí)行。

? HTML引用了幾個CSS文件，它們也會被下載，如圖2.12所示。

? 這些CSS文件托管在另外一個域（images-na.ssl-images- amazon.com），出于性能考慮，此域名和主域名不同。由于域名是獨(dú)立的，所以在下載CSS文件時，需要從頭開始，再來一次DNS查詢、網(wǎng)絡(luò)連接和HTTPS協(xié)商。請求1的創(chuàng)建時間在某種程度上是不可避免的，但第2個請求的創(chuàng)建時間是可以避免的。域名分片只是為了解決HTTP/1.1的性能問題。同時也要注意，在請求1中，當(dāng)瀏覽器還在處理HTML頁面時，CSS請求就開始了。盡管HTML頁面在0.5 s之后才下載完，請求2在0.4 s前一點(diǎn)就開始了。瀏覽器不需要等整個HTML頁面下載處理完才開始下載其他資源，它只要發(fā)現(xiàn)域名引用就開啟新的資源請求（盡管由于連接創(chuàng)建延遲，新的資源在HTML下載完成時還沒有進(jìn)入下載流程）。

? 第三個請求是同一個域名上的CSS資源。由于HTTP/1.1在一個連接上同一時間只允許執(zhí)行一個請求，因此瀏覽器創(chuàng)建了另外一個連接。這次省去了DNS查詢時間（通過請求2，已經(jīng)知道域名的IP地址了），但是在請求CSS之前，還需要進(jìn)行耗時的TCP/IP連接創(chuàng)建和HTTPS協(xié)商。這個額外的連接存在的意義只是為了解決HTTP/1.1性能問題。

? 之后瀏覽器通過這兩個已經(jīng)創(chuàng)建的連接請求了另外3個CSS文件。圖中沒有說明為什么瀏覽器沒有直接請求這些文件，這樣會需要更多連接，花費(fèi)更多資源。我看了Amazon的源碼，在CSS文件請求之前有一個<script>標(biāo)簽，直到它執(zhí)行完成后，才開始加載資源。這就解釋了，為什么請求4、5、6沒有和請求2、3同時發(fā)起。這一點(diǎn)很重要，后面我們會講，HTTP/1.1的效率問題是互聯(lián)網(wǎng)的其中一問題，這可以通過改善HTTP（如HTTP/2）來解決，但網(wǎng)絡(luò)慢遠(yuǎn)遠(yuǎn)不止這一個原因。

? 在第2～6個請求中，加載CSS文件之后，瀏覽器認(rèn)為接下來要加載圖片，于是開始下載圖片，如圖2.13所示。

? 請求7中的首個.png文件，是由多個圖標(biāo)合成的精靈圖（在圖2.13中未顯示），這是Amazon實(shí)現(xiàn)的另外一個優(yōu)化。從請求8開始，加載了一些.jpg文件。

? 當(dāng)有兩個圖片在請求中時，瀏覽器需要創(chuàng)建更多消耗性能的連接，以并行下載資源，如請求9、10、11和15。然后對請求14、17、18和19使用不同的域名。

- 在一些場景下（請求9、10和11），瀏覽器猜測可能需要更多的連接，所以提前創(chuàng)建連接，這就是為什么連接創(chuàng)建和SSL發(fā)生得更早，而且可以和請求7、8同時發(fā)出圖片請求。

- Amazon添加了一個性能優(yōu)化的方法，對m.media-amazon.com使用DNS prefetch（預(yù)解析）[13]。奇怪的是，沒有對fls-na.amazon.com添加prefetch。這就是為什么，請求17的DNS解析過程發(fā)生在0.6 s，在發(fā)請求之前。在第6章我們會再次討論這個問題。

在這些請求之后，頁面還要加載更多內(nèi)容，但是這些請求足以說明HTTP/1.1的問題了。所以不用查看整個網(wǎng)站的請求。

為了防止請求排隊(duì)，需要創(chuàng)建很多連接。通常，這會導(dǎo)致下載資源花費(fèi)的總時間翻倍。Web Page Test有個很方便的連接視圖[14]（如圖2.14所示），我們可以通過該視圖看看大致情況）。

可以看到，加載amazon.com主頁需要20個連接，這還沒算廣告資源，它需要28個請求（圖2.14中未顯示）。images-na.ssl-images-amazon.com域名的前6個連接已經(jīng)被充分利用了（連接3～8），但此域名的另外4個連接沒有被好好利用（連接9～12）。有些連接（如連接15、16、17、18、19、20），只用來加載一兩個資源，那創(chuàng)建這些連接的時間就有些浪費(fèi)。

在images-na.ssl-images-amazon.com域名上創(chuàng)建額外4個連接（為什么Chrome看起來突破了每個域名6個連接的限制）的原因非常有趣，我們需要研究一下。請求可以攜帶認(rèn)證信息（經(jīng)常使用cookie），也可以不帶，Chrome通過不同的連接來處理這兩類請求。出于安全上的考慮（參考瀏覽器如何處理跨域請求[15]），Amazon在對JavaScript文件的一部分請求中使用了setAttribute ("crossorigin","anonymous")，即不帶認(rèn)證信息，這意味著不使用現(xiàn)有的連接。所以，瀏覽器創(chuàng)建了更多的連接。這個屬性對于HTML頁面中的<script>標(biāo)簽直接發(fā)起的JavaScript請求來說，不是必需的。對于主域上托管的資源，這個變通的方法也不必要，這再一次說明在HTTP層面，域名分片可能效率低下。

Amazon的示例說明，在HTTP/1.1下，就算網(wǎng)站通過變通的方法進(jìn)行了充分的性能優(yōu)化，它還是會有一些性能問題。這些優(yōu)化方法設(shè)置起來也很復(fù)雜。不是每個網(wǎng)站都想管理多個域名，都需要做精靈圖，或者將JavaScript（或CSS）合并起來。也不是每個網(wǎng)站都像Amazon一樣有能力、有資源做這些優(yōu)化。更小的網(wǎng)站通常沒做太多優(yōu)化，性能受HTTP/1的限制影響較大。

2.4.2 示例網(wǎng)站2：imgur.com

如果不做這些優(yōu)化，會怎樣？我們以imgur.com為例來了解一下。因?yàn)樗且粋€圖片分享網(wǎng)站，所以在主頁會加載大量圖片，而且不會將它們合并為精靈圖。我截了WebPagetest瀑布圖的一部分，如圖2.15所示。

我們跳過網(wǎng)頁加載的第一部分（在請求31之前的部分），因?yàn)檫@部分和amazon.com有大量重復(fù)。可以看到，它使用最大6個連接去加載請求31～36，之后的請求在排隊(duì)。當(dāng)每6個請求完成后，開始新的6個請求，這就形成了圖2-1所示的瀑布圖。注意，這6個請求之間沒有關(guān)聯(lián)，可能在不同的時間完成（如瀑布圖中后面的部分所示），但如果它們的大小接近，則它們常常同時完成。這就產(chǎn)生了6個請求互相關(guān)聯(lián)的假象，但在HTTP層面，它們確實(shí)沒有關(guān)聯(lián)（除了它們共享同樣帶寬、連接同樣的服務(wù)器之外）。

Chrome的瀑布圖如圖2.16所示。在該圖中，問題更清晰，因?yàn)樗瑫r計(jì)算了資源從可以加載到開始加載的時間。你能看到，對于后續(xù)的請求，在圖片請求之前有一個很長的延遲（方框高亮顯示），后面跟一個相對較短的下載時間。

2.4.3 這個問題究竟有多嚴(yán)重

本章一直在討論HTTP效率低下的問題，雖然存在一些變通的解決方案，但是，這些解決方案并不完善。為此，需要花時間和資金，需要理解如何實(shí)現(xiàn)、如何維護(hù)，而且它本身也有性能問題。開發(fā)的成本并不便宜，花時間兼容一個效率低下的協(xié)議雖然有必要，但是成本高昂（更不用說，很多網(wǎng)站沒意識到他們網(wǎng)站性能對他們的影響）。很多研究表明，網(wǎng)站緩慢會導(dǎo)致用戶離開，訂單減少。[16]，[17]

你必須認(rèn)識到，和其他性能問題想比，HTTP協(xié)議的問題有多嚴(yán)重。導(dǎo)致網(wǎng)站緩慢的原因很多，從網(wǎng)絡(luò)連接的質(zhì)量到網(wǎng)站的大小，再到某些網(wǎng)站可能使用荒唐的JavaScript文件數(shù)，再到越來越多的性能低下的廣告、數(shù)據(jù)追蹤服務(wù)，等等。盡管更高效和更快地下載資源可以解決一部分問題，但是很多網(wǎng)站還是會慢。很多網(wǎng)站清楚地知道HTTP協(xié)議對網(wǎng)站性能的影響，所以他們實(shí)現(xiàn)了一些優(yōu)化HTTP/1.1性能的方法。但是因?yàn)檫@些方法復(fù)雜且難以理解，所以很多其他的網(wǎng)站沒有實(shí)現(xiàn)。

另外一個問題是，這些解決方案也有一些限制。這些方案本身也會引入低效率的因素，隨著網(wǎng)站內(nèi)容和復(fù)雜度的增加，最終這些變通的解決方案也會失效。盡管瀏覽器在每個域名上打開6個連接，并且可以增大這個數(shù)，但這么做的收益較低，這也是為什么瀏覽器限制并發(fā)的連接數(shù)為6個，盡管站長們可以通過域名分片的方法來突破這個限制。

總體來說，每個網(wǎng)站都是不一樣的，每個站長或者Web開發(fā)者都要花時間分析網(wǎng)站本身的性能瓶頸，并使用瀑布圖之類的工具，查明網(wǎng)站受到HTTP/1.1性能問題的影響有多大。