1.TCP的滑動窗口
為了提高信道的利用率TCP協議不使用停止等待協議，而是使用連續ARQ協議，意思就是可以連續發出若干個分組然後等待確認，而不是發送一個分組就停止並等待該分組的確認。
TCP的兩端都有發送/接收緩存和發送/接收窗口。TCP的緩存是一個循環隊列，其中發送窗口可以用3個指針表示。而發送窗口的大小受TCP數據報中窗口大小的影響，TCP數據報中的窗口大小是接收端通知發送端其還可以接收多少數據，所以發送窗口根據接收的的窗口大小的值動態變化。
以下的幾張圖片就幫助理解一下滑動窗口的機制：
注意上圖中的3個指針P1、P2、P3！此時接收窗口中接收的數據可能是失序的，但是也先存儲在接收緩存之中。發送確認號的時候依然發送31，表示B期望接收的下一個數據報的標示符是31。
當B收到31後連同之前接收到的數據報，發送確認號34，此時A的滑動窗口可以向前移動了。
如果發送窗口中的數據報都屬於已發送但未被確認的話，那麼A就不能再繼續發送數據，而需要進行等待。
2.TCP流量控制
所謂流量控制就是讓發送發送速率不要過快，讓接收方來得及接收。利用滑動窗口機制就可以實施流量控制。
原理這就是運用TCP報文段中的窗口大小欄位來控制，發送方的發送窗口不可以大於接收方發回的窗口大小。
考慮一種特殊的情況，就是接收方若沒有緩存足夠使用，就會發送零窗口大小的報文，此時發送放將發送窗口設置為0，停止發送數據。之後接收方有足夠的緩存，發送了非零窗口大小的報文，但是這個報文在中途丟失的，那麼發送方的發送窗口就一直為零導致死鎖。
解決這個問題，TCP為每一個連接設置一個持續計時器（persistence timer）。只要TCP的一方收到對方的零窗口通知，就啟動該計時器，周期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出現在的窗口大小（注意：TCP規定，即使設置為零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段）。
3.傳輸效率及Nagle演算法
TCP的數據傳輸分為交互數據流和成塊數據流，交互數據流一般是一些互動式應用程序的命令，所以這些數據很小，而考慮到TCP報頭和IP報頭的總和就有40位元組，如果數據量很小的話，那麼網路的利用效率就較低。
數據傳輸使用Nagle演算法，Nagle演算法很簡單，就是規定一個TCP連接最多只能有一個未被確認的未完成的小分組。在該分組的確認到達之前不能發送其他的小分組。
但是也要考慮另一個問題，叫做糊塗窗口綜合症。當接收方的緩存已滿的時候，交互應用程序一次只從緩存中讀取一個位元組（這時候緩存中騰出一個位元組），然後向發送方發送確認信息，此時發送方再發送一個位元組（收到的窗口大小為1），這樣網路的效率很低。
素以要解決這個問題，可以讓接收方等待一段時間，使得接收緩存已有最夠的空間容納一個最長報文段，或者等到接收緩存已有一半的空間。只要這兩種情況出現一種，就發送確認報文，同時發送方可以把數據積累成大的報文段發送。