TCP INCAST解決思路
應用場景：在集群文件系統內，客戶端應用請求某個邏輯數據塊（通常情況下一個讀數據塊大小是1MB），該數據塊以條帶化方式分別存儲在幾個存儲服務器上，即采用更小的數據片存儲（32KB，256KB等），這種小數據片稱為服務器請求單元（SRU）。只有當客戶端接收到所有的服務器返回的其所請求數據塊的SRU后才繼續發送出下一個數據塊請求，即客戶端同時向多個存儲服務器發起並發TCP請求，且所有服務器同時向客戶端發送SRU。
出現的問題：
1) 這種多對一的服務器向客戶端並發傳輸數據的模式，很容易造成與客戶端相連接交換機端口的緩沖區溢出，從而導致丟包及隨后的TCP重傳。在丟包嚴重的情況下，TCP將經歷一個最少持續200ms的超時期，這由TCP最小重傳超時（RTOmin）確定。
2) 在並發傳輸過程中，當某個服務器發生了傳輸超時但其他服務器完成了傳輸，則客戶端在接收到剩余SRU之前必須等待至少RTOmin，而等待期間客戶端的鏈路很有可能處於完全空閑狀態，這就導致在應用層的可見吞吐量與鏈路容量相比較顯著下降且總的請求延遲將高於RTOmin。
切入角度：
深入研究瓶頸鏈路吞吐量下降甚至降為0，使得瓶頸鏈路處於完全空閑狀態，帶寬利用率極低的問題。
若不會發生TCP Incast問題，瓶頸鏈路的吞吐量會保持在一定范圍內波動，帶寬利用率也會較高。
當TCP Incast現象發生了，一旦多個SRU發生超時重傳，其他完成數據傳輸的SRU必須等待其超時重傳的SRU傳輸完成，客戶端才可以發送下一個數據塊請求。這樣在成功發送完的SRU和正在等待超時的SRU交疊的時間塊上，瓶頸鏈路的吞吐量降為0，帶寬利用率同時也會降為0.
具體的例子：
假設一共有10個服務器請求單元：SRU1，SRU2…SRU9，SRU10；
其中SRU2，SRU3，SRU6發生超時重傳，其他服務器請求單元要在完成傳輸后等待SRU2，SRU3，SRU6傳輸完成。而此時，SRU2，SRU3，SRU6正在等待超時。
處於這種情況下，7個成功發送數據的服務器正在等待3個未成功發送數據的服務器超時重傳，這段時間內，瓶頸鏈路的吞吐量降為0，處於完全空閑狀態，同時帶寬利用率也為0。
根本原因分析：
1) 障礙同步機制（應用本身的問題，前提條件）
2) 我們發現瓶頸鏈路吞吐量下降為0的時間不僅僅和超時等待的RTO有關系。
² 若擁塞發生在7個成功發送數據的服務器之后，3個未成功發送數據的服務器將等待超時，此時，瓶頸鏈路將沒有數據傳輸，吞吐量降為0，帶寬利用率為0。Time（瓶頸鏈路吞吐量=0）> RTO;
² 若擁塞發生在7個成功發送數據的服務器之前，3個未成功發送數據的服務器即使在等待超時，瓶頸鏈路仍然有數據在傳輸，吞吐量不會降為0，帶寬利用率也會保持在一定范圍內。此時Time（瓶頸鏈路吞吐量=0）< RTO;
² 事實上，一個發送端超時了，有可能其他的發送端還在繼續發送數據，此時瓶頸鏈路仍然有數據在發送。這樣來說瓶頸鏈路的帶寬利用率，吞吐量大小是由超時等待的時間長短（RTO）與未超時的流的傳輸時間共同決定的。
解決方法：
一方面，我們減少超時等待的流的個數以延長處於障礙同步的流的個數，另一方面，我們減少超時等待的時延以使瓶頸鏈路吞吐量為0的時間進一步減少。
一方面增加成功的發送端的個數，拉長其傳輸時間以使瓶頸鏈路一直有數據在傳輸，不至於讓吞吐量降為0。另一方面縮短未成功的發送端的超時等待時間RTO。
1) 減少超時重傳的服務器個數（本質上丟包是無法避免的，丟包解決不了只能從快速重傳，快速恢復來切入。但是有的情況下無法觸發快速重傳機制，只能等待超時。我們就是要減少這種情況的發生，將那些超時等待的情況轉變為快速重傳）
超時的原因主要分為三個方面：數據塊頭部，數據塊尾部，數據塊重傳丟失
數據塊頭部超時：
² 擁塞窗口值較小的流不幸丟掉了窗口所有的數據包，由於沒有ACK 回來，所以只能等待超時重傳。
數據塊尾部超時：
² 塊尾倒數三個數據包中的任何一個包丟失都會導致發送端超時。
數據塊重傳丟失：
² 另一個重要的超時是重傳的包丟失。當tcp的發送端通過監測發現了丟包，會立即快速重傳丟失的包。然而如果重傳的包再一次丟失。發送端就只能等待超時。
針對數據塊頭部超時，其實本質上慢啟動過程中的不公平現象。當一個回合的傳輸開始時，所有的發送端進入慢啟動階段。在慢啟動階段擁賽窗口按指數級增長，由於發送端窗口增長的步伐並不是一致的，先啟動窗口增長過程的發送端取得競爭帶寬的優勢，這種優勢會隨着指數級的窗口增長被逐漸放大，等到網絡擁賽時，所有的發送端的窗口大小是層次不齊的。擁塞窗口值較小的流就有可能全部丟失，被迫超時重傳。
所以我們要設計策略提高慢啟動階段的公平性。如果有一個集中的控制器，它知道所有流的占據的帶寬值並據此調整他們的發送速率。交換機完全可以充當這個集中的控制器，當所有流經過交換機時，交換機計算所有流的平均窗口值AVG，通過ACK顯示回饋給發送端。發送端統一將發送窗口調整為AVG大小來公平的分配帶寬。
針對數據塊尾部超時，本質上是由於沒有足夠的ACK觸發快速重傳。我們只要重傳數據塊尾部最后一個數據包，即能夠產生足夠的ACK觸發快速重傳，也不需要產生和處理新的數據包。
針對數據塊重傳丟失，這個問題我們可以選擇概率性重傳那些需要重傳的包。減小這種情況的發生概率。
2) 動態調整RTO的值（根據擁塞程度）