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 (45):
Adresovßnφ v TCP/IP sφtφch - II.
V minulΘm dφlu naÜeho serißlu jsme se podrobn∞ji
zab²vali IP adresami. Vφme ji₧, ₧e p°edstavujφ jednotnΘ
adresy, kterΘ pou₧φvß libovoln² konglomerßt vzßjemn∞
propojen²ch sφtφ na bßzi soustavy protokol∙ TCP/IP. Jsou
vÜak stßle jen abstrakcφ na ·rovni sφ¥ovΘ vrstvy, kterß
odpovφdß p°edstav∞ jednotnΘ virtußlnφ sφt∞. Ta je ale ve
skuteΦnosti realizovßna dφlΦφmi sφt∞mi vφce Φi mΘn∞
odliÜnΘho typu, kterΘ pou₧φvajφ svΘ vlastnφ mechanismy
adresovßnφ a formßty adres. Proto takΘ IP adresy musφ b²t
p°evßd∞ny na takovΘ konkrΘtnφ (fyzickΘ) adresy, jakΘ
p°φsluÜnß dφlΦφ sφ¥ skuteΦn∞ pou₧φvß (na ·rovni vrstvy
sφ¥ovΘho rozhranφ). Otßzkou ovÜem je, jak takov²to p°evod
v∙bec realizovat.
P°edstavme si dva hostitelskΘ poΦφtaΦe A a B, kterΘ
majφ po °ad∞ IP adresy IA a IB. P°edpoklßdejme dßle, ₧e jde
o uzly tΘ₧e (dφlΦφ) sφt∞, kterΘ dφky tomu mohou komunikovat
mezi sebou p°φmo (resp. nejsou odkßzßny na brßnu, resp. IP
sm∞rovaΦ, propojujφcφ r∙znΘ dφlΦφ sφt∞). V rßmci "svΘ" dφlΦφ
sφt∞ p°itom majφ oba uzly fyzickΘ adresy FA a FB. Jestli₧e
nynφ sφ¥ovß vrstva (IP vrstva) poΦφtaΦe A dostane od svΘ
transportnφ vrstvy za ·kol p°enΘst urΦitß data poΦφtaΦi s IP
adresou IB(tj. poΦφtaΦi B), musφ b²t schopna zajistit
p°evod IP adresy IB na fyzickou adresu FB. Tu toti₧
pot°ebuje p°φsluÜn² ovladaΦ v bezprost°edn∞ ni₧Üφ vrstv∞
(vrstv∞ sφ¥ovΘho rozhranφ), aby mohl p°enßÜenß data skuteΦn∞
doruΦit. Podobn∞ poΦφtaΦ B: jakmile bude chtφt poΦφtaΦi
A odpov∞d∞t, musφ v∞d∞t, jakß fyzickß adresa (FA) odpovφdß
IP adrese poΦφtaΦe A (IA).
ProblΘm transformace adres a jeho °eÜenφ
ProblΘm transformace adres vyÜÜφ ·rovn∞ na adresy ni₧Üφ
·rovn∞, konkrΘtn∞ nalezenφ odpovφdajφcφ fyzickΘ adresy k IP
adrese, se oznaΦuje jako address resolution problem. Je
mo₧nΘ jej °eÜit nap°φklad formou tabulky, obsahujφcφ seznam
vzßjemn∞ si odpovφdajφcφch adres. Je to ovÜem spojeno
s Φetn²mi problΘmy - kdo a jak zajistφ poΦßteΦnφ napln∞nφ
tabulky, kdo ji bude udr₧ovat a p°izp∙sobovat momentßlnφmu
stavu sφt∞, kdo zajistφ, aby jejφ velikost nep°esßhla
·nosnou mez atd.
Tam, kde je to jen trochu mo₧nΘ, se proto pou₧φvajφ
spφÜe jinß °eÜenφ, kterß jsou ovÜem zßvislß na konkrΘtnφ
povaze (dφlΦφ) sφt∞ a jφm pou₧φvanΘm mechanismu adresovßnφ.
╪eÜenφ pomocφ p°φmΘho p°evodu
Velmi jednoduchß myÜlenka, kterΘ se v tΘto souvislosti
sama nabφzφ, je ne°eÜit p°evod v²Φtem (tj. pomocφ tabulky),
ale pomocφ vhodnΘ tranformaΦnφ funkce (vzoreΦku pro p°evod).
To je ale mo₧nΘ jen tam, kde si u₧ivatel resp. z°izovatel
sφt∞ m∙₧e fyzickΘ adresy jednotliv²ch uzlov²ch poΦφtaΦ∙
volit sßm, podle vlastnφch pot°eb. Tak je tomu nap°φklad v
sφtφch ARCnet Φi proNET-10, kde si u₧ivatel p°i instalaci
sφ¥ovΘ karty do svΘho poΦφtaΦe sßm volφ jejφ fyzickou adresu
(a tφm i fyzickou adresu poΦφtaΦe, p°ipojenΘho
prost°ednictvφm tΘto sφ¥ovΘ karty). Mß-li nap°φklad
volitelnß fyzickß adresa rozsah 8 bit∙ (jako je tomu prßv∞
u sφtφ ARCnet i proNET-10), je nejjednoduÜÜφ volit ji shodn∞
s poslednφm oktetem (poslednφmi osmi bity) IP adresy.
Transformace IP adresy na fyzickou se pak stßvß zcela
trivißlnφ.
╪eÜenφ pomocφ dynamickΘ vazby
Mo₧nost volit fyzickou adresu p°φmo na sφ¥ovΘm adaptΘru
p°i jeho instalaci je v praxi ·nosnß jen pro adresy malΘho
rozsahu. P°edevÜφm je ale spojena s potencißlnφm nebezpeΦφm
lidsk²ch chyb, kterΘ mohou vy·stit v existenci dvou adaptΘr∙
resp. uzl∙ se stejnou fyzickou adresou v jednΘ sφti. JinΘ
sφ¥ovΘ technologie se proto k celΘmu problΘmu stavφ opaΦn∞
- u₧ivateli nedßvajφ ₧ßdnou mo₧nost ovlivnit fyzickou adresu
sφ¥ovΘho adaptΘru. Ten ji mß v sob∞ jednou prov₧dy pevn∞
zabudovßnu.
Takto je tomu nap°φklad u lokßlnφch sφtφ typu Ethernet.
Ty pou₧φvajφ fyzickΘ adresy v rozsahu 48 bit∙, kterΘ
v p°φsluÜn²ch sφ¥ov²ch adaptΘrech nastavuje p°φmo jejich
v²robce. Aby se zajistila jednoznaΦnost adres i mezi
sφ¥ov²mi adaptΘry r∙zn²ch v²robc∙, musφ si ka₧d² z nich
nechat p°id∞lit urΦit² rozsah adres od centrßlnφ autority,
kterß EthernetovskΘ adresy spravuje (a kterou je v tomto
konkrΘtnφm p°φpad∞ americkΘ sdru₧enφ IEEE).
Jakmile je ale pot°eba transformovat 32-bitovΘ IP
adresy na 48-bitovΘ EthernetovskΘ (Φi jinΘ "velkΘ" adresy,
kterΘ nenφ mo₧nΘ podle pot°eby volit), nezb²vß ne₧ vrßtit se
zp∞t k p°evodnφm tabulkßm, definujφcφm vzßjemnou vazbu mezi
jednotliv²mi adresami. Pokud mo₧no ale nikoli ke statick²m
tabulkßm, ale naopak k tabulkßm dynamick²m, kterΘ se vytvß°φ
a modifikujφ pr∙b∞₧n∞, podle okam₧itΘho stavu sφt∞.
Protokol ARP
V soustav∞ protokol∙ TCP/IP je zahrnut velmi elegantnφ
mechanismus dynamickΘho budovßnφ a udr₧ovßnφ p°evodnφch
tabulek mezi IP adresami a fyzick²mi adresami, zalo₧en² na
protokolu ARP (Address Resolution Protocol). Ten vyu₧φvß
schopnosti vÜesm∞rovΘho vysφlßnφ (tzv. broadcastingu)
v n∞kter²ch sφtφch, kterΘ umo₧≥ujφ adresovat datov² rßmec
vÜem uzl∙m danΘ lokßlnφ (resp. dφlΦφ) sφt∞ souΦasn∞ - bez
nutnosti znßt jejich konkrΘtnφ adresy. Nap°φklad v sφtφch
typu Ethernet lze vyslat datov² rßmec na jednu, p°edem
znßmou specißlnφ adresu, na kterou "slyÜφ" vÜechny sφ¥ovΘ
adaptΘry bez ohledu na svou konkrΘtnφ fyzickou adresu.
Protokol ARP tΘto mo₧nosti vyu₧φvß tak, ₧e si jejφm
prost°ednictvφm nechß najφt majitele p°φsluÜnΘ IP adresy:
 |
Obr. 45.1.: ZjiÜt∞nφ fyzickΘ adresy podle IP adresy (protokol ARP)
P°edstavme si situaci, kdy jeden uzlov² poΦφtaΦ chce
zaslat n∞jakß data jinΘmu poΦφtaΦi v tΘ₧e dφlΦφ sφti. Znß
vÜak pouze jeho IP adresu, nikoli jeho fyzickou adresu.
Protokol ARP prvnφho poΦφtaΦe proto vyu₧ije mo₧nosti
vÜesm∞rovΘho vysφlßnφ, a vÜem uzl∙m danΘ dφlΦφ sφt∞ poÜle
zvlßÜtnφ rßmec resp. paket s dotazem: "Kdo mß IP
adresu■....?" (viz obr. 45.1. a/). Tento rßmec p°ijmou
vÜechny uzly, a vÜechny takΘ vyhodnotφ paket, kter² je v n∞m
obsa₧en. Pouze uzel B vÜak rozpoznß, ₧e obsahuje jemu urΦen²
dotaz, a tak na n∞j odpovφ zaslßnφm svΘ fyzickΘ adresy (op∞t
prost°ednictvφm specißlnφho paketu, jeho₧ formßt definuje
protokol ARP). Ostatnφ uzly p°itom na p∙vodnφ dotaz
neodpovφdajφ - viz obr. 45.1. b/.
Nebylo by ale ·nosnΘ se takov²mto zp∙sobem ptßt p°i
ka₧dΘm jednotlivΘm p°enosu v₧dy znovu. Ka₧d² uzlov² poΦφtaΦ
si proto sßm pr∙b∞₧n∞ vytvß°φ pot°ebnou p°evodnφ tabulku
mezi IP adresami a fyzick²mi adresami (ve vhodnΘ vyrovnßvacφ
pam∞ti), a prßv∞ naznaΦen² mechanismus vyu₧φvß a₧ v p°φpad∞,
kdy ji pot°ebuje doplnit Φi aktualizovat.
Protokol RARP
Protokol ARP umo₧≥uje, aby ka₧d² hostitelsk² poΦφtaΦ
(uzel) po svΘm spuÜt∞nφ vystaΦil jen se znalostφ svΘ vlastnφ
fyzickΘ adresy a svΘ vlastnφ IP adresy (kterou si obvykle
p°eΦte z konfiguraΦnφho souboru na svΘm pevnΘm disku). Na
fyzickΘ adresy vÜech ostatnφch uzl∙ ve svΘ dφlΦφ sφtφ se pak
vhodn∞ "doptß". Otßzkou ovÜem je, jak tomu bude v p°φpad∞
bezdiskov²ch stanic, kterΘ si svou IP adresu z vlastnφho
pevnΘho disku p°eΦφst nemohou.
 |
Obr. 45.2.: ZjiÜt∞nφ vlastnφ IP adresy pro bezdiskovou stanici (protokol RARP)
Po svΘm spuÜt∞nφ si ka₧dß bezdiskovß stanice musφ svou
vlastnφ IP adresu nejprve vy₧ßdat na jinΘm uzlovΘm poΦφtaΦi,
kter² v∙Φi nφ vystupuje v roli serveru IP adres. Zp∙sob,
jak²m se na n∞j bezdiskovß stanice obracφ, je analogick²
v²Üe naznaΦenΘmu mechanismu protokolu ARP - prost°ednictvφm
vÜesm∞rovΘho vysφlßnφ bezdiskovß stanice rozeÜle vÜem
ostatnφm uzl∙m dotaz typu: "Jakß je moje IP adresa?". Sebe
sama p°itom stanice identifikuje prost°ednictvφm fyzickΘ
adresy, kterou mß zabudovßnu ve svΘm sφ¥ovΘm adaptΘru - viz
obrßzek 45.2. a/.
KonkrΘtnφ protokol, prost°ednictvφm kterΘho si
bezdiskovß stanice m∙₧e svou IP adresu vy₧ßdat, vychßzφ
z protokolu ARP, a je oznaΦovßn jako RARP (Reverse Address
Resolution Protocol).
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
