前言

最近忙的要死，app要上線一系列功能…到周末只想躺著，今天的文章是來(lái)自哥們的一篇網(wǎng)絡(luò)性能優(yōu)化的文章。雖然他搞的是前端，但是網(wǎng)絡(luò)這一塊是“大家”的，所以個(gè)人覺(jué)得各職業(yè)小伙伴看一看沒(méi)壞處~

強(qiáng)調(diào)HTTP請(qǐng)求的完整過(guò)程

• DNS解析
• 首先會(huì)搜索瀏覽器自身的DNS緩存(緩存時(shí)間比較短，大概只有1分鐘，且只能容納1000條緩存)
• 如果瀏覽器自身的緩存里面沒(méi)有找到，那么瀏覽器會(huì)搜索系統(tǒng)自身的DNS緩存
• 如果還沒(méi)有找到，那么嘗試從 hosts文件里面去找
• 在前面三個(gè)過(guò)程都沒(méi)獲取到的情況下，就遞歸地去域名服務(wù)器去查找
• 建立TCP鏈接
• 拿到域名對(duì)應(yīng)的IP地址之后，瀏覽器會(huì)以一個(gè)隨機(jī)端口(1024<端口<65535)向服務(wù)器的WEB程序(常用的有httpd，nginx)等的80端口發(fā)送鏈接請(qǐng)求。
• 連接請(qǐng)求(原始的http請(qǐng)求經(jīng)過(guò)TCP/IP4層模型的層層封包)到達(dá)服務(wù)器端(這中間有各種路由設(shè)備，局域網(wǎng)內(nèi)除外)
• 進(jìn)入到網(wǎng)卡，然后進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧(用于識(shí)別連接請(qǐng)求，解封包，一層一層的剝開(kāi))，還有可能要經(jīng)過(guò)Netfilter防火墻(屬于內(nèi)核的模塊)的過(guò)濾，最終達(dá)到WEB程序
• 建立了TCP/IP的連接
• TCP連接的三次握手/四次握手
• SYN > SYN-ACK > ACK(HTTPS協(xié)議還有一個(gè)ssl握手過(guò)程)

• 三次握手
• HTTP重定向的話，從頭開(kāi)始握手過(guò)程
• Web瀏覽器發(fā)送HTTP請(qǐng)求報(bào)文
• HTTP請(qǐng)求報(bào)文由三部分組成：請(qǐng)求行，請(qǐng)求頭和請(qǐng)求正文
• Web服務(wù)器發(fā)送HTTP響應(yīng)報(bào)文
• HTTP響應(yīng)也由三部分組成：狀態(tài)碼，響應(yīng)頭和實(shí)體內(nèi)容
• Web服務(wù)器關(guān)閉TCP連接

假設(shè)一個(gè)典型的寬帶環(huán)境

• 沒(méi)有本地緩存
• 相對(duì)較快的DNS解析(50ms)，TCP握手，ssl協(xié)商
• 較快的服務(wù)器響應(yīng)時(shí)間(100ms)
• 一次延遲(80ms)

網(wǎng)絡(luò)傳輸層時(shí)間分析

• 總時(shí)間(470ms)
• 50ms for DNS
• 80ms for TCP handshake (one RTT)
• 160ms for SSL handshake (two RTT's)
• 40ms (發(fā)送請(qǐng)求到服務(wù)器)
• 100ms (服務(wù)器處理)
• 40ms (服務(wù)器回傳響應(yīng)數(shù)據(jù))
• 一個(gè)請(qǐng)求耗費(fèi)470ms，事實(shí)上，470ms已經(jīng)很樂(lè)觀了
• (較早的數(shù)據(jù)，現(xiàn)在的DNS預(yù)解析和優(yōu)化已經(jīng)將這個(gè)時(shí)間減少部分)

優(yōu)化方案

最快的請(qǐng)求就是沒(méi)有請(qǐng)求

優(yōu)化DNS解析

• 使用DNS緩存
• 加快DNS解析速度
• 使用DNS負(fù)載均衡
• 為同一個(gè)主機(jī)名配置多個(gè)IP地址，在應(yīng)答DNS查詢(xún)時(shí)，DNS服務(wù)器對(duì)每個(gè)查詢(xún)將以DNS文件中主機(jī)記錄的IP地址按順序返回不同的解析結(jié)果，將客戶(hù)端的訪問(wèn)引導(dǎo)到不同的機(jī)器上去，使得不同的客戶(hù)端訪問(wèn)不同的服務(wù)器，從而達(dá)到負(fù)載均衡的目的。

優(yōu)化緩存性能

• 強(qiáng)緩存和協(xié)商緩存的概念
• 1)瀏覽器在加載資源時(shí)，先根據(jù)這個(gè)資源的一些http header判斷它是否***強(qiáng)緩存，強(qiáng)緩存如果***，瀏覽器直接從自己的緩存中讀取資源，不會(huì)發(fā)請(qǐng)求到服務(wù)器。比如某個(gè)css文件，如果瀏覽器在加載它所在的網(wǎng)頁(yè)時(shí)，這個(gè)css文件的緩存配置***了強(qiáng)緩存，瀏覽器就直接從緩存中加載這個(gè)css，連請(qǐng)求都不會(huì)發(fā)送到網(wǎng)頁(yè)所在服務(wù)器;
• 2)當(dāng)強(qiáng)緩存沒(méi)有***的時(shí)候，瀏覽器一定會(huì)發(fā)送一個(gè)請(qǐng)求到服務(wù)器，通過(guò)服務(wù)器端依據(jù)資源的另外一些http header驗(yàn)證這個(gè)資源是否***協(xié)商緩存，如果協(xié)商緩存***，服務(wù)器會(huì)將這個(gè)請(qǐng)求返回，但是不會(huì)返回這個(gè)資源的數(shù)據(jù)，而是告訴客戶(hù)端可以直接從緩存中加載這個(gè)資源，于是瀏覽器就又會(huì)從自己的緩存中去加載這個(gè)資源;
• 3)共同點(diǎn)是：如果***，都是從客戶(hù)端緩存中加載資源，而不是從服務(wù)器加載資源數(shù)據(jù);
• 4)區(qū)別是：強(qiáng)緩存不發(fā)請(qǐng)求到服務(wù)器，協(xié)商緩存會(huì)發(fā)請(qǐng)求到服務(wù)器。
• 5)當(dāng)協(xié)商緩存也沒(méi)有***的時(shí)候，瀏覽器直接從服務(wù)器加載資源數(shù)據(jù)。
• 緩存的實(shí)現(xiàn)：本地磁盤(pán)和內(nèi)存
• 內(nèi)存模式主要應(yīng)用于無(wú)痕瀏覽，在窗口關(guān)閉時(shí)清除掉
• 磁盤(pán)緩存實(shí)現(xiàn)了它自己的一組數(shù)據(jù)結(jié)構(gòu), 它們被存儲(chǔ)在一個(gè)單獨(dú)的緩存目錄里。其中有索引文件(在瀏覽器啟動(dòng)時(shí)加載到內(nèi)存中)，數(shù)據(jù)文件(存儲(chǔ)著實(shí)際數(shù)據(jù)，以及HTTP頭以及其它信息)
• 實(shí)現(xiàn)方式：Expires, ETag, Last-Modified, keepalive，Cache-Control(具體細(xì)節(jié)請(qǐng)移步HTTP-header)

使用Service Worker

• 概念：谷歌開(kāi)發(fā)的，在后臺(tái)啟動(dòng)的一條服務(wù)Worker線程，作用是不管開(kāi)多少個(gè)頁(yè)面始終只有一個(gè)Worker在負(fù)責(zé)管理，把資源緩存起來(lái)，攔截頁(yè)面請(qǐng)求，查看緩存。
• Service Worker結(jié)合Web APP Manifest能實(shí)現(xiàn)離線使用，斷網(wǎng)時(shí)返回200，提示用戶(hù)把網(wǎng)站添加圖標(biāo)到桌面(也是PWA的檢測(cè)標(biāo)準(zhǔn))
• 兼容性問(wèn)題：現(xiàn)在所有的瀏覽器均支持Service Worker

利用Chrome Devtools進(jìn)行優(yōu)化傳輸資源檢查與優(yōu)化體積

• console
• console.log: 不解釋
• console.table: 表格形式打印復(fù)雜的數(shù)據(jù)結(jié)構(gòu)
• console.dir: 遞歸打印對(duì)象的所有屬性
• console.trace(): 追蹤函數(shù)的調(diào)用軌跡
• console.group()、console.groupEnd(): 分組打印信息
• 帶樣式打印

• 帶樣式打印
• 檢查沒(méi)用的CSS/JS
• more tools=>Coverage

• 檢查沒(méi)用的CSS/JS

Chrome瀏覽器提供的相關(guān)數(shù)據(jù)

• 查看緩存存儲(chǔ)的數(shù)據(jù)和響應(yīng)處理: chrome://net-internals/#httpCache
• DNS度量數(shù)據(jù): chrome://histograms/DNS
• DNS緩存: chrome://net-internals/#dns
• Chrome瀏覽器的url表: chrome://chrome-urls/