又到了三月，處于一些眾所周知的原因。把之前沒有完成的文章往出放一放官帘，增加一些大家對我的了解。
問題背景
有一天被pm小姐姐反饋網(wǎng)站無法打開昧谊，一直是白屏刽虹； 我再本地打開了一下是正常的，而且展示速度也是正常的呢诬；查了下日志報錯也沒有啥問題涌哲；這個頁面中只有一個展示二維碼，掃碼登錄的功能馅巷；
于是開始了我的debug之旅：
-
收集了報錯現(xiàn)場 ---小姐姐的錯誤請求的curl以及截圖膛虫；發(fā)現(xiàn)請求一直pending，直到30s之后才會正常返回钓猬，于是排除了網(wǎng)絡導致的請求延遲之后稍刀，開始考慮是什么因素致使請求一直被掛起呢？
收集的請求
30s后返回 -
分析了一下每個請求的 Timing之后發(fā)現(xiàn)：每個請求的Stalled時間都很久敞曹，但是又都可以發(fā)送成功账月。
image.png
所以要了解一下Timing之中各個參數(shù)的意義，這個參數(shù)其實在優(yōu)化網(wǎng)絡請求時我們也有了解過澳迫，順手做一下復習：
- Queuing - 資源加載的排隊
- Stalled/Blocking - 請求等待發(fā)送所用的時間局齿。Queuing中的所有原因加上代理協(xié)商所用的任何時間。
- Proxy Negotiation - 與代理服務器連接協(xié)商所用的時間橄登。
- DNS Lookup - DNS查詢所用的時間
- Initial Connection / Connecting - 建立連接所用的時間抓歼，包括TCP 握手/重試和協(xié)商 SSL的時間讥此。
- SSL - 完成SSL握手所用的時間。
- Request Sent / Sending - 發(fā)出網(wǎng)絡請求所用的時間谣妻。通常不到一毫秒萄喳。
- Waiting (TTFB) - 等待初始響應所用的時間，也稱為至第一字節(jié)的時間蹋半。
- Content Download / Downloading - 接收響應數(shù)據(jù)所用的時間他巨。
畫一畫重點 請求等待發(fā)送所用的時間。Queuing中的所有原因加上代理協(xié)商所用的任何時間减江。
在查看我的請求為何被掛起的過程中染突，突然發(fā)現(xiàn)我的請求優(yōu)先級是
medium，話說會不會是被更高優(yōu)先級的請求擺了一道呢辈灼？
在 關于請求被掛起頁面加載緩慢問題的追查 這篇文章中了解到份企，chrome有cache_lock的機制，并且可以通過查看chrome 網(wǎng)絡日志的方式來查看巡莹，并且在其中可以查看請求的優(yōu)先級薪棒；
- 于是NetLog 粉墨登場
-
瀏覽器輸入
chrome://net-export/打開 Chrome NetLog ，按照步驟收集榕莺，對應時間的網(wǎng)絡日志俐芯；并且下載到本地；
NetLog -
在 NetLog Viewer钉鸯，上傳剛才下載好的網(wǎng)絡日志（不排除可以肉眼看出日志中想要的內容的可能吧史，我試了一下，失敗了）唠雕。
NetLog Viewer
上傳完成狀態(tài) 點擊左側的
Event贸营，然后按需搜索就好了。在這里我看到了我心儀已久的priority岩睁，發(fā)現(xiàn)似乎請求集美們都是medium钞脂，沒有人比對應的請求更優(yōu)秀。（ 走偏-
但是不太影響我們在網(wǎng)絡日志中發(fā)現(xiàn)了所有請求的對應狀態(tài)捕儒，麻麻再也不怕別人問我請求中狀態(tài)變化了冰啃。（ 怕
priority 意識到可能不是這個原因，還是花了點時間搞清楚了 https://juejin.im/post/5c7cc63951882562e7482c65
雖然在網(wǎng)絡日志這里沒有解決問題刘莹，但是還是發(fā)現(xiàn)了一個重要的表象 ----
校驗二維碼的請求怎么會這么多阎毅？（ 列文虎克
- 震驚的發(fā)現(xiàn)在瀏覽器的其他tab下，打開了一個閑置的登錄頁面点弯，失控了一樣發(fā)送校驗請求扇调。關掉之后，本頁面的登錄抢肛、加載也回歸了正常狼钮。（如此碳柱，我們也抓到了本次bug的真兇！）可是真兇的成因不在本篇文章的了解范圍內熬芜，按下不表了士聪。（ 已手刃
探究下為什么會出現(xiàn)這個情況？
排除代碼中的bug本身猛蔽，造成這個現(xiàn)象的原因其實是因為瀏覽器對同一域名請求是有最大并發(fā)數(shù)限制的。正是因為瘋狂發(fā)起的請求超過了請求閾值灵寺，并且這個檢查接口本身返回就比較慢曼库，造成了后續(xù)請求的掛起而不是直接失敗。
-
不同瀏覽器對并發(fā)限制也不盡相同：
各瀏覽器并發(fā)統(tǒng)計
- 究其原因是處于多方面因素的優(yōu)化考量：
- 對客戶端操作系統(tǒng)而言略板，過多的并發(fā)涉及到端口數(shù)量和線程切換開銷毁枯。
- HTTP/1.1有Keep Alive，支持復用現(xiàn)有連接叮称，等請求返回回來后种玛，再復用連接請求可以快很多。
- 將所有請求一起發(fā)給服務器瓤檐，也很可能會引發(fā)服務器的并發(fā)閾值控制而被BAN赂韵。
- 同樣涉及到的優(yōu)化方式也比較多：
- domain hash：對資源做哈希，請求到不同的域下面挠蛉。關于域名發(fā)散與收斂祭示，其實要對不同場景分別做細化了。
- cookie free：前后端分離谴古，減少不必要的cookie提交质涛。
- css sprite：將零星的圖片整合到一張大圖中，減少請求次數(shù)掰担。
- js/css combine：資源合并汇陆，減少請求次數(shù)，不過也會增加文件修改的幾率带饱。
- max expires time：合理設置客戶端緩存時間毡代。
- loading images on demand：圖片按需加載。
- 夾帶一些這方面的面試題附送給各位：
https://juejin.im/post/5d59ffe46fb9a06ad0056ddf
以上勺疼。
參考鏈接：
- https://segmentfault.com/a/1190000015133004
- https://developers.google.com/web/tools/chrome-devtools/network/understanding-resource-timing?hl=zh-cn
- https://blog.csdn.net/zhang_zhenwei/article/details/90692095
- https://www.cnblogs.com/sunsky303/p/8862128.html
- https://www.zhihu.com/question/20474326
- http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/
