爲了提高信道的利用率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），這樣網絡的效率很低。
素以要解決這個問題，可以讓接收方等待一段時間，使得接收緩存已有最夠的空間容納一個最長報文段，或者等到接收緩存已有一半的空間。只要這兩種情況出現一種，就發送確認報文，同時發送方可以把數據積累成大的報文段發送。