Cloudflare թե Google DNS․ արագ պատասխանը միշտ չէ, որ արագացնում է կայքը

Հայաստանում Cloudflare DNS-ի և Google Public DNS-ի միջև բոլոր կապերի համար արագության մեկ հաղթող չկա։ Cloudflare-ը կարող է ավելի շուտ վերադարձնել կայքի հասցեն, բայց Google-ով նույն կայքը երբեմն կարող է ավելի արագ բացվել, եթե բովանդակության մատակարարման ցանցը նրա միջոցով ավելի հարմար հանգույց ընտրի։ Ընտրությունը կախված է օգտագործվող ցանցից, կայքերից և գաղտնիության նախապատվությունից։

Համեմատության համար պետք է առանձնացնել DNS պատասխանի ժամանակը կայքի բեռնման ժամանակից։ DNS-ը տալիս է հասցեն, որից հետո սարքը միանում է սերվերին և ստանում էջի բովանդակությունը։ Եթե արագ պատասխանի դիմաց ընտրված սերվերին հասնելն ավելի երկար է տևում, DNS-ում շահած ժամանակը կարող է չերևալ էջի բացման մեջ։

Ինչ տվյալներ են պահում երկու լուծիչները

Cloudflare-ի 1.1.1.1-ի գաղտնիության պայմաններով՝ հարցում կատարողի ամբողջական IP հասցեն չի պահվում սովորական DNS գրառումների մշտական կրիչում, իսկ կրճատված հասցեն և այդ գրառումները ջնջվում են 25 ժամվա ընթացքում։ Պայմանները նախատեսում են բացառություն ցանցային խնդիրների ու ծառայության դեմ հարձակումների քննության համար պատահականորեն ընտրված փաթեթների դեպքում։ Անանունացված հարցումների որոշ տվյալներ հասանելի են նաև APNIC Labs-ին, իսկ ամփոփ վիճակագրությունը կարող է պահպանվել ավելի երկար։

Google-ի Public DNS գաղտնիության նկարագրությամբ՝ ժամանակավոր գրառումները պարունակում են և՛ հարցումը, և՛ սարքի ամբողջական IP հասցեն ու սովորաբար ջնջվում են 24–48 ժամում։ Անվտանգության և չարաշահման դեպքերի քննության համար դրանք կարող են պահպանվել ավելի երկար։ Մշտական գրառումներում ամբողջական IP հասցեն փոխարինվում է քաղաքի կամ տարածաշրջանի մակարդակի տեղադրությամբ, բայց հարցված տիրույթը, հարցման տեսակը և այլ տեխնիկական տվյալներ մնում են։

Երկու ծառայությունն էլ հայտարարում են, որ Public DNS-ից ստացված անձնական տվյալները չեն օգտագործում գովազդի թիրախավորման համար։ Տարբերությունն ավելի տեսանելի է գրառումների կառուցվածքում. Cloudflare-ի սովորական գրառումներում ամբողջական IP հասցեն չպահելու պարտավորությունը տարբերվում է Google-ի ժամանակավոր գրառումներից, որտեղ այդ հասցեն առկա է։ Ուստի գաղտնիությունը գնահատելիս պետք է հաշվի առնել նաև պահպանման բացառություններն ու ամփոփ տվյալների հետագա օգտագործումը։

DoH և DoT. գաղտնագրվում է կապը լուծիչի հետ

Cloudflare-ի գաղտնագրման նկարագրությունը նշում է, որ 1.1.1.1-ն աջակցում է և՛ HTTPS-ով փոխանցվող DNS-ին՝ DoH-ին, և՛ առանձին TLS կապ օգտագործող DoT-ին։ Երկուսն էլ պաշտպանում են սարքից դեպի լուծիչ ուղարկվող հարցումը այդ ճանապարհի վրա դիտումից։ Լուծիչը, սակայն, շարունակում է ստանալ հարցումը, որպեսզի կարողանա պատասխանել դրան։

Google-ի Public DNS տեխնիկական հարցուպատասխանը հաստատում է 8.8.8.8-ի համար DoH և DoT աջակցությունը և նկարագրում EDNS Client Subnet-ի կիրառումը։ Վերջին մեխանիզմը որոշ հարցումների դեպքում հեղինակավոր DNS սերվերին փոխանցում է հաճախորդի IP հասցեի մասնակի նախածանցը, որպեսզի պատասխանը կարողանա հաշվի առնել նրա ցանցի տեղադրությունը։ Դա կարող է օգնել բովանդակության հանգույցի ընտրությանը, բայց նաև այդ ցանցի մասին լրացուցիչ տեղեկություն է փոխանցում պատասխանող կողմին։

Միայն DNS հասցեն սարքի կարգավորումներում փոխելը DoH կամ DoT ինքնաբերաբար չի միացնում։ Գաղտնագրումն ու ընտրված լուծիչը պետք է ստուգել հենց այն համակարգում կամ բրաուզերում, որով կայքեր եք բացում։ Եթե բրաուզերն ունի առանձին անվտանգ DNS կարգավորում, համակարգային հասցեի փոփոխությունը կարող է չփոխել բրաուզերի ուղարկած հարցումների ճանապարհը։ Հանրային Wi-Fi-ում առանձին կարգավորումը կարող է նաև ազդել մուտքի էջի, իսկ աշխատանքային ցանցում՝ ներքին հասցեների աշխատանքի վրա։

Ինչու DNS-ի ցածր ուշացումը չի որոշում կայքի արագությունը

2022 թվականին RIPE Atlas-ի 1717 չափման հանգույցներով կատարված DNS-ի և CDN-ի փոխազդեցության հետազոտությունը ցույց է տվել, որ Cloudflare-ը Google-ից արագ էր DNS պատասխանի մասով, մինչդեռ Google-ի միջոցով ստացված CDN հանգույցների ուշացումը մոտ էր ինտերնետ մատակարարների լուծիչների արդյունքին, իսկ Cloudflare-ի դեպքում Akamai-ի որոշ բովանդակության համար նկատվել էր հանգույցի ընտրության տույժ։ Հետազոտության հրապարակումը ավելի ուշ է, քան չափումները. դրա արդյունքները Հայաստանի որևէ օպերատորի ընթացիկ արագության վարկանիշ չեն։

CDN-ը նույն բովանդակությունը կարող է մատուցել տարբեր եզրային հանգույցներից։ Տիրույթի համար ստացված հասցեն ազդում է այն բանի վրա, թե սարքը որ հանգույցին կմիանա, իսկ կապի ուշացումն ու բովանդակության փոխանցումը տեղի են ունենում DNS պատասխանից հետո։ Հետազոտողների դիտարկմամբ՝ Google-ի կիրառած մասնակի ցանցային տեղեկությունը Akamai-ի դեպքում հավանական բացատրություններից մեկն էր ավելի հարմար հանգույցի ընտրության համար։ Այդ մեխանիզմի օգուտը կախված է նաև կոնկրետ CDN-ի աշխատանքից։

Չափված «հանգույցի ուշացումն» ու ամբողջ էջի բեռնումը նույնպես նույն ցուցանիշը չեն։ Էջը կարող է առանձին տիրույթներից ստանալ պատկերներ, տեսանյութեր, տառատեսակներ և ծրագրային ֆայլեր, որոնց համար կարող են գործել տարբեր DNS պատասխաններ ու տարբեր CDN-ներ։ Բացի այդ, բրաուզերի քեշը կամ արդեն բաց կապը երբեմն ընդհանրապես շրջանցում են նոր DNS հարցման անհրաժեշտությունը։ Ահա թե ինչու մեկ տիրույթի պատասխանի ժամանակը բավարար չէ ընտրության համար։

Կրկնելի չափում Հայաստանի երեք կապով

Տան ֆիքսված կապը, բջջային տվյալները և հանրային Wi-Fi-ը չափեք առանձին։ Դրանք կարող են տարբեր ճանապարհներով հասնել թե՛ DNS լուծիչին, թե՛ կայքի բովանդակությանը։ Օգտագործեք նույն սարքը, նույն բրաուզերը և ամեն օր այցելվող կայքերի նույն ցանկը։ Եթե համեմատում եք տարբեր բջջային օպերատորներ, նրանց արդյունքները նույնպես մի միավորեք մեկ շարքում։

1. Յուրաքանչյուր փորձի համար գրանցեք կապի տեսակը, օպերատորը կամ Wi-Fi ցանցը, ժամը, VPN-ի վիճակը, ընտրված լուծիչը և DoH կամ DoT կարգավորումը։ Կայքերի ցանկում պահեք և՛ պարզ էջ, և՛ բազմաթիվ արտաքին ֆայլեր բեռնող էջ։ Այս գրառումները թույլ են տալիս հետագայում տարբերել կապի փոփոխությունը լուծիչի փոփոխությունից։
2. Նույն տիրույթների համար հերթով չափեք Cloudflare-ի 1.1.1.1-ի, Google-ի 8.8.8.8-ի և ցանցի լռելյայն լուծիչի DNS պատասխանը։ Օրինակ՝ dig գործիքով կարելի է ուղղակի հարցում ուղարկել յուրաքանչյուր հասցեին և գրանցել պատասխանի ժամանակը։ Կրկնեք հարցումները, բայց առաջին պատասխանը պահեք առանձին. հետագա հարցումները կարող են սպասարկվել քեշից։ Սովորական DNS հարցման չափումը մի անվանեք DoH-ի կամ DoT-ի արդյունք, եթե գործիքն այդ կապուղին չի օգտագործել։
3. Այնուհետև ընտրված լուծիչը հերթով միացրեք իրական օգտագործվող սարքում կամ բրաուզերում և համոզվեք, որ հարցումներն իսկապես գնում են այնտեղ։ Միևնույն պայմաններում մի քանի անգամ բացեք նույն էջերը՝ բոլոր փորձերում կիրառելով քեշի մաքրման նույն կանոնը։ Բրաուզերի ցանցային չափումներում գրանցեք DNS փուլը, սերվերից առաջին պատասխանի և ամբողջ բեռնման ժամանակները, ինչպես նաև ստացված հասցեները։

Արդյունքները համեմատեք յուրաքանչյուր կապի ներսում։ Դիտեք տիպական ժամանակը և տատանումները, որովհետև մեկ արագ փորձը կարող է պատահական լինել։ Եթե DNS պատասխանների տարբերությունը կայքի բացման մեջ չի կրկնվում, լուծիչը փոխելու արագության օգուտը փոքր է այդ կայքերի համար։ Եթե էջի բեռնումը հետևողականորեն փոխվում է, վերադարձված հասցեներն ու միացման ժամանակները կարող են ցույց տալ՝ տարբերությունը հասցե գտնելո՞ւ, թե՞ բովանդակության հանգույցին հասնելու փուլում է։

Որ ընտրությունն է համապատասխանում ձեր առաջնահերթությանը

Եթե էջերի արագությունը ձեր կապում գրեթե նույնն է, իսկ առաջնահերթությունը ամբողջական IP հասցեի սովորական DNS գրառումներում պահպանումը սահմանափակելն է, Cloudflare-ի պայմանները կարող են ավելի հարմար լինել։ Եթե հաճախ բացվող կայքերը Google-ով հետևողականորեն արագ են բեռնվում, այդ գործնական արդյունքը կարող է որոշիչ դառնալ՝ ընդունելով նրա ժամանակավոր գրառումների պայմանները։ Համեմատության մեջ արժե պահել նաև օպերատորի լռելյայն DNS-ը. նույն տեղային ցանցում այն ևս կարող է լավ արդյունք տալ։ Օպերատորի, կապի տեսակի կամ կարևոր կայքերի փոփոխության դեպքում ընտրությունը նորից չափելը հիմնավոր է։

Կարդացեք նաև:

• ChatGPT Plus, Claude Pro, Google AI Pro․ ո՞ր $20 փաթեթն է շահավետ