TCP/IP 和 HTTP不了解？看完這篇文章，網(wǎng)絡(luò)知識就全懂了

imnobody2001 2018-02-14

展開全文

本文來自作者宋璐在 GitChat 上分享「如何快速入門網(wǎng)絡(luò)基礎(chǔ)知識（TCP/IP 和 HTTP）」，「閱讀原文」查看交流實錄

「文末高能」

編輯 | 洛肯

前言

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

對于計算機網(wǎng)絡(luò)有初步的認識和了解，了解一些經(jīng)典專業(yè)術(shù)語，如三次握手、四次揮手、DNS解析的含義。
了解一些應(yīng)用層協(xié)議，如傳統(tǒng)的HTTP、HTTPS協(xié)議，以及業(yè)界近幾年開始逐步普及的HTTP2、QUIC協(xié)議。
通過實際生產(chǎn)環(huán)境下的例子，了解網(wǎng)絡(luò)優(yōu)化在項目中的實際意義以及帶來的效果。

課前準備

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

了解TCP/IP的基本概念，推薦去閱讀《TCP/IP協(xié)議詳解》中的第3章和第17章，這里給大家一個鏈接，可以免費下載，傳送門(http://download.csdn.net/download/u012155923/10046395)。
其次希望在學習的過程中，為了能夠更好地看到效果，請下載抓包工具，這里推薦的是Wireshark(https://www./download.html)和Charles(https://www./download/)，大家可以下載后，結(jié)合文章內(nèi)容并嘗試抓包，更容易理解整個網(wǎng)絡(luò)轉(zhuǎn)發(fā)過程。

網(wǎng)絡(luò)模型

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

可以看到，OSI七層模型和TCP/IP五層模型存在一個對應(yīng)關(guān)系，并且傳輸層以下的完全一致(TCP模型中的網(wǎng)絡(luò)接口層就是數(shù)據(jù)鏈路層和物理層的集合)，因此可以說將OSI模型中的會話層、表示層與應(yīng)用層合并為TCP/IP模型中的應(yīng)用層后，二者基本一致。

上述兩個網(wǎng)絡(luò)模型都屬于通用網(wǎng)絡(luò)模型，相對來說，TCP/IP模型更為普遍一些，所以我們也主要以TCP/IP模型為網(wǎng)絡(luò)模型開展論述，這也是為什么這節(jié)課的名字TCP/IP的由來。

那么每一層都對應(yīng)哪些協(xié)議呢？請看下圖：

可以看到，我們熟知的一些協(xié)議，IP協(xié)議位于網(wǎng)絡(luò)層，TCP協(xié)議位于傳輸層，而HTTP協(xié)議則位于應(yīng)用層，其余還有比較熟悉的DNS協(xié)議，F(xiàn)TP協(xié)議等等，都有其所屬的層級。

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

從上往下依次是Frame幀頭、以太幀頭、IP協(xié)議頭、TCP協(xié)議頭和HTTP協(xié)議頭，最后的一行則是本次請求的數(shù)據(jù)，其格式為JSON

三握四揮

所謂三握四揮是指三次握手和四次揮手，也就是TCP協(xié)議建立連接和斷開連接的過程，之所以叫做三次握手，是因為建立連接的雙方需要經(jīng)過三次數(shù)據(jù)交互以后才能完成連接的建立，同樣的，四次揮手是指在斷開連接時需要四次數(shù)據(jù)交互，其交互過程圖如下：

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

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

而四次揮手的過程則是：

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

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

那么你肯定會問啦，為什么TCP要這么設(shè)計呢，這是因為TCP是一個全雙工的協(xié)議，全雙工(Full Duplex)是通訊傳輸?shù)囊粋€術(shù)語。通信允許數(shù)據(jù)在兩個方向上同時傳輸，我們在上面的例子也提到了在一次TCP交互中，需要維持兩條線路，因此無論是在建立和斷開的時候，都要確保兩條線路的狀態(tài)正確。

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

客戶端IP為：10.2.203.93
服務(wù)端IP為：10.108.21.2

客戶端和服務(wù)端建立連接時的抓包情況：

可以看到由客戶端首先發(fā)SYN報文，服務(wù)端收到并回應(yīng)SYN ACK報文，客戶端最后再回一個ACK報文，連接就算建立完畢了。

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

和建立連接時不同，斷開連接的發(fā)起者是服務(wù)端，可以看到服務(wù)端發(fā)送FIN報文，然后客戶端再發(fā)ACK報文，此時服務(wù)端便不再向客戶端傳輸數(shù)據(jù)，而客戶端在完成數(shù)據(jù)傳輸后，也發(fā)送FIN報文到服務(wù)端，在收到服務(wù)端的Last ACK報文后正式斷開連接。

關(guān)于TCP連接建立和斷開時的三握四揮就先講到這里，再附上一張TCP的狀態(tài)遷移圖，對了解整個TCP協(xié)議有很大的幫助：

DNS解析

DNS（Domain Name System，域名系統(tǒng)），因特網(wǎng)上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數(shù)串。通過主機名，最終得到該主機名對應(yīng)的IP地址的過程叫做域名解析（或主機名解析）。

這是來源于百度百科的一段描述，簡單點說DNS解析做的工作就是，讓我們把能記住的，比較好記的域名轉(zhuǎn)換為IP地址的一個系統(tǒng)，下面我們就借助Wireshark來看看它到底是怎么工作的。

我們在瀏覽器中輸入www.baidu.com時，會向服務(wù)器發(fā)送DNS請求報文，當服務(wù)器端處理完這個請求以后，就會發(fā)送DNS響應(yīng)報文，其中就包含我們關(guān)心的IP地址，可以看到我們抓到兩個報文，前者我們稱之為DNS請求報文，后者稱之為DNS響應(yīng)報文，注意我們的篩選條件，通過UDP端口來過濾更加方便：

先來看DNS請求報文：

可以看到DNS的傳輸層協(xié)議是UDP，而不是TCP，并且其端口號為53。緊接著的是Transaction ID(2字節(jié))，這個ID可以作為DNS請求的一個唯一ID來使用，也就是說對于一個請求和應(yīng)答報文，這個ID是相同的，因此也可以借助這個ID來查找請求報文相對應(yīng)的應(yīng)答報文。

Flags字段長度也是2字節(jié)，可以看到，16bit被分成了以下幾部分，依次為：

Response(1比特)，該值為0則說明是一個DNS請求報文，為1則說明是DNS響應(yīng)報文
opcode（4比特）：定義查詢或響應(yīng)的類型（若為0則表示是標準的，若為1則是反向的，若為2則是服務(wù)器狀態(tài)請求）。
AA（1比特）：授權(quán)回答的標志位。該位在響應(yīng)報文中有效，1表示名字服務(wù)器是權(quán)限服務(wù)器
TC（1比特）：截斷標志位。1表示響應(yīng)已超過512字節(jié)并已被截斷
RD（1比特）：該位為1表示客戶端希望得到遞歸回答
RA（1比特）：只能在響應(yīng)報文中置為1，表示可以得到遞歸響應(yīng)。
zero（3比特）：不說也知道都是0了，保留字段。
rcode（4比特）：返回碼，表示響應(yīng)的差錯狀態(tài)，通常為0和3，各取值含義如下：
0 無差錯
1 格式差錯
2 問題在域名服務(wù)器上
3 域參照問題
4 查詢類型不支持
5 在管理上被禁止
6 — 15 保留

緊接著Flags下面的幾個字段分別是：queries、answers、auth_r、add_rr，其相應(yīng)的中文含義為問題數(shù)、資源記錄數(shù)、授權(quán)資源記錄數(shù)和額外資源記錄數(shù)，它們的長度都是2字節(jié)，一般來說queries為1，其余的字段值為0。

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

后續(xù)的兩個字段分別是Type和Class，在這里兩個字段都為1，其中Type為A則代表此次請求類型是通過域名獲取IP地址，也是最為常見的一種DNS請求形式。而Class字段為1，則代表這里查詢的數(shù)據(jù)是internet數(shù)據(jù)，也是最為常見的一種形式。

介紹完了請求報文，接下來再看一下響應(yīng)報文：

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

請求報文正文中最主要的部分就是Answers字段，這里面包括了我們想要的IP地址，但是我們也注意到，對于www.baidu.com這一個域名，響應(yīng)字段居然有3條，那么究竟以哪一條為準呢？我們一條條來看。

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

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

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

在這里可以看到你訪問過的網(wǎng)站，以及相應(yīng)的解析記錄，這里還有一欄TTL，代表域名解析結(jié)果的生存時間，簡單點說就是當我們解析完畢一個域名以后，會將其記錄緩存起來，在TTL時間之內(nèi)的訪問，我們都直接從緩存中獲取，而不再去進行DNS解析，這樣帶來的好處就是減少DNS解析時間，加快網(wǎng)頁訪問速度，但同時帶來的影響就是如果TTL值過大，那么如果服務(wù)器的域名解析發(fā)生變化，也需要很長時間才能在客戶端生效，所以TTL要根據(jù)實際生產(chǎn)環(huán)境需求來調(diào)整

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

應(yīng)用層協(xié)議

介紹完TCP協(xié)議和DNS協(xié)議之后，我們就要開始介紹處于TCP/IP模型中最上層的應(yīng)用層協(xié)議了。應(yīng)用層協(xié)議也是和用戶交互最密切的，因此對用戶感知影響也是最直接的，下面就以此介紹幾種比較常見的應(yīng)用層協(xié)議。

HTTP

HTTP（HyperText Transport Protocol）是超文本傳輸協(xié)議的縮寫，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細內(nèi)容請參考RFC2616。HTTP協(xié)議采用了請求/響應(yīng)模型?？蛻舳讼蚍?wù)器發(fā)送一個請求，請求頭包含請求的方法、URL、協(xié)議版本、以及包含請求修飾符、客戶信息和內(nèi)容的類似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯誤編碼加上包含服務(wù)器信息、實體元信息以及可能的實體內(nèi)容。

上面是關(guān)于HTTP的權(quán)威描述，HTTP可以說是整個互聯(lián)網(wǎng)當中最普遍也是最重要的一個協(xié)議了，包括你現(xiàn)在能看到我寫的這篇文章，也是利用HTTP進行數(shù)據(jù)傳輸?shù)?，那么糾結(jié)是如何進行工作的呢？這次我們借助另外一款抓包神器——Charles來進行抓包分析。

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

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

上面是整個完整的交互，實際上包含了兩部分，首先是HTTP request請求，也就是上面中上半部分，可以看到，在request請求中幾個關(guān)鍵點是GET、HTTP/1.1、Host、User-Agent、Accept以及Cookie，這些關(guān)鍵字構(gòu)成了一個request請求的報文頭，代表客戶端想通過本次請求得到服務(wù)端的哪些數(shù)據(jù)，服務(wù)端在收到request后，作出的回應(yīng)便是HTTP response報文，也就是上圖中下半部分，因為我們訪問的是csdn的主頁，并且在Accept里也指定了html是一種請求數(shù)據(jù)，所以response報文返回的數(shù)據(jù)里便包含了HTML數(shù)據(jù)，當然，response報文也有其它組成部分，如下圖所示：

這里面就包括了服務(wù)端對于本次請求的回應(yīng)數(shù)據(jù)，其中最關(guān)鍵的便是200 OK這個字段，這是響應(yīng)狀態(tài)碼，最常見的就是200，也就是表明請求OK，還有比較常見的就是404和502，前者代表客戶端非法請求，后者代表服務(wù)端響應(yīng)失敗，比如說我們輸入http://www.csdn.net/test123時，頁面就會提示：

HTTPS

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL。它是一個URI scheme（抽象標識符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）

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

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

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

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

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

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

HTTP2

HTTP/2（超文本傳輸協(xié)議第2版，最初命名為HTTP 2.0），簡稱為h2（基于TLS/1.2或以上版本的加密連接）或h2c（非加密連接）[1]，是HTTP協(xié)議的的第二個主要版本，使用于萬維網(wǎng)。
HTTP/2是HTTP協(xié)議自1999年HTTP 1.1發(fā)布后的首個更新，主要基于SPDY協(xié)議。它由互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發(fā)。[2]該組織于2014年12月將HTTP/2標準提議遞交至IESG進行討論[3]，于2015年2月17日被批準。[4]

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

多數(shù)主流瀏覽器已經(jīng)在2015年底支持了該協(xié)議。[8]此外，根據(jù)W3Techs的數(shù)據(jù)，在2017年5月，在排名前一千萬的網(wǎng)站中，有13.7%支持了HTTP/2。

可以看到HTTP2協(xié)議已經(jīng)在互聯(lián)網(wǎng)占有一席之地，那么它究竟比HTTP強在哪里呢？總結(jié)了一下，大致有以下幾點。相比 HTTP/1.x，HTTP/2 在底層傳輸做了很大的改動和優(yōu)化：

二進制傳輸：HTTP2 采用二進制格式傳輸數(shù)據(jù)，而非 HTTP 的文本格式。二進制格式在協(xié)議的解析和優(yōu)化擴展上帶來更多的優(yōu)勢和可能
多路復(fù)用：HTTP2 做到了并發(fā)請求。同時，流還支持優(yōu)先級和流量控制。
服務(wù)端push：服務(wù)端能夠更快的把資源推送給客戶端
首部壓縮：首部壓縮使得整個HTTP2數(shù)據(jù)包小了很多，傳輸也就會更快

QUIC

QUIC是一種新的傳輸方式，與TCP相比可以減少延遲。表面上，QUIC與在UDP上實現(xiàn)的TCP + TLS + HTTP / 2非常相似。由于TCP是在操作系統(tǒng)內(nèi)核和中間件固件中實現(xiàn)的，所以對TCP進行重大改變幾乎是不可能的。但是，由于QUIC是建立在UDP之上的，所以沒有這樣的限制。

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

0-RTT 建聯(lián)(首次建聯(lián)除外)
類似TCP的可靠傳輸
類似TLS的加密傳輸，支持完美前向安全
用戶空間的擁塞控制，最新的BBR算法
支持h2的基于流的多路復(fù)用，但沒有TCP的HOL問題
前向糾錯FEC
類似MPTCP的Connection migration

那在實際環(huán)境中，如何知道哪些訪問使用了HTTP2、哪些訪問使用了QUIC協(xié)議呢？

這里就要提到chrome的一個插件——HTTP/2 and SPDY indicator，當下載該插件并成功訪問后，我們就可以看到瀏覽器地址欄右側(cè)會多一個??標志：

訪問百度時，這個??標志是白色的，當我們訪問YouTube時：

會發(fā)現(xiàn)標志變?yōu)樗{色，鼠標移到該標志時，提示HTTP2已經(jīng)使能，這說明在YouTube上面已經(jīng)開始使用HTTP2協(xié)議了，在chrome瀏覽器中輸入chrome://net-internals/#http2就可以看到具體哪些網(wǎng)站使用了HTTP2和QUIC：