一、基礎(chǔ)概念

• 服務(wù)對象：進(jìn)程
• 功能：邏輯通訊
• 載體：報文段
• 工作環(huán)境：端系統(tǒng)
• 運輸層協(xié)議
  ??TCP：為進(jìn)程提供可靠的、面向連接的服務(wù)
  ??UDP：為進(jìn)程提供不可靠的、無連接的服務(wù)

二、多路分解與多路復(fù)用

• 多路分解：將運輸層報文中的數(shù)據(jù)交付到正確的套接字(socket)上工作
• 多路復(fù)用：在原主機(jī)從不用套接字中收集數(shù)據(jù)塊，并為每個數(shù)據(jù)塊封裝上首部信息，從而生成報文段，然后將報文段傳遞到網(wǎng)絡(luò)層。
• 運輸層多路復(fù)用要求：
  ??a. 套接字有唯一標(biāo)識符
  ??b. 每個報文段有特殊字段（源端口號字段、目的端口號字段）來指示改報文段所要交付到的套接字
• 運輸層分解服務(wù)實現(xiàn)：
  ??在主機(jī)上的每個套接字能夠分配一個端口號，當(dāng)報文段到達(dá)主機(jī)時，運輸層檢查報文段中的目的端口號，并將其定向到相應(yīng)的套接字
  ??UDP套接字由一個二元組（目的IP地址，目的端口號）來標(biāo)識
  ??TCP套接字由一個四元組（源IP地址，源端口號，目的IP地址，目的端口號）來標(biāo)識

三、可靠數(shù)據(jù)傳輸

1. 可靠數(shù)據(jù)傳輸協(xié)議的要點：檢驗和、序號、定時器、肯定和否定確認(rèn)分組

2. 流水線技術(shù)
   ?1） 含義：不使用停等方式運行，允許發(fā)送方發(fā)送多個分組而無需等待確認(rèn)
   ?2） 對可靠數(shù)據(jù)傳輸協(xié)議帶來的影響：
   ??a. 必須增加序號范圍，因為每個輸送中的分組（不計算重傳的）必須有一個唯一的序號，而且也許有多個在輸送中未確認(rèn)的報文；
   ??b. 協(xié)議的發(fā)送方和接收方兩端也許必須緩存多個分組；
   ??c. 所需序號范圍和對緩沖的要求取決于數(shù)據(jù)傳輸協(xié)議如何處理丟失。損壞及延時過大的分組。
   ?3） 解決流水線的差錯恢復(fù)的兩種基本方法：回退N步 (GBN) 和選擇重傳 (SR)

3. 回退N步 (GNB)
   ? 1） 定義：允許發(fā)送放發(fā)送多個分組而不需要等待確認(rèn)，但在流水線中未確認(rèn)的分組數(shù)不得超過窗口長度N，隨著協(xié)議運行，該窗口的序號空間在向前滑動，所以GBN協(xié)議也被稱為滑動窗口協(xié)議
   ? 2） 發(fā)送方采用動作：
   ?? a. 上層的調(diào)用。發(fā)送方檢查發(fā)送窗口是否已滿，如果未滿則產(chǎn)生分組將其發(fā)送；如果已滿則緩存等待或者通過同步機(jī)制運行上層僅當(dāng)窗口不滿時才被調(diào)用。
   ?? b. 收到一個ACK。GBN采用累積確認(rèn)，表明接收方已經(jīng)收到序號n以及n以前的所有分組。
   ?? c. 超時事件。發(fā)送方重傳所有已發(fā)送但未被確認(rèn)過的分組，如果接收到一個ACK，但仍有已發(fā)送但未被確認(rèn)的分組，則定時器重新啟動。
   ? 3） 接收方采用動作：如果序號為n的分組被正確收到，兵器按序，則接收方為分組n發(fā)送一個ACK，并將分組中的數(shù)據(jù)交付到上層；其他情況，接收方丟棄該分組，并為最近按序接收的分組重新發(fā)送ACK。
   ? 4） 丟棄未按序分組帶來的優(yōu)缺點
   ?? a. 優(yōu)點：接收緩存簡單，即接收方不需要緩存失序分組
   ?? b. 缺點：隨后對該分組的重傳也許會丟失或出錯，因此需要更多的重傳

4. 選擇重傳（SR）
   ? 1） 定義：允許發(fā)送放發(fā)送多個分組而不需要等待確認(rèn)，發(fā)送方僅重傳那些他懷疑接收方出錯的分組而避免面不必要的重傳。
   ? 2） 發(fā)送方采用動作：
   ?? a. 上層的調(diào)用。發(fā)送方檢查發(fā)送窗口是否已滿，如果未滿則產(chǎn)生分組將其發(fā)送；如果已滿則緩存等待或者通過同步機(jī)制運行上層僅當(dāng)窗口不滿時才被調(diào)用。
   ?? b. 超時。每個分組都有一個自己的邏輯定時器，發(fā)生超時只能發(fā)送一個分組。
   ?? c. 收到ACK。如果ACK確認(rèn)的序號等于窗口最左端序號，則窗口向右移動，否則標(biāo)記該組為已收到。
   ? 3） 接收方采用動作
   ?? a. 序號在窗口內(nèi)。發(fā)送ACK，如果第一次接收則緩存（窗口左端如果緩存了則向上交付）
   ?? b. 序號在窗口-N內(nèi)。立刻發(fā)送ACK。
   ?? c. 其它情況。忽略分組

四、面向連接的運輸：TCP

1. TCP報文結(jié)構(gòu)

   
   

2. TCP連接管理

• 三次握手
  ??(1) 第一次握手：建立連接時，客戶端A發(fā)送SYN包[SYN=1,seq=x]到服務(wù)器B，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器B確認(rèn)。
  ??(2) 第二次握手：服務(wù)器B收到SYN包，必須確認(rèn)客戶A的SYN，同時自己也發(fā)送一個SYN包，即SYN+ACK包[SYN=1,ACK=1,seq=y,ack=x+1]，此時服務(wù)器B進(jìn)入SYN_RECV狀態(tài)。
  ??(3) 第三次握手：客戶端A收到服務(wù)器B的SYN＋ACK包，向服務(wù)器B發(fā)送確認(rèn)包ACK[ACK=1,seq=x+1,ack=y+1]，此包發(fā)送完畢，客戶端A和服務(wù)器B進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。 第三次握手可在報文段負(fù)載中攜帶客戶到服務(wù)器的數(shù)據(jù)。三次握手后客戶端與服務(wù)器開始傳送數(shù)據(jù)。

• 四次揮手
  ??(1) 首先A B端的TCP進(jìn)程都處于ESTABLISHED狀態(tài)， 當(dāng)A的應(yīng)用程序傳送完報文段，就會去主動關(guān)閉連接。A會停止發(fā)送報文段（但是還會接收），并向B發(fā)送[FIN = 1,seq=u]數(shù)據(jù)，之后進(jìn)入FIN-WAIT-1狀態(tài)；
  ??(2) B接收到A發(fā)送的請求之后，會通知應(yīng)用進(jìn)程，A已經(jīng)不再發(fā)送數(shù)據(jù)，同時B會向A發(fā)送ACK確認(rèn)數(shù)據(jù)[ACK=1,seq=v,ack=u+1 ]，B進(jìn)入CLOSE-WAIT狀態(tài)，A接收到B發(fā)送的數(shù)據(jù)之后，A進(jìn)入FIN-WAIT-2狀態(tài)；此時A到B方的連接已經(jīng)關(guān)閉了（即半連接狀態(tài)）。
  ??(3) 當(dāng)B的應(yīng)用進(jìn)程發(fā)現(xiàn)自己也沒有數(shù)據(jù)需要傳送，B應(yīng)用進(jìn)程就會發(fā)出被動關(guān)閉的請求，B此時向A發(fā)送[FIN=1,ACK=1,seq=w,ack=u+1]數(shù)據(jù)，并且進(jìn)入LAST-ACK狀態(tài)；
  ??(4) A接收到B發(fā)送的數(shù)據(jù)之后，向B發(fā)送ACK確認(rèn)數(shù)據(jù)[ACK =1,seq=u+1,ack=w+1]，進(jìn)入TIME-WAIT狀態(tài)，等待2MSL之后正常關(guān)閉連接進(jìn)入CLOSED狀態(tài)；B接收到A發(fā)送的確認(rèn)之后進(jìn)入CLOSED狀態(tài)。B到A方的連接關(guān)閉！至此，TCP連接才真正全部關(guān)閉！

• 為什么建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢？
  ??這是因為服務(wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到客戶端的SYN報文的建立連接請求后，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個報文里來發(fā)送。但關(guān)閉連接時，當(dāng)收到對方的FIN報文通知時，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了，所以你可以未必會馬上會關(guān)閉SOCKET，也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報文給對方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的。

• 為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？
  ??這是因為雖然雙方都同意關(guān)閉連接了，而且握手的4個報文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接回到CLOSED狀態(tài)（就好比從SYN_SEND狀態(tài)到 ESTABLISH狀態(tài)那樣）；但是因為我們必須要假想網(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報文會一定被對方收到，因此對方處于 LAST_ACK狀態(tài)下的SOCKET可能會因為超時未收到ACK報文，而重發(fā)FIN報文，所以這個TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的 ACK報文。

3. TCP可靠數(shù)據(jù)傳輸

(1) 上層調(diào)用
??TCP從應(yīng)用程序接收數(shù)據(jù)，將數(shù)據(jù)封裝到一個報文段中，并將改報文段交給IP（每個報文段都包含一個序號）
(2) 超時
??TCP通過重傳引起超時的報文段來相應(yīng)超時時間，然后TCP重啟定時器。
(3) 收到ACK
??TCP采用累計確認(rèn)策略。確認(rèn)序號表示序號前的所有字節(jié)都已經(jīng)正確且按序接收。

• 超時間隔設(shè)定
  ??每次TCP重傳時都會將下一次的超時間隔設(shè)定為先前值的兩倍，這種修改提供了一個形式受限的擁塞控制（在擁塞的時候，如果源持續(xù)重傳分組，會使擁塞更加嚴(yán)重）

• 快速重傳
  ??如果TCP發(fā)送方接收到對相同數(shù)據(jù)的3個冗余ACK（3個冗余ACK = 1個正常ACK + 3 個重復(fù)ACK），它把著當(dāng)作一種指示，說明跟在這個已被確認(rèn)過3次的報文段之后的報文段已經(jīng)丟失，TCP就執(zhí)行快速重傳，即在改報文段的定時器過期之前重傳丟失的報文。

• TCP 差錯恢復(fù)機(jī)制
  ??雖然TCP采用累計確認(rèn)，但是TCP發(fā)生超時事件時重傳至多一個報文段。此外，如果對報文段 n+1 的確認(rèn)報文在報文段 n 超時前到達(dá)，TCP不會重傳報文段 n。因此，TCP的差錯恢復(fù)機(jī)制是GBN和SR協(xié)議的混合體。

• TCP超時重傳舉例
  ??(1) 如果主機(jī) A 向主機(jī) B 發(fā)送一個報文段，當(dāng)超時事件發(fā)生時，A 會重傳相同的報文段
  ??(2) 如果主機(jī) A 向主機(jī) B 發(fā)送兩個報文段，當(dāng)超時事件發(fā)生時（沒有一個確認(rèn)報文到達(dá) A），A 只會重傳第一個報文段，并啟動定時器，如果第二個報文段的ACK在新的超時發(fā)生前到達(dá)，則第二報文段不會被重傳。
  ??(3) 如果主機(jī) A 向主機(jī) B 發(fā)送兩個報文段，如果第一個報文段的ACK在網(wǎng)絡(luò)丟失，但在超時前接收到第二個報文段的確認(rèn)報文，由于TCP采用累積確認(rèn)，所以不會發(fā)生重傳。

• 流量控制
  ??TCP的流量控制是一個速度匹配服務(wù)。通過發(fā)送方維護(hù)一個接收窗口（接收方還有多少緩存空間）的變量來提供流量控制。接收窗口大小 = 接收緩存空間大小 - 緩存中的TCP數(shù)據(jù)大小。
  ??當(dāng)主機(jī)的接收窗口為0時，發(fā)送方會繼續(xù)發(fā)送只有一個字節(jié)數(shù)據(jù)的報文。

• 為什么當(dāng)接收窗口為0時，發(fā)送方仍然繼續(xù)發(fā)送報文？
  ??TCP當(dāng)且僅當(dāng)有數(shù)據(jù)或有確認(rèn)要發(fā)時才會發(fā)送報文段。
  ??A為發(fā)送方，B為接收方。假設(shè)B告知A接收窗口大小為0，且B沒任何數(shù)據(jù)發(fā)送給A。當(dāng)B上的應(yīng)用進(jìn)程將緩存清空，因為B沒有數(shù)據(jù)或者確認(rèn)向A發(fā)送報文段，所以TCP并不會向A發(fā)送帶有接收窗口大小的新報文，導(dǎo)致A不可能知道B中有新的空間，即A被阻塞而不能再發(fā)送給數(shù)據(jù)。

五、TCP擁塞控制

• TCP采用的方法：讓每一個發(fā)送方根據(jù)所感知到的網(wǎng)絡(luò)擁塞程度來限制其能向鏈接發(fā)送流量的速率。

• TCP發(fā)送方如何限制它發(fā)送流量的速率？
  ??運行在發(fā)送方的TCP擁塞控制機(jī)制跟蹤一個額外的變量——擁塞窗口，在發(fā)送方未確認(rèn)的數(shù)據(jù)量不得超過擁塞窗口與接收窗口的最小值（間接地限制發(fā)送方的發(fā)送速率）。
  ??發(fā)送速率 = 發(fā)送數(shù)據(jù)量（未確認(rèn)數(shù)據(jù)流） / 往返時間，通過調(diào)節(jié)擁塞窗口可以達(dá)到調(diào)整發(fā)送方發(fā)送數(shù)據(jù)的速率。

• TCP如何感知它到目的地之間的路徑是否擁塞？
  ??TCP發(fā)送方的“丟包事件”定義為：要么出現(xiàn)超時，要么收到來自接收方的3個冗余ACK。當(dāng)出現(xiàn)過度的擁塞時，在沿著這條路徑上的一臺或多臺路由器的緩存會溢出，引起數(shù)據(jù)包（含TCP報文段）被丟棄。被丟棄的數(shù)據(jù)包會引發(fā)發(fā)送方的丟包時間（超時或者收到3個冗余ACK），發(fā)送方就會認(rèn)為在發(fā)送方到接收方的路徑上出現(xiàn)了擁塞的指示。

• TCP發(fā)送方如何確定發(fā)送速率？
  ??(1) 當(dāng)發(fā)生丟失報文段時應(yīng)當(dāng)降低TCP發(fā)送方的速率（減少擁塞窗口的長度）
  ??(2) 當(dāng)對先前未確認(rèn)報文段的確認(rèn)到達(dá)時，增加發(fā)送方速率（增加擁塞窗口的長度）
  ??(3) 帶寬探測。

• TCP擁塞控制算法
  慢啟動算法
  ??1) 連接建好的開始先初始化擁塞窗口cwnd大小為1，表明可以傳一個MSS大小的數(shù)據(jù)。
  ??2) 每當(dāng)收到一個ACK，cwnd大小加一，呈線性上升。
  ??3) 每當(dāng)過了一個往返延遲時間RTT(Round-Trip Time)，cwnd大小直接翻倍，乘以2，呈指數(shù)讓升。
  ??4) 還有一個ssthresh（slow start threshold），是一個上限，當(dāng)cwnd >= ssthresh時，就會進(jìn)入“擁塞避免算法”
  擁塞避免算法
  ??1) 收到一個ACK，則cwnd = cwnd + 1 / cwnd
  ??2) 每當(dāng)過了一個往返延遲時間RTT，cwnd大小加一。
  擁塞狀態(tài)時的算法
  ??1) 更改cwnd和ssthresh為原有cwnd的一半
  ??2) 然后進(jìn)入快速恢復(fù)算法Fast Recovery。
  快速恢復(fù)
  ??1) cwnd = cwnd + 3 * MSS，加3 * MSS的原因是因為收到3個重復(fù)的ACK。
  ??2) 重傳DACKs指定的數(shù)據(jù)包。
  ??3) 如果再收到DACKs，那么cwnd大小增加一。
  ??4) 如果收到新的ACK，表明重傳的包成功了，那么退出快速恢復(fù)算法。將cwnd設(shè)置為ssthresh，然后進(jìn)入擁塞避免算法。

六、無連接的服務(wù)UDP

• 定義：在IP協(xié)議上，添加復(fù)用/分解功能以及少量的差錯檢測。發(fā)送放和接收方的運輸層實體之間沒有握手，所以被稱為是無連接的。

• 使用UDP優(yōu)勢
  ??1) 能夠為應(yīng)用層更精細(xì)控制（時間及數(shù)據(jù)類型）。只要應(yīng)用進(jìn)程將數(shù)據(jù)傳遞給UDP，UDP就會將數(shù)據(jù)打包進(jìn)UDP報文段并立刻傳遞給網(wǎng)絡(luò)層。TCP由于可靠傳輸、擁塞控制機(jī)制等，可能會導(dǎo)致報文段傳送的延遲。當(dāng)實時應(yīng)用要求最小的發(fā)送速率、不希望過分地延遲報文段的發(fā)送，且容忍一些數(shù)據(jù)的丟失，UDP更為適用。
  ??2) 無需連接建立。UDP不需要任何準(zhǔn)備就能進(jìn)行數(shù)據(jù)傳輸，所以UDP不會引入建立連接的時延。
  ??3) 無連接狀態(tài)。TCP需要在段端系統(tǒng)中維護(hù)連接狀態(tài)（接收和發(fā)送緩存、擁塞控制參數(shù)以及序號與確定號等參數(shù)），由于UDP是無連接狀態(tài)所以不需要維護(hù)也不需要跟蹤這些參數(shù)。所以在某些專門應(yīng)用于特定應(yīng)用的服務(wù)器，當(dāng)應(yīng)用程序運行在UDP而非TCP上時，能夠支持更多的活躍用戶。
  ??4) 分組首部開銷小。TCP報文段需要20字節(jié)的首部開銷，而UDP僅需要8字節(jié)。

• UDP的弊端
  ??UDP中缺乏擁塞控制能夠?qū)е耈DP發(fā)送方和接收方之間的高丟包率，并擠垮了TCP會話，這是一個潛在的嚴(yán)重問題。

• 流行的因特網(wǎng)應(yīng)用及其下面的運輸協(xié)議