За многу задачи, доцнењата помеѓу клиентот и серверот се критични, на пример во онлајн игри, видео/говорни конференции, IP телефонија, VPN итн. Ако серверот е премногу далеку од клиентот на ниво на IP мрежа, тогаш одложувањата (популарно наречени „пинг“, „заостанување“) ќе ја попречат работата.
Географската близина на серверот не е секогаш еднаква на близината на ниво на IP рутирање. Така, на пример, сервер во друга земја може да биде „поблиску“ до вас отколку сервер во вашиот град. Сето тоа се должи на особеностите на рутирањето и изградбата на мрежата.
Како да изберете сервер што е што е можно поблизок до сите потенцијални клиенти? Што е IP мрежно поврзување? Како да го насочите клиентот до најблискиот сервер? Ајде да дознаеме во статијата.
Мерење на одложувања
Прво, да научиме како да ги измериме доцнењата. Оваа задача не е толку едноставна како што може да изгледа бидејќи одложувањата може да варираат за различни протоколи и големини на пакети. Може да пропуштите и краткорочни настани, како што се падови кои траат неколку милисекунди.
ICMP - редовен пинг
Ќе ја користиме алатката за пинг Unix; таа ви овозможува рачно да ги поставите интервалите помеѓу испраќањето пакети, што верзијата за пинг за Windows не може да го направи. Ова е важно затоа што ако има долги паузи помеѓу пакетите, можеби едноставно нема да видите што се случува меѓу нив.
Големина на пакувањето (опција -s) - стандардно, алатката за пинг испраќа пакети со големина од 64 бајти. Со толку мали пакети, феномените што се случуваат кај поголемите пакети може да не бидат забележливи, па затоа ќе ја поставиме големината на пакетот на 1300 бајти.
Интервал помеѓу пакетите (опција -i) — време помеѓу испраќањето податоци. Стандардно, пакетите се испраќаат еднаш во секунда, ова е многу долго, вистинските програми испраќаат стотици и илјадници пакети во секунда, така што ќе го поставиме интервалот на 0.1 секунда. Програмата едноставно не дозволува помалку.
Како резултат на тоа, командата изгледа вака:
ping -s 1300 -i 0.1 yandex.ru
Овој дизајн ви овозможува да видите пореална слика за одложувањата.
Пинг преку UDP и TCP
Во некои случаи, TCP конекциите се обработуваат поинаку од ICMP пакетите, и поради тоа, мерењата може да варираат во зависност од протоколот. Исто така, често се случува домаќинот едноставно да не реагира на ICMP, а редовниот пинг да не работи. Така прави домаќинот цел живот, на пример. microsoft.com.
Алатка од програмерите на познатиот скенер nmap може да генерира какви било пакети. Може да се користи и за мерење на доцнењата.
Бидејќи UDP и TCP работат на специфични, треба да „пингуваме“ одредена порта. Ајде да се обидеме да направиме пинг 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), може да покаже доцнења за секој домаќин во синџирот на пакети. Исто така, може да следи правци не само преку ICMP, туку и преку UDP и TCP.
$ sudo mtr microsoft.com
(со кликнување) MTR програмски интерфејс. Започна следењето на маршрутата до microsoft.com
MTR веднаш го покажува пингот на секој хост во синџирот, а податоците постојано се ажурираат додека програмата работи и може да се видат краткорочни промени.
Сликата од екранот покажува дека јазолот #6 има загуби на пакети, но всушност тоа не е сосема точно, бидејќи некои рутери едноставно можат да ги отфрлат пакетите со истечен TTL и да не враќаат одговор на грешка, така што податоците за загубата на пакетите може да се игнорираат овде.
WiFi наспроти кабел
Оваа тема не е целосно релевантна за статијата, но според мене е многу важна во контекст на доцнење. Навистина сакам WiFi, но ако имам и најмала можност да се поврзам на интернет со кабел, ќе го искористам. Исто така, секогаш ги обесхрабрувам луѓето да користат WiFi камери.
Ако играте сериозни онлајн стрелци, стримувате видео или тргувате на берза: ве молиме користете го Интернетот преку кабел.
Еве визуелен тест за споредба на WiFi и кабелските врски. Ова е пинг до рутерот за WiFi, односно сè уште не дури ни Интернет.
(Може да се кликне) Споредба на пинг до WiFi рутер преку кабел и преку WiFi
Се гледа дека преку WiFi доцнењето е 1ms подолго, а понекогаш има пакети со доцнења десет пати подолго! И ова е само краток временски период. Во исто време, истиот рутер произведува стабилни доцнења од <1ms.
Во горниот пример, се користи WiFi 802.11n на 2.4 GHz, само лаптоп и телефон се поврзани со пристапната точка за WiFi. Ако има повеќе клиенти на пристапната точка, резултатите би биле многу полоши. Ова е причината зошто јас сум толку против префрлување на сите канцелариски компјутери на WiFi ако е можно да се стигне до нив со кабел.
IP конекција
Значи, научивме да ги мериме доцнењата на серверот, ајде да се обидеме да го најдеме најблискиот сервер до нас. За да го направите ова, можеме да погледнеме како функционира рутирањето на нашиот провајдер. Удобно е да се користи услугата за ова
Кога пристапуваме до страницата, гледаме дека нашата IP адреса припаѓа на автономниот систем .
Гледајќи го графиконот за поврзување на автономните системи, можеме да видиме преку кои провајдери на повисоко ниво нашиот провајдер е поврзан со остатокот од светот. Секоја од точките може да се кликне, можете да влезете и да прочитате за каков провајдер се работи.
График за поврзување на автономните системи на давателот
Користејќи ја оваа алатка, можете да проучите како се структурирани каналите на кој било провајдер, вклучително и хостинг. Погледнете со кои провајдери е директно поврзан. За да го направите ова, треба да ја внесете IP адресата на серверот во пребарувањето за bgp.he.net и да го погледнете графикот на неговиот автономен систем. Можете исто така да разберете како еден центар за податоци или давател на хостинг е поврзан со друг.
Повеќето точки за размена на сообраќајот обезбедуваат специјална алатка наречена стакло за гледање, која ви овозможува да пингувате и да следите од одреден рутер на местото на размена.
Еве, на пример, од МГТС
Значи, при изборот на сервер, можеме однапред да видиме како ќе изгледа од различни точки за размена на сообраќај. И ако нашите потенцијални клиенти се наоѓаат во одредена географска област, можеме да ја најдеме оптималната локација за серверот.
Изберете го најблискиот сервер
Решивме да ја поедноставиме процедурата за наоѓање оптимален сервер за нашите клиенти и создадовме страница со автоматско тестирање на локации во близина: .
Кога посетувате страница, скриптата ги мери доцнењата од вашиот прелистувач до секој сервер и ги прикажува на интерактивна мапа. Кога ќе кликнете на центарот за податоци, се прикажуваат информации со резултати од тестот.
Копчето ве води до тест-страницата за латентност за сите наши центри за податоци. За да ги видите резултатите од тестот, кликнете на точката на центарот за податоци на мапата
Извор: www.habr.com