UGC版中的乙個速度只有幾K的BUG分析

2021-05-27 01:52:55 字數 1081 閱讀 1020

最近在做ugc專案,使用udp協議上傳,自己做了一層比較簡單的擁塞控制,機制如下:

1、每個會話都有乙個傳送佇列,根據當前計算出的傳送速率勻速傳送

2、伺服器每秒返回乙個控制訊息,包含的資訊有伺服器接收資料報的速率和丟包率等

3、客戶端根據伺服器返回的控制訊息調整傳送佇列裡的資料報的傳送速率

今天有一台機器突然出現只有一兩kb的上傳速度,這明顯有問題,正常應該是佔滿上行頻寬的。而且超時重傳的資料報反而比滿頻寬上傳時多n倍。這就怪了!按道理,傳送速度如此的慢,超時應該更少才對。

後來認真分析了下,找到原因了,為了避免忘記,記錄一下:

為什麼只有幾k的上傳?

因為傳送佇列的傳送速率是按伺服器丟包率來調整的,調整**如下:

if(lost < 5.0f)

else

其中send_speed是浮點型

從中可以看出,當丟包率小於5%時,是1.1到1.2倍的增長,但當丟包率大於5%,特別是特別大時,傳送速率會急劇下滑,真是緩漲大落呀

那麼最終可能會導致send_speed為1的結果。

從**來看,就算是緩漲大落,速度也應該能馬上調上去才對,但為什麼就是調不上去呢??

呵呵,其實伺服器返回的丟包率也不是真正的丟包率,而是在1秒內伺服器沒有收到的資料報,那麼就包括了真正丟的資料報和正在路上的資料報。

現在1秒才發1到2個包,那在路上的資料報的機率就大大增加了。比如一秒才發2個包,那有乙個還有路上,這丟包率就是50%了,速度怎麼能上得去?

還有,傳送佇列裡的傳送速率是dword的,float轉成dowrd,1點幾的值全白漲了,都是1

至於為什麼**會這樣寫,我只能說事件就是這樣了,至於你信不信,反正我是信了!

為什麼傳送速度慢了,超時反而多了?

因為兩點之間的rtt其實很小的,而我的超時值為4倍的rtt。而佇列裡能push16個包,發乙個包就push乙個包。好了,現在每秒只能發兩個包了,而超時又是從放入佇列時算起,這樣一來在佇列裡呆的時間都大於4rtt了

後話:這樣挫的**,我也無奈,老大要我四天寫完,而能力有限的我加班加點用了近兩周才寫完,難免會出這樣那樣的錯誤。老大臉色不好,我也累。。。

python中的元組如何定義只有乙個元素

如果要定義乙個空的tuple,可以寫成 t t try 但是,要定義乙個只有1個元素的tuple,如果你這麼定義 t 1 t 1try 定義的不是tuple,是1這個數!這是因為括號 既可以表示tuple,又可以表示數學公式中的小括號,這就產生了歧義,因此,python規定,這種情況下,按小括號進行...

python中的元組如何定義只有乙個元素

壹 要定義乙個只有1個元素的tuple,不能直接 1 因為括號 既可以表示tuple,又可以表示數學公式中的小括號,這就產生了歧義 貳 因此,python規定,這種情況下,按小括號進行計算,計算結果自然是1。叄 所以,只有1個元素的tuple定義時必須加乙個逗號,來消除歧義 t 1,或參考 pyth...

速度 人類的乙個本性

縱看整科學技術的發展,從蒸汽機的發明,從汽車的發明,從 的發明,從電腦的發明,從網際網路的發明到未來人工智慧的發展可以看出,人們的生活速度越來越快了,而且不可能再回去了。人們依賴上了快速的網路,交通帶來的便利,效率與快感,不再喜歡耐心的等待。為什麼人天生就喜歡快速呢?如果乙個電腦的頁面開啟超過10秒...