TCP向調用它的因特網應用提供所提供的服務模型

數據可以通過一條可靠的信道進行傳輸。借助於可靠的信道，傳輸比特就不會受到損壞或丟失，而且所有數據都是按其發送順序進行交付。

可靠傳輸協議

實現服務模型就需要可靠的傳輸協議。但是由於可靠傳輸協議的下層協議可能是不可靠的，所以可靠傳輸協議的實現比較復雜。

構造可靠傳輸協議

1. 經完全可靠信道的可靠數據傳輸：rdt 1.0

??先是考慮最簡單的情況，底層信道是完全可靠的。因為信道是完全可靠的，所以發送方傳輸給接收方的數據會沒有比特差錯，接收方也不必向發送方提供任何反饋信息。

2. 經具有比特差錯信道的可靠數據傳輸：rdt 2.0

??在實際底層信道中傳輸的分組中的比特可能會受損。在分組的傳輸、傳播或者緩存的過程中，這種比特差錯常發生在網絡的物理部件中。現在我們繼續假定所有發送的分組（某些比特會受損）將按其發送順序被接收。
??接收方接收到發送方的分組後，需要告知之發送方自己收到的分組是正確的、還是有比特錯誤的（發送發就會重傳該分組）。基於這樣的傳重傳機制的可靠傳輸協議稱為自動重傳請求(Automatic Repeat reQuest ARQ)協議

??在ARQ協議中需要三種協議功能來處理比特差錯

• 差錯檢測
  差錯檢測機制使得接收方能夠檢測到分組中出現了比特差錯。
  例如：UDP中的檢驗和字段是一種差錯檢測機制，在數據連路層會使用CRC循環冗余檢測機制進行差錯檢測。

• 接收方反饋
  因為發送方和接收方通常在不同端系統上執行，發送方要了解接收方的情況（分組是否被正確接收）的唯一途徑就是讓接收方提供明確的反饋消息給發送方。
  rdt2.0協議將從接收方向發送方回送ACK或者NAK分組。理論上分組只需一個比特長，如0表示NAK，1表示ACK。

• 重傳
  接收收到有差錯的分組時，發送方將重傳該分組。

??需要註意：當發送發處於等待ACK或者NAK的狀態時，它不能從上層獲得更多的數據。也就是說發送方不會發送一塊新的數據，除非發送方確信接收方已正確接收當前分組。此時的rdt 2.0被稱為停止等待(stop-and-wait)協議

??協議rdt2.0看起來雖然可以運行了，但是有一個致命的缺陷，沒有考慮到ACK/NAK分組受損的可能性！

??通常解決受含糊不清的ACK/NAK時，發送方會重傳當前數據分組。
這樣會讓接收方的信道中出現冗余分組。
??解決冗余分組的方法是在數據分組中添加一新字段，讓發送方對其數據分組進行編號，將分組的編號填入該字段中。接收方只需要檢查序號就可以得知該分組是否是一次重傳。
??對於停止等待協議來說，1比特序號就可以了，重傳的分組序號與最近接收到的分組序號相同，新的分組序號會變化（使用模2使序號前移）。目前我們假定的是信道不會丟失分組，所以ACK/NAK分組本身不需要指明他們要確認的分組序號。發送方接收到ACK/NAK分組是為響應最近發送的數據分組而生成的。

??rdt2.1反映出目前正在發送的分組或希望接收的分組的序號是0還是1。
??rdt2.1使用了從接收方收到的肯定確認和否定確認。當接收方收到失序分組時，發送肯定確認。如果收到受損分組，則發送否定確認。
??如果不發送NAK，而是對正確接收到的分組發送一個ACK，那麽也能得到與NAK一樣的效果。發送方收到對同一個分組的兩個ACK（接收到了冗余ACK）後，就可以知道接收方沒有正確接收被確認兩次的分組後面的分組。
??這也產生了協議rdt2.2。rdt2.2是在有比特差錯信道上實現的一個無NAK的可靠傳輸協議，此時ACK報文就需明確所確認的分組序號。

3. 經具有比特差錯的丟包信道的可靠傳輸：rdt3.0(比特交替協議)

??在今天的計算機網絡中除了比特會出現受損也會出現丟包的情況。所以，現在協議需要關註兩個問題：怎樣檢測丟包以及丟包後該做些什麽。
??有很多方法用於解決丟包問題。這裏，我們讓發送方負責檢測和恢復丟包工作。接收方確實沒有接收到數據分組和接收方響應給發送方的ACK丟失，都會讓發送發收不到接收方的響應。發送方等待足夠長的時間來確認分組丟失，然後進行重傳分組。如果是因為ACK丟失，發送方重傳分組則會造成冗余數據分組。但是,rdt2.2中的序號可以解決接收方收到冗余分組的問題。
??在發送方的眼裏，重傳是一種萬能靈藥。無論數據分組丟失還是ACK丟失都可以采用同樣的動作：重傳。基於時間的重傳機制，需要一個倒計時定時器,在一個給定的時間量過期後，可中斷發送方。因此，發送方需要做到 ① 每次發送一個分組（包括第一次和重傳分組）時，便啟動一個定時器 ② 響應定時器中 斷 ③ 終止定時器

??歸納：在構造可靠傳輸協議的過程中我們用到了檢驗和、序號、定時器、肯定和否定確認分組技術。

計算機網絡自頂向下方法——可靠數據傳輸原理1（構造可靠數據傳輸協議）