前言

在寫之前，先給這篇文章做一個明確定位，讀完這篇文章後，希望你能夠：

• 對於計算機網路有初步的認識和了解，瞭解一些經典專業術語，如三次握手、四次揮手、DNS解析的含義。
• 瞭解一些應用層協議，如傳統的HTTP、HTTPS協議，以及業界近幾年開始逐步普及的HTTP2、QUIC協議。
• 通過實際生產環境下的例子，瞭解網路優化在專案中的實際意義以及帶來的效果。

課前準備

為了能夠更好地理解這篇文章的內容，建議閱讀之前做以下幾個準備：

• 瞭解TCP/IP的基本概念，推薦去閱讀《TCP/IP協議詳解》中的第3章和第17章，這裡給大家一個連結，可以免費下載，傳送門。
• 其次希望在學習的過程中，為了能夠更好地看到效果，請下載抓包工具，這裡推薦的是
  Wireshark和Charles，大家可以下載後，結合文章內容並嘗試抓包，更容易理解整個網路轉發過程。

網路模型

在學習具體知識前，搞清楚它所在的知識體系和模型是非常重要的，對於網路知識亦是如此，目前公認的網路模型有兩種，一種是OSI七層模型，另一種則是TCP/IP五層模型，請看下圖：

可以看到，OSI七層模型和TCP/IP五層模型存在一個對應關係，並且傳輸層以下的完全一致(TCP模型中的網路介面層就是資料鏈路層和物理層的集合)，因此可以說將OSI模型中的會話層、表示層與應用層合併為TCP/IP模型中的應用層後，二者基本一致。

上述兩個網路模型都屬於通用網路模型，相對來說，TCP/IP模型更為普遍一些，所以我們也主要以TCP/IP模型為網路模型開展論述，這也是為什麼這節課的名字TCP/IP的由來。

那麼每一層都對應哪些協議呢？請看下圖：

可以看到，我們熟知的一些協議，IP協議位於網路層，TCP協議位於傳輸層，而HTTP協議則位於應用層，其餘還有比較熟悉的DNS協議，FTP協議等等，都有其所屬的層級。

我們可以通過Wireshark抓包驗證這一點，隨便抓取一個HTTP報文：

從上往下依次是Frame幀頭、以太幀頭、IP協議頭、TCP協議頭和HTTP協議頭，最後的一行則是本次請求的資料，其格式為JSON

三握四揮

所謂三握四揮是指三次握手和四次揮手，也就是TCP協議建立連線和斷開連線的過程，之所以叫做三次握手，是因為建立連線的雙方需要經過三次資料互動以後才能完成連線的建立，同樣的，四次揮手是指在斷開連線時需要四次資料互動，其互動過程圖如下：

舉個簡單的例子，兩個人小S和小C打電話，他們的三次握手建立連線過程就是：

小S：喂，是小C麼？ 小C：嗯嗯是的，你是小S麼？ 小S：是的是的，咱們開始愉快的聊天吧！

而四次揮手的過程則是：

小S：喂，小C，我有點累啦，今天要不就這樣吧 小C：好呀，你休息下，我再說兩句 小C：哎呀，我也好累呀，今天就到這裡吧 小S：好，那就到這吧，886

然後小S和小C就掛了電話，我們注意到，在四次揮手的過程中，小S先提出了斷開連線，但實際上他們的對話並沒有結束，後面小C確認這個訊息後，並沒有立馬斷開連線，而是繼續對話，這是因為TCP協議具備全雙工特性，簡單點說就是一個連線，存在小C——小S和小S到小C兩條線路，而小S提出並由小C確認關閉的只是小S——小C這條線路，因此小C還可以繼續向小S發訊息，直到小C也覺得要關閉連線並由小S確認後，兩人的所有連線才徹底關閉。

那麼你肯定會問啦，為什麼TCP要這麼設計呢，這是因為TCP是一個全雙工的協議，全雙工(Full Duplex)是通訊傳輸的一個術語。通訊允許資料在兩個方向上同時傳輸，我們在上面的例子也提到了在一次TCP互動中，需要維持兩條線路，因此無論是在建立和斷開的時候，都要確保兩條線路的狀態正確。

上面的闡述還是建立在理論階段，為了能更好地鞏固知識，我們利用Wireshark在實際生產環境下抓包看下:

客戶端IP為：10.2.203.93 服務端IP為：10.108.21.2

客戶端和服務端建立連線時的抓包情況：

可以看到由客戶端首先發SYN報文，服務端收到並回應SYN ACK報文，客戶端最後再回一個ACK報文，連線就算建立完畢了。

再來看看斷開連線時的情況：

和建立連線時不同，斷開連線的發起者是服務端，可以看到服務端傳送FIN報文，然後客戶端再發ACK報文，此時服務端便不再向客戶端傳輸資料，而客戶端在完成資料傳輸後，也傳送FIN報文到服務端，在收到服務端的Last ACK報文後正式斷開連線。

關於TCP連線建立和斷開時的三握四揮就先講到這裡，再附上一張TCP的狀態遷移圖，對了解整個TCP協議有很大的幫助：

DNS解析

DNS（Domain Name System，域名系統），因特網上作為域名和IP地址相互對映的一個分散式資料庫，能夠使使用者更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。

這是來源於百度百科的一段描述，簡單點說DNS解析做的工作就是，讓我們把能記住的，比較好記的域名轉換為IP地址的一個系統，下面我們就藉助Wireshark來看看它到底是怎麼工作的。

我們在瀏覽器中輸入www.baidu.com時，會向伺服器傳送DNS請求報文，當伺服器端處理完這個請求以後，就會發送DNS響應報文，其中就包含我們關心的IP地址，可以看到我們抓到兩個報文，前者我們稱之為DNS請求報文，後者稱之為DNS響應報文，注意我們的篩選條件，通過UDP埠來過濾更加方便：

先來看DNS請求報文：

可以看到DNS的傳輸層協議是UDP，而不是TCP，並且其埠號為53。緊接著的是Transaction ID(2位元組)，這個ID可以作為DNS請求的一個唯一ID來使用，也就是說對於一個請求和應答報文，這個ID是相同的，因此也可以藉助這個ID來查詢請求報文相對應的應答報文。

Flags欄位長度也是2位元組，可以看到，16bit被分成了以下幾部分，依次為：

• Response(1位元)，該值為0則說明是一個DNS請求報文，為1則說明是DNS響應報文
• opcode（4位元）：定義查詢或響應的型別（若為0則表示是標準的，若為1則是反向的，若為2則是伺服器狀態請求）。
• AA（1位元）：授權回答的標誌位。該位在響應報文中有效，1表示名字伺服器是許可權伺服器
• TC（1位元）：截斷標誌位。1表示響應已超過512位元組並已被截斷
• RD（1位元）：該位為1表示客戶端希望得到遞歸回答
• RA（1位元）：只能在響應報文中置為1，表示可以得到遞迴響應。
• zero（3位元）：不說也知道都是0了，保留欄位。
• rcode（4位元）：返回碼，表示響應的差錯狀態，通常為0和3，各取值含義如下： 0 無差錯 1 格式差錯 2 問題在域名伺服器上 3 域參照問題 4 查詢型別不支援 5 在管理上被禁止 6 -- 15 保留

緊接著Flags下面的幾個欄位分別是：queries、answers、authr、addrr，其相應的中文含義為問題數、資源記錄數、授權資源記錄數和額外資源記錄數，它們的長度都是2位元組，一般來說queries為1，其餘的欄位值為0。

接下來就是報文的正文部分，這裡包括要查詢的域名，查詢型別和相應的查詢類，這裡的域名的格式比較特別，在這裡的域名是www.baidu.com，而標記為藍色的部分則是報文中的表示，可以看到，03是代表3個位元組，而緊跟著3個77，如果轉換為ASIC碼的話，就是0x77，因此對於www.baidu.com，首先是以“.”為分隔符，分成3個部分後，用相應的段長度再加上域名段的ASIC組成一個段，這樣就構成了一個完整的域名。

後續的兩個欄位分別是Type和Class，在這裡兩個欄位都為1，其中Type為A則代表此次請求型別是通過域名獲取IP地址，也是最為常見的一種DNS請求形式。而Class欄位為1，則代表這裡查詢的資料是internet資料，也是最為常見的一種形式。

介紹完了請求報文，接下來再看一下響應報文：

響應報文和應答報文相同的部分就不再贅述了，可以看到Flags中的Response值為1，就說明這是一個響應報文，同時Transaction ID也和請求報文中的ID一致，說明這就是上面那個請求報文所對應的響應報文。

請求報文正文中最主要的部分就是Answers欄位，這裡麵包括了我們想要的IP地址，但是我們也注意到，對於www.baidu.com這一個域名，響應欄位居然有3條，那麼究竟以哪一條為準呢？我們一條條來看。

首先是第1條Answer，這裡的Type型別為CNAME，這裡的CNAME表示這個迴應是請求報文中查詢的域名的一個別名，也就是此處返回的將是www.baidu.com的一個別名，也就是www.a.shifen.com，緊接著後面兩個Answer，Type型別為A，代表返回值將是一個IPV4地址，其他的比較常見的Type型別還有AAAA——IPV6地址，PTR——IP地址轉換為域名，NS——名字伺服器。

可以看到，對於同一個域名，可以返回多個IP地址，在上面的響應報文中，返回了2個IP地址，分別是61.135.169.125和61.135.169.121，這就是我們最終想要的結果，為了防止其中某個IP地址出現異常，因此通常對於一個域名，都會有兩個甚至以上的IP地址與其對應，這樣便可以起到一個主備容災效果，當其中一個IP地址無法連線時，還可以切換到另一個IP進行訪問。在瀏覽器中輸入 或61.135.169.121，也可以正常訪問頁面：

對於使用chrome瀏覽器的同學，可以輸入chrome://net-internals/#dns 來檢視瀏覽器DNS解析列表：

在這裡可以看到你訪問過的網站，以及相應的解析記錄，這裡還有一欄TTL，代表域名解析結果的生存時間，簡單點說就是當我們解析完畢一個域名以後，會將其記錄快取起來，在TTL時間之內的訪問，我們都直接從快取中獲取，而不再去進行DNS解析，這樣帶來的好處就是減少DNS解析時間，加快網頁訪問速度，但同時帶來的影響就是如果TTL值過大，那麼如果伺服器的域名解析發生變化，也需要很長時間才能在客戶端生效，所以TTL要根據實際生產環境需求來調整

關於DNS的解析暫時將到這裡，建議大家參照上面的抓包過程去實踐一把，相信可以對整個過程有更深入的理解！

應用層協議

介紹完TCP協議和DNS協議之後，我們就要開始介紹處於TCP/IP模型中最上層的應用層協議了。應用層協議也是和使用者互動最密切的，因此對使用者感知影響也是最直接的，下面就以此介紹幾種比較常見的應用層協議。

HTTP

HTTP（HyperText Transport Protocol）是超文字傳輸協議的縮寫，它用於傳送WWW方式的資料，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議採用了請求/響應模型。客戶端向伺服器傳送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶資訊和內容的類似於MIME的訊息結構。伺服器以一個狀態行作為響應，響應的內容包括訊息協議的版本，成功或者錯誤編碼加上包含伺服器資訊、實體元資訊以及可能的實體內容。

上面是關於HTTP的權威描述，HTTP可以說是整個網際網路當中最普遍也是最重要的一個協議了，包括你現在能看到我寫的這篇文章，也是利用HTTP進行資料傳輸的，那麼糾結是如何進行工作的呢？這次我們藉助另外一款抓包神器——Charles來進行抓包分析。

當我們利用瀏覽器訪問http://www.csdn.net/時，瀏覽器會在我們輸入地址並敲下回車後在頁面顯示：

這是一個在平常不過的操作了，此時我們用Charles進行抓包，得到下面的結果：

上面是整個完整的互動，實際上包含了兩部分，首先是HTTP request請求，也就是上面中上半部分，可以看到，在request請求中幾個關鍵點是GET、HTTP/1.1、Host、User-Agent、Accept以及Cookie，這些關鍵字構成了一個request請求的報文頭，代表客戶端想通過本次請求得到服務端的哪些資料，服務端在收到request後，作出的迴應便是HTTP response報文，也就是上圖中下半部分，因為我們訪問的是csdn的主頁，並且在Accept裡也指定了html是一種請求資料，所以response報文返回的資料裡便包含了HTML資料，當然，response報文也有其它組成部分，如下圖所示：

這裡面就包括了服務端對於本次請求的迴應資料，其中最關鍵的便是200 OK這個欄位，這是響應狀態碼，最常見的就是200，也就是表明請求OK，還有比較常見的就是404和502，前者代表客戶端非法請求，後者代表服務端響應失敗，比如說我們輸入http://www.csdn.net/test123時，頁面就會提示：

HTTPS

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 它是一個URI scheme（抽象識別符號體系），句法類同http:體系。用於安全的HTTP資料傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的預設埠及一個加密/身份驗證層（在HTTP與TCP之間）

從上面的闡述中我們可以得到HTTPS = HTTP + TLS這樣一個簡單的結論，也就試試哦HTTPS是比HTTP更加安全的協議，並且目前已經有不少網站開始支援HTTPS了。比如說百度：

可以看到，使用的是HTTPS協議，同時瀏覽器會提示安全，我們再看另外幾個例子：

上圖是工行的登陸介面，可以看到也使用了HTTPS協議，如果使用的仍然是HTTP協議，瀏覽器便不會有安全字樣的提示：

哈，建行主頁竟然還沒有使用HTTPS協議，那是不是就說明建行不安全了呢？

其實不然，我們點選登陸按鈕：

可以看到使用的協議還是HTTPS協議，這說明我們的登陸操作依然是有安全保障的，大大降低了賬號資訊被盜用的可能

HTTP2

HTTP/2（超文字傳輸協議第2版，最初命名為HTTP 2.0），簡稱為h2（基於TLS/1.2或以上版本的加密連線）或h2c（非加密連線）[1]，是HTTP協議的的第二個主要版本，使用於全球資訊網。

HTTP/2是HTTP協議自1999年HTTP 1.1釋出後的首個更新，主要基於SPDY協議。它由網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。[2]該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論[3]，於2015年2月17日被批准。[4]

HTTP/2標準於2015年5月以RFC 7540正式發表。[5]HTTP/2的標準化工作由Chrome、Opera、Firefox[6]、Internet Explorer 11、Safari、Amazon Silk及Edge等瀏覽器提供支援。[7]

多數主流瀏覽器已經在2015年底支援了該協議。[8]此外，根據W3Techs的資料，在2017年5月，在排名前一千萬的網站中，有13.7%支援了HTTP/2。

可以看到HTTP2協議已經在網際網路佔有一席之地，那麼它究竟比HTTP強在哪裡呢？總結了一下，大致有以下幾點。相比 HTTP/1.x，HTTP/2 在底層傳輸做了很大的改動和優化：

• 二進位制傳輸：HTTP2 採用二進位制格式傳輸資料，而非 HTTP 的文字格式。二進位制格式在協議的解析和優化擴充套件上帶來更多的優勢和可能
• 多路複用：HTTP2 做到了併發請求。同時，流還支援優先順序和流量控制。
• 服務端push：服務端能夠更快的把資源推送給客戶端
• 首部壓縮：首部壓縮使得整個HTTP2資料包小了很多，傳輸也就會更快

QUIC

QUIC是一種新的傳輸 方式，與TCP相比可以減少延遲。 表面上，QUIC與在UDP上實現的TCP + TLS + HTTP / 2非常相似。由於TCP是在作業系統核心和中介軟體韌體中實現的，所以對TCP進行重大改變幾乎是不可能的。但是，由於QUIC是建立在UDP之上的，所以沒有這樣的限制。

QUIC相比於上述介紹的HTTP、HTTPS和HTTP2協議最大的不同就在於，其傳輸層採用的是UDP協議而不是TCP協議，因此其具備的特性有以下幾點：

• 0-RTT 建聯(首次建聯除外)
• 類似TCP的可靠傳輸
• 類似TLS的加密傳輸，支援完美前向安全
• 使用者空間的擁塞控制，最新的BBR演算法
• 支援h2的基於流的多路複用， 但沒有TCP的HOL問題
• 前向糾錯FEC
• 類似MPTCP的Connection migration

那在實際環境中，如何知道哪些訪問使用了HTTP2、哪些訪問使用了QUIC協議呢？

這裡就要提到chrome的一個外掛——HTTP/2 and SPDY indicator，當下載該外掛併成功訪問後，我們就可以看到瀏覽器位址列右側會多一個⚡️標誌：

訪問百度時，這個⚡️標誌是白色的，當我們訪問YouTube時：

會發現標誌變為藍色，滑鼠移到該標誌時，提示HTTP2已經使能，這說明在YouTube上面已經開始使用HTTP2協議了，在chrome瀏覽器中輸入chrome://net-internals/#http2就可以看到具體哪些網站使用了HTTP2和QUIC：

總結

本期的內容到這裡也就告一段落了，希望讀完本篇文章後，可以讓你對網路有更深入的瞭解，並且能夠在實際生活中，去留意這些知識，尤其是抓包分析網路問題，可以說是學習網路知識和分析網路問題的最大利器。

後續我會在這一期的基礎上，再推出一期網路知識進階篇，敬請期待！