TCP傳輸控制協議?
TCP 協議是一種面向連接的，為不同主機進程間提供可靠數據傳輸的協議。TCP 協議假定其所使用的網絡棧下層協議（如IP 協議）是非可靠的，其自身提供機制保證數據的可靠性傳輸。在目前的網絡棧協議族中，在需要提供可靠性數據傳輸的應用中，TCP 協議是首選的，有時也是唯一的選擇。TCP協議使用的是網絡層協議（如IP協議）提供的服務。?
網絡層協議主要完成對上層協議的數據的傳遞，但是不提供數據的可靠性傳遞，可靠性主要由上層協議（如TCP協議提供，但是UDP協議不提供可靠性）。
TCP實現可靠性傳輸的底層實現機制主要包括：1> 使用序列號對傳輸的數據進行編號， ? ? 2>數據超時重傳， ? ?3>數據確認應答！

網絡層協議主要完成的工作是：?
（1）實現不同網絡（主機）間的數據包路由傳遞。
（2） 在發送端（或中轉站）提供數據包分片功能以使數據包大小滿足 PMTU（路徑MTU（最大尺寸））。
（3） 在接收端提供數據包分片重組功能
（4） 負責數據包優先級，安全性等問題。

傳輸層協議（主要是TCP協議）的工作：?
1> 提供多路復用。
2> 實現數據基本傳輸功能。
3> 建立通信通道。
4> 提供流量控制。
5> 提供數據可靠性傳輸保證。

數據可靠性傳輸包括的內容

1> 能夠處理數據傳輸過程中被破壞問題。

2> 能夠處理重復數據接收問題。

3> 能夠發現數據丟失以及對此進行有效解決。

4> 能夠處理接收端數據亂序到達問題。

TCP 協議可靠性數據傳輸實現基本原理

TCP 協議必須提供對所有這些問題的解決方案方可保證其所聲稱的數據可靠性傳輸。TCP協議規范和當前絕大多數TCP 協議實現代碼均采用數據重傳和數據確認應答機制來完成TCP 協議的可靠性數據傳輸。數據超時重傳和數據應答機制的基本前提是對每個傳輸的字節進行編號，即我們通常所說的序列號。數據超時重傳是發送端在某個數據包發送出去，在一段固定時間后如果沒有收到對該數據包的確認應答，則（假定該數據包在傳輸過程中丟失）重新發送該數據包。而數據確認應答是指接收端在成功接收到一個有效數據包后，發送一個確認應答數據包給發送端主機，該確認應答數據包中所包含的應答序列號即指已接收到的數據中最后一個字節的序列號加1，加1 的目的在于指出此時接收端期望接收的下一個數據包中第一個字節的序列號。數據超時重傳和數據確認應答以及對每個傳輸的字節分配序列號是TCP 協議提供可靠性數據傳輸的核心本質。


1）數據確認應答數據包中應答序列號的含義


應答序列號并非其表面上所顯示的意義，其實際上是指接收端希望接收的下一個字節的序列號。所以接收端在成功接收到部分數據后，其發送的應答數據包中應答序列號被設置為這些數據中最后一個字節的序列號加一。所以從其含義上來說，應答序列號稱為請求序列號有時更為合適。應答序列號在TCP 首部中應答序列號字段中被設置。而TCP 首部中序列號字段表示包含該TCP 首部的數據包中所包含數據的第一個字節的序列號（令為N）。如果接收端成功接收該數據包，之前又無丟失數據包，則接收端發送的應答數據包中的應答序列號應該為：N+LEN。其中LEN 為接收的數據包的數據長度。該應答序列號也是發送端將要發送的下一個數據包中第一個字節的序列號（由此亦可看出上文中將應答序列號稱為請求序列號的原因所在）。


2）數據確認應答中的累積效應


TCP 協議中接收端對所接收數據的應答是累積的。累積的含義有二：


1>應答序列號是逐漸遞增的，這與發送端數據編號是遞增的相吻合。


2>不可進行跨越式數據應答。


所謂不可進行跨越式數據應答，可以以數據包亂序到達為例進行說明。如果由于發送端所選擇傳輸路徑的不同，較后發送的序列號較大的數據包先到達接收端，而先發送的序列號較小的數據包由于線路問題（或路由器故障）被暫時延遲在網絡中，此時接收端不可對這些序列號較大的數據進行應答。如果接收端需要發送一個應答數據包，則應答序列號仍然應該設置成對序列號較小的數據包的請求（注意應答序列號指的是接收端希望接收的下一個字節的序列號，故在數據傳輸過程中將應答數據包稱為數據請求數據包更為合適）。舉例來說，如果接收端目前的應答序列號為201，表示接收端正在等待發送端發送從201 開始編號的數據，之后發送端連續發送了兩個數據包，第一個數據包中數據序列號范圍為201-300，第二個數據包中數據序列號范圍為301-400。如果由于選擇了不同的傳輸路徑造成第二個數據包最先到達接收端，而第一個數據包在網絡中延遲了一段時間，則接收端不可對第二個數據包進行應答，即不可發送應答序列號為401 的確認應答數據包，而是不斷發送應答序列號為201的應答數據包直到該序列號的數據到達。我們通常所說的快速重傳機制即發送端在連續接收到3 個相同序列號的應答數據包后需要立刻重傳應答序列號所表示的數據。因為此時表示極有可能出現了數據包丟失的情況，如上例中第一個數據包如果丟失在網絡中并且發送端重傳的相同數據包由于選擇相同的線路也未能到達接收端，則接收端將不斷發送應答序列號為201 的應答數據包而不會將應答序列號設置為401。注意此時接收端已接收到序列號從301-400 的數據。


3）重傳應答機制與序列號結合：


1> 能夠處理數據在傳輸過程中被破壞的問題。


首先通過對所接收數據包的校驗，確認該數據包中數據是否存在錯誤。如果有，則簡單丟棄或者發送一個應答數據包重新對這些數據進行請求。發送端在等待一段時間后，則會重新發送這些數據。本質上，數據傳輸錯誤的解決是通過數據重傳機制完成的。


2> 能夠處理接收重復數據問題。


首先利用序列號可以發現數據重復問題。因為每個傳輸的數據均被賦予一個唯一的序列號，如果到達的兩份數據具有重疊的序列號（如由發送端數據包重傳造成），則表示出現數據重復問題，此時只須丟棄其中一份保留另一份即可。多個數據包中數據重疊的情況解決方式類似。本質上，數據重復問題的解決是通過檢查序列號完成的。


3> 能夠發現數據丟失以及進行有效解決。


首先必須說明，此處數據包丟失的概念是指在一段合理時間內，應該到達的數據包沒有到達，而非我們平常所理解的永遠不到達。所以數據包丟失與數據包亂序到達有時在判斷上和軟件處理上很難區分。數據丟失的判斷是猜測性的，我們無法確定一個數據包一定丟失在傳輸過程中，大多是被延遲在網絡中，即實質的問題只是數據包亂序到達。將二者區分開來的一個主要依據是在合理的時間內，由這個可能丟失的數據包所造成的序列號“空洞“是否能夠被填補上。可能的數據丟失一個顯然的結果是在接收端接收的數據出現序列號不連續現象。如接收端只接收到序列號從1 到100 的數據包，之后又接收到序列號從200 到300 的數據包，而且在一段合理的


時間內（由此基本排除亂序問題），序列號從101 到199 的數據一直未到達，則表示包含序列號從101 到199 的數據包在傳輸過程中很可能丟失（或者有極不正常的延遲）。對數據包是否丟失判斷的另外一個干擾因素是發送端的重傳機制，如果一個序列號較前的數據包在網絡中丟失，造成序列號較后的數據包提前到達接收端，也會暫時造成序列號不連續，但由于發送端在沒有接收到確認應答時，會重新發送序列號較前的那個數據包，如果此后接收端接收到一個重傳的數據包，則僅僅只會在接收端造成數據包亂序到達的表象。無論實質如何，如果軟件實現判斷出數據包丟失，則接收端將通過不斷發送對這些丟失的數據的請求數據包（也即應答數據包，見前文中對數據應答數據包和數據應答累積效應的說明）來迫使發送端重新發送這些數據。通常發送端自身會自發的重傳這些未得到對方確認的數據，但由于重傳機制采用指數退避算法，每次重傳的間隔時間均會加倍，所以通過發送方主動重傳機制恢復的時間較長，而接收端通過不斷發送對這些丟失數據的請求，發送端在接收到三個這樣的請求數據包后（三個請求數據包中具有同一個請求序列號–也即前文中所說的應答序列號），會立刻觸發對這些數據的重新發送，這稱為快速恢復或者快速重傳機制。本質上，對于數據丟失問題的解決是通過數據重傳機制完成的。在此過程中序列號和數據確認應答起著關鍵的作用。


4> 能夠處理接收端數據亂序到達問題。


如果通信雙方存在多條傳輸路徑， 則有可能出現數據亂序問題，即序列號較大的數據先于序列號較小的數據到達，而發送端確實是按序列號由小到大的順序發送的。數據亂序的本質是數據都成功到達了，但到達的順序不盡如人意。對這個問題的解決相對比較簡單，只需對這些數據進行重新排序即可。本質上，對數據亂序問題的解決是通過排序數據序列號完成的。

總結

以上是生活随笔為你收集整理的TCP如何保证可靠性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。