高階Web必備：網路優化，拿去鎮住面試官

摘要： 前言 最近忙的要死，app要上線一系列功能…到週末只想躺著，今天的文章是來自哥們的一篇網路效能優化的文章。雖然他搞的是前端，但是網路這一塊是“大家”的，所以個人覺得各職業小夥伴看一看沒壞處~ 強調HTTP請求的完整過程 DNS解析 首先會搜尋瀏覽器自身的DNS快取(快...

前言

最近忙的要死，app要上線一系列功能…到週末只想躺著，今天的文章是來自哥們的一篇網路效能優化的文章。雖然他搞的是前端，但是網路這一塊是“大家”的，所以個人覺得各職業小夥伴看一看沒壞處~

強調HTTP請求的完整過程

• DNS解析
• 首先會搜尋瀏覽器自身的DNS快取(快取時間比較短，大概只有1分鐘，且只能容納1000條快取)
• 如果瀏覽器自身的快取裡面沒有找到，那麼瀏覽器會搜尋系統自身的DNS快取
• 如果還沒有找到，那麼嘗試從 hosts檔案裡面去找
• 在前面三個過程都沒獲取到的情況下，就遞迴地去域名伺服器去查詢
• 建立TCP連結
• 拿到域名對應的IP地址之後，瀏覽器會以一個隨機埠(1024<埠<65535)向伺服器的WEB程式(常用的有httpd，nginx)等的80埠傳送連結請求。
• 連線請求(原始的http請求經過TCP/IP4層模型的層層封包)到達伺服器端(這中間有各種路由裝置，區域網內除外)
• 進入到網絡卡，然後進入到核心的TCP/IP協議棧(用於識別連線請求，解封包，一層一層的剝開)，還有可能要經過Netfilter防火牆(屬於核心的模組)的過濾，最終達到WEB程式
• 建立了TCP/IP的連線
• TCP連線的三次握手/四次握手
• SYN > SYN-ACK > ACK(HTTPS協議還有一個ssl握手過程)

• 三次握手
• HTTP重定向的話，從頭開始握手過程
• Web瀏覽器傳送HTTP請求報文
• HTTP請求報文由三部分組成：請求行，請求頭和請求正文
• Web伺服器傳送HTTP響應報文
• HTTP響應也由三部分組成：狀態碼，響應頭和實體內容
• Web伺服器關閉TCP連線

假設一個典型的寬頻環境

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

網路傳輸層時間分析

• 總時間(470ms)
• 50ms for DNS
• 80ms for TCP handshake (one RTT)
• 160ms for SSL handshake (two RTT's)
• 40ms (傳送請求到伺服器)
• 100ms (伺服器處理)
• 40ms (伺服器回傳響應資料)
• 一個請求耗費470ms，事實上，470ms已經很樂觀了
• (較早的資料，現在的DNS預解析和優化已經將這個時間減少部分)

優化方案

最快的請求就是沒有請求

優化DNS解析

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

優化快取效能

• 強快取和協商快取的概念
• 1)瀏覽器在載入資源時，先根據這個資源的一些http header判斷它是否命中強快取，強快取如果命中，瀏覽器直接從自己的快取中讀取資源，不會發請求到伺服器。比如某個css檔案，如果瀏覽器在載入它所在的網頁時，這個css檔案的快取配置命中了強快取，瀏覽器就直接從快取中載入這個css，連請求都不會發送到網頁所在伺服器;
• 2)當強快取沒有命中的時候，瀏覽器一定會發送一個請求到伺服器，通過伺服器端依據資源的另外一些http header驗證這個資源是否命中協商快取，如果協商快取命中，伺服器會將這個請求返回，但是不會返回這個資源的資料，而是告訴客戶端可以直接從快取中載入這個資源，於是瀏覽器就又會從自己的快取中去載入這個資源;
• 3)共同點是：如果命中，都是從客戶端快取中載入資源，而不是從伺服器載入資源資料;
• 4)區別是：強快取不發請求到伺服器，協商快取會發請求到伺服器。
• 5)當協商快取也沒有命中的時候，瀏覽器直接從伺服器載入資源資料。
• 快取的實現：本地磁碟和記憶體
• 記憶體模式主要應用於無痕瀏覽，在視窗關閉時清除掉
• 磁碟快取實現了它自己的一組資料結構, 它們被儲存在一個單獨的快取目錄裡。其中有索引檔案(在瀏覽器啟動時載入到記憶體中)，資料檔案(儲存著實際資料，以及HTTP頭以及其它資訊)
• 實現方式：Expires, ETag, Last-Modified, keepalive，Cache-Control(具體細節請移步HTTP-header)

使用Service Worker

• 概念：谷歌開發的，在後臺啟動的一條服務Worker執行緒，作用是不管開多少個頁面始終只有一個Worker在負責管理，把資源快取起來，攔截頁面請求，檢視快取。
• Service Worker結合Web APP Manifest能實現離線使用，斷網時返回200，提示使用者把網站新增圖示到桌面(也是PWA的檢測標準)
• 相容性問題：現在所有的瀏覽器均支援Service Worker

利用Chrome Devtools進行優化傳輸資源檢查與優化體積

• console
• console.log: 不解釋
• console.table: 表格形式列印複雜的資料結構
• console.dir: 遞迴列印物件的所有屬性
• console.trace(): 追蹤函式的呼叫軌跡
• console.group()、console.groupEnd(): 分組列印資訊
• 帶樣式列印

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

• 檢查沒用的CSS/JS

Chrome瀏覽器提供的相關資料

• 檢視快取儲存的資料和響應處理: chrome://net-internals/#httpCache
• DNS度量資料: chrome://histograms/DNS
• DNS快取: chrome://net-internals/#dns
• Chrome瀏覽器的url表: chrome://chrome-urls/