在瀏覽器里輸入網(wǎng)址或者點(diǎn)擊鏈接，網(wǎng)頁打開了……這是我們上網(wǎng)時(shí)再普通不過的一幕，但是如此簡單的表象背后，卻隱藏著無比復(fù)雜的技術(shù)流程。想漲漲知識(shí)嗎？往下看吧。

一個(gè)HTTP請求的過程

為了簡化我們先從一個(gè)HTTP請求開始，簡要介紹一下一個(gè)HTTP求情的網(wǎng)絡(luò)傳輸過程，也就是所謂的“從輸入U(xiǎn)RL到頁面下載完的過程中都發(fā)生了什么事情”。

● DNS Lookup 先獲得URL對(duì)應(yīng)的IP地址

● Socket Connect 瀏覽器和服務(wù)器建立TCP連接

● Send Request 發(fā)送HTTP請求

● Content Download 服務(wù)器發(fā)送響應(yīng)

如果下到物理層去講就有點(diǎn)耍流氓了。如果這些你還認(rèn)可這幾個(gè)步驟的話，我們就來講一下這里面存在的性能問題。

● 如果你對(duì)DNS的查詢還有印象的話現(xiàn)在反思一下，DNS Lookup就是為了獲取一串IP地址要和無數(shù)個(gè)DNS服務(wù)器進(jìn)行通信，這要消耗多少時(shí)間？別忘了，你查詢完了的時(shí)候，你還沒和那邊的服務(wù)器通信呢。

● TCP連接要三次握手。如果服務(wù)器很遠(yuǎn)的話這三次握手要花多少時(shí)間？別忘了建立連接之后你還沒發(fā)請求呢。（通常到這里0.5秒就出去了）

● 發(fā)送HTTP請求的時(shí)候你要知道一點(diǎn)，就是我們的網(wǎng)絡(luò)帶寬上行和下行通常是不一樣的，通常上行的帶寬會(huì)小一些，一個(gè)的話還好，但是現(xiàn)在的網(wǎng)頁通常都會(huì)后續(xù)請求很多資源，帶寬小的時(shí)候上行擁塞怎么辦？別忘了已經(jīng)到第三步了，服務(wù)器還沒給你發(fā)響應(yīng)呢，現(xiàn)在你的瀏覽器還什么都畫不出來。

● 終于到了服務(wù)器發(fā)響應(yīng)了，不巧你訪問的這個(gè)服務(wù)器比較忙，好幾萬個(gè)人都要這個(gè)資源，服務(wù)器的上行帶寬也是有限的，怎么辦？

我覺得我出了幾道還不錯(cuò)的面試題。順便提一下，前兩步的延遲和網(wǎng)絡(luò)帶寬的影響不大；后兩步加帶寬是能一定程度緩解，不過你要有錢，而且很貴。

雖說博主做過WebKit本地渲染的優(yōu)化，但是深知網(wǎng)頁加載的主要時(shí)間還是浪費(fèi)在網(wǎng)絡(luò)通信上，所以在這些步驟上的優(yōu)化會(huì)比你在瀏覽器內(nèi)核的優(yōu)化省力且效果明顯。

網(wǎng)絡(luò)方面的主要優(yōu)化手段，總結(jié)一下不外乎緩存、預(yù)取、壓縮、并行。以后如果再有面試問性能優(yōu)化之類的問題，大家都可以照著這個(gè)思路去考慮。

下面就分階段介紹一下現(xiàn)有的優(yōu)化手段。

DNS優(yōu)化

對(duì)于DNS優(yōu)化，緩存無疑是最簡單粗暴且效果明顯的了。說到緩存就一定要提到緩存層級(jí)：

● 瀏覽器DNS緩存

● 系統(tǒng)DNS緩存

● Hosts文件

● 各個(gè)DNS服務(wù)器上的緩存

當(dāng)然DNS緩存失效期通常都比較短，很多情況下都要再去查找。為了降低用戶體驗(yàn)到的延遲（注意這里不是網(wǎng)絡(luò)延時(shí)），預(yù)取是一個(gè)不錯(cuò)的方法。

比如說你敲網(wǎng)址的時(shí)候還沒有敲完，但是瀏覽器根據(jù)你的歷史發(fā)現(xiàn)你很有可能去訪問哪個(gè)網(wǎng)站，就提前給你做DNS預(yù)取了，比如你打了一個(gè)“w”的時(shí)候，chrome已經(jīng)幫你去找weibo.com的IP地址了。chrome用戶看一下chrome://predictors 你就知道了。

此外瀏覽器還會(huì)記錄你過去的歷史，知道每個(gè)域名下通常還會(huì)有哪些其他的鏈接，以便建立起網(wǎng)站的拓?fù)浣Y(jié)構(gòu)。當(dāng)你訪問這個(gè)域名下的網(wǎng)站，它就會(huì)預(yù)先對(duì)其他鏈接的域名進(jìn)行DNS解析。

TCP優(yōu)化

看到前面的DNS的具體優(yōu)化這么繁雜，知道這簡單的一步?jīng)]那么簡單了吧。

結(jié)果到TCP這一步優(yōu)化反而簡單了，因?yàn)閯偛臘NS已經(jīng)把IP都預(yù)先弄到了，那么我們順著剛才的步驟再建立連接就好了。

所以在你敲第一個(gè)字母的時(shí)候，DNS解析完了就去建立連接了，這時(shí)候你可能網(wǎng)址還沒敲完。當(dāng)你剛訪問一個(gè)網(wǎng)站的時(shí)候，瀏覽器刷刷刷的幫你把到別的服務(wù)器的TCP連接給你建好。

HTTP傳輸優(yōu)化

寫到這里可能有人會(huì)想，既然已經(jīng)把TCP連接建立好了，那我干脆預(yù)取更進(jìn)一步，把所有的鏈接內(nèi)容直接預(yù)取下來不就好了，這樣我網(wǎng)址還沒敲完網(wǎng)頁就已經(jīng)加載完成了。

這個(gè)想法是好的，但現(xiàn)實(shí)卻是殘酷的，因?yàn)橐涀∥覀兊膸捠怯邢薜?，DNS和TCP連接量級(jí)都比較輕，對(duì)網(wǎng)絡(luò)帶寬不會(huì)占據(jù)太多，但是HTTP傳輸就不一樣了。如果你所有鏈接都去預(yù)取的話，你的帶寬很快就被占滿了，這樣你正常的請求無法得到滿足，性能反而會(huì)嚴(yán)重下降。

緩存就又出現(xiàn)了，提緩存必提層次結(jié)構(gòu)。

● PageCache 這個(gè)是最快的了，直接在內(nèi)存中緩存了現(xiàn)有網(wǎng)頁的DOM結(jié)構(gòu)和渲染結(jié)果，這就是你為什么在點(diǎn)前進(jìn)后退的時(shí)候會(huì)這么快。

● HTTP Cache 文件級(jí)別的Cache存在本地的文件系統(tǒng)上按照RFC2616實(shí)現(xiàn)。

● 代理Cache 如果是通過代理服務(wù)器上網(wǎng)的話，代理服務(wù)器通常也會(huì)按照緩存標(biāo)準(zhǔn)

● CDN 一個(gè)地理上離你很近的內(nèi)容服務(wù)器，比如說你在北京請求杭州淘寶的一個(gè)圖片，結(jié)果在北京的一個(gè)CDN上有這個(gè)圖片，那么就不用去杭州了。

● DMOC（distributed memory object caching system）CDN主要存放的是靜態(tài)數(shù)據(jù)，但是網(wǎng)頁中通常有很多動(dòng)態(tài)的數(shù)據(jù)需要查數(shù)據(jù)庫，流量多了壓力就會(huì)很大，通常服務(wù)器外圍還會(huì)有一層內(nèi)存緩存服務(wù)器，專門緩存這些數(shù)據(jù)庫中的對(duì)象，據(jù)《淘寶技術(shù)這10年》稱可以減少99.5%的數(shù)據(jù)庫訪問。

● Server 其實(shí)真正落在服務(wù)器上的請求已經(jīng)不多了。

大家看到這里有沒有想到能在什么地方再加一層緩存呢？其實(shí)可以在2和3之間加，也就是在路由器上加緩存。

小米路由器和搜狗合作的預(yù)取引擎其實(shí)就相當(dāng)于在路由器上加一層緩存款順便智能預(yù)取一下。為什么在這里另起一段專門談小米呢？難不成是小米的水軍？才不是呢，是因?yàn)椴┲骺吹竭@個(gè)消息的時(shí)候心都涼了，和博主的畢設(shè)撞車了有木有。

去年在360剛出隨身Wi-Fi的時(shí)候博主想到了這么個(gè)點(diǎn)子，還想著把這個(gè)東西做出來之后用這個(gè)創(chuàng)業(yè)和360談合作，結(jié)果最近剛做完，論文也投出去了，幻想著開啟人生巔峰，顛覆行業(yè)，結(jié)果就發(fā)現(xiàn)小米和搜狗出了這么個(gè)一樣的東西還都商業(yè)化了。說好的人生巔峰就這樣沒有了，早知道去年就先申請個(gè)專利了。

另一個(gè)HTTP常用的優(yōu)化就是壓縮了，網(wǎng)絡(luò)傳輸時(shí)間＝消息大小/網(wǎng)速。既然網(wǎng)速比較貴那么就壓縮一下吧，大部分服務(wù)器都會(huì)對(duì)HTTP消息進(jìn)行g(shù)zip壓縮。可以在Http Header中看到，具體的就不細(xì)說了。

未來協(xié)議：SPDY

上面的都是傳統(tǒng)做法，下面講一個(gè)未來的技術(shù)。由于HTTP協(xié)議是上個(gè)世紀(jì)制定的協(xié)議了，已經(jīng)不能很好地適應(yīng)現(xiàn)在Web的發(fā)展，所以Google提出了SPDY協(xié)議，目前是指定中的HTTP2.0標(biāo)準(zhǔn)的一個(gè)底版。

SPDY主要有下面的特點(diǎn)：

● 一個(gè)TCP連接上并行多個(gè)HTTP連接，減少連接的建立時(shí)間。

● 請求優(yōu)先級(jí)（目前還沒看到具體實(shí)現(xiàn)）。

● HTTP頭部壓縮，上文提到的HTTP壓縮是對(duì)HTTP body的壓縮，并沒有對(duì)頭部壓縮。對(duì)于小的HTTP消息，頭部的比重還是很大的，而現(xiàn)在的web中存在大量小消息。

● Server push/hint 服務(wù)器主動(dòng)推送對(duì)象（可以想象成服務(wù)器幫客戶端預(yù)取）。

業(yè)界目前對(duì)SPDY是有贊有彈，博主也持謹(jǐn)慎的態(tài)度，主要在1和4上，4其實(shí)和之前提到的HTTP直接預(yù)取的矛盾點(diǎn)一樣，萬一推送的不需要又占據(jù)了帶寬怎么辦？hint到底該如何實(shí)現(xiàn)都有困難。

第一條潛在的風(fēng)險(xiǎn)就是TCP連接中途斷開，那么所有的連接就全部停掉了，PC互聯(lián)網(wǎng)這種情況可能會(huì)少一些，但是移動(dòng)互聯(lián)網(wǎng)中TCP連接斷開的情況還是比較常見的。

不過作為一個(gè)未來的技術(shù)，還是有必要關(guān)注一下。