Олон даалгаврын хувьд үйлчлүүлэгч болон серверийн хоорондох саатал чухал байдаг, жишээлбэл онлайн тоглоом, видео/дуут хурал, 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
Энэхүү загвар нь саатлын талаар илүү бодитой дүр зургийг харах боломжийг танд олгоно.
UDP болон TCP-ээр дамжуулан ping хийх
Зарим тохиолдолд TCP холболтууд нь ICMP пакетуудаас өөрөөр боловсруулагддаг бөгөөд үүнээс болж хэмжилт нь протоколоос хамаарч өөр өөр байж болно. Мөн хост нь ICMP-д хариу өгөхгүй байх, ердийн пинг ажиллахгүй байх нь олонтаа тохиолддог. Жишээлбэл, хөтлөгч бүх насаараа ийм зүйл хийдэг. microsoft.com.
Хэрэгсэл Алдарт nmap сканнерийн хөгжүүлэгчдээс ямар ч пакет үүсгэх боломжтой. Үүнийг мөн саатал хэмжихэд ашиглаж болно.
UDP болон TCP нь тодорхой портууд дээр ажилладаг тул бид тодорхой портыг "ping" хийх хэрэгтэй. TCP 80, өөрөөр хэлбэл вэб серверийн портыг ping хийхийг оролдъё.
$ 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 (хоолойн цаг) нь 101 мс байгааг бид харж байна.
MTR - стероидууд дээр traceroute
Хөтөлбөр My Traceroute бол алслагдсан хост руу чиглүүлж буй маршрутыг хянах дэвшилтэт хэрэгсэл юм. Ердийн системийн хэрэглүүрийн traceroute-ээс ялгаатай нь (Windows-д энэ нь tracert хэрэгсэл юм) пакетийн сүлжээн дэх хост бүрт саатал харуулах боломжтой. Энэ нь зөвхөн ICMP-ээр зогсохгүй UDP болон TCP-ээр дамжуулан маршрутуудыг хянах боломжтой.
$ sudo mtr microsoft.com
(Дарж болно) MTR програмын интерфейс. microsoft.com руу чиглүүлж эхэлсэн
MTR нь сүлжээн дэх хост бүрт ping-г шууд харуулдаг бөгөөд програм ажиллаж байх үед өгөгдөл байнга шинэчлэгдэж, богино хугацааны өөрчлөлтүүдийг харж болно.
Дэлгэцийн зургаас харахад зангилаа №6 нь пакетийн алдагдалтай байгааг харуулж байгаа боловч үнэн хэрэгтээ энэ нь бүхэлдээ үнэн биш, учир нь зарим чиглүүлэгчид хугацаа нь дууссан TTL-тэй пакетуудыг зүгээр л хаяж, алдааны хариу өгөхгүй байж болох тул энд пакет алдагдлын өгөгдлийг үл тоомсорлож болно.
WiFi vs кабель
Энэ сэдэв нь нийтлэлд бүхэлдээ хамааралгүй, гэхдээ миний бодлоор энэ нь саатлын нөхцөлд маш чухал юм. Би WiFi-д үнэхээр дуртай, гэхдээ надад кабелиар интернетэд холбогдох өчүүхэн ч гэсэн боломж гарвал би үүнийг ашиглах болно. Би хүмүүсийг WiFi камер ашиглахыг үргэлж хориглодог.
Хэрэв та ноцтой онлайн мэргэн бууч тоглох, видео цацах, хөрөнгийн бирж дээр арилжаа хийх бол: кабелиар интернет ашиглана уу.
WiFi болон кабелийн холболтыг харьцуулах харааны тестийг энд оруулав. Энэ бол WiFi чиглүүлэгчийн ping, өөрөөр хэлбэл интернетэд ч холбогдоогүй байна.
(Дарж болно) Кабель болон WiFi-ээр дамжуулан WiFi чиглүүлэгчтэй ping-ийг харьцуулах
Эндээс харахад WiFi-аас үзэхэд саатал 1 мс урт, заримдаа арав дахин их сааталтай пакетууд байдаг! Мөн энэ бол богинохон хугацаа юм. Үүний зэрэгцээ ижил чиглүүлэгч нь <1ms-ийн тогтвортой саатал үүсгэдэг.
Дээрх жишээнд 802.11GHz давтамжтай WiFi 2.4n ашиглаж байгаа бөгөөд зөвхөн зөөврийн компьютер болон утас нь WiFi хандалтын цэгт холбогдсон байна. Хэрэв хандалтын цэг дээр илүү олон үйлчлүүлэгч байсан бол үр дүн нь хамаагүй муу байх болно. Ийм учраас би бүх оффисын компьютерт кабелиар холбогдох боломжтой бол WiFi руу шилжихийн эсрэг байна.
IP холболт
Тиймээс бид серверийн саатлыг хэмжиж сурсан тул өөрт хамгийн ойр серверийг хайж олъё. Үүнийг хийхийн тулд бид үйлчилгээ үзүүлэгчийн чиглүүлэлт хэрхэн ажилладагийг харж болно. Үүний тулд үйлчилгээг ашиглах нь тохиромжтой
Бид сайт руу ороход бидний IP хаяг нь автономит системд харьяалагддаг болохыг хардаг .
Автономит системүүдийн холболтын графикийг харснаар манай үйлчилгээ үзүүлэгч аль дээд түвшний үйлчилгээ үзүүлэгчээр дамжуулан дэлхийн бусад улстай холбогдож байгааг харж болно. Цэг бүр дээр дарах боломжтой тул та ямар төрлийн үйлчилгээ үзүүлэгч болохыг уншиж болно.
Үйлчилгээ үзүүлэгчийн бие даасан системүүдийн холболтын график
Энэ хэрэгслийг ашиглан та ямар ч үйлчилгээ үзүүлэгч, тэр дундаа хостинг зэрэг сувгууд хэрхэн бүтэцлэгдсэнийг судлах боломжтой. Аль үйлчилгээ үзүүлэгчтэй шууд холбогдож байгааг хараарай. Үүнийг хийхийн тулд та bgp.he.net хайлтын системд серверийн IP хаягийг оруулаад автономит системийн графикийг харах хэрэгтэй. Та нэг дата төв эсвэл хостинг үйлчилгээ үзүүлэгч нь нөгөөтэй хэрхэн холбогдож байгааг ойлгох боломжтой.
Ихэнх замын солилцооны цэгүүд нь харагдах шил гэж нэрлэгддэг тусгай хэрэгслээр хангадаг бөгөөд энэ нь солилцооны цэг дээр тодорхой чиглүүлэгчээс пинг хийх, хянах боломжийг олгодог.
Жишээлбэл, MGTS-ээс
Тиймээс сервер сонгохдоо янз бүрийн траффик солилцох цэгүүдээс хэрхэн харагдахыг урьдчилан харж болно. Хэрэв манай боломжит үйлчлүүлэгчид тодорхой газарзүйн бүсэд байрладаг бол бид серверийн оновчтой байршлыг олох боломжтой.
Хамгийн ойрын серверийг сонгоно уу
Бид үйлчлүүлэгчдэдээ оновчтой серверийг олох журмыг хялбарчлахаар шийдэж, ойролцоох байршлыг автоматаар шалгах хуудсыг үүсгэв. .
Таныг нэг хуудсанд зочлох үед скрипт нь таны хөтөчөөс сервер бүрт сааталыг хэмжиж, интерактив газрын зураг дээр харуулна. Дата төв дээр дарахад тестийн үр дүн бүхий мэдээлэл гарч ирнэ.
Товчлуур нь таныг манай бүх дата төвүүдийн саатал шалгах хуудас руу аваачна. Туршилтын үр дүнг харахын тулд газрын зураг дээрх дата төвийн цэг дээр дарна уу
Эх сурвалж: www.habr.com