計算機網絡之傳輸層

傳輸層

傳輸層的概述

​ 傳輸層位於應用層和網絡層之間，爲運行在不一樣主機的應用進程提供了邏輯通訊。從應用程序的角度看，經過邏輯通訊，運行不一樣進程的主機好像直接相連同樣。

​ 傳輸層協議是在端系統實現而非路由器中實現，在發送端，傳輸層將應用層傳輸來的報文分割成分組，每一個分組添加上傳輸層協議的首部，這些分組被稱爲報文段，以後，傳輸層把報文段傳遞給網絡層處理，網絡層處理以後再發送出去。

因特網傳輸層協議

• UDP：UDP爲應用程序提供了一種不可靠，無鏈接的服務，UDP沒法保證數據無缺完好地交付給接收方。
• TCP：TCP爲應用程序提供了一種可靠，面向鏈接的服務。TCP相對於UDP多了可靠數據傳輸服務、擁塞控制、流量控制等功能。

無鏈接傳輸：UDP

• UDP基於IP協議的基礎上，增長了複用/分用、簡單的錯誤校驗的功能。

• UDP可能發生丟失或亂序問題。

• UDP發送方和接收方不須要握手，沒有UDP段的處理獨立於其餘段。

UDP的優點

• 無需創建鏈接
• 實現簡單
• 頭部開銷少
• 沒有擁塞控制機制，應用層能夠更好控制流量和傳輸速率

UDP校驗和

​ 目的：檢測報文段是否傳輸過程當中發生反轉。

• 校驗和的建立：發送方將報文段的內容視爲16-bit整數，將全部整數相加（若是有進位，則將進位數字加到最後）以後按位取反。
• 校驗和的校驗：計算收到的報文段的校驗和，若是和原校驗和進行比對。若是不相等，則出現錯誤；若是相等，表明沒有檢測出錯誤（不表明沒有發生錯誤）。

可靠數據傳輸原理

rdt1.0

​ 底層信道徹底可靠，不發生錯誤，不發生丟包。

過程

• 發送方：發送方傳輸層等待上層調用、上層調用以後發送分組。
• 接收方：接收方傳輸層等待下層調用、下層調用以後接受分組交付給上層。

rdt2.0

​ 底層信道可能發生錯誤，但不會發生分組丟失。

過程

• 發送方

  1. 發送方傳輸層等待上層調用、上層調用以後發送分組。
  2. 等待接收方發送的ACK或者NAK。
  3. 當接收到ACK後，發送下一個分組；接收到NAK以後，從新發送該分組。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 接收到分組後，使用校驗和來檢測是否發生錯誤。
  3. 若是發生錯誤，向發送方發送NAK；若是沒有發生錯誤，向發送方發送ACK，同時將分組交付給上層。

rdt2.1

​ 若是ACK/NAK發生錯誤，則發送方重傳該分組，但會出現重複分組的問題，爲了解決重複分組的問題，使用rdt2.1.

過程

• 發送方

  1. 發送方傳輸層等待上層調用、上層調用以後發送分組，附帶序列號0或1。
  2. 等待接收方發送的ACK或者NAK。
  3. 當接收到ACK後，發送下一個分組，若是上一次發送的序列號爲1則這次發送0，若是上一次是0則這次發送1；接收到NAK或ACK/NAK發生錯誤以後，從新發送該分組，序列號和上一次同樣。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 接收到分組後，使用校驗和來檢測是否發生錯誤。
  3. 若是發生錯誤，向發送方發送NAK；若是沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送ACK，同時將分組交付給上層；若是收到的分組與預期的分組序列號不一致，向發送方發送ACK。

• 注：

  1. 什麼是預期的分組序列號？

     若是上一次接收方將分組序列號爲1的分組交付給上層，則0上它這次預期的分組序列號，若是上一次接收方將分組序列號爲0的分組交付給上層，則1上它這次預期的分組序列號。

  2. 當收到的分組與預期的分組序列號不一致，爲什麼發送ACK？

     收到的分組與預期的分組序列號不一致說明發送方發送了重複的分組，且該分組已經被交付給上層，接收方發送ACK目的是告知發送方發送一下個新的分組。

rdt2.2

​ 取消掉NAK，在ACK中加入被確認分組的序列號

過程

• 發送方

  1. 發送方傳輸層等待上層調用、上層調用以後發送分組，附帶序列號0或1。
  2. 等待接收方發送的ACK或者NAK。
  3. 當接收到ACK後，發送下一個分組，若是上一次發送的序列號爲1則這次發送0，若是上一次是0則這次發送1；接收到與預期序列號不一樣的ACK或ACK發生錯誤以後，從新發送分組，序列號和上一次同樣。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 接收到分組後，使用校驗和來檢測是否發生錯誤。
  3. 若是發生錯誤或者收到的分組與預期的分組序列號不一致，向發送方發送和上一次序列號同樣的ACK；若是沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送帶這次序列號ACK，同時將分組交付給上層。

rdt3.0

​ 信道即會發生錯誤，也會丟失分組，添加定時器機制

過程

• 發送方

  1. 發送方傳輸層等待上層調用、上層調用以後發送分組，附帶序列號0或1，啓動定時器。
  2. 等待接收方發送的ACK或者NAK。
  3. 若是超時，則重傳並重啓定時器（此過程多是分組丟失也多是ACK丟失）。
  4. 當接收到預期序列號ACK後，中止計時器，發送下一個分組，啓動定時器，若是上一次發送的序列號爲1則這次發送0，若是上一次是0則這次發送1；接收到重複ACK或ACK/NAK發生錯誤以後，什麼也不作，繼續等待預期的ACK。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 接收到分組後，使用校驗和來檢測是否發生錯誤。
  3. 若是發生錯誤或者收到的分組與預期的分組序列號不一致，向發送方發送和上一次序列號同樣的ACK；若是沒有發生錯誤且收到的分組與預期的分組序列號一致，向發送方發送帶這次序列號ACK，同時將分組交付給上層。

流水線機制和滑動窗口

​ rtd3.0性能較差，因此引入流水線機制。

滑動窗口協議

​ 滑動窗口定義了容許使用的序列號範圍，窗口的尺寸爲N，表明最多有N個等待確認的消息。

GBN滑動窗口協議

​ 如圖所示，窗口的左端是已經發送而且獲得ACK的分組，窗口內黃色的是已發送但未ACK的分組，綠色是能發送的分組，白色是暫時不可發送的分組。

過程

• 發送方

  1. 發送方傳輸層等待上層調用
  2. 若是有窗口中有可用的序列號，則發送分組，並將黃色部分向後移動，若是如今發送的是窗口的第一個序列號，則啓動計時器。
  3. 若是超時，重發全部黃色的分組。
  4. 若是收到ACK，該ACK附帶一個序列號爲N，將窗口向右移動，移動到N+1。若是此時沒有發出去的分組，則中止計時器，若是已經有發出去的分組，則重啓計時器
  5. 若是收到錯誤ACK，什麼也不作。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 若是序號爲n的分組正確且有序到達，則發送序列號爲n的ACK。
  3. 其他狀況下，丟棄該分組，併發送最近收到的有序的分組的序列號的ACK

SR協議

​ 接收方可以緩存亂序分組，因此接收方也有一個滑動窗口。

過程

• 發送方

  1. 發送方傳輸層等待上層調用
  2. 若是有窗口中有可用的序列號，則發送分組，並將黃色部分向後移動。對每次發送的分組都開啓一個單獨的計時器
  3. 若是某個計時器超時，則重發那個分組。
  4. 若是接收到了ACK，將接收到ACK的分組標記一下，若是該分組是窗口內最小的，將窗口向右滑動。

• 接收方

  1. 接收方傳輸層等待下層調用、下層調用以後接受分組。
  2. 若是該分組亂序，則緩存該分組，若是該分組有序到達，則交付上層。
  3. 發送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的響應報文段。

鏈接管理

三次握手

1. 客戶端發送一個報文段首部SYN比特爲1的報文段，該報文段的序號是一個隨機序號client_isn。
2. 服務器收到該特殊的報文段後，分配緩存和變量，並向客戶端發送一個報文段首部SYN比特爲一、確認號爲client_isn+一、序號爲隨機序號server_isn的報文段。
3. 客戶端收到該特殊的報文段後向服務器發送一個報文段首部SYN比特爲0、確認號爲server_isn+1的報文段。

爲什麼須要三次握手？

1. 爲了防止舊的鏈接使得整個鏈接形成混亂。

   假設客戶端向服務器發起了SYN報文段，以後因爲網絡阻塞客戶端遲遲未到達服務端，以後客戶端再次發送SYN報文段，這時，舊的SYN先到達了服務器，服務器認爲客戶端想以這個舊的報文段所攜帶的client_isn爲序號，實際上這個是舊的報文段，已經不須要，那麼客戶端在第三次握手的時候就會告知服務器這個舊的鏈接終止。

2. 從上文能夠看出，三次握手是要分配必要的空間和變量，通知另外一端一些初始信息如序號。

四次揮手

客戶端和服務器均可以主動斷開鏈接，假設客戶端主動斷開鏈接。

過程

1. 客戶端發送一個特殊的TCP數據報，該數據包的一個標誌爲FIN設置爲1。
2. 服務器接收到該特殊的數據報，向客戶端發送一個確認ACK的數據報。
3. 服務器發送一個特殊的TCP數據報，該數據包的一個標誌爲FIN設置爲1。
4. 客戶端接收到該特殊的數據報，向服務器發送一個確認ACK的數據報。
5. 服務器收到確認數據報後關閉鏈接。
6. 客戶端通過定時等待後關閉鏈接。

爲什麼須要四次揮手？

客戶端發出FIN，說明客戶端已經沒有了數據想要發送，因此主動斷開鏈接。服務器即便接收到了FIN數據報，回覆了ACK，如果服務器仍然在處理數據，而且還想發送，則它就不想關閉鏈接，若是服務器無數據要處理和發送了，則服務器也發送FIN數據報。

爲什麼須要定時等待？

數據傳遞過程當中，可能有一些應用數據報因爲網絡延遲遲遲不送達，定時等待時間爲兩倍的報文最大存活時間，通過定時等待時間以後，能夠確保這次連接即便是延遲的數據報也沒有了，防止本次鏈接的數據報傳遞給下一次新的鏈接致使數據混亂。

TCP擁塞控制

控制發送速率

​ 經過網絡的擁塞程度,動態調節擁塞控制窗口.

感知網絡擁塞

• 超時
• 三個ACK

加性增-乘性減

​ 逐漸增長髮送速率,當發生loss時,快速下降發送速率.

慢啓動

​ 當鏈接開始時,可用帶寬可能遠遠高於初始帶寬。因此，當鏈接開始時，擁塞窗口自1開始指數型增加。

慢啓動轉加性增

​ 定義一個變量Threshold，當感知到擁塞發生時，Threshold設爲發生Loss時擁塞窗口的值的一半。

• 發生超時：擁塞窗口降爲1，慢啓動。
• 3個重複ACK：擁塞窗口將爲原來的一半，加性增。