從KCP中窺探TCP存在的問題

2021-08-21 04:11:16 字數 1109 閱讀 7236

kcp是一種基於上層協議的(udp協議)快速可靠協議,在kcp官網中提到跟tcp相比的優勢就是降低延時,能夠平均降低30%~40%的延時時間且最大延遲降低三倍的傳輸效果,不過所付出的代價是浪費比tcp10%~20%的頻寬代價。

從個人角度來看,可以從三個方面去分析kcp與tcp的所導致的效能問題:

1、計算包超時的策略

2、包重傳的策略

3、退流控制策略

計算包超時策略:

tcp計算超時的策略是每超時一次新的rto=rto*2,這種策略對於在網路不穩定的情況下影響是很致命的,而kcp在快速模式下是rto=rto*1.5,這樣在網路不穩的情況下會傳輸速度就會很差。還有一點很重要的是tcp預設是開啟延時ack的,這樣的話rto就會比真實的大,然而再加上rto=rto*2的情況下網路傳輸速度就會更慢。

包重傳策略:

包重傳策略方面有兩個主要的區別,分別來自於重傳判斷以及包重傳邏輯策略:

(1) 重傳判斷:

在判斷重傳方面,kcp在處理包重傳的策略是跟tcp(tcp快重傳機制)的策略是基本一致的,差別在於tcp需要接收到丟包的後三個包就認為是丟包了重傳而kcp只需兩次。

(2) 包重傳邏輯:

在網路中傳輸1,2,3,4,5包時,如果包2丟失了且客戶端已確認需重傳,那麼tcp跟kcp的對待方式會不一樣,tcp會認為如果包2丟了有可能包3,4,5也有可能丟失,因此tcp會把2,3,4,5包也一併進行重發。而kcp的做法是認為只是由於網路上一剎那的問題導致包2丟了,後續的包還是正常傳送過去的(kcp呈現的一種樂觀的心態^_^),因此kcp只會傳認為丟失的那乙個包。

*注意:tcp有sack選項用來減少這種重複報重傳的演算法,具體為當服務端確定有丟包了,服務端就會在tcp包頭的sack選項中新增確實的包序號的範圍,從而讓客戶端只傳輸丟失的包。

退流控制策略:

正常情況下kcp與tcp有著一致的退流避讓策略,基本策略為:傳送快取視窗、接收快取視窗、丟包退讓、慢啟動,但是kcp可以通過配置去跳過後面兩個策略(丟包退讓、慢啟動),因此kcp可以在網路擁堵的情況下也能進行快速的資料傳送(搶網路)

*關於tcp丟包退讓以及慢啟動可以參看後續的《關於tcp擁塞處理的思考》文章

scrapy 中存在的問題

1 關於spider中的custom settings 我有乙個需求是向spider中傳入custom settings 但是通過 init f方法之後發現不起作用,看了文件之後發現,必須是類的屬性才行 這時候要傳就需要使用spider來傳了 但是還存在的問題就是,關於一些pipeline的設定就沒...

TCP中的CRC問題

tcp給crc的長度是一定的,如果校驗和的長度超出範圍怎辦?具體是怎麼實現的?ushort checksum ushort buffer,int size if size cksum cksum 16 cksum 0xffff cksum cksum 16 return ushort cksum 在...

使用ckeditor中存在的問題

1.引入js ckeditor ckeditor.js script 2.定義textarea test div 3.啟用控制項 1 第一種寫法 ckeditor.replace test 指定textarea的id 2 另一種寫法,可以設定一些屬性值 ckeditor.replace test 1...