TCP是如何名副其實地進行傳輸控制的呢？它對傳輸進行的控制，主要目的是爲了解決 UDP 中發生的丟包，重複收包，亂序等問題。
以下插圖和內容分凝練於《圖解TCP/IP(第5版)》((日)竹下隆史) 。對此書感興趣網上資源自搜。侵權聯繫刪除
太長不看可跳最後總結
TCP的序列號以及確認應答號
確認應答的起因：告知發送端，其發出的數據，接收端已收到。發送端藉此決定對丟包重發。
序號的起因：接收端需要知道是否接收了重複的包（包中字節已收過）。所以給字節編號。比如1~1000號字節打包發送。
序列號的起因：發送端告知接收端此次發送的包的起始字節的序列號。
確認應答號的起因：發送端需要知道接收端後續需要的數據。是接收端根據接收到的包頭的起始字節序號和包的數據段長推算到的。
TCP的超時重發計算
計算的起因：在不同的網絡狀況下，發送端的包被接收端接收到的時間，以及接收端發送的ACK包到達發送端時間，二者總和稱爲RTT往返時延，是不同的。且每一個包的RTT也是不同的，稱爲偏差。TCP 需要確認一個閾值，保證重發不佔用帶寬。
偏差的計入起因：雖然某一輪 RTT 低，但如果它相對上一輪低了好多，加入偏差後的閾值更滿足該網絡的不穩定性特質。
TCP的連接管理
連接的起因：TCP 通信中，發送端與接收端做好互相通信準備後，纔會互相發數據包。UDP 中則不管對方的狀態，直接發送。
連接的管理：TCP的包頭中，有對應的控制字段。
TCP以段爲單位發送數據
MSS的解釋：最長段大小，TCP對大量數據也是分段發送的。
MSS的計算：TCP包作爲IP包的數據段最好包大小不超過IP包能承載的數據段大小，也就是MSS受限於MTU。假設網絡的 MTU 爲 1500，IP首部爲20，那麼TCP包最大爲 1480 字節，TCP包的包頭大概 20 字節，那麼 MSS 就是 1480-20=1460 字節。
TCP使用窗口提高性能
性能問題：TCP以段位單位進行通信，接收端每接收一個段都要給確認應答號，發送端纔會繼續發送下一個段。大數據傳輸耗時。
解決方法：允許發送端在接收到應答前，還能連續發送一定數量的段，這個數量就是窗口大小。允許接收端連續接收段並處理後，只發送最新的確認應答號。
具體做法：發送端與接收端的通信如下圖所示。在接收到最新的確認應答號前，可以發送四個數據段，窗口大小爲4。
TCP的窗口控制與重發控制
重發的起因：丟包。丟包有兩種情況：一種接收端的應答丟了，這種情況沒有關係，只要窗口內該段後的確認應答號包沒掉，就代表段已收到；一種是發送端的包丟了，這種情況需要重發。
重發控制：接收端即便收到了滑動窗口內後面的段，但是一直回覆的確認應答號是那個丟掉的段號，發送端在收到了三次重複的確認應答號後，確定丟包才重發。
TCP流控制
流控制的起因：接收端收到包需要處理時間，發送端的發送速率超出了接收端處理的能力。引發接收端丟包，發送端重發。
解決方法：接收端告知發送端自己處理數據的能力，控制發送端發包。發送端在遲遲沒接收到接收端告知接受能力的時候，主動窗口探測詢問接受能力。
具體做法：接收端使用緩衝區存放發送端傳來的包，排隊處理。接收端在TCP報頭加入緩衝區大小，告知發送端，發送端根據接收端緩衝區大小和收到的包ACK控制發送速率。具體發送端會建立一個發送窗口，只發窗口內的包，比如只發1~1000，發到1000後，就不再發送；直到收到接收端返回的窗口最前端的包ACK，說明接收端已處理完緩衝區中對應的包，緩衝區有空位騰出了，發送端此時將窗口後移，繼續發包；比如收到了1~500的ACK時，窗口後移至 501~1501，繼續發送1001~1501包。
TCP擁塞控制
擁塞的產生：剛開始通信時，發送端根據接收端通知的窗口大小 W 連續發包。
解決方法：慢啓動，發送端控制啓動時的吞吐量。窗口從1個數據段大小開始增長，每接到一個接收端ACK窗口增加一個數據段大小。
擁塞產生：按上述方法建模窗口 W(1) = 1，W(n+1) = W(n) + W(n) = 2W(n)。容易推知 W(∞)=∞。
解決方法：設置慢啓動窗口大小閾值W，當窗口大小超過W時，增長公式調整爲 W(n+1) = W(n) + 1個數據段大小² / W(n) 。
Nagle 算法
Nagle算法的產生：避免小分組降低網絡利用率 [ = 1-(包頭/包頭+數據）]
解決方案：就等着不發出去，一直等到——要麼發送端等了一會兒數據量達到了MSS水平；要麼等接收端全部已發的都確認收到了。再繼續發送。
缺點：對於實時性應用來說，這種拖延戰略不適合。
優點：降低小包數量，提高了網絡利用率
延遲確認應答
延遲確認應答的產生：確認應答包不帶數據，降低了網絡利用率。
解決方案：確認應答可以表示該序列號-1之前的所有包都收到了，所以可以等一會兒，等收到一定數量處理完後，一次性確認。
這個解決方案中發送端可在收到確認前連續發送一定數量的包，是基於滑窗機制的。
缺點：不宜制定標準，通常設定兩個包（不一定是MSS）應答一次，當第二個包遲遲不來時，最多等待0.2s，一定會返回確認應答，這個值是實現了TCP協議的UNIX操作系統決定的。
捎帶應答
捎帶應答的產生：遠程登陸中的回送校驗，郵件系統中的回執機制，www的HTTP應用，都是交互式應用，互相發送信息，雙方都既需要發空包確認應答，又同時要發數據包，兩倍的包量拉低了網絡利用率。
解決方案：二包合體。在確認包裏帶上要回復的數據。
總結
1、TCP 爲了確保數據送達，引入了確認應答機制，每個包從原來的一去變成需要都要一去一回，爲了不影響性能，又使用了滑動窗口機制，允許在通信開始時，以及通信中每收到一個確認應答號後，可連續發送一定數量的包，提升了發送的並行度。
2、滑動窗口在確認窗口大小時使用窗口探測同時解決了發送端發送能力與接收端接收能力不匹配的問題。
3、TCP 爲了控制大量的連續發包導致的網絡擁塞（接收端處理能力強，奈何網絡不佳），引入了慢啓動機制。
4、TCP爲了降低純控制包和小分組的數量，以提高網絡利用率，引入了Nagle算法，延遲確認應答，捎帶應答。
