- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 8 Jul 2014 22:49:09 -0700
- To: Erik Nygren <erik@nygren.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYgJrf6vSEgNXSke4gw1stnkcEHXu-GmXEvK-sEDY9CGVA@mail.gmail.com>
On Tue, Jul 8, 2014 at 7:19 PM, Erik Nygren <erik@nygren.org> wrote: > On Tue, Jul 8, 2014 at 9:49 PM, William Chan (陈智昌) <willchan@chromium.org> > wrote: > >> Fair enough. I'll read it more thoroughly tomorrow. Note that the happy >> eyeballs for ipv6 is different, because origins have to opt into serving >> AAAA responses. They get to make that latency tradeoff decision themselves, >> rather than Chrome version X launching and being slower for all websites. >> > > > I'm not sure how I see the difference between this vs AAAA responses with > happy eyeballs? In both cases for websites that don't have the records you > have to issue both queries and wait at least some time for an authoritative > and cacheable NXDOMAIN or NOERROR back. And in both cases you start off > with fairly few names actually having the record, with that shifting over > time as adoption grows. > OIC, there is confusing terminology going on. When I refer to happy eyeballs in Chromium, I refer to the implementation I wrote: http://src.chromium.org/viewvc/chrome?revision=85934&view=revision. This adds a backup connect() for the IPv4 address after waiting a period of time for the IPv6 connect() to complete. Therefore, this happy eyeballs delay is only incurred when there is an IPv6 address. As for simply issuing the A and AAAA queries, it indeed has a huge impact on our performance. Mike's written about this before: http://www.belshe.com/2011/06/15/ipv6-dns-lookup-times/. In short, it's terrible, but we'd have to subvert the OS settings and explicitly disable IPv6 within Chromium if we didn't want to pay this performance hit. And choosing not to support IPv6 is...a big deal. Anyway, I'll read the proposal in detail tomorrow. Cheers. > > Erik > > >
Received on Wednesday, 9 July 2014 05:49:36 UTC