TCP下面的IP層是盡力的交付，是不可靠的，所以TCP需要靠自己去完成可靠傳輸。下面，我們先從簡單的停止等待協定來講解可靠傳輸的如何實現的。需要注意可靠傳輸的幾個特點：不遺失、不重複、依序到達。
注意，TCP並沒有使用停止等待協定來實現可靠傳輸。
停止等待協定
傳輸層的資料傳輸單元稱為區段。下面，為了方便，都稱為分組。
停止等待協議的原理非常簡單，發送一個分組後就停止繼續發送，等待收到上一個分組的確認後，再繼續發送後面的分組。
下面透過幾個不同情況來分析：
無錯誤狀況
無錯誤情況非常簡單，如下圖。每發送完一個分組後，就停止發送，等待收到該分組的確認後，再繼續發送後面的分組。
出現錯誤
#出現錯誤分兩種情況，第一種是發送的分組沒有交付成功到目的位址，另一種情況是傳送的資料包有錯誤。透過圖例，我們來分析兩種情況
#首先來看看B的操作：A發送M1分組，該分組如果是錯誤的，B收到後會丟棄該數分組，然後什麼也不做（不會通知A收到了錯誤分組）。如果B沒有收到M1分組，那麼它什麼都不知道，也不會去做任何動作。
接下來看A是如何做的：A發完分組後，遲遲收不到B對M1分組的確認後，當等待的時間超時了，那麼就需要重新發送該M1分組。要實現超時重傳，就需要設定一個超時計時器，當發送的一個分組在超時時間前收到了確認，那麼就重置超時計時器，否則的話就需要重傳分組。
有幾點是需要注意的：
A在傳送完一個分組後，必須也要儲存該分組的副本，以便逾時重傳。當收到這個分組的確認後，就可以丟棄該分組的副本了。
需要為每一個分組做編號，這樣才知道是各個分組的到達狀況。
逾時時間應該設定的比平均傳輸時間稍長一些，以免造成不必要的重傳。
確認遺失和確認遲到
#除了分組在傳送過程中會出現錯誤，在回傳確認的時候，也會出現錯誤－確認遺失和確認遲到。
首先看確認遺失情況，A的分組B收到了，並給A發送了確認，但該確認遺失了，A沒有收到。因為A沒有收到M1的確認，那麼等待超過超時後，就會向B重傳M1。這時候B收到了重複的分組M1，需要做兩個動作：
將重複的分組M1丟棄
向A發送M1的確認。因為既然A重傳了M1，就表示A沒有收到M1的分組。所以B需要繼續發送對M1的確認。
再來看另一種情況，對M1的分組確認遲到了（超過逾時時間後才收到）。 A在收到重複的確認後，會丟棄，其他什麼都不做。
透過上述的逾時重送機制，就可以實現在不可靠的網路傳輸上實現可靠的傳輸。
通道利用率
上述的停止等待協定簡單，但它有一個非常大的缺點－通道的使用率太低。在等待收到確認的這段時間，頻道是完全空閒的，十分浪費。
為了提高通道利用率，可以使用管線傳輸，管線傳輸可以連續傳送多個分組，這樣就可以大幅提高頻道利用率了。
採用管線傳輸的協定有連續ARQ協定和視窗滑動協定。而TCP就是採用滑動視窗協定來完成可靠傳輸的。
以上是一文讀懂TCP的可靠傳輸原理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
