前言
簡單介紹一下我為什么要整理這個抓包，因為工作需要吧，以前有網絡基礎，但是如何應用這些網絡基礎還是缺乏系統化的應用，所以想整理一些系統化的應用，並且可以提升自己的應用實際水平。
簡單點說就是說基礎有，但是如何去利用這些基礎知識呢？ 如何更好的去使用呢，這個需要一系列話的學習，整理一下。
首先整理一下google瀏覽器如何去查看http的一些協議。
正文
打開面板
control+shift+i:
關閉也是control+shift+i
面板上的內容:
功能分別如下:
-
控制面板的外觀與功能
-
過濾請求列表中顯示的資源
-
概覽： 顯示http請求、響應的時間軸
-
請求列表： 默認時間排序，可選擇顯示列
-
概要： 請求總數、總數據量、總花費時間等
首先介紹一下這個過濾：
這一排中讓人不解的可能就是這個hide data urls，這個東西了。
這東西是這樣的，比如我們的url可以是這種base64的。
這里面隱藏的就是這種data urls。
WS：全稱 WebSocket，是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的協議。
Manifest 安卓開發文件名，屬於 AndroidManifest.xml 文件，在簡單的 Android 系統的應用中提出了重要的信息碼。
Has blocked cookies：僅顯示具有阻止響應 cookie 的請求。
3rd-party requests 就是帶第三方庫，這里值得是非同源庫。
blocked requests 這個一般是被阻止的跨域哈，就是說瀏覽器阻止的請求了。
還可以通過屬性過濾：
比如：
中間加空格或者空格可以多個屬性空格。
有個比較使用多的就是查看是否緩存中使用了的。
還有些比較實用的哈，比如一些set cookie之類的:
列表排序:
按照其他的時間哈:
請求列表我們也可以添加哈：
initiator:
然后這個size 也是值得關注的，下面那個是壓縮后的大小，下面那個是解壓后的大小。
然后我們還可以增加一些自定義的頭部：
預覽信息:
這里可能有點難理解的就是這個上下游哈：
比如說我訪問一個頁面，然后里面里面有張圖片src=‘xxx’，這個訪問頁面得到html就是上游，然后加載圖片就是下游。
可以通過shilt 將鼠標放在某個請求上，藍色的就是上游紅色的就是下游。
瀏覽器加載時間:
時間詳細分布:
簡單介紹一下哈:
queueing 就是這個請求加入隊列到真正發起響應的時間。
Stalled. 請求會因為上面的queueing 一個原因而阻塞
proxy nogotiation: The browser is negotiating the request with a proxy server.
Request sent（發送請求）： 發送HTTP請求的時間（從第一個bit到最后一個bit）
Waiting (TTFB)（等待響應）： 瀏覽器正在等待響應的第一個字節。TTFB表示時間到第一個字節。這個時間包括1個延遲往返和服務器准備響應所花費的時間
Content Download（下載）： 下載HTTP響應的時間（包含頭部和響應體）
這上面有個難理解的地方哈：
queueing 可以理解為排隊實際。
這里stalled 就比較耐人尋味了。
有人給出這樣的一個解釋。
因為有“隊頭阻塞”，瀏覽器對每個域名最多開 6 個並發連接（HTTP/1.1），當頁面里鏈接很多的時候就必須排隊等待（Queued、Queueing），這里它就等待了 1.62 秒，然后才被瀏覽器正式處理；瀏覽器要預先分配資源，調度連接，花費了 11.56 毫秒（Stalled）;連接前必須要解析域名，這里因為有本地緩存，所以只消耗了 0.41 毫秒（DNS Lookup）；與網站服務器建立連接的成本很高，總共花費了 270.87 毫秒，其中有 134.89 毫秒用於 TLS 握手，那么 TCP 握手的時間就是 135.98 毫秒（Initial connection、SSL）；實際發送數據非常快，只用了 0.11 毫秒（Request sent）；之后就是等待服務器的響應，專有名詞叫 TTFB（Time To First Byte），也就是“首字節響應時間”，里面包括了服務器的處理時間和網絡傳輸時間，花了 124.2 毫秒；接收數據也是非常快的，用了 3.58 毫秒（Content Dowload）。
我們應該理解為處理到正在去連接所花費的時間。可能代碼里面是這樣的，從隊列中拿出來，做一些處理啊，到正在去請求花費的時間。
我這么說也是有依據的，比如要和代理去協商，是加入到stalled里面的。
結
下一節介紹wireshark。