一、為什么TCP是可靠傳輸？

1. 停止等待協(xié)議

通過確認與超時重傳機制實現(xiàn)可靠傳輸

在發(fā)送完一個分組后，必須暫時保留已發(fā)送的分組的副本。

分組和確認分組都必須進行編號。

超時計時器的重傳時間應(yīng)當比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。

出現(xiàn)差錯或丟失的時候，發(fā)送方會將自己備份的副本再重傳一次，直到收到接收的確認信息。當接收方收到重復(fù)的數(shù)據(jù)時，會直接丟棄，但是會給發(fā)送方請確認自己已經(jīng)收到了。

2. 改進的停止等待協(xié)議——連續(xù)ARQ協(xié)議和滑動窗口協(xié)議

上面的停止等待協(xié)議每發(fā)送一組數(shù)據(jù)就必須等到接收方回復(fù)確認后，再發(fā)起第二組數(shù)據(jù)，如果出現(xiàn)超時重傳的話，效率更低。因此為了提高傳輸?shù)男剩倪M了等待傳輸協(xié)議。

連續(xù)ARQ協(xié)議和滑動窗口協(xié)議的機制是以接收方回復(fù)確認為單位，每次連續(xù)發(fā)送一個滑動窗口指定的數(shù)據(jù)組。示例圖如下：

2.1 什么是滑動窗口協(xié)議？（發(fā)送方怎么發(fā)送數(shù)據(jù)）

滑動窗口是由發(fā)送方維護的類似指針的變量，在每收到一個接收方的確認消息后，該指針向前移動并發(fā)送數(shù)據(jù)，到窗口指定大小的數(shù)據(jù)組時停下，等待接收方的確認。示意看圖：

2.2 接收方怎么回復(fù)確認？

累積確認機制

發(fā)送方不對收到的分組逐個發(fā)送確認，而是對按序到達的最后一個分組發(fā)送確認，這樣就表示：到這個分組為止的所有分組都已正確收到了。

優(yōu)點：容易實現(xiàn)，即使確認丟失也不必重傳。

缺點：不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。

Go-back-N（回退 N）

為了解決上述同一窗口中數(shù)據(jù)組不能完整確認的問題，連續(xù)ARQ協(xié)議采用了回退機制。比如說：發(fā)送方發(fā)送了前 5 個分組，而中間的第 3 個分組丟失了。這時接收方只能對前兩個分組發(fā)出確認。發(fā)送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。這就叫做 Go-back-N（回退 N），表示需要再退回來重傳已發(fā)送過的 N 個分組。

結(jié)論：當通信線路質(zhì)量不好時，連續(xù) ARQ 協(xié)議會帶來負面的影響?？赡苓€不如傳統(tǒng)的停止等待協(xié)議。

3. TCP可靠傳輸?shù)膶崿F(xiàn)

TCP 連接的每一端都必須設(shè)有兩個窗口——一個發(fā)送窗口和一個接收窗口。

TCP 的可靠傳輸機制用字節(jié)的序號進行控制。TCP 所有的確認都是基于序號而不是基于報文段。

TCP 兩端的四個窗口經(jīng)常處于動態(tài)變化之中。

TCP連接的往返時間 RTT 也不是固定不變的。需要使用特定的算法估算較為合理的重傳時間。

3.1 以字節(jié)為單位的滑動窗口技術(shù)

滑動窗口是面向字節(jié)流的，為了方便記住每個分組的序號，下面的圖解以一個分組假設(shè)100個字節(jié)，為了方便畫圖表示，將分組進行編號簡化表示，如圖所示，但是要記住，每一個分組的序號是多少。

3.2 改進的確認——選擇確認(SACK)

TCP通信時，如果發(fā)送序列中間某個數(shù)據(jù)包丟失，TCP會通過重傳最后確認的分組后續(xù)的分組，這樣原先已經(jīng)正確傳輸?shù)姆纸M也可能重復(fù)發(fā)送，降低了TCP性能。SACK（Selective Acknowledgment，選擇確認）技術(shù)，使TCP只重新發(fā)送丟失的包，不用發(fā)送后續(xù)所有的分組，而且提供相應(yīng)機制使接收方能告訴發(fā)送方哪些數(shù)據(jù)丟失，哪些數(shù)據(jù)已經(jīng)提前收到等。在建立 TCP 連接時，就要在 TCP 首部的選項中加上“允許 SACK”的選項，而雙方必須都事先商定好。原來首部中的“確認號字段”的用法仍然不變。只是以后在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續(xù)的字節(jié)塊的邊界。

選擇性確認最多表示4個邊界：由于首部選項的長度最多只有 40 字節(jié)。需要一個字節(jié)指明是SACK選項，另一個字節(jié)指明占多少字節(jié)。而指明一個邊界就要用掉 4 字節(jié)。在選項中最多只能指明 4 個字節(jié)塊的邊界信息。因4個字節(jié)塊共8個邊界信息。

抓包分析：

3.3 超時重傳時間的選擇?

重傳機制是 TCP 中最重要和最復(fù)雜的問題之一。TCP 每發(fā)送一個報文段，就對這個報文段設(shè)置一次計時器。只要計時器設(shè)置的重傳時間到但還沒有收到確認，就要重傳這一報文段。那么這個重傳時間到底應(yīng)該設(shè)置多少呢？這里面有學(xué)問。以下是我截取的“手抄報”，暫時看不懂。建議跳過。

加權(quán)平均往返時間

TCP 保留了 RTT 的一個加權(quán)平均往返時間 RTTS（這又稱為平滑的往返時間）。第一次測量到 RTT 樣本時，RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTTS：

超時計時器設(shè)置的超時重傳時間RTO

往返時間的測量

Karn算法

二、TCP的流量控制

流量控制(flow control)就是讓發(fā)送方的發(fā)送速率不要太快，既要讓接收方來得及接收，也不要使網(wǎng)絡(luò)發(fā)生擁塞。利用滑動窗口機制可以很方便地在 TCP 連接上實現(xiàn)流量控制。?

流量控制舉例說明：

零窗口處理——持續(xù)計數(shù)器

考慮上面的例子中，當A發(fā)送的數(shù)據(jù)已經(jīng)到達B的接收窗口上限，此時A就必須等待B處理了部分數(shù)據(jù)后，待接收窗口有空閑的時候，再次發(fā)送數(shù)據(jù)，那么A是怎么知道B的接收窗口何時有空閑呢?這時就用到了持續(xù)計時器。

TCP 為每一個連接設(shè)有一個持續(xù)計時器。只要 TCP 連接的一方收到對方的零窗口通知，就啟動持續(xù)計時器。若持續(xù)計時器設(shè)置的時間到期，就發(fā)送一個零窗口探測報文段（僅攜帶 1 字節(jié)的數(shù)據(jù)），而對方就在確認這個探測報文段時給出了現(xiàn)在的窗口值。若窗口仍然是零，則收到這個報文段的一方就重新設(shè)置持續(xù)計時器。若窗口不是零，則死鎖的僵局就可以打破了。

三、TCP的傳輸效率

關(guān)于TCP的傳輸效率問題，需要從三方面來考慮，1.何時發(fā)送；2.少字節(jié)發(fā)送數(shù)據(jù)問題；3.糊涂窗口綜合癥問題

3.1 TCP報文的發(fā)送時機：

第一種機制是 TCP 維持一個變量，它等于最大報文段長度 MSS。只要緩存中存放的數(shù)據(jù)達到 MSS 字節(jié)時，就組裝成一個 TCP 報文段發(fā)送出去。
第二種機制是由發(fā)送方的應(yīng)用進程指明要求發(fā)送報文段，即 TCP 支持的推送(push)操作。
第三種機制是發(fā)送方的一個計時器期限到了，這時就把當前已有的緩存數(shù)據(jù)裝入報文段（但長度不能超過 MSS）發(fā)送出去。

3.2 少量字節(jié)發(fā)送數(shù)據(jù)問題：

問題描述：如果應(yīng)用程序一次產(chǎn)生一字節(jié)數(shù)據(jù)，這樣會導(dǎo)致網(wǎng)絡(luò)由于太多的包而過載。如：從鍵盤輸入的一個字符，占用一個字節(jié)，可能在傳輸上造成41字節(jié)的包，其中包括1字節(jié)的有用信息和40字節(jié)的標題數(shù)據(jù)。

解決方案（NAGLE算法）：發(fā)送端的應(yīng)用進程將欲發(fā)送的數(shù)據(jù)逐個字節(jié)地送到TCP緩存，則發(fā)送端就將第一個字符先發(fā)送出去。將后面到達的字符都緩存起來。當接收端收到對第一個字符確認后，再將緩存中的所有字符裝成一個報文段發(fā)送出去，同時繼續(xù)對隨后到在的字符進行緩存。只有在收到對前一個報文段確認后才繼續(xù)發(fā)送下一個報文段。

3.3 糊涂窗口綜合癥問題：

問題描述：設(shè)想一種情況：接收端緩存已滿，而交互式的應(yīng)用進程一次只從緩存中讀取一個字符，然后向發(fā)送端發(fā)送確認，并將窗口設(shè)置1個字節(jié)。接著發(fā)送端又發(fā)來1個字符。接收端發(fā)回確認，仍然將窗口設(shè)置為1個字節(jié)。這樣下去，網(wǎng)絡(luò)效率非常低。

解決方案：接收端等待一段時間，使得緩存已有足夠空間容納；或者緩存已有一半空的空間，再向發(fā)送端發(fā)送確認。
編輯：hfy