Google Chrome izboljšal IPv6 to IPv4 failover mehanizem
Googlovci so verjetno na pobudo Erika Klinea in Lorenza Colittija že maja dodali to funkcionalnost v preview verzijo “Canary”, sedaj pa je izboljšava prišla v zadnjo stabilno verzijo Google Chrome brskalnika. S tem popravkom bodo Chrome uporabniki precej manj občutili možne posledice na Svetovni IPv6 dan…
Za kaj se točno gre? Kot so zapisali na conceivablytech.com, so programerji zmanjšali timeout na povezavah na 300ms, kar pomeni, da če v 300ms ne dobimo odgovora preko IPv6 se hkrati sproži še IPv4 zahtevek in tisti protokol ki prej dostavi podatke postane glavni prenosni vir.
Ta ideja je zapisana v predlogu RFC-ja “Happy eyeballs” avtorjev Dana Winga in Andrewa Yourtchenka (oba Cisco). V Pragi smo se na IETF meetingu vsedli skupaj na BOF sestanek in potegnili nekaj zaključkov, ki so bili kasneje implementirani tako v Safari kot tudi sedaj v Chrome browser.
Zavedati se moramo, da je splet (www) samo eden od servisov oziroma storitev na internetu, kar pomeni da popravki brskalnikov uredijo le majhen del internetnih servisov – ta mehanizem “happy eyeballs” bo treba implementirati kot osnovni način komunikacije TCP/IP skladov v operacijskih sistemih, šele nato bomo lahko rekli, da smo naredili nekaj za Internet in njega lažjo dostopnost.
Kakorkoli, Uporabniki z brskalnikom Chrome in Safari bodo precej manj občutili morebitne težave pri dostopanju do Google.com in Facebook.com ter ostalih udeležencev Svetovnega IPv6 dneva, ki bodo svoje vsebine ponudili preko obeh protokolov hkrati.
Jan Žorž
Vaš IP naslov (ali ste na IPv6 ?):
3.144.172.125
Comments(4)
Hm 300ms.
Meni se to zdi malo malo, vsaj glede na to, da če pingaš kakšen server na drugem koncu sveta kaj hitro prideš do 300 ms pinga. 350ms pinga imam recimo do kame.net pa sem na native dualstacku.
Drug problem vidim tudi pri 3G povezavah – tam so latence vedno dokaj visoke. Torej se bojim, da bo hitro prišlo do nezaželenega fallback-a na IPv4.
Pomojem bi bila bolj smiselna vrednost okoli 500ms.
Razen če tu dejstvo da ima IPv4 zahtevek potem še 300ms zakasnitve kaj dosti vpliva na končni rezultat “tekmovanja” med IPv6 in IPv4?
300ms je prednosti, kar pomeni, da bi moral imeti IPv6 za 300ms slabsi kot IPv4 da bi ta prevladal.
Ce pa IPv6 ne dela je prvi “hit” 300ms + IPv4 RTT, vse ostalo pa gre po IPv4.
Smart, is it?
TCP stacka seveda ne moreš popraviti ker je Socket API polomljen.
http://blog.ioshints.info/2009/08/what-went-wrong-socket-api.html
Lahko bi popravili kakšno knjižnico, teh je pa verjetno malo morje (pa še vsak programer si je napisal svojo).
eh, vse se da… With sufficient thrust, pigs fly just fine. (RFC1925) 😀