移动端 | 加入收藏 | 设为首页 | 我要投稿 | 赞助本站 | RSS
 

freefq.comfree——免费、自由fq——翻墙

困在墙内,请发邮件到freefqcom#gmail.com获得最新免费翻墙方法!
您当前的位置:首页 > 翻墙动态

Congestion Control Arrives in Tor 0.4.7-stable!

时间:2022-05-12  来源:torproject  作者:mikeperry 条评论

Tor has released 0.4.7.7, the first stable Tor release with support for congestion control. Congestion control will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays. It will result in significant performance improvements in Tor, as well as increased utilization of our network capacity. In order for users to experience these benefits, we need Exit relay operators to upgrade as soon as possible. This post covers a bit of congestion control history, describes technical details, and contains important information for all relay and onion service operators.WDk免费翻墙网

What is Congestion Control?

Congestion Control is an adaptive property of distributed networks, whereby a network and its endpoints operate such that utilization is maximized, while minimizing a constraint property, and ensuring fairness between connections. When this optimization problem is solved, the optimal outcome is that all connections transmit an equal fraction of the bandwidth of the slowest router in their shared path, for every path through the network.WDk免费翻墙网

TCP Congestion Control solves this optimization problem primarily by minimizing packet drops as the constraint property, effectively increasing speed until router queues overflow, and reducing speed in proportion to these drops. In TCP terminology, the congestion control optimization problem is solved by setting the Congestion Window equal to the Bandwidth-Delay Product of a path.WDk免费翻墙网

Some congestion control algorithms can make use of auxiliary information, such as latency, in order to anticipate congestion before the point at which queues overflow and packets drop. Notable examples are TCP Vegas, Bittorrent's LEDBAT, and Google's BBR.WDk免费翻墙网

Congestion Control Means a Faster Tor

While Tor uses TCP between relays, Tor was designed without any end-to-end congestion control through the network itself. Instead, it set a fixed window size of 1000 512-byte Tor cells on a circuit. In the early days of Tor, this resulted in unbearable latency caused by excessive queue delay, because these windows were much larger than each client's fair share of the Bandwidth-Delay Product on any given circuit. In the early Tor days, users could wait for up to a minute for a page load to respond. This also meant that relays used a huge amount of memory in these cases.WDk免费翻墙网

Once spare network capacity increased such that the spare Bandwidth-Delay Product of circuits exceeded this fixed window size of 1000 cells, overall latency improved due to lower queue delay, but throughput began to level off. Because the Bandwidth-Delay Product was artificially limited to 1000 cells, this fixed window size became a speed limit, with the property that lower-latency circuits had higher throughput than high-latency circuits, directly in proportion to their latency.WDk免费翻墙网

This turning point with respect to the window size happened around 2015:WDk免费翻墙网

Throughput and Latency from 2013-2016WDk免费翻墙网

When this capacity turning point was reached, congestion control became not only something that would improve latency, it would also significantly increase throughput.WDk免费翻墙网

This turning point made congestion control a top-priority improvement for the Tor network! Congestion control will remove this speed limit entirely, and will also reduce the impact of path latency on throughput.WDk免费翻墙网

History of Congestion Control Research on Tor

Unfortunately, because Tor's circuit cryptography cannot support packet drops or reordering, the research community struggled for nearly two decades to determine a way to provide congestion control on the Tor network.WDk免费翻墙网

Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.WDk免费翻墙网

This ultimately left only a very small class of candidate algorithms to consider: those that used Round-Trip Time to measure queue delay as a congestion signal, and those that directly measured Bandwidth-Delay Product. The up-shot is that this class of algorithms only requires clients and Exit relays and onion services to upgrade; they do not require any changes to intermediate relays.WDk免费翻墙网

We ultimately specified three candidate algorithms informed by prior Tor and TCP research: Tor-Westwood, Tor-Vegas, and Tor-NOLA. These algorithms are detailed in Tor Proposal 324WDk免费翻墙网

Tor-Westwood is based on the unnamed RTT threshold algorithm from the DefenestraTor Paper, in combination with Bandwidth-Delay Product estimation ideas from TCP Westwood.WDk免费翻墙网

Tor-Vegas is very closely based on TCP Vegas. TCP Vegas uses a much more fine-grained RTT ratio to directly estimate the total queue length on the path, and then targets a specific queue length as the constraint criteria. TCP Vegas is extremely efficient and effective, and is able to achieve fairness without any packet drops at all. However, it was never deployed on the Internet, because it was out-competed by the more aggressive and already deployed TCP Reno. Because Reno continues increasing speed until packet drops happen, TCP Reno would end up soaking up the capacity of less aggressive Vegas flows that did not drop packets.WDk免费翻墙网

The final algorithm, Tor-NOLA, was created to test the behavior of Bandwidth-Delay Product estimation used directly as the congestion window, without any adaptation.WDk免费翻墙网

An additional component, called Flow Control, is necessary to handle the case where an Internet destination or application is slower than Tor. We won't cover Flow Control in this post, but the interested reader can examine those details in Section 4 of Proposal 324.WDk免费翻墙网

Implementation, Simulation, and Deployment

We implemented all three algorithms (Tor-Westwood, Tor-Vegas, and Tor-NOLA) in Tor 0.4.7, and subjected them to extensive evaluation in the Shadow Simulator.WDk免费翻墙网

The end result was that Tor-Westwood and Tor-NOLA exhibited ack compression, which caused them to wildly overestimate the Bandwidth-Delay Product, which lead to runaway congestion conditions. Standard mechanisms for dealing with ack compression, such as smoothing, probing, and long-term averaging did little to address this, perhaps because of the lack of packet drops as a backstop on queue pressure. Tor-Westwood also exhibited runaway conditions due to the nature of its RTT threshold. (As an aside, Google's BBR algorithm also has these problems, and relies on packet drops as a backstop as well).WDk免费翻墙网

Tor-Vegas performed beautifully, almost exactly as the theory predicted. Here's the Shadow Simulator's throughput graphs of clients with simulated locations in Germany and Hong Kong:WDk免费翻墙网

Simulated HK and German ClientsWDk免费翻墙网

While there is still a difference in throughput between these two locations, the speed limit from 0.4.6 Tor is clearly gone. End-to-end latency was not affected at all, according to the simulator.WDk免费翻墙网

Additionally, Tor-Vegas was not out-competed by legacy Tor traffic, allowing us to enable it as soon as 0.4.7 came out. We also gain protection from rogue algorithms via the combination of KIST and Circuit-EWMA, which were previously deployed on Tor to address latency problems during the BDP bottleneck era.WDk免费翻墙网

Exit Relay Operators: Please Upgrade!

Users of Tor versions 0.4.7 and above will experience faster performance when using Exits or Onion Services that have upgraded to 0.4.7.WDk免费翻墙网

This means that in order for users to see the benefits of these improvements, we need our Exit relay operators to upgrade to the new Tor 0.4.7 stable series, asap!WDk免费翻墙网

Packages for Debian, Ubuntu, and Fedora/CentOS/RHEL are already available. Please follow those links for instructions on using our packaging repos for those distributions, and upgrade asap!WDk免费翻墙网

BSD users should be able to install this release from their flavor's ports system.WDk免费翻墙网

If you run into problems while upgrading your relay, you can ask your questions on the public tor-relays mailing list and Relay Operator sub-category on the Tor Forum. You can also get help by joining the channel #tor-relays.WDk免费翻墙网

All Relay Operators: Be Prepared to Set Bandwidth Limits

Non-exit relay operators do not need to upgrade for congestion control to work, but this also means they may be surprised by the network effects of congestion control traffic running through their relays.WDk免费翻墙网

The faster performance and increased utilization of congestion control means that we will soon be able to use the full capacity of the Tor network. This means that all relays will soon experience new bottlenecks. Congestion control should prevent these bottlenecks from overwhelming relays completely, but this behavior may come as a surprise to operators who were used to the last several years of low CPU and bandwidth utilization.WDk免费翻墙网

We are already seeing an increase in the Advertised Bandwidth of relays as a result of some higher-throughput congestion control circuit use, similar to our previous flooding experiments, even though most clients are not yet using congestion control:WDk免费翻墙网

Advertised Bandwidth IncreaseWDk免费翻墙网

This increase is because Advertised Bandwidth is computed from the highest 7-day burst of traffic seen, where as Consumed Bandwidth is the average byte rate. As more clients upgrade, particularly after a Tor Browser Stable release with 0.4.7 is made, the Consumed Bandwidth of the network should also rise. We expect to make this Tor Browser Stable release on May 31st, 2022.WDk免费翻墙网

Once users migrate to this new release, relay operators who pay for bandwidth by the gigabyte may want to consider enabling hibernation, to avoid surprise cost increases.WDk免费翻墙网

This increased traffic may also cause your relay CPU usage to spike, due to increased cryptographic load of the additional traffic. In theory, Tor-Vegas congestion control should treat CPU throughput bottlenecks exactly the same as bandwidth bottlenecks, and back off once CPU bottleneck causes queue delay. However, if you also pay for CPU, you may want to rate limit your relay's bandwidth.WDk免费翻墙网

Relays may also experience overload on the Relay Search Portal. Here is an example of that:WDk免费翻墙网

Corona OverloadWDk免费翻墙网

This overload indicator may appear for several reasons. If your relay has this overload indicator, follow the instructions on our overload support page, in order to diagnose the specific cause. If the cause is CPU overload, consider setting bandwidth limits, to reduce the traffic through your relay.WDk免费翻墙网

If you have issues diagnosing or eliminating the cause of overload, you can ask questions on the public tor-relays mailing list and Relay Operator sub-category on the Tor Forum. You can also get help by joining the channel #tor-relays.WDk免费翻墙网

Onion Service Operators Should Also Upgrade

Just like Exit relays, Onion Services also need to upgrade to 0.4.7 for users to be able to use congestion control with them.WDk免费翻墙网

Additionally, Tor 0.4.7 has a security improvement for short-lived onion services, called Vanguards-Lite. This system will reduce the risk of attacks that can discover the Guard relay of an onion service or onion client, so long as that onion service is around for a month or less. Longer lived onion services are still encouraged to use the vanguards addon.WDk免费翻墙网

Deployment Plan

The Tor Browser Alpha series already supports congestion control, but it won't experience improved performance unless an 0.4.7 Exit or Onion Service is used with it.WDk免费翻墙网

Because our network is roughly 25% utilized, we expect that throughput may be very high for the first few users who use 0.4.7 on fast circuits with fast 0.4.7 Exits, until the point where most clients have upgraded. At that point, a new equilibrium will be reached in terms of throughput and network utilization.WDk免费翻墙网

For this reason, we are holding back on releasing a Tor Browser Stable with congestion control, until enough Exits have upgraded to make the experience more uniform. We hope this will happen by May 31st.WDk免费翻墙网

Also for this reason, we won't be upgrading our Tor performance metrics sources to 0.4.7 until enough Exits have upgraded for those measurements to be an accurate reflection of congestion control. So these improvements will not be reflected in our performance metrics until we upgrade those onionperf instances, either.WDk免费翻墙网

The Future

The astute reader will note that we rejected datagram transports. However, this does not mean that Tor will never carry UDP traffic. On the contrary, congestion control deployment means that queue delay and latency will be much more stable and predictable. This will enable us to carry UDP without packet drops in the network, and only drop UDP at the edges, when the congestion window becomes full. We are hopeful that this new behavior will match what existing UDP protocols expect, allowing their use over Tor.WDk免费翻墙网

This still leaves the problem that very slow Tor relays may become a bottleneck, prohibiting the use of interactive voice and video over UDP while using them in a circuit. To address this problem, we will be examining our Guard and Fast relay bandwidth cutoffs, to avoid giving these flags to relays that are too slow to handle multiple clients at once.WDk免费翻墙网

Additionally, in Tor 0.4.8, we will be implementing a traffic splitting mechanism based on a previous Tor research paper called Conflux, with improvements from recent Multipath TCP research. This system is specified in Tor Proposal 329.WDk免费翻墙网

Conflux has the ability to rebalance traffic over multiple paths to an Exit relay, optimizing for either throughput, or latency.WDk免费翻墙网

With Conflux, Exit relays will become the new the speed limit of Tor, making fast Exits more valuable than ever before!WDk免费翻墙网

来顶一下
返回首页
返回首页
欢迎评论:免登录,输入验证码即可匿名评论 共有条评论
用户名: 密码:
验证码: 匿名发表

推荐资讯

自由浏览器FreeBrowser5.1.2下载
自由浏览器FreeBrowse
原子网络加速器 - 免费高速VPN 一键链接 方便快捷
原子网络加速器 - 免费
foxovpn绿狐VPN——即连即用、快速、安全
foxovpn绿狐VPN——即
Dubai VPN - Free, Fast & Secure VPN下载
Dubai VPN - Free, Fa
相关文章
栏目更新
栏目热门
墙外新闻
读者文摘

你可以访问真正的互联网了。You can access the real Internet.

管理员精中特别提醒:本网站域名、主机和管理员都在美国,且本网站内容仅为非中国大陆网友服务。禁止中国大陆网友浏览本站!若中国大陆网友因错误操作打开本站网页,请立即关闭!中国大陆网友浏览本网站存在法律风险,恳请立即关闭本站所有页面!对于您因浏览本站所遭遇的法律问题、安全问题和其他所有问题,本站均无法负责也概不负责。

特别警告:本站推荐各种免费科学上网软件、app和方法,不建议各位网友购买收费账号或服务。若您因付费购买而遭遇骗局,没有得到想要的服务,请把苦水往自己肚子里咽,本站无法承担也概不承担任何责任!

本站严正声明:各位翻墙的网友切勿将本站介绍的翻墙方法运用于违反当地法律法规的活动,本站对网友的遵纪守法行为表示支持,对网友的违法犯罪行为表示反对!

网站管理员定居美国,因此本站所推荐的翻墙软件及翻墙方法都未经测试,发布仅供网友测试和参考,但你懂的——翻墙软件或方法随时有可能失效,因此本站信息具有极强时效性,想要更多有效免费翻墙方法敬请阅读本站最新信息,建议收藏本站!本站为纯粹技术网站,支持科学与民主,支持宗教信仰自由,反对恐怖主义、邪教、伪科学与专制,不支持或反对任何极端主义的政治观点或宗教信仰。有注明出处的信息均为转载文章,转载信息仅供参考,并不表明本站支持其观点或行为。未注明出处的信息为本站原创,转载时也请注明来自本站。

鉴于各种免费翻墙软件甚至是收费翻墙软件可能存在的安全风险及个人隐私泄漏可能,本站提醒各位网友做好各方面的安全防护措施!本站无法对推荐的翻墙软件、应用或服务等进行全面而严格的安全测试,因此无法对其安全性做保证,无法对您因为安全问题或隐私泄漏等问题造成的任何损失承担任何责任!

S. Grand Ave.,Suite 3910,Los Angeles,CA 90071

知识共享许可协议
本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。