[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3875 [Firefox Patch Issues]: TBB's Firefox should use optimistic data socks handshake variant
#3875: TBB's Firefox should use optimistic data socks handshake variant
-----------------------------------+----------------------------------------
Reporter: arma | Owner: mikeperry
Type: enhancement | Status: new
Priority: major | Milestone: TorBrowserBundle 2.3.x-stable
Component: Firefox Patch Issues | Version:
Keywords: performance roundtrip | Parent: #3890
Points: | Actualpoints:
-----------------------------------+----------------------------------------
Comment(by t55wang):
Replying to [comment:15 mikeperry]:
> Replying to [comment:13 t55wang]:
> > Replying to [comment:12 mikeperry]:
> > > Replying to [comment:11 t55wang]:
> > > > I've implemented preliminary versions of both. Right now, the
"tiny change to FF" approach works except for the SSL handshake, which is
to say it does not work. The "modifying OP" approach works, but doesn't
deal with some errors very well yet. I will keep you updated when either
or both approaches do in fact work.
> > >
> > > How exactly does the SSL handshake fail, and in what cases?
> > >
> > > And for the OP case, what does "not dealing with some errors very
well" mean in practice? The user experience for errors is already pretty
bad. I think in practice we can ignore most UX issues with the errors
since the perf benefit for the good case is so clear.
> >
> > These things have been fixed. For the SSL handshake, I told it to stop
polling after one round and I shouldn't have. For the errors, I meant that
DNS resolution failure returns "connection has been reset" to the Browser,
which seems confusing, so I wrote an error message explaining what
happened (copying from the original "Tor is not an HTTP proxy" message)
for that case.
>
> Ah yeah, for DNS typos that's pretty sad... Random thought: On the
Firefox side, we could simply retry with optimistic data disabled before
actually displaying any errors... The error path would then be like 2X as
slow but correct, but the common case would be still fast. Or, we could
sink the work into figuring out how to communicate the error belatedly
through some ungodly side channel. I would not be opposed to either of
these approaches, if one or both are easy...
>
> However, looking at your change to Tor, it looks like we can still give
the exact error condition to the user anyways.. Unless that's what you
mean wrt the port 80 hack? I guess the error message gets eaten by Firefox
if the DNS failure was for a 443 connect? Oh, ew, also, we'd have to
localize that message in tor either way, and I think tor currently has no
localization support at all for any messages :/.
>
The error is sort of communicated to the user in this patch I posted - if
DNS resolution fails with the Tor fix (not the Tor Browser fix), the user
will see a message displayed in the Browser saying something like "Tor has
terminated the connection because DNS resolution failed".
Oh, you're right, 443 connects were not considered. I could change it to
"port 80 or port 443". Not sure if this is the best solution.
What do you mean by localization?
> > > Also, can you attach patches as well? It will make it easier for us
to make suggestions/decisions.
> >
> > I have included patches for both the Tor Browser and Tor. Both are
working, but performance measurements are underway and should be done by
tomorrow.
> >
> > The Tor Browser fix is slightly more involved, as it introduces a new
state to the connect process (marking where the GET request can be sent)
and changes the behavior of the SOCKS handshake. I am not sure if there
are unforeseen consequences of flipping the handshake on its head -
everything I've tried has worked so far. The Tor fix is much simpler (the
core is literally one line), but there are some potential problems. We did
a "hack" where Tor checks if the port we're trying to talk to is port 80,
and only displays the specific HTTP error message (for DNS resolution
failure) in that situation. There's also the problem that Tor is
essentially lying to Firefox by telling it that the socks connect has been
accepted by the end server, when it hasn't been.
>
> Do you know off-hand if we can grow the SOCKS state machine easily to do
a (possibly synthetic?) retry-on-error, or is that likely to involve some
higher-level Firefox logic or side channel?
Currently the SOCKS state machine works this way, as far as I know. During
the handshake stage, if anything arrives at the socket, a function catches
it during polling and calls the handshake function. The handshake function
tries to proceed to the next step of the handshake based on what arrived
at the socket and what its current step is. If it succeeds, it will keep
trying to go to the next step further until it can't, in which case it
informs the polling function to call it again once anything else arrives
at the socket. At some step the handshake is finished.
So there is a sort of retry-on-error in there, the handshake function will
keep trying until the handshake function itself declares that the
handshake is finished (either a complete success or a complete failure).
There are only a few conditions which trigger a complete failure, like a
bad SOCKS version number or an unreadable destination address. So, what
the handshake function understands as a complete failure can indeed be
tampered with. What are we considering?
I have done some straightforward measurements. I measured the time taken
between the SOCKS request and the HTTP 200 OK reply for a given site.
After ten measurements Tor with optimistic data had an average time of
0.56 seconds with a standard deviation of 0.14 seconds, whereas Tor
without optimistic data had an average time of 0.80 seconds with a
standard deviation of 0.11 seconds.
If I measure the time between the GET request and the HTTP 200 OK reply
for the same site, the average would be 0.56 seconds with a standard
deviation of 0.09 seconds for Tor without optimistic data, and the same
measurement would be unchanged for Tor with optimistic data (logically).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3875#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs