目錄

傳輸層

傳輸層功能

傳輸層所提供的服務(wù)

傳輸層的兩個協(xié)議

TCP協(xié)議與UDP協(xié)議

端口

端口分類

IP地址和端口的關(guān)系

UDP協(xié)議?

前言：

UDP報文格式

檢驗和的偽首部

偽首部內(nèi)容

TCP協(xié)議

TCP報文格式

TCP協(xié)議數(shù)據(jù)段的理解

TCP的偽首部

偽首部內(nèi)容

標(biāo)志位flags

理解TCP的序號與確認(rèn)號

TCP的幾個要點

TCP可靠傳輸

停止等待-ARQ（automatic repeat-request）自動重傳請求

連續(xù)ARQ協(xié)議+滑動窗口協(xié)議

具體案例

SACK選擇性確認(rèn)

傳輸層數(shù)據(jù)分段

流量控制

原理：

具體案例

流量控制的特殊情況

擁塞控制

前言

擁塞控制方法

基本知識

擁塞窗口、接收窗口、發(fā)送窗口的理解

擁塞控制-慢開始

擁塞避免

擁塞控制-快重傳

快恢復(fù)

TCP連接管理

TCP建立連接三次握手

TCP建立連接三次握手的原因

連接過程（以http的get請求為例——數(shù)據(jù)部分為4字節(jié)）

TCP釋放連接四次揮手

為什么釋放連接需要四次揮手

客戶端發(fā)送ACK報文后需要時間等待原因

時間等待的確認(rèn)

傳輸層

傳輸層功能

1. 定義應(yīng)用層協(xié)議數(shù)據(jù)報文的端口號，流量控制
2. 對原始數(shù)據(jù)進(jìn)行分段處理

傳輸層所提供的服務(wù)

1. 傳輸連接服務(wù)（主要是針對會話層的要求，對每一個傳輸連接去建立相應(yīng)的連接）
2. 數(shù)據(jù)傳輸服務(wù)（流量控制，差錯控制，序列控制）

傳輸層的兩個協(xié)議

• TCP（Transmission Control Protocol）傳輸控制協(xié)議
• UDP（User Datagram Protocol）用戶數(shù)據(jù)報協(xié)議?

TCP協(xié)議與UDP協(xié)議

端口

含義：應(yīng)用程序在計算機中的唯一標(biāo)識

端口分類

• 源端口：一般位于客戶機
• 目標(biāo)端口：一般位于服務(wù)器

IP地址和端口的關(guān)系

注意：

• 端口可分為虛擬端口和物理端口，其中虛擬端口指的是計算機內(nèi)部或交換機路由器內(nèi)的端口，不可見。
• UDP/TCP首部中，端口占用2字節(jié)，因此可以計算出端口范圍：0-65535
• 防火墻可以設(shè)置開啟和關(guān)閉某些端口來提高安全性

UDP協(xié)議?

前言：

• UDP協(xié)議是面向無連接的，他減少了建立和釋放連接的開銷
• UDP盡最大能力交付，不保證可靠傳輸
• UDP不需要維護(hù)一些復(fù)雜的參數(shù)，首部只有8個字節(jié)
• UDP協(xié)議不需要建立連接，直接發(fā)送數(shù)據(jù)，不會去重新排序，不需要確認(rèn)

UDP報文格式

注意：

• 16位UDP長度：指的是UDP首部的長度和UDP數(shù)據(jù)的總長度
• 16位UDP檢驗和：將偽首部和首部和數(shù)據(jù)部分計算出一個值，用來檢測UDP用戶數(shù)據(jù)在傳輸過程中是否有錯，有錯就丟棄
• 偽首部僅在計算檢驗和的時候起作用，并不會傳遞給網(wǎng)絡(luò)層

檢驗和的偽首部

偽首部內(nèi)容

• 源IP地址
• 目標(biāo)IP地址
• 保留位（固定為0）
• 協(xié)議類型（封裝所用的協(xié)議的數(shù)字表示形式）
• UDP長度不包括偽首部長度，主要為UDP首部和數(shù)據(jù)部分的總長度

注意：

• 偽首部固定12個字節(jié)
• 偽首部僅在計算檢驗和的時候起作用，并不會傳遞給網(wǎng)絡(luò)層

TCP協(xié)議

前言：該協(xié)議要求數(shù)據(jù)在傳輸前必須建立連接，數(shù)據(jù)在傳輸完成后必須釋放連接。

TCP報文格式

TCP協(xié)議數(shù)據(jù)段的理解

• 序號：占32位，傳輸過程中的每一個字節(jié)都有一個編號，在建立連接后，序號代表這一次傳給對方多個數(shù)據(jù)包，每個數(shù)據(jù)包的起始位置所在字節(jié)的編號。
• 確認(rèn)號：占32位，標(biāo)志位flags內(nèi)的ACK為1時才有意義，代表期望對方下一次傳過來的TCP數(shù)據(jù)部分的第一個字節(jié)編號（序號）
• 數(shù)據(jù)偏移：占4位，數(shù)據(jù)偏移×4為首部的長度；由此可以算出TCP首部最長60字節(jié)；因為首部長度最小20字節(jié)，所以數(shù)據(jù)偏移最小為5
• 保留：占6位，目前全為0
• 標(biāo)志位flags：占6位，主要用于分析控制數(shù)據(jù)段的狀態(tài)
• 窗口：占16位，主要用于TCP的流量控制，用以告知對方下一次允許發(fā)送數(shù)據(jù)的大小（真正的接收緩存區(qū)大小還需要乘窗口縮放系數(shù)）
• 檢驗和：占16位，通過偽首部+首部+數(shù)據(jù)來計算出檢驗和；用來檢測TCP數(shù)據(jù)段在傳輸過程中是否有錯，有錯就丟棄
• 緊急指針：占16位，標(biāo)志位flags內(nèi)的URG為1時才有意義（若緊急指針為8，則代表TCP數(shù)據(jù)部分前8字節(jié)為緊急數(shù)據(jù)）

TCP的偽首部

前言：占用12個字節(jié)，僅在計算檢驗時起作用，并不會傳輸?shù)骄W(wǎng)絡(luò)層

偽首部內(nèi)容

• 源IP地址
• 目標(biāo)IP地址
• 保留位（固定為0）
• 協(xié)議類型（封裝所用的協(xié)議的數(shù)字表示形式）
• TCP長度不包括偽首部長度，主要為TCP首部和數(shù)據(jù)部分的總長度

注意：

• TCP首部中僅僅有4個字段（數(shù)據(jù)偏移）記錄了TCP報文的首部長度，并沒有字段記錄了TCP報文的數(shù)據(jù)長度，但是偽首部中有TCP首部和數(shù)據(jù)的總長度（TCP長度）
• TCP/UDP的數(shù)據(jù)長度完全可以由IP數(shù)據(jù)包的首部推測出來：傳輸層的數(shù)據(jù)總長度=網(wǎng)絡(luò)層的總長度-網(wǎng)絡(luò)層的首部長度-傳輸層的首部長度

標(biāo)志位flags

• UGR：緊急指針
• ACK：確認(rèn)響應(yīng)序號有效（確認(rèn)建立連接）
• PSH：數(shù)據(jù)傳輸標(biāo)記
• RST：重置連接（當(dāng)RST=1時表明連接出現(xiàn)問題，必須釋放連接后重新建立連接）
• SYN：SYN=1，ACK=0代表這是一個建立連接的請求
• FIN：發(fā)送端完成發(fā)送任務(wù)，要求釋放連接

注意：flags的設(shè)置通過設(shè)置0/1來實現(xiàn)

理解TCP的序號與確認(rèn)號

TCP的幾個要點

• 可靠傳輸
• 流量控制
• 擁塞控制
• 連接管理

TCP可靠傳輸

可靠傳輸：客戶端發(fā)起請求給服務(wù)器，服務(wù)器收到請求給客戶端返回數(shù)據(jù)，若服務(wù)器返回的數(shù)據(jù)比較大那么服務(wù)器不可能一次性把數(shù)據(jù)傳出去，此時數(shù)據(jù)就會被分成好幾個段來進(jìn)行發(fā)送，若發(fā)送的過程中某個數(shù)據(jù)包丟失（客戶端沒有確認(rèn)收到）那么服務(wù)器只會將該包重新發(fā)送

停止等待-ARQ（automatic repeat-request）自動重傳請求

例子：A發(fā)送3個包給B（M1、M2、M3）

• 正常情況：A發(fā)送M1到B，B收到后發(fā)確認(rèn)請求到A，A收到確認(rèn)后發(fā)送M2到B，以此類推
• 超時情況：A發(fā)送M1到B（M1在運輸過程出現(xiàn)差錯）B丟棄有差錯的報文，不向A響應(yīng)確認(rèn)，超時后A重新發(fā)送M1給B，B收到完好的M1后向A響應(yīng)確認(rèn)
• 確認(rèn)丟失：A發(fā)起M1向B，B收到后向A響應(yīng)確認(rèn)M1（傳輸過程確認(rèn)失效），A超時仍沒有收到確認(rèn)，再向B重新發(fā)送M1，B收到后丟棄重復(fù)的M1，重新向A響應(yīng)確認(rèn)，A收到確認(rèn)響應(yīng)
• 確認(rèn)遲到：A發(fā)送M1給B，B收到后響應(yīng)確認(rèn)到A，因為響應(yīng)超時A向B重傳M1，B收到后丟棄重復(fù)的M1后響應(yīng)確認(rèn)到A，此時A收到確認(rèn)可以繼續(xù)發(fā)送其他數(shù)據(jù)包，過一會B的確認(rèn)到達(dá)，A不會做任何動作

連續(xù)ARQ協(xié)議+滑動窗口協(xié)議

注意：

• 滑動窗口的大小由接收方（B）決定
• 有些系統(tǒng)重傳5次還未成功就會發(fā)送RST報文斷開TCP連接
• 接受方在拿到發(fā)送方發(fā)送方的數(shù)據(jù)的時候首先會放到緩存（有大小限制）內(nèi)，若緩存將要不夠用那么就會告訴發(fā)送方特定的接收窗口大小（接收窗口大小不是固定死的）

具體案例

電腦A向電腦B發(fā)送的數(shù)據(jù)

發(fā)送的過程：

SACK選擇性確認(rèn)

前言：在TCP通信過程中，若發(fā)送序列中間某個數(shù)據(jù)包丟失（比如1、2、3、4、5中的3在發(fā)送過程中丟失了）不用SACK技術(shù)的話TCP會通過重傳最后確認(rèn)的分組后續(xù)的分組（最后確認(rèn)的2，會重傳3、4、5）這樣原先已經(jīng)正確發(fā)送的分組也可能重復(fù)發(fā)送（比如4、5）降低了TCP的性能；為了改善上述情況，發(fā)展了SACK技術(shù)，它可以告訴發(fā)送方那些數(shù)據(jù)丟失，那些數(shù)據(jù)已經(jīng)提前收到，這樣TCP只重新發(fā)送丟失的包（3）不用發(fā)送后續(xù)的包（4、5）

舉例：?

理解：假設(shè)發(fā)送方發(fā)了201-1000這么多數(shù)據(jù)，接收方僅僅接受了棕色范圍內(nèi)的數(shù)據(jù)，白色范圍內(nèi)的數(shù)據(jù)都沒接收；那么就會告訴發(fā)送端，自己接受了（左邊界301右邊界401、左邊界501右邊界601、左邊界701右邊界801、左邊界901右邊界1001）的數(shù)據(jù)。

注意：

• SACK信息會放在TCP首部的選項部分
• kind：占1字節(jié)；值為5就代表這是SACK選項（就意味著TCP選項有很多種）
• length：占1字節(jié)；表明SACK選項共占多少字節(jié)
• left edge：占4字節(jié)，左邊界
• right edge：占4字節(jié)，右邊界
• 因為選項部分最多40個字節(jié)，40字節(jié)僅有2字節(jié)是剛需，留給左右邊界的僅有38字節(jié)，因為左右邊界一組為8字節(jié)，那么僅能存放4組左右邊界（TCP數(shù)據(jù)偏移計算得知TCP首部最長60字節(jié)，有20字節(jié)的固定長度，所以選項部分最長40字節(jié)）

傳輸層數(shù)據(jù)分段

為什么選擇在傳輸層就進(jìn)行數(shù)據(jù)分段，而不是等到網(wǎng)絡(luò)層再分片傳遞給數(shù)據(jù)鏈路層？

因為可靠傳輸是在傳輸層進(jìn)行控制的，若在傳輸層不分段，那么一旦出現(xiàn)數(shù)據(jù)丟失，那么整個傳輸層的數(shù)據(jù)都得重傳；若在傳輸層分了段，那么一旦出現(xiàn)數(shù)據(jù)丟失，只需要重傳丟失的那些段即可。

流量控制

前言：接受方在拿到發(fā)送方發(fā)送方的數(shù)據(jù)的時候首先會放到緩存，若接收方的緩存滿了發(fā)送方還在瘋狂的發(fā)送數(shù)據(jù)，那么接收方只能把收到的數(shù)據(jù)包丟掉，大量的丟包會極大的浪費網(wǎng)絡(luò)資源，所以要進(jìn)行流量控制

含義：讓發(fā)送方發(fā)送的速率不要太快，讓接收方來得及接收處理

原理：

• 通過確認(rèn)報文中的窗口字段來控制發(fā)送方的發(fā)送速率
• 發(fā)送方發(fā)送的窗口大小不能超過接收方給出的窗口大小
• 當(dāng)發(fā)送方收到接收窗口大小為0時，發(fā)送方就會停止發(fā)送數(shù)據(jù)

具體案例

流量控制的特殊情況

起初接收方給發(fā)送方發(fā)送了0窗口的報文段，后面接收方又有了一些儲存空間，給發(fā)送方發(fā)送了非0窗口的報文段丟失了發(fā)送方的發(fā)送窗口一直為0，雙方陷入僵局

解決辦法：當(dāng)發(fā)送方收到0窗口通知時，發(fā)送方停止發(fā)送報文，并且同時開啟一個定時器，隔一段時間就發(fā)送個測試報文去詢問接收方最新的窗口大小，若接收窗口大小還是0，則發(fā)送方再次刷新啟動定時器

擁塞控制

前言

理解：

• 防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)
• 避免網(wǎng)絡(luò)中的路由器或鏈路過載

注意：擁塞控制是一個全局性的過程涉及到所有主機、路由器以及降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素，是大家共同努力的結(jié)果，相比而言，流量控制是點對點的通信控制

擁塞控制方法

• 慢開始（slow start）
• 擁塞避免（congestion avoidance）
• 快速重傳（fast retransmit）
• 快速恢復(fù)（fast recovery）

基本知識

• MSS：（MAXimum Segment Size）每個段最大數(shù)據(jù)部分大小，建立連接時確定，發(fā)送方的每個段都不能超過該值
• cwnd：（congestion window）擁塞窗口（使整個網(wǎng)絡(luò)恰好擁塞的最小窗口）
• rwnd：（receive window）接收窗口（接收方告訴發(fā)送方最多發(fā)送的數(shù)據(jù)是多少）
• swnd：（send window）發(fā)送窗口（實際發(fā)送數(shù)據(jù)的窗口）

擁塞窗口、接收窗口、發(fā)送窗口的理解

假設(shè)接收方窗口大小為3000，那么發(fā)送方的發(fā)送窗口發(fā)送的數(shù)據(jù)最多為3000，而擁塞窗口是會經(jīng)常變動的，假設(shè)網(wǎng)絡(luò)現(xiàn)在繁忙不能發(fā)送太多擁塞窗口只有2000（沒有超過接收窗口的3000），那么發(fā)送窗口和擁塞窗口都是相等的；若現(xiàn)在網(wǎng)絡(luò)很順暢，擁塞窗口有5000，而對方接收窗口為3000，那么接收窗口等于發(fā)送窗口。

總結(jié)：發(fā)送窗口=min（接收窗口，擁塞窗口）

擁塞控制-慢開始

理解：接收方告訴發(fā)送方，讓發(fā)送方最多發(fā)送3000數(shù)據(jù)，每個包的數(shù)據(jù)部分不能超過100；接收方收到請求首先先發(fā)1個包，然后收到對方的確認(rèn)了，然后發(fā)送方明白了（發(fā)送一個包沒問題網(wǎng)絡(luò)不堵，可以再給加點量），然后發(fā)送方發(fā)了2個包，對方又都確認(rèn)了，那再發(fā)4個，對方都確認(rèn)，那么再發(fā)8個。

擁塞窗口隨時間變化關(guān)系圖

總結(jié)：cwnd（擁塞窗口）的初始值比較小，然后隨著數(shù)據(jù)包被接收方確認(rèn)（收到一個ACK）cwnd就會成倍增長（指數(shù)級增加）

擁塞避免

注意：

• ssthresh(slow start threshold)：慢開始閾值，cwnd達(dá)到閾值后，以線性方式增加
• 擁塞避免（加法增大）：擁塞窗口緩慢增大，以防止網(wǎng)絡(luò)過早出現(xiàn)擁塞
• 判斷網(wǎng)絡(luò)擁塞：發(fā)送方發(fā)送的數(shù)據(jù)沒有收到對方的確認(rèn)，那么就考慮重傳（有些包丟了）就可以說明網(wǎng)絡(luò)可能出現(xiàn)擁塞
• 乘法減小：當(dāng)發(fā)送方感知到網(wǎng)絡(luò)可能擁塞了就把ssthresh減為峰值的一半，與此同時執(zhí)行慢開始算法（cwnd又恢復(fù)到初始值）

擁塞控制-快重傳

理解：

• 接收方：每當(dāng)收到一個失序的分組后就立即發(fā)出重復(fù)確認(rèn)使發(fā)送方及時知道有分組沒有到達(dá)，而不是等待自己發(fā)送數(shù)據(jù)時才進(jìn)行確認(rèn)
• 發(fā)送方：只要連續(xù)收到三個重復(fù)確認(rèn)（總共4個相同的確認(rèn)）就應(yīng)當(dāng)立即重傳對方尚未收到的報文段，而不必繼續(xù)等待重傳計時器到期后再重傳

快恢復(fù)

理解：當(dāng)發(fā)送方連續(xù)收到三個重復(fù)確認(rèn)，就執(zhí)行“乘法減小”算法，把ssthresh為減為峰值的一半，與慢開始不同的是現(xiàn)在不執(zhí)行慢開始算法，即cwnd現(xiàn)在不會恢復(fù)到初始值，而是把cwnd值設(shè)為ssthresh減半后的數(shù)值然后開始執(zhí)行擁塞避免算法（加法增大），使擁塞窗口緩慢線性的增大

TCP連接管理

注意：連接管理中建立連接的三次握手以及四次揮手的報文中只有TCP報文頭部，而沒有TCP報文數(shù)據(jù)部分

TCP建立連接三次握手

理解：

1. 客戶機向服務(wù)器發(fā)送請求建立連接，控制位syn=1，ACK沒有等于1說明這是一個請求建立連接，這時會自動生成一個序號seq（這個序號是隨機的）?這個序號我們用x來表示，向服務(wù)器發(fā)起請求
2. 服務(wù)器收到請求后，他會向客戶機發(fā)送確認(rèn)請求，進(jìn)而SYN=1，ACK=1，同時有了確認(rèn)的序列號ack=x+1（期望發(fā)送原來序列號的下一個請求）這時服務(wù)端隨機生成一個序列號seq=y；
3. 客戶機收到服務(wù)器發(fā)來的確認(rèn)，客戶機進(jìn)行確認(rèn)ACK=1，客戶機不會再發(fā)請求了，因此沒有SYN，同時有了確認(rèn)序號ack=y+1（期望服務(wù)器執(zhí)行下一步操作），seq=x+1
4. 開始進(jìn)行數(shù)據(jù)傳輸

TCP建立連接三次握手的原因

若建立連接只需要兩次握手，那么可能出現(xiàn)：客戶端發(fā)送的第一個請求因為網(wǎng)絡(luò)延時，在連接釋放以后的某個時間才到達(dá)服務(wù)端，服務(wù)端收到該請求后響應(yīng)了這個遲到的連接請求，但是剛剛客戶端已經(jīng)接受了數(shù)據(jù)，進(jìn)而不會發(fā)起http請求，這樣服務(wù)器就會一直等待進(jìn)而浪費了資源（一直處于建立連接狀態(tài)）

注意：若第三次握手失敗了，此時server的狀態(tài)為syn-rcvd，若等不到客戶端的ACK，server會重新發(fā)送SYN+ACK包，若此時server多次重發(fā)SYN+ACK都等不到客戶端的ACK，就會發(fā)送RST包，強制關(guān)閉連接

連接過程（以http的get請求為例——數(shù)據(jù)部分為4字節(jié)）

注意：這里使用的seq和ack都是相對的

1.首先客戶端開始發(fā)起http的get請求，seq為1（相對于之前建立連接的x）ack為1（相對于之前建立連接的y）含義為期望服務(wù)端開始發(fā)送數(shù)據(jù)；

2.然后服務(wù)器收到請求連續(xù)發(fā)送4個包（之前的連續(xù)arq協(xié)議）

這里面的seq就是發(fā)送的每個數(shù)據(jù)包的起始字節(jié)序號，這里的ack就是希望客戶端開始發(fā)送第k+1個字節(jié)；

3.客戶端收到對方的4個TCP數(shù)據(jù)段，TCP數(shù)據(jù)部分占0字節(jié)，seq標(biāo)識這是發(fā)給服務(wù)端的k+1個字節(jié)，ack標(biāo)識期望服務(wù)端發(fā)送b1+b2+b3+b4+1個字節(jié)

TCP釋放連接四次揮手

前言：

• TCP是全雙工通信
• TCP/IP協(xié)議棧上，允許任何一方發(fā)起斷開連接請求

理解：

1. 數(shù)據(jù)傳輸完成后，客戶機向服務(wù)器發(fā)送釋放連接請求FIN=1，同時隨機生成序列號u
2. 服務(wù)端收到客戶端的請求進(jìn)行確認(rèn)ACK=1，隨機生成序列號seq=v
3. 此時服務(wù)器這邊若也覺得沒有東西可以發(fā)給客戶端，服務(wù)器也會發(fā)釋放連接請求給客戶端（FIN=1）隨機生成序列號w
4. 客戶端收到服務(wù)端的請求對其進(jìn)行確認(rèn)ACK=1（告訴服務(wù)器知道沒有東西發(fā)給自己了）進(jìn)而雙方關(guān)閉連接

為什么釋放連接需要四次揮手

• 第一次揮手：當(dāng)客戶端發(fā)出FIN報文時表示客戶端告訴服務(wù)器，自己已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是還是可以接收到服務(wù)器的數(shù)據(jù)
• 第二次揮手：當(dāng)服務(wù)器返回ACK報文時，表示服務(wù)器已經(jīng)知道客戶端沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器還是可以發(fā)送數(shù)據(jù)到客戶端
• 第三次揮手：當(dāng)服務(wù)器也發(fā)送FIN報文時表示服務(wù)器告訴客戶端，服務(wù)器也沒有數(shù)據(jù)要發(fā)送了
• 第四次揮手：當(dāng)客戶端返回ACK報文時，表示客戶端已經(jīng)知道服務(wù)器沒有數(shù)據(jù)要發(fā)送了，隨后正式斷開整個TCP連接

客戶端發(fā)送ACK報文后需要時間等待原因

若客戶端發(fā)送ACK后馬上釋放了，然后又因為網(wǎng)絡(luò)原因，server沒有收到client的ACK，server就會重發(fā)FIN可能出現(xiàn)以下情況

• client沒有任何響應(yīng)，服務(wù)器那邊會干等，甚至多次重發(fā)FIN，浪費資源
• client剛好有個新應(yīng)用程序，分配了同一個端口號，新應(yīng)用程序收到FIN后馬上開始執(zhí)行斷開連接操作，但是本來他想和服務(wù)器建立連接的

時間等待的確認(rèn)

一般是2倍的MSL（MAXimum Segment Lifetime，最大分段生存周期）MSL是TCP報文在internet上的最大生存時間，每個具體的TCP實現(xiàn)都必須選擇一個確定的MSL值，RFC 1122建議是2分鐘，這樣可以防止本次鏈接中產(chǎn)生的數(shù)據(jù)包誤傳到下一次連接中（因為本次連接中的數(shù)據(jù)包都會在2MSL時間內(nèi)消失）