Շատ առաջադրանքների համար հաճախորդի և սերվերի միջև ուշացումները կարևոր են, օրինակ՝ առցանց խաղերում, վիդեո/ձայնային կոնֆերանսներում, IP հեռախոսակապում, VPN-ում և այլն: Եթե սերվերը IP ցանցի մակարդակով շատ հեռու է հաճախորդից, ապա ուշացումները (սովորաբար կոչվում են «ping», «lag») կխանգարեն աշխատանքին:
Սերվերի աշխարհագրական մոտիկությունը միշտ չէ, որ հավասարազոր է IP երթուղային մակարդակում: Այսպիսով, օրինակ, մեկ այլ երկրի սերվերը կարող է ձեզ «ավելի մոտ» լինել, քան ձեր քաղաքի սերվերը: Այս ամենը պայմանավորված է երթուղային և ցանցի կառուցման առանձնահատկություններով:
Ինչպե՞ս ընտրել սերվեր, որը հնարավորինս մոտ է բոլոր պոտենցիալ հաճախորդներին: Ի՞նչ է IP ցանցի միացումը: Ինչպե՞ս հաճախորդին ուղղորդել մոտակա սերվերին: Եկեք պարզենք հոդվածում:
Հետաձգումների չափում
Նախ, եկեք սովորենք, թե ինչպես չափել ուշացումները: Այս առաջադրանքն այնքան էլ պարզ չէ, որքան կարող է թվալ, քանի որ ուշացումները կարող են տարբեր լինել տարբեր արձանագրությունների և փաթեթների չափերի համար: Դուք կարող եք նաև բաց թողնել կարճաժամկետ իրադարձություններ, ինչպիսիք են մի քանի միլիվայրկյան տեւողությամբ անկումները:
ICMP - սովորական պինգ
Մենք կօգտագործենք Unix ping կոմունալ ծրագիրը, որը թույլ է տալիս ձեռքով սահմանել փաթեթների ուղարկման միջակայքերը, ինչը Windows-ի համար ping տարբերակը չի կարող անել: Սա կարևոր է, քանի որ եթե փաթեթների միջև երկար դադարներ կան, դուք կարող եք պարզապես չտեսնել, թե ինչ է կատարվում նրանց միջև:
Փաթեթի չափը (տարբերակ -s) - լռելյայնորեն, ping կոմունալն ուղարկում է 64 բայթ չափի փաթեթներ: Նման փոքր փաթեթների դեպքում ավելի մեծ փաթեթների հետ տեղի ունեցող երևույթները կարող են նկատելի չլինել, ուստի մենք փաթեթի չափը կսահմանենք 1300 բայթ:
Փաթեթների միջև ընդմիջում (տարբերակ -i) - տվյալների ուղարկման միջև ընկած ժամանակահատվածը: Լռելյայնորեն, փաթեթներն ուղարկվում են վայրկյանում մեկ անգամ, սա շատ երկար է, իրական ծրագրերը վայրկյանում հարյուրավոր և հազարավոր փաթեթներ են ուղարկում, ուստի մենք միջակայքը կսահմանենք 0.1 վայրկյան: Ծրագիրը պարզապես թույլ չի տալիս պակաս:
Արդյունքում հրամանն այսպիսի տեսք ունի.
ping -s 1300 -i 0.1 yandex.ru
Այս դիզայնը թույլ է տալիս տեսնել ուշացումների ավելի իրատեսական պատկերը:
Ping-ը UDP-ի և TCP-ի միջոցով
Որոշ դեպքերում, TCP կապերը մշակվում են տարբեր կերպ, քան ICMP փաթեթները, և դրա պատճառով չափումները կարող են տարբեր լինել՝ կախված արձանագրությունից: Հաճախ է պատահում նաև, որ հաղորդավարը պարզապես չի արձագանքում ICMP-ին, և սովորական ping-ը չի աշխատում։ Ահա թե ինչ է անում հաղորդավարն իր ամբողջ կյանքում, օրինակ. microsoft.com.
Օգտակար հայտնի սկաների մշակողներից nmap կարող է առաջացնել ցանկացած փաթեթ: Այն կարող է օգտագործվել նաև ուշացումները չափելու համար:
Քանի որ UDP-ն և TCP-ն աշխատում են կոնկրետների վրա, մենք պետք է «պինգ» անենք որոշակի նավահանգիստ: Փորձենք ping կատարել TCP 80, այսինքն՝ վեբ սերվերի պորտը.
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
Լռելյայնորեն, nping-ը ուղարկում է 4 փաթեթ և կանգ է առնում: Տարբերակ -գ 0 հնարավորություն է տալիս անվերջ ուղարկել փաթեթներ, ծրագիրը դադարեցնելու համար անհրաժեշտ է սեղմել Ctrl+C: Վիճակագրությունը կցուցադրվի վերջում։ Մենք տեսնում ենք, որ միջին rtt (երկկողմանի ժամանակ) արժեքը 101ms է:
MTR - ստերոիդների վրա տրակերուտ
Ծրագիր My Traceroute-ը առաջադեմ կոմունալ ծրագիր է՝ դեպի հեռավոր հյուրընկալող երթուղիները հետագծելու համար: Ի տարբերություն սովորական համակարգի օգտակար traceroute-ի (Windows-ում սա tracert utility-ն է), այն կարող է ուշացումներ ցույց տալ փաթեթների շղթայի յուրաքանչյուր հոսթին: Այն կարող է նաև հետևել երթուղիներին ոչ միայն ICMP-ի, այլև UDP-ի և TCP-ի միջոցով:
$ sudo mtr microsoft.com
(Սեղմելի) MTR ծրագրի միջերես: Սկսվել է դեպի microsoft.com երթուղու հետագծումը
MTR-ն անմիջապես ցույց է տալիս պինգը շղթայի յուրաքանչյուր հոսթին, և տվյալներն անընդհատ թարմացվում են ծրագրի գործարկման ընթացքում, և կարելի է տեսնել կարճաժամկետ փոփոխություններ:
Սքրինշոթը ցույց է տալիս, որ թիվ 6 հանգույցն ունի փաթեթների կորուստներ, բայց իրականում դա լիովին ճիշտ չէ, քանի որ որոշ երթուղիչներ կարող են պարզապես հրաժարվել ժամկետանց TTL-ով փաթեթներից և սխալի պատասխան չտալ, ուստի փաթեթի կորստի տվյալները կարող են անտեսվել այստեղ:
WiFi ընդդեմ մալուխի
Այս թեման ամբողջությամբ չի վերաբերում հոդվածին, բայց իմ կարծիքով շատ կարևոր է ուշացումների համատեքստում։ Ես իսկապես սիրում եմ WiFi-ը, բայց եթե մալուխով ինտերնետին միանալու ամենաչնչին հնարավորություն էլ ունենամ, կօգտվեմ դրանից։ Ես նաև միշտ խանգարում եմ մարդկանց օգտվել WiFi տեսախցիկներից:
Եթե դուք խաղում եք լուրջ առցանց հրաձիգներ, հեռարձակում եք տեսանյութեր կամ առևտուր եք անում բորսայում, խնդրում ենք օգտագործել ինտերնետը մալուխի միջոցով:
Ահա տեսողական թեստ՝ WiFi-ի և մալուխային կապերը համեմատելու համար: Սա WiFi երթուղիչի պինգ է, այսինքն, նույնիսկ ինտերնետը դեռևս չէ:
(Սեղմել) WiFi երթուղիչին մալուխի և WiFi-ի միջոցով ping-ի համեմատություն
Երևում է, որ WiFi-ի միջոցով ուշացումը 1մս-ով ավելի է, և երբեմն լինում են տասնապատիկ ավելի ուշացումներով փաթեթներ: Եվ սա ընդամենը կարճ ժամանակահատված է։ Միևնույն ժամանակ, նույն երթուղիչը ստեղծում է <1 ms-ի կայուն ուշացումներ:
Վերոնշյալ օրինակում օգտագործվում է WiFi 802.11n 2.4 ԳՀց հաճախականությամբ, WiFi մուտքի կետին միացված են միայն նոութբուքը և հեռախոսը: Եթե մուտքի կետում ավելի շատ հաճախորդներ լինեին, արդյունքները շատ ավելի վատ կլինեին: Ահա թե ինչու ես դեմ եմ բոլոր գրասենյակային համակարգիչները WiFi-ի անցնելուն, եթե հնարավոր է դրանց հասնել մալուխով:
IP միացում
Այսպիսով, մենք սովորել ենք չափել սերվերի հետաձգումները, եկեք փորձենք գտնել մեզ ամենամոտ սերվերը: Դա անելու համար մենք կարող ենք տեսնել, թե ինչպես է աշխատում մեր մատակարարի երթուղին: Դրա համար հարմար է օգտվել ծառայությունից
Երբ մենք մուտք ենք գործում կայք, տեսնում ենք, որ մեր IP հասցեն պատկանում է ինքնավար համակարգին .
Դիտելով ինքնավար համակարգերի միացման գրաֆիկը՝ մենք կարող ենք տեսնել, թե որ բարձր մակարդակի մատակարարների միջոցով է մեր մատակարարը միացված մնացած աշխարհին: Կետերից յուրաքանչյուրը սեղմելի է, կարող եք մտնել և կարդալ, թե ինչ մատակարար է:
Մատակարարի ինքնավար համակարգերի միացման գրաֆիկը
Օգտագործելով այս գործիքը, դուք կարող եք ուսումնասիրել, թե ինչպես են կառուցված ցանկացած մատակարարի ալիքները, ներառյալ հոսթինգը: Տեսեք, թե որ պրովայդերների հետ է այն ուղղակիորեն կապված: Դա անելու համար դուք պետք է մուտքագրեք սերվերի IP հասցեն bgp.he.net որոնման մեջ և դիտեք դրա ինքնավար համակարգի գրաֆիկը: Կարող եք նաև հասկանալ, թե ինչպես է տվյալների կենտրոնը կամ հոսթինգի մատակարարը միացված մյուսին:
Երթևեկության փոխանակման կետերից շատերը ապահովում են հատուկ գործիք, որը կոչվում է նայող ապակի, որը թույլ է տալիս փոխանակման կետում հատուկ երթուղիչից ping և հետագծել:
Այստեղ, օրինակ, MGTS-ից
Այսպիսով, սերվեր ընտրելիս մենք կարող ենք նախապես տեսնել, թե ինչպես այն կանդրադառնա թրաֆիկի փոխանակման տարբեր կետերից։ Եվ եթե մեր պոտենցիալ հաճախորդները գտնվում են որոշակի աշխարհագրական տարածքում, մենք կարող ենք գտնել օպտիմալ տեղադրությունը սերվերի համար:
Ընտրեք մոտակա սերվերը
Մենք որոշեցինք պարզեցնել մեր հաճախորդների համար օպտիմալ սերվեր գտնելու ընթացակարգը և ստեղծեցինք էջ մոտակա վայրերի ավտոմատ փորձարկումով. .
Երբ այցելում եք էջ, սկրիպտը չափում է ձեր բրաուզերից յուրաքանչյուր սերվերի հետաձգումները և ցուցադրում դրանք ինտերակտիվ քարտեզի վրա: Երբ սեղմում եք տվյալների կենտրոնի վրա, ցուցադրվում են թեստի արդյունքներով տեղեկատվությունը:
Կոճակը ձեզ տանում է դեպի մեր տվյալների բոլոր կենտրոնների հետաձգման փորձարկման էջ: Թեստի արդյունքները դիտելու համար կտտացրեք քարտեզի տվյալների կենտրոնի կետին
Source: www.habr.com