TCP面向流的滑動窗口確認機制
TCP是面向字節(jié)流的删窒。
TCP消息確認機制如上圖所示，首先，每一條消息都有一個識別編號限番，每一條消息都能夠被獨立地確認，因此同一時刻可以發(fā)送多條信息呀舔。設備B定期發(fā)送給A一條發(fā)送限制參數(shù)弥虐，制約設備A一次能發(fā)送的消息最大數(shù)量。設備B可以對該參數(shù)進行調整媚赖，以控制設備A的數(shù)據(jù)流霜瘪。
為了提高速度，TCP并沒有按照字節(jié)單個發(fā)送而是將數(shù)據(jù)流劃分為片段惧磺。片段內所有字節(jié)都是一起發(fā)送和接收的颖对，因此也是一起確認的。確認機制沒有采用message ID字段磨隘，而是使用的片段內最后一個字節(jié)的sequence number缤底。因此一次可以處理不同的字節(jié)數(shù)，這一數(shù)量即為片段內的sequence numb番捂。
TCP滑動窗口原理
1）對于TCP會話的發(fā)送方个唧，任何時候在其發(fā)送緩存內的數(shù)據(jù)都可以分為4類：
- “已經發(fā)送并得到對端ACK的”，數(shù)據(jù)流中最早的字節(jié)已經發(fā)送并得到確認设预。這些數(shù)據(jù)是站在發(fā)送設備的角度來看的徙歼。如下圖：31個字節(jié)已經發(fā)送并確認。
- “已經發(fā)送但還未收到對端ACK的”，已發(fā)送但尚未得到確認的字節(jié)魄梯。發(fā)送方在確認之前呼股，不認為這些數(shù)據(jù)已經被處理。如下圖：淺藍色部分画恰。
- “未發(fā)送但對端允許發(fā)送的”彭谁，如下圖，綠色部分允扇。
- “未發(fā)送且對端不允許發(fā)送”缠局，如下圖，橙色部分考润。
接收方允許發(fā)送方一次能容納的未確認的字節(jié)數(shù)狭园。這稱為發(fā)送窗口，有時也稱為窗口糊治。該窗口決定了發(fā)送方允許傳送的字節(jié)數(shù)唱矛，也是“已經發(fā)送但還未收到對端ACK的”和“未發(fā)送但對端允許發(fā)送的”這兩部之和（中間兩部分）。
當收到接收方新的ACK對于發(fā)送窗口中后續(xù)字節(jié)的確認時井辜，窗口滑動绎谦，滑動原理如下圖。
每一次確認接收以后粥脚，這一過程都會發(fā)生窃肠，從而讓窗口滑動過整個數(shù)據(jù)流以供傳輸。
2）對于TCP的接收方刷允，在某一時刻在它的接收緩存內存在3種冤留。“已接收”树灶，“未接收準備接收”纤怒，“未接收并未準備接收”（由于ACK直接由TCP協(xié)議棧回復天通，默認無應用延遲泊窘，不存在“已接收未回復ACK”）。其中“未接收準備接收”稱之為接收窗口土砂。
下面舉例就滑動窗口協(xié)議做出更詳細的說明州既，這里為了簡單起見設定發(fā)送方窗口大小為2，接受方大小為1萝映∥庖叮看下面圖：
一：初始態(tài)，發(fā)送方沒有幀發(fā)出序臂，發(fā)送窗口前后沿相重合蚌卤。接收方0號窗口打開实束，等待接收0號幀；
二：發(fā)送方打開0號窗口逊彭，表示已發(fā)出0幀但尚確認返回信息咸灿。 此時接收窗口狀態(tài)不變；
三：發(fā)送方打開0侮叮、1號窗口避矢，表示0、1號幀均在等待確認之列囊榜。至此审胸，發(fā)送方打開的窗口數(shù)已達規(guī)定限度，在未收到新的確認返回幀之 前卸勺，發(fā)送方將暫停發(fā)送新的數(shù)據(jù)幀砂沛。接收窗口此時狀態(tài)仍未變；
四：接收方已收到0號幀曙求，0號窗口關閉碍庵，1號窗口打開，表示準備接收1號幀悟狱。此時發(fā)送窗口狀態(tài)不 變静浴；
五：發(fā)送方收到接收方發(fā)來的0號幀確認返回信息，關閉0號窗口芽淡，表示從重發(fā)表中刪除0號幀马绝。此時接收窗口狀態(tài)仍不變
六：發(fā)送方繼續(xù)發(fā)送2號幀豆赏，2號窗口 打開挣菲，表示2號幀也納入待確認之列。至此掷邦，發(fā)送方打開的窗口又已達規(guī)定限度白胀，在未收到新的確認返回幀之前，發(fā)送方將暫停發(fā)送新的數(shù)據(jù)幀抚岗，此時接收窗口狀態(tài) 仍不變或杠；
七：接收方已收到1號幀，1號窗口關閉宣蔚，2號窗口打開向抢，表示準備接收2號幀。此時發(fā)送窗口狀態(tài)不變胚委；
八：發(fā)送方收到接收方發(fā)來的1號幀收畢的確認信 息挟鸠，關閉1號窗口，表示從重發(fā)表中刪除1號幀亩冬。此時接收窗口狀態(tài)仍不變艘希。
發(fā)送窗口和接收窗口的關系
TCP是雙工的協(xié)議台丛，會話的雙方都可以同時接收惩嘉、發(fā)送數(shù)據(jù)。TCP會話的雙方都各自維護一個“發(fā)送窗口”和一個“接收窗口”。其中各自的“接收窗口”大小取決于應用他嫡、系統(tǒng)、硬件的限制（TCP傳輸速率不能大于應用的數(shù)據(jù)處理速率）扯再。各自的“發(fā)送窗口”則要求取決于對端通告的“接收窗口”传黄，要求相同。
滑動窗口的可靠性
TCP的滑動窗口的可靠性也是建立在“確認重傳”基礎上的凤壁。
發(fā)送窗口只有收到對端對于本段發(fā)送窗口內字節(jié)的ACK確認巍糯，才會移動發(fā)送窗口的左邊界。
接收窗口只有在前面所有的段都確認的情況下才會移動左邊界客扎。當在前面還有字節(jié)未接收但收到后面字節(jié)的情況下祟峦，窗口不會移動，并不對后續(xù)字節(jié)確認徙鱼。以此確保對端會對這些數(shù)據(jù)重傳宅楞。
應用實例
1.停止-等待協(xié)議
這時接受方的窗口和發(fā)送方的窗口大小都是1，1個比特就夠表示了袱吆，所以也叫1比特滑動窗口協(xié)議厌衙。發(fā)送方這時自然發(fā)送每次只能發(fā)送一個，并且必須等待這個數(shù)據(jù)包的ACK绞绒，才能發(fā)送下一個婶希。雖然在效率上比較低，帶寬利用率明顯較低蓬衡，不過在網絡環(huán)境較差喻杈，或是帶寬本身很低的情況下，還是適用的狰晚。
2.回退n步協(xié)議
由于停止等待協(xié)議效率太低筒饰，因此有了回退n-步協(xié)議，這也是滑動窗口協(xié)議真正的用處壁晒，這里發(fā)送的窗口大小為n瓷们，接受方的窗口仍然為1。具體看下面的圖秒咐，這里假設n=9： 首先發(fā)送方一口氣發(fā)送10個數(shù)據(jù)幀谬晕，前面兩個幀正確返回了，數(shù)據(jù)幀2出現(xiàn)了錯誤携取，這時發(fā)送方被迫重新發(fā)送2-8這7個幀攒钳，接受方也必須丟棄之前接受的3-8這幾個幀。 后退n協(xié)議的好處無疑是提高了效率歹茶，但是一旦網絡情況糟糕夕玩，則會導致大量數(shù)據(jù)重發(fā)你弦，反而不如上面的停等協(xié)議。
3.選擇重傳協(xié)議
后退n協(xié)議的問題是燎孟，當有錯誤幀出現(xiàn)后禽作，總是要重發(fā)該幀之后的所有幀，毫無疑問在網絡不是很好的情況下會進一步惡化網絡狀況揩页。
重傳協(xié)議便是用來解決這個問題旷偿。原理也很簡單，接收端總會緩存所有收到的幀爆侣，當某個幀出現(xiàn)錯誤時萍程，只會要求重傳這一個幀，只有當某個序號后的所有幀都正確收到后兔仰，才會一起提交給高層應用茫负。重傳協(xié)議的缺點在于接受端需要更多的緩存。
