在現有複雜的網絡環境中，如果我們的產品提供網絡傳輸功能，特別是提供點對點的大數據量網絡傳輸服務，我們會經常收到一小部分用戶的抱怨，傳輸不穩定而且速度慢。針對這部分環境，在排除了應用實現的代碼問題之後，通過抓包分析，我們可以發現，TCP的擁塞控制實現策略對現有的低速網絡，特別是上行受限的ADSL用戶網絡不具很好的適應性。我們把發送端標記爲A，接收端標記爲B, 具體如下：
A、B建立連接後，A端擁塞控制窗口cwnd=mss, 應用層向A的TCP發送緩衝區放入數據之後，A向B發送一個mss長度的TCP封裝數據，B端收到併發回ACK，A端收到ACK，cwnd += mss(cwnd=2*mss)，A再次向B發送2個mss的TCP封裝數據。當cwnd增大到n * mss時，A向B發送n個mss長度的TCP封裝數據包，B向A確認，但是隻確認了前i（i < n）個, 即是 B沒有收到 i + 1 到 n個包。則由TCP的實現策略，當i >= 3時，傳輸將進入超時重傳或快速恢復。i< 3,則只有進入超時重傳。不管是進入哪個流程，都會影響到傳輸的效率。如果 n <= 3,則傳輸會頻頻進入超時重傳流程，對於以100毫秒爲基本單位的定時器實現的超時檢查，每次該事件發生時，將至少浪費數百毫秒連接無利用，嚴重影響傳輸的速度。
針對這類問題，如果我們使用的是操作平臺提供的TCP傳輸通道，我們只能通過偵測傳輸通道的網絡狀況，計算出每次發送包合適的大小，減少擁塞發生的概率。這種處理方式能夠稍稍增強傳輸的穩定性，甚至可以提高傳輸速度，增強用戶體驗。
但是這種方式是通過控制發送數據包在一定大小實現的，對於傳輸定量的數據，顯然是增加了send函數的系統調用，降低了程序的系能。同時也不是解決問題的根本之道，因爲應用層獲取TCP連接的擁塞控制窗口cwnd是不現實的，通過應用層的邏輯計算很難保證準確，從架構角度講不應該是應用層所關心的事情。
重寫tcp的實現對於一般的產品而言，是不現實的，但是不應該是阻止我們研究該問題的理由。通過前面的分析，我們知道在現實的網絡環境中，有些環境下兩端點之間的物理設備由於帶寬以及處理能力的限制，每次發送超過2個或3個mss大小的數據包就高概率丟包，由此進入頻繁的超時重傳。如果可靠傳輸控制流程能夠加入偵測機制，當發現發送超過m個mss大小的數據包時，在運行環境內就會丟包，如此設定擁塞控制窗口的一個關係值m，當達到m後，進入一個比擁塞控制流程更慢的增長過程，則系統能夠大大提高傳輸速度。
今天先寫到這裏，改天再續！