計算機網絡讀書筆記(三)

運輸層

傳輸層位與應用層和網絡層之間，是分層的網絡體系結構的重要部分。該層為運作在不同主機上的應用程序提供直接的通信服務起着至關重要的作用。

一. 概述和運輸層服務

運輸層協定為運作在不同主機上的應用程式之間提供了邏輯通信功能。從應用程式的角度看，通過邏輯通信，運作不同程序的主機好像直接相連一樣，實際上，這些主機是通過很多路由器及不同類型的鍊路相連，也就是說，對于運輸層而言，他起到的作用是程序與程序之間的通信。

在發送端，運輸層将從發送應用程式程序接收到的封包轉化成運輸層分組，該分組稱為運輸層封包段。實作的方法可能是将應用封包劃分為較小的塊，并為每塊加上一個運輸層首部以生成運輸層封包段。然後在發送端系統中，運輸層将這些封包段傳遞給網絡層，網絡層将其封裝成網絡層分組(即資料報)并向目的地發送。網絡路由器僅将其作用于該資料報的網絡層字段，即他們不檢查封裝在該資料報的運輸層封包段的字段。在接收端，網絡層從資料報中提取運輸層封包段，并為該封包段向上交給運輸層。運輸層則處理接收到的封包段，使該封包段中的資料為接收應用程序使用。

網絡應用可以使用多種傳輸層協定，網際網路有兩種傳輸層協定，即TCP和UDP，不同的傳輸層協定提供不同的運輸層服務。

1.1.1 運輸層和網絡層的關系

在協定棧中，運輸層剛好為于網絡層之上。網絡層提供了主機之間的邏輯通信，而運輸層為運作在不同主機上的程序之間提供了邏輯通信。

運輸層協定隻工作在端系統中。在端系統中，傳輸層協定将來自應用程序的封包移動到網絡邊緣即網絡層，反過來也從網絡層接收這些封包段；傳輸層對封包段如何在網絡核心傳輸并不做幹涉；事實上中間路由器既不處理也不識别傳輸層加載應用層封包上的任何資訊

運輸層協定能提供的服務常常受制于底層網絡層協定的服務類型，如果網絡層協定無法為主機之間的通信提供時延和帶寬保證的話，運輸層協定也就無法為程序之間發送的應用程式封包提供時延或者帶寬保證.

然而即使底層網絡協定不能在網絡層提供響應的服務，運輸層協定也能提供某些服務。例如，即使底層網絡協定是不可靠的，運輸協定也能為應用程式提供可抗的資料傳輸服務。

1.1.2 網際網路運輸層概述

網際網路為應用層提供了兩種截然不同的可用傳輸層協定。這些協定一種是UDP（使用者資料報協定），它為調用它的應用程式提供了一種不可靠、無連接配接的服務。另一種是TCP（傳輸控制協定），它為調用它的應用程式提供了一種可靠的、面向連接配接的服務。

網際網路網絡層協定有一個名字叫IP協定，即網際協定。IP為主機之間提供了邏輯通信。IP的服務模型是盡力而為傳遞服務。這意味這IP盡它最大努力在通信的主機之間傳遞封包段，但他不并不做任何確定。它不確定封包段的傳遞，不保證封包段的按序傳遞，不保證封包段中資料的完整性，由此，IP被稱為不可靠服務。

UDP和TCP的最基本的責任是，将兩個端系統間IP的傳遞服務擴充為運作在端系統上的兩個程序之間的傳遞服務。将主機間傳遞擴充到程序間傳遞被稱為運輸層的多路複用與多路分解。UDP和TCP還可以通過在其封包段首部中包括差錯檢查字段而提供完整性檢查。程序到程序的資料傳遞和差錯檢查是兩種最低限度的運輸層服務，也是UDP所能提供的僅有的兩種服務。UDP也是一種不可靠的服務。

TCP為應用程式提供了幾種附加服務。首先，它提供可靠資料傳輸。通過流量控制、序号、确認和定時器，TCP確定正确地，按序地将資料從發送程序傳遞給接收程序，這樣，TCP就将兩個端系統之間的不可靠IP服務轉化成一種程序間的可靠資料傳輸服務。TCP還提供擁塞控制，可以防止任何一條TCP連接配接用過多流量來淹沒通信主機之間的鍊路和交換裝置。

二. 多路複用與多路分解

有前面的介紹，我們可以知道，傳輸層将網絡層提供的面向主機的邏輯通信擴充為面向不同應用程序的邏輯通信，并且這一過程稱為多路複用和多路分解；值得注意的是，多路複用和多路分解是每個計算機網絡都需要的。

在目的主機，運輸層從緊鄰其下的網絡層接收封包段。運輸層負責将這些封包段中的資料傳遞給主機上運作的适當應用程式程序。一個程序有一個或多個套接字，它相當于從網絡向程序傳遞資料和從程序向網路傳遞資料的門戶。是以，在接收主機中的運輸層實際上并沒有直接将資料傳遞給程序，而是将資料傳遞給了中間的一個套接字。由于每個套接字都有唯一的辨別符(此辨別符稱為端口号，端口号大小在0-65535之間，其中0-1023屬于周知端口号，它們為特定的Socket而擁有)，辨別符的格式決定它是UDP還是TCP套接字，是以由此可以區分是傳遞給哪個程序。

傳輸層從同一台主機上的不同Socket接收資料的過程稱為多路複用；傳輸層向同一台主機上的不同Socket傳輸資料的過程稱為多路分解；為了實作多路複用和多路分解，我們需要标志套接字，并将相關資訊添加到封包段中。

在發送方主機多路複用：

從多個套接字接收來自多個程序的封包，根據套接字對應的IP位址和端口号等資訊對封包段用頭部加以封裝(該頭部資訊用于之後的解複用)。

在接收方主機多路解複用：

根據封包段的頭部資訊中的IP位址和端口号，将接收到的封包段發送給正确的套接字。

1. 無連接配接的多路複用與多路分解

   一個UDP套接字是由一個二進制組全面辨別的，該二進制組包含一個目的IP位址和一個目的端口号。是以，如果兩個UDP封包段有不同的源IP位址和/或源端口号，但具有相同的目的IP位址和目的端口号，那麼這兩個封包段将通過相同的目的套接字被定向到相同的目的程序。

2. 面向連接配接的多路複用與多路分解

   TCP套接字是由一個四元組(源IP位址，源端口号，目的IP位址，目的端口号)來辨別的。是以，當一個TCP封包段從網路到達一台主機時，該主機使用全部4個值來将封包段定向(分解)到相應的套接字。特别與UDP不同的是，兩個具有不同源IP位址或源端口号的到達TCP封包段将被定向到兩個不同的套接字，除非TCP封包段攜帶了初始建立連接配接的請求。

   在TCP中，存在一個歡迎套接字，他在某一個端口上等待TCP用戶端的連接配接請求，假如接收到一個連接配接請求後，對應的伺服器程序就會建立一個新的套接字。

   當一個TCP封包段到達主機時，所有四個字段被用來将封包段定向(分解)到相應的套接字。

三.無連接配接運輸：UDP

UDP從應用程式得到資料，附加上用于多路複用/分解服務的源和目的端口号字段，以及兩個其他的小字段，然後将形成的封包段交給網絡層。網絡層将該運輸層封包段封裝到一個IP資料報中，然後盡力而為地嘗試将此封包段傳遞給接收主機。如果封包段到達接收主機，UDP使用目的地端口号将封包段中的資料傳遞給正确的應用程序。在使用UDP時，在發送封包段之前，發送方和接收方的運輸層實體之間沒有握手，是以，UDP被稱為是無連接配接的。

既然TCP提供了可靠資料傳輸，并且提供了擁塞控制，為什麼人們還需UDP呢？事實上，有些應用很适合UDP（因為沒有連接配接過程，不會受擁塞控制的調節）；UDP有以下好處：

• 關于何時、發送什麼資料的應用層控制更為精細：這是因為一旦應用程式将資料交給UDP，UDP就會打包将其發送給網絡層，不會受到傳輸層的調節，這在一些實時應用中比較實用；當然，應用程式還可以通過UDP+自主開發一些功能的模式來擴充UDP。
• 無需建立連接配接：是以就不會引入額外的時延。這也可能是DNS使用UDP而不是TCP的主要原因，如果使用TCP的話，DNS服務将會慢很多；HTTP使用TCP的主要原因是對TCP的可靠性的依賴超過對速度的要求；
• 無需維護連接配接狀态：TCP為了實作可靠資料傳輸和擁塞控制需要在端系統中維護一些參數，這些參數包括：接收和發送的緩存、擁塞控制參數、确認号和序号；這些參數資訊都是必須的；而UDP因為不建立連接配接，是以自然也就不需要維護這些狀态，這就減少了時空開銷；
• 分組首部更小：TCP有20位元組的首部開銷，而UDP隻有8位元組；

這些應用程式使用了TCP作為其傳輸層協定：電子郵件、遠端終端通路、Web、檔案傳輸；這些應用通常使用UDP作為其傳輸層協定：遠端檔案伺服器、網絡管理（因為這裡應用即便在網絡處于擁塞的情況下仍要工作，是以UDP更為合适）、路由選擇協定和名稱轉換（DNS）；這些應用兩個都有使用：流式多媒體、網際網路電話等多媒體應用；這些應用對實時性的要求較高同時對可靠性的要求又不是很高，是以既可以使用UDP也可以使用TCP協定。

不過在UDP之上運作多媒體應用是有争議的，因為UDP沒有擁塞控制協定，是以其對網絡有很大的威脅性：大量的UDP流量将使網絡過度擁塞而造成TCP連接配接幾乎無法傳輸資料，并且因為網絡擁塞，是以應用又有着較高的丢包率，而因為丢包率UDP很有可能繼續發送資料，由此使得網絡效率低下。也有研究人員提出一些新的機制，使得所有資料源，包括UDP源執行自适應的擁塞控制來解決這一問題；

需要注意的是，使用UDP仍然可以實作可靠資料傳輸，隻不過這一部分功能需要在應用程式中自主開發；将可靠性直接建構于應用程式中。将使其既可以可靠地傳輸資料又可以避免受制于TCP的擁塞控制（傳輸速率的控制）

3.1 UDP封包段結構

UDP首部隻有4個字段(源端口号、目的端口号、長度、校驗和)，每個字段由兩個位元組組成。通過端口号可以使目的主機将應用資料交給運作在目的端系統中的相應程序。長度字段訓示了在UDP封包段中的位元組數(首部加資料)。因為資料字段的長度在一個UDP段中不同于在另一個段中，是以需要有一個明确的長度。接收方使用檢驗和來檢查在該封包段中是否出現了差錯。

3.2 UDP校驗和

UDP檢驗和提供了差錯檢測功能。校驗和用于确定當UDP封包段從源到達目的地移動時，其中的比特是否發生了改變。發送方的UDP對封包段中的所有16比特字的和進行反碼運算，求和時遇到的任何移除都被回卷(将進位加到最低位)。

發送方：

①将封包段的内容視為16比特的整數

②校驗和：封包段的加法和（1的補運算）

③發送方将校驗和放在UDP的檢驗和字段

接收方:

①計算接收到的封包段的校驗和

②檢查計算出的校驗和與校驗和字段的内容是否相等，不等一定有錯，相等可能有錯。

UDP作為傳輸層協定，提供的差錯檢測功能很有可能和底層協定提供的相似功能産生備援；但是，這是必須的，因為由于不能保證源和目的地之間所有鍊路都提供差錯檢測功能，即便資料在鍊路上正确傳輸，也無法保證其在中間路由器的記憶體中不發生錯誤；是以要實作端到端的差錯檢測，就必須在傳輸層協定中實作該功能；這一原則在系統設計中被稱為端到端原則：“因為某一功能必須在端到端實作，與在較高層次提供這些功能的代價相比，在較低層次上設定的功能可能是備援的，或者根本是沒有用的”。IP作為網絡層協定，可以運作在任何第二層協定上，是以運輸層提供差錯檢測也是必須的；UDP可以檢測差錯，但是無法恢複差錯，能做的除了将其丢棄外，便是将其交給應用程式然後給出警告。

四.可靠資料傳輸原理

可靠資料傳輸為上層提供的服務抽象是：資料可以通過一條可靠的信道進行傳輸。借助于可靠信道，傳輸資料比特就不會收到損壞或丢失，而且所有資料都是按照其發送順序進行傳遞。實作這種服務抽象是可靠資料傳輸協定的責任。

在可靠的資料傳輸下，我們将：

1. 漸增式地開發可靠資料協定的發送方和接收方
2. 隻考慮單向資料傳輸，雙向的資料傳輸問題實際上是兩個單向資料傳輸問題的綜合
3. 使用有限狀态機(FSM)來描述發送方和接收方。

4.1 經完全可靠信道的可靠資料傳輸: rdt1.0

首先我們假設底層信道是完全可靠的，即分組在底層信道傳輸時，沒有比特出錯，沒有分組丢失；發送方的資料将資料送到下層信道，接收方從下層信道接收資料。

因為有了完全可靠的信道，是以無需考慮出現差錯，此時就不需要任何回饋資訊。

4.2.經具有比特差錯信道的可靠資料傳輸：rdt2.x

rdt2.0：

底層信道更為實際的模型是分組中的比特可能受損的模型。在實際生活中，我們在交流時，通常會要求對方在得到資訊後發出一個肯定确認與否定确認。這些确認可以讓發送方知道接收方知道哪些内容被正确洗手，哪些内容接收有誤并需要重複發送。在計算機網絡環境中，基于這樣的重傳機制的可靠資料傳輸協定稱為自動重傳請求協定(ARQ)。

ARQ協定還需要另外三種協定功能來處理存在比特差錯的情況：

①. 差錯檢測：首先，需要一種機制以使接收方檢測到何時出現了比特差錯。這時需要有額外的比特從發送發發送到接收方，這些比特将被彙集在rdt2.0資料分組的分組檢驗和字段中。

② . 接收方回報：發送方想要了解接收方是否正确接收分組，唯一的途徑就是讓接收方提供明确的回報資訊給發送方。即肯定确認(ACK)和否定确認(NAK)。這些分組理論上僅僅需要一個比特長，用0表示NAK，用1表示ACK。

③. 重傳：接收方收到有差錯的分組時，發送方将重傳該分組文。

注：當發送方處于等待ACK或NAK的狀态時，它不能從上層獲得更多的資料，也就是說rdt_send()事件不可能出現；僅當接收到ACK并離開該狀态時才能發生這樣的事件。是以，發送發将不會發送一塊新資料，除非發送方确信接受方已正确接收目前分組，是以，rdt2.0協定又被稱為停等協定。

rdt2.1：

但是此時還有一個緻命的問題，假如我們的ACK或NAK分組受損該怎麼處理！

處理ACK或NAK受損時的三種情況：

①.無法識别對方傳回的确認資訊，即無法分别傳回的是ACK或NAK中的哪一種，此時，發送方将複述其回答，然後發送至接收方，但是中途可能還會出現錯誤，是以此方法十分困難。

②.增加足夠的檢驗和比特，使得發送方不僅可以檢測差錯，還可以回複差錯，對于會産生差錯但是不丢失分組的信道，這就可以直接解決問題。

③.當收到含糊不清的ACK或者NAK時，隻需要重傳目前資料分組即可，然後這種方法在發送發到接收方的信道中引入了備援分組。但是 因為備援分組的存在，接收方不知道它所發送的ACK或NAK是否被發送方正确收到。

解決此問題的一個簡單辦法，就是在資料分組中添加一個信字段，讓發送方對其資料分組編号，即将發送資料分組的序号放在該字段，此時，接收方隻需要檢查序号即可确定收到的分組是否一次重傳。

rdt2.2：

當接收到失序的分組時候，接收方對所接收的分組發送一個肯定确認。如果收到受損的分組，則接收方将發送一個否定确認。如果不發送NAK，而是對上次正确接收的分組發送一個ACK，我們也能實作與NAK一樣的效果(很好了解，比如說你給我依次發送兩個，當發送完第二個封包後，我對你說你的第一個封包發送完畢了，那不就意思是你的第二個封包有問題要重新發送嘛)。發送方接收到對同一個分組的兩個ACK(即接收備援ACK)後，就知道接收方沒有正确收到跟在被确認兩次的分組後面的分組。

rdt2.2是在有比特差錯信道上實作的一個無NAK的可靠資料傳輸協定。rdt2.1和rdt2.2之間的變化在于：接收方此時必須包括由一個ACK封包所确認的分組序号(這可以通過在接收方FSM中，在make_pkt()中包括參數ACK 0或ACK 1來實作)，發送方此時必須檢查接收到的ACK封包中被确認的分組序号。

4.3 經具有比特差錯的丢包信道的可靠資料傳輸：rdt3.0

現在假定除了比特受損外，還存在底層信道會丢包，協定此時就需要關注：怎樣檢測丢包以及丢包後該怎麼辦。在之前的rdt2.x中我們通過校驗和、序号、ACK分組和重傳機制等來解決第二個問題，對于第一個問題，我們使用如下方法。

我們假設發送方傳輸了一個資料分組，該分組或者接收方對該分組的ACK發生了丢失，那麼此時發送方都收不到應當到來的接收方的響應，如果發送發願意等待足夠長的時間以便确認分組丢失，那麼它隻需要重傳該資料分組即可，下面我們要做的就是确認等待時間。

我們認為，發送方至少等待這樣長的時間：即發送方與接收方之間的一個往返時延加上接收方處理一個分組所需要的時間。如果在這個時間内沒有收到ACK請求，就重傳該分組(逾時重傳機制).但是也有可能分組經曆了一個特别大的時延，發送發可能會重傳該分組，即使該分組及ACK都沒有丢失，那麼就會引入備援資料分組，我們此時可以通過rdt2.2中的序号來處理備援分組情況。為了實作基于時間的重傳機制，需要一個倒計數定時器，在一個給定的時間量過期後，可中斷發送方。

因為分組序号在0和1之間交替，是以rdt3.0有時被稱為比特交替協定。

4.4 流水線可靠資料傳輸

rdt3.0雖然功能正确，但是在高速網絡下性能太低，因為他是一個停等協定。

解決性能問題最直接的方法：不以停等方式運作，允許發送方發送多個分組而無需等待确認。因為許多從發送方向接收接受方輸送的分組可以被看成是填充到一條流水線，故這種技術被稱為流水線。

要使用流水線模式，必須滿足下面條件：

• 必須增加序号範圍，因為每個輸送中的分組(不計算重傳的)必須有一個唯一的序号，而且也許有多個在輸送中的未确認封包。
• 協定的發送方和接收方兩端也要能緩存多個分組。發送方最低限度應當能夠緩沖哪些已發送但沒有确認的分組；接收方需要能緩存哪些已正确接收的分組。
• 所需要的序号範圍和對緩沖的要求取決于資料傳輸協定如何處理丢失、損壞及延時過大的分組。

解決流水線的差錯恢複有兩種基本的方法是：回退N步和選擇重傳。

4.5 回退N步

在回退N步(GBN)協定中，允許發送方發送多個分組(當有多個分組可用時)而不需要等待确認，但是它也受限于在流水線中未确認的分組數不能超過最大允許數N。

在回退N步中，發送方維護一個N大小的視窗和一個base，發送方期待收到的最小待确認分組序号，同樣也是視窗的起點，還有一個next Sequence變量，表示上層需要發送分組時，可以使用的序号。這樣全部序号就被劃分為0-base-1，這一部分的分組是已發送且收到接收方确認的分組，base~next Sequence-1這一部分的分組是已發送但是尚未收到确認的，其中base是尚未收到确認的最小序号；next-1~base+N-1表示目前發送方可以使用的序号，表示一種發送能力；當發送方收到确認号為base的确認分組後就會向前移動視窗，是以回退N步也被稱為滑動視窗協定。

滑動視窗協定：發送視窗

發送緩沖區：

• 形式：記憶體中的一個區域，落入緩沖區的分組可以發送
• 功能：已發送但是還沒有得到确認的分組
• 必要性：需要重發時可用

發送緩沖區的大小：

• 停止等待協定=1
• 流水線協定>1，選擇合理的值不能很大，鍊路使用率不能超過100%

發送緩沖區的分組：

• 未發送的：落入發送緩沖區的分組，可以連續發送出去
• 已經發送的：等待對方确認的分組，隻有得到了确認才能删除

發送視窗：

• 發送緩沖區的一個範圍，哪些已經發送但未經确認的序号構成的空間
• 發送視窗的值<=發送緩沖區的值
• 一開始沒有發送任何一個分組，後沿=前沿；每發送一個視窗前沿前移一個機關。

這是發送方需要維護的資料，同時發送方需要響應的事件有：上層調用、收到ACK、逾時事件：

• 上層調用：檢查next Sequence是否在視窗之内，如果在，這說明發送方還有發送能力，發送之；
• 收到ACK：回退N步政策對序号為n的分組采取累積确認的方式，即當收到序号為n的ACK時，表明序号小于等于n的分組全部到位；發送方收到的ACK畢竟來自接收方，收到ACK的情況還得看接收方如何發送；
• 逾時事件：如果發生逾時事件，那麼發送方會重發所有已發送但是未确認的分組，即分組号在base和next sequence-1之間的所有分組；這也是為什麼叫“回退N步”，如果收到一個ACK，則定時器會重行啟動；如果沒有待确認的分組，定時器将被終止；

滑動視窗協定：接收視窗

• 接收視窗用于控制哪些分組可以接收

  隻有收到的分組序号落入接收視窗内才允許接收；

  若序号在接收視窗之外，則丢棄

  若接收到的分組序号與之前所接收到的分組序号亂序(比如說已經接收到1号分組，此時又傳來3号分組)，那麼就将新接受的分組丢棄。

• 接收視窗尺寸Wr=1，則隻能順序接收
• 接收視窗尺寸Wr>1，則可以亂序接收，但送出給上層的分組需要按序

兩個視窗的互動：

發送視窗：

• 有了新的分組落入發送緩沖區範圍内，發送并前沿滑動
• 來了老的低序号分組的确認後，後沿向前滑動，新的分組可以落入發送緩沖區的範圍内

接收視窗：

• 收到分組，落入到接收視窗範圍内，接收
• 是低序号，發送确認給對方

4.6 選擇重傳(SR)

回退N步協定存在一個問題就是當視窗和帶寬的時延都較大時，單個分組的差錯可能會引起GBN重傳大量的分組，然後許多本來不用重傳的分組會充斥在信道中，造成資源浪費；選擇重傳就是讓發送方僅重傳那些丢失和受損的分組而避免不必要的重傳。

顧名思義，選擇重傳(SR)協定通過讓發送方僅重傳那些它懷疑在接收方出錯(即丢失或受損)的分組而避免了不必要的重傳。

SR接收方将确認一個正确接收的分組而不管其是否按需排序。時許的分組将被緩存直到所有丢失分組(即序号更小的分組)皆被收到為止，這樣才可以将一批分組傳遞給上層。

SR 發送方的事件和動作：

• 從上層接收資料： 檢查下一個可用于該分組的序号，若在發送方的視窗内，則将資料打包發送。
• 逾時： 定時器再次用來防止丢失分組。但是現在每個分組必須得有單獨的定時器。
• 收到 ACK：倘若該分組序号在視窗内，則 SR 發送方将那個被确認的分組标記為已接收。如果該分組的序号等于send_base，則視窗基序号向前移動到具有最小序号的未确認分組處。如果視窗移動了并且該序号落在視窗内的未發送分組，則發送這些分組。

SR 接收方的事件和動作：

• 序号在 [rcv_base, rcv_base + N -1] 内的分組被正确接收：在此情況下，收到的分組落在接收方的視窗内，一個選擇 ACK 被回送給發送方。如果該分組以前沒收到過，則緩存該分組。如果該分組的序号等于接收視窗的基序号，則該分組及以前緩存的序号連續的分組傳遞給上層。
• 序号在 [rcv_base - N, rcv_base - 1] 内的分組被正确接收： 産生一個 ACK，即使該分組是接收方以前已确認過的分組。因為視圖不一緻
• 其他情況：忽略該分組。

接收方将确認一個正确接收的分組而不管其是否按序；失序的分組被緩存，直到形成連續資料後将其送出給上層；值得注意的是，如果接收方收到了已經确認的分組，則說明确認ACK丢失，或者時延太長，接收方和發送方溝通不及時；這也表明了關于那些分組到位了，那些分組還沒到位，接收方和發送方有着不一樣的視圖。

另外還需要注意的是，序号的重用問題，如果在分組中序号字段的位數為k，那麼最大的序号為2^k-1，是以有可能不同分組同時占用一個序号，為了避免這種情況，需要做的是控制分組的生命周期。視窗長度必須小于或等于序号空間大小的一半。

通過上圖的對比可以看出：對于SR協定來講，其與滑動視窗協定不同的地方在于，如果發送的分組沒有收到ACK确認，那麼逾時後就會重新發送目前分組而不是全部重新發送；對于接收端而言，吐過收到的分組序号亂序，也不會直接丢棄而是緩存起來，等到之前丢失的分組收到後，再按序加之前緩存好的分組直接傳遞給上層，是以說SR是滑動視窗協定的一個改進。

可靠資料傳輸機制以及用途的總結：

五.面向連接配接的傳輸：TCP

TCP是網際網路運輸層的面向連接配接的可靠的運輸協定。為了提供可靠資料傳輸，TCP依賴于前一節所讨論的許多基本原理，其中包括差錯檢測，重傳，累計确認，定時器以及用于序号和确認号的首部字段。

5.1 TCP連接配接

TCP被成為是面向連接配接的，這是因為在一個應用程序可以開始向另一個應用程序發送資料之前，這兩個程序必須先互相握手，即它們必須互相發送某些預備封包段，以確定資料傳輸的參數。

TCP連接配接是一條邏輯連接配接，其共同狀态僅保留在兩個通信端系統的TCP程式中。中間路由器對TCP連接配接完全視而不見，它們看到的是資料報而不是連接配接。TCP提供的是全雙工服務，并且是點對點的。

三次握手的過程：客戶首先發送一個特殊的TCP封包段，伺服器用另一個特殊的TCP封包段來響應，最後客戶再用第三個特殊封包段作為響應。前兩個封包段不承載“有效載荷”，也就是不包含應用層資料；而第三個封包段可以承接有效載荷，由于兩台主機之間發送了3個封包段，是以這種連接配接建立過程常被稱為三次握手。

當TCP連接配接建立後，兩個應用程序就可以發送資料了。應用程式将要發送的資料通過Socket傳遞給TCP，TCP将資料引導到該連接配接的發送緩存，發送緩存大小是在三次握手的過程中确定的；之後TCP将時不時從該緩存中拿出資料進行發送，一個有趣的事情是，TCP規範中沒有規定TCP應該在何時發送緩存裡的資料，描述為“TCP應該在它友善的時候以封包段的形式發送資料”；TCP每次可以從緩存中發送的最大資料長度稱為MSS(Maximum Segment Size)。一般來說，MSS+TCP/IP首部的長度要小于等于鍊路的MTU（即鍊路層最大幀長度Maximum Transport Unit）而以太網和PPP的MTU都等于1500位元組，TCP/IP的首部通常為40位元組，是以MSS一般來說為1460位元組。

注意：MSS指的是封包段中應用層資料最大長度，而不是包括TCP首部的封包段長度。

TCP為每塊客戶資料加上TCP首部後就形成了一個個TCP封包段；這些TCP封包段被交給網絡層，然後被發送到網絡中；當TCP封包段到達接收端時，便進入了接收端的緩存，等待被應用程式讀取。

TCP連接配接的每一端都有發送和接收緩存。

5.2 TCP封包段結構

TCP首部包括源端口号和目的端口号，它被用于多路複用/分解來自或送到上層應用的資料，另外，同UDP一樣，TCP首部也包括檢驗和字段，TCP封包段首部還包含下列字段：

• 32比特的序号字段和32比特的确認号字段，這些字段被TCP發送方和接收方用來實作可靠資料傳輸服務。
• 16比特的接收視窗字段，這字段用于流量控制
• 4比特的首部長字段，該字段訓示了以32比特的字為機關的TCP首部長度。
• 可選與變長的選項字段，該字段用于發送方與接收方協商最大封包段長度MSS時，或在高速網絡環境下用作視窗調教因子使用。
• 6比特的标志字段。ACK比特用于隻是确認字段中的值是有效地，即該封包段包括一個對已被成功接收封包段的确認。RST,SYN,FIN比特用于連接配接建立和拆除。

  

  1.序号和确認号

  TCP把資料看成一個無結構的、有序的位元組流。一個封包段的序号是該封包段首位元組的位元組流編号。因為TCP是全雙工的，是以主機A在向主機B發送資料的同時，也許也接收來自主機B的資料(都是同一條TCP連接配接的一部分)。從主機B到達的每個封包段中都有一個序号用于從B流向A的資料。主機A填充進封包段的确認号是主機A期望從主機B收到的下一個位元組的序号。再舉一個例子，假設主機A已收到一個來自主機B的包含位元組0~535的封包段，以及另一個包含900-1000的封包段。主機A為了重新建構主機B的資料流，仍在等待位元組536(和其後的位元組)。是以，A到B的下一個封包段将在确認号字段中包含536.是以TCP隻确認該流中至第一個丢失位元組為止的位元組，是以TCP被稱為累計确認。

5.3 往返時間的估計和逾時

TCP如同之前所講的rdt協定一樣，采用逾時/重傳機制來處理封包段的丢失問題。逾時時間一定大于該連接配接的往返時間(RTT),但是該如何設定呢？

TCP使用一種Sample RTT的方法來估計RTT。Sample RTT就是從某封包段發出到收到對該封包段的确認之間的時間量。大多數TCP的實作是在某個時刻做一個Sample RTT測試。TCP并不為已經重發的封包段做Sample RTT測試，它隻為傳輸一次的封包段測量Sample RTT。

TCP一般來說通過Estimated RTT=(1-a)Estimated RTT+a*Sample RTT來計算因路由器的擁塞和端系統負載變化所導緻變化的RTT。a一般取1/8；因為Estimated RTT表示最近的網絡狀況，是以其理應得到較大的權值；這種方法也被稱為指數權重移動平均

除了估計RTT外，計算RTT的變化也是ok的，DevRTT =(1-b)DevRTT+b*|Sample RTT-Estimated RTT|；其中b的推薦值為0.25；當Sample RTT變化較大的時候，DevRTT的值較大，當Sample RTT變化較小的時候，DevRTT就較小；

TCP是如何考慮逾時時間的呢？該時間因略大于測量的RTT，不易過小——容易引起不必要的重傳，也不易過大——網絡對于封包段丢失情況的反應就會變慢；最後TCP采用了如下計算方式：Timeout Interval=Estimated RTT+4*Dev RTT；

當出現逾時後，TimeOutInteval值将加倍。不管怎麼樣，一旦封包段收到并更新Estimated RTT後，TimeInteval就又用上值計算了。

5.4 可靠資料傳輸

TCP在IP不可靠的盡力而為服務之上建立了一種可靠資料傳輸服務。TCP的可靠資料傳輸服務確定一個程序從其接收緩存中讀出的資料流是無損壞、無間隙、非備援和按序的資料流，即該位元組流與連接配接的另一方端系統發送出的位元組流是完全相同的。

TCP的發送方有3個與發送和重傳有關的主要事件：從上層應用接收資料，定時器逾時和收到ACK。

1.一些有趣的情況

以下展示三種不同情況下簡易版本的TCP連接配接：

注意：在下面這種情況下，主機A的第一個封包段的确認封包在網絡中丢失，但是在逾時事件發生之前主機A收到一個确認号為120的确認封包。主機A是以知道了主機B已經收到了序号為119及之前的所有位元組，是以主機A不會重傳這兩個封包段中的任何一個。

2.逾時間隔加倍

每當逾時事件發生時，TCP重傳具有最小序号的還未被确認的封包段。隻是每次TCP重傳時都會将下一次的逾時間間隔設為先前的兩倍。是以，逾時間間隔在每次重傳後會呈指數型增長，然而，當定時器在另兩個事件(即收到上層應用的資料和收到ACK)中的任意一個啟動時，TimeoutInterval由最近的EstimatiedRTT值與DevRTT值推算得到。這種辦法是一個形式受限的擁塞控制。

3. 快速重傳

逾時觸發重傳存在的問題之一是逾時周期可能相對較長，當一個封包段丢失時，這種長逾時周期迫使發送方延遲重傳丢失的分組，因而增加了端到端的時延。發送方可以在逾時事件發生之前通過注意所謂備援ACK來較好地檢測到丢包情況。備援ACK就是再次确認某個封包段的ACK，而發送方先前已經收到對該封包段的确認。要知道接收方為什麼要發送備援ACK，可以先看下表關于産生TCP ACK的建議：

因為發送方經常一個接一個地發送大量的封包段，如果一個封包段丢失，就可能引起許多一個接一個的備援ACK。如果TCP發送方接收到對相同資料的3個備援ACK，說明這個已被确認過3次的封包段之後的封包段已經丢失，那麼就執行快速重傳，即在該封包段的定時器過期之前重傳丢失的封包段。

為什麼是3個備援ACK：

是因為當接收到第一個ACK代表的是正常，收到第二個ACK代表接收方亂序，可能是由于網絡時延等原因導緻，當收到第三個ACK的時候則表示該分組已經很大可能丢失了。

4. 是回退N步還是選擇重傳

TCP确認是累計式的，正确接收但失序的封包段是不會被接收方逐個确認的。是以，**TCP發送方僅需維持已發送過但未被确認的位元組的最小序号和下一個要發送的位元組的序号。**看上去像是GBN風格的協定，但是還是有一些差別。

對TCP提出的一種修改意見是所謂的選擇确認，它允許TCP接收方有選擇的确認失序封包段，而不是累計地确認最後一個正确接收的有序封包段。當該機制與選擇重傳機制結合起來使用時，TCP就很像SR協定了，是以，TCP應該是二者的混合。

5.5 流量控制

當TCP連接配接接收到正确、按序的位元組後，它就将資料放入接收緩存。但是，接收方應用也許忙于其他工作，甚至要過很長事件後才去讀取資料，是以，此時如果發送發發送太多太快，發送的資料就會很容易使該連結的接收緩存溢出。

TCP為它的應用程式提供了流量控制服務以消除接收方緩存溢出的可能性，流量控制服務是以是一個速度比對服務，即發送方的發送速率與接收方的應用讀取速讀像比對。

TCP通過讓發送方維護一個稱為接收視窗的變量來提供流量控制。通俗地說，接收視窗用于給發送方一個訓示-該接收方還有多少可用的緩存空間。因為TCP是全雙工通信，是以連接配接的兩端都各自維護一個接收視窗。

在TCP首部中有一個視窗大小字段，TCP連接配接的雙方通過該字段來向對方表明自己的視窗大小，即緩存空間的大小；同樣，在TCP連接配接的兩端，各自維護着相關的變量：last Sent、last Acked；在發送方，這兩個變量之間的分組就是已經發送但是尚未确認的分組；而在接收方，last Read表示應用程序下一次讀取的資料，last Revd表示最後納入緩存的封包段編号（注意，我們讨論的前提是TCP會将失序到達的封包段丢棄）；通過這些變量以及封包段首部中視窗大小字段，我們就可以對發送速度做一些控制：在發送方last Sent-last Acked應該小于等于接收方的視窗大小；在接收端A=last Received-last Read就是已經使用的空間大小，是以視窗大小=buffer-A；

還有一個問題就是，如果接收方的視窗大小為0，那麼發送端該如何處理呢？一個需要注意的事實是，接收方在沒有ACK或者資料要向發送端發送的時候，是不會通知發送方其視窗大小已經改變，即如果應用程式讀取了緩存中的資料，發送方是不會知道的，除非它向接收方發送了資料，而發送方對其進行了确認；實際上，發送方也是這麼做的！當接收到視窗大小為0的封包段後，發送方會向接收方間隔發送隻有一個位元組的資料。

5.6 TCP連接配接管理

1.TCP三向交握

TCP協定中，主動發起請求的一端稱為『用戶端』，被動連接配接的一端稱為『服務端』。不管是用戶端還是服務端，TCP連接配接建立完後都能發送和接收資料。

起初，伺服器和用戶端都為CLOSED狀态。在通信開始前，雙方都得建立各自的傳輸控制塊（TCB）。伺服器建立完TCB後遍進入LISTEN狀态，此時準備接收用戶端發來的連接配接請求。

第一次握手

用戶端TCP向服務端TCP發送一個特殊的封包段。該封包段不包含應用層資料，但是其首部中SYN=1，ACK=0，seq=x，其中x是客戶随機選擇一個初始序号，并将此序号放置于該起始的TCP SYN封包段的序号字段部分。請求發送後，用戶端便進入SYN-SENT狀态。

PS1：SYN=1，ACK=0表示該封包段為連接配接請求封包。

PS2：x為本次TCP通信的位元組流的初始序号，是客戶随機配置設定的。

TCP規定：SYN=1的封包段不能有資料部分，但要消耗掉一個序号。

第二次握手

服務端收到連接配接請求封包段後，如果同意連接配接，則會發送一個應答：SYN=1，ACK=1，seq=y，确認号=x+1。

該應答發送完成後便進入SYN-RCVD狀态。

PS1：SYN=1，ACK=1表示該封包段為連接配接同意的應答封包。

PS2：seq=y表示服務端作為發送者時，發送位元組流的初始序号。

PS3：确認号=x+1表示服務端希望下一個資料報發送序号從x+1開始的位元組。

第三次握手

當用戶端收到連接配接同意的應答後，還要向服務端發送一個确認封包段，表示：服務端發來的連接配接同意應答已經成功收到。

該封包段的頭部為：ACK=1，seq=x+1，确認号=y+1。

用戶端發完這個封包段後便進入ESTABLISHED狀态，服務端收到這個應答後也進入ESTABLISHED狀态，此時連接配接的建立完成，此時SYN比特被置為0！

為什麼連接配接建立需要三次握手，而不是兩次握手？

防止失效的連接配接請求封包段被服務端接收，進而産生錯誤。

失效的連接配接請求：若用戶端向服務端發送的連接配接請求丢失，用戶端等待應答逾時後就會再次發送連接配接請求，此時，上一個連接配接請求就是『失效的』。若建立連接配接隻需兩次握手，用戶端并沒有太大的變化，仍然需要獲得服務端的應答後才進入ESTABLISHED狀态，而服務端在收到連接配接請求後就進入ESTABLISHED狀态。此時如果網絡擁塞，用戶端發送的連接配接請求遲遲到不了服務端，用戶端便逾時重發請求，如果服務端正确接收并确認應答，雙友善開始通信，通信結束後釋放連接配接。此時，如果那個失效的連接配接請求抵達了服務端，由于隻有兩次握手，服務端收到請求就會進入ESTABLISHED狀态，等待發送資料或主動發送資料。但此時的用戶端早已進入CLOSED狀态，服務端将會一直等待下去，這樣浪費服務端連接配接資源。

2.TCP連接配接的釋放一共需要四步，是以稱為*四次揮手：

第一次揮手：

若A認為資料發送完成，則它需要向B發送連接配接釋放請求。該請求隻有封包頭，頭中攜帶的主要參數為：

FIN=1，seq=u。此時，A将進入FIN-WAIT-1狀态。

PS1：FIN=1表示該封包段是一個連接配接釋放請求。

PS2：seq=u，u-1是A向B發送的最後一個位元組的序号。

第二次揮手

B收到連接配接釋放請求後，會通知相應的應用程式，告訴它A向B這個方向的連接配接已經釋放。此時B進入CLOSE-WAIT狀态，并向A發送連接配接釋放的應答，其封包頭包含：ACK=1，seq=v，确認号=u+1。

PS1：ACK=1：除TCP連接配接請求封包段以外，TCP通信過程中所有資料報的ACK都為1，表示應答。

PS2：seq=v，v-1是B向A發送的最後一個位元組的序号。

PS3：确認号=u+1表示希望收到從第u+1個位元組開始的封包段，并且已經成功接收了前u個位元組。

A收到該應答，進入FIN-WAIT-2狀态，等待B發送連接配接釋放請求，此時從B發送的應該為FIN被置為1的另一個封包段。

注：第二次揮手完成後，A到B方向的連接配接已經釋放，B不會再接收資料，A也不會再發送資料。但B到A方向的連接配接仍然存在，B可以繼續向A發送資料。

第三次揮手：

當B向A發完所有資料後，向A發送連接配接釋放請求，請求頭：FIN=1，ACK=1，seq=w，确認号=u+1。B便進入LAST-ACK狀态。

第四次揮手：

A收到釋放請求後，向B發送确認應答，此時A進入TIME-WAIT狀态。該狀态會持續2MSL時間，若該時間段内沒有B的重發請求的話，就進入CLOSED狀态，撤銷TCB。當B收到确認應答後，也便進入CLOSED狀态，撤銷TCB。

為什麼A要先進入TIME-WAIT狀态，等待時間後才進入CLOSED狀态？

為了保證B能收到A的确認應答。若A發完确認應答後直接進入CLOSED狀态，那麼如果該應答丢失，B等待逾時後就會重新發送連接配接釋放請求，但此時A已經關閉了，不會作出任何響應，是以B永遠無法正常關閉。

六.擁塞控制原理

在實踐中，丢包一般是當網絡變得擁塞時由于伺服器緩存溢出引起的。分組重傳是以作為網絡擁塞的征兆來對待，但是缺無法處理導緻網絡擁塞的原因，因為有太多源想以過高的速率發送資料。為了處理網絡擁塞的原因，需要一些機制以在面臨網絡擁塞時遏制發送方。

6.1 擁塞原因與代價

計算機網絡擁塞的原因是因為網絡中的分組太多，而鍊路帶寬和路由器緩存容量都是有限的；

• 當分組的到達速率接近鍊路容量時，分組将經曆巨大的排隊時延；
• 發送方必須執行重傳已補償因為緩存溢出而丢棄的分組
• 發送方遇到大時延時所進行的不必要重傳會引起路由器利用其鍊路帶寬來轉發不必要的分組副本。
• 當一個分組沿着一條路徑被丢棄時，每個上遊路由器用于轉發該分組到丢棄該分組而使用的傳輸容量最終被浪費掉了；

6.2 擁塞控制方法

1.擁塞控制：擁塞控制是作用于網絡的，它是防止過多的資料注入到網絡中，避免出現網絡負載過大的情況；

2.流量控制：流量控制是作用于接收者的，它是控制發送者的發送速度進而使接收者來得及接收。

總體來說，我們可以更具網絡層是否為傳輸層擁塞控制提供了顯式幫助來區分擁塞控制方法：端到端擁塞控制和網絡輔助擁塞控制；

在端到端擁塞控制方法中，網絡層并沒有向傳輸層擁塞控制提供顯式支援，即便網絡中存在擁塞，端系統也必須通過對網絡行為的觀察（如分組丢失與時延）來判斷；TCP必須通過端到端的方法解決擁塞控制，因為IP層不會像端系統提供有關網絡擁塞的回報資訊。TCP封包段的丢失（逾時或者收到3次備援确認而得知）被認為是網絡擁塞的一個迹象，TCP将相應地減小視窗長度；

在網絡輔助的擁塞控制方法裡，網絡層會向發送方提供關于網絡中擁塞狀态的顯式回報消息；比如使用一個比特位來訓示網絡是否擁塞；擁塞資訊從網絡回報到發送方一般有兩種方式，其中直接回報資訊可以由網絡路由器發送給發送方，這種方式的通知通常采用一種擁塞分組的形式；第二種形式的通知是**路由器标記或者更新從發送方到接收方的分組中的某個字段來訓示擁塞的産生，然後由接收方向發送方通知該網絡發生了擁塞

**。

七.TCP擁塞控制

TCP采用擁塞控制的方法是讓每一個發送方根據所感覺到的網絡擁塞程度來限制其能向連接配接發送流量的速率。由此引出了三個問題：一個TCP發送方如何讓限制它想其連接配接發送流量的速率；一個TCP發送方如何感覺從它到目的地之間的路徑上存在擁塞；當發送方感覺到端到端的擁塞時，采用什麼算法來改變發送速率。

我們知道，TCP連接配接的雙方都維護着兩個視窗，其中一個是作為發送方的視窗，也被稱為擁塞視窗cwnd，它對發送方能向網絡中發送流量的速率進行了限制，last sent-last acked<=min{cwnd,rwnd}；另一個自然是作為接收方的接收視窗。我們假設，發送方可以在RTT時間範圍内連續發送cwnd個位元組的資料，是以發送速率即為cwnd/RTT；發送方通過調整視窗大小來對發送資料的速率加以控制。

我們将TCP發送方的丢包事件定義為：要麼逾時，要麼收到接收方的3個備援ACK；如果網路擁塞，那麼網絡中的路由器就會發生緩存溢出，進而導緻資料報被丢棄，然後就會引起發送方的丢包事件；此時，TCP發送方就可以認為TCP連接配接出現了擁塞；另外，TCP将接收方發送的ACK視為網絡通暢的标志，如果ACK到達的速率較高，那麼TCP的擁塞視窗就會以較高的速率擴大，如果ACK到達的速率較慢，那麼TCP擁塞視窗的增加速度也會較慢；因為TCP使用ACK對擁塞視窗做出調節，是以也别稱為自計時的；

TCP發送速率過高，網絡就很容易擁塞；TCP發送方如果過于謹慎，那麼就無法充分利用網絡的帶寬；是以TCP如何設定自己的發送速率，才能使得網絡不會擁塞而且還充分利用帶寬呢？關于這個問題，TCP使用下列指導性原則回答這些問題：

• 一個丢失的封包段意味着擁塞，是以當丢失封包段時應當降低TCP發送方的速率；
• 一個确認封包段訓示該網絡正在向接收方傳遞發送方的封包段，是以，當收到對先前封包段的确認時，可以增加發送方的速率；
• 帶寬檢測；TCP調節器傳輸速率的政策是增加其速率以響應到達的ACK，除非出現丢包，此時才減少發送速率；以為網絡中沒有明确的擁塞控制狀态信令，ACK和丢包事件充當了隐式信号.

以上為TCP擁塞控制的概述，接下來就是廣受贊譽的TCP擁塞控制算法，該算法包含三個主要部分：慢啟動、擁塞避免、快速恢複；慢啟動和擁塞控制是TCP的強制部分；兩者的差異在于對收到的ACK做出反應時增加cwnd長度的方式；快速恢複是推薦部分，對于TCP發送方并非是必須的。

慢啟動：

TCP連接配接在開始的時候，其cwnd常設定為一個MSS，然後在慢啟動狀态每收到一個ACK，cwnd就增加一個MSS；這樣的話，在慢啟動階段，發送速率是指數增加的（1,2,4,8…）

何時結束這種指數增長？有三種情況：發送了逾時、發生了備援ACK以及cwnd達到ssthresh。ssthresh是慢啟動門檻值的速記；在慢啟動階段，如果發生了逾時事件，那麼ssthresh就被設定為目前cwnd的一半，然後将cwnd置為1；當cwnd逐漸增加到ssthresh時，再翻倍增加cwnd就有一點魯莽了，是以此時TCP結束慢啟動，進入擁塞避免模式。在擁塞避免模式裡，TCP将更謹慎地增加cwnd；如果收到備援ACK，那麼TCP會做一次快速重傳，然後進入快速恢複階段；

擁塞避免：

一旦進入擁塞避免狀态，cwnd的值大約是上次遇到擁塞時的一半，是以TCP在每個RTT中，隻将cwnd增加一個1個MSS大小；也就是說在擁塞避免階段，cwnd是線性增加的；

當出現逾時時，TCP将cwnd設定為1，然後将ssthresh更新為cwnd的一半；當收到備援ACK時，TCP将cwnd減半，然後将ssthresh置為cwnd值的一半，并且進入快速恢複狀态。

快速恢複

在快速恢複階段，對于引起TCP進入該狀态的缺失封包段，每收到一個ACK，cwnd增加一個MSS；最終，當對丢失封包段的一個ACK到達時，TCP降低cwnd後進入擁塞避免狀态；如果出現逾時事件，快速恢複在執行如同慢啟動和擁塞避免中相同動作後，進入慢啟動狀态：當丢包事件出現時，cwnd的值被設定為1個MSS，并且ssthresh變為cwnd的一半.

7.1 公平性

TCP趨于在競争的多條TCP連接配接之間提供對一段瓶頸鍊路帶寬的平等分享。

1.公平性和UDP

UDP是沒有内置的擁塞控制的，當運作在UDP上時，這些應用能夠以恒定的速率将其音頻以及視訊資料注入網絡中并且偶爾會丢失分組，而不願再擁塞時将其發送速率降至“公平”級别并不丢失分組。

2.公平性和并行TCP連接配接

通常,Web浏覽器通常使用多個并行TCP連接配接來傳送一個Web頁中的多個對象。當一個應用使用多條并行連接配接時，它占用了一條擁塞鍊路中較大比例的帶寬。

7.2 明确擁塞通告：網絡輔助擁塞控制

一個TCP發送方不會收到來自網絡層的明确擁塞訓示，而是通過觀察分組丢失來推斷擁塞，最近提出一種方案，該方案允許網絡明确向TCP發送方和接收方發出擁塞信号，這種形式的網絡輔助擁塞控制稱為明确擁塞通告。