RFC6555 Happy Eyeballs and RFC8305 Happy Eyeballs 2

RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts

RFC3484 gives IPv6 addresses higher precedence than IPv4 addresses. Because of this when IPv6 connectivity is impaired, IPv6-capable applications incur many seconds of delay before falling back to IPv4.
Happy Eyeballs aims to provide a fast connection for users, by quickly attempting to connect using IPv6 and (if that connection attempt is not quickly successful) to connect using IPv4.

f:id:momokamy6:20220413030904p:plain

from RFC6555


RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency

Happy Eyeballs 2 adds the following features on top of RFC6555

Asynchronous DNS queries.

The diagram below shows how the DNS queries are handled asynchronously. Implementations SHOULD NOT wait for both families of answers to return before attempting connection establishment. If one query fails to return or takes significantly longer to return, waiting for the second address family can significantly delay the connection establishment of the first one.
This is a workaround for faulty resolvers that take a long time to return results after AAAA queries are made.

f:id:momokamy6:20220413200942p:plain



Sorting of resolved destination addresses

Whichever address family is first in the list should be followed by an address of the other address family; that is, if the first address in the sorted list is IPv6, then the first IPv4 address should be moved up in the list to be second in the list.

f:id:momokamy6:20220413030757p:plain

 

Asynchronous connection attempts

After "Connection Attempt Delay" has passed after starting a connection attempt for an address, start a new connection attempt to the next address. This shouldn’t affect previous attempts, as multiple connection attempts may occur in parallel.

ネットワーク系で最近調べたこと


WebSocket

WebSocketについて調べてみた。 - Qiita



DNS

DNSRFCの歩き⽅

https://dnsops.jp/event/20120831/DNS-RFC-PRIMER-2.pdf

DNSのRFSの読みかた。RFC読む前にこれ読んだほうがよさそう 1034, 1035 の要約


マルチキャストDNS - Wikipedia

mDNS


「魔法の数字8.8.8.8」を検証する:Geekなぺーじ

Google Public DNS 8.8.8.8 を使ったのときの遅延を検証

ISPDNSキャッシュサーバのかわりにPublic DNSを使うとCDNの良さが殺されるのか。

2011年の記事でGoogle Public DNSCDNの相性を改善する取り組みが紹介されてるから今は違うかも。


domain name system - Is dig +trace always accurate? - Server Fault

digにtraceオプションをつけると,DNSに関する最後の問い合わせ結果だけでなく,途中の様子が見られる. けど、これはキャッシュサーバからいつもより多く情報をもらってるだけで、実際にroot サーバから順に問い合わせをしているわけではない。 これができるオプションがあればいいのに。



CORS

CORS とは? - JavaScript の基本 - JavaScript 入門

CORSとは。

zenn.dev

この記事が圧倒的にわかりやすかった。