分佈式架構 網絡傳輸優化
本文主要講解，瀏覽器請求過程及網絡傳輸等優化手段
優化之前首先了解其調用過程，如下圖：
流程分析
-
通過URL請求到服務器，瀏覽器就要知道這個url對應的ip是什麼？只有知道了ip地址，瀏覽器才能準備把請求發送到指定服務器的具體ip和端口上去。瀏覽器的DNS解析器負責把url解析爲正確的ip地址，這個解析很花時間，而且這個解析時間段，瀏覽器不能從服務器那裏下載任何東西。瀏覽器和操作系統提供了DNS解析緩存支持
-
獲取IP之後，瀏覽器會請求與服務器連接，TCP經過3次握手後建立連接通道
-
瀏覽器真實發送http請求，發送請求報文（請求行：包含請求方法、URI、HTTP版本信息，請求首部字段，請求內容實體，空行）
-
通用首部字段（請求報文與響應報文都會使用的首部字段）
Date：創建報文時間
Connection：連接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式 -
請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內容編碼
Accept-Language：可接受的自然語言 -
網絡開始傳輸請求到服務器，這個會包含很多時間，如網絡阻塞時間、網絡延遲時間、真正傳輸內容時間等
-
web服務器接收到請求，會根據url上下文轉交給相應web應用進行處理
-
web應用會經過很多處理，如 filter、aop前置處理、IOC處理、處理尋找對象和創建，進行業務處理後生成Response對象，熟悉spring對此過程更清晰
-
返回HTTP響應報文（狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語,響應首部字段,響應內容實體,空行）
-
響應首部字段（響應報文會使用的首部字段）
Accept-Ranges：可接受的字節範圍
Location：令客戶端重新定向到的URI
Server：HTTP服務器的安裝信息 -
實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
Allow：資源可支持的HTTP方法
Content-Type：實體主類的類型
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的自然語言
Content-Length：實體主體的的字節數
Content-Range：實體主體的位置範圍，一般用於發出部分請求時使用 -
通過網絡傳輸應答內容回到前端瀏覽器，先返回html代碼，不包含圖片、外部腳本、css等
-
瀏覽器解析頁面，進行渲染和繪製過程
1.裝載和解析html文檔，構建DOM，如果在解析過程中發現需要其它資源，如圖片，瀏覽器會發出請求獲取資源
2.裝載和解析css，構建cssom
3.根據DOM和cssom構建渲染樹
4.然後對渲染樹節點進行佈局處理，確認其屏幕位置
5.渲染好的節點繪製到界面上，渲染引擎不會等到所有html都解析完後才創建佈局渲染樹，並行處理解析渲染樹同時向後端請求資源
重繪：頁面渲染到後面發現需要修改前面已經繪製元素的外觀，如背景色、文字顏色。需要重繪這個元素
迴流：頁面渲染到後面發現需要修改前面已經繪製好的元素某些行爲，引起頁面上某些元素佔位面積、定位方式、邊距的變化，會引起周圍或者整個頁面重新渲染
針對以上第三點之後，可以進行特定的網絡優化
優化思路：
- 儘量利用瀏覽器緩存，優化到極致能不傳輸最好不傳
- 儘量減少需要傳輸的內容數據量
- 儘量最短距離訪問，比如使用客戶端最近CDN
- 儘量優化網絡鏈路
詳細描述
- 使用瀏覽器本身緩存，儘量減少來回傳輸數據量
- 精簡代碼，移除不必要的字符以減少其大小
- 靜態文件，如JS/CSS，進行混淆壓縮，如jsmin、YUIcompressor、CSScompressor
- 優先考慮使用CSS來代替，其次纔是圖片裁剪，如果條件允許，選擇有損壓縮格式，如jpg
針對大圖片，儘量進行精簡，在圖片效果和大小之間仔細斟酌 - 壓縮請求傳輸內容，前後端交互文章中有詳細實例說明，使用壓縮 如Gzip 後再傳輸給客戶端，客戶端接收後由瀏覽器進行解壓，稍微會佔取客戶端和服務器的CPU，但是會顯著提高寬帶利用率，特別是純文本，相當明顯
- 減少cookie傳遞，http規範中描述，每個客戶端最多保持300個，每個域名下最多20個，其大小基本保持4K左右，如需傳輸控制其傳輸大小
總結
web調用過程分爲很多階段、不同階段處理方式不同，其過程鏈路複雜甚長，瞭解過程後可對其中特定點進行優化，本文主要特定闡述網絡傳輸的優化方式，週期甚短，優化過後效果顯著。
作者簡介：張程 技術研究
更多文章請關注微信公衆號：zachary分解獅 (frankly0423)
