ugrás a tartalomhoz

TCP és UDP pingelés hogyan működik?

inf · 2019. Ápr. 18. (Cs), 06.49
Szeretném tesztelni az internet kapcsolatot itthon, és úgy tudom, hogy a normál pingelés ICMP-vel megy. Elvileg annyi az egész, hogy azon a protokollon küld egy kérést a szervernek, és a szerver echo-zik, ha ott van. Bizonyos esetekben ez az ICMP nem elég, és a tényleges kommunikációra kell tesztelni, ami TCP vagy UDP. Ilyen mondjuk, ha tűzfal szabály fogja valahol egyik vagy másik protokollt.

Az én esetemben konkrétan az van, hogy a UPC-s Connect Box-nál használt PUMA6 chipset firmware-jét az Intel megtákolta, hogy az ICMP pingelés viszonylag normálisan működjön, de a TCP és az UDP azt mondják ugyanúgy baromi lagos, mert a gond a hardware-el van, nem a software-el. Hivatalosan ezt nem ismerik el, mert hatalmas bukás lenne az Intelnek is, meg sok internet szolgáltatónak is. Nagyon sokan használják az ilyen chipset-re épülő modemeket. Igazából nálam nem sikerült még ezt a firmware fixet se feltenni a UPC-nek a modemre, mert ez az oldal szerintem ICMP-vel pingel: link, de az is lehet, hogy ez a max, amit a firmware fix-el ki tudtak hozni, és a másik két protokollnál jóval nagyobb a baj. Itt csak percenként 1-2 néhány tized másodperces lag spike van, de elképzelhető, hogy UDP-nél sokkal gyakrabban belagzik.

Szívesen lemérném böngésző helyett egy erre tervezett alkalmazással is a pinget egy negyed órára, hogy hogyan változik terheléstől függően, illetve szeretnék alapos lenni, és megnézni TCP és UDP protokolloknál is. Ez elméletileg jó ICMP-re: PingPlotter, de az UDP és TCP bizonytalan. Nem akarom elindítani a 14 napos trialt, hogy kipróbáljam, amíg nem kérek egy kölcsön routert, hogy bridge mode-ban is tudjam tesztelni a Connect Box-ot. Elvileg ICMP-t így kell mérni vele: link a Google DNS szerverén. Ez PsPing elvileg tudja mindhárom protokollt, és az eredményekből ugyanúgy tudok grafikont készíteni. A gond, hogy nem tudok róla, hogy lenne valami olyan szabvány ping, mint ICMP-re, de igazából sosem néztem utána annyira ezeknek a protokolloknak. Még ha létezik ilyen, akkor sem tudom, hogy milyen szervert tudnék pingelni, ami annyira beton biztosan elérhető, mint a Google. Bármi tipp, ötlet a témában?
 
1

Eddig annyit találtam TCP-re,

inf · 2019. Ápr. 18. (Cs), 11.56
Eddig annyit találtam TCP-re, hogy Nagios-nak küldtek echo parancsot, ami meg végrehajtotta. Ezek alapján is az a gyanús, hogy TCP-re és UDP-re nincs szabvány ping, mint ICMP-re. Nyomozok tovább, hátha találok valami TCP meg UDP szervert, ami engedi, hogy ilyesmi formán pingeljem. Nem tudom létezik e ilyen szolgáltatás. Legrosszabb esetben felteszek valamit Herokura, amin le tudom mérni.
3

Ezt jól látod, az icmp

mind1 valami név · 2019. Ápr. 18. (Cs), 13.00
Ezt jól látod, az icmp kifejezetten ilyesmire van, a TCP/UDP az alapvetően nem ilyen, nem lehet velük "pingelni" (lehet, lásd lejjebb, de az nem ugyanaz)
2

Mondjuk a szolgáltatói

mind1 valami név · 2019. Ápr. 18. (Cs), 12.58
Mondjuk a szolgáltatói dobozok használata... én biztosan csak bridge mode-ban tenném.

Amennyire "értek" a témához: az icmp egy kifejezetten gyors, nem igazán adatok átvitelére kitalált protokoll, szerintem nem nagyon kellett semmit "optimalizálni" a dobozodban ahhoz, hogy az icmp akkor is normális életjeleket mutasson, amikor egy tcp vagy udp alapú kommunikáció már döglődni kezd.

Hogy pontosan hogyan képzeled a nem icmp alapú ping-et, az számomra nem teljesen világos.
A traceroute például UDP alapú, de tud TCP packetekkel is dolgozni, csak ez utóbbihoz, meg tán az icmp-hez is, root jog kell neki linuxon.
Aztán van még az nmap, mint diagnosztikai eszköz: link

De ha ilyesmit akarsz tesztelni, arra én inkább egy download managert használnék, ami akár grafikonon is meg tudja jeleníteni a letöltési sebesség változásait és megcéloznám a legközelebbi linux tükröt, ahonnan min. 10Gbps sebességgel lehet letölteni, ott már esélyes, hogy akár a gigabites szolgáltatásodat is ki tudják szolgálni, és megpróbálnám letölteni valamelyik linux image-et a /dev/null-ba.
Ilyesmire gondoltál?
4

Hát pedig ezzel a chipsettel

inf · 2019. Ápr. 18. (Cs), 14.08
Hát pedig ezzel a chipsettel voltak latency spike-ok az ICMP-vel is. Csináltak rá egy firmware fix-et, ami javított a helyzeten, de állítólag még mindig van. Én mondjuk 20 perc alatt 1 packet-et vesztettem az 1200-ból ki tudja miért, szóval a gyakorlatban nem túl sűrű az ilyen. Kipróbálom később, hátha lehet 0.1sec-es időközt is beállítani. Nem néztem.

Úgy képzelem el, hogy küldök valamit, a szerver meg echozza, én meg mérem a küldés és érkezés közötti időközt. Nem valami bonyolult dolog. Viszont ehhez a szervernek is hozzá kellene járulni. Nem tudom léteznek e ilyen szerverek, amikkel megoldható, ahogy azt sem, hogy a psping meg hasonlók hogyan pingelnek TCP-re és UDP-re. Valahogy mégis megcsinálják. Elvileg.

Igazából az érdekelne, hogy alapból mennyire szar a helyzet UDP-vel, és hogy ha bridge mode-ba teszem, akkor az javít e rajta.

Nem világos, hogy a letöltési sebesség ingadozása miről ad információt.
5

Ha nagyon ingadozik a

mind1 valami név · 2019. Ápr. 18. (Cs), 15.58
Ha nagyon ingadozik a letöltés, akkor valahol gond van.
Ha minden szerveren, akkor esélyes, hogy nálad.
De mondom, nem teljesen tiszta a problémád lényege, különösen, hogy udp-t emlegetsz. Játszani próbálsz és szaggat?

echo szerver létezik, bár ezek azt hiszem, inkább websocketes tesztekhez vannak.
6

Ngram-al pár sor egy echo

inf · 2019. Ápr. 18. (Cs), 17.13
Ngram-al pár sor egy echo szervert írni. Olyan egyszerű, hogy még githubon se lehet megtalálni. :D pl: link

Hosszú...

Annak idején nagyobb részt azért hagytam abba az esportot, mert valami fura lagot tapasztaltam. Olyan volt párszor, hogy bementem egy szobába, aztán fél másodperccel később rajzolta ki a játék, hogy a szoba nem üres. Addigra igazából már mindegy volt, hogy mit csinálok, mert halott voltam. Olyan is volt, hogy lőttek rám, aztán semmi HP veszteségem nem volt, utána meg hirtelen egyszerre regisztrálta az összes találatot, ami az előtte lévő néhány másodpercben beütött. Célzásnál is rendesen az ember elé vagy mögé, vagy ki tudja hova kellett lőni, a lényeg, hogy ne oda, ahol az embert látom, mert ott kb. sosem talált. Mindhárom jelenség arra utal, hogy a letöltésnél baromi nagy lagok vannak. Mellette a játék stabil 45-ös pinget írt, és egyáltalán nem mutatott lagot.

Amikor ez a jelenség elkezdődött, akkor cseréltem gépet, monitort, egeret, internet szolgáltatót, operációs rendszert. Azóta se derült ki számomra, hogy melyik okozta. Gépet már cseréltem sokszor, biztosan nem azzal van a gond, vagy nagyon peches vagyok. Egyedül a táp maradt ugyanaz, amit bemértem táp teszterrel, rendesen működik. Egeret cseréltem többször, mert olyan érzés volt, amikor céloztam, mintha a mouseaccel be lenne kapcsolva, vagy a kábél elhúzná a célzásom. Vettem vezeték nélküli gamer egeret is, de ezzel is ugyanolyan, pedig annak idején egy darabig volt vezeték nélküli egerem még a régi időkben, és azzal lőttem a legpontosabban, mert nem zavart be a kábel. Fedora-t teszteltem, azzal mintha jobb lett volna, mint Win7-el, de sokszor nem vette be a nem NKRO billentyűzet gombjait, így nem tudtam normálisan megnézni. Most van NKRO mechanikus billentyűm, de 2 éve nem volt időm vagy kedvem játszani. Szóval továbbra is lehet, hogy a Win7 vagy a monitor vagy az oprendszer okozza.

Nagyjából ez a sztori. Nem rég meg olvastam, hogy a UPC-nél 2 éve PUMA6 chipsetes Connect Box-ok voltak, és hogy hibás a chipset, mert terhelésre durván belagzik az egész, és fel-fel ugrál a ping 200-ra. Állítólag az Intel kiadott valami tákolást hozzá, hogy az ICMP jó legyen, azóta a ping csak ritkábban ugrál fel. Viszont sokan azt mondják, hogy az UDP és a TCP ugyanúgy belagzik, mert az egészet hardver hiba okozza, nem szoftver hiba, és emiatt a firmware tákolása nem tudja megoldani. Szóval azt mondják, hogy az Intel csak elkendőzte ezzel, hogy szarok ezek a modemek, és az internet szolgáltatók ehhez asszisztálnak, mert baromi sok pénzt buknának, ha hirtelen mindenkinél modemet kellene cserélni. Utánanéztem egy kicsit régebben, és 50k lenne kicserélnem a ConnectBox-ot egy hasonló képességű router-re, azonos wifi erősséggel és sávszélességgel. Még ha ötöd ennyivel nézzük, akkor is 10k egy háztartásnál, és ha mondjuk a UPC-nek van 1M ügyfele, akkor az már 25 milliárd Forint...

Na most ez az egész teljes mértékben magyarázná, hogy a ping normális nekem játék közben és mellette lagot érzek az egész játékban, mert a pingelés ICMP-vel megy, a játék meg UDP-t használ. Volt még több hiba is ezzel a chipsettel, pl le lehet ültetni a routert DOS támadással. A hibák egy része (nem tudom melyik része) a PUMA5 és PUMA7 chipsetbe is sikeresen bekerült. A PUMA6 úgy olvasom wikipedia-n, hogy 2012 óta van, elképzelhető, hogy előtte PUMA5 volt a Connect Box-okban. Itt valamikor 2008 és 2010 között váltottunk UPC-re, szóval elképzelhető, hogy ez okozza a gondjaimat. Azt mondják, hogy bridge mode-ban megoldódnak a problémák, viszont állítólag meg valakinél úgy sem működött rendesen. Szóval külön akarom tesztelni UDP-re és TCP-re is a netet a Connect Box-al és bridge mode-ban egy másik routerrel is. Egyelőre az ICMP-s pinget megnéztem, az jónak tűnik. Az UDP, ami igazán érdekes, hogy mennyire ugrál fel. Mellette még a meter.net ping tesztjét néztem, ami nem tudom mit használ, de mivel böngészős és nem kért flash vagy java hozzáférést, ezért vagy WebRTC vagy websocket mehet a háttérben, ami UDP vagy TCP lesz. Meg kéne nézném a forráskódját, hogy biztosra megmondjam. Aztán persze az is lehet, hogy flash-el varázsol valamit a háttérben, és valamiért elmaradt az engedély kérés. Ami a lényeg, hogy a meter.net percenként mutatott néhány 100 és 200 közötti lag spike-ot. Viszont ami nekem kéne az egy 20 perces mérés, amin tisztán látom, hogy rossz a kapcsolat. Utána meg ugyanez bridge mode-ban egy normális routerrel, amit kölcsön kérek valakitől.

Ha egyikben sem rossz, akkor nem a net okozza a problémát, hanem vagy a monitor vagy a win7 (de a meter.net-es teszt alapján valszeg nem ez a helyzet). Ha bridge mode-ban jó, akkor vennem kell egy új routert. Ha egyikben sem jó, akkor így jártam. Nem akarok Invitelre visszaváltani, mert utáltam a szolgáltatásukat. Kábelmodemet se tudok betenni sajátot, mert állítólag a UPC nem enged idegen készülékeket a hálózatába. Tudnék régi UPC-s kábelmodemet venni, de ki tudja milyen minőségre, illetve max 300Mbit, amit ki lehet sajtolni belőle azt mondják, nekem meg 500-as netem van csomagban. Mondjuk meg tudom nézni, hogy redukálható e 250-re, mert úgysem használom ki igazán. Mellette egy normális wifis routerrel megoldható a dolog. Pénzben egyedül a win7 lecserélése Linuxra, ami ingyen lenne. A többi 50k legalább.
7

Hát ennek a precíz

mind1 valami név · 2019. Ápr. 18. (Cs), 17.24
Hát ennek a precíz felderítése bőven meghaladja a tudásomat.
A stackexchange-en van egy ilyesmit taglaló poszt: link, de nem biztos, hogy rajtad segít.

Ha van a neten egy olyan szervered, amiről tudod, hogy 100%-os kellene legyen a net felé és van rajta parancssori elérésed is, akkor ott lenne az iperf, de annak az értelmezése is külön tudományág :) (elég sok hülyeséget sikerült "kitalálnom" amikor azzal méricskéltem a wifimet)
Ilyesmi...
9

Máshol a hping-et ajánlották,

inf · 2019. Ápr. 18. (Cs), 20.51
Máshol a hping-et ajánlották, hogy nézzek bele a kódjába, hátha jutok valamire. De azt hiszem írok majd a hping issuejai közé egy kérdést, hogy erre van e valami szabvány, vagy csak így lehet megoldani. Igazából eddig az jött le, hogy teljesen igazam van, nincs szabvány rá, és speciális szerver kell hozzá, ami echozza a timestampeket vagy id-ket, amiket küldünk feléje. Viszont ha nincs szabvány, akkor nem értem, hogy a psping meg a pingplotter hogyan működik, vagy hol dokumentálják le, hogy milyen kell legyen a szerver hozzá, amin tesztelni akarunk.
12

Ahogy azt már BlaZe is írta,

mind1 valami név · 2019. Ápr. 19. (P), 09.29
Ahogy azt már BlaZe is írta, az UDP és TCP nem a tesztelésre van kitalálva, nincs olyan "szabvány", hogy hogyan teszteljük.
Windows-om nincs, a pingplottert nem tudom kipróbálni, de engem kísértetiesen emlékeztet a traceroute-ra, aminek van egy mtr nevű alternatívája is linuxon, ráadásul utóbbinak van GUI-ja is. Mintha létezne belőle windows-os is, de ebben nem vagyok biztos.
Esetleg azt is megnézheted, bár grafikont nem tud, de sok más egyebet igen.

Egyébként úgy tűnik, ennek mindegy, hogy a megcélzott szerveren mi van, mert kötve hiszem, hogy a steam.com oldalon futna bármi UDP alapú, publikus szolgáltatás, a mtr mégis tudja mérni. Viszont ez sem olyan, mint amit te szeretnél, mert nagyon rövid packetekkel dolgozik. (36 byte, ha igaz), a játékoknak meg ennél valószínűleg több kell.

Egyébként úgy húsz éve, valamelyik első multiplayer FPS-nek volt olyan konzolja, ahol le lehetett kérni a grafika, a network stb. statisztikákat, köztük a network lag, packet loss és hasonló értékeket.
8

Írhatsz ilyen service-t

BlaZe · 2019. Ápr. 18. (Cs), 20.45
Írhatsz ilyen service-t magadnak TCP és UDP fölé, amit kirakhatsz valahova és csak visszaböfög valamit egy adott inputra. De ezek alapvetően adatátviteli protokolok, szemben az ICMP-vel, többek között ezért sem az igazi választás pingre.

TCP esetén az az izgalmas, hogy az egy kapcsolat alapú protokol, tehát bármit kommunikálsz felette, kell egy handshake előtte. Élő connection alatt tudsz értelmesen pinget mérni, ez egy erős érv a TCP ping ellen. Illetve pl beállíthatsz rajta TCP_NO_DELAY-t, azzal egész mást mérhetsz, mint nélküle.

UDP esetén nincs kapcsolat, cserébe viszont az by design egy nem megbízható protokol, vagyis elveszhetnek csomagok, random sorrendben érkezhetnek meg stb.

Mivel mindkettő adatátvitelre van tervezve, számítani fog az átvivendő adatmennyiség, a buffer mérete, esetleg az egyéb más hálózati kommunikáció befolyásolni fogja, hogy mikor kerül ki ténylegesen a hálóra stb.

Én semennyit nem játszottam az elmúlt X évben, de felteszem a játékok mérik a lagot. Az nem használható arra, hogy erről meggyőződj?
10

Ez az, hogy nem tudni mi

inf · 2019. Ápr. 18. (Cs), 21.05
Ez az, hogy nem tudni mi alapján mérik. Ha ICMP-vel pingelnek közben, akkor az semmit nem fog mutatni ezen a modemen. Ha TCP-vel vagy UDP-vel mérik, akkor az mutathat 200-as tüskéket. Amivel én toltam, annál erős a gyanúm, hogy ICMP-vel pingel, és úgy mér, közben meg UDP-n megy maga a játék. Legalábbis ahogy írtam 45-ös pinget írt szinte lag nélkül, közben meg volt, hogy 200-nak érződött, és minden jel arra utal, hogy annyi is volt ténylegesen, ha nem több.

Igazából még ezen kívül az jöhet szóba, hogy a net normális, és a megjelenítésnél valamiért elcsúszik az ellenfelek renderelése pár tized másodperccel. Nem tudok róla, hogy hardver hiba okozhatna ilyesmit, szóval ha ez így van, akkor valszeg rosszul megírt a játék. Másnál viszont nem jelentkezik ugyanez a probléma, és mióta elkezdődött, azóta 2x cseréltem már gépet szinte teljesen. Igazából már hallottam mástól is, de az emberek többsége azt mondja, hogy nála tökéletesen működik minden. Mellette meg nincs meg stabilan a 125 FPS core i5-el, GTX 750 Ti-vel egy 15 éves játékban, ahol a 999-et is stabilan kéne hoznia...
11

Jó nagy hülye vagyok, egész

inf · 2019. Ápr. 19. (P), 09.26
Jó nagy hülye vagyok, egész idáig pinggel kerestem google-ben ahelyett, hogy measure latency-t írtam volna. A ping-nél meg ugye a találatok túlnyomó része ICMP-s.
13

Azért ez nem fedi teljesen a

mind1 valami név · 2019. Ápr. 19. (P), 09.32
Azért ez nem fedi teljesen a problémádat.
Az jutott még eszembe, hogy azon a júpíszís vackon nincs valami admin felület, ahol pl. a csomagvesztéseket le lehetne kérdezni?
Lokálisan meg tudod nézni, de a dobozod NAT-ol, így azt hiszem, ott csak a doboz és a géped közti hibákat látod, az internetre vonatkozókat nem annyira.
14

Jel szinteket, ilyesmit lehet

inf · 2019. Ápr. 19. (P), 10.06
Jel szinteket, ilyesmit lehet lekérdezni, nem rémlik, hogy packet loss lenne. Post RS Errors, Pre RS Errors, T3 timeouts, amiket számol.
15

Eszembe jutott még olyasmi

mind1 valami név · 2019. Ápr. 19. (P), 10.17
Eszembe jutott még olyasmi is, hogy játékoknál zavaró lehet egy bekapcsolt QoS szolgáltatás is, a routeren. De csomagvesztés, lag előfordulhat valamelyik terheltebb routeren is, közted és a szerver közt, ami jöhet akár abhól is, hogy a szolgáltatód vagy az általa hasznàlt útvonal egyik-másik routere nem bírja a terhelést.

Vagy... a kedvencem, a digi elkefélt fttb eszközei a lépcsőházakban: fizikailag közeli szerverrel lehet normálisan kommunikàlni, de mondjuk egy londoni vagy hong kongi szerverrel már katasztrofális a sebesség, miközben ugyanez a szomszéd lakásban teljesen jó. (Hálózatos ismerős mondott erre valamit anno, hogy kicsit át kéne paraméterezni a dobozokat a folyosón, de a digi ügyfélelhárítók nem akarnak foglalkozni vele) És ez csupa olyan, amit egy szolgáltató váltás hozhat és semmit sem tudsz tenni. :(
16

Igazából UPC-vel még jön a

inf · 2019. Ápr. 19. (P), 10.45
Igazából UPC-vel még jön a wifree is, és bárki az utcáról a te áramoddal menő modemet használja wifizésre. Kikapcsolni elviekben a myupc oldalán lehet, gyakorlatban hibásra írták meg, hogy ne lehessen kikapcsolni. Nem mintha ez számítana egy alapból rossz modemnél.

Ez a QoS érdekes, majd megnézem admin felületen, hogy találok e bármi ilyet.
17

A wifree állítólag nem

mind1 valami név · 2019. Ápr. 19. (P), 12.00
A wifree állítólag nem befolyásolja a rendelkezésedre álló sávszélességet, mondhatni független a szolgáltatásodtól. Persze ki tudja...

A QoS-t nem feltétlenül magadnál kell keresni. Attól kezdve, hogy a torrentet valamilyen módon visszafogja a upc, valószínű, hogy vqn a hálózatukon ilyesmi (pusztán feltételezés rèszemről, de másképp hogy tudna egyetlen szolgáltatást korlátozni?)


Szerintem találgatás helyett jobban járnál egy gigabites pppoe-t kihajtani képes router+bridge mode kipróbálásával.
Feltéve, hogy van rá lehetőséged.
Nekem egy wdr4300 van tartalékban, az a 100Mbitet is épphogy elbírja.
18

Pont ez az, hogyha vennék

inf · 2019. Ápr. 19. (P), 15.20
Pont ez az, hogyha vennék most egy új routert az találgatás lenne. Le akarom mérni először, hogy tényleg rossz e a modem, aztán kérek kölcsön valakitől egy routert, hogy megnézzem bridge mode-ban is rossz e, vagy mi a helyzet. Ha esetleg mégis jó, akkor már csak olyan ötletem van, hogy felveszem játék közben, hogy mit mutat a monitor meg visszajátszva is, és összehasonlítom a kettőt. Ha nincs teljes átfedés, hanem az emberek el vannak tolódva, akkor legalább kimutattam, hogy valahol tényleg latency kerül bele. Még ami szóba jöhet, hogy kicserélem a monitort egy másikra, aztán megnézem azzal is, hogy mi a helyzet. Nagyjából ennyi, igazából minden mérés, amit eddig csináltam az utóbbi 10 évben azt mondja, hogy minden tökéletes, pedig messze nem az.
19

Hát online játékoknál én már

mind1 valami név · 2019. Ápr. 19. (P), 16.02
Hát online játékoknál én már régebben is azt tapasztaltam, hogy leginkább a hálózat routeren túli oldalán van a hiba.
Mi lenne, ha beszélnél a supporttal, hogy ideiglenesen tegyék át bridge módba, aztán használnád közvetlenül a gépedről (feltételezem, nem wifin játszol, mert az felér egy orosz rulettel, amit egy Beretta M9 segítségével játszol :D)
Akkor még a routerrel sem kell szarozni, ott van a gépeden a közvetlen kapcsolat, azzal a router gondot biztosan kizárhatod.
20

Ja, ebben teljesen igazad

inf · 2019. Ápr. 19. (P), 16.32
Ja, ebben teljesen igazad van, nem is kell router az itthoni teszthez, közvetlenül is rá lehet kötni a gépet. Át tudom rakni bridge mode-ba admin felületről gondolom. Inkább a visszaállítás szokott gondot okozni, mert olyankor el szokott tűnni az admin oldal más routereken.
21

Upc-t nem tudom, diginél

mind1 valami név · 2019. Ápr. 19. (P), 16.50
Upc-t nem tudom, diginél állítólag az ügyfélelhárító szolgálat segítségét kell kérni.