作者：楊志曉
一、相關協議類概念：
a.TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協議屬於傳輸層協議。 其中TCP提供IP環境下的數據可靠傳輸，它提供的服務包括數據流傳送、可靠性、有效流控、全雙工操作和多路複用。 通過面向連接、端到端和可靠的數據包發送。
b.SPDY協議是Google提出的基於傳輸控制協議(TCP)的應用層協議，通過壓縮、多路複用和優先級來縮短加載時間。 該協議是一種更加快速的內容傳輸協議。
c.QUIC（Quick UDP Internet Connections)基於UDP的傳輸層協議，提供像TCP一樣的可靠性。在提高web應用性能上，可以選擇在應用層使用HTTP2.0實現多路傳輸，在物理層使用CDN解決網絡擁塞和最後一公里問題。在傳輸層，目前主要使用TCP，但由於TCP本身的問題（一個充滿補丁的醜陋的協議），成爲了限制web應用性能的一個瓶頸。
二、wireshark抓包解析報文：
a.mac網卡（多路訪問控制協議(multiple access control protocol)
1_1.png
b.Ip報文解析
1_2.png
ip報頭長度計算：
1_3.png
5*4 =20
c.tcp報文解析
1_4.png
三、http1.0基本原理
a.通過一個普通html分析：
1_5.png
1_6.png
b.如上圖分析：
綠色爲：Waiting (TTFB)：TTFB (Time To First Byte)，是最初的網絡請求被髮起到從服務器接收到第一個字節這段時間，它包含了 TCP連接時間，發送HTTP請求時間和獲得響應消息第一個字節的時間。
藍色爲：Content Download
c.等待時間影響因素：從發送請求到收到響應之間的空隙，會受到線路、服務器距離等因素的影響。
d.瀏覽器同域名發出6個請求，建立幾個tcp？1 or 6？
帶着上面的疑問我們對demo進行抓包
抓包分析：
1_7.png
分析後發現：三張圖片+html總共四個請求
index.html+section4new.png端口是55653
section01.png+section2.jpg端口是55654
爲什麼是這樣呢：
查看tcp抓包：
1_8.png
通過抓包看到 ：
第一個http請求 index.html請求端口是：55653
第二個http請求 section4new.png請求端口是：55653
第三個http請求 section01.png請求端口是：55654
第四個http請求section2.jpg請求端口是：55654
同時也看到tcp開始建立時同時發出了兩條請求
1_9.png
默認谷歌瀏覽器發起了兩條tcp請求（瀏覽器不同,可能是請求個數少）
同樣抓包中看到了tcp的三次握手
1_10.png
http2.0 ：
a.瀏覽器加載如下：
1_11.png
b.討論點：http1.1請求會是按照如下圖1還是圖2？
1_12.png
討論結論：
http1.1 without pipelining: 通過tcp連接上一個請求相應完後，下一個請求才能發出
http1.1 with pipelining: 通過tcp連接，上一個請求發出，下一個請求不需要等待，但是返回是同一順序。
http2.0在TCP連接上傳輸的是幀，客戶端會將要傳輸的數據拆分爲不同的幀，並標記對應的數據流ID，異步發出，服務端接收到幀集合根據數據流ID拼湊起來即爲客戶端發送來的數據。同理，服務端也是將數據拆分爲不同幀返回。
附瀏覽器同域名請求的最大併發限制：
1_13.png
附課堂板書：
1_14