Název „happy eyeballs“ – tedy „šťastné bulvy“ – je sympaticky nekorektní a zároveň naznačuje, že hlavní důraz je kladen na uživatelskou spokojenost, a to i za cenu o něco vyšší zátěže přenosové sítě a koncových systémů. Hned druhou prioritou však je udržet přidanou zátěž v rozumných mezích.
Výchozí situací, pro niž je metodika vytvářena, je víceprotokolová síť. Pokud obě strany komunikace podporují IPv4 i IPv6 (dual-stack), mohou si vybrat, jakým protokolem si budou předávat data. Standardní procedura je dnes taková, že operační systém má nastaveny priority ohledně používaných protokolů a adres. Když aplikace požádá DNS o nalezení IP adres k zadanému jménu, dostane je seřazeny podle systémové politiky a v tomto pořadí se obvykle snaží navázat spojení.
Problém nastane, pokud pro první adresu neuspěje. Typická situace: správce zprovoznil službu po IPv6, přidal proto do DNS ke jménu příslušného serveru i IPv6 adresu, ale zapomněl ji povolit ve firewallu chránícím síť. Lokálně bude vše fungovat, ale jakmile se někdo zvenčí pokusí se serverem spojit, po IPv6 to nepůjde. Jenže IPv6 adresa je v DNS a politika většiny současných operačních systémů je taková, že pokud je stroj připojen oběma verzemi IP a DNS vrátí IPv4 i IPv6 adresy, dá přednost IPv6. To ovšem v daném případě nefunguje a bude trvat desítky vteřin, než aplikace zanechá neúspěšného snažení o navázání IPv6 komunikace a zkusí IPv4. Odkazy na podrobnější rozbor situace najdete v našem předchozím článku a úplně čerstvě se této problematice věnoval Geoff Huston na právě probíhajícím RIPE meetingu.
Doporučení happy eyeballs popsané v RFC 6555 ve stručnosti říká, že je záhodno nevsázet na jednu kartu a rychle vyzkoušet i alternativu. Dokument neobsahuje konkrétní algoritmus, ten ponechává na autorech aplikací a očekává, že vznikne celá řada různých přístupů. Text se proto omezuje na obecná doporučení, která by algoritmy měly splňovat. Typický algoritmus by podle happy eyeballs měl pracovat zhruba takto:
- Standardním způsobem seřadí dostupné adresy cíle podle systémových priorit.
- Zkusí navázat spojení s první adresou. Pokud uspěje, není co řešit.
- Jestliže se poměrně rychle nedostaví úspěch, pokusí se navázat spojení na adresu cíle pro jiný protokol. Použil-li pro první pokus IPv6 adresu a neuspěl, ve druhém pokusu vybere některou z IPv4 adres cíle (a naopak).
- Dokud neuspěje, bude postupně zkoušet další a další adresy. Jejich pořadí už autoři nechávají na volbě autorů algoritmu – podstatné je, aby se v prvních dvou pokusech vyzkoušely oba protokoly.
Mezi jednotlivými pokusy mají být poměrně krátké přestávky, doporučený odstup činí 150–250 ms. To je na jedné straně dostatek času k navázání spojení, pokud protokol funguje, a na druhé straně se v případě neúspěchu zkoušejí alternativy dostatečně rychle na to, aby uživatel netrpěl. Samozřejmě se může stát, že aplikace bude příliš nedočkavá a odpověď z druhé strany dorazí až po zahájení dalšího pokusu. Vzniknou-li takto dvě navázaná spojení, aplikace si jedno vybere a druhé ukončí.
Specifikace zároveň požaduje, aby se informace o výsledcích navazování spojení ukládaly do dočasné paměti a při opakované komunikaci se stejným cílem využívaly. Příště proto systém nejprve vyzkouší úspěšnou variantu z minula a nebude zbytečně opakovat slepé uličky. Životnost těchto informací by ale neměla přesáhnout 10 minut.
RFC 6555 se zabývá i otázkou, kde algoritmus implementovat. Popisuje chování aplikací, jako první a nejjednodušší prostředí pro něj se proto nabízejí aplikace (a některé už jej obsahují, například Chrome či Firefox). Nevýhodou je, že se pak různé aplikace budou chovat odlišně, což rozhodně neusnadní hledání problémů. Zajímavá je proto varianta vytvoření API, kdy by byl algoritmus happy eyeballs buď zabudován do standardního aplikačního rozhraní transportní vrstvy, nebo by byla k dispozici jeho takto rozšířená varianta. Výsledkem by bylo konzistentnější chování aplikací v rámci operačního systému.
Řada otázek zůstává zatím nezodpovězených. Doporučení se například explicitně věnuje jen spojovanému protokolu TCP. Nespojované UDP podrobněji nediskutuje, mělo by se řešit „podobně“. Nezabývá se také situací, kdy stroj má k dispozici několik síťových připojení a bylo by proto záhodno, aby ve svých pokusech kromě protokolů měnil i použitá rozhraní. Do budoucna lze proto očekávat rozšířenou verzi. Ale zřejmě až po získání dostatku zkušeností s praktickým chováním používaných algoritmů.
Doplňkem obecné specifikace je RFC 6556, které popisuje metodu pro testování rychlosti navazování spojení. Obsahuje velmi konkrétní návrh experimentální sítě a metodiku pro měření jednotlivých veličin.
Zbývá už jen to nejdůležitější – implementace. První vlaštovky už sice existují (např. zmiňované prohlížeče), ale nějakou dobu nepochybně potrvá, než bude možné považovat chování podle happy eyeballs za běžné.
