1樓：ggffss
kcp 作者說的很清楚了，KCP是為了低延遲而生。
例如流式傳輸等等。講道理用Kcp就是為了低延遲。所以。這些功能都有些多餘。
傳輸效率Kcp就segment的報頭就至少是32位元組了。怎麼和TCP的20位元組比？
2樓：SakyaZhu
可以考慮用飛馳傳輸的產品（http://
ftrans.cn
），相容TCP和UDP，提供API整合介面。這種事情花太高的代價去實現不如花點小錢。
3樓：Jake
超時重傳和nack肯定要結合使用，nack需要接收方多次的ack才能判斷要重發哪個包，只剩最後幾個包的時候只能靠傳送方定時器檢測unack的包，這個timeout要根據擁塞控制接受視窗等等係數計算出來，timeout的設定參考rfc4960 sack部分有詳細的實現你的問題早有方案。
4樓：韋易笑
1. kcp本來就不是為大流量傳送服務的，是為有限流量降低 rtt服務的，我主頁寫的很清楚，不是幫你提高每秒多少KB的頻寬利用率，而是幫你降低 rtt。再者你用kcp的時候設定的引數是什麼？
同時你是怎麼測試的？內網？公網？
如果你在內網測試不開網路模擬的話，基本沒什麼丟包，tcp是效能最好的，問題是公網不是這樣，公網有丟包，特別是高峰期。
2. nack超時傳送重傳請求的話，需要估計雙方rtt，超過短時均值rtt的 1.5倍就發起請求，有兩種回應，當前沒包了，或者有包。
3. 你tfrc沒寫對吧，好多用tfrc的協議不是跑的好好的？速率控制你做丟包遞減了沒？
4. 如姚老師，考慮多路tcp同時傳送，但是tcp執行緒開幾條就得了，5條以上有時適得其反。
5樓：
收到nack的時候，判斷該發的包是否在傳輸佇列裡。如果在，就忽略這個nack包。
不過看你不是很怕麻煩，要不把快速重傳加上？三個ACK發過來，就插隊傳送丟失的包。
6樓：吶吶啵
還可能你發了9，10，11，12，收到的順序是9，12，10，11。我覺得還得引入ack，不能一味的傳送，至少設定個滑動視窗，在視窗耗盡前還收不到一包確認，就得停下來等超時重發了。
怎麼將超大的檔案傳輸給別人？
雲盒子 雲盤！先把檔案上傳至雲盤，在雲盤中生成鏈結即可。不管多大的檔案都可以生成鏈結，並控制訪問許可權。雲盒子企業網盤 yhz66.com 雲盒子企業網盤 建立外鏈 雲盒子企業網盤 設定外鏈 windy 同類問題跨國大檔案傳輸，我們學校的研究專案也有過一段時間的調研 一般就2種方案 點對點直傳 通過...
群暉nas如何實現較快的檔案傳輸？
戈多在跳舞 我用FTP軟體傳，MBP網線連路由器，群暉也是網線連路由器，其它就沒有什麼高階網路架構了，路由器是網件r7000刷的梅林，傳輸速度大概能達到10MiB s 王大錘 如果沒理解錯，你是用無線連線nas對吧，對於千兆網路來說有限直連速度能達到100m s。而無限連線主要在於路由器和無線網絡卡...
為什麼將檔案傳輸到蘋果裝置上必須要通過 iTunes？
王希 用了兩天 iPad，感覺買蘋果真的和找了個爹一樣。在他的安排下，你幹啥都出不了大亂子。如果你嘗試適應他的安排，工作學習會很方便，也可以玩得挺爽。但一旦你想有點自由，有些方面想得和他安排得不一樣，那就難得要死了。作為一家公司，對使用者和爹一樣，反映的就是傲慢。無論你把我照顧得多好，我不願意除了我...