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

Protokol TCP - IV.

Obr. 60.1.: Formßt TCP segmentu

Nejprve si ale p°ipome≥me (v souladu s 57. dφlem), ₧e bloky dat, p°enßÜenΘ protokolem TCP jako celek, se oznaΦujφ jako segmenty (segments), zatφmco v p°φpad∞ alternativnφho protokolu UDP jde o tzv. u₧ivatelskΘ datagramy (user datagrams). V obou p°φpadech je p°enßÜen² datov² blok tvo°en dv∞ma hlavnφmi Φßstmi: hlaviΦkou (header) a vlastnφmi daty. Zatφmco ale v p°φpad∞ protokolu UDP staΦφ, kdy₧ hlaviΦka krom∞ zabezpeΦovacφho ·daje a p°φznaku dΘlky obsahuje ji₧ jen ·daj o portu koncovΘho p°φjemce a odesilatele (viz obr. 56.2 v 56. dφlu), hlaviΦka TCP segmentu musφ b²t obsa₧n∞jÜφ - jak je ostatn∞ mo₧nΘ oΦekßvat v p°φpad∞ v²razn∞ slo₧it∞jÜφho p°enosovΘho protokolu. P°esn² formßt segmentu protokolu TCP ukazuje obrßzek 60.1.

╚φm je urΦeno spojenφ

Co je ale koncov²m a poΦßteΦnφm bodem spojenφ v p°φpad∞ protokolu TCP? IP adresa p°φjemce a odesilatele nestaΦφ, nebo¥ ta jednoznaΦn∞ identifikuje pouze uzlov² poΦφtaΦ, a nikoli ji₧ konkrΘtnφ entitu aplikaΦnφ vrstvy v rßmci danΘho uzlu. Obdobn∞ nenφ samo o sob∞ dostateΦnΘ ani Φφslo portu (viz 55. dφl), kterΘ zase identifikuje aplikaΦnφ entitu v rßmci danΘho poΦφtaΦe. PoΦßteΦnφ (a stejn∞ tak i koncov²) bod spojenφ m∙₧e b²t urΦen a₧ dvojicφ <IP adresa, Φφslo portu>.

Obr. 60.2.: TCP segment a jeho pseudohlaviΦka

Jak ovÜem vypl²vß z obrßzku 60.1., v TCP segmentu jsou vyjßd°eny pouze Φφsla port∙ odesilatele a p°φjemce. Pot°ebnΘ IP adresy jsou pak, obdobn∞ jako v p°φpad∞ protokolu UDP, souΦßstφ tzv. pseudohlaviΦky (viz obr. 60.2), kterß je shodnß s pseudohlaviΦkou protokolu UDP (samoz°ejm∞ a₧ na obsah pole PROTO, kterΘ identifikuje transportnφ protokol, a pro TCP mß hodnotu 6). Stejn² jako u protokolu UDP je i v²znam pseudohlaviΦky a zp∙sob jejφho vyu₧itφ - je zahrnuta do v²poΦtu kontrolnφho souΦtu (polo₧ka CHECKSUM v TCP segmentu), ale ve skuteΦnosti p°enßÜena nenφ. Obsah jednotliv²ch polo₧ek (p°edevÜφm pak ob∞ IP adresy) dostßvß transportnφ vrstva na stran∞ p°φjemce od vrstvy sφ¥ovΘ - stejn²m zp∙sobem, kter² jsme si popisovali ji₧ v 56. dφlu.

KladnΘ potvrzovßnφ

Je dobrΘ si uv∞domit, ke kterΘmu sm∞ru p°enosu se obsah t°φ prßv∞ uveden²ch polo₧ek vztahuje. Uva₧ujeme-li segment, sm∞°ujφcφ od uzlu A do uzlu B, t²kß se jeho polo₧ka SEQUENCE NUMBER p°enosu v tΘm₧e sm∞ru (tj. od A do B), zatφmco potvrzenφ v polo₧ce ACKNOWLEDGEMENT NUMBER se vztahuje k p°enosu dat v opaΦnΘm sm∞ru (tj. od B do A). Stejn∞ tak se i obsah polo₧ky WINDOW t²kß p°enosu dat v opaΦnΘm sm∞ru (od B do A).

NalΘhavß data

Protokol TCP vÜak prßv∞ pro tyto ·Φely nabφzφ mo₧nost "p°edbφhßnφ", dovolujφcφ vyslat p°φsluÜnΘ povely jako tzv. nalΘhavß data (urgent data), n∞kdy oznaΦovanß tΘ₧ jako data mimo po°adφ (out-of-band data). P°φznak toho, ₧e dan² segment obsahuje nalΘhavß data, je vyjßd°en nastavenφm p°φsluÜnΘho bitu v polo₧ce CODE BITS. Vlastnφ nalΘhavß data pak musφ b²t umφst∞na od zaΦßtku datovΘ Φßsti segmentu, a v polo₧ce URGENT POINTER je ukazatel na jejich konec v rßmci danΘho segmentu.

Po doruΦenφ nalΘhav²ch dat by m∞l b²t koncov² p°φjemce neprodlen∞ upozorn∞n na jejich existenci. Samotn² protokol TCP vÜak ji₧ nestanovuje, jak²m zp∙sobem se tak mß dφt. Ostatn∞ ani dost dob°e nem∙₧e, nebo¥ p°φsluÜn² mechanismus zßvisφ na konkrΘtnφ implementaci.

DalÜφ °φdφcφ bity v ÜestibitovΘ polo₧ce CODE BITS pak slou₧φ mj. pot°ebßm navazovßnφ a ruÜenφ spojenφ, operaci push (viz 57. dφl), umo₧≥ujφ zneplatnit polo₧ku ACKNOWLEDGEMENT NUMBER atd.

Segment ani jeho hlaviΦka nemajφ pevnou dΘlku

Otßzkou ovÜem je, jak volit optimßlnφ velikost segmentu. Zde je nutnΘ si uv∞domit, ₧e jednotlivΘ segmenty jsou vklßdßny do IP datagram∙, a ty zase do rßmc∙ (na ·rovni rßmc∙ vrstvy sφ¥ovΘho rozhranφ) - ka₧d² z nich si ale k "u₧iteΦn²m" dat∙m p°idßvß svß °φdφcφ data, kterß p°edstavujφ re₧ii p°enosu. V p°φpad∞ mal²ch segment∙ je tato re₧ie relativn∞ velkß, zatφmco v p°φpad∞ velk²ch segment∙ dochßzφ k fragmentaci, kdy₧ nelze umφstit celΘ segmenty resp. IP datagramy do p°enosov²ch rßmc∙. Optimßlnφ by byl co nejv∞tÜφ segment, p°i kterΘm jeÜt∞ nebude dochßzet k ₧ßdnΘ fragmentaci. Najφt jeho velikost je ale velmi netrivißlnφ (tato velikost toti₧ zßvisφ na mnoha faktorech, kterΘ se navφc mohou dynamicky m∞nit). Samotn² protokol TCP neobsahuje ₧ßdn² mechanismus pro nalezenφ optimßlnφ velikosti segmentu.

Co vÜak protokol TCP nabφzφ, je prost°edek, pomocφ kterΘho se ob∞ strany mohou dohodnout alespo≥ na maximßlnφ velikosti p°enßÜen²ch segment∙. Implicitn∞ pou₧φvß TCP maximum, kterΘ odpovφdß datovΘ Φßsti segmentu o velikosti 536 byt∙ (tak, aby se segment vΦetn∞ svΘ obvyklΘ hlaviΦky veÜel do IP datagramu implicitnφ velikosti 576 byt∙). Tato implicitnφ hodnota je zalo₧ena spφÜe na pesimistickΘm p°edpokladu, ₧e spojenφ mezi ob∞ma koncov²mi ·Φastnφky nenφ p°φmΘ, ale vede p°es jednu Φi n∞kolik bran, a mß malou propustnost. Pokud jsou vÜak oba koncovφ ·Φastnφci p°ipojeni nap°φklad k tΘmu₧ segmentu rychlΘ lokßlnφ sφt∞, je jist∞ ₧ßdoucφ, aby pln∞ vyu₧φvali jejφ v∞tÜφ Üφ°ku p°enosovΘho pßsma a jejφ schopnost p°enßÜet najednou v∞tÜφ bloky dat. Tedy volit v∞tÜφ maximßlnφ velikost segment∙.

KonkrΘtnφ mechanismus pro stanovenφ maximßlnφ velikosti segmentu vyu₧φvß volitelnΘ polo₧ky OPTIONS v hlaviΦce segmentu (viz obr. 60.1.). Je-li ovÜem tato polo₧ka volitelnß, stejn∞ tak jako je prom∞nnß jejφ dΘlka, nem∙₧e mφt pevnou dΘlku ani samotnß hlaviΦka TCP segmentu. KonkrΘtnφ velikost hlaviΦky (rozÜφ°enΘ v²plnφ ze sam²ch nul na nßsobek 16 bit∙) je pak vyjßd°ena v polo₧ce HLEN.