VyÜlo v t²denφku: COMPUTERWORLD
╚φslo:5/93
RoΦnφk:1993
Rubrika/kategorie: Co je Φφm ... v poΦφtaΦov²ch sφtφch
Dφl:57

zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl

Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (57):

Protokol TCP - I.

╪ekne-li se dnes TCP/IP, mnoho lidφ si pod tφm p°edstavφ dvojici protokol∙: TCP (Transmission Control Protocol) a IP (Internet Protocol). Z naÜeho dosavadnφho povφdßnφ o poΦφtaΦov²ch sφtφch vÜak ji₧ vφme, ₧e ve skuteΦnosti jde o celou soustavu protokol∙ (anglicky: protocol suite), spojenou s vlastnφ soustavou nßzor∙ na to, jak by poΦφtaΦovΘ sφt∞ m∞ly vypadat a jak by m∞ly fungovat - tedy to, co jsme si ji₧ d°φve oznaΦili jako sφ¥ovou architekturu Φi sφ¥ov² model. Protokol TCP je tedy jen jednφm z vφce protokol∙ soustavy TCP/IP, i kdy₧ protokolem velmi v²znamn²m. Dnes se u n∞j zastavφme podrobn∞ji.

Nejprve si ale znovu p°ipome≥me, ₧e protokol TCP je protokolem transportnφ vrstvy, a ₧e je jednφm ze dvou alternativnφch protokol∙, kterΘ sφ¥ov² model TCP/IP na ·rovni tΘto vrstvy nabφzφ. P°ipome≥me si takΘ d∙vod tΘto nabφdky dvou alternativnφch protokol∙: jednotlivΘ aplikace majφ mo₧nost si vybrat, zda je pro n∞ v²hodn∞jÜφ pou₧φvat na ·rovni transportnφ vrstvy nespolehlivΘ (ale rychlejÜφ) p°enosovΘ slu₧by, zajiÜ¥ovanΘ protokolem UDP (User Datagram Protocol), nebo naopak pomalejÜφ, zato ale spolehlivΘ slu₧by protokolu TCP. V minulΘm dφlu naÜeho serißlu jsme se podrobn∞ji zab²vali protokolem UDP a naznaΦili jsme si, ₧e je vlastn∞ jen jednoduchou obßlkou nad p°enosov²mi slu₧bami sφ¥ovΘ vrstvy, kterß nijak nem∞nφ jejich kvalitu (tj. nespolehlivost) ani povahu (nespojovan² charakter), a pouze je zp°φstup≥uje entitßm aplikaΦnφ vrstvy. ┌kol protokolu TCP je z tohoto pohledu mnohem nßroΦn∞jÜφ - k dispozici mß stejnΘ nespolehlivΘ slu₧by na ·rovni sφ¥ovΘ vrstvy, ale s jejich pomocφ musφ sßm zajiÜ¥ovat slu₧by spolehlivΘ.

DalÜφ v²znamn² rozdφl mezi protokoly UDP a TCP spoΦφvß v tom, ₧e zatφmco UDP nabφzφ nespojovanΘ (connectionless) slu₧by, protokol TCP nabφzφ svΘ p°enosovΘ slu₧by jako spojovanΘ (connection-oriented). P°ed ka₧dou v²m∞nou dat mezi dv∞ma uzly tedy musφ b²t nejprve navßzßno spojenφ, a po skonΦenφ p°enosu musφ b²t toto spojenφ zase zruÜeno. V²hodami i nev²hodami spojovan²ch a nespojovan²ch slu₧eb jsme se zab²vali ji₧ ve 27. dφlu naÜeho serißlu.

Stream, neboli proud

DalÜφm v²znamn²m rozdφlem mezi p°enosov²mi slu₧bami protokol∙ TCP a UDP je takΘ jejich pohled na p°enßÜenß data. Jak jsme si ji₧ naznaΦili minule, protokol UDP oΦekßvß od svΘ bezprost°edn∞ vyÜÜφ vrstvy v₧dy cel² blok dat, kter² se sna₧φ p°enΘst op∞t jako celek (v rßmci jedinΘho tzv. u₧ivatelskΘho datagramu, viz minule), a na stran∞ p°φjemce jej p°edßvß svΘ bezprost°edn∞ vyÜÜφ vrstv∞ op∞t jako celek.

Naproti tomu protokol TCP se sna₧φ nabφzet svΘ bezprost°edn∞ vyÜÜφ vrstv∞ p°enos jednotliv²ch byt∙. OΦekßvß tedy, ₧e entity aplikaΦnφ vrstvy mu na stran∞ odesilatele budou postupn∞ p°edßvat jednotlivΘ byty (p°esn∞ji: osmibitovΘ oktety), a na stran∞ p°φjemce si je zase budou po jednom vyzvedßvat. Tφm vznikß iluze proudu (anglicky: stream) jednotliv²ch byt∙, kter² navφc nenφ nijak strukturovßn - tj. vÜechny p°enßÜenΘ byty jsou pova₧ovßny za rovnocennΘ. Ve skuteΦnosti samoz°ejm∞ nejsou jednotlivΘ bity p°enßÜeny ka₧d² zvlßÜ¥. Protokol TCP na stran∞ odesilatele postupn∞ akumuluje jednotlivΘ byty do vhodnΘ vyrovnßvacφ pam∞ti (bufferu), a po jejφm napln∞nφ odeÜle cel² jejφ obsah najednou - v tzv. segmentu, jak se naz²vß blok, p°enßÜen² protokolem TCP. Analogicky na stran∞ p°φjemce, kde se datov² obsah segmentu uklßdß do vyrovnßvacφ pam∞ti, a jednotlivΘ byty jsou entitßm aplikaΦnφ vrstvy poskytovßny z tΘto vyrovnßvacφ pam∞ti. Cel² mechanismus sdru₧ovßnφ jednotliv²ch byt∙ do blok∙ je pln∞ v re₧ii protokolu TCP, kter² se p°enosem v∞tÜφch celk∙ sna₧φ optimalizovat vyu₧itφ p°enosov²ch cest. Pro vyÜÜφ vrstvu je tento mechanismus neviditeln² - vyÜφ vrstva pracuje s p°edstavou proudu jednotliv²ch byt∙.

Existujφ vÜak takovΘ aplikace, pro kterΘ prßv∞ naznaΦen² mechanismus nenφ p°φliÜ vhodn². P°φkladem mohou b²t tzv. vzdßlenΘ terminßlovΘ relace, uskuteΦ≥ovanΘ prost°ednictvφm sφt∞ - kdy jeden uzlov² poΦφtaΦ vystupuje v roli terminßlu jinΘho poΦφtaΦe a jednotlivΘ znaky, zadanΘ z jeho klßvesnice, posφlß ke zpracovßnφ tomuto druhΘmu poΦφtaΦi (kter² mu zase posφlß zp∞t vÜe, co mß b²t zobrazeno na obrazovce terminßlu). Kdyby v takovΘto situaci protokol TCP Φekal, a₧ vstupnφ znaky naplnφ vyrovnßvacφ pam∞¥ na stran∞ odesilatele a teprve pak je skuteΦn∞ odeslal, u₧ivatel by hodn∞ dlouho maΦkal klßvesy bez jakΘkoli odezvy. Protokol TCP vÜak i s tφmto poΦφtß, a nabφzφ odesilateli mechanismus (oznaΦovan² jako push), kter²m si aplikace m∙₧e vynutit skuteΦnΘ odeslßnφ dat i v p°φpad∞, ₧e p°φsluÜnß vyrovnßvacφ pam∞¥ nenφ jeÜt∞ napln∞na.

Jak se dosahuje spolehlivost

Ji₧ ve 30. dφlu serißlu jsme si naznaΦili, ₧e prakticky jedinou mo₧nostφ, jak pomocφ nespolehlivΘ p°enosovΘ slu₧by zajistit spolehlivΘ p°enosy, je umo₧nit p°φjemci rozpoznat chybn∞ p°enesen² blok, a vy₧ßdat si jeho op∞tovnΘ vyslßnφ.

Obrßzek 57.1.
Obr. 57.1.: P°edstava potvrzovßnφ v protokolu TCP
Ukßzali jsme si takΘ, ₧e za tφmto ·Φelem se pou₧φvß vφce r∙zn²ch zp∙sob∙ tzv. potvrzovßnφ (acknowledgement), viz op∞t 30. dφl. Protokol TCP pou₧φvß tzv. kladnΘ potvrzovßnφ (positive acknowledgement), co₧ znamenß, ₧e potvrzuje ·sp∞Ün∞ p°ijatß data, a na chybn∞ p°ijatß data nereaguje nijak (ty pak odesilatel znovu vyÜle na zßklad∞ vyprÜenφ ΦasovΘho limitu, ve kterΘm oΦekßval jejich kladnΘ potvrzenφ). Ve svΘ zßkladnφ podob∞ tzv. jednotlivΘho kladnΘho potvrzovßnφ (stop&wait positive acknowledgement), kdy odesilatel p°ed odeslßnφm ka₧dΘho dalÜφho bloku Φekß na kladnΘ potvrzenφ naposledy vyslanΘho bloku, je tento mechanismus znaΦn∞ neefektivnφ. Protokol TCP proto pou₧φvß kladnΘ potvrzovßnφ ve variant∞ tzv. kontinußlnφho potvrzovßnφ (continuous acknowledgement), znßmΘho tΘ₧ jako tzv. metoda okΘnka (sliding window). Podstata tΘto varianty spoΦφvß v tom, ₧e odesilatel m∙₧e odeslat dalÜφ blok (resp. n∞kolik dalÜφch blok∙) jeÜt∞ d°φve, ne₧ dostane potvrzenφ o p°ijetφ bloku p°edchozφho. O tom, kolik blok∙ m∙₧e takto vyslat "dop°edu", rozhoduje velikost pomyslnΘho okΘnka (viz obr. 30.4. ve 30. dφlu).

Kdy₧ jsme se ve 30. dφlu zab²vali r∙zn²mi metodami potvrzovßnφ, p°edpoklßdali jsme, ₧e potvrzovan²mi jednotkami jsou celΘ bloky dat. V p°φpad∞ protokolu TCP se p°enßÜenΘ bloky dat oznaΦujφ jako segmenty, a mohou mφt r∙znou dΘlku. V p°φpad∞, ₧e n∞kter² segment nenφ p°enesen bezchybn∞ (resp. nenφ kladn∞ potvrzen do vyprÜenφ ΦasovΘho limitu), je jeho obsah vyslßn znovu, a po n∞m takΘ obsah vÜech nßsledujφcφch segment∙. Jde tedy o tzv. opakovßnφ s nßvratem (Go-Back-N), viz op∞t 30. dφl. PodstatnΘ ale je, ₧e p°i tomto opakovanΘm vysφlßnφ ji₧ jednou vyslan²ch dat nemusφ b²t dodr₧eny p∙vodnφ velikosti segment∙ - znovu vyslan² segment m∙₧e b²t v∞tÜφ ne₧ segment, vyslan² p∙vodn∞. To ale Φinφ potvrzovßnφ cel²ch segment∙ problematickΘ. Proto jsou v protokolu TCP potvrzovan²mi jednotkami dat nikoli celΘ bloky (segmenty), ale jednotlivΘ byty (p°esn∞ji: oktety)!!

KonkrΘtnφ zp∙sob implementace potvrzovßnφ v protokolu TCP vyu₧φvß pln∞ duplexnφho charakteru spojenφ na ·rovni transportnφ vrstvy. Jak naznaΦuje obrßzek 57.1., ka₧d² segment obsahuje krom∞ vlastnφch dat i ·daj o pozici prvnφho bytu t∞chto dat v rßmci celΘho proudu byt∙ (tzv. sequence number). S vyu₧itφm tohoto ·daje pak p°φjemce p∙vodnφ proud byt∙ rekonstruuje. Jednotlivß kladnß potvrzenφ se op∞t vztahujφ k cel²m byt∙m, a jsou vklßdßna do segment∙, p°enßÜen²ch v opaΦnΘm sm∞ru, ne₧ potvrzovanß data. Jde tedy o tzv. nesamostatnΘ potvrzovßnφ (anglicky: piggybacking), viz 30. dφl. KladnΘ potvrzenφ mß p°itom formu Φφsla pozice prvnφho bytu (v rßmci proudu), kter² p°φjemce oΦekßvß jako dalÜφ (tj. prvnφho bytu za poslednφm ·sp∞Ün∞ p°ijat²m) - jde o tzv. acknowledgement number.


zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl
Tento Φlßnek m∙₧e b²t voln∞ Üφ°en, pokud se tak d∞je pro studijnφ ·Φely, na nev²d∞leΦnΘm zßklad∞ a se zachovßnφm tohoto dov∞tku. Podrobnosti hledejte zde, resp. na adrese http://archiv.czech.net/copyleft.htm