博客原文地址：Claiyre的個(gè)人博客 https://claiyre.github.io/
博客園地址：http://www.cnblogs.com/nuannuan7362/
如需轉(zhuǎn)載蛾方，請(qǐng)?jiān)谖恼麻_(kāi)頭注明原文地址

衡量一個(gè)網(wǎng)站的性能有多個(gè)指標(biāo)酬凳，DNS解析時(shí)間铐维，TCP鏈接時(shí)間溉贿，HTTP重定向時(shí)間儒陨，等待服務(wù)器響應(yīng)時(shí)間等等刁品，從用戶(hù)角度來(lái)看印蔬，就可以歸結(jié)為該網(wǎng)站訪(fǎng)問(wèn)速度的快慢。也就是說(shuō)性能等于網(wǎng)站的訪(fǎng)問(wèn)速度基显。
早些年Amazon曾經(jīng)做過(guò)一個(gè)統(tǒng)計(jì)：網(wǎng)頁(yè)加載時(shí)間每延長(zhǎng)1秒鐘蘸吓，一年將減少16億美元的營(yíng)收。（16億美元是一個(gè)什么概念呢撩幽？2015年库继，百度全年的總營(yíng)收約100億美元！）窜醉。
鑒于性能的重要性宪萄，于是我們便經(jīng)常看到許多記錄提升訪(fǎng)問(wèn)速度的方法的文章：減少http請(qǐng)求榨惰，雪碧圖拜英，壓縮文件等等，看了這些文章后琅催，博主了解了一些比較普遍的提升性能的方法居凶，但是還不明白為啥這樣能提升速度呀！
作為一名有志青年藤抡，博主認(rèn)為侠碧，不僅要知其然，還要知其所以然缠黍。在查閱大量書(shū)籍和博文后舆床，終于明白了其中的玄機(jī)，特此記錄下來(lái)嫁佳，與大家分享。

接下來(lái)谷暮，我們首先來(lái)深入理解一個(gè)瀏覽器與互聯(lián)網(wǎng)的通信過(guò)程蒿往，然后分析每個(gè)過(guò)程所占時(shí)間的多少，以及哪些過(guò)程的時(shí)間是可以減少的湿弦，再說(shuō)明通過(guò)怎樣的方法可以減少這些時(shí)間瓤漏，以此來(lái)縮小網(wǎng)站總的加載時(shí)間，提升網(wǎng)站的訪(fǎng)問(wèn)速度。

從輸入url到瀏覽器開(kāi)始渲染頁(yè)面中間都發(fā)生了什么

互聯(lián)網(wǎng)內(nèi)各網(wǎng)絡(luò)設(shè)備間的通信都遵循TCP/IP協(xié)議蔬充，利用TCP/IP協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)蝶俱，會(huì)通過(guò)分層順序與對(duì)方進(jìn)行通信。分層由高到低分別為：應(yīng)用層饥漫、傳輸層榨呆、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層庸队。發(fā)送端從應(yīng)用層往下走积蜻，接收端從數(shù)據(jù)鏈路層網(wǎng)上走。如圖所示：

1. 在瀏覽器中輸入url
   用戶(hù)輸入url彻消，如https://www.zhihu.com竿拆。其中https是協(xié)議，//后面的是網(wǎng)絡(luò)地址宾尚，網(wǎng)絡(luò)地址指出了請(qǐng)求的資源在哪個(gè)計(jì)算機(jī)上丙笋。網(wǎng)絡(luò)地址可以是IP地址，也可以是域名煌贴，這里是域名御板，域名更方便記憶

2. 瀏覽器查詢(xún)緩存
   如果存在有效的緩存，則跳至第11步的渲染階段崔步。

3. 應(yīng)用層DNS解析域名
   域名是為了方便人類(lèi)記憶稳吮，但計(jì)算機(jī)不能很好的處理域名，因?yàn)镮P地址的長(zhǎng)度是固定的32位（IPv6是128位）井濒，而域名的長(zhǎng)度不固定灶似，機(jī)器處理起來(lái)比較困難，因此需要有一個(gè)輔助系統(tǒng)提供域名到IP地址的映射瑞你，這個(gè)輔助系統(tǒng)就是DNS（Domain Name System）酪惭。 在收到一個(gè)域名后，客戶(hù)端會(huì)先檢查本地是否有對(duì)應(yīng)的IP地址者甲，若找到則返回響應(yīng)的IP地址春感。若沒(méi)找到則請(qǐng)求上級(jí)DNS服務(wù)器，直至找到根域虏缸。最終得到域名對(duì)應(yīng)的IP地址鲫懒，存在負(fù)載均衡時(shí)同一域名返回IP可能不同，所以IP地址才是是計(jì)算機(jī)在網(wǎng)絡(luò)中的唯一標(biāo)識(shí)刽辙。

4. 應(yīng)用層發(fā)送http請(qǐng)求
   http協(xié)議是用于客戶(hù)端與服務(wù)器端通信的一種協(xié)議窥岩，它是通過(guò)請(qǐng)求和響應(yīng)這種方式來(lái)實(shí)現(xiàn)通信的。HTTP請(qǐng)求包括請(qǐng)求報(bào)頭和請(qǐng)求主體兩個(gè)部分宰缤，其中請(qǐng)求報(bào)頭包含了至關(guān)重要的信息颂翼，比如請(qǐng)求的方法（GET晃洒，POST,PUT,DELETE,CONNECT...）、目標(biāo)url朦乏、遵循的協(xié)議（http / https / ftp…）球及，以及客戶(hù)端是否發(fā)送cookie等。

5. SSL/TLS安全傳輸協(xié)議
   它是位于傳輸層之上的一個(gè)安全套接層也就是https中的's'呻疹，確保了（1）所有信息都是加密傳播的吃引，第三方無(wú)法竊聽(tīng)（2）具有校驗(yàn)機(jī)制，一旦被篡改诲宇，通信雙方會(huì)立刻發(fā)現(xiàn)（3）配備身份證書(shū)际歼，防止身份被發(fā)現(xiàn)。
   為網(wǎng)絡(luò)通信提供安全保障姑蓝。

6. 傳輸層用TCP協(xié)議傳輸報(bào)文
   位于傳輸層的TCP協(xié)議為傳輸報(bào)文提供可靠的字節(jié)流服務(wù)鹅心。它為了方便傳輸，將大塊的數(shù)據(jù)分割成以報(bào)文段為單位的數(shù)據(jù)包纺荧，并為他們編號(hào)旭愧，方便服務(wù)器接收時(shí)能正確的快速還原報(bào)文信息。TCP協(xié)議通過(guò)三次握手來(lái)建立連接宙暇，通過(guò)四次揮手?jǐn)嚅_(kāi)連接输枯，保證了傳輸?shù)陌踩煽浚旅娴膬蓮垐D和那后地解釋了三次握手和四次揮手占贫。

7. 網(wǎng)絡(luò)層IP協(xié)議查詢(xún)MAC地址
   IP協(xié)議的作用是把TCP分割好的各種數(shù)據(jù)包傳送給接收方桃熄，這時(shí)就需要接收方的MAC 地址，也就是物理地址型奥。IP地址和MAC地址是一一對(duì)應(yīng)的關(guān)系瞳收，一個(gè)網(wǎng)絡(luò)設(shè)備的IP地址可以更換，但是MAC地址一般是固定不變的厢汹。ARP協(xié)議可以將IP地址解析成對(duì)應(yīng)的MAC地址螟深。當(dāng)通信的雙方不在同一個(gè)局域網(wǎng)時(shí)，需要多次中轉(zhuǎn)才能到達(dá)最終的目標(biāo)烫葬，在中轉(zhuǎn)的過(guò)程中需要通過(guò)下一個(gè)中轉(zhuǎn)站的MAC地址來(lái)搜索下一個(gè)中轉(zhuǎn)目標(biāo)界弧，路由提供這種中轉(zhuǎn)服務(wù)。

8. 數(shù)據(jù)到達(dá)數(shù)據(jù)鏈路層被處理包裝

在找到對(duì)方的MAC地址后搭综，就將數(shù)據(jù)發(fā)送到數(shù)據(jù)鏈路層垢箕，數(shù)據(jù)鏈路層負(fù)責(zé)三件事：封裝成幀，透明傳輸兑巾，差錯(cuò)檢測(cè)舰讹。

9. 物理層傳輸?shù)竭_(dá)服務(wù)器端
   數(shù)據(jù)進(jìn)入物理層到達(dá)服務(wù)器后，再經(jīng)歷3-7的相反操作：在鏈路層接收到數(shù)據(jù)包闪朱，再層層向上直到應(yīng)用層月匣。這過(guò)程中包括在運(yùn)輸層通過(guò)TCP協(xié)議將分段的數(shù)據(jù)包重新組成原來(lái)的HTTP請(qǐng)求報(bào)文。

10. 服務(wù)器響應(yīng)
    服務(wù)接收到客戶(hù)端發(fā)送的HTTP請(qǐng)求后奋姿，查找客戶(hù)端請(qǐng)求的資源锄开，并返回響應(yīng)報(bào)文，響應(yīng)報(bào)文中包括一個(gè)重要的信息——狀態(tài)碼称诗。狀態(tài)碼由三位數(shù)字組成萍悴，其中比較常見(jiàn)的是200 OK表示請(qǐng)求成功。301表示永久重定向寓免，即請(qǐng)求的資源已經(jīng)永久轉(zhuǎn)移到新的位置癣诱。在返回301狀態(tài)碼的同時(shí)，響應(yīng)報(bào)文也會(huì)附帶重定向的url袜香，客戶(hù)端接收到后將http請(qǐng)求的url做相應(yīng)的改變?cè)僦匦掳l(fā)送撕予。

11. 客戶(hù)端接收響應(yīng)并渲染頁(yè)面
    服務(wù)器的響應(yīng)到達(dá)客戶(hù)端后，瀏覽器會(huì)根據(jù)接收到的數(shù)據(jù)渲染頁(yè)面蜈首。渲染階段也有許多改善性能的方案实抡，本文的重點(diǎn)不在這里，下次在另一篇文章里細(xì)說(shuō)欢策。

以上就是網(wǎng)絡(luò)通信的整個(gè)過(guò)程吆寨，深究起來(lái)極其復(fù)雜，用到的協(xié)議也是非常多踩寇，不得不由衷地佩服先人的智慧啄清！

chrome開(kāi)發(fā)者模式Network下分析各個(gè)過(guò)程對(duì)應(yīng)時(shí)間

chrome瀏覽器下按F12打開(kāi)開(kāi)發(fā)者工具，找到第四欄的network俺孙，在瀏覽器上方地址欄輸入一個(gè)自己從未訪(fǎng)問(wèn)過(guò)的url,目的是保證請(qǐng)求的內(nèi)容沒(méi)被緩存在本地（為此辣卒，博主還清理了一波瀏覽器緩存(；′⌒`)鼠冕，傷心）添寺。
整體大概是這樣：

找一個(gè)有代表性的請(qǐng)求，如上圖紅色框所示懈费，將鼠標(biāo)放在黃色箭頭所指的地方计露，會(huì)浮現(xiàn)該請(qǐng)求timeline的詳情，如下圖所示

這張?jiān)斍閳D中可謂是藏了不少有價(jià)值的信息呢( ?? ω ?? )?憎乙，注意看咯票罐！

1. Resource scheduling（紅色圈圈3）
   第一部分首先是資源調(diào)度的時(shí)間。
   紅色圈圈告訴我們Queued at 214.06ms泞边，在214.06 ms 時(shí)開(kāi)始排隊(duì)该押。排了0.57ms后（圈圈4），就Started at 214.63ms（圈圈2）阵谚，也就是說(shuō)資源調(diào)度結(jié)束后就開(kāi)始處理該指令了蚕礼。
   據(jù)chrome官方解釋?zhuān)瑢?dǎo)致Queueing的原因有以下幾種：

• 請(qǐng)求已被渲染引擎推遲烟具，因?yàn)樵撜?qǐng)求的優(yōu)先級(jí)被視為低于關(guān)鍵資源（例如腳本/樣式）的優(yōu)先級(jí)。 圖像經(jīng)常發(fā)生這種情況奠蹬。
• 請(qǐng)求已被暫停朝聋，以等待將要釋放的不可用 TCP 套接字。
• 請(qǐng)求已被暫停囤躁，因?yàn)樵?HTTP 1 上冀痕，瀏覽器僅允許每個(gè)源擁有六個(gè) TCP 連接。
• 生成磁盤(pán)緩存條目所用的時(shí)間（通常非常迅速）

2. Connection Start（圈圈5）
   資源調(diào)度后就要開(kāi)始建立鏈接了狸演。
   圈圈6 Stalled代表 請(qǐng)求等待發(fā)送所用的時(shí)間言蛇，此時(shí)間包含第一部分中的第二步：查看瀏覽器緩存所用的時(shí)間，下圖是刷新后一個(gè)“from disk cache”文件的詳情圖宵距，可以很好地證明這一點(diǎn)腊尚。

圈圈7 Proxy negotiation 代表與代理服務(wù)器協(xié)商的時(shí)間
圈圈8 DNS Lookup 執(zhí)行 DNS 查詢(xún)所用的時(shí)間。 頁(yè)面上的每一個(gè)新域都需要完整的往返才能執(zhí)行 DNS 查詢(xún)消玄。對(duì)應(yīng)于第一部分中的“應(yīng)用層DNS解析域名”時(shí)間
圈圈9 Initial Connection 初始化連接所用的時(shí)間跟伏，包括 TCP 握手/重試和協(xié)商 SSL 的時(shí)間。對(duì)應(yīng)于第一部分的6和7
圈圈10 SSL 完成SSL握手所需要的時(shí)間翩瓜，對(duì)應(yīng)于第一部分的5

機(jī)智的你是不是已經(jīng)發(fā)現(xiàn)建立鏈接的時(shí)間剛好對(duì)應(yīng)于第一部分中的3-

3. Request/Response
   通信鏈接建立后受扳，就可以發(fā)送請(qǐng)求了，服務(wù)器處理后返回響應(yīng)兔跌，客戶(hù)端再根據(jù)響應(yīng)內(nèi)容下一步處理

圈圈11 Request sent 發(fā)送請(qǐng)求的時(shí)間勘高，這個(gè)是非常快的
圈圈12 Waiting（TTFB）等待服務(wù)器初始響應(yīng)所用的時(shí)間坟桅，也稱(chēng)為至第一字節(jié)的時(shí)間华望。 此時(shí)間將捕捉到服務(wù)器往返的延遲時(shí)間，以及等待服務(wù)器傳送響應(yīng)所用的時(shí)間仅乓。
最后是 Content Download赖舟，接受（下載）響應(yīng)數(shù)據(jù)所需要的時(shí)間。

可以發(fā)現(xiàn)夸楣，詳情圖中的時(shí)間順序和第一張網(wǎng)絡(luò)模型示意圖剛好一一對(duì)應(yīng)宾抓，只有TCP/IP連接建立完成后，才能再建立SSL/TLS豫喧，最后才可用http協(xié)議請(qǐng)求/響應(yīng)石洗。

到這里，想必你已經(jīng)明白了一次完整的請(qǐng)求需要經(jīng)歷的步驟和耗費(fèi)的時(shí)間紧显，那么這些時(shí)間中有哪些是可以人為減少的呢讲衫？我們可以通過(guò)怎樣的方式來(lái)減少這些時(shí)間來(lái)提高性能呢？
看下面

優(yōu)化web性能的若干方法

1. 減少http的請(qǐng)求數(shù)降低connection的時(shí)間
   由上面的詳情圖可以看到孵班，如果本地沒(méi)有緩存時(shí)涉兽，許多時(shí)間都花在了第二步Connection Start 建立鏈接上招驴，只有少部分花在了Content Download上。那好花椭，現(xiàn)在如果我們把兩個(gè)文件合并成一個(gè)忽匈，就可以用一次請(qǐng)求代替之前的兩次請(qǐng)求，理論上是不是就節(jié)約了一次Connection的時(shí)間了矿辽？合并的文件越多，節(jié)約的時(shí)間就越多郭厌。
   所以我們可以把圖片袋倔，css,js等一些可以合并的文件盡量合并來(lái)減少http的請(qǐng)求數(shù)，降低總的connection的時(shí)間折柠。
   細(xì)心的朋友可能會(huì)發(fā)現(xiàn)宾娜，有的請(qǐng)求是幾乎沒(méi)有connection的時(shí)間的，它們的詳情圖長(zhǎng)這樣：

查看request header發(fā)現(xiàn)其中有一個(gè)這樣的鍵值對(duì)：

對(duì)扇售，就是因?yàn)樗八琱ttp的keep-alive可以在一定的時(shí)間內(nèi)保證連接的可復(fù)用性，減少連接時(shí)間承冰，但它的期限是有限的华弓，可以看到network下的請(qǐng)求中還是有若干次請(qǐng)求是有connection的時(shí)間的，所以合并文件還是必須的困乒。

2. 壓縮文件降低content download的時(shí)間
   上圖中content download的時(shí)間不算多寂屏，只有20.47ms ，但它還是可以被減少的呀娜搂，如果我們壓縮了該文件迁霎，在相同物理環(huán)境下，它會(huì)變得更少呀百宇！能減少一點(diǎn)是一點(diǎn)嘛考廉。
   而且在一些項(xiàng)目中，部分文件可達(dá)幾百kb携御，這時(shí)content download的時(shí)間就不止20ms了昌粤，所以壓縮后還是能減少不少時(shí)間的。
   所以項(xiàng)目上線(xiàn)前因痛，像一些圖片啦婚苹，css,js啦，能壓縮的還是盡量壓縮鸵膏。

3. 使用瀏覽器緩存
   把網(wǎng)站里面更新頻率比較低的靜態(tài)資源緩存在瀏覽器中膊升，能夠很好地提升速度。事實(shí)證明的確如此谭企，( ?? ω ?? )?

畢竟對(duì)于幾百K的文件硬盤(pán)還是可以秒讀的嘛廓译。
通過(guò)設(shè)置 http 頭里的 Cache-Control 和 Expires 屬性來(lái)設(shè)定瀏覽器緩存時(shí)間评肆，另外還有 Etags 和 opcode 的緩存，根據(jù)具體情況進(jìn)行選擇吧

4. 減少DNS查找
   DNS用于映射主機(jī)名和IP地址非区，一般一次解析需要20～120毫秒瓜挽。瀏覽器會(huì)首先根據(jù)頁(yè)面的主機(jī)名進(jìn)行域名解析，在有ISP返回結(jié)果之前頁(yè)面不會(huì)加載任何內(nèi)容征绸，所以減少DNS查找可以有效降低等待時(shí)間久橙。為達(dá)到更高的性能，DNS解析通常被多級(jí)別地緩存管怠，如由ISP或局域網(wǎng)維護(hù)的caching server淆衷，本地機(jī)器操作系統(tǒng)的緩存（如windows上的DNS Client Service），瀏覽器渤弛。IE的缺省DNS緩存時(shí)間為30分鐘祝拯，F(xiàn)irefox的缺省緩沖時(shí)間是1分鐘。 我們能做的是盡量減少一個(gè)頁(yè)面的主機(jī)名她肯，但要在瀏覽器最大并行下載數(shù)跟dns查找之間做權(quán)衡佳头。根據(jù)雅虎的研究，最好將主機(jī)名控制在2-4個(gè)內(nèi)晴氨。

5. CDN加速
   CDN 的本質(zhì)也屬于緩存康嘉，內(nèi)容分發(fā)網(wǎng)絡(luò)，把數(shù)據(jù)緩存在里用戶(hù)近的地方瑞筐，使用戶(hù)盡快的獲取數(shù)據(jù)凄鼻。
   CDN 通常是部署在網(wǎng)絡(luò)運(yùn)營(yíng)商的機(jī)房，這些運(yùn)營(yíng)商為用戶(hù)提供網(wǎng)絡(luò)服務(wù)聚假，因此用戶(hù)請(qǐng)求的路由會(huì)優(yōu)先到達(dá) CDN 服務(wù)器块蚌，如果存在請(qǐng)求的資源的話(huà)，就直接返回膘格，以最短路徑返回響應(yīng)峭范，提高了用戶(hù)訪(fǎng)問(wèn)速度，同時(shí)還能夠?yàn)橹行臋C(jī)房減輕壓力瘪贱。其原理如下：

CDN 一般用來(lái)緩存靜態(tài)資源纱控，如css，Script腳本菜秦，靜態(tài)頁(yè)面甜害，圖片等，這些內(nèi)容修改頻率很低但是訪(fǎng)問(wèn)請(qǐng)求頻率很高球昨，因此放在 CDN 上能夠很好的改善訪(fǎng)問(wèn)速度

6. 減少重定向
   重定向是指將一個(gè)URL重新路由到另一個(gè)URL尔店。瀏覽器會(huì)自動(dòng)重定向請(qǐng)求到Location指定的URL上，也就說(shuō)把之前的過(guò)程又重復(fù)一遍才能請(qǐng)求到真正的資源，會(huì)極大地降低用戶(hù)體驗(yàn)嚣州。

好了鲫售，到此本文的主要內(nèi)容已全部完結(jié)了。
本文是博主在學(xué)習(xí)過(guò)程中的一個(gè)總結(jié)该肴，特此記錄下來(lái)備忘情竹，也希望對(duì)其他小伙伴有所幫助。其中如有敘述不當(dāng)之處匀哄，還望您能指出秦效，一起探討~

參考：(http://www.cnblogs.com/dojo-lzz/p/4591446.html)[http://www.cnblogs.com/dojo-lzz/p/4591446.html]
(http://seanlook.com/2015/01/07/tls-ssl/)[http://seanlook.com/2015/01/07/tls-ssl/]
(https://segmentfault.com/a/1190000007624980)[https://segmentfault.com/a/1190000007624980]