VyÜlo v t²denφku: COMPUTERWORLD
╚φslo:48/92
RoΦnφk:1992
Rubrika/kategorie: Co je Φφm ... v poΦφtaΦov²ch sφtφch
Dφl:53
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 (53):

Protokol IP

V p°edchßzejφcφch dφlech naÜeho serißlu jsme se zab²vali adresami a zp∙sobem adresovßnφ na r∙zn²ch ·rovnφch - tedy fyzick²mi adresami, IP adresami i symbolick²mi jmΘny, a dßle otßzkou sm∞rovßnφ. Nynφ se ji₧ budeme v∞novat konkrΘtnφm mechanism∙m p°enos∙ v TCP/IP sφtφch.

Vra¥me se vÜak jeÜt∞ jednou ke 42. dφlu, ve kterΘm jsme si naznaΦili celkovou filosofii sφ¥ovΘho modelu TCP/IP, a srovnßvali ji s filosofiφ referenΦnφho modelu ISO/OSI. Zde jsme si uvedli, ₧e sφ¥ov² model TCP/IP vychßzφ z p°edpokladu, ₧e zajiÜt∞nφ spolehlivosti p°i p°enosu dat je spφÜe otßzkou koncov²ch ·Φastnφk∙, a nikoli otßzkou komunikaΦnφ podsφt∞. ╪eΦeno jin²mi slovy: sφ¥ov² model TCP/IP za°azuje mechanismy pro zajiÜt∞nφ spolehlivosti p°enos∙ a₧ do vrstvy transportnφ, a nikoli do vrstvy sφ¥ovΘ (resp. tzv. IP vrstvy). Od tΘto vrstvy oΦekßvß pouze jednoduchou p°enosovou slu₧bu nespojovanΘho (connectionless) charakteru, kterß by sice nem∞la samovoln∞ ztrßcet p°enßÜenΘ pakety, ale na druhΘ stran∞ zase nenφ povinna podnikat ₧ßdnΘ nßpravnΘ akce v p°φpad∞, ₧e se n∞kter² paket skuteΦn∞
Obrßzek 53.1.
Obr. 53.1.: Slu₧by, poskytovanΘ na jednotliv²ch ·rovnφch sφ¥ovΘho modelu TCP/IP
ztratφ, nebo kdy₧ jej tato vrstva nenφ z objektivnφch d∙vod∙ schopna doruΦit - nap°φklad kv∙li p°epln∞n²m vyrovnßvacφm pam∞tem, kv∙li v²padku spojenφ atd. Takovouto nespolehlivou nespojovanou slu₧bu vÜak musφ sφ¥ovß vrstva poskytovat jednotn²m zp∙sobem v rßmci celΘ soustavy vzßjemn∞ propojen²ch sφtφ (tj. v rßmci celΘho internetu, s mal²m "i"), bez ohledu na to, zda jsou data ve skuteΦnosti p°enßÜena po lokßlnφ sφti typu Ethernet, po dvoubodovΘm spoji, ve°ejnou datovou sφtφ Φi jin²m zp∙sobem.

Nad touto nespolehlivou nespojovanou p°enosovou slu₧bou na ·rovni sφ¥ovΘ vrstvy pak TCP/IP model buduje spolehlivou transportnφ slu₧bu, a nad nφ pak r∙znΘ druhy aplikaΦnφch slu₧eb - viz obrßzek 53.1.

IP, neboli Internet Protocol

V∞nujme se nynφ zp∙sobu, jak²m je v TCP/IP modelu implementovßna v²Üe zmφn∞nß nespolehlivß a nespojovanß p°enosovß slu₧ba na ·rovni sφ¥ovΘ vrstvy. Definuje ji protokol, kter² se pln²m jmΘnem naz²vß Internet Protocol, ale nejΦast∞ji je oznaΦovßn zkratkou IP.

Obrßzek 53.2.
Obr. 53.2.: P°edstava IP datagram∙ a datov²ch rßmc∙
IP protokol definuje zßkladnφ jednotku dat, kterß je soustavou TCP/IP sφtφ p°enßÜena na ·rovni sφ¥ovΘ vrstvy, tzv. Internet datagram, zkrßcen∞ IP datagram, a jeho p°esn² vnit°nφ formßt. Definuje takΘ zp∙sob, jak²m majφ b²t jednotlivΘ IP datagramy sm∞rovßny, a toto sm∞rovßnφ pak p°φsluÜn² IP software takΘ zajiÜ¥uje. Krom∞ toho IP protokol takΘ podrobn∞ji definuje i dalÜφ aspekty poskytovanΘ nespolehlivΘ a nespojovanΘ p°enosovΘ slu₧by - nap°φklad podmφnky, za jak²ch mohou b²t p°enßÜenΘ pakety zahazovßny, kdy majφ b²t generovßna chybovß hlßÜenφ a jakß tato hlßÜenφ majφ b²t.

IP datagram a jeho formßt

Podobn∞ jako ka₧d² jin² druh paketu Φi rßmce, mß i IP datagram dv∞ zßkladnφ Φßsti: °φdφcφ Φßst, tvo°enou hlaviΦkou datagramu, a datovou Φßst. Jak naznaΦuje obrßzek 53.2., p°i vlastnφm p°enosu se tento datagram vklßdß (jako data) do datovΘ Φßsti rßmce, se kter²m pracuje bezprost°edn∞ ni₧Üφ
Obrßzek 53.3.
Obr. 53.3.: Formßt hlaviΦky IP datagramu
vrstva - vrstva sφ¥ovΘho rozhranφ. V hlaviΦce jsou pak r∙znΘ °φdφcφ informace, pot°ebnΘ pro doruΦenφ datagramu resp. rßmce - v p°φpad∞ hlaviΦky rßmce jde mj. o fyzickou adresu skuteΦnΘho odesilatele a bezprost°ednφho p°φjemce, zatφmco v hlaviΦce IP datagramu jde o IP adresy koncovΘho p°φjemce a p∙vodnφho odesilatele. Jeliko₧ v datovΘm rßmci mohou b²t v principu p°enßÜeny i jinΘ druhy paket∙, musφ zde b²t vyjßd°eno takΘ to, o jak² konkrΘtnφ druh paketu se v danΘm p°φpad∞ jednß (nap°φklad v sφtφch typu Ethernet se druh paketu udßvß pomocφ dvoubytovΘ polo₧ky v hlaviΦce rßmce, a IP datagramy zde majφ vyhrazen k≤d 0800H). Podobn∞ je tomu i na ·rovni paketu, resp. IP datagramu - takΘ v jeho hlaviΦce musφ b²t vyjßd°eno, jak² je v²znam obsahu datovΘ Φßsti. V p°φpad∞ IP datagramu jde o jednobytovou polo₧ku, udßvßjφcφ Φφslo protokolu na ·rovni transportnφ vrstvy, kterΘmu obsah IP datagramu pat°φ (polo₧ka PROTOCOL, viz obr. 53.3.).

Maximßlnφ dΘlka IP datagramu

KonkrΘtnφ formßt hlaviΦky IP datagramu ukazuje obrßzek 53.3. Za zmφnku stojφ nap°φklad velikost polo₧ky TOTAL LENGTH, kterß udßvß celkovou dΘlku IP datagramu (tj. jeho hlaviΦky i datovΘ Φßsti), m∞°enou v oktetech (tj. v osmibitov²ch bytech). Jeliko₧ tato polo₧ka mß rozsah 16 bit∙, omezuje tφm maximßlnφ mo₧nou velikost IP datagramu na 65 535 oktet∙.

Doba ₧ivota

DalÜφ zajφmavou polo₧kou je jednobytovß polo₧ka TIME TO LIVE. Ta udßvß, jak dlouho (m∞°eno v sekundßch) se dan² IP datagram m∙₧e nachßzet v soustav∞ vzßjemn∞ propojen²ch sφtφ. Tato polo₧ka je jakousi pojistkou proti nekonzistentnostem ve sm∞rovacφch tabulkßch, dφky kter²m by mohlo dojφt k situaci, ₧e by IP datagram byl sm∞rovßn v kruhu, a obφhal v n∞m nekoneΦn∞ dlouho. Tomu zabra≥uje prßv∞ tato polo₧ka, jejφ₧ obsah je ka₧dß mezilehlß brßna povinna sni₧ovat podle toho, jak dlouho se v nφ p°φsluÜn² datagram "zdr₧φ". Jakmile dojde k vynulovßnφ polo₧ky TIME TO LIVE (doslova: doba ₧ivota), je podle pravidel IP protokolu brßna oprßvn∞na dan² IP datagram zahodit.

Fragmentace datagram∙

SkuteΦnost, ₧e IP protokol musφ b²t schopen p°enßÜet svΘ datagramy prost°ednictvφm r∙zn²ch druh∙ p°enosov²ch cest, mß n∞kterΘ v²znamnΘ d∙sledky. Nap°φklad velikost datov²ch rßmc∙, p°enßÜen²ch na ·rovni vrstvy sφ¥ovΘho rozhranφ TCP/IP modelu, je zßvislß na konkrΘtnφ p°enosovΘ technologii, pomocφ kterΘ je danß dφlΦφ sφ¥ realizovßna. V p°φpad∞ lokßlnφch sφtφ typu Ethernet je to 1500 oktet∙, zatφmco nap°φklad sφt∞ Token Bus p°ipouÜtφ rßmce a₧ do velikosti 8191 oktet∙, a ve°ejnΘ datovΘ sφt∞ na bßzi doporuΦenφ X.25 pracujφ s rßmci a₧ do velikosti 4096 oktet∙. N∞kterΘ modernφ p°enosovΘ technologie vÜak pracujφ s mnohem menÜφmi rßmci - nap°φklad jen 128 oktet∙ Φi jeÜt∞ mΘn∞. Protokol IP se ale dost dob°e nem∙₧e p°izp∙sobit nejmenÜφmu mo₧nΘmu formßtu rßmce, aby do n∞j mohl v₧dy vlo₧it sv∙j IP datagram cel². Proto musφ poΦφtat s mo₧nostφ fragmentace (viz tΘ₧ 41. dφl naÜeho serißlu), p°i kterΘ pro pot°eby p°enosu dochßzφ k rozd∞lenφ p∙vodnφho datagramu na n∞kolik dφlΦφch fragment∙ - tak velk²ch, aby se ji₧ veÜly celΘ do t∞ch rßmc∙, kterΘ je p°φsluÜnß sφ¥ schopna skuteΦn∞ p°enΘst - viz obr. 53.4. Jak jsme si ji₧ takΘ naznaΦili ve 41. dφlu, jde p°itom o tzv. netransparentnφ fragmentaci, p°i kterΘ jednotlivΘ fragmenty sklßdß do p∙vodnφho celku a₧ jejich koncov² p°φjemce. Ten pak k tomu vyu₧φvß polo₧ky IDENTIFICATION, FLAGS a FRAGMENT OFFSET jednotliv²ch fragment∙.

NepovinnΘ Φßsti IP datagram∙

Obrßzek 53.4.
Obr. 53.4.: P°edstava fragmentace
Polo₧ka IP Options, kterß v hlaviΦce IP datagramu nßsleduje IP adresu koneΦnΘho adresßta, je polo₧kou nepovinnou. Je urΦena p°edevÜφm pro pot°eby testovßnφ a lad∞nφ. Pomocφ tΘto polo₧ky, kterß mß prom∞nnou dΘlku, je nap°φklad mo₧nΘ zaznamenßvat cestu, kterou je p°φsluÜn² datagram postupn∞ p°enßÜen - co₧ je neocenitelnΘ zvlßÜt∞ pro pot°eby sprßvy sφtφ. Krom∞ IP adres bran, kter²mi datagram postupn∞ prochßzφ, je mo₧nΘ v tΘto polo₧ce zaznamenßvat i Φas, kdy datagram jednotliv²mi brßnami prochßzφ. DalÜφm mechanismem, velmi u₧iteΦn²m pro sprßvu vzßjemn∞ propojen²ch sφtφ, je pak mo₧nost explicitn∞ p°edepsat v tΘto polo₧ce trasu, kterou mß b²t IP datagram doruΦen.
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