摘要：假如我們底層的連接得到重用，這時(shí)候的情況會(huì)是這樣子很明顯，在獲取的請求中，減少了一次握手往返。在使用持久連接后，避免了一次握手往返總延遲減少為。其代價(jià)往往是不能充分利用網(wǎng)絡(luò)連接，造成服務(wù)器緩沖開銷，有可能導(dǎo)致客戶端更大的延遲。

歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實(shí)踐干貨哦~

本文由騰訊IVWEB團(tuán)隊(duì)發(fā)表于云+社區(qū)專欄

作者：yangchunwen

HTTP協(xié)議是前端性能乃至安全中一個(gè)非常重要的話題，最近在看《web性能權(quán)威指南(High Performance Browser Networking)》，把其中關(guān)于HTTP部分的內(nèi)容拿出來分享一下，加了一點(diǎn)自己的想法，當(dāng)然沒有《HTTP權(quán)威指南》講得詳細(xì)，但對(duì)于理解我們平常做的事情很有啟發(fā)。預(yù)計(jì)會(huì)有兩三篇文章，重點(diǎn)分別會(huì)涉及到HTTP 1.1、HTTPS、HTTP 2.0等內(nèi)容，本篇主要涉及HTTP 1.1及其應(yīng)用。

HTTP的歷史

HTTP 0.9

HTTP的第一個(gè)版本被官方稱為HTTP0.9，這是個(gè)只有一行的協(xié)議，例如：

GET /about/

(超文本響應(yīng)……)
(連接關(guān)閉……)

HTTP 0.9有幾個(gè)要點(diǎn)：

• 客戶端/服務(wù)器、請求/響應(yīng)協(xié)議
• ASCII 協(xié)議，運(yùn)行于TCP/IP鏈接之上
• 設(shè)計(jì)用來傳輸超文本文檔(HTML)
• 服務(wù)器與客戶端之間的連接在每次請求之后都會(huì)關(guān)閉

這個(gè)版本的HTTP主要用來傳輸文本，并且沒有共用TCP連接。

HTTP 1.0

一個(gè)典型的HTTP 1.0請求過程如下：

GET /rfc/rfc1945.txt HTTP/1.0 
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 
Accept: */* 

HTTP/1.0 200 OK 
Content-Type: text/plain 
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT 
Last-Modified: Wed, 1 May 1996 12:45:26 GMT Server: Apache 0.84

(超文本響應(yīng)……)
(連接關(guān)閉……)

相對(duì)前一個(gè)版本，HTTP 1.0主要有以下幾點(diǎn)變化：

• 請求和相應(yīng)可以由于多行首部字段構(gòu)成
• 響應(yīng)對(duì)象前面添加了一個(gè)響應(yīng)狀態(tài)行
• 響應(yīng)對(duì)象不局限于超文本
• 服務(wù)器與客戶端之間的連接在每次請求之后都會(huì)關(guān)閉
• 實(shí)現(xiàn)了Expires等傳輸內(nèi)容的緩存控制
• 內(nèi)容編碼Accept-Encoding、字符集Accept-Charset等協(xié)商內(nèi)容的支持

這時(shí)候開始有了請求及返回首部的概念，開始傳輸不限于文本（其他二進(jìn)制內(nèi)容）

HTTP 1.1

HTTP 1.1是當(dāng)前大部分應(yīng)用所使用的協(xié)議版本。相對(duì)前面的1.0版本，HTTP 1.1語義格式基本保持不變，但是它加入了很多重要的性能優(yōu)化：持久連接、分塊編碼傳輸、字節(jié)范圍請求、增強(qiáng)的緩存機(jī)制、傳輸編碼及請求管道。

實(shí)際上，持久鏈接在后來被反向移植到了HTTP1.0上

HTTP 2.0

HTTP 2.0 的主要目標(biāo)是改進(jìn)傳輸性能,實(shí)現(xiàn)低延遲和高吞吐量。HTTP 2.0作了很多性能角度的優(yōu)化，另一方面，HTTP的高層協(xié)議語義并不會(huì)因?yàn)檫@次版本升級(jí)而受影響。所有HTTP首部、值,以及它們的使用場景都不會(huì)變?，F(xiàn)有的任何網(wǎng)站和應(yīng)用,無需做任何修改都可以在 HTTP 2.0 上跑起來。換句話說, 等以后我們的服務(wù)器、客戶端（如瀏覽器）都支持HTTP 2.0的時(shí)候，我們不用為了利用 HTTP 2.0 的好處而修改標(biāo)記，作很多額外的編碼，卻能享受到它帶來的更低的延遲和更高的網(wǎng)絡(luò)連接利用率交付！

HTTP 2.0的內(nèi)容將在下篇或下下篇放出，本文不對(duì)其做過多潤色

HTTP 1.1與前端性能

前面講到，HTTP 1.1這個(gè)版本引入了大量增強(qiáng)性能的重要特性，其中包括：

• 持久化連接以支持連接重用
• 分塊傳輸編碼以支持流式響應(yīng)
• 請求管道以支持并行請求處理
• 字節(jié)服務(wù)以支持基于范圍的資源請求
• 改進(jìn)的更好的緩存機(jī)制

這里重點(diǎn)講一下持久化、管道在前端性能優(yōu)化中的一些應(yīng)用

持久連接

所謂持久連接，就是重用 TCP連接，多個(gè)HTTP請求公用一個(gè)TCP連接。

HTTP 1.1 改變了 HTTP 協(xié)議的語義,默認(rèn)使用持久連接。換句話說,除非明確告知(通過 Connection: close 首部),否則服務(wù)器默認(rèn)會(huì)保持TCP連接打開。如果你使用的是 HTTP 1.1,從技術(shù)上說不需要 Connection: Keep-Alive 首部,但很多客戶端還是選擇加上它，比如我們的瀏覽器在發(fā)起請求的時(shí)候，一般會(huì)默認(rèn)幫我們帶上 Connection: Keep-Alive 首部。

我們來看一下為什么持久連接對(duì)我們來說這么重要。

假設(shè)一個(gè)網(wǎng)頁僅包含一個(gè)HTML文檔及一個(gè)CSS樣式文件，服務(wù)器響應(yīng)這兩個(gè)文件的時(shí)間分別為40ms及20ms，服務(wù)器和瀏覽者分別在哈爾濱和深圳，兩者之間單向光纖延遲為28ms(假設(shè)的理想狀態(tài)，實(shí)際會(huì)比這個(gè)要大)。

1. 首先是獲取HTML文檔的請求過程：

HTML下載完畢后，TCP連接關(guān)閉。

1. 其次，發(fā)起CSS資源的請求，再次經(jīng)歷一次TCP握手

可以看到，兩個(gè)HTTP請求都分別需要經(jīng)歷一次TCP的三次握手時(shí)間，另外，圖中沒有體現(xiàn)到的是，每一次TCP請求都有可能會(huì)經(jīng)歷一次TCP慢啟動(dòng) 過程，這是影響傳播性能的一個(gè)不可忽視的重要因素。

假如我們底層的TCP連接得到重用，這時(shí)候的情況會(huì)是這樣子：

很明顯，在獲取CSS的請求中，減少了一次握手往返。

一開始，每個(gè)請求要用兩個(gè)TCP連接，總延遲為284ms。在使用持久連接后，避免了一次握手往返,總延遲減少為228ms。這里面兩次請求節(jié)省了56ms（一個(gè)RTT，Round-Trip Time）的時(shí)間

上面的例子還只是只有一個(gè)HTML和一個(gè)CSS的簡單假設(shè)情況，而現(xiàn)實(shí)世界的web的HTTP請求數(shù)量比這個(gè)要多得多，在啟用持久連接的情況下，N次請求節(jié)省的總延遲時(shí)間就是(N-1)×RTT。

現(xiàn)實(shí)情況中，延遲更高、請求更多，性能提升效果比這里還要高得多。事實(shí)上,網(wǎng)絡(luò)延遲越高,請求越多,節(jié)省的時(shí)間就越多。實(shí)際應(yīng)用中，這個(gè)節(jié)省的總時(shí)間可按秒來算了。如果每一個(gè)HTTP都重啟一個(gè)TCP連接，可想而知要浪費(fèi)多少時(shí)間！

HTTP管道

持久 HTTP 可以讓我們重用已有的連接來完成多次應(yīng)用請求，但多次請求必須嚴(yán)格滿足先進(jìn)先出(FIFO，first in first out)的隊(duì)列順序：發(fā)送請求,等待響應(yīng)完成,再發(fā)送客戶端隊(duì)列中的下一個(gè)請求。

舉一下上一節(jié)持久連接的那個(gè)例子，首先，服務(wù)器處理完第一次請求后，會(huì)發(fā)生了一次完整的往返：先是響應(yīng)回傳，接著是第二次請求，在第二次請求到達(dá)服務(wù)器之間的這段時(shí)間里，服務(wù)器空閑。

如果服務(wù)器能在處理完第一次請求后,立即開始處理第二次請求呢？甚至，如果服務(wù)器可以并行處理兩個(gè)請求呢?

這時(shí)候HTTP管道就派上用場了，HTTP管道是一個(gè)很小但對(duì)上述工作流非常重要的一次優(yōu)化。

有了HTTP管道，我們的HTTP請求在一定程度上不用再一個(gè)一個(gè)地串行請求，而是可以多個(gè)并行了，看起來好像很理想：

如上圖，HTML和CSS的請求同時(shí)到達(dá)服務(wù)器，服務(wù)器同時(shí)處理，然后返回。

這一次，通過使用HTTP管道，又減少了兩次請求之間的一次往返,總延遲減少為 172 ms。從一開始沒有持久連接、沒有管道的284ms，到優(yōu)化后的172ms，這40%的性能提升完全拜簡單的協(xié)議優(yōu)化所賜。

等一下，剛剛那個(gè)例子好像哪里還不夠好：既然請求同時(shí)到達(dá)，同時(shí)處理，為什么后面要先返回HTML，然后再返回CSS？兩者不能同時(shí)返回嗎？

理想很豐滿，現(xiàn)實(shí)卻有點(diǎn)骨感，這就是HTTP 1.1管道的一個(gè)很大的局限性：HTTP請求無法很好地利用多路復(fù)用，不允許一個(gè)連接上的多個(gè)響應(yīng)數(shù)據(jù)交錯(cuò)返回(多路復(fù)用)。因而一個(gè)響應(yīng)必須完全返回后，下一個(gè)響應(yīng)才會(huì)開始傳輸。

這個(gè)管道只是讓我們把FIFO隊(duì)列從客戶端遷移到了服務(wù)器。也就是說，請求可以同時(shí)到達(dá)服務(wù)器，服務(wù)器也可以同時(shí)處理兩個(gè)文件，但是，兩個(gè)文件還是得按順序返回給用戶，如下圖：

• HTML和CSS請求同時(shí)到達(dá)，但先處理的是HTML請求
• 服務(wù)器并行處理兩個(gè)請求，其中處理 HTML 用時(shí)40ms，處理CSS用時(shí)20ms
• CSS請求先處理完成，但被緩沖起來以等候HTML響應(yīng)先發(fā)送
• 發(fā)送完HTML響應(yīng)后，再發(fā)送服務(wù)器緩沖中的CSS響應(yīng)

可以看到，即使客戶端同時(shí)發(fā)送了兩個(gè)請求,而且CSS資源先準(zhǔn)備就緒，但是服務(wù)器也會(huì)先發(fā)送 HTML 響應(yīng)，然后再交付 CSS。

題外話 上面兩節(jié)舉的例子，說到了HTML和CSS請求同時(shí)到達(dá)，這是書中的例子，實(shí)際上，個(gè)人覺得這個(gè)例子舉得不是很恰當(dāng)。 實(shí)際的web中，HTML及其包含的CSS一般不會(huì)同時(shí)到達(dá)服務(wù)器，正常的瀑布圖也不是這樣的，往往是要先獲取HTML內(nèi)容后瀏覽器才能發(fā)起其中的CSS等資源請求。我想作者只是為了闡述原理吧，個(gè)人認(rèn)為換成同一個(gè)HTML文檔中CSS和JS可能更加恰當(dāng)。

這個(gè)問題的原理在于TCP層面的“隊(duì)首阻塞”，感興趣可以去復(fù)習(xí)下計(jì)算機(jī)網(wǎng)絡(luò)的課程。其代價(jià)往往是：不能充分利用網(wǎng)絡(luò)連接，造成服務(wù)器緩沖開銷，有可能導(dǎo)致客戶端更大的延遲。更嚴(yán)重的時(shí)，假如前面的請求無限期掛起，或者要花很長時(shí)間才能處理完,所有后續(xù)的請求都將被阻塞,等待它完成。

所以，在HTTP 1.1中，管道技術(shù)的應(yīng)用非常有限，盡管其優(yōu)點(diǎn)毋庸置疑。實(shí)際上，一些支持管道的瀏覽器，通常都將其作為一個(gè)高級(jí)配置選項(xiàng)，但大多數(shù)瀏覽器都會(huì)禁用它。換句話說，作為前端工程師，開發(fā)的應(yīng)用是面向普通瀏覽器應(yīng)用的話，還是不要過多的指望HTTP管道，看來還是期待一下HTTP 2.0中對(duì)管道的優(yōu)化吧。

不過，實(shí)際上還是有很好地利用HTTP管道的一些應(yīng)用，例如在WWDC 2012上，有蘋果的工程師分享了一個(gè)針對(duì)HTTP優(yōu)化取得巨大成效的案例：通過使用HTTP的持久連接和管道，重用iTunes中既有的TCP連接，使得低網(wǎng)速用戶的性能提升到原來的3倍！

實(shí)際上假如你想充分利用管道的好處，必須要保證下面這幾點(diǎn)條件：

• HTTP客戶端支持管道
• HTTP服務(wù)器支持管道
• 應(yīng)用可以處理中斷的連接并恢復(fù)
• 應(yīng)用可以處理中斷請求的冪等問題
• 應(yīng)用可以保護(hù)自身不受出問題的代理的影響

因?yàn)閕Tunes的服務(wù)器和客戶端都受開發(fā)者控制的應(yīng)用，所以他們能滿足以上的條件。這也許能給開發(fā)hybrid應(yīng)用或者開發(fā)瀏覽器之外的web應(yīng)用的前端工程師們一些啟發(fā)，如果你開發(fā)的網(wǎng)站面向的用戶是使用五花八門的瀏覽器，你可能就沒轍了。

使用多個(gè)TCP連接

因?yàn)镠TTP 1.1管道存在上面的缺點(diǎn)，所以利用率不高。那么問題來了：假設(shè)沒有使用HTTP管道，我們的所有HTTP請求都只能通過持久連接，一個(gè)接一個(gè)地串行返回，這得有多慢？

實(shí)際上，現(xiàn)階段的瀏覽器廠商采取了另外的辦法來解決HTTP 1.1管道的缺陷：允許我們并行打開多個(gè)TCP會(huì)話。至于是多少個(gè)，大家可能已經(jīng)似曾相識(shí)：4到8個(gè)不等。這就是前端工程師非常熟悉的瀏覽器只允許從同一個(gè)服務(wù)器并行加載4到8個(gè)資源這一認(rèn)識(shí)的真正來歷。

HTTP持久連接雖然幫我們解決了TCP連接復(fù)用的問題，但是現(xiàn)階段的HTTP管道卻無法實(shí)現(xiàn)多個(gè)請求結(jié)果的交錯(cuò)返回，所以瀏覽器只能開啟多個(gè)TCP連接，以達(dá)到并行地加載資源的目的。

只能說，這是作為繞過應(yīng)用協(xié)議（HTTP）限制的一個(gè)權(quán)宜之計(jì)?？梢赃@樣打一個(gè)比喻，一個(gè)水管無法同時(shí)運(yùn)輸多種液體，那就只能給每一種液體開通一條運(yùn)輸管了，至于這個(gè)水管什么時(shí)候可以智能化到同時(shí)運(yùn)輸不同的液體，又能保證各自完整不受干擾到達(dá)目的地并在目的地自行分類？還是那一句，期待HTTP 2.0吧。

這里的連接數(shù)為什么是4到8個(gè)，是多方平衡的結(jié)果：這個(gè)數(shù)字越大，客戶端和服務(wù)器的資源占用越多（在高并發(fā)訪問的服務(wù)器中因?yàn)門CP連接造成的系統(tǒng)開銷不可忽視），每個(gè)主機(jī)4到8個(gè)連接只不過是大家都覺得比較安全的一個(gè)數(shù)字。

域名分區(qū)

前面說到，瀏覽器和服務(wù)器之間只能并發(fā)4到8個(gè)TCP連接，也就是同時(shí)下載4到8個(gè)資源，夠嗎？

看看我們現(xiàn)在的大部分網(wǎng)站，動(dòng)不動(dòng)就幾十個(gè)JS、CSS，一次六個(gè)，會(huì)造成后面大量的資源排隊(duì)等待；另外，只下載6個(gè)資源，對(duì)帶寬的利用率也是很低的。

打個(gè)比喻，一個(gè)工廠裝了100根水管，每次卻只能用其中6根接水，既慢，又浪費(fèi)水管！

所以，我們前端性能優(yōu)化中有一個(gè)最佳實(shí)踐：使用域名分區(qū)！

對(duì)啊，何必把自己只限制在一個(gè)主機(jī)上呢？我們可以手工將所有資源分散到多個(gè)子域名，由于主機(jī)名稱不一樣了，就可以突破瀏覽器的連接限制，實(shí)現(xiàn)更高的并行能力。

通過這種方式“欺騙”瀏覽器，這樣瀏覽器和服務(wù)器之間的并行傳輸數(shù)量就變多了。

域名分區(qū)使用得越多，并行能力就越強(qiáng)！

但是，域名分區(qū)也是有代價(jià)的！

實(shí)踐中，域名分區(qū)經(jīng)常會(huì)被濫用。

例如，假設(shè)你的應(yīng)用面向的是2G網(wǎng)絡(luò)的手機(jī)用戶，你分配了好幾個(gè)域名，同時(shí)加載十幾二十多個(gè)CSS、JS，這里的問題在于：

• 每一個(gè)域名都會(huì)多出來的DNS查詢開銷，這是額外的機(jī)器資源開銷和額外的網(wǎng)絡(luò)延時(shí)代價(jià)。2G網(wǎng)絡(luò)的DNS查詢可不像你公司的電腦一樣，相反可能是好幾秒的延遲
• 同時(shí)加載多個(gè)資源，以2G網(wǎng)絡(luò)那種小得可憐的帶寬來看，后果往往就是帶寬被占滿，每一個(gè)資源都下載得很慢
• 手機(jī)的耗電加快

所以在一些低帶寬高延時(shí)的場景，例如2G手機(jī)網(wǎng)絡(luò)，域名分區(qū)做過了的話，不光不會(huì)帶來前端性能的提升，反而會(huì)變成性能殺手。

域名分區(qū)是一種合理但又不完美的優(yōu)化手段，最合適的辦法就是，從最小分區(qū)數(shù)目（不分區(qū)）開始，然后逐個(gè)增加分區(qū)并度量分區(qū)后對(duì)應(yīng)用的影響，從而得到一個(gè)最優(yōu)的域名數(shù)。

連接與拼合

我們前端性能優(yōu)化中有這么一個(gè)所謂的最佳實(shí)踐原則：合并打包JS、CSS文件，以及做CSS sprite。

現(xiàn)在我們應(yīng)該知道為什么要這樣做了，實(shí)際上就是因?yàn)楝F(xiàn)在HTTP 1.1的管道太弱了，這兩種技術(shù)的效果就好像是隱式地啟用了HTTP 管道：來自多個(gè)響應(yīng)的數(shù)據(jù)前后相繼地連接在一起，消除了額外的網(wǎng)絡(luò)延遲。

實(shí)際上，就是把管道提高了一層，置入了應(yīng)用中，也許到了HTTP 2.0時(shí)代，前端工程師就不用干這樣的活了吧？(HTTP 2.0的內(nèi)容下篇講)

當(dāng)然，連接拼合技術(shù)同樣有代價(jià)的。

• 例如CSS sprite，瀏覽器必須分析整個(gè)圖片，即便實(shí)際上只顯示了其中的一小塊，也要始終把整個(gè)圖片都保存在內(nèi)存中。瀏覽器沒有辦法把不顯示的部分從內(nèi)存中剔除掉。
• 再者，既然JS、CSS合并了，帶來的一般就是體積的增大，在帶寬有限的環(huán)境下（例如2G）下載時(shí)間就變長，一般導(dǎo)致的就是頁面渲染時(shí)間延后等后果。因?yàn)镴avaScript 和CSS 處理器都不允許遞增式執(zhí)行的，對(duì)于JavaScript 和CSS 的解析及執(zhí)行，則要等到整個(gè)文件下載完畢。

打包文件到底多大合適呢？可惜的是，沒有理想的大小。然而，谷歌PageSpeed團(tuán)隊(duì)的測試表明，30~50 KB（壓縮后）是每個(gè)JavaScript 文件大小的合適范圍：既大到了能夠減少小文件帶來的網(wǎng)絡(luò)延遲，還能確保遞增及分層式的執(zhí)行。具體的結(jié)果可能會(huì)由于應(yīng)用類型和腳本數(shù)量而有所不同。

資源內(nèi)嵌

JavaScript 和CSS 代碼， 通過適當(dāng)?shù)膕cript 和style 塊可以直接放在頁面中，而圖片甚至音頻或PDF 文件，都可以通過數(shù)據(jù)URI（data:[mediatype][;base64],data）的方式嵌入到頁面中。

上面的這種方式我們稱為資源內(nèi)嵌。

嵌入資源是另一種非常流行的優(yōu)化方法， 把資源嵌入文檔可以減少請求的次數(shù)。尤其在2G網(wǎng)絡(luò)等情況中，內(nèi)嵌資源可以有效地減少多次請求帶來的時(shí)延?？梢詤⒖歼@篇文章在2G中的一些實(shí)踐。

當(dāng)然，有缺點(diǎn)：

• 內(nèi)嵌方式的資源，不能被瀏覽器、CDN 或其他緩存代理作為多帶帶的資源緩存。如果在多個(gè)頁面中都嵌入同樣的資源，那么這個(gè)資源將會(huì)隨著每個(gè)頁面的加載而被加載，從而增大每個(gè)頁面的總體大小。
• 如果嵌入資源更新，那么所有以前出現(xiàn)過它的頁面都將被宣告無效，而由客戶端重新從服 務(wù)器獲取。
• 圖片等非文本性資源通過base64 編碼，會(huì)導(dǎo)致開銷明顯增大：編碼后的資源大小比原大小增大33%！

Google的磚家給出一些經(jīng)驗(yàn)：

• 只考慮嵌入1~2 KB 以下的資源，因?yàn)樾∮谶@個(gè)標(biāo)準(zhǔn)的資源經(jīng)常會(huì)導(dǎo)致比它自身更高的HTTP 開銷
• 如果文件很小，而且只有個(gè)別頁面使用，可以考慮嵌入。理想情況下，最好是只用一次的資源
• 如果文件很小，但需要在多個(gè)頁面中重用，應(yīng)該考慮集中打包
• 如果小文件經(jīng)常需要更新，就不要嵌入了
• 通過減少 HTTP cookie 的大小將協(xié)議開銷最小化

小結(jié)

本文介紹了HTTP 1.1在前端性能優(yōu)化中的一些應(yīng)用，有些是為了繞過HTTP 1.1局限性的一些不得不做的事情，比如資源合并、壓縮、內(nèi)嵌等，這些都可以說是HTTP 2.0來臨前的一些解決問題的“黑魔法”。

HTTP 1.1及其利用當(dāng)然遠(yuǎn)遠(yuǎn)沒有本文說得那么簡單，我只是濃縮了一部分內(nèi)容，有興趣可以去研究《HTTP權(quán)威指南》。

問答
BDD框架的前端如何搭建？
相關(guān)閱讀
全面進(jìn)階 H5 直播（上）
NodeJs內(nèi)存管理
WebGL 紋理顏色原理
【每日課程推薦】機(jī)器學(xué)習(xí)實(shí)戰(zhàn)！快速入門在線廣告業(yè)務(wù)及CTR相應(yīng)知識(shí)

此文已由作者授權(quán)騰訊云+社區(qū)發(fā)布，更多原文請點(diǎn)擊

搜索關(guān)注公眾號(hào)「云加社區(qū)」，第一時(shí)間獲取技術(shù)干貨，關(guān)注后回復(fù)1024 送你一份技術(shù)課程大禮包！

海量技術(shù)實(shí)踐經(jīng)驗(yàn)，盡在云加社區(qū)！