數據傳輸引擎涉及到的rdt(可靠數據傳輸)，所以學習一下
在TCP網絡傳輸中，數據都是通過網絡上可靠的通道來傳輸。但實際存在許多狀況，如資料位元錯誤、封包遺失，造車資料不可靠，所以必須建立有效的傳輸協定。
1.rdt1.0
rdt的模型主要是用FSM(Finite State Machine-有限狀態機)來定義狀態與操作方式。
rdt1.0是假設使用最可靠的通道情況。主要有傳輸端與接收端兩個部分，資料傳輸方式很單純，傳輸端等待上層傳資料進來，收到上面的資料以後裝成封包送出去。
接收端收到封包以後，將封包解開，把訊息往上送。
2.rdt2.0
2.0考慮到了資料錯誤的情形，當接收端收到資料，會有ACK(相當於OK)與NAK(相當於Send Again)兩種訊息，當資料接收到以後確認無誤，會送ACK給來源已確定資料無誤。當偵測到錯誤時 會傳回NAK通知來源端再送一次。
3.rdt2.1
2.1新增了sequence number，同樣使用ACK與NAK來確認訊息，封包的號碼可以用來確認是否重新傳輸封包。例如接收端在等待編號0的封包，結果收到封包1，此時會回傳ACK1給來源端，而正在等候ACK0的來源端收到ACK1 表示封包0可能遺失，所以會再重送封包0.
4.rdt2.2
一次使用兩種確認訊息 處理起來比較費力，因此2.2中移除NAK的訊息，在ACK中加入編號 就可以達到確認與否認的效果。
5.rdt3.0
3.0同時考慮到封包遺失與資料錯誤的情形，除了使用ACK機制，另外在傳送端多了倒數計時器，封包送出去如果超過時間仍未收到ACK或是收到不正確編號的ACK，則再送出封包一次。
6.Stop-and_Wait與Pipelined Protocol
rdt3.0雖然確保了資料的可靠性，可是它採用Stop-and-Wait機制，效能方面無法讓人接受，因爲送出封包後必須等待對方迴應才能繼續傳送，假如連線Delay太長，整體效率會嚴重低落。
爲解決這問題，後來發展出 Pipelined Protocol，可以讓傳送端同時傳送多個封包不需等待確認相對的，傳輸端與接收端都必須增加封包的暫存空間與序列號碼。當其中的封包出現錯誤時有不同的回覆方法，主要有Go-Back-N(GBN)與Selective Repeat(SR)兩種方法。
Go-Back-N(GBN)
傳輸多個封包 必須有個暫存的區域，暫存的區域中存在着窗格大小(Window Size) N，存放着各種封包(已確認、已送出但未收到ACK、未送出的封包等等)。
接收端也會開啓窗格來接收封包，會記着目前收到封包的編號，假設收到順序不對的封包N+1(等待接收第N個，下一個傳來的卻是第N+1號)，會將N以後的封包全部丟棄，此時傳送端一直沒收到ACK(N)，會把N號以後的封包全部重新傳送出去。
Selective Repear(SR)
GBN的傳送方法往往會造成不必要的重複，因此SR的傳送方法就是隻針對未收到的封包做重新傳輸的動作。首先規劃出大小爲N的窗格來限制大小，窗格的基底會停留在最近一個尚未收到ACK的封包區域，當封包時間逾時會重新送出封包，直到收到該封包的ACK 窗格基底纔會往前移動。
7.Flow Control(流量控制)
雖然TCP接收端有緩衝區，但有時候應用程序讀取訊息的速度小於傳輸端傳送訊息的速度，假如緩衝區滿了還繼續傳資料過來，會造成緩衝區溢位的情況，爲避免此狀況，設了一個"receive window(接收窗格簡寫成rcvWindow)"變量，用來記錄緩衝區剩餘的空間有多少。
當接收端收到訊息後，會回傳給傳送端rcvWindow的數值，如果rcvWindow=0，傳送端會停止傳輸資料但這個方法會造成問題，假設停止後 接收端一直沒訊息通知傳送端，此時傳送端不會運作，而接收緩衝區也是空的，資料傳輸停止。
因此當接收端rcvWindow=0時，傳送端會持續傳送一個1byte的區段給接收端 以確認緩衝區可否繼續接收資料。
