Для шматлікіх задач затрымкі паміж кліентам і серверам крытычна важныя, напрыклад у анлайн гульнях, відэа/галасавых канферэнцыях, IP тэлефаніі, VPN і г.д. Калі сервер будзе занадта выдалены ад кліента на ўзроўні IP-сеткі, то затрымкі (у народзе "пінг", "лаг") будуць замінаць працы.
Геаграфічная блізкасць сервера не заўсёды роўная блізкасці на ўзроўні IP маршрутызацыі. Так, напрыклад, сервер у іншай краіне можа быць "бліжэй" да вас, чым сервер у вашым горадзе. Усё з-за асаблівасцей маршрутызацыі і пабудовы сетак.
Як абраць сервер максімальна блізкі да ўсіх патэнцыйных кліентаў? Што такое складнасць IP-сетак? Як накіраваць кліента на найбліжэйшы сервер? Разбярэмся ў артыкуле.
Вымяраем затрымкі
Для пачатку навучымся вымяраць затрымкі. Гэтая задача не такая простая, як можа здацца, таму што для розных пратаколаў і памераў пакета затрымкі могуць адрознівацца. Таксама можна не заўважыць кароткачасовыя з'явы, напрыклад правалы працягласцю ў некалькі мілісекунд.
ICMP – звычайны ping
Будзем выкарыстоўваць юніксавую ўтыліту ping, яна дазваляе ўручную ўсталяваць інтэрвалы паміж пасылкамі пакетаў, чаго не ўмее версія ping для windows. Гэта важна, таму што, калі паўзы паміж пакетамі доўгія, можна проста не ўбачыць, што адбываецца паміж імі.
Памер пакета (опцыя -s) - па змаўчанні ўтыліта ping пасылае пакеты памерам 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 (round-trip time) роўна 101мс.
MTR - traceroute на пазіцыі, метадалагічнай
Праграма (англ.: My Traceroute) — прасунутая ўтыліта для трасіроўкі маршрутаў да выдаленага хаста. У адрозненні ад звычайнай сістэмнай утыліты traceroute (у windows гэта ўтыліта tracert), умее паказваць затрымкі да кожнага хаста ў ланцужку прытрымлівання пакета. Таксама ўмее трасіраваць маршруты не толькі па ICMP, але і па UDP і TCP.
$ sudo mtr microsoft.com
(Клікабельна) Інтэрфейс праграмы MTR. Запушчана трасіроўка маршруту да microsoft.com
MTR адразу паказвае пінг да кожнага хаста ў ланцужку, прытым дадзеныя ўвесь час абнаўляюцца, пакуль праграма запушчана і можна бачыць кароткачасовыя змены.
На скрыншоце відаць, што на вузле №6 ёсць страты пакетаў, але насамрэч гэта не зусім так, таму што некаторыя маршрутызатары могуць проста адкідаць пакеты са скончаным TTL і не вяртаць адказ з памылкай, таму дадзеныя аб стратах пакетаў тут можна ігнараваць.
WiFi супраць кабеля
Гэтая тэма не зусім адносіцца да артыкула, але на мой погляд вельмі важная ў кантэксце затрымак. Я вельмі кахаю WiFi, але, калі ў мяне ёсць хоць найменшая магчымасць падлучыцца кабелем да інтэрнэту, я ёю скарыстаюся. Таксама я заўсёды адгаворваю людзей выкарыстоўваць WiFi камеры.
Калі вы гуляеце ў сур'ёзныя анлайн-шутэры, вяшчаеце струменевае відэа, гандлюеце на біржы: калі ласка, выкарыстайце інтэрнэт па кабелі.
Вось наглядны тэст для параўнання WiFi і кабельнага падключэння. Гэта ping да WiFi роўтара, то бок яшчэ нават не інтэрнэт.
(Клікабельна) Параўнанне ping да WiFi роўтара па кабелі і па WiFi
Відаць, што па WiFi затрымкі больш на 1мс і часам бываюць пакеты з затрымкамі ў дзесяць разоў больш! І гэта толькі кароткі адрэзак часу. Пры гэтым той жа самы роўтэр выдае стабільныя затрымкі <1мс.
У прыкладзе вышэй выкарыстоўваецца WiFi 802.11n на 2.4GHz, да кропкі доступу па WiFi падлучаны толькі наўтбук і тэлефон. Калі б на кропцы доступу было больш кліентаў, вынікі былі б моцна горшыя. Менавіта таму я так супраць пераводу ўсіх офісных кампутараў на WiFi, калі ёсць магчымасць дацягнуцца да іх кабелем.
IP складнасць
Такім чынам, мы навучыліся вымяраць затрымкі да сервера, паспрабуем знайсці найбліжэйшы сервер да нас. Для гэтага можам паглядзець, як уладкованая маршрутызацыя ў нашага правайдэра. Для гэтага зручна выкарыстоўваць сэрвіс
Пры заходзе на сайт бачым, што наш IP-адрас належыць аўтаномнай сістэме. .
Паглядзеўшы на граф складнасці аўтаномным сістэм, можам убачыць праз якіх вышэйстаячых правайдэраў наш правайдэр звязаны з астатнім светам. Кожная з кропак клікабельна, можна зайсці і пачытаць, што гэта за правайдэр.
Граф складнасці аўтаномных сістэм правайдэра
Выкарыстоўваючы гэты інструмент можна вывучыць, як уладкованыя каналы любога правайдэра, у тым ліку і хостынгу. Паглядзець да якіх правайдэрам ён падлучаны напрамую. Для гэтага трэба забіць у пошук bgp.he.net IP-адрас сервера і паглядзець на граф яго аўтаномнай сістэмы. Таксама можна зразумець, як адзін датацэнтр ці хостынг-правайдэр звязаны з іншым.
Большасць кропак абмену трафікам падаюць адмысловую прыладу, званы, looking glass, які дазваляе выканаць ping і traceroute са боку пэўнага роўтара на кропцы абмену.
Вось, напрыклад, ад МГТС
Так, выбіраючы сервер, мы можам загадзя паглядзець як ён будзе выглядаць з розных кропак абмену трафікам. І калі нашы патэнцыйныя кліенты знаходзяцца ў пэўнай геаграфічнай зоне, мы можам знайсці аптымальную лакацыю для сервера.
Выбіраемы бліжэйшы сервер
Мы вырашылі спрасціць працэдуру пошуку аптымальнага сервера для нашых кліентаў і зрабілі старонку з аўтаматычным тэстам бліжэйшых лакацый: .
Пры заходзе на старонку скрыпт вымярае затрымкі ад вашага браўзэра да кожнага сервера і адлюстроўвае іх на інтэрактыўнай мапе. Пры зграі на датацэнтр паказваецца інфармацыя з вынікамі тэстаў.
Кнопка вядзе на старонку тэсту затрымак да ўсіх нашых датацэнтраў. Каб паглядзець вынікі тэставання націсніце на кропку датацэнтра на мапе
Крыніца: habr.com