我們在前端開發中經常用到chrome瀏覽器的network來查看，調試HTTP、HTTPS的網絡請求。
我們先來看的Network的使用。
Chrome的Network
我們平時能從Network裏看的如下圖
我們能看到HTTP/HTTPS請求的地址，協議，請求的大小，時間等。更多的信息可在title欄右鍵然後選擇即可
點擊某條請求可以查看詳細信息
header裏的東西我們就不多說了，我們看下timing裏的信息
1. Queuing（排隊中）
如果一個請求排隊，則表明：
1）請求被渲染引擎推遲，因爲它被認爲比關鍵資源（如腳本/樣式）的優先級低。這經常發生在 images（圖像） 上。
2）這個請求被擱置，在等待一個即將被釋放的不可用的TCP socket。
3）這個請求被擱置，因爲瀏覽器限制。在HTTP 1協議中，每個源上只能有6個TCP連接，這個問題將在下一面的章節中提到。
4）正在生成磁盤緩存條目（通常非常快）。
2.Stalled/Blocking (停止/阻塞)
發送請求之前等待的時間。它可能因爲進入隊列的任何原因而被阻塞。這個時間包括代理協商的時間。
3.Proxy Negotiation (代理協商)
與代理服務器連接協商花費的時間
4.DNS Lookup (DNS查找)
執行DNS查找所用的時間。 頁面上的每個新域都需要完整的往返(roundtrip)才能進行DNS查找。當本地DNS緩存沒有的時候，這個時間可能是有一段長度的，但是比如你一旦在host中設置了DNS，或者第二次訪問，由於瀏覽器的DNS緩存還在，這個時間就爲0了。
5.Initial Connection / Connecting (初始連接/連接)
建立連接所需的時間， 包括TCP握手/重試和協商SSL。
6.SSL
完成SSL握手所用的時間，如果是HTTPS的話
7.Request Sent / Sending (請求已發送/正在發送)
發出網絡請求所花費的時間。 通常是幾分之一毫秒。
8.Waiting (TTFB) (等待)
等待初始響應所花費的時間，也稱爲`Time To First Byte`(接收到第一個字節所花費的時間)。這個時間除了等待服務器傳遞響應所花費的時間之外，還捕獲到服務器發送數據的延遲時間。這些情況可能會導致高TTFB：1.客戶端和服務器之間的網絡條件差；2.服務器端程序響應很慢。
9.Content Download / Downloading (內容下載/下載)
接收響應數據所花費的時間。從接收到第一個字節開始，到下載完最後一個字節結束。
通過對請求發出和響應的每個階段的理解，我們就能分析出當前HTTP請求存在的問題，並據此解決問題。
客戶端與服務端通過HTTP協議的交互過程（TCP/IP的三次握手）
1、瀏覽器向服務器發出連接請求，併發送SYN包，進入SYN_SEND狀態，等待服務器確認。這是TCP三次握手的第一次。
2、服務器響應了瀏覽器的請求，確認瀏覽器的SYN（ACK=J+1），並且自己也發送SYN包也就是SYN+ACK包，要求瀏覽器進行確認，此時了服務器進入SYN_RECV狀態。這是TCP三次握手的第二次。
3、瀏覽器響應了服務器的SYN+ACK包，向服務器發送確認包ACK(ACK=K+1），此包發送完畢，瀏覽器和服務器進入ESTABLISHED狀態，這是TCP三次握手的第三次，握手完成，TCP連接成功建立。
三次請求可以這麼理解，相當於2個人進行對話，
甲乙兩個人路上遇見
第一次握手相當於甲向乙打個招呼，看乙是否能夠接收到甲打的招呼。這時甲進入等待狀態。
第二次握手相當於乙聽到了甲的招呼，進行迴應（相當於告訴甲乙可以接收到並能理解甲的招呼）並向甲打招呼看甲是否能接收到乙的招呼，這時乙進入等待狀態
第三次是甲接收到乙的迴應知道乙可以接收到甲的信息並能理解，並且迴應了乙的招呼，告訴乙這時候甲能接受乙的信息並能理解。這時候就能確定雙方都可以接收到對方的信息並能進行正常的對話。下一步就開始對話。也就是信息傳輸。
網絡的OSI7層模型
前面提到的三次握手發生在傳輸層，實際不是在這個OSI的7層模型內。
TCP和UDP
tcp 需要進行三次握手來確定連接的可靠性在進行傳輸
udp 不需要進行確定而直接進行傳輸
優缺點
TCP的優點：
可靠，穩定 TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開連接用來節約系統資源。
TCP的缺點：
慢，效率低，佔用系統資源高，易被攻擊 TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺設備上維護所有的傳輸連接，事實上，每個連接都會佔用系統的CPU、內存等硬件資源。 而且，因爲TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用。
UDP的優點：
快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的
UDP的缺點：
不可靠，不穩定 因爲UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。
基於上面的優缺點，那麼： 什麼時候應該使用TCP： 當對網絡通訊質量有要求的時候，比如：整個數據要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。 在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 ………… 什麼時候應該使用UDP： 當對網絡通訊質量要求不高的時候，要求網絡通訊速度能儘量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下： QQ語音 QQ視頻 TFTP ……
HTTP阻塞
HTTP1.1默認只能同時創建6條TCP連接，每條連接結束以後才能釋放出來給對另外一個資源的請求來使用。雖然和HTTP1.0相比，在性能上已有較大提升，但是並沒有本質的改變。以本項目爲例，如果當瞬間發起滿10個請求後，只有前6個請求能夠分配6個不同的HTTP連接進行處理，後續4個請求只有等待這6個請求有任何一個釋放HTTP連接資源以後，才能繼續。也就是說前6個請求中如果最少耗時都在1s，那麼後4個請求的最少Pending時間都在1s。
可以發現阻塞現象相當嚴重，而且每個HTTP請求會創建一個獨立的TCP連接進行處理，請求完成以後再關閉，再爲下一次請求創建一個新的HTTP連接，資源開銷極大。這裏keep-alive雖然開着的，但是server端沒有設置connection: true，所以暫沒法保持連接。
我們可以通過Network查看是否是一次連接，通過Connection ID來查看
