TCP是如何實現可靠鏈接的？

TCP是如何實現可靠鏈接的？

TCP是面向鏈接的協議，它與UDP的不一樣之處主要有兩點：
一、TCP是面向鏈接的，而UDP是不面向鏈接的；
二、TCP的信息傳輸是可靠的，而UDP的信息傳輸是不可靠的。
那麼TCP是如何實現可靠鏈接的呢？
TCP協議主要經過檢驗和、序列號、確認應答（ACK）、重發控制、鏈接管理、窗口控制等實現可靠性鏈接。

1、確認應答：ACK（Positive Acknowled-gement）意指已經接收。

假設沒有丟包，那麼發送端每次發送數據後都會受到接收端的確認應答（ACK），發送端只有受到接收端的確認應答（ACK）後，纔會繼續發送數據。

假設發送過程當中產生了丟包，那麼在特定時間內發送端將沒法受到接收端的確認應答（ACK），以後發送端會從新發送以前的數據，直到在發送數據後的特定時間內受到接收端的確認應答（ACK）。

請思考：那麼若是出現如下狀況怎麼辦？ 根據上面說的規則，發送端只有在特定時間內接收到的ACK纔會中止從新發送以前的數據，那麼若是發送端發送數據後，由於網絡延遲等緣由，接收端發送的ACK出現了延遲，致使發送端在特定時間外接收到接收端的ACK，那對接收端來講就是一個「災難」——它在不斷地接收發送端發來的重複數據。

2、序列號

看了上述思考題後，首先咱們會想到這種狀況是徹底有可能的，由於網絡的不穩定頗有可能致使這種狀況，可是TCP要保證不管是在何種狀況下都要有高性能的傳輸能力，那麼該如何作呢？
爲了不上述狀況，保證TCP高性能的傳輸能力的特性，協議中給發送端的每段數據都規定了一個序列號。
以下圖所示，爲了方便起見，咱們將數據按照1000爲一個單位，數據的初始序列號爲數據量（實際中是以數據的散列值爲準），每當發送端發送數據時，會將序列號放入TCP包的首部中，而後接收端接收到數據後會解析TCP包的首部，在序列號的基礎上+1生成新的序列號，經過ACK發回給發送端，那麼即便當發送端在特定時間外接收到以前接收端返回的ACK，發送端會根據序列號判斷是否要繼續從新發送以前的數據。自此，經過序列號咱們解決了因網絡延遲的問題不斷從新發送相同數據的狀況。

請思考：經過上文，咱們瞭解到TCP發送數據後會有一個特定的等待時間，若是這個等待時間過長，那麼勢必會致使數據傳輸性能減弱，若是太短，那麼發送端將會發送屢次相同數據，一樣致使數據傳輸性能減弱，那麼如何作到合理的規定這個特定的等待時間呢？

3、重發控制

首先咱們將那個等待的特定時間定義爲重發超時——是指重發數據以前，等待ACK到來的那個特定時間。
TCP要求不論在何種網絡環境下都要提供高性能通訊，而且不管網絡擁堵狀況發生何種變化，都必須保持這種特性。爲此，它在發包時都會計算往返時間及其誤差。
計算完往返時間及其誤差後，將往返時間加上誤差就能得出重發超時。
數據被重發以後若仍是收不到確認應答，則進行再次發生。此時，等待確認應答的時間將會以2倍、4倍的指數函數增加。此外，數據不會被無限、反覆的重發。達到必定重發次數以後，若是仍沒有任何確認應答返回，就會判斷爲網絡或對端主機發生異常，強制關閉鏈接。而且通知應用通訊異常強行終止。

請思考：獲得重發超時後，按理咱們已經基本已經完成了基本的可靠性傳輸，可以保證丟包後從新發送而且不會出錯，那麼爲何TCP還要規定其餘的東西呢？目前咱們完成的協議是否有弊端？該如何解決？

4、窗口控制

在瞭解什麼是窗口控制前，咱們須要知道的是以前咱們完成的方案是存在弊端的，那就是實際傳輸效率很低。那是由於每次咱們要發一個包都得等一個ACK甚至是重發超時+ACK的時間，若是發送的數據不少，那麼勢必會影響到傳輸速度，而這顯然違背了TCP高性能傳輸的特性。
爲了解決這個弊端，TCP提出了一個很好的解決方案——窗口控制。
如圖下圖所示，ACK再也不是以每一個分段，而是以更大的單位進行確認時，轉發時間將會被大幅度的縮短。也就是說，發送端主機，在發送了一個段之後沒必要要一直等待確認應答，而是繼續發送。

自此，咱們基本實現了高性能的可靠性傳輸，而TCP在此以外還規定了其餘的內容，如流控制，用來處理緩衝區滿的狀況等等，這些內容進一步提升了傳輸性能。
最後，建議初學者能夠去看《圖解TCP/IP》。