窗口：
TCP是一個滑動窗口協議，即一個TCP連接的發送端在某個時刻能發多少數據是由滑動窗口控制的，而滑動窗口的大小實際上是由兩個窗口共同決定的，一個是接收端的通告窗口，這個窗口值在TCP協議頭部信息中有，會隨着數據的ACK包發送給發送端，這個值表示的是在接收端的TCP協議緩存中還有多少剩餘空間，發送端必須保證發送的數據不超過這個剩餘空間以免造成緩衝區溢出，這個窗口是接收端用來進行流量限制的，在傳輸過程中，通告窗口大小與接收端的進程取出數據的快慢有關。另一個窗口是發送端的擁塞窗口(Congestion window)，由發送端維護這個值，在協議頭部信息中沒有，滑動窗口的大小就是通告窗口和擁塞窗口的較小值，所以擁塞窗口也看做是發送端用來進行流量控制的窗口。滑動窗口的左邊沿向右移動稱爲窗口合攏，發生在發送的數據被確認時（此時，表明數據已被接收端收到，不會再被需要重傳，可以從發送端的發送緩存中清除了），滑動窗口的右邊沿向右移動稱爲窗口張開，發生在接收進程從接收端協議緩存中取出數據時。隨着發送端不斷收到的被髮送數據的ACK包，根據ACK包中的確認序號和通告窗口大小使滑動窗口得以不斷的合攏和張開，形成滑動窗口的向前滑動。如果接收進程一直不取數據，則會出現0窗口現象，即滑動窗口左邊沿與右邊沿重合，此時窗口大小爲0，就無法再發送數據。
下面附一個TCP協議頭的格式和滑動窗口的示意圖（截自TCPIP協議詳解）：
圖1.TCP頭部結構
圖2.滑動窗口示意圖
帶寬：
這裏帶寬是指單位時間內從發送端到接收端所能通過的“最高數據率”，是一種硬件限制。TCP發送端和接收端的數據傳輸數率不可能超過兩點間的帶寬限制。
RTT：
即Round Trip Time，表示從發送端到接收端的一去一回需要的時間，tcp在數據傳輸過程中會對RTT進行採樣（即對發送的數據包及其ACK的時間差進行測量，並根據測量值更新RTT值，具體的算法TCPIP詳解裏面有），TCP根據得到的RTT值更新RTO值，即Retransmission TimeOut，就是重傳間隔，發送端對每個發出的數據包進行計時，如果在RTO時間內沒有收到所發出的數據包的對應ACK，則任務數據包丟失，將重傳數據。一般RTO值都比採樣得到的RTT值要大。
帶寬時延乘積：
帶寬時延乘積=帶寬*RTT，實際上等於發送端到接收端單向通道的數據容積的兩倍，這裏單向通道的數據容積可以這樣來理解，單向通道看成是一條單行道馬路，帶寬就是馬路的車道數，路上跑的汽車就是數據（不過這裏所有汽車的速率都是一樣的，且不會有人想超車，大家齊頭並進），那麼單向通道的數據容積就是這條單行道上擺滿車，一共可以擺多少輛。當路面上已經擺滿的時候，就不能再往裏面放了。這裏順便再說一下發送時延和傳播時延的差別，單位數據量發送時延是由帶寬決定的，就是帶寬的倒數，以馬路來類比，比如有10輛車，如果車道數爲1，那麼這10輛車只能首尾相接的順序上路，從第一輛車的車頭到最後一輛車的車尾可以看作是發送時延，此時就是10輛車的車長，如果把車道數改成10，那麼這10輛車可以並排上路，發送時延就變成了一輛車的車長了，由此可見，帶寬越高，則發送時延越短，反之則反。傳播時延則是由電的傳播速度（可以看做是一個）常量以及發送和接收端線路的物理長度決定的，比如從美國到中國，傳播時延就很大，而一個局域網內部，傳播時延就很小。因爲發送時延是與數據量大小有關係的，RTT其實只是考慮傳播時延。
介紹了上面的概念後，現在再來看看TCP發送數據時，其速率和這些有什麼關係，下邊用一些符號表示前面提到過的值，
設滑動窗口大小爲W， 發送端和接收端的帶寬爲B， RTT爲Tr。
前面已經說過了，TCP發送數據時受滑動窗口的限制，當TCP將滑動窗口中的數據都發出後，在收到第一個ACK之前，滑動窗口大小是0，不能再發送數據了，必須等待ACK包使滑動窗口移動。那麼在理想情況下，ACK包應該在什麼時候到達呢？顯然，就是在數據發出後的RTT時間後，ACK包到達。這也就是說，現在在不考慮丟包和擁塞情況下，TCP在一個RTT時間內能發出的最大數據量爲W，所以不考慮帶寬限制下，TCP能一個時刻能達到的最大速度是 V = W/Tr
由此可以看出，如果假設Tr是一個定值，那麼決定TCP速率的唯一因素就是TCP的滑動窗口大小。現在再考慮帶寬限制，前面說過當馬路上擺滿車的時候，就無法再往裏放車了，同理，TCP發送端在Tr/2時間內，能往通道上放的數據量爲 V*Tr/2，當 V*Tr/2<=B*Tr/2時，單向通道容積不構成瓶頸，速率的限制主要來源於窗口大小限制。而當V*Tr/2>B*Tr/2時，則就受到容積限制，即此時速率限制來源於帶寬限制。
把V*Tr/2<=B*Tr/2和V*Tr/2>B*Tr/2兩邊的Tr/2約掉，再把V = W/Tr代入，則可以得到 ：
W <= B*Tr 及 W > B*Tr
B*Tr就是帶寬時延乘積，取W爲TCP能支持窗口的最大值Wmax，當Wmax <= B*Tr時，此時發送和接收端之間的通道就是所謂的長肥管道，即帶寬時延乘積大的通道。在我們平時生活中使用的寬帶網絡，ADSL等環境下，因爲帶寬都比較小，從而B*Tr也比較小，再加上網絡情況比較複雜，擁塞情況比較常見，所以這些網絡環境下，TCP速率的主要限制因素在於帶寬，丟包率等。長肥管道一般不太常見，多見於一些單位使用的專線網絡，在這些網絡中速率的主要限制因素就是窗口大小了，這也是傳統TCP在這些網絡環境中不能充分利用帶寬的原因所在（因爲傳統TCP的窗口大小是用2字節表示的，所以最大隻有65535（不考慮窗口擴大選項）），除了專線網絡外，隨着網絡硬件技術的發展，萬兆交換機的出現，局域網中也可能會出現帶寬時延乘積較大的情況。
總結，在W<B*Tr時，影響TCP發送數據速率的最直接的因素是滑動窗口的大小，TCP的流量控制策略（比如超時時窗口設置爲1，重複ACK時窗口減半）最終都是通過控制窗口大小來控制速率，而慢啓動，擁塞避免這些流量控制算法實際上就是控制窗口增長方式的算法，也就是控制的是加速度大小。當W>B*Tr時，則影響速率的因素就是帶寬了。
現在出現很多基於UDP的可靠傳輸技術，因爲UDP在IP的上層除了加了端口號之外基本上沒做其他什麼事，所以提供給應用層控制的空間就很大，這些技術也大致都是通過在應用層添加可靠性保證，並擴大窗口大小和改變流量控制策略來克服傳統TCP的缺點。
BTW，開源項目UDT其實是個好東西，也是基於UDP的可靠傳輸，還沒來得及深入研究。但是看了下文檔知道它給外部提供了流量控制策略定製化接口，這點很好，留給了使用者相當大的靈活性，有時間要研究研究。
原文地址：http://blog.csdn.net/bad_sheep/article/details/6158676
