終於懂了TCP協議爲什麼是可靠的，計算機基礎（六）之運輸層

大家好，我是後來，我會分享我在學習和工作中遇到的點滴，希望有機會我的某篇文章能夠對你有所幫助，所有的文章都會在公衆號首發，歡迎大家關注我的公衆號" 後來X大數據 "，感謝你的支持與認可。

不知不覺我的計算機網絡專欄已經寫了5篇了，今天是第6篇，到運輸層了。其中第4篇警察叔叔順着網線是怎麼找到你的？計算機網絡（四）之網絡層未完待續閱讀量最高。

通過學習計算機網絡，開始逐漸理解了兩臺主機之間是如何進行通信的，但是還有一個問題困擾着我，我們爲啥非要下載一個微信才能一起聊天，難道不能你用微信，我用QQ麼，也就是微信上發的消息爲啥不會出現在QQ上呢？

帶着這個疑問我們來看今天的內容。來劃重點了：

1. 通信實質上是進程之間的通信
2. 端口和套接字的意義
3. 用戶數據報協議UDP
4. 傳輸控制協議TCP
5. 三次握手
6. 四次揮手
7. 可靠傳輸是如何實現的？

還是老樣子，這張圖再來看一遍，現在應該記住了吧，畢竟在我的文章裏已經出現了5次了。

1、運輸層是幹啥的？

從上圖能看到，運輸層是向它上面的應用層提供通信服務的。

拋開這些複雜的邏輯，我們回到我寫文章最開始的問題：我發的文章怎麼到你手機上了？
爲了簡單討論原理，我們把問題同理爲：我給你發的微信消息爲什麼只會出現在你的微信上？而不是QQ上

我們之前通過網絡層的IP地址與MAC地址，已經把消息發送到了主機裏，那麼大家知道我們的電腦同時執行着多個進程，比如在座的各位，平時是不是一邊聊微信，一邊看瀏覽器。

重點：通信的真正的端點不是主機，而是主機中的進程
所以，消息到了網絡層，再發到那個進程的這件事已經不歸網絡層管了，而是歸運輸層管。

1.1 那麼運輸層咋管呢？——端口號

那麼消息已經到了主機的網絡層，

1. 運輸層首先得分清楚哪條消息是發給哪個進程的吧?
   這個時候就需要一個標識符來進程區分，而且這個標識符必須是全世界統一，不然每個電腦廠家都有自己的一套，那對於用戶來說，就太不方便了，所以就在運輸層使用協議端口號，簡稱爲端口（port）,爲端口(port），也就是說，雖然通信的終點是應用進程，但只要把所傳送的報文交到目的主機的某個合適的目的端口，剩下的工作(即最後交付目的進程)就由TCP或UDP來完成。
   
   注意，這個端口是一個虛擬的端口號，0-65534，而不是指的電腦插網線的那個真實存在的端口。
   重點：通信的真正的端點不是主機，而是主機中的進程，使用端口號來標識進程

2. 其次，運輸層還要對收到的報文進程差錯檢測：
   也就是看又沒有異常，我們之前提到網絡層是不可靠的，那麼下面這幾層都不咋負責，運輸層得擔起責任啊，所以運輸層根據應用程序的不同需求，有兩種不同的運輸協議，那就是今天的重點：面向連接的TCP協議和無連接的UDP協議。
   這個協議有啥好處，它讓你覺得，你在使用微信聊天時，感受是：你的微信在和對方的微信聊天，直接屏蔽了底層的細節，好像是兩個運輸層直接通信一樣。

綜上所述：

1. IP協議雖然能把分組送到目的主機，但是這個分組還停留在主機的網絡層而沒有交付主機中的應用進程。
2. 從運輸層的角度看，真正進行通信的實體是在主機中的進程，是這臺主機中的一個進程和另一臺主機中的一個進程在交換數據(即通信)。 在一臺主機中經常有多個應用進程同時分別和另一臺主機中的多個應用進程通信。

看到這裏，大家發現，運輸層會對收到的消息進程分端口交付，這叫分用；對需要發送出去的消息會打包在一起發給網絡層，這叫複用；這個過程像什麼？像不像一個快遞網點？所以運輸層的特點也總結出來了：分用與複用！

1.2 端口的再瞭解

其實關於端口，對程序員來說，再熟悉不過了。TCP/IP體系協議的運輸層用16位的端口號來標誌一個端口，也就是說只有65535個端口，這對於一個計算機來說是足夠使用的。同時，這個端口只具有本地意義；在不同的計算機中，相同的端口號是沒有關聯的。

所以說，在互聯網裏進行通信，要知道對方的IP地址，MAC地址，還有端口號，纔行，這可以稱爲是通信3劍客。
端口號分爲2大類：

1. 服務器端使用的端口號
   1 熟知端口號 ：0~1023
   
   2 登記端口號：1024~49151
2. 客戶端使用的端口號：49152~65535

那麼怎麼表示一個TCP連接呢？
每一條TCP連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定。 即:
套接字 socket = {IP地址 ： 端口號}
TCP 連接 :: =(socket$_1$, socket$_2$)=((IP$_1$: port$_1$),(IP2$_2$: port$_2$)
套接字是抽象的，只是爲了表示TCP連接而存在。

在講下面的協議前，大家一定要知道，TCP是全雙工的通信，就是說A可以給B發消息，B同時也可以給A發消息。我們在下面的舉例中，爲了簡便只考慮時單向。

先把題目中的問題解答一下：微信和QQ屬於2個不同的進程，所以在一臺主機中進程之間的端口號不一樣，所以當微信發送的消息通過網絡層到達目的主機後，通過運輸層對端口的判斷，會把對應的消息會交付給目的主機中負責微信的進程。而不會選擇QQ，所以這個問題的關鍵還是端口。

但是隻知道個端口並不能說你瞭解運輸層，因爲TCP協議纔是運輸層的核心。來跟着我的思路一起了解一下運輸層吧。

2、用戶數據報協議UDP

這麼說吧，UDP協議大概意思是，我給你傳數據，等於我去你家串門，我不需要知道你方便不方便以及在不在家，我直接去了，去了之後能進去就進去，進不去就算了。所以UDP是不可靠傳輸

那麼TCP協議就不一樣了，我給你傳數據，必須要確保你能接收，也就是要通過試探的問一下，你在不在，通過後面講的３次握手方式，先建立連接，然後才正兒八經的發數據。最後走的時候，還要通過４次揮手的方式離場。所以TCP是可靠傳輸。

我們在這裏有個大概印象後再來看UDP協議的特點。着重說一下第3點和第4點

1. UDP是無連接的
2. UDP不保證可靠交付
3. UDP面向報文
   發送方： UDP對應用層交下來的報文，在添加首部後就向下交付IP層。既不合並，也不拆分
   接收方： UDP對IP層交上來的UDP用戶數據報，在去除首部後就原封不動的交付給應用層。
   
4. UDP沒有擁塞控制：發送方的UDP只管發，至於接收方能不能收到以及收到處理的速度怎麼樣，發送方不關心。其實微信視頻電話就是這種模式，所以在網絡不好的時候可能會斷斷續續的，但是也不會把數據重新發一遍。
5. UDP支持一對一、一對多、多對一、多對多的交互通信
6. UDP的首部開銷小，只有８字節，而TCP有20字節。

2.1 UDP的首部格式

初學者只需要知道：UDP首部中包含了

1. 源端口
2. 目的端口
3. 長度
4. 檢驗和
   
   也就是把自己的端口和目的端口放進去，給了網絡層，網絡層再包上IP地址以及目標MAC地址，就把數據發出去了。那麼接收方收到後，網絡層再通過UDP首部知道是從哪兒發來的，以及要發給哪個端口。

同時UDP協議還要做差錯檢驗，如果目的端口號不正確（不存在對於端口的進程），就丟棄該報文，並讓網絡層ICMP協議發回去”端口不可達“。這個時候，其實通信已經完成了。
還有檢驗和的這個方法就不說了，反正也不是很簡單，說一遍也不是很懂，有興趣深入瞭解的可以去查資料啦。

3、面向連接的TCP協議（重頭戲）

這纔是今天的重頭戲，也比較複雜，個人水平有限，我就把一些比較重要的拿出來說。

我們在前面也粗略的說了TCP協議是可靠傳輸，那麼TCP協議是怎麼實現可靠傳輸的?

千萬別以爲只是因爲TCP協議是面向連接這麼簡單，比如：我已經確認你在了，但是我發消息的速率是不是太快，沒收到你的確認收到的消息，我是不是應該重發？這中間怎麼提高效率才達到提到信道利用率的目的？

那麼我們先從建立連接開始說起：

3.1 3次握手

之前有漫畫畫過這個原理，比較形象，我們爲了說明問題，只考慮單向發送消息， 假設A是客戶端，是要發消息，B是服務器，是收消息的。
那麼連接圖如下：

第一眼看不懂再看下一張圖，我畫的還行吧

看完基本能明白3次握手，那再返回來看第一張圖，我們來從原理層面理解一下TCP協議：

1. 最初的兩端TCP都是處於關閉狀態，A客戶端主動打開，B服務端被動打開後就處於收聽狀態，準備做出響應
2. A向B發送連接請求報文段，首部的同步位SYN=1，同時初始序號seq = x（這裏的首部的字段我下面會解釋），其實這個時候，並不攜帶數據，也就是隻試探性的請求一下。
3. B收到連接請求報文段後，如果同意建立連接，會向A發送確認。確認的時候SYN=1，ACK=1，確認號ack=x+1，同時也選擇一個初始序列號seq=y。這個時候的B就處於SYN-RCVD（同步收到）狀態
4. A收到B的確認信息後，還要向B給出確認，確認報文段的ACK=1，確認號ack=y+1，而序列號seq=x+1。這個時候A處於ESTABLISHED（已建立連接）狀態。
5. B收到A的確認後，也進入ESTABLISHED（已建立連接）狀態。

但其實：
B發給A的報文段，其實是2個報文段的合併， 先確認報文段（ACK=1,ack=x+1）,然後再發送一個同步報文段（SYN=1，seq=y）。所以這樣的話就是4次握手，但效果卻是一樣的。所以我們目前都說是3次握手。

問題：爲社麼A最後還要發送一次確認呢？
答：爲了防止已失效的連接請求報文段突然又傳送到了B，因爲產生錯誤
聽不太懂？我來舉個例子：
假如現在是2次握手，那麼A發出請求後，遲遲沒有收到B的確認，於是A就重傳請求。然後很快這次就建立了連接。到目前爲止還沒有問題，但是：
第一次發出去的請求並沒有丟失，而是在某個網絡節點滯留了，所以延遲了一會兒到達了B，這個時候B以爲是A發出的新請求，又同意了。但是這個時候A早就忘了還有這個請求了，所以也不會理睬B的確認，也不會向B發送數據，所以這個給連接的資源就被浪費了。

3.2 4次揮手

剛剛說的是建立連接，那麼等到數據發送完了，雙方都可以釋放連接，那怎麼斷開連接呢？我們爲了簡單說明原理，還是假設A先斷開連接

老樣子,看不懂就看我畫的圖：

大概理解了我們來看看原理：

1. 現在A和B都處於 ESTABLISHED狀態，A先向自身的TCP發出連接釋放報文段，並停止再發送數據，主動關閉TCP連接。A把連接釋放報文段首部的終止控制位FN置1，其序號seq=u，這時A進入 FIN-WAIT-1(終止等待1)狀態，等待B的確認。
2. B收到連接釋放報文段後即發出確認，確認號是ack=u+1，而這個報文段自己的序號是v，等於B前面已傳送過的數據的最後一個字節的序號加1。然後B就進入 CLOSEWAT(關閉等待)狀態。【TCP服務器進程這時應通知高層應用進程，所以從A到B這個方向的連接就釋放了，這時的TCP連接處於半關閉( half-close)狀態，即A已經沒有數據要發送了，但B若發送數據，A仍要接收。也就是說，從B到A這個方向的連接並未關閉，這個狀態可能會持續一段時間。】
3. A收到來自B的確認後，就進入 FIN-WA2(終止等待2)狀態，等待B發出的連接釋放報文段。若B已經沒有要向A發送的數據，其應用進程就通知TCP釋放連接。這時B發出的連接釋放報文段必須使FN=1。
4. 現假定B的序號爲w(在半關閉狀態B可能又發送了一些數據)。B還必須重複上次已發送過的確認號ack=u+1。這時B就進入LAST-ACK(最後確認)狀態，等待A的確認。
5. A在收到B的連接釋放報文段後，必須對此發出確認。在確認報文段中把ACK置1，確認號ack=w+1,而自己的序號是seq=u+1。然後進入到 TIME-WAIT(時間等待)狀態。【請注意,現在TCP連接還沒有釋放掉。必須經過時間等待計時器( TIME- WAIT timer)設置的時間2MSL後,A才進入到 CLOSED狀態。時間MSL叫做最長報文段壽命 Maximum Segment Lifetime),RFC793建議設爲2分鐘，但實際中允許不同的實現允許比較小的MSL值。】

好了，關於TCP連接的建立與釋放就到這裏了。到這裏，我已經花了3個多小時了，可是還有一部分還沒寫完。

3.3 可靠傳輸的工作原理

我們上面只是建立了連接，要想做到可靠傳輸，還得在傳輸的時候信道不產生差錯，以及不管發送方發的多快，接收方總能處理完。
但現實終究是很殘酷的，所以我們需要使用可靠傳輸協議

3.3.1 停止等待協議

這個協議是比較簡單的。簡單說就是：
發一條消息，收到對方確認再發下一條。
如果沒收到確認，就認爲是出錯了，超時重傳。

但是如果B確認的消息丟失了，導致A又重新發了一遍，B應該丟棄重複數據再向A發確認收到。
如果B確認的消息遲到了，B就會收到2次數據，那麼B應該丟棄重複數據再向A發確認收到，同時A會收到2次確認，但收到第二次確認就什麼也不做。

這裏面注意的是超時時間不是固定的，具體怎麼取值後面3.5再講。

我們發現這種協議雖然能實現可靠傳輸，但是信道利用率太低了。

假定A發送分組需要的時間是TD，B發送確認分組需要時間TA。消息往返時間RTT，因此信道的利用率U=TD/(TD+RTT+TA）

3.3.2 連續ARQ協議

所以爲了提高傳輸效率，發送方可以使用流水線傳輸

其實看到這裏的時候，我感覺有點像大數據處理中Spark與Flink的窗口函數的原理。
這個ARQ是TCP協議的精髓，所以大家還是大概理解一下：

就好比是A員工給B老闆發一些帶順序編號的文件。
假設窗口是5，也就是說可以連續發5個文件不能等老闆一個一個確認收到，但是假如發完這5個文件後，老闆一個也沒回復你，你就不能發第6個文件，我們把這個5稱爲窗口。

但是問題是：老闆比較忙，所以只會回覆當前收到最後一個文件的序號，對於中間的可能會丟失。但對於A來說，只要收到確認，那麼就可以繼續發送了，總之窗口不能超過5

這樣的話有好有壞：
好處是：如果網好的話，A發的文件B都收到了，直接回復5，那麼A就可以繼續發5個了
壞處是：假如網不好，A發了5個文件，B卻只回復2，這個時候，A就只能認爲另外3個丟失了，再把後面的文件重新傳一遍。

其實瞭解到這裏，關於運輸層的可靠傳輸已經有了基本的瞭解，如果你想再具體的知道ARQ協議是怎麼優化的？ 那麼接着看下面的內容。

要想深入瞭解，還得返回來再看看TCP報文段的首部格式：

3.4 TCP報文段的首部格式

我們再上面這些衆多的標籤裏面挑重點的說一下：

1. 源端口和目的端口： 各佔2個字節，目的從字面上也能看出來，體現了TCP的分用功能
2. 序號： 佔4個字節，所以範圍就是【0，2的32次-1】= 4294967296 個序號。當序號到達最大以後，下一個序號就回到0。這裏的序號就等於上面的ARQ協議中的文件編號，文件=字節。是怎麼實現的，就是這裏一個個編好的。而且這麼多序號大概可以爲4GB的數據編號，所以在一般情況下，當序號重複使用時，舊序號的數據早已經通過網絡到達終點了。
3. 確認號，佔4個字節。雖然是確認呢，但它發的是期望收到對方下一個報文段的第一個數據字節的序號。比如上面例子中的老闆回覆3意味着，它希望下次從3開始發，1和2他已經收到了。
4. 數據偏移
5. 保留
6. 緊急URG（URGent） 當URG=1時，表明此報文字段有緊急數據，應儘快傳送，優先級高於普通數據，也就不會按照之前的排隊順序來傳送
7. 確認ACK ACK=1才表示確認號有效，所以在建立連接後所有的報文段的ACK都等於1
8. 推送PSH（push）很少使用
9. 復位RST（reset）當RST=1表示TCP連接中出現問題，需要釋放連接重新建立連接
10. 同步SYN（synchronization）在建立連接時來同步序號
11. 終止FIN（finis）當FIN=1，表示此報文段的數據發完了，要釋放連接
12. 窗口 佔2字節，窗口指的是，接收方的接收窗口，因爲接收方的數據緩存空間是有限的。窗口字段動態變化
13. 檢驗和：2字節
14. 緊急指針：2字節。它只在URG=1的時候纔有意義。
15. 選項：長度可變，最大40字節。

終於把這些字段大概解釋完了，應該對之前3次握手和4次揮手中的一次名詞眼熟了吧。

知道這個首部格式後，就爲後面的理解奠定了基礎。我們再來返回來看之前的滑動窗口的實現：下面就是給舉例子啦，認證看都能看懂！！！

現在假定A發送了序號爲31~41的數據。這時,發送窗口位置並未改變

但發送窗口內靠前面有11個字節(黑色小方框表示)表示已發送但未收到確認。而發送窗口內靠後面的9個字節(42~50)是允許發送但尚未發送的。

但現在A是發出去了，那麼B收到的情況怎麼樣呢？
B的接受也是20，目前30號之前的是確認過的，這部分數據已經交付了，B的緩存就可以不保存。目前B收到了序號32和33，但是亂序的，而31也不知道去哪鬼混了，可能是丟失了。那麼B該怎麼發送確認消息呢？
B只能對按序收到的數據中的最高序號給出確認， 也就是確認號依然爲31，也就是期望收到的下一個序號仍然是31。

假設現在B收到了31-33並且確認號回覆了34，那麼A的窗口會向前滑動，保持20大小。

同時B的窗口也會向前滑動

但時能發現其實序號37，38和40，B也收到了，只是沒有按序到達，那麼就先暫時存在B的接收窗口中，等到其他數據也到了再回復確認。
但是此時A已經把它窗口中的序號都發送完了，但B還沒有新的確認回覆，那麼此時的A就不能繼續發消息了，只能等待B的確認回覆

所以通過上面的這段舉例，我們發現發送方，把字節流寫入TCP的發送緩存，接收方呢從TCP的接受緩存讀取字節流。 大概就是下面這個樣子。

3.5 超時重傳時間的選擇

我們在上面討論的是正常網絡情況下，B都收到了A的消息，但是假如網絡狀態不好，A發的消息B遲遲沒有回覆，A就會觸發超時重傳，但是這個超時的時間到底是多少合適呢？ 這個時間固定了肯定是不好，因爲網絡的狀態是不確定的，所以TCP採用了一種自適應算法。

我把公式貼一下，看不懂的略過
RTO=RTTs + 4 X RTTd
好了，問題來了。RTTs是什麼？RTTd又是什麼？

首先大家應該還記得這張圖吧：

我們把報文的往返時間記爲RTT，那麼還記的在TCP連接時，就第一次測出來了RTT值，那個就是RTT樣本值。

所以規定：當第一次獲取RTTs的值時，就RTTs = RTT樣本值
但以後每測量到一個新的RTT樣本，就按照下面這個公司再算一次：
新的RTTs=(1-a) X (舊的RTTs)+ a X (新的RTT樣本)

好了，我們再來看RTTd是什麼？
RTTd是RTT 的偏差的加權平均值，說到加權，就想一想初中二年紀的只是吧。
規定：
當第一次獲取RTTd的值時，RTTd = RTT樣本值/2
在以後的測量時：用下面的公式計算：
新的RTTd=(1-B) × (舊的RTTd) + B x |RTTs-新的RTT樣本|
而這個B推薦值是0.25

好了，我知道這公式你也不會去看的，那麼反正知道了超時重傳時間不是固定的而是算出來的就行了。

那麼再來思考一個問題：A現在發消息後超時重傳了，相當於消息發了２次，但問題是原本的消息並沒有丟失，而是網絡延遲，現在A收到B的確認消息了，A怎麼知道B是對第一次發送的消息進行確認還是對後來補發的消息進行確認？

爲什麼還要思考這個問題呢？因爲如上圖所述，這涉及到新的RTT樣本值計算是以那次發送消息的時間爲準。
如果是確認重傳報文，被源主機當作是確認首次發送的消息，那就會RTT樣本值增大，重傳時間RTO偏大，這樣的情況發送多次，就使得RTO越來越長
如果是確認首次發送的報文，但被源主機當作是確認重傳報文，那就會使得RTT樣本值偏小，重傳時間RTO偏小，這樣就會導致報文段過多的重傳，使得RTO越來越短。

所以，最後大牛們討論得到這樣的算法：報文段每重傳一次，新的重傳時間爲舊的重傳時間的2倍。當不再發生報文段的重傳時,才根據上面給出的公式計算超時重傳時間。 實踐證明,這種策略較爲合理。

3.6 選擇確認SACK

現在看似問題都基本得到了解決，但還有個小問題，就是當B收到的數據字節流的序號是斷斷續續的話，怎麼辦？

如果按照之前的約定，只返回按照順序收到的最大的序號，那麼就意味着這些斷斷續續的字節都得重新發送，其實有點浪費，那麼能不能把這些缺失的序號告訴A，這樣A就不用全部重新發送了，於是就在TCP首部的可選字段中，現在多出來了一個選擇確認塊。

但目前文檔並沒有說明A收到選擇確認塊後，該如何響應。所以導致其實目前大多數的實現還是重傳所有未被確認的數據塊。

長出一口氣，寫了7000多字了，還沒結束，看到這裏的你絕對是個狠人，雖然知道寫這麼長，看的人沒幾個，但學習嘛還是爲了自己而學。

3.7 TCP的流量控制

我們在上面通過大段的篇幅已經實現了TCP 的可靠傳輸，但是沒考慮A發消息的速度到底是多少合適？ 太快吧B來不及處理，太慢吧又浪費信道資源。所以就有了流量控制這個學問：讓發送方的發送速率不要太快，要讓接受方來得及接收。

所以，大牛們研究出來了滑動窗口機制。這個大家在上面已經知道了，就是通過窗口大小來控制。

那麼思考一個問題：目前A已經把窗口內的字節都發送完了，不能再發送了，除非等到B的確認號，這樣A的窗口才能繼續向後移動，但可惡的是B的確認信號卻在半路上丟失了，那現在A在等B發確認，B以爲A收到了，在等A發數據。形成了死鎖。

所以爲了解決死鎖問題，TCP爲每一個連接都設有一個持續計時器，只要A第一次收到B的確認，就啓動持續計時器。若持續計時器設置的時間到，就發送一個零窗口探測報文段〔僅攜帶1字節的數據)，而對方就在確認這個探測報文段時，給出了現在的窗口值。如果窗口仍然是零，那麼收到這個報文段的一方就重新設置持續計時器。如果窗口不是零，那麼死鎖的僵局就可以打破了。

好了，死鎖解決了，還有個效率問題，舉個例子：
B的窗口值是400 ，現在A已經發完了該窗口內的400個字節，不能再發了，但是現在A收到了B確認號，但顯示只能向後一個字節，那麼問題來了，A只能發送一個字節，有沒有必要專門發一次？ 還是攢着等B確認到所有字節後A再繼續發？

大牛們又通過考慮，規定：

可以讓接收方等待一段時間，

1. 使得接收緩存已有足夠空間容納一個最長的報文段
2. 或者等到接收緩存已有一半空閒的空間。

只要出現這兩種情況之一，接收方就發出確認報文，並向發送方通知當前的窗口大小。

此外發送方也不要發送太小的報文段，而是把數據積累成足夠大的報文段，或達到接收方緩存的空間的一半大小。
上述兩種方法可配合使用。

嗯，到目前爲止，TCP還剩下一個擁塞控制沒有說，這個主要講的是：

對資源的需求 > 可用資源

這個時候就出現了網絡擁塞，這個裏面的算法已經超出我的理解範圍了，所以我就跳過了。

但是本文到底爲止講述的關於運輸層的內容還是不少的，最後一個問題也不會影響大家整體理解運輸層。

4、本文收尾

OMG，這篇文章終於寫完了，一共花費時間大概在8小時左右，而我第一次看這章只需要不到2小時。但我現在寫完之後對運輸層的理解肯定是比第一次看完要深。

本文內容是根據《計算機網絡（第7版）謝希仁》寫的，我也是看完後寫的，所以文章的圖還有部分內容都是直接引用的該書。

下次就把最後一層應用層寫完。希望對大家能有所幫助。如果覺得寫的還不錯，就點贊收藏鼓勵一下吧。

掃碼關注公衆號“後來X大數據”，回覆【電子書】，領取超多本pdf 【java及大數據 電子書】