合并HTTP請(qǐng)求 vs 并行HTTP請(qǐng)求，到底誰更快？
面試時(shí)，經(jīng)常會(huì)問候選人一個(gè)問題：如何提高網(wǎng)頁性能？
有些基礎(chǔ)的人都會(huì)提到這么一條：減少/合并HTTP請(qǐng)求。
繼續(xù)問：瀏覽器不是可以并行下載資源嗎？將多個(gè)資源合并成一個(gè)資源，只使用一個(gè)HTTP請(qǐng)求下載，難道要比用多個(gè)HTTP請(qǐng)求并行下載沒有合并過的多個(gè)資源速度更快？
候選人：……（至今，還沒有遇到讓我滿意的回答）
減少HTTP請(qǐng)求，是雅虎前端性能優(yōu)化35條軍規(guī)的第1條，2006年雅虎提出了這35條軍規(guī)，從那以后，就深深地影響到了一批又一批的前端開發(fā)者，即使在12年后的今天，影響力依舊不減…..
但是，雅虎軍規(guī)中還有1條是：拆分資源以***化利用瀏覽器并行下載的能力。現(xiàn)在問題就來了，減少HTTP請(qǐng)求，但網(wǎng)頁所需的資源并不能減少（否則網(wǎng)頁就不再是之前的網(wǎng)頁了），所以減少HTTP請(qǐng)求，主要是通過合并資源來實(shí)現(xiàn)的，一邊是建議合并資源，一邊是建議拆分資源，顯然是有沖突的地方，那么到底該怎么做呢？網(wǎng)上有些文章也討論過這個(gè)問題，但大多是停留在想當(dāng)然的理論分析上，而且忽略了TCP傳輸機(jī)制的影響。今天，老干部就帶大家一起用實(shí)驗(yàn)+理論，仔細(xì)探討下這個(gè)問題。
HTTP請(qǐng)求過程
一個(gè)HTTP請(qǐng)求的主要過程是：
DNS解析(T1) -> 建立TCP連接(T2) -> 發(fā)送請(qǐng)求(T3) -> 等待服務(wù)器返回首字節(jié)（TTFB）(T4) -> 接收數(shù)據(jù)(T5)。
如下圖所示，是Chrome Devtools中顯示的一個(gè)HTTP請(qǐng)求，顯示了HTTP請(qǐng)求的主要階段，注意，Queueing階段是請(qǐng)求在瀏覽器隊(duì)列中的排隊(duì)時(shí)間，并不計(jì)入HTTP請(qǐng)求時(shí)間。
?
??
從這個(gè)過程中，可以看出如果合并N個(gè)HTTP請(qǐng)求為1個(gè)，可以節(jié)?。∟-1)* (T1+T2+T3+T4) 的時(shí)間。
但實(shí)際場(chǎng)景并沒有這么理想，上面的分析存在幾個(gè)漏洞：
- 瀏覽器會(huì)緩存DNS信息，因此不是每次請(qǐng)求都需要DNS解析。
- HTTP 1.1 keep-alive的特性，使HTTP請(qǐng)求可以復(fù)用已有TCP連接，所以并不是每個(gè)HTTP請(qǐng)求都需要建立新的TCP連接。
- 瀏覽器可以并行發(fā)送多個(gè)HTTP請(qǐng)求，同樣可能影響到資源的下載時(shí)間，而上面的分析顯然只是基于同一時(shí)刻只有1個(gè)HTTP請(qǐng)求的場(chǎng)景。
實(shí)驗(yàn)論證
我們來做4組實(shí)驗(yàn)，對(duì)比一個(gè)HTTP請(qǐng)求加載合并后的資源所需時(shí)間，和多個(gè)HTTP請(qǐng)求并行加載拆分的資源所需時(shí)間。每組實(shí)驗(yàn)所用資源的體積大小有顯著差異。
實(shí)驗(yàn)環(huán)境：
服務(wù)器：阿里云ECS 1核 2GB內(nèi)存 帶寬1M
Web服務(wù)器：Nginx (未啟用Gzip)
Chrome v66 隱身模式，禁用緩存
Client 網(wǎng)絡(luò)：wifi 帶寬20M
實(shí)驗(yàn)代碼地址：??https://github.com/xuchaobei/...??
實(shí)驗(yàn) 1
測(cè)試文件：large1.css、large2.css … large6.css，每個(gè)文件141K；large-6in1.css，由前面6個(gè)css文件合并而成，大小為846K。parallel-large.html引用large1.css、large2.css … large6.css， combined-large.html引用large-6in1.css，代碼如下：
// parallel-large.html <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Parallel Large</title> <link rel="stylesheet" type="text/css" media="screen" href="large1.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large2.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large3.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large4.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large5.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large6.css" /> </head> <body> Hello, world! </body> </html> // combined-large.html <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Combined Large</title> <link rel="stylesheet" type="text/css" media="screen" href="large-6in1.css" /> </head> <body> Hello, world! </body> </html>
分別刷新2個(gè)頁面各10次，利用Devtools 的Network計(jì)算CSS資源加載的平均時(shí)間。
注意事項(xiàng)：
- large1.css、large2.css … large6.css的加載時(shí)間，計(jì)算方式為從***個(gè)資源的HTTP請(qǐng)求發(fā)送開始，到6個(gè)文件都下載完成的時(shí)間，如圖2紅色框內(nèi)的時(shí)間。
- 兩個(gè)html頁面不能同時(shí)加載，否則帶寬為兩個(gè)頁面所共享，會(huì)影響測(cè)試結(jié)果。需要等待一個(gè)頁面加載完畢后，再手動(dòng)刷新加載另外一個(gè)頁面。
- 頁面兩次刷新時(shí)間間隔在1分鐘以上 ，以避免HTTP 1.1 連接復(fù)用對(duì)實(shí)驗(yàn)的影響。
?
??
實(shí)驗(yàn)結(jié)果如下：
large-6in1.css | large1.css、large2.css … large6.css | |
平均時(shí)間(s) | 5.52 | 5.3 |
我們?cè)侔裭arge1.css、large2.css … large6.css合并為3個(gè)資源large-2in1a.css、large-2in1b.css、large-2in1c.css，每個(gè)資源282K，在combined-large-1.html中引用這3個(gè)資源：
// combined-large-1.html <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Parallel Large 1</title> <link rel="stylesheet" type="text/css" media="screen" href="large-2in1a.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large-2in1b.css" /> <link rel="stylesheet" type="text/css" media="screen" href="large-2in1c.css" /> </head> <body> Hello, world! </body> </html>
測(cè)試10次，平均加載時(shí)間為5.20s。
匯總實(shí)驗(yàn)結(jié)果如下：
large-6in1.css | large1.css、large2.css … large6.css | large-2in1a.css、... large-2in1c.css | |
平均時(shí)間(s) | 5.52 | 5.30 | 5.20 |
從實(shí)驗(yàn)1結(jié)果可以看出，合并資源和拆分資源對(duì)于資源的總加載時(shí)間沒有顯著影響。實(shí)驗(yàn)中耗時(shí)最少的是拆分成3個(gè)資源的情況（5.2s），耗時(shí)最多的是合并成一個(gè)資源的情況(5.52s)，但兩者也只不過相差6%。考慮到實(shí)驗(yàn)環(huán)境具有一定隨機(jī)性，以及實(shí)驗(yàn)重復(fù)次數(shù)只有10次，這個(gè)時(shí)間差并不能表征3種場(chǎng)景有明顯的時(shí)間差異性。
實(shí)驗(yàn) 2
繼續(xù)增加css文件大小。
測(cè)試文件：xlarge1.css、xlarge2.css 、xlarge3.css，每個(gè)文件1.7M；xlarge-3in1.css，由前面3個(gè)css文件合并而成，大小為5.1M。parallel-xlarge.html引用xlarge1.css、xlarge2.css 、xlarge3.css， combined-xlarge.html引用xlarge-3in1.css。
測(cè)試過程同上，實(shí)驗(yàn)結(jié)果如下：
xlarge-3in1.css | xlarge1.css、xlarge2.css、xlarge3.css | |
平均時(shí)間(s) | 37.72 | 36.88 |
這組實(shí)驗(yàn)的時(shí)間差只有2%，更小了，所以更無法說明合并資源和拆分資源的總加載時(shí)間有明顯差異性。
實(shí)際上，理想情況下，隨著資源體積變大，兩種資源加載方式所需時(shí)間將趨于相同。
從理論上解釋，因?yàn)镠TTP的傳輸通道是基于TCP連接的，而TCP連接具有慢啟動(dòng)的特性，剛開始時(shí)并沒有充分利用網(wǎng)絡(luò)帶寬，經(jīng)過慢啟動(dòng)過程后，逐漸占滿可利用的帶寬。對(duì)于大資源而言，帶寬總是會(huì)被充分利用的，所以帶寬是瓶頸，即使使用更多的TCP連接，也不能帶來速度的提升。資源越大，慢啟動(dòng)所占總的下載時(shí)間的比例就越小，絕大部分時(shí)間，帶寬都是被充分利用的，總數(shù)據(jù)量相同（拆分資源導(dǎo)致的額外Header在這種情況下完全可以忽略不計(jì)），帶寬相同，傳輸時(shí)間當(dāng)然也相同。
實(shí)驗(yàn) 3
減小css文件大小。
測(cè)試文件：medium1.css、medium2.css … medium6.css，每個(gè)文件9.4K；medium-6in1.css，由前面6個(gè)css文件合并而成，大小為56.4K。parallel-medium.html引用medium1.css、medium2.css … medium6.css， combined-medium.html 引用 medium-6in1.css。
實(shí)驗(yàn)結(jié)果如下：
medium-6in1.css | medium1.css、medium2.css … medium6.css | |
平均時(shí)間(ms) | 34.87 | 46.24 |
注意單位變成ms
實(shí)驗(yàn)3的時(shí)間差是33%，雖然數(shù)值上只差12ms。先不多分析，繼續(xù)看實(shí)驗(yàn)4。
實(shí)驗(yàn) 4
繼續(xù)減小css文件大小，至幾十字節(jié)級(jí)別。
測(cè)試文件：small1.css、small2.css … small6.css，每個(gè)文件28B；small-6in1.css，由前面6個(gè)css文件合并而成，大小為173B。parallel-medium.html引用small1.css、small2.css … small6.css， combined-medium.html 引用 small-6in1.css。
實(shí)驗(yàn)結(jié)果如下：
small-6in1.css | small1.css、small2.css … small6.css | |
平均時(shí)間(ms) | 20.33 | 35 |
實(shí)驗(yàn)4的時(shí)間差是72%。
根據(jù)實(shí)驗(yàn)3和實(shí)驗(yàn)4，發(fā)現(xiàn)當(dāng)資源體積很小時(shí)，合并資源和拆分資源的加載時(shí)間有了比較明顯的差異。圖3和圖4是實(shí)驗(yàn)4中的某次測(cè)試結(jié)果的截圖，當(dāng)資源體積很小時(shí)，數(shù)據(jù)的下載時(shí)間（圖中水平柱的藍(lán)色部分所示）占總時(shí)間的比例就很小了，這時(shí)候影響資源加載時(shí)間的關(guān)鍵就是DNS解析(T1) 、 TCP連接建立(T2) 、發(fā)送請(qǐng)求(T3) 和等待服務(wù)器返回首字節(jié)（TTFB）(T4) 。但同時(shí)建立多個(gè)HTTP連接本身就存在額外的資源消耗，每個(gè)HTTP的DNS查詢時(shí)間、TCP連接的建立時(shí)間等也存在一定的隨機(jī)性，這就導(dǎo)致并發(fā)請(qǐng)求資源時(shí)，出現(xiàn)某個(gè)HTTP耗時(shí)明顯增加的可能性變大。如圖3所示，small1.css加載時(shí)間最短（16ms），small5.css加載時(shí)間最長(zhǎng)(32ms)，兩者相差了1倍，但計(jì)算時(shí)間是以所有資源都加載完成為準(zhǔn)，這種情況下，同時(shí)使用多個(gè)HTTP請(qǐng)求就會(huì)導(dǎo)致更大的時(shí)間不均勻性和不確定性，表現(xiàn)結(jié)果就是往往要比使用一個(gè)HTTP請(qǐng)求加載合并后的資源慢。
?
??
?
??
更復(fù)雜的情況
對(duì)于小文件一定是合并資源更快嗎？
其實(shí)未必，在一些情況下，合并小文件反而有可能明顯增加資源加載時(shí)間。
再說些理論的東西。為了提高傳輸效率，TCP通道上，并不是發(fā)送方每發(fā)送一個(gè)數(shù)據(jù)包，都要等到收到接收方的確認(rèn)應(yīng)答（ACK）后，再發(fā)送下一個(gè)報(bào)文。TCP引入了”窗口“的概念，窗口大小指無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的***值，例如窗口大小是4個(gè)MSS（Maximum Segment Size，TCP數(shù)據(jù)包每次能夠傳輸?shù)?**數(shù)據(jù)分段），表示當(dāng)前可以連續(xù)發(fā)送4個(gè)報(bào)文段，而不需要等待接收方的確認(rèn)信號(hào)，也就是說，在1次網(wǎng)絡(luò)往返（round-trip）中完成了4個(gè)報(bào)文段的傳輸。如下圖所示（MSS為1，窗口大小為4），1 - 4000 數(shù)據(jù)是連續(xù)發(fā)送的，并沒有等待確認(rèn)應(yīng)答，同樣的，4001 - 8000也是連續(xù)發(fā)送的。請(qǐng)注意，這只是理想情況下的示意圖，實(shí)際情況要比這里更復(fù)雜。
?
??
在慢啟動(dòng)階段，TCP維護(hù)一個(gè)擁塞窗口變量，這個(gè)階段窗口的大小就等于擁塞窗口，慢啟動(dòng)階段，隨著每次網(wǎng)絡(luò)往返，擁塞窗口的大小就會(huì)翻一倍，例如，假設(shè)擁塞窗口的初始大小為1，擁塞窗口的大小變化為：1，2，4，8……。如下圖所示。
?
??
實(shí)際網(wǎng)絡(luò)中，擁塞窗口的初始值一般是10，所以擁塞窗口的大小變化為：10，20，40 ... ，MSS的值取決于網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)和硬件設(shè)備，以太網(wǎng)中MSS值一般是1460字節(jié)，按每個(gè)報(bào)文段傳輸?shù)臄?shù)據(jù)大小都等于MSS計(jì)算（實(shí)際情況可以小于MSS值），經(jīng)過第1次網(wǎng)絡(luò)往返后，傳輸?shù)?**數(shù)據(jù)為14.6K，第2次后，為(10+20) 1.46 = 43.8K， 第3次后，為(10+20+40) 1.46 = 102.2K。
根據(jù)上面的理論介紹，實(shí)驗(yàn)4中，不管是合并資源，還是拆分資源，都是在1次網(wǎng)絡(luò)往返中傳輸完成。但實(shí)驗(yàn)3，拆分后的資源大小為9.4K，可以在1次網(wǎng)絡(luò)往返中傳輸完成，而合并后的資源大小為56.4K，需要3次網(wǎng)絡(luò)往返才能傳輸完成，如果網(wǎng)絡(luò)延時(shí)很大（例如1s），帶寬又不是瓶頸，多了兩次網(wǎng)絡(luò)往返將導(dǎo)致耗時(shí)增加1s，這時(shí)候合并資源就可能得不償失了。實(shí)驗(yàn)3并沒有產(chǎn)生這個(gè)結(jié)果的原因是，實(shí)驗(yàn)中網(wǎng)絡(luò)延時(shí)是10ms左右，由于數(shù)值太小而沒有對(duì)結(jié)果產(chǎn)生明顯影響。
總結(jié)
對(duì)于大資源，是否合并對(duì)于加載時(shí)間沒有明顯影響，但拆分資源可以更好的利用瀏覽器緩存，不會(huì)因?yàn)槟硞€(gè)資源的更新導(dǎo)致所有資源緩存失效，而資源合并后，任一資源的更新都會(huì)導(dǎo)致整體資源的緩存失效。另外還可以利用域名分片技術(shù)，將資源拆分部署到不同域名下，既可以分散服務(wù)器的壓力，又可以降低網(wǎng)絡(luò)抖動(dòng)帶來的影響。
對(duì)于小資源，合并資源往往具有更快的加載速度，但在網(wǎng)絡(luò)帶寬狀況良好的情況下，因?yàn)樘嵘臅r(shí)間單位以ms計(jì)量，收益可以忽略。如果網(wǎng)絡(luò)延遲很大，服務(wù)器響應(yīng)速度又慢，則可以帶來一定收益，但在高延遲的網(wǎng)絡(luò)場(chǎng)景下，又要注意合并資源后可能帶來網(wǎng)絡(luò)往返次數(shù)的增加，進(jìn)而影響到加載時(shí)間。
其實(shí)，看到這里，是合是分已經(jīng)不重要了，重要的是我們要知道合分背后的原理是什么，和業(yè)務(wù)場(chǎng)景是怎樣的。
