TCP IP複習筆記（二）

上一次算是複習了一下tcp協議的大體原理。由於tcp中的內容實在繁雜，光是其中的乙個功能的實現原理就足夠寫一篇部落格。於是也只好分成好幾篇複習筆記分別來完成，算是複習結果的乙個檢驗。

在上篇中，就複習到tcp可靠傳輸的實現原理，那就是超時重傳。那麼什麼是超時重傳呢？舉個栗子，a向b傳送資料，a向b傳送完乙個資料封包完畢後就立即設定乙個定時器，在定時器的時間內若未收到b傳送回來的確認報文段，a就重新傳送這個報文段並重置定時器，b收到資料報文後就向a傳送確認。

當然，這裡還有種情況，那就是a傳送的報文並沒有丟失，而是滯留在網路中的某個節點上，甚至在a給b重傳的報文後到達b，此時b對這個遲到的報文只是簡單的丟掉就ok了。

就這樣，a傳送乙個報文段，b確認乙個，a沒收到確認就重傳。這樣，就能保證a傳送的資料與b收到的資料都是一致的了。

這在tcp協議中稱為是自動重傳請求arq（automatic repeat request）。

雖然上面是解決了可靠傳輸的問題。可是問題在於，這樣傳送乙個確認乙個似乎效率有點太低了。

所以tcp協議為了解決這個問題，就使用了連續arq協議。在複習連續arq協議之前，還需要先複習一下tcp的滑動視窗機制。

之所以要先複習這個滑動視窗機制是因為滑動視窗機制正是tcp協議的精髓所在。tcp協議中的可靠傳輸、流量控制和擁塞控制都是基於滑動視窗機制來實現的。

就像上面的看到的那樣，虛線中的就是滑動視窗。

傳送方和接收方各有乙個滑動視窗，分別稱為傳送視窗和接收視窗。

簡單來說，滑動視窗協議規定允許傳送方一次性將視窗中的資料封包傳送出去而不需要等到接收方發來的確認。

只有傳送方收到接收方傳送來的確認後才會將視窗向右滑動。

從名字上來理解，所謂的連續確認就是連續傳送若干個資料封包再進行確認。

tcp也確實是這麼幹的。

連續arq就是先接收若干資料封包然後再對收到的最後乙個按序到達的進行確認。什麼意思呢？

比如說，a傳送了序號是5-13這幾個序號的封包，而b收到了5-6，8-13這些封包，7號封包暫時沒收到。那麼這時，b就會給a傳送確認封包，封包中的seq=7（上篇中的封包序號）。這樣，a收到了b傳送的確認封包後就會知道6號封包以後（這裡不包括6）的封包b沒收到，於是就會重發7-13的封包。

那麼結合滑動視窗協議呢？

滑動視窗的示意圖大概像下面這個樣子：

結合第一幅圖看。

其實就像上面說的，a先傳送完它的傳送視窗中的內容後，就停止傳送，如果還沒有收到來自b的確認的話就不能往右滑，因為它得儲存視窗中的內容準備超時重傳給b。只有收到來自b的確認後才會往右滑動視窗，準備傳送新的資料。

那麼，向右滑動多少呢？

當然是滑動到最後收到的來自b的確認啊。還是接上面的栗子，比如說視窗大小是9（就僅僅是舉個栗子，實際挺大的），a傳送完5-13號封包後，收到了來自b的對6號封包的確認，那麼a的傳送視窗就滑動到7-15號封包的位置，準備傳送14-15號封包。

此時b的接收視窗又如何呢？

b的接收視窗只有再傳送完對連續收到的最後乙個封包後才會忘右滑動。

承接上例， b收到了5-6， 8-15號封包，在傳送完seq=8的確認封包後，b的接收視窗向右滑動到8-16號的位置，準備接收14-16號封包（因為36-39已經接收到並快取起來了）。