1. 累計確認（cumulative acknowledgement）
由於 TCP 使用可變長度的報文段來發送數據，而且重傳的報文段中可能比原報文段包含更多的數據，所以不能簡單地對數據報和報文段進行確認。實際上，TCP使用流序號對流中的一個位置進行確認(序號---確認號)。接收方使用序號將報文段重新排序，接收方總是對已正確收到流的最長連續前綴進行確認。每個確認給出一個序號值，其值比收到的連續前綴中最高八位組的位置大 1。這樣，發送方就能在繼續發送流的同時，從接收方得到連續的反饋信息。因此：
一個TCP確認指出了接收方期望收到的下一個字節的序號。
TCP的確認方法稱爲累積確認（cumulative acknowledgement） ，因爲它報告了接收方已累積收到流中的多少個字節。累計確認，允許ACK丟失，沒有必要進行重傳。
2. 自適應重傳算法（adaptive retransmission algorithm）
TCP監視每條連接的性能，由此推算出適當的超時時限值。當網絡負載發生變化時，TCP隨即修改觸發重傳的定時器的長短。
“樣本往返時間”(sample round trip time)或者“往返時間樣本”（round trip sample）:
TCP軟件計算往返時間的加權平均值，作爲往返時間的估計值（RTT, 即round trip time），並不斷的使用新的往返時間樣本來逐步修改這個平均值:
RTT = (α * OLD_RTT) + ((1 - α) * New_Round_Trip_Time)
超時時限值爲：Timeout = β * RTT (β一般等於2)
3. 往返時間樣本的精確測量
1）確認二義性（acknowledgement ambiguity）
TCP使用累積確認方式，把測量一個往返時間樣本的問題複雜化了。因爲確認針對的是收到的數據，而不是針對攜帶這些數據的某個數據報實例。當發生重傳時，接收方可能會收到的那個ACK確認，我們不知道它是針對原來的數據包還是重傳的數據包。
2）Karm算法與計時器補償
爲了避免二義性的確認，Karm算法規定：TCP不爲重傳的報文更新往返時間估計值，而只對沒有重傳，不會發生二義性確認來調整往返時間的估計值。
同時爲了避免網絡時延突然增大後，超時時限太小從而造成報文段反覆重傳的情況發生。Karn 算法要求發送方在對重傳的超時時限進行設置時結合使用計時器退避（timer backoff）策略：
當發生重傳時：new_timeout = γ * timeout (γ一般等於2)
4. 對高方差時延的對策
1989 年的 TCP 協議規範要求，協議在實現時既要估計往返時間的平均值，也要估計往返時間的方差，並使用方差的估計值替代常數β。這樣，TCP的新實現就能適應更大範圍變化時延的情況，還能實現較高的吞吐率。
5. 擁塞控制
1）擁塞（congestion）:
是指一個或多個交換點（如路由器）的數據包超載而導致時延劇烈增加的現象。當發生擁塞時，數據報的時延增加，路由器開始把數據報放在隊列中排隊，直到能夠對它們進行轉發。在最壞的情況下，到達擁塞路由器的數據報總數不斷增加，直至路由器容量達到飽和，並開始丟棄報文。從而導致重傳，重傳只會加劇擁塞，而不會減輕擁塞。如此惡性循環，直至網絡變得無法使用。這種現象稱爲擁塞崩潰（congestion collapse）。
爲了避免出現擁塞崩潰，TCP必須在擁塞發生時減小傳輸速率。路由器觀察隊列的長度，使用類似於ICMP源站抑制（source quench）的技術通知主機已發生擁塞。類似 TCP的運輸協議，在時延較大時可以自動降低傳輸速率，這樣有助於避免擁塞的發生。
爲了避免擁塞，TCP 標準推薦使用兩種技術：慢開始（slow-start）和乘法減小（multiplicative dcrease）.爲了控制擁塞，TCP 使用第二個窗口限制，即擁塞窗口限制（congestion window limit）或稱擁塞窗口（congestion window）。當發生擁塞時，可使用此限制讓數據流量小於接收方的緩衝區大小。也就是說，在任何時候，TCP通信把窗口的大小當成：
Allowed_window = min(receiver_adversement, congestion_window)
爲了估算擁塞窗口的大小，TCP 假設報文的丟失大多數是由於擁塞造成的，並使用下面的策略來改變窗口大小，乘法減小的擁塞避免策略：
一旦發現報文段丟失，就把擁塞窗口的大小減半（直到減至最小的窗口，窗口中應包括至少一個報文段） 。對於留在許可窗口內的那些報文段，採用指數退避算法計算重傳計時器的時限值。
擁塞結束後，TCP 如何恢復正常通信呢？
實際上，TCP使用慢開始（slow-start）的技術來逐步恢復傳輸:
慢開始（加法）恢復：在一條新連接上開始傳輸通信量時，或在一段時間的擁塞後增加通信量時，擁塞窗口的大小剛開始只有一個報文段，以後隨着一個確認的到達，擁塞窗口的大小每次增加一個報文段。當擁塞窗口到達擁塞發生前窗口大小的一半時，TCP進入一個擁塞避免（congestion avoidance）的階段，減慢窗口增長的速度。在擁塞避免期間，只有當窗口中的所有報文段都被確認之後，窗口大小才能增加 1。
把慢開始、乘法減小、加法增加、方差估計、計時器指數退避等技術結合在一起，就能顯著地提高TCP的性能，同時不需要爲協議軟件增加大量的計算開銷。使用了這些技術的TCP版本，比過去一些版本的性能提高了2～10倍。（使用這些機制的是早期的TCP版本——也稱爲Tahoe版本）
6. Reno版本——快重傳改進
1990 年出現了 Reno 版本的 TCP，它對舊版本做了幾處改進，包括一個名爲快恢復（fast
recovery）或快重傳（fast retransmit）的啓發式方法，在偶爾發生丟失的環境中具有更高的吞吐率。
在快恢復中使用的技巧產生於 TCP 的累積確認機制：如果一個報文段丟失，當後續的報文段到達接收方時，要求接收方產生一個 ACK，該確認指明瞭丟失的報文段在流中的位置點。從發送方的角度來看，它會收到一連串的確認，每個確認中攜帶的是同一個序號。快重傳啓發式方法使用一連串的三個重複確認（即最初的確認加上三個完全相同的副本）來激活一次重傳，而不必等到計時器超時後再重傳。
爲了維持更高的吞吐率，快重傳啓發式方法在等待重傳報文段的確認時，還繼續發送窗口中的數據。此外，擁塞窗口被人爲地膨脹開：擁塞窗口因重傳而被縮小一半，但伴隨每個重複 ACK 在重傳前後的到達，都會使擁塞窗口擴大一個最大長度的報文段。由此可見，在快重傳期間，TCP讓很多報文段處於發送方和接收方之間的傳輸途中。
7. TCP友好速率控制（TCP Friendly Rate Control,簡稱TFRC）
我們發現，雖然在發生擁塞時 TCP 減少了傳輸通信量，但UDP並沒有減少，這意味着隨着 TCP 流量繼續回退， UDP流量將佔據更多的寬帶。由於 UDP 不使用滑動窗口，TFRC 讓接收方向發送方報告分組丟失的情況，並讓發送方使用被告知丟失的數據來計算UDP應該使用的發送速率，通過這些措施來嘗試模仿 TCP的行爲。
8. 擁塞、尾部丟棄、隨機早期丟棄（RED）
1）尾部丟棄
路由器的尾部丟棄策略：如果數據報到達時輸入隊列已滿，則丟棄該數據報。
尾部丟棄策略很可能使路由器丟棄來自N個連接的N 個報文段（每個連接丟失一個報文段） ，而不是來自一個連接的 N個報文段。這種同時發生的丟失造成TCP的 N 個實例同時進入慢開始。導致了全局的同步。
2）隨機早期丟棄（RED）
路由器如何避免全局的同步呢？答案是一種儘可能避免尾部丟棄的方法。 這種方法稱爲隨機早期檢測（Random Early Detection）或者隨機早期丟棄（Random Early Discard/Drop,簡稱RED）