對于多任務多連接多執行緒實作限速的實作方法及思考
前言
最近在寫畢業設計，我的畢業設計就是用Rust語言實作一個Bittorrent客戶端協議及其拓展協議，順便寫個Web讓這個玩意能跑起來用，
總之就是要實作一個類似迅雷的下載器，下載器嘛，肯定要有限速功能的，不然吃滿帶寬導致其他應用餓死（BT下載尤其如此，因為是多連接多執行緒多任務下載，網路好的情況下真的很容易完全吃滿網速導致其需要網路的應用根本不能用，不僅下載帶寬會被吃滿，上傳帶寬也會被吃滿），
通常實作下載限速的方式就是固定時間內傳輸固定位元組數量，對于單任務單連接單執行緒來說，很好實作，直接傳輸完了就開始sleep就完事了，但是對于多任務多連接多執行緒來說，如何做到讓所有正在傳輸的執行緒的總和加起來的速度不超過設定值是一個讓我頭疼的問題，
所以我需要設計一個限速的方法或者說架構，來實作多執行緒多任務多連接下載，思考之前也在往上搜索了相關的資料，沒有找到適合這個場景的方法，只能自己想一個嘍，
系統架構
低耦合高內聚，不同的模塊之間雖然是包含關系，大部分操作通過資訊的傳遞來進行控制，
主行程可以設定全域限速，TASK可以設定TASK限速及TASK本身優先級，connect也可以單獨設定限速及優先級，（優先級本質上是資源分配權重）
實作思路
什么是速度？什么是限速？速度本質上是資源，限速本質上是有限資源的分配！
在BT下載中，速度通常來說分別有下載速度以及上傳速度，這都是速度，只是方向不同，因此統一用速度來代替下載和上傳兩種速度，下載和上傳除了方向不作區分，
-
物理中的定義，速度分為平均速度和瞬時速度，瞬時速度就是時間無限小之內的位移除以時間，那么在下載中的速度一般指瞬時速度，但是一般來說，如果要得到瞬時速度，那么基本上程式都用來算速度而不是邏輯執行以及網路傳輸了，所以這里的速度一般指的就是固定時間內，位元組傳輸的平均速度，假設1s傳輸了100位元組，那就是100Byte Per Second （100bps），因此軟體實作測速就是固定間隔時間，計算在這段時間內傳輸的總位元組數，很簡單的事情，
-
再深入一些，什么是限制速度？限制速度本質上就是限制一段時間內傳輸的位元組數量，也就是限制流量，想到這一刻的時候，我豁然開朗！對啊，速度也是一種資源，和記憶體一樣，是一種可以消耗的資源，
-
因此在多執行緒多模型多連接的傳輸場景下，實作限速，就可以使用“速度是資源”這一思想，要做的就是資源的分配，而且這種資源的分配不會像記憶體分配那樣產生內部碎片和外部碎片，因為流量本身就是連續的，是一種流，根本不用實作類似buddy系統+slab系統這種較為復雜的資源分配器，也不存在資源的返還，用了就是用了，不用還的，
資源分配方式
在我的設想中，資源（速度）的分配主要就分為兩種方式，
- 主動分配被動接受
- 主動申請被動分配
主動分配，被動接受
-
實作思路
在第一種方式中，主行程每隔一段時間掃描所有task，然后根據限速及優先級綜合分配資源，TASK執行緒每隔一段時間掃一遍connect，將自己有的資源分配給connect，在這種方式中，我們首先要保證公平性，也就是如果兩個task優先級一樣，并且連接性能理想化（也就是假設不給限速，帶寬就是無限大），需要分配的資源是相同的，也就是在實際下載中，速度相同，如果優先級不同，則根據優先級分配資源，
同樣的我們還需要保證高效率低浪費，對于同一個task下的所有connect，假設connect連接優先級均等同，那么這時候哪個連接的性能越好，其速度應該越高，因為如果均使用平均分配的方式，那么連接性能好的connect會饑餓，但是連接差的connect會過飽，多勞多得，本質上也是一種公平，
同時，還需要防止資源的“壟斷”，因為如果連接性能越好，獲得的資源越多，那么資源越多的情況下有時候會反應更好的連接性能，這時候就造成了壟斷，
因此，還需要一個方案來測算真實連接性能，
在一段時間內，有傳輸時間，有等待資源獲取時間，那么有效的時間就是傳輸時間，而不是資源獲取時間，因此實際連接性能應該根據 （流量/有效傳輸時間） 來測算，這樣可以保持公平性，
資源的浪費會導致達不到設定的速度，
-
架構優點
- 可以實作較復雜的優先級設定及資源分配模式
- 天然實作速度測量
-
架構缺點及問題
- 測算的開銷可能較大，而且測算是有誤差的，
- 反應慢，不能及時做出分配，在線路性能不穩定的時候，資源的等待時間可能會過長，
- 實作復雜
- 等待補充，讀者也可以在評論區提出呀
主動申請，被動分配
參考記憶體分配的方式，記憶體分配一般都是程式向作業系統提出申請，然后作業系統作出反應來分配記憶體，
-
實作思路
固定每次分配的流量大小，每次申請均回傳固定大小的資源，當connect用完資源后才去申請，task回應connect的申請，主行程回應task的申請，要保證一段時間內保證可以分配匹配限速的資源數量，不然會導致task的流量堆積，
-
架構優點
- 回應速度快
- 資源利用率高
- 實作簡單
-
架構缺點
- 復雜的分配邏輯難以實作
- 需要額外實作速度測量
- 等待補充，讀者也可以在評論區提出呀
代碼實作
主動分配，被動接受
todo
主動申請，被動分配
todo
如果錯誤之處，一定要指出來！
感謝你的閱讀，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/547034.html
標籤：架構設計
下一篇：python策略模式場景