Ar gyfer llawer o dasgau, mae oedi rhwng y cleient a'r gweinydd yn hollbwysig, er enghraifft mewn gemau ar-lein, fideo/cynadledda llais, teleffoni IP, VPN, ac ati. Os yw'r gweinydd yn rhy bell oddi wrth y cleient ar lefel rhwydwaith IP, yna bydd oedi (a elwir yn boblogaidd yn “ping”, “lag”) yn ymyrryd â gwaith.
Nid yw agosrwydd daearyddol gweinydd bob amser yn gyfartal agosrwydd ar y lefel llwybro IP. Felly, er enghraifft, gall gweinydd mewn gwlad arall fod yn “agosach” atoch chi na gweinydd yn eich dinas. Y cyfan oherwydd hynodrwydd llwybro ac adeiladu rhwydwaith.
Sut i ddewis gweinydd sydd mor agos â phosibl at bob cleient posibl? Beth yw cysylltedd rhwydwaith IP? Sut i gyfeirio cleient at y gweinydd agosaf? Gadewch i ni ddarganfod yn yr erthygl.
Mesur oedi
Yn gyntaf, gadewch i ni ddysgu sut i fesur oedi. Nid yw'r dasg hon mor syml ag y gall ymddangos oherwydd gall oedi amrywio ar gyfer protocolau a meintiau pecynnau gwahanol. Efallai y byddwch hefyd yn colli digwyddiadau tymor byr, fel dipiau sy'n para ychydig milieiliadau.
ICMP - ping rheolaidd
Byddwn yn defnyddio cyfleustodau ping Unix; mae'n caniatáu ichi osod y cyfnodau rhwng anfon pecynnau â llaw, na all y fersiwn ping ar gyfer Windows ei wneud. Mae hyn yn bwysig oherwydd os oes seibiau hir rhwng pecynnau, efallai na fyddwch yn gweld beth sy'n digwydd rhyngddynt.
Maint pecyn (option -s) - yn ddiofyn, mae'r cyfleustodau ping yn anfon pecynnau o 64 bytes o faint. Gyda phecynnau mor fach, efallai na fydd ffenomenau sy'n digwydd gyda phecynnau mwy yn amlwg, felly byddwn yn gosod maint y pecyn i 1300 beit.
Ysbaid rhwng pecynnau (opsiwn -i) — yr amser rhwng anfon data. Yn ddiofyn, anfonir pecynnau unwaith yr eiliad, mae hyn yn hir iawn, mae rhaglenni go iawn yn anfon cannoedd ar filoedd o becynnau yr eiliad, felly byddwn yn gosod yr egwyl i 0.1 eiliad. Yn syml, nid yw'r rhaglen yn caniatáu llai.
O ganlyniad, mae'r gorchymyn yn edrych fel hyn:
ping -s 1300 -i 0.1 yandex.ru
Mae'r dyluniad hwn yn caniatáu ichi weld darlun mwy realistig o oedi.
Ping trwy CDU a TCP
Mewn rhai achosion, mae cysylltiadau TCP yn cael eu prosesu'n wahanol na phecynnau ICMP, ac oherwydd hyn, gall mesuriadau amrywio yn dibynnu ar y protocol. Mae hefyd yn aml yn digwydd nad yw'r gwesteiwr yn ymateb i ICMP, ac nid yw ping rheolaidd yn gweithio. Dyma beth mae gwesteiwr yn ei wneud ar hyd ei oes, er enghraifft. microsoft.com.
Cyfleustodau gan ddatblygwyr y sganiwr enwog gall nmap gynhyrchu unrhyw becynnau. Gellir ei ddefnyddio hefyd i fesur oedi.
Gan fod CDU a TCP yn gweithredu ar rai penodol, mae angen i ni “pingio” porthladd penodol. Gadewch i ni geisio ping TCP 80, hynny yw, y porth gweinydd gwe:
$ 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
Yn ddiofyn, mae nping yn anfon 4 pecyn ac yn stopio. Opsiwn -c 0 galluogi anfon pecynnau yn ddiddiwedd; i atal y rhaglen, mae angen i chi wasgu Ctrl+C. Bydd ystadegau yn cael eu dangos ar y diwedd. Gwelwn fod y gwerth rtt (amser taith gron) ar gyfartaledd yn 101ms.
MTR - traceroute ar steroidau
Rhaglen Mae My Traceroute yn gyfleustodau datblygedig ar gyfer olrhain llwybrau i westeiwr anghysbell. Yn wahanol i'r traceroute cyfleustodau system arferol (yn Windows dyma'r cyfleustodau tracert), gall ddangos oedi i bob gwesteiwr yn y gadwyn paced. Gall hefyd olrhain llwybrau nid yn unig trwy ICMP, ond hefyd trwy CDU a TCP.
$ sudo mtr microsoft.com
(Cliciadwy) rhyngwyneb rhaglen MTR. Dechreuwyd olrhain llwybrau i microsoft.com
Mae MTR yn dangos y ping ar unwaith i bob gwesteiwr yn y gadwyn, ac mae'r data'n cael ei ddiweddaru'n gyson tra bod y rhaglen yn rhedeg a gellir gweld newidiadau tymor byr.
Mae'r sgrinlun yn dangos bod gan nod #6 golledion pecynnau, ond mewn gwirionedd nid yw hyn yn hollol wir, oherwydd gall rhai llwybryddion daflu pecynnau gyda TTL sydd wedi dod i ben a pheidio â dychwelyd ymateb gwall, felly gellir anwybyddu'r data colli pecynnau yma.
WiFi yn erbyn cebl
Nid yw'r pwnc hwn yn gwbl berthnasol i'r erthygl, ond yn fy marn i mae'n bwysig iawn yng nghyd-destun oedi. Rwyf wrth fy modd â WiFi, ond os oes gennyf hyd yn oed y cyfle lleiaf i gysylltu â'r Rhyngrwyd gyda chebl, byddaf yn ei ddefnyddio. Rwyf hefyd bob amser yn annog pobl i beidio â defnyddio camerâu WiFi.
Os ydych chi'n chwarae saethwyr ar-lein difrifol, yn ffrydio fideo, neu'n masnachu ar y gyfnewidfa stoc: defnyddiwch y Rhyngrwyd trwy gebl.
Dyma brawf gweledol i gymharu cysylltiadau WiFi a chebl. Mae hwn yn ping i'r llwybrydd WiFi, hynny yw, nid hyd yn oed y Rhyngrwyd eto.
(Cliciadwy) Cymharu ping â llwybrydd WiFi trwy gebl a thrwy WiFi
Gellir gweld bod yr oedi dros WiFi 1ms yn hirach ac weithiau mae pecynnau gydag oedi ddeg gwaith yn hirach! A dim ond cyfnod byr yw hwn. Ar yr un pryd, mae'r un llwybrydd yn cynhyrchu oedi sefydlog o <1ms.
Yn yr enghraifft uchod, defnyddir WiFi 802.11n ar 2.4GHz, dim ond gliniadur a ffôn sydd wedi'u cysylltu â'r pwynt mynediad WiFi. Pe bai mwy o gleientiaid ar y pwynt mynediad, byddai'r canlyniadau'n waeth o lawer. Dyma pam fy mod mor erbyn newid pob cyfrifiadur swyddfa i WiFi os yw'n bosibl eu cyrraedd gyda chebl.
Cysylltedd IP
Felly, rydym wedi dysgu mesur oedi i'r gweinydd, gadewch i ni geisio dod o hyd i'r gweinydd agosaf atom ni. I wneud hyn, gallwn edrych ar sut mae llwybro ein darparwr yn gweithio. Mae'n gyfleus defnyddio'r gwasanaeth ar gyfer hyn
Pan fyddwn yn cyrchu'r wefan, gwelwn fod ein cyfeiriad IP yn perthyn i'r system ymreolaethol .
Trwy edrych ar graff cysylltedd systemau ymreolaethol, gallwn weld trwy ba ddarparwyr lefel uwch y mae ein darparwr wedi'i gysylltu â gweddill y byd. Gellir clicio ar bob un o'r dotiau, gallwch fynd i mewn a darllen pa fath o ddarparwr ydyw.
Graff cysylltedd o systemau ymreolaethol y darparwr
Gan ddefnyddio'r offeryn hwn, gallwch astudio sut mae sianeli unrhyw ddarparwr, gan gynnwys cynnal, wedi'u strwythuro. Gweld pa ddarparwyr y mae wedi'u cysylltu'n uniongyrchol â nhw. I wneud hyn, mae angen i chi nodi cyfeiriad IP y gweinydd yn y chwiliad am bgp.he.net ac edrych ar graff ei system ymreolaethol. Gallwch hefyd ddeall sut mae un ganolfan ddata neu ddarparwr cynnal wedi'i gysylltu ag un arall.
Mae'r rhan fwyaf o bwyntiau cyfnewid traffig yn darparu teclyn arbennig o'r enw gwydr sy'n edrych, sy'n eich galluogi i ping ac olrhain o lwybrydd penodol yn y man cyfnewid.
Er enghraifft, oddi wrth MGTS
Felly, wrth ddewis gweinydd, gallwn weld ymlaen llaw sut y bydd yn edrych o wahanol bwyntiau cyfnewid traffig. Ac os yw ein darpar gleientiaid wedi'u lleoli mewn ardal ddaearyddol benodol, gallwn ddod o hyd i'r lleoliad gorau posibl ar gyfer y gweinydd.
Dewiswch y gweinydd agosaf
Fe wnaethom benderfynu symleiddio'r weithdrefn ar gyfer dod o hyd i'r gweinydd gorau posibl ar gyfer ein cleientiaid a chreu tudalen gyda phrofion awtomatig o leoliadau cyfagos: .
Pan fyddwch yn ymweld â thudalen, mae'r sgript yn mesur yr oedi o'ch porwr i bob gweinydd ac yn eu dangos ar fap rhyngweithiol. Pan gliciwch ar ganolfan ddata, dangosir gwybodaeth gyda chanlyniadau profion.
Mae'r botwm yn mynd â chi i'r dudalen prawf hwyrni ar gyfer ein holl ganolfannau data. I weld canlyniadau'r profion, cliciwch ar y pwynt canolfan ddata ar y map
Ffynhonnell: hab.com