前言

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

強調HTTP請求的完整過程

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

• 三次握手
• HTTP重定向的話，從頭開始握手過程
• Web瀏覽器發(fā)送HTTP請求報文
• HTTP請求報文由三部分組成：請求行，請求頭和請求正文
• Web服務器發(fā)送HTTP響應報文
• HTTP響應也由三部分組成：狀態(tài)碼，響應頭和實體內容
• Web服務器關閉TCP連接

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

• 沒有本地緩存
• 相對較快的DNS解析(50ms)，TCP握手，ssl協(xié)商
• 較快的服務器響應時間(100ms)
• 一次延遲(80ms)

網(wǎng)絡傳輸層時間分析

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

優(yōu)化方案

最快的請求就是沒有請求

優(yōu)化DNS解析

• 使用DNS緩存
• 加快DNS解析速度
• 使用DNS負載均衡
• 為同一個主機名配置多個IP地址，在應答DNS查詢時，DNS服務器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結果，將客戶端的訪問引導到不同的機器上去，使得不同的客戶端訪問不同的服務器，從而達到負載均衡的目的。

優(yōu)化緩存性能

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

使用Service Worker

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

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

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

• 帶樣式打印
• 檢查沒用的CSS/JS
• more tools=>Coverage

• 檢查沒用的CSS/JS

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

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