TCP可靠傳輸&流量控制&擁塞控制
TCP可靠傳輸
TCP可靠傳輸的工作原理
1.無差錯
1>：無差錯： A發送分組M1，發送就暫停發送，等待B的確認，B收到M1就向A發送確認，A收到對M1的確認后再發送下一個分組。（若A收到連續的M1分組的確認信息，則證明M2缺失）
2>：出現差錯：
A只要超過一段時間仍然沒有收到確認，就認為剛才發送的分組丟失了，就重傳前面發過的分組，叫超時重傳。由重傳計時器實現。
而且：
（1）A每次發送分組必須暫時保留分組副本；
（2）分組和確認分組必須進行編號‘
（3）超時計時器的重傳時間應當比數據在分組的平均往返時間更多一些。
3>：如果B收到重復的分組M1,不向上一層交付；而且，向A發送確認。
2.超時重傳
其原理是在發送某一個數據以后就開啟一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那么就重新發送數據，直到發送成功為止。
3.停止等待協議
優點是簡單，但是信道利用率太低了。解決方法是采用連續ARQ協議，發送方維持發送窗口，每次連續發送幾個分組，接收方采用累積確認，對按序到達的最后一個分組發送確認。
缺點是不能向發送方反映出接收方已經正確收到的所有分組信息，例如丟失中間的分組。
4.TCP可靠傳輸的實現
TCP 連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口。TCP 的可靠傳輸機制用字節的序號進行控制。TCP 所有的確認都是基于序號而不是基于報文段。
發送過的數據未收到確認之前必須保留，以便超時重傳時使用。發送窗口不動(沒收到確認)和前移(收到新的確認)
發送緩存用來暫時存放： 發送應用程序傳送給發送方 TCP 準備發送的數據；TCP 已發送出但尚未收到確認的數據。接收緩存用來暫時存放：按序到達的、但尚未被接收應用程序讀取的數據； 不按序到達的數據。
必須強調三點：
1> A 的發送窗口并不總是和 B 的接收窗口一樣大（因為有一定的時間滯后）。
2> TCP 標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到后，再按序交付上層的應用進程。
3> TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷
5.滑動窗口圖解
TCP擁塞控制和流量控制的差別
所謂擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能承受現有的網絡負荷。
流量控制往往指的是點對點通信量的控制，是個端到端的問題。流量控制所要做的就是控制發送端發送數據的速率，以便使接收端來得及接受。
TCP流量控制
所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接受。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。
TCP的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。
只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
TCP流量控制
所謂流量控制就是讓發送發送速率不要過快，讓接收方來得及接收。利用滑動窗口機制就可以實施流量控制。
原理這就是運用TCP報文段中的窗口大小字段來控制，發送方的發送窗口不可以大于接收方發回的窗口大小。
考慮一種特殊的情況，就是接收方若沒有緩存足夠使用，就會發送零窗口大小的報文，此時發送放將發送窗口設置為0，停止發送數據。之后接收方有足夠的緩存，發送了非零窗口大小的報文，但是這個報文在中途丟失的，那么發送方的發送窗口就一直為零導致死鎖。
解決這個問題，TCP為每一個連接設置一個持續計時器（persistence timer）。只要TCP的一方收到對方的零窗口通知，就啟動該計時器，周期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出現在的窗口大小（注意：TCP規定，即使設置為零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段）。
TCP擁塞控制
在某段時間，若對網絡中的某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變化，這種情況叫做擁塞。
擁塞控制設計
擁塞控制是很難設計的，因為它是一個動態的問題，許多情況下，甚至正式擁塞控制機制本身成為引起網絡性能惡化甚至死鎖的原因。從控制理論的角度來看擁塞控制這個問題，可以分為開環控制和閉環控制兩種方法。開環控制就是在設計網絡時事先將有關擁塞發生的所有因素考慮周到，一旦系統運行起來就不能在中途改正。
閉環控制是基于反饋環路的概念，包括如下措施：
1）監測網路系統以便檢測擁塞在何時何地發生
2）把擁塞發生的信息傳送到可采取行動的地方
3）調整網絡系統的行動以解決出現的問題。
擁塞控制方法
因特網建議標準RFC2581定義了進行擁塞控制的四種算法，即慢開始（Slow-start)，擁塞避免（Congestion Avoidance)快重傳（Fast Restrangsmit)和快恢復（Fast Recovery）。我們假定
1）數據是單方向傳送，而另外一個方向只傳送確認。
2）接收方總是有足夠大的緩存空間，因為發送窗口的大小由網絡的擁塞程度來決定。
下圖是慢啟動和擁塞避免的一個可視化描述。我們以段為單位來顯示cwnd和ssthresh，但它們實際上都是以字節為單位進行維護的。
慢開始和擁塞避免
發送報文段速率的確定，既要根據接收端的接收能力，又要從全局考慮不要使網絡發生擁塞，這由接收窗口和擁塞窗口兩個狀態量確定。接收端窗口（Reciver Window)又稱通知窗口（Advertised Window),是接收端根據目前的接收緩存大小所許諾的最新窗口值，是來自接收端的流量控制。擁塞窗口cwnd（Congestion Window)是發送端根據自己估計的網絡擁塞程度而設置的窗口值，是來自發送端的流量控制。
1.慢啟動原理：
1）當主機開始發送數據時，如果立即將較大的發送窗口的全部數據字節都注入到網絡中，那么由于不清楚網絡的情況，有可能引其網絡擁塞
2）比較好的方法是試探一下，即從小到達逐漸增大發送端的擁塞控制窗口數值
3）通常在剛剛開始發送報文段時可先將擁塞窗口cwnd(擁塞窗口)設置為一個最大報文段的MSS的數值。在每收到一個對新報文段確認后，將擁塞窗口增加至多一個MSS的數值，當rwind（接收窗口）足夠大的時候，為了防止擁塞窗口cwind的增長引起網絡擁塞，還需要另外一個變量---慢開始門限ssthresh
2. 擁塞控制
具體過程為：
1）TCP連接初始化，將擁塞窗口設置為1
2）執行 慢開始算法：cwind按指數規律增長，知道cwind == ssthress開始執行 擁塞避免算法：cwnd按線性規律增長
3）當網絡發生擁塞，把ssthresh值更新為擁塞前ssthresh值的一半，cwnd重新設置為1，按照步驟（2）執行。
3.快重傳和快恢復
一條TCP連接有時會因等待重傳計時器的超時而空閑較長的時間，慢開始和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法。
快重傳算法并非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段（如果當發送端接收到三個重復的確認ACK時，則斷定分組丟失，立即重傳丟失的報文段，而不必等待重傳計時器超時）。
例如：M1，M2，M3 -----> M1,M3,缺失M2，則向發送方發送M2重復確認，當發送方收到M2的三次重復確認，則認為M2報文丟失，啟動快重傳機制，重傳數據，其他數據發送數據放入隊列，待快重傳結束后再正常傳輸。
快恢復算法有以下兩個要點：
1）當發送方連續收到接收方發來的三個重復確認時，就執行“乘法減小”算法，把慢開始門限減半，這是為了預防網絡發生擁塞。
2）由于發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，而是把cwnd(擁塞窗口)值設置為慢開始門限減半后的值，然后開始執行擁塞避免算法，是擁塞窗口的線性增大。
報文重復確認:
重復ACK，代表報文丟失，觸發快速重傳機制
序列號：返回發送端的確認編號實際上是接收端希望收到的序列號。
當重傳主機從發送端接收到3個重復ACK時，它會假設此報文確實在傳送中丟失，并且立即發送一個快速重傳。一旦觸發了快速重傳，所有正在傳輸的其他報文都被放入隊列中暫停發送，直到快速重傳報文發送完為止。
過程如下圖所示：
