已不記得多少次玩游戲時，被隔壁loser下片卡掉線。

已不記得多少次瀏覽網頁時，被隔壁sb下片卡得動彈不了。

為什么帶寬總是被P2P下載搶光呢？

是因為P2P太流氓了嗎？

有句老話說得好，人背不能歸社會。與其抱怨P2P協議太流氓，不如說tcp協議太憨厚老實了。tcp協議的擁塞控制算法，會根據丟包、重傳、延時等現象，判斷當前網絡狀態。當網絡狀況不好時，tcp協議會自動降低傳輸速率，以降低網絡壓力，避免網絡因過重的壓力而崩潰。當P2P拼命搶帶寬時，tcp協議卻不停的降低自己的速度，結果就是帶寬被P2P吃完而tcp的速度接近于0。

tcp擁塞控制，是針對PCà服務器的整條線路進行流量控制。保護的是“整條互聯網線路”。這是一個舍己為人的“君子”協議。在帶寬大而且p2p不是很泛濫的國家（除中國外的全世界），tcp能讓大家都過上網絡通暢的好日子。但是在中國，“流氓”軟件越來越多。各種P2P下載工具、視屏插件瘋狂搶帶寬。使得TCP擁塞控制變得越來越不合時宜。

我們需要對TCP協議的擁塞控制做一次革命！！！

我們真的需要擁塞控制嗎？

需要的，但不是針對“整條互聯網線路”，而是僅僅針對我們的出口帶寬做擁塞控制。假如我的出口帶寬只有10MB，那么我們的擁塞控制就應該針對10MB來做，正好占滿這10MB帶寬。至于電信小區出口帶寬不夠了，電信移動間連接節點帶寬不夠了，這些位置的擁塞都和我們沒關系。P2P只管自己死活，我們的tcp也必須以同樣的策略對抗才能保證用戶正常上網。這就是我們的貪婪TCP協議：僅針對自身的網絡出口帶寬進行擁塞控制。

說來容易實現難

tcp協議中的擁塞控制是由發送方控制的，也就是說，當我們用PC瀏覽網頁時，PC只能控制自己上傳數據的速率，無法控制服務器發送數據的速率。所以貪婪tcp協議主要是做在服務器端的。通過在服務器端采用貪婪tcp協議來提高用戶訪問網站/玩游戲的流暢度。很多大公司都會采用“把擁塞控制初始窗口改大幾十倍”的辦法來達到提高擁塞窗口的效果。不過我們作為一家自己寫內核的公司，順手做一個貪婪tcp協議能達到更好的效果。

在實現貪婪tcp協議時主要涉及到幾個技術點：

1、出口帶寬的監控和各個連接間的速率分配

我們是通過流量控制模塊來實現的（因為之前已經有流控了，這樣做成本最小），將各個tcp連接的數據包接入流控管理隊列，流控管理隊列根據當前出口帶寬情況控制選擇合適的數據包通過網卡發送出去；然后再將積壓未發送的數據長度反饋給各個tcp連接，減小tcp發送速率。一個更高性能的實現方案是：各個tcp連接將自己的發送狀態反饋到一個per-cpu流量管理中心，per-cpu流量管理中心為tcp連接分配當前時間周期能發送的數據量；各個per-cpu的流量管理中心則隔幾十毫秒同步一次數據。

2、流量控制窗口

tcp協議中，接收方可以通過流量控制窗口來限制發送方的發送速率。一般來說，當接收方的接收緩沖區不夠時，就會通過tcp流量控制窗口來限制發送方的發送速率。正常情況下，這種限制是很少發生的。但是為了保險起見，我們需要對tcp流量控制窗口進行支持。

3、別真的發的太快了

因為我們只考慮了服務器端出口帶寬，沒有考慮客戶端的出口帶寬。如果真的拼命發到1GB/s的數據，有可能把PC用戶的出口帶寬沖垮。因為我們只是用貪婪tcp協議來支持游戲、網頁瀏覽這種耗流量較小的服務器，很少會碰到一次發送數據超過1MB的情況，所以基本不會碰到“發的太快”的情況。

如果要支持大文件傳輸，則必須對客戶端出口帶寬進行預測。我們可以假定客戶端的網絡帶寬在若干小時內一般是固定的。然后計算當我們提高/降低速率時丟包率的變化。例如當我們以10KB/s傳輸數據時，丟包率就已經達到了20%；100KB/s時丟包率僅僅升高為23%，就可以認為丟包主要不是由我們引起的，可以進一步提高發送速率，提高我們搶帶寬的能力。

原文：//blog.chinaunix.net/uid-29873073-id-4498350.html