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

????????我們假定數(shù)據(jù)傳輸只在一個方向進行，即A發(fā)送數(shù)據(jù)，B給出確認。這樣的好處是使討論限于兩個窗口，即發(fā)送方A的發(fā)送窗口和接收方B的接收窗口。

以字節(jié)為單位滑動窗口

發(fā)送方構(gòu)造窗口

?

窗口前沿和后沿的移動情況

描述發(fā)送窗口的狀態(tài)需要三個指針?

傳輸步驟詳解

? ? ? ? 注意，這里使用的累積確認和超時重傳機制：這樣在延遲的時間內(nèi)收到多個連續(xù)的包，可以累積一個包，確認通過延遲和累計確認的方式，減少了回復(fù)確認包的數(shù)量。

---

窗口和緩存的關(guān)系

????????

? ? ? ? 在TCP的面向字節(jié)流的特點得知：把字節(jié)流寫入TCP的發(fā)送緩存，接收方的應(yīng)用進程從TCP的接收緩存中讀取字節(jié)流：

????????首先我們要明確兩點：

????????第一，緩存空間和序號空間都是有限的，并且都是循環(huán)使用的。
????????第二，由于緩存或窗口中實際的字節(jié)數(shù)可能很大，因此圖例僅僅是個示意圖，并不代表具體大小數(shù)值關(guān)系
?

?發(fā)送緩存

?

發(fā)送緩存用來暫時存放:
(1)發(fā)送應(yīng)用程序傳送給發(fā)送方TCP準(zhǔn)備發(fā)送的數(shù)據(jù);

(2)TCP已發(fā)送出但尚未收到確認的數(shù)據(jù)。

---

????????發(fā)送窗口通常只是發(fā)送緩存的一部分。已被確認的數(shù)據(jù)應(yīng)當(dāng)從發(fā)送緩存中刪除，因此發(fā)送緩存和發(fā)送窗口的后沿是重合的。

????????發(fā)送應(yīng)用程序最后寫入發(fā)送緩存的字節(jié)減去最后被確認的字節(jié)，就是還保留在發(fā)送緩存中的被寫入的字節(jié)數(shù)。

????????發(fā)送應(yīng)用程序必須控制寫入緩存的速率，不能太快，否則發(fā)送緩存就會沒有存放數(shù)據(jù)的空間。

接收緩存?

接收緩存用來暫時存放:
(1)按序到達的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù);

(2)未按序到達的數(shù)據(jù)。

---

????????如果收到的分組被檢測出有差錯，則要丟棄。

????????如果接收應(yīng)用程序來不及讀取收到的數(shù)據(jù)，接收緩存最終就會被填滿，使接收窗口減小到零。

????????反之，如果接收應(yīng)用程序能夠及時從接收緩存中讀取收到的數(shù)據(jù)，接收窗口就可以增大，但最大不能超過接收緩存的大小。

強調(diào)三點重要的關(guān)系?

????????第一，雖然A的發(fā)送窗口是根據(jù)B的接收窗口設(shè)置的，但在同一時刻，A的發(fā)送窗口并不總是和B的接收窗口一樣大。這是因為通過網(wǎng)絡(luò)傳送窗口值需要經(jīng)歷一定的時間滯后性

? ? ? ? 另外，發(fā)送方A還可能根據(jù)網(wǎng)絡(luò)當(dāng)時的擁塞情況適當(dāng)減小自己的發(fā)送窗口數(shù)值。

? ? ? ? 第二，TCP通常是把不按序到達的數(shù)據(jù)先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應(yīng)用進程。

? ? ? ? 第三，TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。接收方可以在合適的時候發(fā)送確認，也可以在自己有數(shù)據(jù)要發(fā)送時把確認信息順便捎帶上。

? ? ? ? 需要注意兩點：

• 一是接收方不應(yīng)過分推遲發(fā)送確認，否則會導(dǎo)致發(fā)送方不必要的重傳，這反而浪費了網(wǎng)絡(luò)的資源。
  • TCP標(biāo)準(zhǔn)規(guī)定，確認推遲的時間不應(yīng)超過0.5秒。若收到一連串具有最大長度的報文段，則必須每隔一個報文段就發(fā)送一個確認。
• 二是捎帶確認實際上并不經(jīng)常發(fā)生，因為大多數(shù)應(yīng)用程序很少同時在兩個方向上發(fā)送數(shù)據(jù)。
  ?

????????第四、TCP的通信是全雙工通信。通信中的每一方都在發(fā)送和接收報文段。因此，每一方都有自己的發(fā)送窗口和接收窗口。在談到這些窗口時，一定要弄清楚是哪一方的窗口

超時重傳時間?

?

RTTs??

? ? ? ? TCP采用了一種自適應(yīng)算法，它記錄一個報文段發(fā)出的時間，以及收到的相應(yīng)的確認時間。這兩個時間之差就是報文段往返時間RTT?

超時重傳時間RTO的計算?

往返時間測量相當(dāng)復(fù)雜?

????????通過上述兩個例子可以看出:當(dāng)發(fā)送方出現(xiàn)超時重傳后，收到確認報文段時是無法判斷出該確認到底是對原數(shù)據(jù)報文段的確認還是對重傳數(shù)據(jù)報文段的確認,也就是無法準(zhǔn)確測量出RTT，進而無法正確計算RTO。

練習(xí)?

選擇確認SACK

? ? ? ? 若收到的報文段無差錯只是未按序號，中間還缺少一些序號的數(shù)據(jù)，那么能否設(shè)法只傳送缺少的數(shù)據(jù)而不重傳已經(jīng)正確到達接收方的數(shù)據(jù)?

????????選擇確認(Selective ACK)就是一種可行的處理方法。
?

說明SACK的工作原理?

????????左邊界指出字節(jié)塊的第一個字節(jié)的序號，但右邊界減1才是字節(jié)塊的最后一個序號。

TCP的流量控制?

? ? ? ? 若發(fā)送方數(shù)據(jù)發(fā)送得過快，接收方就可能來不及接收，這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方發(fā)送速率不要太快，要讓接收方來得及接收。?

TCP的流量控制的機制

????????
????????序號201到300的數(shù)據(jù)封裝成一個TCP報文段發(fā)送出去。但該報文段在傳輸過程中丟失了。這可能由于誤碼被路由器丟棄或路由器繁忙而丟棄。

? ? ? ? 注意，上述為第一次流量控制的過程。

超時重傳及第二次流量控制

第三次流量控制

TCP持續(xù)計時器?

????????設(shè)主機B向主機A發(fā)送了零窗口的報文段后不久，主機B的接收緩存又有了一些可用空間。于是主機B向主機A發(fā)送了接收窗口等于300的報文段。

????????然而，這個報文段在傳輸過程中丟失了主機，A會一直等待主機B發(fā)送的非零窗口的通知，而主機B會一直等待主機A發(fā)送的數(shù)據(jù)。

?TCP持續(xù)計時器的原理

????????當(dāng)主機A的持續(xù)計時器超時時，主機A立刻發(fā)送一個僅攜帶1字節(jié)數(shù)據(jù)的零窗口探測報文段。

????????假設(shè)主機B此時的接收窗口值又為零了，主機B就在確認這個零窗口探測報文段時，給出自己現(xiàn)在的接收窗口值為零。主機A再次收到零窗口通知，就再次啟動一個持續(xù)計時器。當(dāng)持續(xù)計時器超時時，主機A立刻發(fā)送一個零窗口探測報文段。

????????假設(shè)主機B此時的接收緩存又有了一些可用的空間，于是將自己的接收窗口調(diào)整為300。主機B就在確認這個零窗口探測報文段時，給出自己現(xiàn)在的接收窗口值為300，這樣就打破了死鎖的局面。

????????Q1:A發(fā)送的零窗口探測報文段到達B時，如果B此時的接收窗口值仍然為0,那么B根本就無法接受該報文段，又怎么會針對該報文段給A發(fā)回確認呢?

? ? ? ? A1：實際上TCP規(guī)定:即使接收窗口值為0，也必須接受零窗口探測報文段、確認報文段以及攜帶有緊急數(shù)據(jù)的報文段。

---

? ? ? ? Q1：如果零窗口探測報文段丟失了，還會打破死鎖的局面嗎?
? ? ? ? A1：回答是肯定的。因為零窗口探測報文段也有重傳計時器，當(dāng)重傳計時器超時后，零窗口探測報文段會被重傳。
?

例題

TCP傳輸效率?

?????????應(yīng)用進程把數(shù)據(jù)傳輸?shù)絋CP的發(fā)送緩存后，剩下的發(fā)送任務(wù)就由TCP來控制了，且可以用不同的機制來控制TCP報文段的發(fā)送時機。

三種機制來控制TCP報文段發(fā)送時機?

? ? ? ? 第一種：TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的數(shù)據(jù)達到MSS字節(jié)，就組裝一個TCP報文段發(fā)送出去。?

? ? ? ? 第二種：發(fā)送方的應(yīng)用進程指明要求發(fā)送報文段，即TCP支持的推送操作

? ? ? ? 第三種：發(fā)送方的一個計時器期限到了，將已有的緩存數(shù)據(jù)裝入報文段（但長度不能超過MSS）發(fā)送出去。

TCP傳輸?shù)膬纱髥栴}——控制發(fā)送時機?

TCP傳輸?shù)膬纱髥栴}——糊涂窗口綜合癥?

????????要解決此問題，可以讓接收方等待一段時間，使得接收緩存已有足夠容納一個最長的報文段，或者等到接收緩存已有一半空間。

TCP的擁塞控制?

? ? ? ? ?在計算機網(wǎng)絡(luò)中的鏈路容量（帶寬）、交換節(jié)點的緩存和處理機等，都是網(wǎng)絡(luò)的資源。在某段時間，若對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞，這種情況叫做擁塞。

流量控制與擁塞控制?

? ? ? ? 從控制理論的角度來看擁塞控制這個問題。?

? ? ? ? 流量控制：往往是點對點通信量的控制，是個端到端的問題。流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便接收端來得及接收。

? ? ? ? ?擁塞控制：防止過多數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不至于過載。

兩者的異同?

????????都是控制源點發(fā)送速率，一個點對點地控制，一個全局性控制。

擁塞控制圖像?

? ? ? ?橫坐標(biāo)是提供的負載，也稱為輸入負載或網(wǎng)絡(luò)負載??？v坐標(biāo)是吞吐量，代表單位時間內(nèi)從網(wǎng)絡(luò)輸出的分組數(shù)目。

? ? ? ? 在吞吐量飽和之前，網(wǎng)絡(luò)吞吐量應(yīng)等于提供的負載，故吞吐量曲線是45°斜線；而到達某一程度吞吐量不再增長而保持為水平線，這就說明提供的負載中有一部分損失掉了。

? ? ? ? 在實際的網(wǎng)絡(luò)下，隨著提供負載增大，網(wǎng)絡(luò)吞吐量的增長速率逐漸減小。也就是說吞吐量還未飽和時，就已經(jīng)有一部分的輸入分組被丟棄了。

• 當(dāng)網(wǎng)絡(luò)的吞吐量明顯小于理想的吞吐量時，網(wǎng)絡(luò)就進入了輕度擁塞狀態(tài)、
• 當(dāng)提供負載達到某一數(shù)值時，網(wǎng)絡(luò)的吞吐量反而隨提供的負載的增大而下降，這時網(wǎng)絡(luò)就進入了擁塞狀態(tài)。
• 當(dāng)提供的負載繼續(xù)增大到某一數(shù)值時，網(wǎng)絡(luò)的吞吐量就下降到零

需要注意：Q1:為什么負載越大，反而容易造成網(wǎng)絡(luò)擁塞？

????????帶寬限制：網(wǎng)絡(luò)的帶寬是有限的，它決定了網(wǎng)絡(luò)能夠同時傳輸?shù)臄?shù)據(jù)量。當(dāng)負載增大時，即有更多的數(shù)據(jù)需要通過網(wǎng)絡(luò)進行傳輸，如果這些數(shù)據(jù)量超過了網(wǎng)絡(luò)的帶寬限制，就會導(dǎo)致網(wǎng)絡(luò)擁塞

擁塞控制的兩種方法?

閉環(huán)控制?

開環(huán)控制?

衡量擁塞程度的指標(biāo)：

? ? ? ? 上述這些指標(biāo)的上升都標(biāo)志著擁塞發(fā)生的可能性增加。

TCP的擁塞控制算法

? ? ? ? 為了集中精力討論擁塞，我們控制以下兩個變量：

1. 數(shù)據(jù)是單方面?zhèn)魉偷?/span>，對方只傳送確認報文。
2. 接收方總是有足夠大的緩存空間，因而發(fā)送窗口的大小由網(wǎng)絡(luò)的擁塞程度來決定。

? ? ? ? 發(fā)送方控制擁塞窗口的原則：只要網(wǎng)絡(luò)未出現(xiàn)擁塞，擁塞窗口就可以增大，以便將更多分組發(fā)送出去；但只要網(wǎng)絡(luò)出現(xiàn)擁塞，就必須把擁塞窗口減小。
?

? ? ? ? 發(fā)送方如何判斷網(wǎng)絡(luò)出現(xiàn)擁塞：網(wǎng)絡(luò)擁塞時，路由器會將來不及處理的分組丟棄；只要發(fā)送方未按時收到確認報文，即出現(xiàn)超時，就可以估計出現(xiàn)了擁塞。因此，發(fā)送方在超市重傳計時器啟動時，就判斷網(wǎng)絡(luò)出現(xiàn)了擁塞。

慢開始算法與擁塞窗口?

?????????雙方建立連接時，擁塞窗口cwnd的初始值被設(shè)置為1。這是因為主機剛開始發(fā)送數(shù)據(jù)時，完全不知道網(wǎng)絡(luò)的擁塞情況。如果立即把大量的數(shù)據(jù)都注入網(wǎng)絡(luò)中，就有可能引起網(wǎng)絡(luò)擁塞。?

????????較好的方法是由小到大逐漸增大發(fā)送方的擁塞窗口（慢開始算法）：
?

????????發(fā)送方給接收方發(fā)送名號數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回對零號數(shù)據(jù)報文段的確認報文段。此時，第一個傳輸輪次結(jié)束，注意，傳輸輪次是指發(fā)送方給接收方。

????????發(fā)送數(shù)據(jù)報文段后的接收方給發(fā)送方發(fā)回相應(yīng)的確認報文段，一個傳輸輪次所經(jīng)歷的時間其實就是往返時間。

? ? ? ? 當(dāng)?shù)竭_慢算法門值ssthresh=16時，改用擁塞避免算法

? ? ? ? 又開始使用慢開始算法

????????

? ? ? ? 之后又是擁塞避免算法：

圖像小結(jié)：

快重傳算法和快開始算法?

? ? ? ? 主機將封裝有TCP報文的IP數(shù)據(jù)報傳輸?shù)铰酚善?#xff0c;該數(shù)據(jù)報首部誤碼被路由器丟棄，這將導(dǎo)致源主機的重傳計時器超時，并誤認為出現(xiàn)擁塞，于是將擁塞窗口的值降為1，開啟了慢開始算法。

???????? 采用快重傳算法可以讓發(fā)送方盡早知道發(fā)生了個別報文段的丟失。快重傳算法首先要求接收方不要等待自己發(fā)送數(shù)據(jù)時才捎帶確認，而是要立即發(fā)送確認，即使收到了失序報文段也要立即發(fā)出對已收到報文段的確認回復(fù)。?

? ? ? ? 發(fā)送方只要一連收到3個重復(fù)確認，就可知道現(xiàn)在并未出現(xiàn)網(wǎng)絡(luò)擁塞，而只是接收方少收到一個報文段，因而立即重傳該報文段。

快重傳算法步驟如下：?

? ? ? ? 接收方正確接收到M1和M2后都及時發(fā)送了確認，現(xiàn)假定未收到M3而接收到了M4。按照快重傳算法，接收方必須立即發(fā)送對M2的重復(fù)確認，以便讓發(fā)送方及早知道未收到報文段M3。

? ? ? ? 發(fā)送方接著發(fā)送了M5、M6，接收方收到后也仍要再次分別發(fā)出對M2的重復(fù)確認。如此，發(fā)送方一個收到4個M2確認，后3個是重復(fù)確認，就可知道現(xiàn)在并未出現(xiàn)網(wǎng)絡(luò)擁塞，而是接收方少收到一個報文段M3，因而立即重傳M3。

快恢復(fù)算法

? ? ? ? ?發(fā)送方現(xiàn)在知道只是丟失個別的報文段。于是不啟動慢開始，而是執(zhí)行快恢復(fù)算法

????????發(fā)送方將慢開始門限ssthresh的值和擁塞窗口cwnd的值都調(diào)整為當(dāng)前cwnd值的一半，并開始執(zhí)行擁塞避免算法。

????????也有的快恢復(fù)實現(xiàn)是把快恢復(fù)開始時的cwnd值再增大一些，即cwnd=新ssthresh+3。既然發(fā)送方收到了3個重復(fù)的確認，就表明有3個數(shù)據(jù)報文段已經(jīng)離開了網(wǎng)絡(luò)。這3個報文段不再消耗網(wǎng)絡(luò)資源而是停留在接收方的接收緩存中。
????????可見現(xiàn)在網(wǎng)絡(luò)中不是堆積了報文段而是減少了3個報文段，因此可以適當(dāng)把cwnd值增大一些。

練習(xí)?

? ? ? ? 發(fā)生超時用慢開始算法，三個確認重傳采用快重傳和快恢復(fù)

????????而且注意題目中詢問的是甲的發(fā)送窗口。

? ? ? 注意出現(xiàn)超時重傳時，慢開始門限要減少一半，且之后開始進行擁塞算法，

? ? ? ? 在流量控制中，講過接收窗口會影響發(fā)送窗口的大小，在擁塞控制中知道這個關(guān)系是取決于擁塞窗口和接收窗口的最小值。

? ? ? ? 將收到的數(shù)據(jù)全部存入緩存而不取走，意味著接收窗口會縮小，發(fā)送窗口的大小意味多少數(shù)據(jù)傳入，接收數(shù)據(jù)前的窗口大小減去當(dāng)前發(fā)送窗口大小就是接收數(shù)據(jù)后的窗口大小。

? ? ? ? 重新認識到RTT的效果，初次建立連接時不算在RTT中。

????????一個RRT包括了：從發(fā)送上一處的數(shù)據(jù)——縮小接收窗口——收到確認后修改發(fā)送窗口，這個修改是：接收到確認分組時，擁塞窗口翻倍且同時修改接收窗口

快速重傳算法

未出現(xiàn)擁塞的前提下的最長時間，即從擁塞窗口從8kb開始使用擁塞避免算法

主動隊列管理AQM?

? ? ? ? 假定一個路由器對某些分組的處理時間特別長，那么這就可能使這些分組中的數(shù)據(jù)部分經(jīng)過很長時間才能到達終點，結(jié)果引起發(fā)送方對這些報文段重傳，就可能會引起擁塞，于是采取了擁塞控制措施。??

????????TCP擁塞控制與網(wǎng)際層擁塞控制策略有著密切關(guān)系。

? ? ? ? 網(wǎng)絡(luò)層的策略對TCP擁塞控制影響最大的就是路由器分組丟棄策略，在最簡單的情況下，路由器隊列通常采用“先進先出”的規(guī)則處理到來的分組。

? ? ? ? 而隊列長度有限，當(dāng)隊列已滿時，以后再到達的所有分組（這些分組都將排在隊列尾部）都被丟棄，這叫作尾部丟棄原則。

? ? ? ??路由器尾部丟棄往往會導(dǎo)致一連串分組丟失，使發(fā)送方出現(xiàn)超時重傳，使TCP進入擁塞控制的慢開始狀態(tài)，結(jié)果使TCP連接的發(fā)送方突然把數(shù)據(jù)的發(fā)送速率降低到很小的數(shù)值。

• 這導(dǎo)致了網(wǎng)絡(luò)中許多TCP連接（它們源點和終點各不同），這些連接中的報文段通常是復(fù)用在網(wǎng)絡(luò)層中的IP數(shù)據(jù)報中傳送的。

????????若發(fā)生了尾部丟棄，同時使這些TCP進入到慢開始狀態(tài)，這在TCP術(shù)語中稱為全局同步

?????????為了避免網(wǎng)絡(luò)中出現(xiàn)全局同步問題，在1998年提出了主動隊列管理。

• 所謂“主動”，就是在路由器的隊列長度達到某個閾值但還未滿時就主動丟棄IP數(shù)據(jù)報，而不是要等到路由器的隊列已滿時才不得不丟棄后面到達的IP數(shù)據(jù)報，這樣就太被動了。
• 應(yīng)當(dāng)在路由器隊列長度達到某個值得警惕的數(shù)值時，也就是網(wǎng)絡(luò)出現(xiàn)了某些擁塞征兆時，就主動丟棄到達的IP數(shù)據(jù)報來造成發(fā)送方的超時重傳，進而降低發(fā)送方的發(fā)送速率，因而有可能減輕網(wǎng)絡(luò)的擁塞程度,甚至不出現(xiàn)網(wǎng)絡(luò)擁塞。

TCP的運輸連接管理

? ? ? ? TCP是建立連接的協(xié)議，運輸連接是用來傳送TCP報文的。

????????TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。

? ? ? ? 因此，運輸連接有三個階段：連接建立、數(shù)據(jù)傳送和連接釋放。運輸連接的管理就是使運輸連接和釋放都能正常進行。

? ? ? ? TCP建立連接的過程要解決以下三個問題：

1. 要使每一方能夠確知對方存在
2. 要允許雙方協(xié)商一些參數(shù)
3. 能夠?qū)\輸實體資源進行分配

? ? ? ? TCP連接的建立采用客戶服務(wù)器方式，主動發(fā)起連接建立的應(yīng)用進程叫作客戶，而被動等待連接建立的應(yīng)用進程叫作服務(wù)器。

TCP的連接建立步驟

? ? ? ? TCP建立連接的過程叫做握手，握手需要在客戶和服務(wù)器之間交換三個TCP報文段?

? ? ? ? 一開始，B的TCP服務(wù)器進程先創(chuàng)建傳輸控制塊TCB，準(zhǔn)備接受客戶進程的連接請求。然后服務(wù)器進程就處于收聽狀態(tài)，等待客戶的連接請求。此時B處于被動打開鏈接。
?

? ? ? ?A的TCP客戶進程也是首先創(chuàng)建傳輸控制塊TCB。然后，在打算建立TCP連接時，向B發(fā)出連接請求報文段。A屬于主動打開鏈接

• 這時首部中同步位SYN=1，同時選擇一個初始序號seq=x。TCP規(guī)定syn=1的報文段不能攜帶數(shù)據(jù)，但要消耗掉一個序號，這時TCP客戶進程進入同步已發(fā)送狀態(tài)。

TCP客戶進程收到請求后，如同意連接建立，向A發(fā)送確認

? ? ? ? TCP連接請求確認報文段首部中的同步標(biāo)志位SYN和確認標(biāo)志位ACK的值都設(shè)置為1，確認號是ack=x+1，同時也為自己選擇一個初始序號seq=y（請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣需要消耗一個序號）。

????????這時TCP服務(wù)器進程進入同步收到狀態(tài)。

TCP客戶進程收到B的確認后，還要向B給出確認。

????????確認報文段的ACK置1，確認號ack=y+1，而自己的序號seq=x+1。

????????TCP標(biāo)準(zhǔn)規(guī)定，ACK報文段可以攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)則不消耗序號，在這種情況下，下一個數(shù)據(jù)報文段的序號仍是seq=x+1。

? ? ? ? 這時，TCP連接已經(jīng)建立，A進入已建立連接狀態(tài)。

當(dāng)B收到A的確認后，也進入已建立連接狀態(tài)

????????Q1：“三報文握手”建立TCP連接—使用“三報文握手”，而不是“兩報文握手”建立TCP連接的原因。

? ? ? ? A1：

? ? ? ? 當(dāng)?shù)谝淮慰蛻舳说腡CP連接請求報文段傳輸延遲時，將會超時重傳該連接請求報文段，假設(shè)經(jīng)過此次重傳后，TCP接收到該報文段后直接進入已建立連接狀態(tài)（因為是兩次握手），并且傳輸完成后釋放連接進入關(guān)閉狀態(tài)。

? ? ? ? 此時第一次的客戶端的TCP連接請求報文傳輸?shù)椒?wù)器，服務(wù)器接收后進入連接建立狀態(tài)，而客戶端收到該報文后因為未發(fā)送連接請求報文段而不做出反應(yīng)，所以會導(dǎo)致服務(wù)器資源耗費。

練習(xí)?

1. ? ? ? ? 發(fā)送方的初始序列號在第一次握手時創(chuàng)立=第三次握手的seq
2. ? ? ? ? 接受方的初始序列號在第二次握手時創(chuàng)立=第三次握手的ack

TCP的連接釋放?

? ? ? ? 數(shù)據(jù)傳輸結(jié)束后，通信雙方都可釋放連接?，F(xiàn)在A和B都處于連接建立狀態(tài)。A的應(yīng)用進程先向其TCP發(fā)出連接釋放報文段，并停止發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接。

????????A把連接釋放報文段首部的終止控制位FIN置1，其序號seq=u，它等于前面已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1。這時A進入終止等待1狀態(tài)（FIN-WAIT-1）。需要注意：FIN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。

? ? ? ? B收到連接釋放報文段即發(fā)出確認，確認號是ack=u+1，而這個報文段自己的序號是v，等于B前面的已傳送過的數(shù)據(jù)最后一個字節(jié)的序號加1。然后B就進入關(guān)閉等待狀態(tài)（CLOSE-WAIT）.

? ? ? ? TCP服務(wù)器進程這時應(yīng)通知高層應(yīng)用進程，因而從A到B這個方向的連接就釋放了，這時的TCP連接處于半關(guān)閉狀態(tài)，即A已經(jīng)沒有數(shù)據(jù)要發(fā)送了。但B若發(fā)送數(shù)據(jù)，A仍要接收。

? ? ? ? A收到B的確認后，就進入終止等待2狀態(tài)，等待B發(fā)出的連接釋放報文段。

? ? ? ? 若B已經(jīng)沒有要向A發(fā)送的數(shù)據(jù)，其應(yīng)用進程就通知TCP釋放連接。這時B發(fā)出的連接釋放報文段必須使FIN=1。現(xiàn)假定B的序號為w。B還必須重復(fù)上次發(fā)送過的確認號ack=u+1。這時B就進入了最終確認狀態(tài)，等待A的確認。

? ? ? ? A在收到B的連接釋放報文段后，必須對此發(fā)出確認。再確認報文段中的ACK置為1，確認號ack=w+1，而自己的序號是seq=u+1（前面發(fā)送過的FIN報文段要消耗一個序號），然后進入到時間等待狀態(tài)。當(dāng)經(jīng)過時間等待計時器設(shè)置的時間2MSL，A才進入到CLOSED狀態(tài)。

Q1：TCP客戶進入時間等待狀態(tài)等待2MSL后才進入關(guān)閉狀態(tài)，這是否有必要？

A1：若客戶在終止等待2狀態(tài)收到B發(fā)來的報文后，發(fā)送了最后確認報文后進入了關(guān)閉狀態(tài)

? ? ? ?
????????若客戶發(fā)送的該報文丟失，服務(wù)器的最后確認狀態(tài)一直向客戶發(fā)送最后確認報文，但此時客戶已經(jīng)關(guān)閉狀態(tài)，而服務(wù)器卻無法進入關(guān)閉狀態(tài)。

練習(xí)?

? ? ? ?

????????“消耗序號”的含義：當(dāng)發(fā)送一個SYN段時，盡管它不包含數(shù)據(jù)，但它仍然會占用一個序號值。這意味著，在后續(xù)的數(shù)據(jù)傳輸過程中，第一個數(shù)據(jù)字節(jié)的序號將是SYN段序號加1。因此，我們可以說SYN段“消耗掉了一個序號”，因為它為后續(xù)的數(shù)據(jù)傳輸預(yù)留了一個序號空間。

????????SYN段指的是三次握手時建立同步這個階段，對于本題，主機甲發(fā)送的序號仍是1001，甲給乙發(fā)送的第一個應(yīng)用層數(shù)據(jù)字節(jié)的TCP序號為1001，因為應(yīng)用層數(shù)據(jù)作為數(shù)據(jù)載荷被封裝在TCP報文段中。

? ? ? ? 這里需要注意第三次握手時的1001后續(xù)傳輸時是未攜帶數(shù)據(jù)的

實際在應(yīng)用層到fin段之前如下：

????????每個序號僅代表一個整數(shù)，若每個整數(shù)占用相同數(shù)量的字節(jié)，范圍內(nèi)的整數(shù)數(shù)量是：
5000 - 1001 + 1 = 4000

TCP計時?；钇?

????????TCP建立連接后，如何知道客戶端發(fā)生故障？

? ? ? ? 客戶端每向服務(wù)器發(fā)送一次TCP報文，就會激活一次2小時的?；钣嫊r器

? ? ? ? 若TCP出現(xiàn)故障，不能再發(fā)送數(shù)據(jù)，?；钣嫊r器到時后，會每隔75秒發(fā)送一個TCP探測報文段，一連發(fā)送十個后仍無TCP客戶進程響應(yīng)，就判斷這個進程所在主機出現(xiàn)故障，便關(guān)閉了這個連接。