傳輸層
傳輸層的概述
傳輸層位於應用層和網絡層之間，為運行在不同主機的應用進程提供了邏輯通信。從應用程序的角度看，通過邏輯通信，運行不同進程的主機好像直接相連一樣。
傳輸層協議是在端系統實現而非路由器中實現，在發送端，傳輸層將應用層傳輸來的報文分割成分組，每個分組添加上傳輸層協議的首部，這些分組被稱為報文段，之后，傳輸層把報文段傳遞給網絡層處理，網絡層處理之后再發送出去。
因特網傳輸層協議
- UDP：UDP為應用程序提供了一種不可靠，無連接的服務，UDP無法保證數據完好無缺地交付給接收方。
- TCP：TCP為應用程序提供了一種可靠，面向連接的服務。TCP相對於UDP多了可靠數據傳輸服務、擁塞控制、流量控制等功能。
無連接傳輸：UDP
-
UDP基於IP協議的基礎上，增加了復用/分用、簡單的錯誤校驗的功能。
-
UDP可能發生丟失或亂序問題。
-
UDP發送方和接收方不需要握手，沒有UDP段的處理獨立於其他段。
UDP的優勢
- 無需建立連接
- 實現簡單
- 頭部開銷少
- 沒有擁塞控制機制，應用層可以更好控制流量和傳輸速率
UDP校驗和
目的：檢測報文段是否傳輸過程中發生反轉。
- 校驗和的創建：發送方將報文段的內容視為16-bit整數，將所有整數相加（如果有進位，則將進位數字加到最后）之后按位取反。
- 校驗和的校驗：計算收到的報文段的校驗和，如果和原校驗和進行比對。如果不相等，則出現錯誤；如果相等，代表沒有檢測出錯誤（不代表沒有發生錯誤）。
可靠數據傳輸原理
rdt1.0
底層信道完全可靠，不發生錯誤，不發生丟包。
過程
- 發送方：發送方傳輸層等待上層調用、上層調用之后發送分組。
- 接收方：接收方傳輸層等待下層調用、下層調用之后接受分組交付給上層。
rdt2.0
底層信道可能發生錯誤，但不會發生分組丟失。
過程
-
發送方
- 發送方傳輸層等待上層調用、上層調用之后發送分組。
- 等待接收方發送的ACK或者NAK。
- 當接收到ACK后，發送下一個分組；接收到NAK之后，重新發送該分組。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 接收到分組后，使用校驗和來檢測是否發生錯誤。
- 如果發生錯誤，向發送方發送NAK；如果沒有發生錯誤，向發送方發送ACK，同時將分組交付給上層。
rdt2.1
如果ACK/NAK發生錯誤，則發送方重傳該分組，但會出現重復分組的問題，為了解決重復分組的問題，使用rdt2.1.
過程
-
發送方
- 發送方傳輸層等待上層調用、上層調用之后發送分組，附帶序列號0或1。
- 等待接收方發送的ACK或者NAK。
- 當接收到ACK后，發送下一個分組，如果上一次發送的序列號為1則此次發送0，如果上一次是0則此次發送1；接收到NAK或ACK/NAK發生錯誤之后，重新發送該分組，序列號和上一次一樣。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 接收到分組后，使用校驗和來檢測是否發生錯誤。
- 如果發生錯誤，向發送方發送NAK；如果沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送ACK，同時將分組交付給上層；如果收到的分組與預期的分組序列號不一致，向發送方發送ACK。
-
注：
-
什么是預期的分組序列號？
如果上一次接收方將分組序列號為1的分組交付給上層，則0上它此次預期的分組序列號，如果上一次接收方將分組序列號為0的分組交付給上層，則1上它此次預期的分組序列號。
-
當收到的分組與預期的分組序列號不一致，為何發送ACK？
收到的分組與預期的分組序列號不一致說明發送方發送了重復的分組，且該分組已經被交付給上層，接收方發送ACK目的是告知發送方發送一下個新的分組。
-
rdt2.2
取消掉NAK，在ACK中加入被確認分組的序列號
過程
-
發送方
- 發送方傳輸層等待上層調用、上層調用之后發送分組，附帶序列號0或1。
- 等待接收方發送的ACK或者NAK。
- 當接收到ACK后，發送下一個分組，如果上一次發送的序列號為1則此次發送0，如果上一次是0則此次發送1；接收到與預期序列號不同的ACK或ACK發生錯誤之后，重新發送分組，序列號和上一次一樣。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 接收到分組后，使用校驗和來檢測是否發生錯誤。
- 如果發生錯誤或者收到的分組與預期的分組序列號不一致，向發送方發送和上一次序列號一樣的ACK；如果沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送帶此次序列號ACK，同時將分組交付給上層。
rdt3.0
信道即會發生錯誤，也會丟失分組，添加定時器機制
過程
-
發送方
- 發送方傳輸層等待上層調用、上層調用之后發送分組，附帶序列號0或1，啟動定時器。
- 等待接收方發送的ACK或者NAK。
- 如果超時，則重傳並重啟定時器（此過程可能是分組丟失也可能是ACK丟失）。
- 當接收到預期序列號ACK后，停止計時器，發送下一個分組，啟動定時器，如果上一次發送的序列號為1則此次發送0，如果上一次是0則此次發送1；接收到重復ACK或ACK/NAK發生錯誤之后，什么也不做，繼續等待預期的ACK。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 接收到分組后，使用校驗和來檢測是否發生錯誤。
- 如果發生錯誤或者收到的分組與預期的分組序列號不一致，向發送方發送和上一次序列號一樣的ACK；如果沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送帶此次序列號ACK，同時將分組交付給上層。
流水線機制和滑動窗口
rtd3.0性能較差，所以引入流水線機制。
滑動窗口協議
滑動窗口定義了允許使用的序列號范圍，窗口的尺寸為N，代表最多有N個等待確認的消息。
GBN滑動窗口協議
如圖所示，窗口的左端是已經發送並且得到ACK的分組，窗口內黃色的是已發送但未ACK的分組，綠色是能發送的分組，白色是暫時不可發送的分組。
過程
-
發送方
- 發送方傳輸層等待上層調用
- 如果有窗口中有可用的序列號，則發送分組，並將黃色部分向后移動，如果現在發送的是窗口的第一個序列號，則啟動計時器。
- 如果超時，重發所有黃色的分組。
- 如果收到ACK，該ACK附帶一個序列號為N，將窗口向右移動，移動到N+1。如果此時沒有發出去的分組，則停止計時器，如果已經有發出去的分組，則重啟計時器
- 如果收到錯誤ACK，什么也不做。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 如果序號為n的分組正確且有序到達，則發送序列號為n的ACK。
- 其余情況下，丟棄該分組，並發送最近收到的有序的分組的序列號的ACK
SR協議
接收方能夠緩存亂序分組，所以接收方也有一個滑動窗口。
過程
-
發送方
- 發送方傳輸層等待上層調用
- 如果有窗口中有可用的序列號，則發送分組，並將黃色部分向后移動。對每次發送的分組都開啟一個單獨的計時器
- 如果某個計時器超時，則重發那個分組。
- 如果接收到了ACK，將接收到ACK的分組標記一下，如果該分組是窗口內最小的，將窗口向右滑動。
-
接收方
- 接收方傳輸層等待下層調用、下層調用之后接受分組。
- 如果該分組亂序，則緩存該分組，如果該分組有序到達，則交付上層。
- 發送ACK
面向連接的傳輸：TCP
TCP報文段
序號與確認號
序號與確認號是TCP報文段中最重要的部分，TCP將傳輸的數據看作是字節流，並隱式地為每個字節編號。報文段中的序號便是此次傳輸的數據段的的首字節的字節流編號。確認號是指接收方累積確認過程中最小沒有接受到的序號。
例如，主機A向主機B發送500000字節的數據，TCP將數據分割為500個報文段，每個報文段中含有1000字節的數據，報文段的首序號為0。則第一次發送的報文段的序號為0，第二次為0+1000=1000，第三次為1000+1000=2000。假設第一個報文段到達主機B，主機B就收到了0-1000的數據，這時最小沒有收到的數據為1001，則主機B向主機A發送確認號為1001的報文段。如果主機A發送的第二個報文段丟失而第三個報文段到達主機B，則主機B緩存上第三個報文段，繼續向主機A發送確認號為1001的報文段。如果主機B收到了再次發送的第二個報文段，則將報文段與緩存中的數據拼接，發出確認號為2001的報文段。
冗余ACK
什么時候會出現冗余ACK？
- 亂序：發送方序號大的數據報先於序號小的數據報到達接收方，接收方根據累積確認原則發送最小沒有接收到的序號，這時便會產生冗余ACK。
- 丟包：序號小的數據報丟失，序號大的數據包沒有丟失，這種情況實際上就是亂序。
定時器
何時啟動定時器？
- 當發送報文時沒有定時器啟動時啟動定時器。
- 當超時重傳之后啟動定時器。
- 當收到一個有效確認報文且此時還有未被確認的報文段時啟動定時器。
流量控制
連接的兩端都會維持一個緩存隊列，對發送方發送速率的控制防止其發送的數據超出了接收方的緩存隊列的方法叫做流量控制。
接收窗口用rwnd來表示，接收窗口指的是緩存隊列可用空間的大小，rwnd時動態變化的。接收方通過將rwnd傳遞給發送方來告知發送方還有多少的可用緩存空間。發送方要在整個連接的生命周期中確保未被確認的數據大小小於rwnd的大小。
如果接收方發來rwnd為0之后，接收方沒有要發送的數據了怎么辦？
如果沒有任何額外的機制，那么發送方將不會知道何時接收方的緩存空間有空余，那么發送方將進入阻塞狀態。實際上，發送方會持續發送1字節數據的報文段，如果接收方有空余，則可以發送rwnd不為0的響應報文段。
連接管理
三次握手
- 客戶端發送一個報文段首部SYN比特為1的報文段，該報文段的序號是一個隨機序號client_isn。
- 服務器收到該特殊的報文段后，分配緩存和變量，並向客戶端發送一個報文段首部SYN比特為1、確認號為client_isn+1、序號為隨機序號server_isn的報文段。
- 客戶端收到該特殊的報文段后向服務器發送一個報文段首部SYN比特為0、確認號為server_isn+1的報文段。
為何需要三次握手？
-
為了防止舊的連接使得整個連接造成混亂。
假設客戶端向服務器發起了SYN報文段，之后由於網絡阻塞客戶端遲遲未到達服務端，之后客戶端再次發送SYN報文段，這時，舊的SYN先到達了服務器，服務器認為客戶端想以這個舊的報文段所攜帶的client_isn為序號，實際上這個是舊的報文段，已經不需要，那么客戶端在第三次握手的時候就會告知服務器這個舊的連接終止。
-
從上文可以看出，三次握手是要分配必要的空間和變量，通知另一端一些初始信息如序號。
四次揮手
客戶端和服務器都可以主動斷開連接，假設客戶端主動斷開連接。
過程
- 客戶端發送一個特殊的TCP數據報，該數據包的一個標志為FIN設置為1。
- 服務器接收到該特殊的數據報，向客戶端發送一個確認ACK的數據報。
- 服務器發送一個特殊的TCP數據報，該數據包的一個標志為FIN設置為1。
- 客戶端接收到該特殊的數據報，向服務器發送一個確認ACK的數據報。
- 服務器收到確認數據報后關閉連接。
- 客戶端經過定時等待后關閉連接。
為何需要四次揮手？
客戶端發出FIN，說明客戶端已經沒有了數據想要發送，所以主動斷開連接。服務器即使接收到了FIN數據報，回復了ACK，若是服務器仍然在處理數據，並且還想發送，則它就不想關閉連接，如果服務器無數據要處理和發送了，則服務器也發送FIN數據報。
為何需要定時等待？
數據傳遞過程中，可能有一些應用數據報由於網絡延遲遲遲不送達，定時等待時間為兩倍的報文最大存活時間，經過定時等待時間之后，可以確保此次鏈接即使是延遲的數據報也沒有了，防止本次連接的數據報傳遞給下一次新的連接導致數據混亂。
TCP擁塞控制
控制發送速率
通過網絡的擁塞程度,動態調節擁塞控制窗口.
感知網絡擁塞
- 超時
- 三個ACK
加性增-乘性減
逐漸增加發送速率,當發生loss時,快速降低發送速率.
慢啟動
當連接開始時,可用帶寬可能遠遠高於初始帶寬。所以，當連接開始時，擁塞窗口自1開始指數型增長。
慢啟動轉加性增
定義一個變量Threshold，當感知到擁塞發生時，Threshold設為發生Loss時擁塞窗口的值的一半。
- 發生超時：擁塞窗口降為1，慢啟動。
- 3個重復ACK：擁塞窗口將為原來的一半，加性增。