potvrzování v protokolu TCP
Dobrý den. Učím se základy počítačových sítí a potřeboval bych osvětlit násludující:
Dočetl jsem se, že protokolem TCP jsou přenášeny tzv. segmenty (respektive od aplikační vrstvy dostává jednotlivé byty a střádá si je do bufferu a poté odešle jako celek v tzv. segmentu). Aby se dosáhlo spolehlivosti, tak na správně přenesená data se reaguje kladným potvrzením (positive-acknowledgement, ještě se tato metoda kombinuje s posunutím pomyslného okénka (sliding windows), které říká, kolik segmentů může odesilatel odeslat bez toho, aby čekal na kladné potvrzení předešlého segmentu) a na špatně přenesená data se nereaguje nijak. Dále jsem se dočetl, že potvrzovanými jednotkami nejsou celé segmenty, ale jednotlivé byty (osmibitové oktety). Pokud dojde k chybě v přenosu nějakého bytu (osmibitového oktetu), tak se přenese vše znova od tohoto chybně přeneseného osmibitového oktetu....příklad: mám byty xyz, které přenáším v segmentu, x se potvrdí (správně přeneseno), y se nepotvrdí (chyba při přenosu) a z se opět potvrdí (správně přeneseno) - a na toto odesilatel reaguje opětovným zasláním bytů yz (metoda Go-Back-N). Je to tak nebo v tom mám bordel? Za případné odpovědi děkuju.
Tak to su pre mna novinky co pises. Nie som velky teoretik skor praktik, ale bol som doteraz v tom, ze kazdy segment okrem prveho so syn priznakom ma vzdy ack priznak, cize potvrdzuju prijate data, cize fakt, ze sa na spatne prenesene data nereaguje je udivujuci. Ved predsa prave v tomto je vyhoda TCP oproti inym protokolom.
V kazdom pripade to ako funguje TCP nie je pre moj zivot extra dolezite, ale mozno sa dozviem nieco nove.
Viz. > pc-site.owebu.cz je to v podstatě přepis prací J. Peterky (zde to lze najít také: index.php3). Takže buď se to změnilo od doby, kdy vyšli jeho materiály nebo jeden z vás nemá pravdu. To nic nemění na tom, že bych to chtěl vědět přesně.
no však - ACKem cíl sděluje, že data od zdroje přijal. Pokud ACK nepošle (nebo ten se ztratí), je paket odeslán znova. Ono to ani jinak nejde, cíl nemůže odeslat zprávu, že nepřijal paket (protože logicky žádný nepřijal a NEVÍ, že má nějaký dojít
).
A samozřejmě, pokud se vyskytne chyba CRC, pak se posílá jen chybná část (na vyžádání cílovým hostitelem)
Da sa povedat ze to mas naucene spravne, az na to ze SW je ina (ucinnejsia) metoda riadenia a potvrdzovania prenosu ako PAR, nakolko pri PAR sa potvrdzuje kazda jednotka dat (byt, paket, skupina dat)...
odkial si cerpal ?
Literatura viz. výše.
Už mi to asi nedostatečně myslí, ale přesto ze sebe udělám tupce a zeptám se: co myslíš tím SW (sliding window?) a PAR?
SW = sliding window
PAR = positive acknowledgment and retransmission
pokial by si to chcel vediet uplne presne myslim, ze je lepsie sa obratit na normu popisujucu TCP/IP (RFC), nakolko moze byt napr. aj novelizovana...
Potvrdzovanými jednotkami sú síce bajty, ale to neznamená, že pre každý bajt sa pošle potvrdenie (ak dátová veľkosť paketu nie je rovná 1). Napr. keď príde paket s 500 bajtami, tak nasledujúce potvrdenie potvrdí všetkých 500 bajtov (ak boli všetky pakety predtým potvrdené). Ak sú bajty xyz v jednom pakete, tak v prípade chyby sa musia opätovne zaslať všetky bajty xyz.
No presne takto som si to doteraz predstavoval ja, ale ten popis v otazke ma celkom zmiatol.
Takže pokud jsou bajty xyz přenáššeny v jednou segmentu (na síťové vrstvě paketu) a dojde k chybě, tak se musí znova poslat všechny bajty xyz. Pokud ovšem jsou bajty xyz posílány každý v jiném segmentu (paketu), tak pokud dojde k chybě pouze v paketu přenášející bajty y, tak se pošlou znova jen bajty yz (ptž protokol TCP kontroluje i správné pořadí, takže nejdříve musí být správně doručeny bajty y a až poté z), x se už znova neposílají?
Jinak díky, že jste mi věnovali nějaký čas, mslím, že mi to pomohlo.
Podla toho ako som ja doteraz chapal TCP je to tak ako to teraz popisujes.
Ak sa stratí paket y a paket z sa prenesie, tak sa paket z nemusí prenášať znova v prípade, že sa vojde do okna. TCP kontroluje správne poradie práve kvôli tomu, že paket z môže byť správne doručený pred paketom y.
Ale ked nedorazi verifikacie packetu y ako sa moze poslat z? Ved predsa musi dojst k odoslaniu y este raz nie? Az potom sa pusti packet z nie?
to právě že ne, zdroj "chrlí" pakety a čeká na odezvy (ACK). Pokud do timeoutu nedorazí ACK, pošle konkrétní pakety, které nebyly přijaty, znova.
Jasne, zabudol som na timeout a bola by blbost keby sa pri kazdom packete cakalo na potvrdenie a az potom by sa odosielali dalsie.