1. 流量控制 - Flow Control
序言：數據的傳送與接收過程當中很可能出現收方來不及接收的情況，這時就需要對發方進行控制以免數據丟失。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。TCP的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。
說明：使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值爲止。B向A發送的三個報文段都設置了ACK=1。
考慮一種特殊的情況，接收方若沒有緩存足夠使用，就會發送零窗口大小的報文，此時發送放將發送窗口設置爲0，停止發送數據；之後接收方有足夠緩存，發送了非零窗口大小的報文，但是這個報文中途丟失，那麼發送方的發送窗口就一直爲0導致死鎖。爲此，TCP爲每一個連接設有一個持續計時器(Persistence Timer)。當TCP連接的一方收到對方的零窗口通知時就啓動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口探測報文段（攜有1字節的數據），那麼收到這個報文段的一方就重新設置持續計時器，給出現在的窗口值。
TCP規定，即使設置爲零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段。
1.1 傳輸效率問題
可以用不同的機制控制TCP報文段的發送時機:
[1]. TCP維持一個變量MSS，等於最大報文段長度。只要緩衝區存放的數據達到MSS字節時，就組裝成了一個TCP報文段發送出去。
[2]. 由發送方的應用進程指明要發送的報文段，即：TCP支持推送操作。
[3]. 發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過MSS大小）發送出去。
1.2 Nagle算法
發送方把第一個數據字節發送出去，把後面到達的數據字節緩存起來。當發送方接收對第一個數據字符的確認後，再把發送緩存中的所有數據組裝成一個報文段再發送出去，同時繼續對隨後到達的數據進行緩存。只有在收到對前一個報文段的確認後，才繼續發送下一個報文段。規定一個TCP連接最多只能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發送其他的小分組。當數據到達較快而網絡速率較慢時，用這樣的方法可明顯地減少所用的網絡帶寬。
Nagle算法還規定：當到達的數據已達到發送窗口大小的一半或已經達到報文段的最大長度時，就可立即發送一個報文段。
1.3 糊塗窗口綜合症
TCP接收方的緩存已滿，而交互式的應用進程一次只從接收緩存中讀取1字節（這樣就使接收緩存空間僅騰出1字節），然後向發送方發送確認，並把窗口設置爲1個字節（但發送的數據報爲40字節的的話）。然後，發送方又發來1個字節的數據（發送方的IP數據報是41字節），接收方發回確認，仍然將窗口設置爲1個字節。這樣，網絡的效率很低。要解決這個問題，可讓接收方等待一段時間，使得或者接收緩存已有足夠空間容納一個最長的報文段或者等到接收方緩存已有一半的空閒空間。只要出現這兩種情況，接收方就發回確認報文，並向發送方通知當前的窗口大小。此外，發送方也不要發送太小的報文段，而是把數據報積累成足夠大的報文段，或達到接收方緩存的空間的一半大小。
2. 擁塞控制 - Congestion Control
序言：網絡擁塞現象是指到達通信子網中某一部分的分組數量過多，使得該部分網絡來不及處理，以致引起這部分乃至整個網絡性能下降的現象，嚴重時導致網絡通信業務陷入停頓出現死鎖現象。擁塞控制是通過擁塞窗口處理網絡擁塞現象的一種機制。
發送報文段速率確定：
[1]. 全局考慮防止擁塞 <- - 擁塞窗口 (Congestion Window) - -> 發送端流量控制，發送端根據自己估計的網絡擁塞程度而設置的窗口值；
[2]. 接收端的接收能力 <- - 接收窗口 (Reciver Window) - -> 接收端流量控制，接收端根據目前的接收緩存大小所許諾的最新窗口值；發送方窗口的上限值 = Min [ rwind, cwind ]
當rwind < cwind 時，接收方的接收能力限制發送方窗口的最大值。
當cwind < rwind 時，網絡的擁塞限制發送方窗口的最大值。
因特網建議標準RFC2581定義了擁塞控制的四種算法：慢開始（Slow-start)，擁塞避免（Congestion Avoidance)，快重傳（Fast Restrangsmit)和快恢復（Fast Recovery）。我們假定
1）數據單方向傳送，而另外一個方向只傳送確認；
2）接收方總是有足夠大的緩存空間，因爲發送窗口的大小由網絡的擁塞程度來決定。
2.1 慢啓動 - (Slow Start) 和 擁塞避免 - (Congestion Avoidance)
慢啓動：
發送方維護一個擁塞窗口cwind的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，動態變化。通過逐漸增加cwind的大小來探測可用的網絡容量，防止連接開始時採用不合適的發送量導致網絡擁塞。
-[1]. 當主機開始發送數據時，如果通過較大的發送窗口立即將全部數據字節都注入到網絡中，由於不清楚網絡情況，有可能引起網絡擁塞；
-[2]. 較好方法是試探，從小到達逐漸增大發送端擁塞控制窗口的cwind數值；
-[3]. 開始發送報文段時，先將擁塞窗口cwind設置爲一個最大報文段MSS值。每收到一個對新報文段的ACK確認後，將擁塞窗口cwind增加至多一個MSS的數值。當rwind足夠大的時候，爲防止擁塞窗口cwind的增長引起網絡擁塞，還需要另外一個變量，慢開始門限ssthresh。
當 cwind < ssthresh時，使用上述慢啓動算法；
當 cwind > ssthresh時，停止使用慢啓動算法，改用擁塞避免算法；
慢啓動侷限性：
[1]. 需要獲得網絡內部流量分佈的信息，浪費可用的網絡容量，額外開銷；
[2]. 估算合理的ssthresh值並不容易，可能耗時較長；
慢啓動的“慢”並不是指cwind的增長速度慢，而是指在TCP開始發送報文段時先設置cwind=1，使得發送方在開始時只發送一個報文段（目的是探測一下網絡的擁塞情況），然後再逐漸增大cwind。
擁塞避免：
讓擁塞窗口cwind緩慢地增大，每經過一個往返時間RTT就把發送方的擁塞窗口cwind加1，而不是加倍。這樣擁塞窗口cwind線性緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。
無論慢啓動開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢啓動門限ssthresh設置爲出現擁塞時的發送方窗口值的一半（但不能小於2）。然後把擁塞窗口cwind重新設置爲1，執行慢啓動算法。目的是迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
控制過程：
-[1]. TCP連接初始化，將擁塞窗口cwind設置爲1個報文段，即cwind=1；
-[2]. 執行慢開始算法，cwind按指數規律增長，直到cwind == ssthresh時，開始執行擁塞避免算法，cwind按線性規律增長；
-[3]. 當網絡發生擁塞，把ssthresh值更新爲擁塞前ssthresh值的一半，cwind重新設置爲1，再按照 [2] 執行。
說明：由指數增長拉低到線性增長，降低出現擁塞的可能。“擁塞避免”並非指完全能夠避免擁塞，利用以上的措施要完全避免網絡擁塞還是不可能的。
慢開始算法只是在TCP連接建立和網絡出現超時時才使用。
2.2 快重傳 - (Fast Retransmission) 和 快恢復 - (Fast Recover)
基本原理：
一條TCP連接有時會因等待重傳計時器的超時而空閒較長的時間，慢開始和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法。
爲使發送方及早知道有報文段沒有達到對方，快速重傳算法首先要求接收方每收到一個報文段後就立即發出重複確認。快重傳算法並非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段，即：當TCP源端收到到三個相同的ACK確認時，即認爲有數據包丟失，則源端重傳丟失的數據包，而不必等待 RTO(Retransmission Timeout)超時。由於發送方儘早重傳未被確認的報文段，因此，採用快重傳後可以使整個網絡吞吐量提高約20%。
控制過程：
與快重傳配合使用的還有快恢復算法，具體地：
- [1]. 當發送方連續收到三個重複確認時，執行“乘法減小”算法，慢啓動門限減半，爲了預防網絡發生擁塞。
- [2]. 由於發送方現在認爲網絡很可能沒有發生擁塞，因此現在不執行慢啓動算法，而是把cwind值設置爲慢啓動門限減半後的值，然後開始執行擁塞避免算法，擁塞窗口cwind值線性增大。避免了當網絡擁塞不夠嚴重時採用”慢啓動”算法而造成過大地減小發送窗口尺寸的現象。
說明：新的 TCP Reno 版本在快重傳之後採用快恢復算法而不是採用慢啓動算法。從接收方對發送方的流量控制的角度考慮，發送方的發送窗口一定不能超過對方給出的接收窗口rwind 。
兩者簡單比較：
相同：提高網絡性能。
不同：
[1].流量控制：在TCP連接上實現對發送流量的控制，考慮點對點之間對通信量的控制，端到端，即：控制發送端的數據發送速率，使接收端可以來得及接收，保證網絡高效穩定運行。
[2].擁塞控制：處理網絡擁塞現象，考慮網絡能夠承受現有的網絡負荷，全局性變量，涉及所有的路由器、主機以及與降低網絡傳輸性能有關的因素。防止過多的數據注入到網絡，使網絡中的路由器或鏈路不致過載，確保通信子網可以有效爲主機傳遞分組。