將TCP與UDP這樣的簡單傳輸協(xié)議區(qū)分開來的是它傳輸數(shù)據(jù)的質(zhì)量。TCP對于發(fā)送數(shù)據(jù)進(jìn)行跟蹤，這種數(shù)據(jù)管理需要協(xié)議有以下兩大關(guān)鍵功能：

可靠性：保證數(shù)據(jù)確實(shí)到達(dá)目的地。如果未到達(dá)，能夠發(fā)現(xiàn)并重傳。

數(shù)據(jù)流控：管理數(shù)據(jù)的發(fā)送速率，以使接收設(shè)備不致于過載。

要完成這些任務(wù)，整個協(xié)議操作是圍繞滑動窗口確認(rèn)機(jī)制來進(jìn)行的。因此，理解了滑動窗口，也就是理解了TCP。

TCP面向流的滑動窗口確認(rèn)機(jī)制:

TCP將獨(dú)立的字節(jié)數(shù)據(jù)當(dāng)作流來處理。一次發(fā)送一個字節(jié)并接收一次確認(rèn)顯然是不可行的。即使重疊傳輸(即不等待確認(rèn)就發(fā)送下一個數(shù)據(jù))，速度也還是會非常緩慢。

TCP消息確認(rèn)機(jī)制如上圖所示，首先，每一條消息都有一個識別編號，每一條消息都能夠被獨(dú)立地確認(rèn)，因此同一時刻可以發(fā)送多條信息。設(shè)備B定期發(fā)送給A一條發(fā)送限制參數(shù)，制約設(shè)備A一次能發(fā)送的消息***數(shù)量。設(shè)備B可以對該參數(shù)進(jìn)行調(diào)整，以控制設(shè)備A的數(shù)據(jù)流。

為了提高速度，TCP并沒有按照字節(jié)單個發(fā)送而是將數(shù)據(jù)流劃分為片段。片段內(nèi)所有字節(jié)都是一起發(fā)送和接收的，因此也是一起確認(rèn)的。確認(rèn)機(jī)制沒有采用message ID字段，而是使用的片段內(nèi)***一個字節(jié)的sequence number。因此一次可以處理不同的字節(jié)數(shù)，這一數(shù)量即為片段內(nèi)的sequence number。

TCP數(shù)據(jù)流的概念劃分類別

假設(shè)A和B之間新建立了一條TCP連接。設(shè)備A需要傳送一長串?dāng)?shù)據(jù)流，但設(shè)備B無法一次全部接收，所以它限制設(shè)備A每次發(fā)送分段指定數(shù)量的字節(jié)數(shù)，直到分段中已發(fā)送的字節(jié)數(shù)得到確認(rèn)。之后，設(shè)備A可以繼續(xù)發(fā)送更多字節(jié)。每一個設(shè)備都對發(fā)送，接收及確認(rèn)數(shù)據(jù)進(jìn)行追蹤。

如果我們在任一時間點(diǎn)對于這一過程做一個“快照”，那么我們可以將TCP buffer中的數(shù)據(jù)分為以下四類，并把它們看作一個時間軸：

1. 已發(fā)送已確認(rèn) 數(shù)據(jù)流中最早的字節(jié)已經(jīng)發(fā)送并得到確認(rèn)。這些數(shù)據(jù)是站在發(fā)送設(shè)備的角度來看的。如下圖所示，31個字節(jié)已經(jīng)發(fā)送并確認(rèn)。

2. 已發(fā)送但尚未確認(rèn) 已發(fā)送但尚未得到確認(rèn)的字節(jié)。發(fā)送方在確認(rèn)之前，不認(rèn)為這些數(shù)據(jù)已經(jīng)被處理。下圖所示14字節(jié)為第2類。

3. 未發(fā)送而接收方已Ready 設(shè)備尚未將數(shù)據(jù)發(fā)出，但接收方根據(jù)最近一次關(guān)于發(fā)送方一次要發(fā)送多少字節(jié)確認(rèn)自己有足夠空間。發(fā)送方會立即嘗試發(fā)送。如圖，第3類有6字節(jié)。

4. 未發(fā)送而接收方Not Ready 由于接收方not ready，還不允許將這部分?jǐn)?shù)據(jù)發(fā)出。

接收方采用類似的機(jī)制來區(qū)分已接收并已確認(rèn)，尚未接受但準(zhǔn)備好接收，以及尚未接收并尚未準(zhǔn)備好接收的數(shù)據(jù)。實(shí)際上，收發(fā)雙方各自維護(hù)一套獨(dú)立的變量，來監(jiān)控發(fā)送和接收的數(shù)據(jù)流落在哪一類。

Sequence Number設(shè)定與同步：

發(fā)送方和接收方必須就它們將要為數(shù)據(jù)流中的字節(jié)指定的sequence number達(dá)成一致。這一過程稱為同步，在TCP連接建立時完成。為了簡化假設(shè)***個字節(jié)sequence number是1，按照上圖示例，四類字節(jié)如下：

1. 已發(fā)送已確認(rèn)字節(jié)1至31。

2. 已發(fā)送但尚未確認(rèn)字節(jié)32至45。

3. 未發(fā)送而接收方已Ready字節(jié)46至51。

4. 未發(fā)送而接收方Not Ready字節(jié)52至95。#p#

發(fā)送窗口與可用窗口：

整個過程關(guān)鍵的操作在于接收方允許發(fā)送方一次能容納的未確認(rèn)的字節(jié)數(shù)。這稱為發(fā)送窗口，有時也稱為窗口。該窗口決定了發(fā)送方允許傳送的字節(jié)數(shù)，也是2類和3類的字節(jié)數(shù)之和。因此，***兩類(接收方準(zhǔn)備好而尚未發(fā)送，接收方未準(zhǔn)備好)的分界線在于添加了從***個未確認(rèn)字節(jié)開始的窗口。本例中，***個未確認(rèn)字節(jié)是32，整個窗口大小是20。

可用窗口的定義是：考慮到正在傳輸?shù)臄?shù)據(jù)量，發(fā)送方仍被允許發(fā)送的數(shù)據(jù)量。實(shí)際上等于第3類的大小。左邊界就是窗口中的***個字節(jié)(字節(jié)32)，右邊界是窗口中***一個字節(jié)(字節(jié)51)。概念的詳細(xì)解釋看下圖。

可用窗口字節(jié)發(fā)送后TCP類目與窗口大小的改變：

當(dāng)上圖中第三類的6字節(jié)立即發(fā)送之后，這6字節(jié)從第3類轉(zhuǎn)移到第2類。字節(jié)變?yōu)槿缦拢?/p>

1. 已發(fā)送已確認(rèn)字節(jié)1至31。

2. 已發(fā)送但尚未確認(rèn)字節(jié)32至51。

3. 未發(fā)送而接收方已Ready字節(jié)為0。

4. 未發(fā)送而接收方Not Ready字節(jié)52至95。

確認(rèn)處理以及窗口縮放：

過了一段時間，目標(biāo)設(shè)備向發(fā)送方傳回確認(rèn)信息。目標(biāo)設(shè)備不會特別列出它已經(jīng)確認(rèn)的字節(jié)，因?yàn)檫@會導(dǎo)致效率低下。目標(biāo)設(shè)備會發(fā)送自上一次成功接收后的最長字節(jié)數(shù)。

例如，假設(shè)已發(fā)送未確認(rèn)字節(jié)(32至45)分為4段傳輸：32-34，35-36，37-41，42-45。第1，2，4已經(jīng)到達(dá)，而3段沒有收到。接收方只會發(fā)回32-36的確認(rèn)信息。接收方會保留42-45但不會確認(rèn)，因?yàn)檫@會表示接收方已經(jīng)收到了37-41。這是很必要的，因?yàn)門CP的確認(rèn)機(jī)制是累計(jì)的，只使用一個數(shù)字來確認(rèn)數(shù)據(jù)。這一數(shù)字是自上一次成功接收后的最長字節(jié)數(shù)。假設(shè)目標(biāo)設(shè)備同樣將窗口設(shè)為20字節(jié)。

當(dāng)發(fā)送設(shè)備接收到確認(rèn)信息，則會將一部分第2類字節(jié)轉(zhuǎn)移到第1類，因?yàn)樗鼈円呀?jīng)得到了確認(rèn)。由于5個字節(jié)已被確認(rèn)，窗口大小沒有改變，允許發(fā)送方多發(fā)5個字節(jié)。結(jié)果，窗口向右滑動5個字節(jié)。同時5個字節(jié)從第二類移動到第1類，5個字節(jié)從第4類移動至第3類，為接下來的傳輸創(chuàng)建了新的可用窗口。因此，在接收到確認(rèn)信息以后，看起來如下圖所示。字節(jié)變?yōu)槿缦拢?/p>

1. 已發(fā)送已確認(rèn)字節(jié)1至36。

2. 已發(fā)送但尚未確認(rèn)字節(jié)37至51。

3. 未發(fā)送而接收方已Ready字節(jié)為52至56。

4. 未發(fā)送而接收方Not Ready字節(jié)57至95。

每一次確認(rèn)接收以后，這一過程都會發(fā)生，從而讓窗口滑動過整個數(shù)據(jù)流以供傳輸。

處理丟失確認(rèn)信息：

但是丟失的42-45如何處理呢?在接收到第3段(37-41)之前，接收設(shè)備不會發(fā)送確認(rèn)信息，也不會發(fā)送這一段之后字節(jié)的確認(rèn)信息。發(fā)送設(shè)備可以將新的字節(jié)添加到第3類之后，即52-56。發(fā)送設(shè)備之后會停止發(fā)送，窗口停留在37-41。

TCP包括一個傳輸及重傳的計(jì)時機(jī)制。TCP會重傳丟失的片段。但有一個缺陷是：因?yàn)樗粫γ恳粋€片段分別進(jìn)行確認(rèn)，這可能會導(dǎo)致其他實(shí)際上已經(jīng)接收到的片段被重傳(比如42至45)。