Vlákno názorů k článku Jak správně číst výpisy z traceroute od anonym - > druhak omezuje čas, který může paket strávit...
-
anonymní> druhak omezuje čas, který může paket strávit v síti (tzn. víte, že když pošlete dva pakety s rozestupem ~4 minut, tak nemůžou do cíle přijít v opačném pořadí).
opravdu ? ttl o case dnes nerika vubec nic. Neniproblem posilat datagram skrze linku bezneho ethernetu ci je prenaset dle rfc1149. V obou pripadech se ttl bude pocitat stejne. Duvod proc se skrze druhou zminovanou variantu nenavaze tcp spojeni lezi naprosto nekde jinde nez v ttl. -
Ale má. Se zamysli, co je větší znalost, traceroute a nebo snifování? Podle mě je traceroute celkem běžná znalost, ale snifování přes TCPDump už umí jen málokdo (z běžných lidí, ne z čtenářů lupy).
"Nemyslis, ze ten kdo umi vymenit filtr v aute ovlada demontaz motoru?"
Podle toho jaký filtr, jestli vzduchu a nebo oleje. A tohle je ten přesný případ, jako by někdo napsal článek o tom, jak vyměnit vzduchový filtr a drobnosti vysvětloval pouhým copy&paste nějakého šíleného návodu, jak rozmontovat motor do šroubku, to je přece hlubší znalost, a každý to neumí.
Copak to nechápeš?
Hodně běžných lidí, co to tu čte zná ping, skoro všichni.
Taky skoro všichni znají traceroute (ale už méně, než ping).
Ale snifovat, tu umí určitě jen třetina lidí, co zná traceroute.
Snad to není tak těžké na pochopení.
Pokud chci tedy vysvětlit traceroute na základě snifování, tak ho musím pořádně okomentovat a nepředpokládat, že ho každý umí, to je postavené na hlavu, protože ho rozhodně každý čtenář Lupy neumí, a i kdyby uměl, tak pořádný autor by to okomentoval i tak. Je třeba psát blbuvzdorně, jinak někdo může napsat článek:
"Jak pracuje traceroute?"
"Jak pracuje traceroute? Viz Google:"traceroute"", ale to ten článek nemusím číst, a rovnou si to můžu všechno vygooglit, když jsem z článku pěkně zmatený. -
To co píšeš nemá logiku.
Nemyslíš si, že ten kdo rozumí TCPDumpu ovládá PERFEKTNĚ traceroute?
Napřed se člověk naučí ping, pak traceroute, a až PAK začne odchytávat pakety a jejich hlavičky.
Tedy pokud vysvětlují základní výpisy z traceroutu, tak k vysvětlení musím použít DETAILNĚ KOMENTOVANÉ výpisy z TCPDumpu (pokud je vůbec nutno je použít...), jinak jim čtenář na dané úrovni (pro koho je článek určen) nebude rozumět. -
Petr (neregistrovaný)Mně paket sekundu v routeru nečeká, ale v tom RFC to tak je specifikované.
The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. -
Jirka P (neregistrovaný)Ne, tak to nebylo. Když si přečtete to RFC, tak je to tam dost jasně: Každý směrovač sníží TTL o zpoždění v sekundách, nejméně však o jedničku. Význam toho je dvojí, jednak to omezuje počet paketů, které jeden odeslaný paket může v síti vytvořit (tzn. ten paket se nemůže milionkrát směrovat, i když jsou někde směrovací tabulky špatně), druhak omezuje čas, který může paket strávit v síti (tzn. víte, že když pošlete dva pakety s rozestupem ~4 minut, tak nemůžou do cíle přijít v opačném pořadí).
MMCH, pokud máte po cestě linku s 9 kbit/s a méně, tak tu sekundu naberete jen přijetím paketu. -
Aha, rozumím.
Proč tohle není všechno uvedeno v článku? Přece pod každý obrázek a nebo nějaký objekt patří popisek, jako v tomhle se člověk opravdu ztratí, kdyby někdo napsal, že je to ze snifferu, a že první řádek je dotaz a ty další začínající ">" odpověď, tak to pochopím hned :(.
Ach jo.
Díky moc, že jsi mi to vysvětlil, jinak ty šipky, porty (i když jsou oddělené tečkou místo klasické dvoutečky), protokol atd, to jsem pochopil taky.
Jen mě fascinuje, že někdo, kdo tomu rozumí sem hodí obrázek a myslí si, že někdo kdo tomu nerozumí, najednou pohým pohledem na obrázek, bez vysvětlení, nějak "prozře".
Teda fakt zlatej Peterka, jeho články jsou sice delší, ale zase mají hlavu a patu, tady aby si člověk hledal polovinu věcí sám a druhou si dosadí ještě špatně a nebo neví vůbec co to je za copy&paste, takhle odfláklý článek pro začátečníky jsem už dlouho neviděl.
Ještě jednou díky za vysvětlení, opravdu jsi mi pomohl! -
Přesně tak.
Navíc ... a opravte mě jestli se pletu .., jsem měl za to že TTL a jeho odečítání po trase je princip traceroute a jeho vypisování celé trasy (přes aktivní prvky).
Pošle se 3x ping s TTL=1, vrátí se 3x odpověď od prvního aktivního prvku na trase.
Pošle se 3x ping s TTL=2, vrátí se 3x odpověď od druhého aktivního prvku po trase.
Atd, až do cíle. -
pupu (neregistrovaný)Dobra, pokud to vezmeme detailne, TTL je opravdu cas (v sekundach) a snizuje se pri pruchodu aktivnimi sitovymi prvky (nikdo jiny nemuze paket modifikovat!) NEJMENE o 1. Doufam, ze se postupne nedostaneme az k citacim z RFC ;-) Pro zajemce - http://www.rfc-editor.org/, napriklad http://www.rfc-editor.org/rfc/rfc791.txt
-
pupu (neregistrovaný)Jdu postupne po polozkach a vybiram ty zajimave. Prvni paket jde s TTL 1, pouziva protokol UDP. Jde z adresy 88.208.65.67 port 33975 na adresu 192.5.5.241 port 33435. Nikdo na nej neni zvedavy (tj. zadna aplikace na cilovem stroji si neregistrovala, ze chce prijimat pakety s takovym cislem portu), takze prvni paket je zahozen a je vygenerovan paket mirici opacnym smerem, ktery ma v okamziku doruceni TTL 64 (poslouchame nejspis na prvnim stroji), pouziva protokol ICMP, jde z adresy 88.208.65.1 (prvni 'hop' po ceste) na 88.208.65.67 a nese zpravu 'ICMP time exceeded in-transit'.
-
S tím socketem jsem to nedal taky :), ale automaticky jsem si za to dosadil to, co popisuješ ty (port s aplikací).
Ohledně TTL:
http://en.wikipedia.org/wiki/Time_to_live
"If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender."
Pokud to chápu dobře je deslán paket s TTL = 2. Jde na první aktivní prvek, ten ho sníží na jedna. Příjde na druhý s jedničkou, ten ho sníží na nulu zahodí a pošle zpět odesilateli hlášku. -
pupu (neregistrovaný)Datove komunikace v TCP/IP sitich probihaji ve forme datovych paketu, tj. data jsou rozdelena na kousky, ty jsou 'obaleny' ruznymi servisnimi daty a odesilany nezavisle na sobe. Neexistujicim soketem mel autor patrne na mysli situaci, kdy na cilovem pocitaci 'neposloucha' zadna aplikace, tj. paket s nastavenym cislem portu nema kdo prijmout. TTL je jedna ze servisnich polozek v hlavicce paketu, je to 'Time To Live' - hodnota, ktera se po pruchodu kazdym aktivnim prvkem po ceste ("hopem") snizuje. Pokud se snizi na nulu, je paket povazovan za zbloudily a je odstranen; pri te prilezitosti je vygenerovan specialni paket mirici opacnym smerem, ktery odesilatele o nastale situaci informuje.
Pokud Vas to opravdu zajima, doporucuji si najit jakoukoliv knihu o zakladech siti. Byva to tam vetsinou pekne vysvetleno. Treba v knihach od pana Dostalka. -
Taky mi připadá, že autor mohl aspoň vysvětlit řádky typu:
10:01:47.548115 IP (tos 0x0, ttl 1, id 62450, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33435: [no cksum] UDP, length 24
> 10:01:47.548203 IP (tos 0xc0, ttl 64, id 3252, offset 0, flags [none], proto: ICMP (1), length: 80) 88.208.65.1 > 88.208.65.67: ICMP time exceeded in-transit, length 60
Rozebrat detailně, co znamenají jednotlivé položky.
Či pokud upozorňuje na nějakou zajímavost v traceroute, tak ji v tom traceroute vyznačit (třeba tučně), se v tom ztrácím a výpisům nerozumím taky. -
Kdyz jsem videl nazev tohoto clanku, mel jsem radost. Konecne nekoho napadlo vysvetlit tento dulezity nastroj. Ale uz samotny zacatek mi vyrazil dech.
Nepochopil jsem ani komu je clanek urcen. Mozna by to chtelo napsat hned v uvodu. Prestoze mu nerozumim, troufam si rict, ze ani neodpovida nazvu. A to jsem prosim studoval kdysi obor "pocitace" :) takze uplny laik nejsem.
"Předně je vhodné si uvědomit, jak traceroute pracuje. Je to jednoduché, pošle packet na neexistující socket" Co to znamena "pošle packet na neexistující socket"? Kdo komu? Rozumim co je "packet", ale co je socket a jeste neexistujici? Kdo na to odpovida?
"TTL se pak zjistí, kolikátý hop v cestě nám zprávu o nedoručitelnosti odeslal."
Co je TTL? Co je "hop"? Co znamena ze "hop odeslal zpravu o nedorucitelnosti"? 8-|
"Pro jednoduchost třikrát uvádím packet jdoucí pouze na první hop a jeho odpověď:" Sorry, ale to neni jednoduchost. To je jakysi vypis nevim z ceho a vubec mu nerozumim. Neslo by to opravdu VYSVETLIT? Moc bych to ocenil.
Sam obcas traceroute pouzivam pro overeni dostupnosti serveru, ale musim priznat, ze detailne jeho vypisu nerozumim.
V clanku je uvedeno mnoho duvodu, proc reklamace na zaklade vypisu traceroute je neopravnena. Ale neni zmineno o jake reklamaci jde rec. Kdo komu reklamuje? Jak pouzit vypis traceroute pro opravnenou reklamaci? Co je treba udelat, overit? "nezbytné je ještě několikanásobně ověřovat" Kolikrat? Jak presne?
Takze diky za pokus, ale pokud by to slo, prosim o skutecne vysvetleni.
