TCP資料流與視窗管理
一、互動式通訊
“互動式”TCP連線是指，該連線需要咋客戶端和服務端之間傳輸使用者輸入資訊，如按鍵操作、短訊息、滑鼠等動作。如果採用較小的報文段來承載這些使用者資訊，那麼傳輸協議需要付出很高的代價，因為每個交換分組中包含的有效負載位元組較少。反之，報文段較大則會引入更大的延遲，對延遲敏感類應用（如線上遊戲，協同工具）造成負面影響。我們需要權衡相關因素，找出折中方法。
二、延遲確認
在很多情況下，TCP並不是對每個到來的資料包都返回ACK，利用TCP的累計ACK欄位就能實現上述功能。累計確認可以允許TCP延遲一段時間傳送ACK，以便將ACK和相同方向上需要傳的資料結合傳送。這種捎帶傳輸的方法常用於與批量資料傳輸。採用延遲ACK的方法會減少ACK傳輸數目，可以一定程度的減輕網路負載。
三、Nagle演算法
微型報傳輸會造成很高的網路傳輸代價，為了解決此問題，提出了Nagle演算法。
Nagle演算法要求，當一個TCP連線中有在傳資料（即那些已傳送但還未確認的資料），小的報文段（長度小於SMSS）就不能被髮送，直到所有的在傳資料都收到ACK。並且，在收到ACK後，TCP需要收集這些小資料，將其整合到一個報文段中傳送。這種方法迫使TCP遵循停等規則------只有等接受到所有在傳資料的ACK後才能繼續傳送。該演算法的精妙在於它實現了自時鐘控制：ACK返回越快，資料傳輸也越快。在相對高延遲的廣域網中，更需要減少微型報的數目，該演算法使得單位時間內傳送的報文數目更少。RTT控制著發包速率。Nagle演算法做出了一種折中：傳輸的包數目更少而長度更大，但同時傳輸時延也更長。
四、延遲ACK與Nagle演算法結合
延遲ACK與Nagle演算法的結合會導致某種程度的死鎖。延遲ACK採用捎帶確認，客戶端在接收到服務端的資料包後，客戶端並不立即傳送ACK，而是出於等待狀態，希望有資料一同捎帶傳送。在服務端，由於使用了Nagle演算法，直到收到ACK之前都不允許傳送資料，因為任意時刻只允許至多一個包在傳，所以延遲ACK與Nagle演算法的結合導致了某種程度的死鎖。
在有些情況下版本適合Nagle演算法，典型的包括哪些要求時延儘量小的應用（如多人網路遊戲），在這種情況下，需要禁用Nagle演算法。
五、流量控制與視窗管理
每個TCP報文段（除了連線建立之初的包交換）都包含一個有效的序列號欄位，一個ACK號和確認欄位，以及一個視窗大小欄位（包含視窗通告資訊）。每個TCP頭部的視窗大小欄位表明接收端可用快取空間的大小，以位元組為單位。
1.傳送視窗結構
TCP傳送視窗可分為兩部分，已傳送但未確認和即將傳送（可用視窗）。左邊界左邊是已傳送已經確認，右邊界往右的部分直至視窗移動前都不能傳送。隨著時間的推移，當接收到返回的ACK，滑動視窗也隨之右移。視窗兩端的相對移動使得視窗增大或減小。
關閉： 即視窗左邊界右移，當已傳送資料得到ACK確認時，視窗會減小。
開啟： 即視窗右邊界右移，使得可傳送資料量增大。當已確認資料得到處理，接收端可用快取增大，視窗也隨之增大。
2.接收視窗結構
接收端視窗結構記錄了已接收並確認的資料，以及他能夠接收的最大序列號。該視窗可以保證其接收資料的正確性。
與傳送視窗一樣，該視窗結構也包含一個左邊界和右邊界，但視窗內的位元組並沒有區分。對接收端來說，到達序列號小於視窗左邊界，被認為是重複資料而丟棄；越過右邊界的資料則超出處理範圍，也被丟棄。注意到由於TCP的累計確認結構，只有當到達資料序列號等於左邊界時，資料才不會被丟棄，窗口才能向前滑動。對選擇確認TCP來說，使用SACK選項，視窗內的其他報文段也可以被接收確認，但只有在接收到等於左邊界的序列號資料時，窗口才能前移。
3.零視窗與TCP持續計數器
TCP通過接收端的通告視窗來實現流量控制，通告視窗指示了接收端可接受的資料量。當視窗值變為0時，可以有效阻止傳送端進行傳送，直到視窗大小恢復為非零值。如果包含一個視窗更新的ACK丟失，通訊雙方就會一直處於等待狀態，造成死鎖。為了防止這種死鎖的發生，傳送端會採用一個持續計數器間歇性地查詢接收端，看其視窗是否已增長。
4.大容量快取與自動調優
接收端視窗大小受限於其快取大小。一般來說，如果上層應用沒有設定其接收快取大小，就會為其分配一個相對較小的空間，因為有時候即使在高頻寬的傳輸路徑上（高頻寬也有可能高延遲，頻寬與延遲無關），傳輸延遲仍然很大，導致網路吞吐效能變差。在一些作業系統中採用自動調優的方式可以高效地自動分配快取大小。
五、糊塗視窗綜合徵
隨著TCP的不斷髮展，出現了一種奇怪的問題。當通告視窗較小時，傳送端會立即傳送資料填滿該視窗，這樣在連線中就會出現大量高耗費的小資料包。這種現象被稱為“糊塗視窗綜合徵”。針對這種問題，對傳送端來說，若通告視窗較小則避免傳送小資料包；接收端則儘量避免通告小視窗。