Pagpili sa labing duol nga mga node sa network

Ang latency sa network adunay dakong epekto sa performance sa mga aplikasyon o serbisyo nga nakig-interact sa network. Kon mas ubos ang latency, mas taas ang performance. Tinuod kini alang sa bisan unsang serbisyo sa network, gikan sa usa ka regular nga website hangtod sa usa ka database o pagtipig sa network.

Usa ka maayong pananglitan mao ang Domain Name System (DNS). Ang DNS sa kinaiyanhon usa ka distributed system, nga adunay mga root node nga nagkatag sa tibuok planeta. Sa yano nga pag-access sa bisan unsang website, kinahanglan nimo una nga makuha ang IP address niini.

Dili nako ihulagway ang tibuok proseso sa recursively nga pag-agi sa "kahoy" sa mga domain zone, apan limitahan ang akong kaugalingon sa kamatuoran nga aron ma-convert ang usa ka domain ngadto sa IP address, nagkinahanglan kami og DNS resolver nga mobuhat sa tanan niini nga trabaho alang sa kanato.

Busa, asa nimo makuha ang address sa DNS resolver?

1. Ang ISP naghatag sa adres sa DNS resolver niini.
2. Pangitaa ang adres sa usa ka public resolver sa Internet.
3. Kuhaa ang imong kaugalingon o gamita ang usa nga gitukod sa imong router sa balay.

Bisan unsa niini nga mga kapilian magtugot kanimo nga malingaw sa walay kabalaka nga pag-surf sa World Wide Web, apan kung kinahanglan nimo nga i-convert ang daghang mga domain sa IP, nan kinahanglan nimo nga duolon ang pagpili sa usa ka solver nga labi ka mabinantayon.

Sama sa nasulat na nako, dugang sa ISP resolver, adunay daghang mga adres sa publiko, pananglitan, mahimo nimong susihon kini nga lista. Ang uban kanila mahimong mas gusto tungod kay sila adunay mas maayo nga koneksyon sa network kaysa sa default nga solusyon.

Kung gamay ra ang lista, dali nimo nga "i-ping" kini nga mano-mano ug itandi ang mga oras sa paglangan, apan kung gikuha nimo ang lista nga gihisgutan sa ibabaw, nan kini nga buluhaton mahimong dili maayo.

Busa, aron mas sayon ​​​​kini nga buluhaton, ako, nga napuno sa impostor syndrome, nag-sketch sa usa ka pamatuod-sa-konsepto sa akong ideya sa Go nga gitawag mas duol.

Ingon usa ka pananglitan, dili nako susihon ang tibuuk nga lista sa mga solver, apan limitahan ang akong kaugalingon sa labing inila lamang.

$ get-closer ping -f dnsresolver.txt -b=0 --count=10
Closest hosts:
	1.0.0.1 [3.4582ms]
	8.8.8.8 [6.7545ms]
	1.1.1.1 [12.6773ms]
	8.8.4.4 [16.6361ms]
	9.9.9.9 [40.0525ms]

Sa usa ka higayon, sa dihang nagpili ko og solver alang sa akong kaugalingon, gilimitahan nako ang akong kaugalingon sa pagsusi lamang sa mga nag-unang adres (1.1.1.1, 8.8.8.8, 9.9.9.9) - bisan pa, kini matahum kaayo, ug unsa ang imong mapaabut gikan sa ngil-ad nga backup nga mga adres.

Apan tungod kay adunay usa ka awtomatiko nga paagi sa pagtandi sa mga paglangan, nganong dili palapdan ang listahan...

Ingon sa gipakita sa pagsulay, ang "backup" nga Cloudflare nga adres mas angay alang kanako, tungod kay kini gisaksak sa spb-ix, nga mas duol kanako kay sa msk-ix, nga adunay nindot nga 1.1.1.1 nga gibutang niini.

Ang kalainan, ingon sa imong makita, mahinungdanon, tungod kay bisan ang pinakapaspas nga silaw sa kahayag dili makaabot gikan sa St. Petersburg ngadto sa Moscow sa ubos sa 10 ms.

Gawas pa sa yano nga ping, ang PoC usab adunay higayon nga itandi ang mga paglangan alang sa ubang mga protocol, sama sa http ug tcp, ingon man ang oras sa pag-convert sa mga domain sa IP pinaagi sa usa ka piho nga solver.

Adunay mga plano nga itandi ang gidaghanon sa mga node tali sa mga host gamit ang traceroute aron mas sayon ​​​​ang pagpangita sa mga host nga adunay mas mubo nga agianan ngadto kanila.

Ang code krudo, kini kulang sa usa ka hugpong sa mga tseke, apan kini maayo kaayo sa limpyo nga datos. Pabilhan nako ang bisan unsang feedback, mga bituon sa github, ug kung adunay nakagusto sa ideya sa proyekto, unya welcome nga mahimong usa ka kontribyutor.

Source: www.habr.com