在瀏覽器裡輸入網址或者點擊鏈接，網頁打開了……這是我們上網時再普通不過的一幕，但是如此簡單的表象背後，卻隱藏著無比複雜的技術流程。想漲漲知識嗎？往下看吧。
一個HTTP請求的過程
為了簡化我們先從一個HTTP請求開始，簡要介紹一下一個HTTP求情的網絡傳輸過程，也就是所謂的「從輸入URL到頁面下載完的過程中都發生了什麼事情」。
● DNS Lookup 先獲得URL對應的IP地址
● Socket Connect 瀏覽器和服務器建立TCP連接
● Send Request 發送HTTP請求
● Content Download 服務器發送響應
如果下到物理層去講就有點耍流氓了。如果這些你還認可這幾個步驟的話，我們就來講一下這裡面存在的性能問題。
● 如果你對DNS的查詢還有印象的話現在反思一下，DNS Lookup就是為了獲取一串IP地址要和無數個DNS服務器進行通信，這要消耗多少時間？別忘了，你查詢完了的時候，你還沒和那邊的服務器通信呢。
● TCP連接要三次握手。如果服務器很遠的話這三次握手要花多少時間？別忘了建立連接之後你還沒發請求呢。（通常到這裡0.5秒就出去了）
● 發送HTTP請求的時候你要知道一點，就是我們的網絡帶寬上行和下行通常是不一樣的，通常上行的帶寬會小一些，一個的話還好，但是現在的網頁通常都會後續請求很多資源，帶寬小的時候上行擁塞怎麼辦？別忘了已經到第三步了，服務器還沒給你發響應呢，現在你的瀏覽器還什麼都畫不出來。
● 終於到了服務器發響應了，不巧你訪問的這個服務器比較忙，好幾萬個人都要這個資源，服務器的上行帶寬也是有限的，怎麼辦？
我覺得我出了幾道還不錯的面試題。順便提一下，前兩步的延遲和網絡帶寬的影響不大；後兩步加帶寬是能一定程度緩解，不過你要有錢，而且很貴。
雖說博主做過WebKit本地渲染的優化，但是深知網頁加載的主要時間還是浪費在網絡通信上，所以在這些步驟上的優化會比你在瀏覽器內核的優化省力且效果明顯。
網絡方面的主要優化手段，總結一下不外乎緩存、預取、壓縮、並行。以後如果再有面試問性能優化之類的問題，大家都可以照著這個思路去考慮。
下面就分階段介紹一下現有的優化手段。
DNS優化
對於DNS優化，緩存無疑是最簡單粗暴且效果明顯的了。說到緩存就一定要提到緩存層級：
● 瀏覽器DNS緩存
● 系統DNS緩存
● Hosts文件
● 各個DNS服務器上的緩存
當然DNS緩存失效期通常都比較短，很多情況下都要再去查找。為了降低用戶體驗到的延遲（注意這裡不是網絡延時），預取是一個不錯的方法。
比如說你敲網址的時候還沒有敲完，但是瀏覽器根據你的歷史發現你很有可能去訪問哪個網站，就提前給你做DNS預取了，比如你打了一個「w」的時候，chrome已經幫你去找weibo.com的IP地址了。chrome用戶看一下chrome://predictors 你就知道了。
此外瀏覽器還會記錄你過去的歷史，知道每個域名下通常還會有哪些其他的鏈接，以便建立起網站的拓撲結構。當你訪問這個域名下的網站，它就會預先對其他鏈接的域名進行DNS解析。
TCP優化
看到前面的DNS的具體優化這麼繁雜，知道這簡單的一步沒那麼簡單了吧。
結果到TCP這一步優化反而簡單了，因為剛才DNS已經把IP都預先弄到了，那麼我們順著剛才的步驟再建立連接就好了。
所以在你敲第一個字母的時候，DNS解析完了就去建立連接了，這時候你可能網址還沒敲完。當你剛訪問一個網站的時候，瀏覽器刷刷刷的幫你把到別的服務器的TCP連接給你建好。
HTTP傳輸優化
寫到這裡可能有人會想，既然已經把TCP連接建立好了，那我乾脆預取更進一步，把所有的鏈接內容直接預取下來不就好了，這樣我網址還沒敲完網頁就已經加載完成了。
這個想法是好的，但現實卻是殘酷的，因為要記住我們的帶寬是有限的，DNS和TCP連接量級都比較輕，對網絡帶寬不會佔據太多，但是HTTP傳輸就不一樣了。如果你所有鏈接都去預取的話，你的帶寬很快就被佔滿了，這樣你正常的請求無法得到滿足，性能反而會嚴重下降。
緩存就又出現了，提緩存必提層次結構。
● PageCache 這個是最快的了，直接在內存中緩存了現有網頁的DOM結構和渲染結果，這就是你為什麼在點前進後退的時候會這麼快。
● HTTP Cache 文件級別的Cache存在本地的文件系統上按照RFC2616實現。
● 代理Cache 如果是通過代理服務器上網的話，代理服務器通常也會按照緩存標準
● CDN 一個地理上離你很近的內容服務器，比如說你在北京請求杭州淘寶的一個圖片，結果在北京的一個CDN上有這個圖片，那麼就不用去杭州了。
● DMOC（distributed memory object caching system）CDN主要存放的是靜態數據，但是網頁中通常有很多動態的數據需要查數據庫，流量多了壓力就會很大，通常服務器外圍還會有一層內存緩存服務 器，專門緩存這些數據庫中的對象，據《淘寶技術這10年》稱可以減少99.5%的數據庫訪問。
● Server 其實真正落在服務器上的請求已經不多了。
大家看到這裡有沒有想到能在什麼地方再加一層緩存呢？其實可以在2和3之間加，也就是在路由器上加緩存。
小米路由器和搜狗合作的預取引擎其實就相當於在路由器上加一層緩存款順便智能預取一下。為什麼在這裡另起一段專門談小米呢？難不成是小米的水軍？才不是呢，是因為博主看到這個消息的時候心都涼了，和博主的畢設撞車了有木有。
去年在360剛出隨身Wi-Fi的時候博主想到了這麼個點子，還想著把這個東西做出來之後用這個創業和360談合作，結果最近剛做完，論文也投出去 了，幻想著開啟人生巔峰，顛覆行業，結果就發現小米和搜狗出了這麼個一樣的東西還都商業化了。說好的人生巔峰就這樣沒有了，早知道去年就先申請個專利了。
另一個HTTP常用的優化就是壓縮了，網絡傳輸時間＝消息大小/網速。既然網速比較貴那麼就壓縮一下吧，大部分服務器都會對HTTP消息進行gzip壓縮。可以在Http Header中看到，具體的就不細說了。
未來協議：SPDY
上面的都是傳統做法，下面講一個未來的技術。由於HTTP協議是上個世紀制定的協議了，已經不能很好地適應現在Web的發展，所以Google提出了SPDY協議，目前是指定中的HTTP2.0標準的一個底版。
SPDY主要有下面的特點：
● 一個TCP連接上並行多個HTTP連接，減少連接的建立時間。
● 請求優先級（目前還沒看到具體實現）。
● HTTP頭部壓縮，上文提到的HTTP壓縮是對HTTP body的壓縮，並沒有對頭部壓縮。對於小的HTTP消息，頭部的比重還是很大的，而現在的web中存在大量小消息。
● Server push/hint 服務器主動推送對象（可以想像成服務器幫客戶端預取）。
業界目前對SPDY是有贊有彈，博主也持謹慎的態度，主要在1和4上，4其實和之前提到的HTTP直接預取的矛盾點一樣，萬一推送的不需要又佔據了帶寬怎麼辦？hint到底該如何實現都有困難。
第一條潛在的風險就是TCP連接中途斷開，那麼所有的連接就全部停掉了，PC互聯網這種情況可能會少一些，但是移動互聯網中TCP連接斷開的情況還是比較常見的。
不過作為一個未來的技術，還是有必要關注一下。
沒有留言:
發佈留言