對於多任務多連接多線程實現限速的實現方法及思考

前言

最近在寫畢業設計，我的畢業設計就是用Rust語言實現一個Bittorrent客戶端協議及其拓展協議，順便寫個Web讓這個玩意能跑起來用。

總之就是要實現一個類似迅雷的下載器。下載器嘛，肯定要有限速功能的，不然吃滿帶寬導致其他應用餓死（BT下載尤其如此，因為是多連接多線程多任務下載，網路好的情況下真的很容易完全吃滿網速導致其需要網路的應用根本不能用，不僅下載帶寬會被吃滿，上傳帶寬也會被吃滿）。

通常實現下載限速的方式就是固定時間內傳輸固定位元組數量。對於單任務單連接單線程來說，很好實現，直接傳輸完了就開始sleep就完事了。但是對於多任務多連接多線程來說，如何做到讓所有正在傳輸的線程的總和加起來的速度不超過設定值是一個讓我頭疼的問題。

所以我需要設計一個限速的方法或者說架構，來實現多線程多任務多連接下載。思考之前也在往上搜索了相關的資料，沒有找到適合這個場景的方法。只能自己想一個嘍。

系統架構

低耦合高內聚。不同的模塊之間雖然是包含關係，大部分操作通過信息的傳遞來進行控制。
主進程可以設置全局限速，TASK可以設置TASK限速及TASK本身優先順序，connect也可以單獨設置限速及優先順序。（優先順序本質上是資源分配權重）

實現思路

什麼是速度？什麼是限速？速度本質上是資源，限速本質上是有限資源的分配！

在BT下載中，速度通常來說分別有下載速度以及上傳速度，這都是速度，只是方向不同，因此統一用速度來代替下載和上傳兩種速度，下載和上傳除了方向不作區分。

• 物理中的定義，速度分為平均速度和瞬時速度。瞬時速度就是時間無限小之內的位移除以時間。那麼在下載中的速度一般指瞬時速度，但是一般來說，如果要得到瞬時速度，那麼基本上程式都用來算速度而不是邏輯執行以及網路傳輸了。所以這裡的速度一般指的就是固定時間內，位元組傳輸的平均速度。假設1s傳輸了100位元組，那就是100Byte Per Second （100bps）。因此軟體實現測速就是固定間隔時間，計算在這段時間內傳輸的總位元組數。很簡單的事情。

• 再深入一些，什麼是限制速度？限制速度本質上就是限制一段時間內傳輸的位元組數量。也就是限制流量。想到這一刻的時候，我豁然開朗！對啊，速度也是一種資源，和記憶體一樣，是一種可以消耗的資源。

• 因此在多線程多模型多連接的傳輸場景下，實現限速，就可以使用“速度是資源”這一思想。要做的就是資源的分配，而且這種資源的分配不會像記憶體分配那樣產生內部碎片和外部碎片。因為流量本身就是連續的，是一種流。根本不用實現類似buddy系統+slab系統這種較為複雜的資源分配器。也不存在資源的返還，用了就是用了，不用還的。

資源分配方式

在我的設想中，資源（速度）的分配主要就分為兩種方式。

1. 主動分配被動接受
2. 主動申請被動分配

主動分配，被動接受

1. 實現思路
   在第一種方式中，主進程每隔一段時間掃描所有task，然後根據限速及優先順序綜合分配資源。TASK線程每隔一段時間掃一遍connect，將自己有的資源分配給connect。

   在這種方式中，我們首先要保證公平性，也就是如果兩個task優先順序一樣，並且連接性能理想化（也就是假設不給限速，帶寬就是無限大）。需要分配的資源是相同的，也就是在實際下載中，速度相同。如果優先順序不同，則根據優先順序分配資源。

   同樣的我們還需要保證高效率低浪費，對於同一個task下的所有connect，假設connect連接優先順序均等同，那麼這時候哪個連接的性能越好，其速度應該越高。因為如果均使用平均分配的方式，那麼連接性能好的connect會饑餓，但是連接差的connect會過飽。多勞多得，本質上也是一種公平。

   同時，還需要防止資源的“壟斷”。因為如果連接性能越好，獲得的資源越多，那麼資源越多的情況下有時候會反應更好的連接性能，這時候就造成了壟斷。

   因此，還需要一個方案來測算真實連接性能。

   在一段時間內，有傳輸時間，有等待資源獲取時間。那麼有效的時間就是傳輸時間，而不是資源獲取時間。因此實際連接性能應該根據 （流量/有效傳輸時間） 來測算，這樣可以保持公平性。

   資源的浪費會導致達不到設置的速度。

2. 架構優點

   • 可以實現較複雜的優先順序設置及資源分配模式
   • 天然實現速度測量

3. 架構缺點及問題

   • 測算的開銷可能較大，而且測算是有誤差的。
   • 反應慢，不能及時做出分配，線上路性能不穩定的時候，資源的等待時間可能會過長。
   • 實現複雜
   • 等待補充，讀者也可以在評論區提出呀

主動申請，被動分配

參考記憶體分配的方式，記憶體分配一般都是程式向操作系統提出申請，然後操作系統作出反應來分配記憶體。

1. 實現思路
   固定每次分配的流量大小，每次申請均返回固定大小的資源。當connect用完資源後才去申請。task響應connect的申請，主進程響應task的申請。

   要保證一段時間內保證可以分配匹配限速的資源數量，不然會導致task的流量堆積。

2. 架構優點

   • 響應速度快
   • 資源利用率高
   • 實現簡單

3. 架構缺點

   • 複雜的分配邏輯難以實現
   • 需要額外實現速度測量
   • 等待補充，讀者也可以在評論區提出呀

代碼實現

主動分配，被動接受

todo

主動申請，被動分配

todo

如果錯誤之處，一定要指出來！
感謝你的閱讀。