network總覽

找了個簡單的網(wǎng)頁來錄制network：?

名詞解釋：

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

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

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

• Size: 資源的大小

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

關(guān)于cookie的延伸：

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

關(guān)于連接復用

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

事件標注

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

請求經(jīng)歷的階段

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

Data URL

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

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。