[tor-bugs] #15482 [Tor]: Don't surprise users with new circuits in the middle of browsing
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Jul 25 10:28:34 UTC 2015
#15482: Don't surprise users with new circuits in the middle of browsing
-------------------------+-------------------------------------------------
Reporter: | Owner: mikeperry
mikeperry | Status: needs_information
Type: | Milestone: Tor: 0.2.7.x-final
enhancement | Version:
Priority: normal | Keywords: tbb-usability, MikePerry201503,
Component: Tor | tbb-wants, TorBrowserTeam201507R
Resolution: | Parent ID:
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Comment (by yawning):
Replying to [comment:27 mikeperry]:
> As it is deployed today, I don't think that this patch should be
changing the total number of circuits significantly. If you are
continuously using a website, you will have *some* circuit open for it.
Really the only thing this patch does is make you tend to use the same
circuit for that activity rather than using a new one.
>
> In aggregate, I guess this *might* cause connections to live longer
between relays, but I doubt it.
Metrics needed here, a bit too late to really characterize the old
behavior, but I believe that number of channels/circuits per relay metrics
will be useful information to have.
> What is more likely the culprit is that in Tor Browser 4.5, we also
reset our connection keepalive to match to Firefox default of 2 minutes
(up from 20 seconds), since we solved #4100. That would cause more
connections to stay open, since the HTTP connections are now being kept
open for longer. I think this in combination with more users is the real
problem.
>
> SPDY and HTTP/2 will make this even worse, since its keep-alive duration
is potentially infinite.
I will reiterate that this isn't a fundamental problem with this patch,
since relays SHOULD (MUST) be able to support talking to any other relay
(and lots of clients or servers if they happen to be Guards/Exits). You
brought up testing inter-relay connectivity and delisting (or reducing the
consensus weight) of relays that fail to build circuits. I think this
will be a good idea, moving forward but such tests are likely to be quite
time consuming. I seem to recall someone running this sort of experiment
in the past, but I don't recall the trac number off the top of my head.
I'd be willing to bet that due to internet quirks all relays can't talk to
every other relay (even if they aren't stuck behind some crappy NAT box).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15482#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list