network總覽

找了個簡單的網頁來錄制network：?

名詞解釋：

• Name (&path): 資源的名稱及其路徑
• Method: 請求該資源的方法
• Status (&Text): 針對該請求服務器返回的狀態碼及描述該狀態碼的簡短信息
• Type: 該資源的類型

• Initator: 初始化該請求的對象或進程，可以是：

  • parser: html解析器
  • Redirect: 一個Http重定向初始化了該請求
  • Script: 以script標簽引用的js
  • Other: 其他情況如用戶點擊了一個鏈接或在地址欄輸入了一個地址

• Size: 資源的大小

• Time: (&Latency): Time就是從請求開始到接到最后一個字節所經歷的時間；而Latency為請求開始到接收第一個字節所經歷的時間。此處的請求開始指的是該請求的狀態從stalled（阻塞）狀態開始。注：后面會講到請求所經歷的幾個階段。
• Timeline: 該列呈現出了每個請求從阻塞狀態到完成請求所經歷的階段，和整個頁面從加載到完成過程中其中資源的加載流。
• Connection Id：該字段用來表示TCP連接的重用，也就是瀏覽器在做完一個請求后，它為后續的請求保持了TCP的連接，而不是讓后續的請求去進行握手和建立新的連接。因為RTT消耗和TCP的慢啟動使得重建TCP連接會比較耗資源。參考鏈接， 此處感謝裕波老師的解答。
• scheme: 該請求URI的scheme部分
• Connection: connection中包含了很多的標簽列表，其中最常見的是keep-alive和close，分別用于向服務器請求保持TCP連接和斷開TCP連接
• Keep-Alive: 在Connection為keep-alive時，該字段才有用，它用來說明服務器估計保留連接的時間和允許后續幾個請求復用這個保持著的連接
• Cache-Control: 指定緩存機制，它的優先級大于Last-Modified。即如果請求中使用了If-Modified-Since，而服務器中該資源確實符合條件，即沒有在指定日期之后修改過，但是Cache-Control中指定的該資源在緩存中的存活時間已經到了，那么服務器須重新發送該資源內容給客戶端，而不是一個簡單的304狀態。
• ETag: 該字段和Last-Modified類似，用于驗證資源是否被修改過。被修改過的資源的ETag會發生變化
• Last-Modified: 指定資源最后一次被修改的時間
• Cookies: 發送該請求時附帶的Cookie信息的數量，它與Resource中你看到的cookies相對應。一個請求發送時，會附帶該域下所有的Cookie
• Set-Cookies: 該請求設置的Cookie數量

關于cookie的延伸：

• 傳輸效率：使用靜態服務器，因為該域不牽涉任何驗證信息，無需cookie進行請求關聯，所有請求無需附加cookie，加快傳輸效率
• 安全問題：我們通過對cookie標注http-only來禁止js腳本對其的訪問。防止XSS攻擊
• 存儲數量：各個瀏覽器對cookie數量均有限制，20-50幾個不等（此條引自互聯網，沒做過測試）
• Cookie工具: 記得有次為了驗證問題，使用了Chrome插件EditThisCookie手動添加了我們自己網站的cookie，就是從一個瀏覽器登陸上之后，記下Cookie信息，然后在Chrome中手動添加該Cookie，結果網站剛打開就成了登陸狀態。

關于連接復用

上面的圖是谷歌官網加載的部分截圖，可以看到谷歌已經在使用http/2了，其實當時沒看到這個protocol字段的時候，一直納悶為什么keep-alive都是空的情況下，請求是如何保持TCP復用的。所以答案就在此了吧。參考h2-14。 看下百度的加載過程：?這也是其中一部分，可以看到此處使用的是http/1.1，Connection為keep-alive，其中很多Connection Id是一致的。

事件標注

紫色的線表示DomContentLoaded事件，即該時間點頁面中的DOM建立完成，發生了DomContentLoaded事件 紅色的線表示load事件，即該時間點頁面加載完了所有的資源，發生了load事件

請求經歷的階段

• Stalled: 即請求處于阻塞狀態, 如之前有很多請求沒處理完，而瀏覽器對同域并發請求有限制，導致后面的請求處于阻塞狀態
• Proxy negotiation: 與代理服務器的連接通信階段
• DNS Lookup: DNS查找階段（本請求未涉及，只有在首次訪問一個新的域名的時候才會有該階段）
• Initial Connection / connecting: 建立連接的過程，包含TCP握手/重試，商定SSL
• SSL: 完成SSL握手階段
• Request sent: 發送請求，通常只要不到1ms的時間
• Waiting(TTFB): 發出請求后等待服務端響應的時間，響應時間極為第一個字節發送過來的時間
• Content Download: 接收響應數據的時間

Data URL

這個特殊的請求，沒有對應的Remote Address、cookies、Connection Id等，是不是不需要TCP連接呢？

單獨把這個URI拿出來寫入地址欄做請求：?結論如下：

• 有請求頭部，也有返回頭部
• 請求的地址很長
• 有狀態碼信息
• 阻塞階段后直接開始下載資源，完全不牽涉到和其它HTTP請求的通信、請求等階段

那么既然如此： 其實我們大致也能想到，它不依賴于相應主體（因為它沒有嘛）。那么它的數據包含在哪里呢？你猜對了，全部包含在這個Request URL中。這種方式比較節省資源，因為它無需進行連接階段。具體可以參考MDN中關于Data URL的介紹

除此之外，你可以參照chrome官方開發工具文檔中的介紹：https://developer.chrome.com/devtools/docs/network#resource-network-timing 歡迎您的批注，如有錯誤，望不吝指正～

from:?http://sentsin.com/web/1185.html

總結

以上是生活随笔為你收集整理的分析chrome中的network面板的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。