TCP/IP 協議精講-精華總結版本

序言

本文旨在介紹一下TCP/IP涉及得所有基礎知識，為大家從宏觀上俯瞰TCP/IP提供一個基石，文檔屬于《TCP/IP圖解（第五版）》的精簡版本。

專業術語

縮寫	全稱
WAN	Wide area network廣域網
LAN	Local area network局域網
TCP	Transmission controll protocol傳輸控制協議
UDP	User Datagram Protocol
IP	Internet Protocol
ISP	Internet Service Provider
IX	Internet Exchange
NOC	Network Operation Center
MTU	Maxinum transmission Unit
DNS	Domain Name System
ARP	Address Resolution Protocol
DHCP	Dynamic Host Configuration Protocol

1 基礎知識

提到通信網絡，不得不想到TCP/IP七層架構，由下圖：

1.1 網絡出現得背景

網絡設備的廣泛使用，處在現在的科技時代，智能設備已經不在講究單打獨斗，而是傾向于“萬物互聯”的生態理念，身邊的電腦、手表、筆記本、電視、汽車...都離不開網絡；
網絡模式的切換，計算機誕生之初，每一臺機器都是一個獨立的設備，之間不能互相通信，如下圖計算機1-3之間沒有任何關聯，用戶如果想切換計算機只能移動實現，想到新中國成立之初，我們在研發核彈、核潛艇...時需要經過大量的計算從而得到科學的結果，但是那個時候國內計算機屈指可數，科研人員想要計算數據時只能來回奔波；

獨立模式：

暫時無法在飛書文檔外展示此內容

互聯模式：

這種模式下不同的計算機之間可以進行信息共享；

暫時無法在飛書文檔外展示此內容

通信方式的轉變，最初的計算機通信是基于有線方式，比如將相同業務的計算機通過有線連接在一起，從而實現信息共享，形成一個局域網，而在新型的網絡通信中，不在有此局限，用戶可以訪問到任何計算機的信息，就像我們坐在家里就可以訪問到國務院下發的最新資訊；
有了網絡之后，萬物互聯將不在是口號，而是做到了真真正正的信息共享，全球”一家“，巴以沖突的最新戰況我們動動手指就能看到；

計算機網絡規模分為兩種：

1.WAN(wide area network)廣域網

廣域網是由多個局域網組成，就像我們幾個人可以組對和其他城市的隊伍競技；

2.LAN(local area network)局域網

顧名思義，局域網就是一個特定區域或者網域環境，可以由交換機、路由器、計算機組合，就像我們幾個人在一個網吧玩紅警；

1.2 協議必要性

協議為多設備之間提供了一種規范，要求所有的設備都必須按照固定的規范執行，這樣高度一致性，不管是什么廠商、平臺...都可以正常通信；

1.3 OSI七層架構及作用

應用層：主要有各應用主導開發，例如郵件協議、文件傳輸協議；

表示層：負責將應用信息轉化為可以利用網絡傳輸的格式，例如在雙端之間傳輸聲音、視頻等信息；

會話層：通信管理協議，負責建立和斷開通信連接；

傳輸層：負責端到端的數據傳輸，TCP/UDP是典型代表；

網絡層：主要負責地址管理域路由選擇，IP是典型代表；

數據鏈路層：雙端直接傳輸的數據，負責將數據轉換為比特流，802.11是典型代表；

物理層：負責將數字信號轉化為電信號/光信號并進行傳輸；

1.4 網絡的構成要素

一個完整的網絡至少需要包含以下幾個要素：

網卡：使計算機聯網的設備；
中繼器：從物理層上延長網絡的設備，可以對信號進行放大和傳輸；
網橋/2層交換機：從數據鏈路層上延長的設備；
路由器/3層交換機：通過網絡層轉發分組數據的設備；
4~7層交換機：處理傳輸層以上各層網絡傳輸的設備；
網關：轉換協議的設備；

1.5 傳輸數據和吞吐量

傳輸速率：（bps）

在數據傳輸過程中，端到端之間數據流動的物理速率就是傳輸速率，傳輸速率高不是指單位時間流動的數據速率有多快，而是指單位時間數據的傳輸量有多少，舉個例子，低速率就好比日常生活中車道少的公路，汽車通路的時間就比較久，而高速率就好比車道多的公路，汽車通過就比較快，那傳輸速率就好比這一段時間通過的車輛；

傳輸速率就可以說是帶寬，帶寬越大，傳輸速率越大；

那對wifi而言，影響數據傳輸數量的因子有哪些呢，如下表格，列出來所有的因子，我們在拆解一個吞吐問題時，首先就需要check這些硬性條件是否滿足（帶寬、空間流、調制解調方式、GI等等）：

吞吐量：

端到端之間實際的傳輸速率被稱為吞吐量，影響吞吐量的因素有這么幾個：

（1）帶寬；

（2）CPU處理能力；

（3）網絡的擁堵程度；

（4）報文中數據字段的占比（不含報文頭，只計算數據段本身）；

.......這幾個因素也將作為后續排查網絡斷流問題的外部因素；

2 TCP/IP基礎知識

TCP/IP更廣義的定義并不是單單指TCP/IP兩種協議（當然就是這么說也沒毛病），但是他們往往是指一個協議家族：

定義協議的組織被稱為是RFC，如何從網絡中獲取協議文檔參考鏈接如下：

RFC協議獲取指導

2.1 新協議標準化流程

2.2 TCP/IP通信流程

2.2.1 數據"身份證"

根據OSI七層架構來看，每一個數據包從應用發送給接收端，都需要經過每一層協議棧層層包裝，如下圖：

每一層都會對所發送的數據進行封裝處理，添加一個首部，這個首部通常包含該層必要的信息，比如發送的目標地址以及協議的相關信息，數據包 = 協議頭 + 數據；（上一層的整個包都會被下一層視為其數據包）

這里我們可以抓一份數據報文來看：

2.2.2 發送數據包

我們舉個例子，我們通過飛書給某位同事發送一個文件壓縮包/語音/文字，看看各層都做了什么：

（1）應用程序處理

在文本框編輯好文字之后，從點擊發送圖標開始，應用程序開始建立TCP連接，當然，他首先會對要發送的內容進行編碼；

（2）傳輸層

這里的傳輸層也可以理解為TCP協議，傳輸層負責建立、斷開TCP連接以及發送數據；

TCP收到應用發來的數據后，會做以下事情：

為數據添加TCP包頭，包頭中將包含以下內容：

將封裝好的數據發送給IP；

（3）網絡層

這里可以理解為是IP協議，IP負責以下內容：

將收到的TCP包整體當作數據包并添加IP包頭，這里將會包含源/目標MAC地址，如果不知道MAC地址，將會通過ARP協議進行尋址，包頭內容如下：

將封裝好的數據發送給驅動程序，也稱為數據鏈路層，這里才開始正真的數據發送；

Mark:這里值得注意的是IP包頭中的TTL字段，他表示這個字段在穿過多少個路由之后被拋棄，當IP沒穿過一個路由器就會-1，當他變成0之后就會被自動拋棄；

（4）數據鏈路層

這里基本是驅動程序，像802.11、以太網、數據網協議都在這一層，拿802.11舉例，驅動程序在拿到數據包之后，負責以下事情：

給網絡層數據包加上802.11協議包頭以及標志802.11的協議，截圖如下：

將封裝好的數據包交給物理層傳輸給數據端；

數據包從應用出來后，經過每一層，都會添加一個包頭，802.11包頭、IP包頭、TCP包頭以及應用自己的包頭，在鏈路層還會添加一個包尾；每個包頭中至少包含兩個信息：

（1）發送端和接收端的地址，數據鏈路層是MAC地址，網絡層是IP地址，傳輸層是端口號；

（2）上一層協議的類型；

Mark:傳輸層和數據鏈路層都有校驗數據完整性的功能；

2.2.3 接收數據包

數據接收過程與發送過程相反，下邊簡單描述下各層協議的任務;

（1）數據鏈路層

從802.11數據包中找到MAC，判斷是否是發給自己的，如果不是就直接丟棄；
查找包頭中類型域，確認包類型交給上一層對應的協議處理；

（2）網絡層

從IP包頭里解析IP地址確認是否是發給自己的包，如果不是直接丟棄；
查找包頭中類型域，確認包類型交給上一層對應的協議處理；
在有路由轉發的情況下，接收端地址往往是路由設備的地址，此時需要根據路由控制表轉發給對應的終端；

（3）傳輸層

計算校驗和，確認數據是否被損壞；
檢查接收數據序號、檢查端口號，確定具體的應用；
傳輸給對應的應用，注意數據校驗完之后會發送一個ACK確認，如果這個ack沒有到達，就會重傳；

3 數據鏈路

數據鏈路層是TCP/IP的基礎，如果沒有數據鏈路，TCP/IP也將無從說起，本文主要介紹數據鏈路的基礎知識，具體協議以802.11為載體；

3.1 數據鏈路層的作用

數據鏈路層的幾個作用在這里簡單介紹下：

端到端之間傳輸數據時，說白了就是數字信號和光/電信號的轉變，轉變為光/電信號正是數據鏈路層和物理層的作用；
數據鏈路層是數據傳輸的最小單位；
數據鏈路層定義了各種通信媒介之間通信的規范；

3.2 數據鏈路相關的技術

3.2.1 MAC地址

MAC地址相當于數據鏈路層的ID，端到端之間通信依賴于MAC地址，因此世界上任何兩臺無線設備都不應該具備相同的MAC地址，MAC地址長度是48b，結構如下：

第1位：單播/多播地址（0/1）

第2位：全局/本地地址（0/1）

第3~24位：由IEEE組織分配，不能重復

第25~48位：由各個廠商直接管理，不能重復

無線設備驅動廠商的識別碼稱為廠商識別碼，即Organizationally Unique Ideifier，簡稱OUI，OUI官網查詢鏈接：OUI官網查詢（在這個鏈接里我們可以看到任何一家廠商的OUI信息）

3.2.2 共享型網絡訪問控制方式

共享網絡是指多設備共用一種傳輸介質，例如多個wifi設備之間共用一個信道進行收發數據，收發數據時都需要獲得傳輸介質，這里就用到了CSMA/CD方式，CSMA/CD要求每個設備發送數據前都需要進行沖突檢測以會的數據傳輸間隙，其工作原理簡單描述就是：

檢測載波信道上有沒有數據波動/能量波動，如果沒有則可以發送數據；
如果有波動，就需要立即釋放載波信道，并隨機退避一段時間，等待時間間隙歸零后重新接入載波信道開始檢測；
這是一種半雙工通信模式；

其具體的工作原理參考這篇文章：DCF之CSMA/CD

3.2.3 非共享型網絡訪問控制方式

非共享型網絡就是指傳輸介質不共享，端到端直接點對點的連接，例如家庭臺式機通過網線與交換機相連，由交換機轉發數據，它是一種全雙工通信模式；

這里簡單說一下半雙工&全雙工通信的差異

半雙工：同一時間只能同時發送數據或者同時接收數據；

全雙工：同一時間可以同時發送數據和接收數據；

3.2.4 MAC地址轉發

在使用同軸網絡的以太網等介質共享環境中，同一時間只能允許一個接入設備收發數據，因此每個設備收發數據時都需要通過競爭手段獲取對介質的控制權限，如此，如果同一個環境中接入的設備數量很龐大時，很明顯的一個弊端就是傳輸效率底下；

為了解決這一弊端，就引入了交換機設備，在以太網中，一臺交換機有多個端口，他們可以根據以太網中每個設備MAC地址決定使用哪個端口轉發，這時端口與MAC地址對應的關系表就成為路由表；這個表一般不需要人為手動配置，大部分機器有自學功能，如下：

Mark：在端口不知情的情況下，端口會給每個連接的設備都發送一個包，在收到其中一個設備回復時，就將此設備MAC地址以及端口號記錄下來，這也是其自學習的過程；

3.2.5 環路檢測技術

在使用了交換機的網絡環境中，如果其中一條網絡通路發生變換，怎么避免一個數據包被反復的發送到一條有問題的鏈路上導致數據包丟失呢？

環路檢測技術就是用來檢測這一問題，在設備直接建立好連接后，會定時的去探測可用的鏈路，這里提到兩種技術：生成樹和源路由，如下：

網絡管理可以設置在規定時間內在各個環路之間進行探測，以確定哪些端口可以使用哪些端口不能使用，同時，網絡管理員也可以設置每個端口之間的權重，規定優先使用哪條環路進行通信，并且在發生問題之后切換備用環路進行通信；

其實在Android Wi-Fi架構設計中，也大量的使用了這個思路，比如系統會設置Wi-Fi、數據等鏈路的權重，根據不同的場景哪些鏈路優先級最高，其次，在DNS、HTTPS探測中也使用備用的地址.....

源路由方法：它是指在傳輸數據幀時，有效記錄設備的源MAC地址并保存到本地，在鏈路發生故障時，直接向源路由發送數據；

3.3 無線局域網

無線通信通常使用電磁波、紅外線、激光等媒介進行傳輸，其傳輸不需要任何網線；架構圖：

無線LAN連接示意圖：

4 IP協議

IP即Internet Protocol，翻譯為國際網絡，屬于網絡層，負責將數據包發送給目標計算機，它可以把世界上任何兩臺計算機關聯到一起；

4.1 IP概述

在網絡七層架構里，IP/網絡層可以理解成重要橋梁，其上連接傳輸層（TCP，以端口作為連接標識），其下連接數據鏈路層，IP傳輸數據包可以跨越不同的數據鏈路層，以IP地址作為連接標識；

4.2 IP基礎

IP模塊涉及的知識塊大致圍繞三塊：IP尋址、路由以及IP的分包與組包；

4.2.1 IP地址

如前文描述中，不同的網絡分層架構中，都有一個唯一的標識用來傳輸數據，傳輸層是采用的端口號，而數據鏈路層是采用了MAC地址作為唯一標識進行傳輸，那么，IP層也有自己的唯一標識 -- IP地址；

4.2.2 路由控制

在一個大型網絡中，涉及到多個路由，而端到端的傳輸一般都需要經過這些路由多次轉發才能到達目標終端，而這個轉發的過程就是路由控制，每一個轉發路由中都應該維護這一張路由表，他不指定終端與終端的地址，而是單獨指定其下一級地址；

4.2.3 數據鏈路層的抽象化

IP協議的主要作用就是用來傳輸多個數據鏈路層的數據，因此對于這些鏈路層的特性抽象化也是IP層重要作用之一，對于IP層來說，無論底層數據鏈路層是什么協議，對于IP來說都是一視同仁，而數據鏈路層之間最大的區別就是最大傳輸單元不同（MTU）；一個典型的場景就是手機使用數據上網，同時開啟熱點為其他設備提供數據網絡，那么這個轉發過程如下：

暫時無法在飛書文檔外展示此內容

手機使用數據上網時，是通過基線交互獲取上網數據，數據鏈路層是以太網，而STA上網時，是通過AP將數據轉發給Data，從而獲取基站的上網數據，這里數據鏈路層是802.11，AP充當了一個轉發路由的角色；

4.2.4 IP屬于無連接型

在此之前，我們肯定聽說過TCP是屬于連接型網絡，而UDP屬于無連接型，這里強調一下，IP也是面向無連接的，數據到達IP層之后，無需建立連接，他會直接進行轉發；問幾個問題，看看大家能回答上來嘛；

（1）IP為什么采用無連接型呢？

一二三，時間到~

這里應該有兩個考慮，一個是簡化管理，因為管理各種各樣的鏈路本來就是一個耗費時間的操作，另外一個就是為了提速，因為如果每次傳輸都需要先進行連接，那么，處理效率就會很低，IP層不連接，而是交給上層協議TCP進行連接管控，這也是協議分層的一個重要目的；

（2）為什么不讓IP層具備可靠傳輸的功能，將協議合并？

一二三，這里留給讀者考慮一下，歡迎各位大佬評論區留言；

4.3 IP地址的基礎知識

在TCP/IP進行傳輸時，每個終端都必須設置正確的IP地址，如果IP地址設置不符合規范或者IP地址沖突，通信就不能正常交互；

4.3.1 IP地址的定義

IP地址的表現形式：32位形式；

計算機如何處理IP地址：計算機處理IP地址都是以二進制形式表示，32位；

10101100. 00010100. 00000001. 00000001（二進制）

172 ? ? ? ?. 20 ? ? ? ? ? .1 ? ? ? ? ? ? . 1 ? ? ? ? ? ? ?(十進制)

在人的世界里，并不習慣二進制形式，因為我們看到的IP都是十進制的，如果按照二進制進行推算的話，那么IP地址池里有多少地址可以分配給計算機：

2^32 = 4 294 967 296；

根據這個數值進行推算，可以為43億個網口分配IP地址，這里有一個理解誤區就是一個計算機并不是只能擁有一個IP地址，例如我們一個手機設備，STA會有一個IP地址，SAP會有一個IP地址，數據會有一個IP地址，P2P會有一個IP地址；

4.3.2 IP地址的組成

IP地址 = 網絡標識 + 主機標識

例如：192.168.31.11/24

網絡標識必須保證在同一連接的數據鏈路上有不同的指，或者在相同的網段下，必須保證有不同的主機標識，總之，每臺主機或者網口不能有相同的指，要么網絡地址不同，要么主機標識不同；一圖說明如下：

//主機標識相同時，網絡標識必須不同

4.3.3 IP地址的分類

IP地址可以劃分為四類：A、B、C、D類；

本節我們腦海里要有一個標準的二進制地址的格式：00000000.00000000.00000000.00000000；

A類：首位以0表示，1-8用來作為網絡標識，9-32用來作為主機標識，其范圍是0.0.0.0 ~ 127.0.0.0，計算方式如下圖：

最小==》00000000.00000000.00000000.00000000轉化為十進制是0.0.0.0；

最大==》01000000.00000000.00000000.00000000轉化為十進制是127.0.0.0；

B類：前兩位以10表示，1-16是網絡標識，17-32是主機標識，其范圍是128.0.0.1 ~ 191.255.0.0；

C類：前三位以110表示，1-24是網絡標識，25-32是主機標識，其范圍是192.168.0.0 ~ 239.255.255.0；

D類：前四位是1110表示，1-32是網絡標識，沒有主機標識，常用來作為多播地址，其范圍是224.0.0.0 ~ 239.255.255.255，經常用來作為多播地址使用；

因此，A、B、C、D類地址的范圍用二進制表示分別如下（表示最大）：

01111111.00000000.00000000.00000000

10111111.11111111.00000000.00000000

11011111.11111111.11111111.00000000

11101111.11111111.11111111.11111111

（以上1是網絡標識部分，0是主機標識部分）

Mark:

(1)如果要用比特位表示主機地址時，不可以全部為0或者1；

(2)全部為1的主機地址默認為廣播地址，全部為0的主機地址經常是未獲取IP的默認地址；例如如果主機地址中出現了十進制的255，那么這個地址大概率就是一個廣播地址；

4.3.4 子網掩碼

4.3.4.1 子網掩碼解決了IP地址分類帶來的浪費

根據之前章節的描述可以知道，一個IP地址只要確定了分類，我們就知道其中網絡標識和主機標識，例如我們根據網絡標識的分類可以確定每個類別：

A類 11111111.00000000.000000000.00000000 -- 255.0.0.0

B類 11111111.11111111.000000000.00000000 -- 255.255.0.0

C類 11111111.11111111.111111111.00000000 -- 255.255.255.0

網絡標識相同的計算機必須屬于同一個鏈路，例如一個B類地址的網絡架構中，理論上一個鏈路上允許6.5W多臺計算機，然而實際網絡環境中一半不會有這么多設備同時連接，因此如果我們直接使用A/B類IP地址的話，就顯得很浪費；

4.3.4.2 子網與子網掩碼

現在，一個 IP 地址的網絡標識和主機標識已不再受限于該地址的類別，而是由一個叫做"子網掩碼"的識別碼通過子網網絡地址細分出比類、類、更小粒度的網絡。這種方式實際上就是將原來類、類等分類中的主機地址部分用作子網地址，可以將原網絡分為多個物理網絡的一種機制。自從引入了子網以后，一個 IP 地址就有了兩種識別碼。一是 IP 地址本身，另一個是表示網絡部的子網掩碼。子網掩碼用二進制方式表示的話，也是一個 32位的數字。它對應 IP 地址網絡標識部分的位全部為 "1" ，對應 IP 地址主機標識的部分則全部為 "0" 。由此，一個 IP 地址可以不再受限于自己的類別，而是可以用這樣的子網掩碼自由地定位自己的網絡標識長度。當然，子網掩碼必須是 IP址的首位開始連續的 "1" "。對于子網掩碼，目前有兩種表示方式。以 172.20.100.52 的前 26 位是網絡地址的情況為例，以下是其中一種表示方法，它將 IP 地址與子網掩碼的地址分別用兩行來表示。

形式一：

IP 地址 ? 172.20.100.52

子網掩碼 255.255.255.192

網絡地址 172.20.100.0

子網掩碼 255.255.255.192

廣播地址 172.20.100.63

子網掩碼 255.255.255.192

形式二：通過一個/加后綴，標識網絡標識的位數，例如/24就表示IP地址的前24位是網絡標識

IP地址：192.168.31.1/24

網絡地址：192.168.31.0/24（0可以省略）

廣播地址：192.168.31.63/24

4.4 IP數據包分片&聚合

4.4.1 MTU類別

MTU就是MAX Transmission Unit最大傳輸單元，表示數據包數據長度的基本單位，例如4.2.3章節描述，不同的物理層其MTU不盡相同：

4.4.2 IP數據包的分片與聚合

由于不同物理層的限制，分片和聚合是必要的，例如，在一個以太網絡環境中，支持的最大MTU是1500字節（包含了首部協議標識），如果發送端要發送4323字節的數據包，就需要先在發送端進行分包，接收端收到之后在進行重組；

如何分包？

（1）路由收到轉發數據之后計算數據長度；

（2）如果帶轉發數據長度大于MTU，則進行分包；

（3）設置一個唯一標識；

（4）接收端根據標識符進行聚合；

我們實際看一下路由的分包與聚合：

暫時無法在飛書文檔外展示此內容

分包：

聚合：

4.4.3 路徑MTU發現

基于上邊介紹的分片機制，我們思考幾個問題：

（1）分片機制解決了設備之間大數據包的發送，如果大量的大數據包持續發送，并且路由需要轉發多個設備的大數據包，負載如何？

（2）大數據包被分片之后，如果因為環境因素導致某個包丟失，這個傳輸后果如何？

歡迎各位大神評論區解答。

那么有沒有一種方式可以解決分片之后導致的一系列問題，當然有了，這就是路徑MTU發現功能；

通俗來說，路徑MTU發現就是探測接收端支持的最大MTU，之后按照MTU之內的數據長度進行發包，如下圖：

（1）首先發送端發送的IP報文里標識分片為false;

（2）路由收到之后由于數據報文長度太長，丟失；

（3）路由發送一個不可達的icmp通知發送端其支持的最大MTU；

（4）發送端發送符合MTU的數據包；

（5）如此反復，直到接收端收不到icmp為止；

4.5 IPV6

4.5.1 為什么需要ipv6

（1）ipv6可以解決ipv4地址被耗盡的缺陷，ipv4的地址長度是4個8位字節，即32比特，而ipv6的地址長度是128比特，一般可以寫成8個16位字節；

（2）ipv6可以彌補ipv4的缺陷，目前大部分的無線產品開始兼容ipv6;

4.5.2 IPV6有什么好處

（1）IP地址擴大，防止路由表膨脹；

（2）性能提升，IPV6僅支持MTU路徑發現，將減小分片帶來的性能，包首部長度固定，簡化了包首部結構，減小路由的負荷；

（3）支持即插即用，即使沒有DHCP服務器也可以實現分配IP；

（4）更加安全，采用了認證和加密功能；

4.5.3 IPV6中IP標記方法

對于IP地址，我相信大部分小伙伴看到這倆個格式的地址會產生不同的感覺：

IPV4：192.168.31.1 -->這是一個IP地址

IPV6：fe80:a415:9ff:fe3a:18c0/64 -->這是什么？

IPV6的地址長度是128位，他能表示38位數（2^128 ~ 3.4 * 10^38），也就是說也可以為這么多用戶分配IP（小編不知道這是多少），如果按照ipv4用十進制表示的話，就是16個數字，這樣就很長，因此習慣上我們以16進制來表示一組，每組中間用：隔開，如果連續的兩段為0時，可以忽略，但是一個IPV6地址最多只能出現一次：：；

IPV6地址標記舉例：

二進制

1111111011011100：1011101010011000：0111011001010100：

0011001000010000：1111111011011100：1011101010011000：

0111011001010100：0011001000010000

十六進制

FEDC：BA98：7654：3210：FEDC：BA98：7654：3210

IPv6 IP 地址省略舉例

二進制

0001000010000000：0000000000000000：0000000000000000：

0000000000000000：0000000000000000：0000100000000000：

0010000000001100：0100000101111010

十進制

1080:0:0:0:8:800:200C:417A

1080::8:800:200C:417A (省略后)

4.5.4 IPV6分片處理

IPV6分片不需要路由參數，而是直接在發送端進行，因此”MTU路由發現“功能必不可少，IPV6中最小MTU是1280字節，如果對于系統資源比較緊張的設備不需要進行MTU路由發現，可以直接按照1280字節發送數據包；

4.6 ipv4首部

這一節我們解析下IPV4首部結構：

版本：

占位4比特，如果是IPV4那么這個值就是4，不同協議版本：

如果遇到我們不知道的協議版本號，可以查閱這個網址：

http://www.iana.org/assignments/version-numbers

首部長度：

4比特，表示IP首部的大小，對于沒有可選項的IP包，首部長度設置為“5”，也就是說IP的首部長度為20字節（4*5）；

區分服務（TOS: Type Of Service）：

8比特，用來表示服務質量，每一位含義如下：

這部分主要與應用強相關，系統層面的網絡基本會無視這一段報文；

這里重點解釋下ECN報文，Explicit Congestion Notification顯式擁塞通告，主要用來報告網絡擁堵的情況，有兩個比特組成：

ECT表示TCP是否處理ECN，如果處理表示為1，CE表示網絡是否擁塞，如果擁塞，表示為1；

總長度：

16比特，因此IP包最大數據長度是2^16 ~ 65535；

標識：

16比特，用于分片，同一個分片這個值相同，通常沒發送一個IP包，這個值+1，此外，即使ID相同，但是源/目標MAC地址不同的話，也會認為是不同的分片；

標志：

3比特，這里是分片相關的信息，具體的含義如下：

片位移：

13比特，用來標識被分片的每一個數據包相對于初始數據包的位置，第一個分片對應的值為。由于 FO 域占 13 位，因此最多可以表示 8192 (= 13 個相對位置。單位為字節，因此最大可表示原始數據加8192=65536 字節的位置。

TTL：

8比特，標識一個數據包可以經過多少路由轉發，每經過一次轉發，值-1；

協議：

8比特，標識IP包頭屬于哪一個協議，具體的協議如下表格：

首部校驗和（Header Checksum）:

16比特，也叫IP首部校驗和。該字段只校驗數據報的首部，不校驗數據部分。它主要用來確保 IP 數據報不被破壞。校驗和的計算過程，首先要將該校驗和的所有位置設置為，然后以 16 比特為單位劃分首部，并用補數'計算所有 16 位字的和。最后將所得到這個和的補數賦給首部校驗和字段。

源地址&目標地址：

均是32比特，標識發送/接收的IP地址；

可選項：

長度不固定，一般在實驗時使用，可以忽略；

數據（Data）：

存入數據，將IP協議上層的首部作為數據段存入；

4.7 ipv6首部

這里大部分和IPV4類似，并且刪除了某些IPV4報文字段用來提升IPV6的性能，小編這里不做進一步拆解，小伙伴有問題歡迎留言討論；

5 IP協議相關技術

IP，網絡協議，其目的是將數據包傳遞到目標主機，思考一個問題，想要完成這個過程，需要哪些必不可少的步驟呢？（1、2、3時間到）

（1）需要完成目標主機IP&MAC地址的解析；

（2）數據包傳輸過程中異常處理的功能；

5.1 IP協議是否可以完成以上所有工作？

很顯然不可以，根據前四篇文章的介紹，我們知道，應用發送一個數據包，需要經過傳輸層、網絡層、數據鏈路層以及物理層層層封裝，而不同的層次都負責了不同的任務，例如傳輸層的是按照端口傳輸，網絡層是按照IP地址傳輸、數據鏈路層是通過MAC地址傳輸，物理層主要負責數字信號和電信號/光信號的轉化，因此僅僅依靠IP協議是根本無法完成傳輸的，我們舉一個非常通俗易懂的例子，我們在終端發起一個ping www.baidu.com的命令，是如何得到服務器回復的（1、2、3時間到）~ （1）會話層：首先，服務器并不能識別字符串代表什么，因此需要通過DNS解析一個IP地址，發送端發送一個HTTP會話到這個IP地址；

（2）傳輸層：添加傳輸層首部，系統為這個數據包分配一個端口號，發送端使用該端口號向接收端發起請求，建立socket連接，然后發送給網絡層；

（3）網絡層：添加網絡層首部，網絡層收到這個數據包之后，查找路由表將數據包轉發給接收端，這里可能需要很多次轉發，當然這個路由表是在路由側維護的，然后發送給數據鏈路層；

（4）數據鏈路層：添加數據鏈路層首部，通過鄰居協議ARP（arp request/reply）/ipv6鄰居協議(NS/NA)查找接收/發送端對應的MAC地址；

（5）物理層：通過傳輸媒介將數據包發送到空口當中，直到到達接收端；

涉及到的協議：

（1）應用層

http - www訪問協議；

（2）傳輸層

TCP - 為HTTP提供可靠的數據傳輸；

UDP - 傳輸音頻、視頻流，包括DNS也是基于UDP實現；

（3）網絡層

Icmp - 鏈路傳輸質量控制，延時、MTU路由發現、差錯檢查、鏈路可達等；

DNS - 實現域名&IP之間的轉換、網絡校驗；

ARP - 實現IP地址&MAC地址之間的轉化；

......

可以看到一個數據包的傳輸是需要經過多種協議協同配合的，因此本章我們簡單整理下各個協議細節；

5.2 DNS

DNS request:

DNS response:

DNS的主要作用就是實現將由羅馬字和點組成的字符串轉化為計算可以識別的IP地址；DNS協議同時適用于IPV4&IPV6；

5.2.1 為什么需要DNS協議

試想一下，如果沒有DNS協議，我們想要訪問一個服務器或者主機時，都需要輸入對應的IP地址，在現代網絡中，一個網絡拓撲結構中存在大量的機器，如果我們想要實現互相的通信，就必須人手一本IP”新華字典“，顯然這樣是不現實的，這個時候我們如果只需要輸入主機名/域名，就比較方便了；

5.2.2 DNS域名系統的作用

在端到端的通信過程中，目前無非兩種方式，通過IP地址或者主機名，IP地址不方便記憶，通過我們會使用主機名進行通信，DNS服務器可以將這個主機域名轉換為IP地址；

Linux系統上通常可以使用nsloopup查詢IP地址 -MT:~$ nslookup www.baidu.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: www.baidu.com canonical name = www.a.shifen.com. Name: www.a.shifen.com Address: 220.181.38.150 Name: www.a.shifen.com Address: 220.181.38.149 Name: www.a.shifen.com Address: 240e:83:205:58:0:ff:b09f:36bf Name: www.a.shifen.com Address: 240e:83:205:5a:0:ff:b05f:346b

5.2.3 Internet DNS域名的樹形結構

上圖展示了 DNS ?服務器的部分層次結構，從上到下依次為根域名服務器、頂級域名服務器和權威域名服務器。域名和IP地址的映射關系必須保存在域名服務器中，供所有其他應用查詢。顯然不能將所有信息都儲存在一臺域名服務器中。DNS使用分布在各地的域名服務器來實現域名到IP地址的轉換。

域名服務器可以劃分為以下四種不同的類型:

根域名服務器：根域名服務器是最高層次的域名服務器。每個根域名服務器都知道所有的頂級域名服務器的域名及其IP地址。因特網上共有13個不同IP地址的根域名服務器。當本地域名服務器向根域名服務器發出查詢請求時，路由器就把查詢請求報文轉發到離這個DNS客戶最近的一個根域名服務器。這就加快了DNS的查詢過程，同時也更合理地利用了因特網的資源。
頂級域名服務器：這些域名服務器負責管理在該頂級域名服務器注冊的所有二級域名。當收到DNS查詢請求時就給出相應的回答（可能是最后的結果，也可能是下一級權限域名服務器的IP地址)。
權限域名服務器：這些域名服務器負責管理某個區的域名。每一個主機的域名都必須在某個權限域名服務器處注冊登記。因此權限域名服務器知道其管轄的域名與IP地址的映射關系。另外，權限域名服務器還知道其下級域名服務器的地址。
本地域名服務器：本地域名服務器不屬于上述的域名服務器的等級結構。當一個主機發出DNS請求報文時，這個報文就首先被送往該主機的本地域名服務器。本地域名服務器起著代理的作用，會將該報文轉發到上述的域名服務器的等級結構中。本地域名服務器離用戶較近，一般不超過幾個路由器的距離，也有可能就在同一個局域網中。本地域名服務器的IP地址需要直接配置在需要域名解析的主機中。

5.2.3 DNS域名解析過程

DNS域名解析有兩種方法：遞歸查詢 & 迭代查詢；

遞歸查詢：

遞歸查詢就是，如果本地主機想要訪問一個服務器資源，本地域名服務器并不知道這個服務器域名對應的IP，那么本地域名服務器將攜帶這個請求向上一級域名服務器查詢，直到查詢到目標IP為止，用一張圖來說明就是：

迭代查詢：

相比遞歸查詢，迭代查詢不同的地方在于，每一級DNS域名服務器并不會抓發dns請求，當一個DNS請求到達一個DNS服務器后，如果這一級DNS服務器找不到目標IP地址，將會返回給上一級一個推薦的DNS域名服務器，接下來主機則會向這個推薦的DNS服務器發起請求，直到查詢到這個目標IP地址，用一張圖來說明就是：

5.2.4 DNS主要記錄

IP以及域名的對應關系只是DNS系統的一部分，DNS域名系統管理的信息還包含如下部分：

5.3 ARP

ARP，又稱Address Resolution Protocol地址解析協議，用來獲取設備IP對應的MAC地址，ARP只適用于ipv4，IPv6對應的尋址協議是ICMPv6;

5.3.1 ARP報文格式

ARP包含兩種包類型：arp request、arp response;

//arp request

//arp response

5.3.2 ARP是如何獲取到對端MAC的

這里使用一張圖來說明：

值得注意的是arp request是廣播包，arp reply是單播包；

5.3.3 ARP緩存

通過上文我們知道，ARP協議是為了發送數據包之前獲取到接收端的MAC地址，那么，如果每次發送一個數據包就需要發送一次arp，這顯然增大了網絡流量，傳輸效率也會很低，因此，我們通常會把獲取到的IP地址 - MAC地址映射關系保存到緩存表里一段時間，下次發送數據包的時候就需要重新發起請求，不過，這個緩存表只能保存一段時間，超過這個期限將會重新請求；

發送端發送arp時，如果接收端沒有回復時將會重新嘗試，重新嘗試的次數一般寫在設備這個節點 cat /proc/sys/net/ipv4/neigh/wlan0/ucast_solicit（廣播） cat /proc/sys/net/ipv4/neigh/wlan0/mcast_solicit（組播）

5.3.4 ARP協議的必要性

ARP作為IP - 數據鏈路層的紐帶，用來實現IP - MAC的查找，我們解讀其必要性通過解釋這么一個問題來說明;

問題 - 如果我們發的數據包沒有IP或者MAC，數據包是否可以到達目標主機？

我們用這個圖來解答這個問題；

首先，如果PC1向PC2發送數據包不需要IP地址，當設備PC1向PC2發包時，在路由學習MAC地址之間，并不知道這個數據包應該發給誰，這個時候路由可以選擇向全世界所有的設備發包，在學習到所有MAC地址之后維護到路由表里，這樣將造成極大的流量浪費&系統資源；

其次，如果PC1向PC2發送數據包不需要MAC地址，PC1向PC2發送數據包時，只有IP地址，當這個數據包到達Route1之后，其并不知道下一路由是誰（下一路由就是MAC地址中的DA mac），或許也可以向所有設備發包，但是這樣就同樣會導致流量浪費；

所以IP&MAC缺一不可；

我們按照上圖實際抓空口包來看一下這個過程：

5.4 ICMP

5.4.1 ICMP扮演的角色

基于此前的文章分析，我們知道ICMP可以用來進行MTU路由發現，這一章就集中整理下ICMP都用來做什么；

（1）MTU路由發現，具體功能我們在4.4.3已經分析了，忘記的同學可以回去再看看；

（2）確認IP數據包是否正確發送，如果未正常達到，發送ICMP包通知具體原因；

（3）網絡質量探測，通過ping延遲判斷網絡是否是通的以及干擾程度；

（4）設備軟件是否存在問題，例如通過ping入測試設備軟件RX性能的健壯性，關于這個話題-如何定位ping入問題本后的軟件原因，小編想了想后邊還是單獨拉一個專題出來整理（Wi-Fi兼容性）；

（5）工具刀，如果我們把一個網絡結構想象成一個龐大的電路設計，如果其中某處供電有問題，我們都可以使用ICMP包進行檢查，小編做這個比喻的目的就是為了提醒大家，ICMP包的作用并不是一兩句話可以陳列完畢，在日常開發過程中，它可以做到方方面面，開發者腦洞有多大，他的作用就有大多，所以我們拿到一份網絡報文，如果看到ICMP包，請先嘗試解讀一下他的上下文，在為的功能定性；

這里例舉一種IP包沒有正常送達目標機器的錯誤通知機制：

5.4.2 ICMP消息類型

ICMP目標不可達消息（類型3）

當路由器無法將IP數據包發送給目標地址時，會給發送端返回這個消息，我們實際當中遇到最多的就是代碼1（Host Unreachable），它是指路由表里沒有目標主機，或者目標主機沒有接入網絡；消息4（Fragmentation Needed and Don't Fragment was Set）就是4.4.3節提到的路徑MTU發現；

還有一些其他的消息類型如下，這里不一一描述，小伙伴可以在實際開發當中遇到時在臨時抱佛腳：

5.5 DHCP

DHCP，即Dynamic Host Configuration Protocol動態地址分配協議，可以實現為每一臺主機分配IP地址的協議，它同時適用于IPV4、IPV6；

5.5.1 DHCP優勢 - 即插即用

DHCP server可以主動為每一臺主機分配IP地址：

5.5.2 DHCP工作機制

客戶端設備如何從DHCP服務器上獲得IP地址，一般來說DHCP分配IP地址有兩種方式：

（1）DHCP server選出一個特定的IP分配給IP；

（2）為某個MAC地址分配固定的MAC；

//DHCP整體流程

5.6 NAT

5.7 IP隧道

5.8 其他IP技術

6 TCP與UDP

TCP和UDP是傳輸層的代表協議，他起著承上啟下的作用，主要負責將應用的數據包發送到網絡層；

6.1 TCP首部

//協議首部

//抓包首部

接下來，我們簡單過一下每個字段內容代表含義：

源端口號：

16位，標識發送端應用端口號；

目標端口號：

16位，標識接收端應用端口號；

序列號：

32位，序列號代表了發包的順序，一般來說，序列號會有計算機程序發送的SYN攜帶其實的序列號，之后每次發送一個包，序列號=起始序列號+數據發長度，如果沒有數據包，默認+1；

確認應答號：

32位，簡稱ACK seq，標識下一次發送數據包的序列號；

數據偏移：

4位，TCP首部的長度，該字段表示 TCP 所傳輸的數據部分應該從 TCP 包的哪個位開始計算，當然也可以把它看作 TCP 首部的長度。該字段長位，單位為字節(即 32 位)。不包括選項字段的話，如圖 6.26 所示 TCP 的首部為 20 字節長，因此數據偏移字段可以設置為。反之，如果該字段的值為，那說明從 TCP 包的最一開始到 20 字節

為止都是 TCP 首部，余下的部分為 TCP 數據。

保留：

沒有實際含義，用來協議的拓展；

控制位：

8位，每一位從左至右分別為 CWR、ECE、URG、ACK、PSH、RST、SYN、FIN 這些控制標志也叫做控制位。當它們對應位上的值為時，具體含義如下圖所示。

Mark:這些控制位默認為0，如果那個控制位被設置為1，就代表了一些特定的含義；

CWR(Congestion Windows Reduced):

CWR標志與后面的ECE標志都用于IP首部的ECN字段。ECE標志為時，則通知對方已將擁塞窗口縮小。

ECN(ECN-Echo):

ECE標志表示ECN-Echo置為會通知通信對方，從對方到這邊的網絡有擁塞。在收到數據包的首部中ECN時將TCP首部中的ECE置為 1 。

URG(Urgeant):

表示有緊急的數據需要處理，對于數據細節將會在后續的該指針中解釋；

ACK(Acknowledgment):

確認應答位，TCP協議中除SYN包之外都應該被設置為1；

PSH(Push flag):

該位為1時，表示需要將收到的數據立刻傳給上層應用協議。PSH 時，則不需要立即傳而是先進行緩存。

RST(Reset):

重置位，當這個位設置為1之后，代表TCP連接必須因為一些原因斷開連接，詳細的解釋參考這里：

mp.weixin.qq.com；

SYN:

連接位，當設置為1時，代表建立TCP連接；

FIN:

釋放連接位，當設置為1之后，表示數據發送方沒有數據發送了，請求斷開連接，接收方在收到這個控制位之后，將會在自己處理完所有數據后，斷開連接；

窗口大小(Windows Size)：

16位，表示當前TCP連接中所能接收的數據大小，TCP協議中不會出現發送大于窗口的數據；

選項：

這個字段出現在TCP連接控制報文中，用于協商上端的能力，常見的幾個代表項如下：

類型2：用來確認連接可以發送的報文最大長度；

類型3：窗口擴大；

類型4、5：選擇確認應答，TCP標準應答中僅允許一次發送一個數據報文+應答報文，這種模式在網絡擁堵的情況下性能會很低，而這個字段可以將應答數量增加到四個數據包，也就是說允許一次接收4個數據包進行一次應答；

類型8：時間戳字段選項，用于高速通信中對序列號的管理。若要將幾個數據高速轉發到網絡時， 32 位序列號的值可能會迅速使用完。在傳輸不穩定的網絡環境下，就有可能會在較晚的時間點卻收到散布在網絡中的一個較早序列號的包。而如果接收端對新老序列號產生棍淆就無法實現可靠傳輸。為了避免這個問題的發生，引入了時間戳這個選項，它可以區分新老序列號。

6.1.1 TCP吞吐量

這個思想也經常用在TCP極限性能測試中，iperf工具提供了一個-P參數，來控制TCP連接；

6.2 UDP首部

UDP相比TCP首部簡單了許多，這里我們不在詳細描述，讀者可以參考TCP部分；

6.3 TCP&UDP的區分

TCP 是面向連接的、可靠的流協議。流就是指不間斷的數據結構，你可以把它想象成排水管道中的水流。當應用程序采用 TCP 發送消息時，雖然可以保證發送的順序，但還是猶如沒有任何間隔的數據流發送給接收端TCP 為提供可靠性傳輸，實行"順序控制"或"重發控制"機制。此外還具備"流控制(流量控制) "、"擁塞控制"、提高網絡利用率等眾多功能。

UDP 是不具有可靠性的數據報協議。細微的處理它會交給上層的應用去完成。在 UDP 的情況下，雖然可以確保發送消息的大小\卻不能保證消息一定會到達。因此，應用有時會根據自己的需要進行重發處理。

這就意味了TCP可以在傳輸層為應用保證可靠的傳輸，而如果應用使用了UDP協議，就需要應用自身需要進行重發處理；

TCP&UDP區分：

6.4 傳輸層標識 - 端口號

在第四章我們提到過，IP層包含了一個協議字段，標識他的上一層協議是TCP還是UDP：

//TCP

//UDP

傳輸層也是如此，他需要一個標識來區分數據包應該發給哪個應用，這個標識就是端口號：

6.4.1 端口號如何確認

1，標準制定的端口號

這部分端口號是固定的，是協議標準組織為一些特定的應用分配，應用程序應該主動避免使用這部分端口號;

2.操作系統分配

動態分配端口號范圍是49152 ~ 65535；

TCP&UDP的一些知名端口號分配如下：

//tcp

//udp

6.5 TCP如何實現可靠性傳輸

6.5.1 通過序列號&確認應答

TCP應用中，發送端向接收端發送數據時，在接收端收到之后，會向發送端回復一個確認代表已經收到，對于發送端來說，如果某個數據包沒有收到回復只要重傳就可以，而對于接收端，如果反復收到來自發送端的重傳數據，這將是災難性的，如果每次收到數據包都處理顯然是不現實的，接收端就要一種機制來確認是否需要接收數據；序列號是發送端順序發送的每一個數據包的序列號，接收端收到數據包之后，解析這個序列號以及數據長度，并且將二者之和作為自己下一次收包的序列號，這樣實現了可靠的傳輸；

6.5.2 超時重傳

超時重傳是指發送出去的數據包到接收到確認包之間的時間，如果超過了這個時間會被認為是丟包了，需要重傳。那么我們該如何確認這個時間值呢？在一個穩定的網絡環境中，一個數據包的收發時間是差不多的，都會有一個類似于平均值的概念。比如發送一個包到接收端收到這個包一共是0.5s，然后接收端回發一個確認包給發送端也要0.5s，這樣的兩個時間就是RTT（往返時間）。當然，隨著網絡擁堵等環境的變化，時間會有偏差，如果我們可以設置一個合理的超時門限，也將大大保證TCP包重傳的穩定性；

6.5.3 連接控制

TCP是面向連接的協議，雙端在發送數據之前，必須進行連接，才可以通信，在通信完成之后主動斷開連接，斷開連接之后，將不在處理收到的發送端的任何數據包，連接與斷開連接流程如下：

6.5.4 TCP以段為單元傳輸

在此之前我們說過，IP層數據包的傳輸單元是MTU，在傳輸層，其最小傳輸單元是MSS，這個值最理想的情況就是

長度不至于在IP層分包，以此簡單分包對于性能的損耗；MSS在TCP建立連接時協商得到，雙端在建立請求時分別告訴對端自己的傳輸單元，然后本次連接將采用最小值進行傳輸，報文內容如下：

//syn

//ack

6.5.5 滑動窗口

如上一節，我們說到，TCP傳輸是以段位傳輸單位，每發送一個段，接收端就需要一次應答，按照這種方式來傳輸的話，TCP的性能將會大大折扣，為了解決這個性能問題，就引入了滑動窗口的概念，簡單來說就是，擴大TCP傳輸單位，即一次傳輸多個數據包，同時，接收端也需要進行多次應答，如果其中一個數據包沒有收到應答，發送端應該繼續保留這部分數據并且進行重傳，直到收到應答，再將緩存區這部分數據刪除；在TCP協議棧中保留了幾個窗口相關的設置：

tcp.window_size_value

tcp.window_size_scalefactor

tcp.window_size

其中tcp.window_size = tcp.window_size_value * tcp.window_size_scalefactor；

幾個注意的點：

1.TCP滑動窗口并不是越大越好；

2.發送的窗口 <= 接收端窗口；

3.滑動窗口的大小是需要根據網絡擁堵情況動態調整；

4.窗口大小由接收端決定；

窗口控制如何實現高效傳輸？

（1）減少不必要的重傳，在發送單個數據段必須對應收到應答報文的傳輸過程中，如果丟失了一個數據包，就必須要進行重傳，而設置了滑動窗口的傳輸過程中，如果僅僅丟失了一個數據包，可以根據后續應答報文的序列號進行復判是否需要重傳；

如上圖，雖然報文段1-1000應答報文丟失了，但是收到了ack-2001，就認為之前的報文都收到了，就不需要進行重傳了；

（2）在快速響應重傳，在發送單個數據段必須對應收到應答報文的傳輸過程中，如果發送端沒有收到應答報文，只能依賴超時機制進行檢測，而在滑動窗口的傳輸過程中，由于發送端在反復發包，如果中間丟失了一個報文，接收端可以通過應答報文的序列號快速響應，如果連續收到幾個ack序列號一致，那么就認為數據丟失，可以快速進行重傳，效率相對較高；

6.5.6 流量控制

上一節描述到，為了解決TCP單段傳輸的性能問題，我們引入了滑動窗口的概念，允許TCP一次發送多個數據包，接收端進行多次確認，那么試想，如果網絡環境比較擁堵，發送端在發送多個數據包的時候，丟失了其中幾個包，如何保證傳輸數據的可靠性？如果窗口設置太多，發送端不停的發送數據包，而接收端處理效率低于發送端，造成的流量阻塞如何解決？那么，針對這些問題，我們如何設計高效的傳輸細節，可以避免呢，本章將會詳細解析；

（1）流控制解決網絡擁堵問題

接收端的應答報文中（TCP首部）會包含一個窗口字段，這個字段也代表了接收端數據緩存區的大小，這個值越大代表網絡的吞吐越大；如果接收端因為環境擁堵或者CPU性能限制，這個值也是逐漸減小，平滑的處理性能問題；

這里兩個代表的算法名稱就是：

快重傳算法：快重傳算法首先要求接收方每收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時才進行捎帶確認。接收方收到了M1和M2后都分別發出了確認。現在假定接收方沒有收到M3但接著收到了M4。顯然，接收方不能確認M4，因為M4是收到的失序報文段。根據可靠傳輸原理，接收方可以什么都不做，也可以在適當時機發送一次對M2的確認。但按照快重傳算法的規定，接收方應及時發送對M2的重復確認，這樣做可以讓發送方及早知道報文段M3沒有到達接收方。發送方接著發送了M5和M6。接收方收到這兩個報文后，也還要再次發出對M2的重復確認。這樣，發送方共收到了接收方的四個對M2的確認，其中后三個都是重復確認。快重傳算法還規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段M3，而不必繼續等待M3設置的重傳計時器到期。由于發送方盡早重傳未被確認的報文段，因此采用快重傳后可以使整個網絡吞吐量提高約20%。

快恢復算法：與快重傳配合使用的還有快恢復算法，其過程有以下兩個要點：當發送方連續收到三個重復確認，就執行“乘法減小”算法，把慢開始門限ssthresh減半。與慢開始不同之處是現在不執行慢開始算法（即擁塞窗口cwnd現在不設置為1），而是把cwnd值設置為慢開始門限ssthresh減半后的數值，然后開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。

（2）慢啟動算法，發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變量。擁塞窗口的大小取決于網絡的擁塞程度，并且動態地在變化。發送方讓自己的發送窗口等于擁塞窗口。發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡中的分組數。慢開始算法：當主機開始發送數據時，如果立即所大量數據字節注入到網絡，那么就有可能引起網絡擁塞，因為現在并不清楚網絡的負荷情況。因此，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口 cwnd 設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口 cwnd ，可以使分組注入到網絡的速率更加合理。

每經過一個傳輸輪次，擁塞窗口 cwnd 就加倍。一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過“傳輸輪次”更加強調：把擁塞窗口cwnd所允許發送的報文段都連續發送出去，并收到了對已發送的最后一個字節的確認。另，慢開始的“慢”并不是指cwnd的增長速率慢，而是指在TCP開始發送報文段時先設置cwnd=1，使得發送方在開始時只發送一個報文段（目的是試探一下網絡的擁塞情況），然后再逐漸增大cwnd。為了防止擁塞窗口cwnd增長過大引起網絡擁塞，還需要設置一個慢開始門限ssthresh狀態變量。慢開始門限ssthresh的用法如下：當 cwnd < ssthresh 時，使用上述的慢開始算法。當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞控制避免算法。擁塞避免算法：讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。

無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設置為1，執行慢開始算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。如下圖，用具體數值說明了上述擁塞控制的過程。現在發送窗口的大小和擁塞窗口一樣大。

6.6 Socket編程

應用在使用 TCP UDP 時，會用到操作系統提供的類庫。這種類庫一般被稱為 API (Application Programming Intenace ，應用編程接口)。使用 TCP UDP 通信時，又會廣泛使用到套接字 (socket) API 套接字原本是由 BSD UNIX 開發的，但是后被移植到了 Windows Winsock以及嵌入式操作系統中。應用程序利用套接字，可以設置對端的 IP 地址、端口號，并實現數據的發送與接收。