TCP的流量控制
滑動窗口
一般來說，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。所謂流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。看下面這個例子：
假設A向B發送數據。在連接建立時，B告訴了A：我的接收窗口是400。因此，發送方的發送窗口不能超過接收方給出的接收窗口的數值。請注意，TCP的窗口單位是字節，不是報文段。再假設每一個報文段爲100字節長，而數據報文段序號的初始值設爲1。從上圖可發現，接收方的主機B進行了三次流量控制。第一次把窗口減小到300，第二次減小到100，最後減到0，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值爲止。B向A發送的三個報文段都設置了ACK = 1，只有在ACK = 1 時，確認號字段纔有意義。
現在我們考慮一種情況。B向A發送了零窗口的報文段後不久，B的接收緩存又有了一些存儲空間。於是B向A發送了rwnd = 400的報文段。然而這個報文段在傳送過程中丟失了。A一直等待收到B發送的非零窗口的通知，而B也一直等待A發送的數據。如果沒有其它措施，這種互相等待的死鎖局面將一直延續下去。爲了解決這個問題。TCP爲每一個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啓動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。如果窗口仍然是零，那麼收到這個報文段的一方就重新設置持續計時器。如果窗口不是零，那麼死鎖的僵局就可以打破了。TCP規定，即使設置爲零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段、攜帶緊急數據的報文段。
傳輸效率
應用進程把數據傳送到TCP的發送緩存後，剩下的發送任務就由TCP來控制了。可以用不同的機制來控制TCP報文段的發送時機。第一種機制是TCP維持一個變量，它等於最大報文段長度MSS。只要緩存中存放的數據達到MSS字節時，就組裝成一個TCP報文段發送出去。第二種機制是由發送方的應用進程指明要求發送報文段，即TCP支持的推送操作。第三種機制是發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段發送出去，但長度不能超過MSS。
但是，如何控制TCP發送報文段的時機仍然是一個較爲複雜的問題。
例如，一個交互式用戶使用一條TELNET連接。假設用戶只發一個字符，加上20字節的首部後，得到21字節長的TCP報文段，再加上20字節長的IP首部，形成41字節長的IP數據報。在接收方TCP立即發出確認，構成的數據報是40字節長。若用戶要求遠地主機回送這一字符，則又要發回41字節長的IP數據報和40字節長的確認IP數據報。這樣，用戶僅發1個字符時，線路上就需傳送總長度爲162字節，共4個報文段。當線路帶寬並不富裕時，這種傳送方法的效率的確不高。因此應適當推遲發回確認報文，並儘量使用捎帶確認的方法。
在TCP的實現中廣泛使用Nagle算法。算法如下：若發送應用進程把要發送的數據逐個字節的送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把後面到達的數據字節都緩存起來。當發送方收到對第一個數據字符的確認後，再把發送緩存中的所有數據組裝成一個報文段發送出去，同時繼續對隨後到達的數據進行緩存。只有在收到對前一個報文段的確認後才繼續發送下一個報文段。當數據到達較快而網絡速率較慢時，用這樣的方法可明顯減少所用的網絡帶寬。Nagle算法還規定，當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。這樣做，就可以有效的提高網絡的吞吐量。
另一個問題叫做糊塗窗口綜合徵，有時也會使TCP的性能變壞。設想一種情況：TCP接收方的緩存已滿，而交互式的應用進程一次只從接收緩存中讀取一個字節，然後向發送方確認，並把窗口設置爲1個字節（但發送的數據報是40字節）。接着，發送方又發來一個字節的數據。接收方發回確認，仍然將窗口設置爲1個字節。這樣進行下去，使網絡的效率很低。要解決這個問題，可以讓接收方等待一段時間，使得或者接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一半空閒的空間。只要出現這兩種情況之一，接收方就發出確認報文，並向發送方通知當前的窗口大小。此外，發送方也不要發送太小的報文段，而是把數據積累成足夠大的報文段，或達到接收方緩存的空間的一半大小。
上面兩種方法可配合使用。使得在發送方不發送很小的報文段的同時，接收方也不要在緩存剛剛有了一點小的空間就急忙把這個很小的窗口大小信息通知給發送方。