Closed
Bug 695789
Opened 13 years ago
Closed 10 years ago
Attempt to maximize session resumption by waiting for a full handshake to complete instead of doing multiple full handshakes in parallel
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: briansmith, Unassigned)
Details
(Keywords: perf)
+++ This bug was initially created as a clone of Bug #674147 +++ (In reply to Honza Bambas (:mayhemer) from Bug 674147 comment 9) > A side note: if we do parallel connections to a host:port we don't have a > cached ssl session for, we should probably do the handshake just by one of > the sockets and all other let wait until the full handshake is done. Those > waiting sockets should then use the just created cached session. This way > we could save load on our side as well as on the server side. > > I'm not sure, but the current ssl thread implementation may enforce this > behavior. > > I don't have a knowledge whether NSS does this somehow internally. (In reply to Wan-Teh Chang from Bug 674147 comment 10) > Honza: Yes, that's a good idea. I believe NSS doesn't do that > internally. > > Note: this optimization is difficult when SSL False Start is > enabled. With SSL False Start, the SSL handshake completion > callback is called before the handshake is truly completed > and the session ID written to the session ID cache. I think it doesn't have to be complicated because it doesn't have to be perfect. We may be able to use logic like this: "Are we (probably) currently doing a full handshake for this host? If so, wait up to XXX ms before starting the handshake for this connection." It would be racy, so sometimes it would result in more full handshakes happening, but it may be good enough.
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → bsmith
Reporter | ||
Updated•10 years ago
|
Assignee: brian → nobody
Reporter | ||
Comment 1•10 years ago
|
||
I read recently that Google Chrome experimented with implementing this and decided not to do it. Also, if you look at the "SSL handshake type" telemetry, Firefox is already doing 1 RTT handshakes--either False Start or resumption--a huge percentage of the time. (Getting rid of OCSP fetching would be the most likely thing to increase that rate further.) Finally, HTTP/2 connection handling (1 connection per server) makes this even less necessary. So, people shouldn't waste their time on this.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•