关于街头篮球网速优化

来源：蜘蛛抓取(WebSpider) 时间：2020-06-16 17:27 标签： 街头篮球网速优化

cFosSpeed (优化网速) 中文特别版[目前最好用嘚有原理说明!]

一款具有很多功能DSL modem和路由器驱动软件,可以充分使用你的ISDN和DSL连接。

用于DSL 调制解调器和路由器；

与通用的 PPPoE 驱动器兼容；

应答游戲以及例如 eMuleKazaa 等的对等网络；

通信量计数器及计时器；

最优远程数据通信网连接提高网速；

智能识别不在使用中的连接等!

TCP 採取交握式封包傳送機制，傳送端必須等待接收端的 ACK（認知）封包傳回後才會繼續傳送下一個封包。也就是說如果傳送端一直等不到接收端的 ACK 封包時，它會一直等待到傳回 ACK 為止這段時間不會傳送任何新的封包；超過時間後，會切斷與接收端的通信 為此，現有 ADSL 多半建議使用者將 TCP 封包長度盡可能開到最大目的是減少 ACK 交握訊號的次數。然而這麼做會有個副作用就是在全速上傳時，排隊在後面的 ACK 封包會因為前一個封包上傳佔據大量時間，無法「及時」傳送給「傳送端」造成 (1) 的狀況。 如果將 TCP 封包長度減少則單位時間內 ACK 交握次數增加，「或許」可以減輕因為全速上傳造成的排隊中的 ACK 封包的延遲「機率」但仍然因為較多的 overhead（封包本身的控制區塊所佔用的頻寬），也沒有佔多少便宜 整理 (2) 與 (3) 可發現，問題都出在 ACK 交握的時間點是否能在「傳送端」等待時間之內這是因為 Windows 內建的 TCP/IP 驅動器，沒有「封包優先權」的設計造成「上傳滿檔壓死下載」的奇特現象。

這張圖就是在說沒有收到「接收端」ACK 封包時「傳送端」停止下一個封包輸出。左邊是「接收端」、祐邊是「傳送端」、紅色小方塊是傳送端等待輸出的封包、正在傳送的綠色是「ACK 封包」由於 TCP 交握機制的運作，收到一個紅色小方塊時僦必須傳一個綠色小方塊對方，告訴對方我已經確實的收到了接下來才能再傳一個紅色小方塊過來。

若無提高 ACK 封包的優先權在網路上傳流量繁忙的時候，因為 ACK 封包延遲送出而造成下載不順的情況出現。

那麼啟動 Traffic Shaping 以後的結果是什麼很明顯的發現，綠色的小方塊（ACK 封包）可以「插隊」在藍色小方塊（上傳封包）之間而且插隊的位置，是在下一個要傳送封包的預備位置也就是說，封包之間產生了「優先權」的機制?所以紅色小方塊（下傳封包）可以不受藍色小方塊（上傳封包）的影響繼續的輸出資料給接收端。對於 P2P 來說這正是最迫切需要的功能。

相信大家看了这么多已经明白点了道理的很不错的一款软件．喜欢的朋友就支持一下！！让更多人受益！！

免责声明：夲文仅代表文章作者的个人观点，与本站无关其原创性、真实性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分內容文字的真实性、完整性和原创性本站不作任何保证或承诺请读者仅作参考，并自行核实相关内容

我要回帖

更多关于 街头篮球网速优化 的文章

 

随机推荐