Sφ¥ov² model TCP/IP

ReferenΦnφ model ISO/OSI, kter²m jsme se v naÜem serißlu dosud zab²vali, je vÜeobecn∞ pova₧ovßn za koncepci resp. sφ¥ovou architekturu, kterß do budoucna p°evlßdne a stane se dominujφcφ. Nenφ ale zdaleka koncepcφ jedinou, a svΘ budoucφ postavenφ si musφ teprve vybojovat. V souΦasnΘ dob∞ je nejv∞tÜφm "rivalem" referenΦnφho modelu ISO/OSI soustava protokol∙ TCP/IP.

╪ekne-li se dnes TCP/IP, je to obvykle chßpßno jen jako oznaΦenφ dvou p°enosov²ch protokol∙, pou₧φvan²ch v poΦφtaΦov²ch sφtφch s poΦφtaΦi na bßzi Unixu, konkrΘtn∞ protokol∙ TCP (Transmission Control Protocol) resp. IP (Internet Protocol). Ve skuteΦnosti ale zkratka TCP/IP oznaΦuje celou soustavu protokol∙, ne nutn∞ vßzanou na operaΦnφ systΘm Unix, p°iΦem₧ TCP a IP jsou sice nejznßm∞jÜφ protokoly tΘto soustavy, ale zdaleka ne protokoly jedinΘ. Sprßvn∞jÜφ je ale pova₧ovat TCP/IP za ucelenou soustavu nßzor∙ o tom, jak by se poΦφtaΦovΘ sφt∞ m∞ly budovat, a jak by m∞ly fungovat. Zahrnuje toti₧ i vlastnφ p°edstavu o tom, jak by m∞lo b²t sφ¥ovΘ programovΘ vybavenφ Φlen∞no na jednotlivΘ vrstvy, jakΘ ·koly by tyto vrstvy m∞ly plnit, a takΘ jak²m zp∙sobem by je m∞ly plnit - tedy jakΘ konkrΘtnφ protokoly by na jednotliv²ch ·rovnφch m∞ly b²t pou₧φvßny. Ve smyslu definice, kterou jsme si zavedli ve 23.kapitole, je tedy TCP/IP sφ¥ovou architekturou.

Pohled do historie

Agentura ARPA (mezitφm p°ejmenovanß na DARPA) se pak sna₧ila prosadit nov∞ vytvo°enΘ protokoly (a vlastn∞ i celou ucelenou sφ¥ovou architekturu) do praktickΘho ₧ivota i mimo sφ¥ ARPANET, p°edevÜφm pak do akademickΘho prost°edφ. V∞tÜina univerzitnφch poΦφtaΦov²ch pracoviÜ¥ v USA v tΘ dob∞ provozovala n∞jakou verzi tzv. BSD Unixu, pochßzejφcφ ze st°ediska Berkeley Software Distribution (BSD) na University of California v Berkeley. Agentura DARPA si proto nechala u p°ednφ americkΘ firmy Bolt, Beranek and Newman (BBN) na zakßzku vyvinout implementaci TCP/IP protokol∙ pod operaΦnφ systΘm Unix, a univerzit∞ v Berkeley p°isp∞la v²zkumn²mi granty na zaΦlen∞nφ t∞chto protokol∙ do univerzitou distribuovan²ch produkt∙. Tφm se protokoly TCP/IP prosadily do BSD Unixu, a poslΘze pak i do ostatnφch verzφ Unixu bu∩ p°φmo jako jejich standardnφ souΦßst, nebo jako voliteln² dopln∞k (option). Dφky svΘ popularit∞ se vÜak zßhy dostaly i na jinΘ platformy, a dnes jsou implementovßny snad ve vÜech v²poΦetnφch prost°edφch, od osobnφch poΦφtaΦ∙ PC s operaΦnφm systΘmem MS DOS a₧ nap°. po sßlovΘ poΦφtaΦe (mainframes) firmy IBM a operaΦnφ systΘm VM.

Pro sv∙j ·zk² vztah k sφti Internet je soustava protokol∙ TCP/IP n∞kdy oznaΦovßna takΘ jako Internet protocol suite (doslova: soustava protokol∙ Internetu), nebo tΘ₧ Department of Defense (DoD) protocol suite, co₧ naopak zd∙raz≥uje vztah k ministerstvu obrany USA.

Filosofie TCP/IP

Hlavnφ odliÜnosti mezi referenΦnφm modelem ISO/OSI a TCP/IP vypl²vajφ p°edevÜφm z rozdφln²ch v²chozφch p°edpoklad∙ a postoj∙ jejich tv∙rc∙. Jak jsme si ji₧ naznaΦili v p°edchozφch dφlech naÜeho serißlu, p°i koncipovßnφ referenΦnφho modelu ISO/OSI m∞li hlavnφ slovo zßstupci spojov²ch organizacφ. Ti pak nov∞ vznikajφcφmu modelu vtiskli svou vlastnφ p°edstavu - p°edevÜφm spojovan² a spolehliv² charakter slu₧eb, poskytovan²ch v komunikaΦnφ podsφti (tj. a₧ do ·rovn∞ sφ¥ovΘ vrstvy, vΦetn∞). Jin²mi slovy: ISO/OSI model poΦφtß se soust°ed∞nφm co mo₧nß nejvφce funkcφ, vΦetn∞ zajiÜt∞nφ spolehlivosti p°enos∙, ji₧ do komunikaΦnφ podsφt∞, kterß v d∙sledku toho bude muset b²t pom∞rn∞ slo₧itß, zatφmco k nφ p°ipojovanΘ hostitelskΘ poΦφtaΦe budou mφt relativn∞ jednoduchou ·lohu. Pozd∞ji se ale ukßzalo, ₧e nap°φklad prßv∞ v otßzce zajiÜt∞nφ spolehlivosti to nenφ nejÜ¥astn∞jÜφ °eÜenφ - ₧e toti₧ vyÜÜφ vrstvy nemohou pova₧ovat spolehlivou komunikaΦnφ podsφ¥ za dostateΦn∞ spolehlivou pro svΘ pot°eby, a tak se sna₧φ zajistit si po₧adovanou mφru spolehlivosti vlastnφmi silami. V d∙sledku toho se pak zajiÜ¥ovßnφm spolehlivosti do urΦitΘ mφry zab²vß vlastn∞ ka₧dß vrstva referenΦnφho modelu ISO/OSI.

Tv∙rci protokol∙ TCP/IP naopak vychßzeli z p°edpokladu, ₧e zajiÜt∞nφ spolehlivosti je problΘmem koncov²ch ·Φastnφk∙ komunikace, a m∞lo by tedy b²t °eÜeno a₧ na ·rovni transportnφ vrstvy. KomunikaΦnφ podsφ¥ pak podle tΘto p°edstavy nemusφ ztrßcet Φßst svΘ p°enosovΘ kapacity na zajiÜ¥ovßnφ spolehlivosti (na potvrzovßnφ, op∞tnΘ vysφlßnφ poÜkozen²ch paket∙ atd.), a m∙₧e ji naopak pln∞ vyu₧φt pro vlastnφ datov² p°enos. KomunikaΦnφ podsφ¥ tedy podle tΘto p°edstavy nemusφ b²t zcela spolehlivß - m∙₧e v nφ dochßzet ke ztrßtßm p°enßÜen²ch paket∙, a to bez varovßnφ a bez snahy o nßpravu. KomunikaΦnφ sφ¥ by ovÜem nem∞la zahazovat pakety bezd∙vodn∞. M∞la by naopak vyvφjet maximßlnφ snahu p°enßÜenΘ pakety doruΦit (v angliΦtin∞ se v tΘto souvislosti pou₧φvß termφn: best effort), a zahazovat pakety a₧ tehdy, kdy₧ je skuteΦn∞ nem∙₧e doruΦit - tedy nap°. kdy₧ dojde k jejich poÜkozenφ p°i p°enosu, kdy₧ pro n∞ nenφ dostatek vyrovnßvacφ pam∞ti pro doΦasnΘ ulo₧enφ, v p°φpad∞ v²padku spojenφ apod. Na rozdφl od referenΦnφho modelu ISO/OSI tedy TCP/IP p°edpoklßdß jednoduchou (ale rychlou) komunikaΦnφ podsφ¥, ke kterΘ se p°ipojujφ inteligentnφ hostitelskΘ poΦφtaΦe.

DalÜφ odliÜnost od referenΦnφho modelu ISO/OSI spoΦφvß v nßzoru na to, jak mß komunikaΦnφ sφ¥ vlastn∞ fungovat. Zatφmco model ISO/OSI poΦφtß p°edevÜφm se spojovan²m p°enosem - tedy s mechanismem virtußlnφch okruh∙, TCP/IP naopak p°edpoklßdß nespojovan² charakter p°enosu v komunikaΦnφ podsφti - tedy jednoduchou datagramovou slu₧bou - co₧ ostatn∞ vypl²vß i z p°edstavy co mo₧nß nejjednoduÜÜφ komunikaΦnφ podsφt∞.

╚ty°i vrstvy TCP/IP

Zatφmco referenΦnφ model ISO/OSI vymezuje sedm vrstev sφ¥ovΘho programovΘho vybavenφ, TCP/IP poΦφtß jen se Φty°mi vrstvami.

Bezprost°edn∞ vyÜÜφ vrstva, kterß ji₧ nenφ zßvislß na konkrΘtnφ p°enosovΘ technologii, je vrstva sφ¥ovß, v terminologii TCP/IP oznaΦovanß jako Internet Layer (voln∞ji: vrstva vzßjemnΘho propojenφ sφtφ), nebo tΘ₧ IP vrstva (IP Layer) podle toho, ₧e je realizovßna pomocφ protokolu IP. ┌kol tΘto vrstvy je v prvnφm p°iblφ₧enφ stejn², jako ·kol sφ¥ovΘ vrstvy v referenΦnφm modelu ISO/OSI - starß se o to, aby se jednotlivΘ pakety dostaly od odesilatele a₧ ke svΘmu skuteΦnΘmu p°φjemci, p°es p°φpadnΘ sm∞rovaΦe resp. brßny. Vzhledem k nespojovanΘmu charakteru p°enos∙ v TCP/IP je na ·rovni tΘto vrstvy zajiÜ¥ovßna jednoduchß (tj. nespolehlivß) datagramovß slu₧ba.

P°esto₧e je transportnφ vrstva TCP/IP nejΦast∞ji zajiÜ¥ovßna prßv∞ protokolem TCP, nenφ to zdaleka jedinß mo₧nost. DalÜφm pou₧φvan²m protokolem na ·rovni transportnφ vrstvy je nap°φklad protokol UDP (User Datagram Protocol), kter² na rozdφl od TCP nezajiÜ¥uje mj. spolehlivost p°enosu - samoz°ejm∞ pro takovΘ aplikace, kterΘ si to (na ·rovni transportnφ vrstvy) nep°ejφ.

NejvyÜÜφ vrstvou TCP/IP je pak vrstva aplikaΦnφ (Application Layer). Jejφmi entitami jsou jednotlivΘ aplikaΦnφ programy, kterΘ na rozdφl od referenΦnφho modelu ISO/OSI komunikujφ p°φmo s transportnφ vrstvou. P°φpadnΘ prezentaΦnφ a relaΦnφ slu₧by, kterΘ v modelu ISO/OSI zajiÜ¥ujφ samostatnΘ vrstvy, si zde musφ jednotlivΘ aplikace v p°φpad∞ pot°eby realizovat samy.

TCP/IP a vzßjemnΘ propojovßnφ sφtφ

Zp∙sob, jak²m je v referenΦnφm modelu ISO/OSI °eÜena otßzka vzßjemnΘho propojovßnφ sφtφ, jsme si naznaΦili ve 40. kapitole. Z nejr∙zn∞jÜφch materißl∙ o referenΦnφm modelu vÜak lze vycφtit, ₧e tato problematika do n∞j byla zapracovßna spφÜe a₧ na poslednφ chvφli, a rozhodn∞ nepat°φ mezi nejsiln∞jÜφ strßnky celΘho referenΦnφho modelu ISO/OSI. V p°φpad∞ TCP/IP je tomu jinak - vzßjemnΘ propojovßnφ sφtφ stejnΘho i odliÜnΘho typu bylo jednφm z v²chozφch p°edpoklad∙ celΘ soustavy protokol∙ TCP/IP, a je v nφ takΘ °eÜeno mnohem systematiΦt∞ji, ne₧ v referenΦnφm modelu ISO/OSI.

Filosofie TCP/IP od zaΦßtku usiluje o co nejuniverzßln∞jÜφ propojenφ sφtφ r∙zn²ch typ∙ - od lokßlnφch sφtφ typu Ethernet, Token Ring apod., p°es ve°ejnΘ datovΘ sφt∞ a₧ po rozlehlΘ sφt∞ celosv∞tovΘho dosahu. Klade si p°itom za cφl umo₧nit ka₧dΘmu poΦφtaΦi komunikovat s kter²mkoli jin²m poΦφtaΦe, bez ohledu na to, zda mezi nimi existuje p°φmΘ spojenφ, nebo zda jsou nap°φklad oba uzly r∙zn²ch sφtφ, kterΘ jsou vzßjemn∞ propojeny jednou nebo n∞kolika dalÜφmi sφt∞mi. V²sledkem je pak jedinß soustava vzßjemn∞ propojen²ch sφtφ, v terminologii TCP/IP oznaΦovanß obecn∞ jako internet (s mal²m "i", viz tΘ₧ 38. kapitola). Z pohledu u₧ivatele by vÜak vnit°nφ struktura tΘto soustavy sφtφ m∞la b²t irelevantnφ - u₧ivatelΘ, resp. jejich aplikaΦnφ programy, se mohou na cel² internet dφvat jako na jedinou velkou sφ¥, ke kterΘ jsou p°ipojeny jednotlivΘ koncovΘ poΦφtaΦe - v terminologii TCP/IP oznaΦovanΘ jako hostitelskΘ poΦφtaΦe (host computers, hosts).

Brßny, Φili IP sm∞rovaΦe

Ve skuteΦnosti je ovÜem v²slednß soustava - internet - stßle jen konglomerßtem (dφlΦφch) sφtφ stejnΘho Φi r∙znΘho typu, vzßjemn∞ propojen²ch pomocφ propojovacφch za°φzenφ. Tato propojovacφ za°φzenφ se p°itom v terminologii TCP/IP oznaΦujφ jako brßny (gateway), Podobn∞ jako referenΦnφ model ISO/OSI, p°edpoklßdajφ i protokoly TCP/IP, ₧e propojenφ jednotliv²ch dφlΦφch sφtφ bude realizovßno na ·rovni sφ¥ovΘ vrstvy. Podle obvykl²ch definic, kterΘ jsme si uvedli ve 38. kapitole, jsou pak ale brßny (v terminologii TCP/IP) ve skuteΦnosti spφÜe sm∞rovaΦi (routers). Tento dosti nep°φjemn² terminologick² konflikt se n∞kterΘ nov∞jÜφ odbornΘ prameny sna₧φ °eÜit zavedenφm v²sti₧n∞jÜφho termφnu IP router (tj. IP sm∞rovaΦ).

OvladaΦ na ·rovni vrstvy sφ¥ovΘho rozhranφ dokß₧e odstφnit sφ¥ovou vrstvu od konkrΘtnφho zp∙sobu ovlßdßnφ p°φsluÜnΘ sφt∞ a p°esnΘho formßtu datov²ch rßmc∙. Nenφ ovÜem ji₧ v jeho silßch zast°φt p°ed sφ¥ovou vrstvou rozdφl v pou₧φvanΘm mechanismu adresovßnφ, resp. zajistit pou₧φvßnφ jednotn²ch adres ve vÜech dφlΦφch sφtφch. Tento jednotn² zp∙sob adresovßnφ m∙₧e zajistit a₧ sφ¥ovß vrstva.

Jednotnß abstrakce

Sφ¥ovß vrstva, resp. protokol IP, kter² se pro jejφ realizaci pou₧φvß, vytvß°φ jednotnou abstrakci vÜech dφlΦφch sφtφ, kterß umo₧≥uje pracovat s jedin²m typem virtußlnφ sφt∞, namφsto s vφce Φi mΘn∞ odliÜn²mi dφlΦφmi sφt∞mi. Tato jednotnß abstrakce spoΦφvß nejen v zavedenφ jednotnΘho zp∙sobu adresovßnφ, ale takΘ v jednotnΘm formßtu datov²ch paket∙, pou₧φvan²ch na ·rovni sφ¥ovΘ vrstvy, tzv. IP datagram∙ (IP datagrams), a v poskytovßnφ jednotnΘ p°enosovΘ slu₧by - nespolehlivΘ nespojovanΘ (datagramovΘ) slu₧by.

IP adresy

Adresy, kterΘ protokol IP zavßdφ (a kterΘ jsou proto oznaΦovßny jako tzv. IP adresy), jsou 32-bitovΘ. Z pohledu transportnφ a aplikaΦnφ vrstvy je lze interpretovat jako lineßrnφ (resp. jednoslo₧kovΘ) adresy - co₧ odpovφdß p°edstav∞ jedinΘ homogennφ sφt∞. Na ·rovni sφ¥ovΘ vrstvy se ale interpretujφ jako dvouslo₧kovΘ, tvo°enΘ Φφslem resp. adresou hostitelskΘho poΦφtaΦe, a Φφslem resp. adresou (dφlΦφ) sφt∞, ve kterΘ se tento hostitelsk² poΦφtaΦ nachßzφ (tato interpretace pak odpovφdß p°edstav∞ vzßjemn∞ propojen²ch dφlΦφch sφtφ. P°esnΘmu formßtu a v²znamu IP adres se budeme jeÜt∞ v∞novat v samostatnΘm dφlu naÜeho serißlu.

Je dobrΘ si znovu zd∙raznit, ₧e IP adresy jsou pouze abstraktnφmi adresami, kterΘ musφ b²t poslΘze p°evedeny na skuteΦnΘ fyzickΘ adresy. Kdykoli toti₧ ovladaΦ na ·rovni vrstvy sφ¥ovΘho rozhranφ dostane n∞jakß data k odeslßnφ, musφ spolu s nimi dostat i konkrΘtnφ fyzickou adresu, na kterou je mß odeslat. Sßm toti₧ s IP adresami nepracuje. Jde-li nap°φklad o lokßlnφ sφ¥ typu Ethernet, dostane sφ¥ovß vrstva (od vrstvy transportnφ) adresu cφlovΘho hostitelskΘho poΦφtaΦe ve form∞ 32-bitovΘ IP adresy, ale p°φsluÜn² ovladaΦ vrstvy sφ¥ovΘho rozhranφ musφ dostat 48-bitovou Ethernetovou adresu. K mechanismu, kter²m se v TCP/IP sφtφch zjiÜ¥uje korespondence mezi IP adresami a konkrΘtnφmi specifick²mi adresami, se samoz°ejm∞ vrßtφme jeÜt∞ podrobn∞ji.

IP datagramy

Podobn∞ jako jednotn² formßt adres a zp∙sob adresovßnφ, zavßdφ protokol IP i jednotn² formßt p°enßÜen²ch dat na ·rovni sφ¥ovΘ vrstvy - ji₧ v²Üe zmφn∞nΘ IP datagramy. Jde o datovΘ pakety, oznaΦovanΘ jako datagramy proto, ₧e jsou p°enßÜeny pomocφ nespojovanΘ (tΘ₧: datagramovΘ) sφ¥ovΘ p°enosovΘ slu₧by.

V²znam p°enßÜen²ch dat na ·rovni jednotliv²ch vrstev ilustruje obrßzek 34.3.: zatφmco aplikaΦnφ a transportnφ vrstvy v∙bec "nevφ" o existenci jednotliv²ch dφlΦφch sφtφ (a jako koncovφ ·Φastnφci p°enosu si tak p°edßvajφ v₧dy p°esn∞ stejn² tvar paket∙, resp. zprßv), na ·rovni vrstvy sφ¥ovΘho rozhranφ se p°enßÜφ identickΘ rßmce jen v jednotliv²ch dφlΦφch sφtφ. V ka₧dΘ z nich je pak p°enßÜen IP datagram v₧dy stejnΘho formßtu, kter² se ovÜem p°eci jen v n∞Φem liÜφ - nap°φklad v hodnot∞ ΦφtaΦe, kter² vyjad°uje ₧ivotnost paketu (co₧ je souΦßst mechanismu, kter² mß zabrßnit p°φpadnΘmu zacyklenφ).

Adresovßnφ v TCP/IP sφtφch - I.

Prßv∞ vyslovenΘ tvrzenφ si zaslou₧φ pon∞kud up°esnit: Ka₧d² hostitelsk² poΦφtaΦ, kter² chce odeslat n∞jak² IP datagram jinΘmu hostitelskΘmu poΦφtaΦi, dokß₧e z IP adresy p°φjemce snadno rozpoznat, zda tento le₧φ ve stejnΘ dφlΦφ sφti Φi nikoli. Pokud ano (nachßzφ-li se nap°φklad v tΘ₧e sφti typu Ethernet), poÜle mu odesilatel sv∙j datagram p°φmo. Pokud se ale p°φjemce nachßzφ v jinΘ sφti, poÜle odesilatel sv∙j datagram nejbli₧Üφ brßn∞ (resp. IP sm∞rovaΦi, viz minule) ve "svΘ" sφti. Na nφ je pak rozhodnout, kudy datagram poslat dßle. PodstatnΘ p°itom je, ₧e p°i svΘm rozhodovßnφ vychßzφ brßna pouze z tΘ Φßsti IP adresy koneΦnΘho p°φjemce, kterß vyjad°uje p°φsluÜnou cφlovou sφ¥. V prvnφm p°iblφ₧enφ si lze p°edstavit, ₧e ka₧dß brßna mß svΘ sm∞rovacφ tabulky ve form∞ seznamu dvojic <<I>sφ¥,brßna>, a podle cφlovΘ sφt∞ p°φjemce si v nich najde, kterΘ brßn∞ mß p°φsluÜn² datagram poslat dßle. Zb²vajφcφ Φßst IP adresy p°φjemce, kterß vyjad°uje adresu hostitelskΘho poΦφtaΦe v rßmci cφlovΘ sφt∞, pak vyu₧ije a₧ ta brßna (poslednφ v °et∞zci), kterß ji₧ le₧φ v p°φsluÜnΘ cφlovΘ sφti, a kterß pak datagram poÜle p°φmo jeho koneΦnΘmu adresßtovi.

32 bit∙, vyhrazen²ch pro IP adresy, je tedy nutnΘ vhodn²m zp∙sobem rozd∞lit na dv∞ Φßsti, tak aby tyto mohly vyjad°ovat adresu sφt∞ a adresu hostitelskΘho poΦφtaΦe v rßmci tΘto sφt∞. Otßzkou ovÜem je, jak toto rozd∞lenφ provΘst. Filosofie sφ¥ovΘho modelu TCP/IP toti₧ p°edpoklßdß, ₧e jednotliv²mi dφlΦφmi sφt∞mi mohou b²t jak "malΘ" sφt∞ s n∞kolika mßlo uzly (hostitelsk²mi poΦφtaΦi), tak i "velkΘ" sφt∞ s tisφci i desφtkami tisφc uzl∙. T°icet dva bit∙, kterΘ jsou k dispozici, pak nelze rozd∞lit jedin²m zp∙sobem, kter² by pamatoval na sφt∞ s velk²m poΦtem uzl∙, a souΦasn∞ m∞l i dostateΦn∞ velkou rezervu pro rychle rostoucφ poΦet jednotliv²ch dφlΦφch sφtφ.

Adresy t°φdy A majφ pro adresu sφt∞ vyhrazeno 7 bit∙, a pro adresu hostitelskΘho poΦφtaΦe 24 bit∙. Adres tΘto t°φdy je tedy relativn∞ velmi mßlo, poΦφtajφ vÜak s velmi velk²m poΦet uzlov²ch poΦφtaΦ∙. Jsou urΦeny pro velkΘ rozlehlΘ sφt∞, jako nap°. sφ¥ ARPAnet (viz 38. dφl serißlu), kterß se stala zßrodkem sφt∞ Internet, pro velkΘ ve°ejnΘ sφt∞, p°φpadn∞ i velkΘ podnikovΘ sφt∞. Adresy t°φdy B, kterΘ p°ipouÜtφ a₧ 65534 uzl∙ (hostitelsk²ch poΦφtaΦ∙), jsou urΦeny pro st°edn∞ velkΘ sφt∞, nap°. pro univerzitnφ sφt∞, podnikovΘ sφt∞ apod., a pou₧φvajφ se tΘ₧ v souvislosti s tzv. subnetting-em (podsφt∞mi, viz dßle). Adresy t°φdy C, kterΘ poΦφtajφ jen se 254 uzly, jsou pak urΦeny pro vÜechny ostatnφ sφt∞.

Symbolick² zßpis IP adres

prvnφ oktet adresysφ¥ovß Φßst adresyΦßst adresy, p°edstavujφcφ relativnφ adresu uzlu v rßmci sφt∞maximßlnφ poΦet hostitelsk²ch poΦφtaΦ∙t°φda A1-126p q.r.s16777214t°φda B128-191p.qr.s65534t°φda C192-223p.q.rs254Tabulka 44.3.: Desφtkovß teΦkovanß notace a IP adresy (je-li p.q.r.s obecn² tvar IP adresy)

Jak volit IP adresy?

U ka₧dΘ poΦφtaΦovΘ sφt∞ Φi soustavy sφtφ, budovanΘ pomocφ protokol∙ TCP/IP, je vÜak prakticky jen otßzkou Φasu, kdy je jejich provozovatelΘ budou chtφt p°ipojit do dnes ji₧ celosv∞tovΘ sφt∞ Internet (viz nap°. CW 7/92). TakΘ zde samoz°ejm∞ platφ zßsada jednoznaΦnosti adres, tak₧e vÜechny nov∞ p°ipojovanΘ sφt∞ musφ mφt dosud nepou₧itΘ adresy. V Internetu proto existuje centrßlnφ autorita (konkrΘtn∞: DDN Network Information Center, SRI International, 333 Rawenswood Avenue, Menlo Park, California 94025), kterß se starß o hospoda°enφ s IP adresami, a p°id∞luje je vÜem potencißlnφm zßjemc∙m (p°esn∞ji: p°id∞luje tu Φßst IP adres, kterß p°edstavuje adresu sφt∞, zatφmco zb²vajφcφ Φßst IP adres si volφ ₧adatel. Ve skuteΦnosti tak p°id∞luje vlastn∞ celΘ skupiny IP adres se shodnou prvnφ Φßstφ). SkuteΦnΘ p°ipojenφ k sφti Internet p°itom v∙bec nenφ podmφnkou pro p°id∞lenφ adresy, tak₧e je naopak dobrΘ si p°id∞lenφ adresy vy₧ßdat co nejd°φve, pokud mo₧no jeÜt∞ p°ed zprovozn∞nφm jakΘkoli sφt∞ na bßzi TCP/IP (a tφm se vyhnout pozd∞jÜφ zm∞n∞ IP adres, kterß je samoz°ejm∞ mo₧nß, ale obvykle znaΦn∞ pracnß).

V naÜich zem∞pisn²ch Üφ°kßch vÜak nenφ nutnΘ se pro p°id∞lenφ IP adresy obracet a₧ do USA. DDN NIC, kterß adresy spravuje, toti₧ delegovala svou pravomoc v p°id∞lovßnφ IP adres pro oblast ╚SFR v²poΦetnφmu centru pra₧skΘ VèCHT (Technickß 5, 166 28 Praha 6).

Subnetting

MyÜlenku tohoto mechanismu si m∙₧eme ukßzat na p°φkladu organizace, p°ipojenΘ k sφti Internet, kterß provozuje vφce dφlΦφch sφtφ, a pro ka₧dou z nich mß p°id∞lenu samostatnou adresu (nejspφÜe t°φdy C). Ka₧dß z t∞chto dφlΦφch sφtφ je pak ovÜem "samostatn∞ viditelnß" i z vn∞ p°φsluÜnΘ organizace, a jako se samostatnou je s nφ takΘ naklßdßno - ve sm∞rovacφch tabulkßch ka₧dß zabφrß samostatnou polo₧ku. Kdyby se ovÜem p°φsluÜnß organizace sama postarala o pot°ebnΘ sm∞rovßnφ mezi sv²mi sφt∞mi, a navenek vystupovala jako jedin² celek, mohla by mφt p°id∞lenu jen jednu sφ¥ovou adresu (nap°φklad t°φdy B mφsto vφce sφ¥ov²ch adres t°φdy C), a ve sm∞rovacφch tabulkßch by tak zabφrala jen jednu polo₧ku. VÜechny dφlΦφ sφt∞, pat°φcφ p°φsluÜnΘ organizaci, by tak navenek vystupovaly jako sφ¥ jedinß, s jedinou spoleΦnou adresou (p°esn∞ji: s IP adresami, kterΘ se shodujφ v Φßsti, vyjad°ujφcφ adresu sφt∞). SkuteΦnΘ vnit°nφ Φlen∞nφ tΘto navenek jednotnΘ sφt∞ by pak bylo pln∞ v kompetenci p°φsluÜnΘ organizace. Ta by takΘ musela zm∞nit p°esn² zp∙sob, jak²m sama interpretuje IP adresy sv²ch hostitelsk²ch poΦφtaΦ∙, a to podle obrßzku 44.1. b/ - tu Φßst, kterß z vn∞jÜφho pohledu p°edstavuje Φφslo resp. adresu hostitelskΘho poΦφtaΦe, by pro sebe musela rozd∞lit na dv∞ Φßsti - Φφslo resp. adresu svΘ dφlΦφ sφt∞ (podsφt∞, neboli subnet, odsud subnetting), a na Φφslo resp. adresu hostitelskΘho poΦφtaΦe v rßmci tΘto podsφt∞. V nejjednoduÜÜφm p°φpad∞ adresy t°φdy B tak, ₧e t°etφ oktet bude pova₧ovat za Φφslo podsφt∞, a Φtvrt² za Φφslo uzlu (hostitelskΘho poΦφtaΦe). V obecnΘm p°φpad∞ pak podle tzv. masky podsφt∞ (subnet mask), kterß ob∞ Φßsti IP adresy nov∞ definuje.

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).

╪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φ.

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

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■....?". 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φ.

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.

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.

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).

Sm∞rovßnφ v TCP/IP sφtφch - I.

 DalÜφ z aspekt∙, d∙le₧it²ch pro pochopenφ celkovΘ filosofie soustavy protokol∙ TCP/IP, je otßzka sm∞rovßnφ ve vzßjemn∞ propojen²ch sφtφch. Z nφ jsme si n∞co naznaΦili ji₧ ve 43. dφlu naÜeho serißlu, nynφ se vÜak touto problematikou budeme zab²vat podrobn∞ji.

Nejprve si ale p°ipome≥me, jak²m zp∙sobem se protokoly TCP/IP dφvajφ na vzßjemn∞ propojenΘ sφt∞ (tzv. internet): p°edpoklßdajφ, ₧e jednotlivΘ (dφlΦφ) sφt∞ jsou propojeny prost°ednictvφm bran (gateways), oznaΦovan²ch takΘ jako IP sm∞rovaΦe (IP routers). VzßjemnΘ propojenφ je p°itom takovΘ, ₧e mezi libovoln²mi dv∞ma dφlΦφmi sφt∞mi v₧dy existuje alespo≥ jedna cesta, kterß ovÜem m∙₧e vΘst i p°es vφce jin²ch dφlΦφch sφtφ, resp. prochßzet posloupnostφ bran, propojujφcφch mezilehlΘ sφt∞.

Ka₧dß brßna je v₧dy p°ipojena nejmΘn∞ do dvou dφlΦφch sφtφ, a slou₧φ pouze pot°ebßm sm∞rovßnφ (a nikoli k provozovßnφ u₧ivatelsk²ch aplikacφ). Tφm se brßny odliÜujφ od druhΘho typu uzl∙, kterΘ naopak slou₧φ p°edevÜφm k provozovßnφ aplikaΦnφch program∙, a kterΘ se v terminologii TCP/IP oznaΦujφ jako hostitelskΘ poΦφtaΦe (hosts, host computers). TakΘ hostitelskΘ poΦφtaΦe vÜak mohou b²t p°ipojeny do dvou Φi vφce dφlΦφch sφtφ souΦasn∞ (pak jde o tzv. multi-homed hosts), a mohou tedy fungovat i jako brßny. P°esto₧e se toto °eÜenφ v praxi obΦas pou₧φvß (hlavn∞ v akademickΘm prost°edφ), nenφ v₧dy bezproblΘmovΘ. Filosofie TCP/IP vÜak velmi ost°e rozliÜuje mezi hostitelsk²m poΦφtaΦem a brßnou, a proto i my se p°idr₧φme p°edstavy dvou fyzicky r∙zn²ch za°φzenφ.

Nynφ si ale p°edstavme situaci, kdy hostitelsk² poΦφtaΦ A chce odeslat IP datagram hostitelskΘmu poΦφtaΦi C. Jeliko₧ z jeho IP adresy rozpoznß, ₧e le₧φ v jinΘ dφlΦφ sφti, poÜle datagram brßn∞ G (ve "svΘ" dφlΦφ sφti). Tφm ·loha hostitelskΘho poΦφtaΦe A jako odesilatele konΦφ, a dalÜφ je ji₧ na brßn∞ G resp. na celΘ struktu°e bran, kterΘ musφ b²t schopnΘ si datagram postupn∞ p°edßvat tak dlouho, dokud se nedostane do cφlovΘ dφlΦφ sφt∞, kde pak m∙₧e b²t prost°ednictvφm p°φmΘho sm∞rovßnφ odeslßn hostitelskΘmu poΦφtaΦi, kter² je jeho koneΦn²m adresßtem. Prßv∞ naznaΦen² p°φpad odpovφdß tzv. nep°φmΘmu sm∞rovßnφ (indirect routing), ke kterΘmu na rozdφl od sm∞rovßnφ p°φmΘho dochßzφ tehdy, jestli₧e adresßt nenφ v tΘ₧e dφlΦφ sφti jako odesilatel, a ten proto posφlß datagram brßn∞.

Volba mezi vφce brßnami

Vzhledem k tomu, ₧e vzßjemn∞ propojenΘ sφt∞ tvo°φ souvisl² celek, musφ b²t v ka₧dΘ dφlΦφ sφti v₧dy alespo≥ jedna brßna. Nemusφ ovÜem b²t zdaleka jen jedna. P°edstavme si jednoduch² p°φklad kde mß hostitelsk² poΦφtaΦ A na v²b∞r dv∞ brßny, G1 a G2. Ka₧dß z nich by sice m∞la b²t schopna doruΦit IP datagram kamkoli je t°eba, ale ₧ßdnß z nich nebude z°ejm∞ optimßlnφ pro vÜechny mo₧nΘ cφle - k n∞kter²m vede kratÜφ cesta p°es brßnu G1, k jin²m zase p°es brßnu G2. Znalost toho, kdy je v²hodn∞jÜφ poslat datagram brßn∞ G1 a kdy brßn∞ G2, by ale m∞l mφt ji₧ hostitelsk² poΦφtaΦ A. Je samoz°ejm∞ mo₧nΘ, aby tento hostitelsk² poΦφtaΦ m∞l pot°ebnΘ informace "pevn∞ zabudovßny" ve sv²ch konfiguraΦnφch souborech, podle nich₧ si pak vytvß°φ svΘ sm∞rovacφ tabulky. Ve vzßjemn∞ propojen²ch sφtφch malΘho rozsahu a s minimem dynamick²ch zm∞n to je rozumnΘ °eÜenφ, v p°φpad∞ v∞tÜφch a Φast∞ji se m∞nφcφch konglomerßt∙ sφtφ ji₧ nikoli. Zde ji₧ je nutn² jin² mechanismus, umo₧≥ujφcφ provßd∞t dynamickou aktualizaci sm∞rovacφch tabulek hostitelsk²ch poΦφtaΦ∙ podle okam₧itΘ situace.

Filosofie sm∞rovßnφ v TCP/IP ale vychßzφ z toho, ₧e znßt nejvhodn∞jÜφ cesty a pr∙b∞₧n∞ reagovat na skuteΦnou situaci je ·kolem bran, a nikoli hostitelsk²ch poΦφtaΦ∙. V soustav∞ protokol∙ TCP/IP je proto zabudovßn mechanismus, pomocφ kterΘho je cel² problΘm velmi elegantn∞ °eÜen: kdykoli n∞jakß brßna zjistφ, ₧e n∞kter² hostitelsk² poΦφtaΦ pou₧φvß neoptimßlnφ cestu, upozornφ jej na tuto skuteΦnost. Uka₧me si to na p°φkladu: nech¥ hostitelsk² poΦφtaΦ A v dφlΦφ sφti X poÜle brßn∞ G1 IP datagram, urΦen² poΦφtaΦi C v dφlΦφ sφti Y. Brßna G1 znß optimßlnφ cestu a vφ, ₧e ze sφt∞ X do sφt∞ Y je v²hodn∞jÜφ pou₧φt brßnu G2. O doruΦenφ p°ijatΘho datagramu se brßna G1 jeÜt∞ postarß, ale souΦasn∞ s tφm upozornφ hostitelsk² poΦφtaΦ A, ₧e dalÜφ datagramy, sm∞°ujφcφ do sφt∞ Y, ji₧ mß posφlat p°es brßnu G2. Hostitelsk² poΦφtaΦ A si tuto informaci zanese do sv²ch sm∞rovacφch tabulek, a nadßle se podle nφ °φdφ.

Prßv∞ naznaΦen² mechanismus mß jeden velmi p°φjemn² efekt - jednotlivΘ hostitelskΘ poΦφtaΦe vystaΦφ na poΦßtku (tj. p°i svΘm spuÜt∞nφ) se znalostφ jednΘ jedinΘ brßny ve "svΘ" dφlΦφ sφti. DalÜφ brßny se pak "nauΦφ" pou₧φvat dφky prßv∞ popsanΘmu mechanismu. Ten je v praxi zajiÜ¥ovßn prost°ednictvφm protokolu ICMP (Internet Control Message Protocol), kter² je povinnou souΦßstφ protokolu IP, a slou₧φ obecn∞ pro p°edßvßnφ °φdφcφch informacφ a zprßv o chybßch a nestandardnφch situacφch.

P°ipome≥me si vÜak jeÜt∞ jednu v²znamnou skuteΦnost, kterou jsme si uvedli ji₧ ve 43. dφlu naÜeho serißlu - kv∙li minimalizaci rozsahu sm∞rovacφch tabulek je veÜkerΘ sm∞rovßnφ v TCP/IP sφtφch zalo₧eno jen na dφlΦφch sφtφch jako takov²ch, a nikoli na jednotliv²ch hostitelsk²ch poΦφtaΦφch (p°esn∞ji: na tΘ Φßsti IP adres, kterΘ p°edstavujφ adresy dφlΦφch sφtφ). V naÜem konkrΘtnφm p°φpad∞ to znamenß, ₧e hostitelsk² poΦφtaΦ A si ve sv²ch sm∞rovacφch tabulkßch bude pamatovat pouze to, ₧e nejv²hodn∞jÜφ cesta do sφt∞ Y vede p°es brßnu G2, a nikoli ₧e k hostitelskΘmu poΦφtaΦi C se dostane nejlΘpe p°es brßnu G2.

Sm∞rovßnφ v TCP/IP sφtφch - II.

V minulΘm dφle jsme se zaΦali podrobn∞ji zab²vat problematikou sm∞rovßnφ v TCP/IP sφtφch. ╪ekli jsme si, ₧e na sm∞rovßnφ se podφlφ jak brßny, tak i hostitelskΘ poΦφtaΦe, a blφ₧e jsme se zab²vali prßv∞ rolφ hostitelsk²ch poΦφtaΦ∙. Dnes se podrobn∞ji zastavφme u toho, jak²m zp∙sobem se na sm∞rovßnφ podφlφ brßny (IP sm∞rovaΦe).

Vra¥me se vÜak jeÜt∞ jednou k hostitelsk²m poΦφtaΦ∙m: jejich ·loha p°i sm∞rovßnφ konΦφ tφm, ₧e datagram bu∩ poÜlou p°φmo jeho koncovΘmu adresßtovi (v p°φpad∞ tzv. p°φmΘho sm∞rovßnφ, viz minule, kdy se p°φjemce nachßzφ v tΘ₧e dφlΦφ sφti), nebo tφm, ₧e datagram p°edajφ n∞kterΘ z bran (v opaΦnΘm p°φpad∞). O postupu hostitelskΘho poΦφtaΦe v prvnφm p°φpad∞ jsme si ji₧ povφdali v souvislosti s problematikou adresovßnφ a transformovßnφ IP adres. Pro druh² p°φpad musφ mφt hostitelsk² poΦφtaΦ prßv∞ tolik informacφ, aby dokßzal zvolit jednu z bran ve svΘ dφlΦφ sφti, a tΘ datagram poslat. Tyto informace si hostitelsk² poΦφtaΦ uchovßvß ve sv²ch sm∞rovacφch tabulkßch.

Uka₧me si nynφ, jak² efekt mß tento mechanismus na sm∞rovacφ tabulky hostitelsk²ch poΦφtaΦ∙ : po spuÜt∞nφ hostitelskΘho poΦφtaΦe musφ jeho sm∞rovacφ tabulka obsahovat informace alespo≥ o jednΘ brßn∞. Tato brßna (resp. jedna z bran, je-li ve sm∞rovacφ tabulce uvedeno) je p°itom prohlßÜena za implicitnφ (default), a hostitelsk² poΦφtaΦ jφ z poΦßtku posφlß vÜechny datagramy, kterΘ sm∞°ujφ do jinΘ dφlΦφ sφt∞. Jakmile tato implicitnφ brßna zjistφ, ₧e by hostitelsk² poΦφtaΦ m∞l pou₧φt jinou v²hodn∞jÜφ cestu (vedoucφ p°es jinou brßnu), upozornφ jej na to. Hostitelsk² poΦφtaΦ si na zßklad∞ tΘto explicitnφ informace upravφ svou sm∞rovacφ tabulku - zavede si v nφ novou polo₧ku, a v nφ si poznaΦφ, ₧e datagramy, sm∞°ujφcφ do p°φsluÜnΘ dφlΦφ sφt∞, mß posφlat p°es tu a tu brßnu. Kdykoli ale mß odeslat datagram do dφlΦφ sφt∞, pro kterou jeÜt∞ nemß ve svΘ sm∞rovacφ tabulce uvedenu konkrΘtnφ cestu, poÜle datagram tΘ brßn∞, kterß je v jeho sm∞rovacφ tabulce uvedena jako implicitnφ. Takovßto organizace sm∞rovacφch tabulek velmi dob°e odpovφdß "stromovit²m" konfiguracφm , kterΘ jsou u lokßlnφch sφtφ dosti ΦastΘ, a p°i kter²ch samostatnΘ cesty (vyjßd°enΘ ve sm∞rovacφ tabulce explicitn∞) vedou jen k n∞kolika mßlo dalÜφm dφlΦφm sφtφm, zatφmco ke "zbytku sv∞ta" vede cesta jedinß (zp°φstupn∞nß implicitnφ brßnou).

Ponechme jeÜt∞ stranou otßzku, jak²m zp∙sobem zφskßvajφ jednotlivΘ brßny pot°ebnΘ informace o cestßch (k tomu se dostaneme p°φÜt∞), a podφvejme se, jak brßny postupujφ p°i vlastnφm sm∞rovßnφ.

Pravidla pro sm∞rovßnφ datagram∙ se u bran principißln∞ neliÜφ od hostitelsk²ch poΦφtaΦ∙. Zjistφ-li brßna, ₧e p°ijat² datagram je urΦen adresßtovi v dφlΦφ sφti, do kterΘ je brßna p°ipojena (a takovΘ musφ b²t alespo≥ dv∞, mß-li jφt v∙bec o brßnu), poÜle mu datagram p°φmo - v rßmci p°φmΘho sm∞rovßnφ . Je-li datagram urΦen adresßtovi v jinΘ dφlΦφ sφti, do kterΘ nenφ brßna p°φmo p°ipojena, musφ zvolit jinou vhodnou brßnu, a tΘ datagram p°edat. Postupuje p°itom obdobn∞ jako hostitelsk² poΦφtaΦ: pokud ve svΘ sm∞rovacφ tabulce najde explicitnφ ·daj o tom, ₧e pro danou cφlovou sφ¥ mß datagram p°edat tΘ a tΘ brßn∞, uΦinφ tak. Pokud o danΘ cφlovΘ sφti nemß ve svΘ sm∞rovacφ tabulce ₧ßdnΘ ·daje, pou₧ije tu brßnu, kterou pova₧uje za implicitnφ - pokud ovÜem mß ve svΘ sm∞rovacφ tabulce implicitnφ brßnu v∙bec definovßnu. Pokud ne, nenφ danß brßna schopna sm∞rovßnφ datagramu zajistit, a musφ to oznßmit jako chybu.

Vra¥me se jeÜt∞ jednou k obsahu sm∞rovacφch tabulek. Jak jsme si ji₧ n∞kolikrßt naznaΦili, je z d∙vodu minimalizace jejich rozsahu veÜkerΘ sm∞rovßnφ zalo₧eno jen na adrese cφlovΘ sφt∞, resp. na tΘ Φßsti IP adresy, kterß tuto cφlovou sφ¥ vyjad°uje. Sm∞rovacφ tabulky jsou pak ve svΘ podstat∞ vlastn∞ seznamem dvojic , kde "sφ¥" p°edstavuje cφlovou dφlΦφ sφ¥, a "brßna" je ta z bran, p°es kterou do cφlovΘ sφt∞ vede (nejvhodn∞jÜφ) cesta. Jde p°itom o brßnu, kterß jeÜt∞ nenφ koneΦn²m p°φjemcem datagramu, ale jen jeho dalÜφ p°estupnφ stanicφ na cest∞ k cφli. V angliΦtin∞ se oznaΦuje jako next hop, doslova: dalÜφ skok.

Brßnou pro "dalÜφ skok" vÜak musφ v₧dy b²t brßna, kterß je z danΘho mφsta dosa₧itelnß p°φmo - tedy takovß brßna , kterß se nalΘzß ve stejnΘ dφlΦφ sφti, jako dan² hostitelsk² poΦφtaΦ, resp. v n∞kterΘ z dφlΦφch sφtφ, do kter²ch je p°φmo p°ipojena danß brßna.

Adresy bran, kterΘ jsou obsa₧eny ve sm∞rovacφch tabulkßch, jsou zßsadn∞ IP adresy, aΦkoli by se na prvnφ pohled mohlo zdßt v²hodn∞jÜφ pou₧φvat zde p°φmo fyzickΘ adresy - Φφm₧ by se uÜet°ila opakovanΘ transformace IP adresy na fyzickou adresu brßny (viz 44. dφl serißlu). D∙vodem pro pou₧itφ IP adres je mo₧nost vyu₧φvat ve vÜech uzlech stejnou programovou realizaci sm∞rovacφho mechanismu, nezßvisle na konkrΘtnφch fyzick²ch adresßch. DalÜφm, velmi d∙le₧it²m d∙vodem, je mo₧nost pr∙b∞₧nΘ aktualizace sm∞rovacφch tabulek a takΘ mo₧nost p°φpadnΘho lad∞nφ, dojde-li k chyb∞ Φi jin²m nestandardnφm situacφm p°i sm∞rovßnφ. V neposlednφ °ad∞ pou₧itφ IP adres ve sm∞rovacφch tabulkßch vychßzφ i z celkovΘ koncepce sφ¥ovΘ (IP) vrstvy a protokolu IP - usilujφcφ o vytvo°enφ jednotnΘ abstrakce vÜech dφlΦφch sφtφ.

V²jimka z pravidla

Nebylo by to snad ani ₧ßdnΘ pravidlo, kdyby nem∞lo takΘ svΘ v²jimky. V p°φpad∞ pravidla o sm∞rovßnφ jen na zßklad∞ adres dφlΦφch sφtφ je touto v²jimkou mo₧nost zavΘst do sm∞rovacφch tabulek explicitn∞ takΘ ·daje o cestßch ke konkrΘtnφm hostitelsk²m poΦφtaΦ∙m, nikoli jen do cel²ch dφlΦφch sφtφ. AΦkoli za b∞₧nΘho provozu by tato mo₧nost m∞la b²t vyu₧φvßna spφÜe vyjφmeΦn∞, je velmi u₧iteΦnß pro sprßvce sφtφ p°i lad∞nφ a sprßv∞ sφt∞ obecn∞. Zde m∙₧e b²t k nezaplacenφ mo₧nost p°esm∞rovat tok slu₧ebnφch dat, sm∞°ujφcφch k pracovnφ stanici sprßvce tak, aby se vyhnul p°etφ₧enΘmu Φi zcela nepr∙chodnΘmu mφstu, kterΘ je zdrojem problΘm∙.

Sm∞rovßnφ v TCP/IP sφtφch - III.

V minul²ch dvou dφlech jsme se zab²vali konkrΘtnφm postupem hostitelsk²ch poΦφtaΦ∙ a bran (IP sm∞rovaΦ∙) p°i sm∞rovßnφ IP datagram∙. Ukßzali jsme si, jak²m zp∙sobem k tomu oba druhy uzl∙ TCP/IP sφtφ vyu₧φvajφ svΘ sm∞rovacφ tabulky, a naznaΦili jsme si takΘ, ₧e udr₧ovßnφ sprßvnΘho obsahu sm∞rovacφch tabulek hostitelsk²ch poΦφtaΦ∙ majφ vlastn∞ na starosti brßny. Dnes se ji₧ dostaneme k tomu, jak si svΘ sm∞rovacφ tabulky vytvß°φ a udr₧ujφ samotnΘ brßny.

Hlavnφ v²hodou sm∞rovßnφ s vyu₧itφm implicitnφch cest je znaΦnß redukce rozsahu sm∞rovacφch tabulek, a s tφm souvisejφcφ menÜφ re₧ie na jejich aktualizaci a udr₧ovßnφ konzistentnφho stavu. Nev²hodou je pak potencißlnφ neefektivita sm∞rovßnφ - cesta, vedoucφ p°es implicitnφ brßnu, samoz°ejm∞ nemusφ b²t nejkratÜφ.

Ani brßny nemusφ znßt vÜechno

Proto se i v p°φpad∞ bran aplikovala stejnß myÜlenka, jako u hostitelsk²ch poΦφtaΦ∙: vybavit v∞tÜinu z nich jen ΦßsteΦnou znalostφ nejkratÜφch cest do vÜech mo₧n²ch cφlov²ch sφtφ, a vyu₧φvat implicitnφ sm∞rovßnφ. KonkrΘtnφ realizace se pak vyvφjela na zßklad∞ toho, jak se TCP/IP protokoly prosazovaly do nov∞ vznikajφcφho Internetu. Podφvejme se proto, jak se situace vyvφjela zde.

Na poΦßtku byl ARPANET

Pokud se jednalo jen o jednu lokßlnφ sφ¥, byla tato napojena na pßte°nφ sφ¥ prost°ednictvφm jedinΘ brßny. Pokud Ülo o vφce lokßlnφch sφtφ (nap°φklad o skupinu lokßlnφch sφtφ v rßmci areßlu univerzity apod.), byly tyto navzßjem propojeny dalÜφmi brßnami, ale na pßte°nφ sφ¥ byly jako celek p°ipojeny op∞t jen v jednom bod∞, resp. prost°ednictvφm jedinΘ brßny. Tato brßna pak v∙Φi ostatnφm vystupovala jako implicitnφ brßna, p°es kterou byl sm∞rovßn veÜker² provoz, urΦen² "mimo" nov∞ p°ipojenou skupinu dφlΦφch sφtφ.

Hlavnφ (core) a vedlejÜφ (noncore) brßny

Pro ty brßny, kterΘ byly p°φmo p°ipojeny na pßte°nφ sφ¥, vÜak ji₧ stejnß ·vaha neplatila. V rßmci pßte°nφ sφt∞ (kterß m∞la ve skuteΦnosti dosti slo₧itou vnit°nφ strukturu) by p°i implicitnφm sm∞rovßnφ ji₧ dochßzelo k v²razn²m neefektivitßm. Tv∙rci Internetu se proto rozhodli poskytnout vÜem brßnßm, p°ipojen²m p°φmo na pßte°nφ sφ¥, "·plnou" znalost celΘho Internetu, a umo₧nit jim tak vyu₧φvat skuteΦn∞ optimßlnφch cest v rßmci pßte°nφ sφt∞. Ka₧dß z t∞chto tzv. hlavnφch bran (core gateways) tedy znala optimßlnφ cestu do vÜech dostupn²ch cφlov²ch sφtφ v celΘm Internetu. VÜechny hlavnφ brßny si pak navzßjem pravideln∞ p°edßvaly nezbytnΘ sm∞rovacφ informace, pomocφ kter²ch si aktualizovaly a vzßjemn∞ koordinovaly svΘ sm∞rovacφ tabulky. Tvo°ily tak ucelen² systΘm, kter² mohl fungovat dostateΦn∞ spolehliv∞ dφky tomu, ₧e vÜechny hlavnφ brßny spravovala jedinß centrßlnφ instituce (Internet Network Operations Center).

Situace si pom∞rn∞ brzy vynutila °adu zm∞n, ale o nich si povφme a₧ p°φÜt∞.

Sm∞rovßnφ v TCP/IP sφtφch - IV.

V minulΘm dφlu jsme dosp∞li k p°edstav∞ toho, ₧e Internet vznikal a postupn∞ se rozÜi°oval p°ipojovßnφm jednotliv²ch dφlΦφch sφtφ Φi cel²ch skupin dφlΦφch sφtφ p°φmo na zßrodeΦnou pßte°nφ sφ¥. V rßmci t∞chto skupin byly jednotlivΘ dφlΦφ sφt∞ propojeny tzv. vedlejÜφmi brßnami (noncore gateways), zatφmco na pßte°nφ sφ¥ byla celß skupina p°ipojena jedinou, tzv. hlavnφ brßnou (core gateway). Tato hlavnφ brßna p°itom pravideln∞ komunikovala se vÜemi ostatnφmi hlavnφmi brßnami Internetu, a vym∞≥ovala si s nimi pot°ebnΘ sm∞rovacφ informace. Dφky tomu mohly vÜechny hlavnφ brßny pracovat s ·plnou znalostφ celΘho Internetu, tj. znßt nejkratÜφ cestu do kterΘkoli dφlΦφ sφt∞. Naproti tomu vedlejÜφ (noncore) brßny vystaΦily jen se znalostφ svΘho bezprost°ednφho okolφ (resp. p°φsluÜnΘ skupiny sφtφ, sdφlejφcφch stejnou hlavnφ brßnu), a pro vÜechny ostatnφ cφle pou₧φvaly implicitnφ sm∞rovßnφ p°es hlavnφ brßnu.

Protokol EGP umo₧≥uje, aby se jeden autonomnφ systΘm nejprve dohodl s jin²m, ₧e si sm∞rovacφ informace v∙bec budou vym∞≥ovat (nebo si je takΘ mohou odmφtnout p°edßvat). Dßle umo₧≥uje, aby jednotlivΘ autonomnφ systΘmy pravideln∞ testovaly dostupnost druh²ch autonomnφch systΘm∙ (tj. testovaly, zda spojenφ s nimi je pr∙chodnΘ). Hlavnφm ·kolem protokolu EGP vÜak je pravideln² p°enos sm∞rovacφ ·daj∙ a informacφ o pr∙b∞₧n²ch zm∞nßch.

Protokol EGP je tedy prost°edkem, pomocφ kterΘho m∙₧e autonomnφ systΘm informovat jinΘ autonomnφ systΘmy o dostupnosti dφlΦφch sφtφ v rßmci vlastnφho autonomnφho systΘmu, a naopak zφskßvat informace o cestßch do dφlΦφch sφtφ v jin²ch autonomnφch systΘmech. V Internetu ale vzhledem k jeho konkrΘtnφ stromovitΘ topologii staΦφ, kdy₧ jednotlivΘ autonomnφ systΘmy p°edßvajφ pot°ebnΘ sm∞rovacφ informace soustav∞ hlavnφch bran (kterß je sama o sob∞ autonomnφm systΘmem).

Jednou ze zajφmav²ch vlastnostφ protokolu EGP je skuteΦnost, ₧e sice p°enßÜφ ·daje o "dΘlkßch" cest do jednotliv²ch dφlΦφch sφtφ, ale pak je ji₧ nepou₧φvß. V d∙sledku toho vlastn∞ pracuje jen informaci o tom, zda cesta do p°φsluÜnΘ dφlΦφ sφt∞ existuje Φi nikoli. To mß zajφmav² d∙sledek: kdyby do n∞kterΘ dφlΦφ sφt∞ existovalo vφce mo₧n²ch cest, p°φsluÜnΘ brßny by nem∞ly podle Φeho mezi nimi vybφrat. Proto jsou p°i vzßjemnΘm propojovßnφ autonomnφch systΘm∙ zakßzßny takovΘ topologie, kterΘ by p°ipouÜt∞ly vφce mo₧n²ch cest do stejn²ch cφlov²ch sφtφ. Protokol EGP tedy poΦφtß pouze se stromovitou strukturu, co₧ ale v p°φpad∞ Internetu pln∞ postaΦuje.

Pokud jde o p°enos sm∞rovacφch informacφ v rßmci jednotliv²ch autonomnφch systΘm∙, zde majφ jejich provozovatelΘ mo₧nost vlastnφho v²b∞ru. Mezi mo₧nosti, kterΘ se jim nabφzφ, pat°φ takΘ samotn² protokol EGP, kter² lze pou₧φvat i "uvnit°" autonomnφch systΘm∙ (povinn² je pouze "vn∞", mezi autonomnφmi systΘmy). DalÜφ, dosti rozÜφ°enou mo₧nostφ je protokol RIP (Routing Information Protocol), prost°ednictvφm kterΘho si jednotlivΘ vnit°nφ brßny autonomnφho systΘmu p°edßvajφ ·daje o tom, do kter²ch cφlov²ch sφtφ vede z kterΘ brßny cesta a jak je dlouhß (m∞°eno v poΦtu mezilehl²ch sφtφ). Ka₧dß z bran si pak na zßklad∞ t∞chto ·daj∙ sama dopoΦφtßvß nejkratÜφ cesty do vÜech dostupn²ch dφlΦφch sφtφ zp∙sobem, kter² jsme si naznaΦili ji₧ v 33. dφlu naÜeho serißlu. Na podobnΘm principu je zalo₧en alternativnφ protokol Hello, kter² vÜak m∞°φ dΘlky jednotliv²ch cest nikoli v poΦtu mezilehl²ch sφtφ, ale v dΘlce zpo₧d∞nφ p°i p°enosu po tΘto cest∞. SpoleΦnou nev²hodou t∞chto algoritm∙, kterΘ pracujφ s dΘlkou cest (a jsou proto oznaΦovßny jako vector-distance algorithms) je jejich velkß re₧ie, kterß navφc p°i zv∞tÜovßnφ poΦtu bran velmi rychle roste. Z tohoto pohledu jsou pak v²hodn∞jÜφ algoritmy, oznaΦovanΘ spoleΦn∞ jako link-state Φi SPF (Shortest Path First) algoritmy. Ty p°edpoklßdajφ, ₧e ka₧dß brßna znß topologii celΘho konglomerßtu vzßjemn∞ propojen²ch sφtφ, a pravideln∞ testuje pr∙chodnost p°enosov²ch cest ke sv²m bezprost°ednφm soused∙m. DvouhodnotovΘ informace o tΘto dostupnosti pak rozesφlß vÜem ostatnφm brßnßm, kterΘ si na jejich zßklad∞, podle tzv. Dijkstrova algoritmu, samy vyhodnocujφ nejkratÜφ cesty do vÜech dφlΦφch sφtφ. Ve srovnßnφ s p°edchozφ skupinou vykazujφ tyto algoritmy v²razn∞ ni₧Üφ re₧ii, kterß p°i zv∞tÜovßnφ poΦtu bran navφc neroste tak rychle.

Zajφmav² je z tohoto pohledu takΘ zp∙sob, jak²m si pot°ebnΘ sm∞rovacφ informace vym∞≥ovala soustava hlavnφch bran, nynφ tvo°φcφ jeden autonomnφ systΘm. P∙vodn∞ tyto hlavnφ brßny pou₧φvaly protokol GGP (Gateway-to-Gateway Protocol), kter² pat°φ do stejnΘ skupiny, jako protokoly RIP a Hello, tedy mezi protokoly, p°enßÜejφcφ ·daje o dΘlce jednotliv²ch cest (v p°φpad∞ protokolu GGP m∞°enΘ v poΦtu "p°estupnφch" bran). Vzhledem k velkΘ re₧ii (viz zßv∞r minulΘho dφlu) vÜak byl tento protokol nahrazen protokolem SPREAD (pat°φcφ mezi protokoly SPF), na kter² soustava hlavnφch bran p°eÜla v roce 1988. VÜechny protokoly, pou₧φvanΘ pro p°enos sm∞rovacφch informacφ mezi jednotliv²mi brßnami "uvnit°" autonomnφch systΘm∙, se souhrnn∞ oznaΦujφ jako protokoly IGP (Interior Gateway Protocol).

Sm∞rovßnφ v TCP/IP sφtφch - V.

V minul²ch dφlech naÜeho serißlu jsme se podrobn∞ji zab²vali otßzkou sm∞rovßnφ v TCP/IP sφtφch. KonkrΘtnφ mechanismy, kterΘ jsme si v tΘto souvislosti popisovali, vÜak vychßzely z urΦitΘ strategie pro p°id∞lovßnφ IP adres, kterou jsme si ukßzali ji₧ ve 43. dφlu. Tato strategie se ale s v²vojem Internetu takΘ postupn∞ vyvφjela, a tak muselo nutn∞ dojφt k urΦit²m modifikacφm i ve zp∙sobu sm∞rovßnφ.

O zm∞n∞ strategie p°i p°id∞lovßnφ IP adres jsme se ji₧ zmφnili ve 43. dφlu, kde jsme si o IP adresßch povφdali podrobn∞ji. P°ipome≥me si proto, v Φem tyto zm∞ny spoΦφvajφ, a hlavn∞ Φφm jsou motivovßny.

Tv∙rci sφ¥ovΘho modelu TCP/IP jist∞ p°edpoklßdali nßr∙st v nasazenφ v²poΦetnφ techniky, ale s Φφm ji₧ poΦφtali mΘn∞ je skuteΦnost, ₧e tento nßr∙st bude tak prudk², a ₧e se bude ubφrat cestou "mal²ch" poΦφtaΦ∙ a velkΘho mno₧stvφ relativn∞ mal²ch lokßlnφch sφtφ. Zatφmco zßsoba IP adres t°φdy C jeÜt∞ zdaleka vyΦerpßna nenφ, ·zk²m mφstem se ukßzala b²t jednak agenda, spojenß s p°id∞lovßnφm IP adres, a p°edevÜφm rozsah sm∞rovacφch tabulek, s nφm₧ pak souvisφ i vysokß re₧ie na udr₧ovßnφ jejich pr∙b∞₧nΘ konzistence.

Jak jsme si ji₧ n∞kolikrßt ukßzali, sna₧φ se TCP/IP protokoly minimalizovat rozsah sm∞rovacφch tabulek a re₧ii na jejich aktualizaci dv∞ma zp∙soby: sm∞rovßnφm jen na zßklad∞ adresy dφlΦφ sφt∞, a pou₧φvßnφm implicitnφho sm∞rovßnφ (resp. implicitnφch cest) v tzv. vedlejÜφch brßnßch (noncore gateways). Ani to vÜak nestaΦφ, a tak se ukßzalo jako nezbytnΘ usilovat o redukci poΦtu r∙zn²ch IP adres cel²ch sφtφ. Jin²mi slovy: usilovat o tom, aby vφce dφlΦφch sφtφ m∞lo p°id∞lenu a sdφlelo stejnou sφ¥ovou adresu (p°esn∞ji: tu Φßst IP adresy, kterß p°edstavuje adresu sφt∞), a ve sm∞rovacφch tabulkßch tak zabφralo jen jednu polo₧ku. P°iÜlo se samoz°ejm∞ na vφce mo₧nostφ, jak toho dosßhnout - tou nejefektivn∞jÜφ se ukßzala b²t technika tzv. podsφtφ (subnets), kterou jsme si naznaΦili ji₧ ve 44. dφlu naÜeho serißlu, a kterß je dnes ji₧ povinnou souΦßstφ TCP/IP protokol∙. Zopakujme si proto jejφ zßkladnφ myÜlenku.

Tento modifikovan² algoritmus mß jednu v²hodu - dokß₧e zobecnit i ob∞ singularity, kterΘ se vyskytujφ u p∙vodnφho algoritmu (viz op∞t 46. dφl), a to sm∞rovßnφ na zßklad∞ adres jednotliv²ch hostitelsk²ch poΦφtaΦ∙, a pou₧itφ implicitnφch cest. V prvnφm p°φpad∞ staΦφ volit takovou masku, dφky kterΘ bude jako adresa sφt∞ interpretovßna celß IP adresa p°φsluÜnΘho hostitelskΘho poΦφtaΦe (zatφmco Φßst, p°edstavujφcφ Φφslo hostitelskΘho poΦφtaΦe, bude prßzdnß). V p°φpad∞ implicitnφch cest pak staΦφ pou₧φt opaΦn² extrΘm - masku, kterß zcela "zamaskuje" adresu sφt∞.

Otßzkou ovÜem je, kdo mß takto modifikovan² algoritmus sm∞rovßnφ pou₧φvat. Kdyby jej toti₧ musely pou₧φvat vÜechny brßny, zcela by se tφm negoval v²sledn² efekt pou₧itφ techniky podsφtφ, spoΦφvajφcφ v dalÜφ redukci sm∞rovacφch tabulek. Modifikovan² algoritmus sm∞rovßnφ musφ v ka₧dΘm p°φpad∞ pou₧φvat vÜechny brßny a hostitelskΘ poΦφtaΦe v jednotliv²ch podsφtφch. Pokud jde o ostatnφ brßny a hostitelskΘ poΦφtaΦe, zde platφ jednoduchΘ teoretickΘ pravidlo: modifikovan² algoritmus sm∞rovßnφ je t°eba pou₧φt tam, odkud mohou vΘst r∙znΘ optimßlnφ cesty do r∙zn²ch podsφtφ se stejnou sφ¥ovou adresou.

Toto pravidlo lze jednoduÜe aplikovat v p°φpad∞, ₧e do celΘ skupiny podsφtφ se stejnou adresou vede jen jedin² vstupnφ bod. V ostatnφch p°φpadech je situace mnohem komplikovan∞jÜφ.

Proxy ARP

Jak jsme si ji₧ naznaΦili v²Üe, technika podsφtφ (subnetting) nenφ jedin²m zp∙sobem, jak m∙₧e vφce dφlΦφch sφtφ sdφlet tutΘ₧ adresu. DalÜφ mo₧nostφ je mechanismus, oznaΦovan² jako proxy ARP Φi promiscuous ARP, nebo takΘ ARP hack. Ten je ovÜem pou₧iteln² jen tam, kde je vyu₧φvßn protokol ARP pro transformaci IP adres na adresy fyzickΘ (tj. nap°φklad v lokßlnφch sφtφch typu Ethernet, viz 44. dφl serißlu). MyÜlenka proxy ARP je zalo₧enß na jednoduchΘm triku: brßna G se sna₧φ p°edstφrat sφti A, ₧e je tφm hostitelsk²m poΦφtaΦem (v sφti B), se kter²m chce prßv∞ komunikovat n∞kter² z uzl∙ sφt∞ A. D∞lß to tak, ₧e kdykoli je pomocφ protokolu ARP vyslßn v sφti A dotaz na fyzickou adresu n∞kterΘho hostitelskΘho poΦφtaΦe v sφti B, brßna G na tento dotaz odpovφ, a vrßtφ svou fyzickou adresu. VÜechny datagramy, urΦenΘ p°φsluÜnΘmu poΦφtaΦi, jsou pak posφlßny na tuto fyzickou adresu, tedy ve skuteΦnosti brßn∞ G, kterΘ je pak prost°ednictvφm sφt∞ B dßle p°edßvß jejich koneΦnΘmu adresßtovi. V²sledn² efekt je tedy takov², jako kdyby sφ¥ B spl²vala se sφtφ A, a m∞la s nφ tudφ₧ stejnou sφ¥ovou adresu.

ProblΘm je ovÜem v omezenΘ pou₧itelnosti (jen tam, kde je pou₧φvßn protokol ARP), a dßle takΘ v tom, ₧e n∞kterΘ implementace protokolu ARP se sna₧φ detekovat a hlßsit sprßvci sφt∞ tzv. spoofing, jak se oznaΦuje situace, kdy jedno za°φzenφ p°edstφrß, ₧e je jin²m za°φzenφm (nap°φklad proto, aby mohlo neoprßvn∞n∞ "odposlouchßvat" p°enßÜenß data).

JmΘna v TCP/IP sφtφch - I.

V minul²ch dφlech naÜeho serißlu jsme si ukßzali, ₧e v sφtφch na bßzi protokol∙ TCP/IP (a samoz°ejm∞ takΘ v Internetu) se pou₧φvajφ jednotnΘ IP adresy ΦφselnΘho charakteru, a ₧e takΘ veÜkerΘ sm∞rovßnφ je zalo₧eno prßv∞ na t∞chto adresßch. Jakkoli jsou ale tyto ΦφselnΘ adresy vhodnΘ pro p°φsluÜn² sφ¥ov² software, pro u₧ivatele p°φliÜ v²sti₧nΘ nejsou. LidΘ rad∞ji pracujφ se snßze zapamatovateln²mi symbolick²mi jmΘny, nap°φklad "aviion.mff.cuni.cs", ne₧ s mßlo mnemonick²mi Φφseln²mi adresami typu 129.1.2.3. Jak je to ale s mo₧nostφ pou₧φvat takovßto symbolickß jmΘna v TCP/IP sφtφch?

Zamysleme se nejprve znovu nad tφm, co je vlastn∞ IP adresa. Ve 44. dφlu jsme dosp∞li k tomu, ₧e IP adresa je dvouslo₧kovß, a ₧e jejφ dv∞ slo₧ky reprezentujφ jednak adresu dφlΦφ sφt∞, jednak adresu hostitelskΘho poΦφtaΦe (resp. brßny) v tΘto dφlΦφ sφti. HostitelskΘ poΦφtaΦe vÜak mohou b²t p°φmo p°ipojeny i do dvou Φi vφce dφlΦφch sφtφ (pak jsou v angliΦtin∞ oznaΦovßny jako multihomed hosts), a brßny dokonce musφ b²t takto p°ipojeny nejmΘn∞ do dvou sφtφ, majφ-li v∙bec fungovat jako brßny. Pak ovÜem majφ takΘ dv∞ Φi vφce r∙zn²ch IP adres. Domyslφme-li tuto skuteΦnost do d∙sledku, je p°esn∞jÜφ chßpat IP adresu nikoli jako adresu poΦφtaΦe resp. brßny jako takovΘ, ale jako rozhranφ mezi sφtφ a hostitelsk²m poΦφtaΦem resp. brßnou. Navφc, dojde-li k p°emφst∞nφ poΦφtaΦe Φi brßny, jejich IP adresy se zm∞nφ.

JmΘna vs. IP adresy

Otßzkou ovÜem je, jak² tvar by m∞la symbolickß jmΘna mφt, kdo je oprßvn∞n je p°id∞lovat, a jak z t∞chto jmen zφskßvat jim odpovφdajφcφ IP adresy, kterΘ jsou pot°eba pro vlastnφ komunikaci.

Flat namespace

Je-li t°eba p°id∞lit symbolickß jmΘna relativn∞ malΘmu poΦtu hostitelsk²ch poΦφtaΦ∙ a bran, je vÜe jednoduchΘ - staΦφ vymyslet dostateΦn² poΦet navzßjem r∙zn²ch jmen, a ty jednotliv²m poΦφtaΦ∙m a brßnßm p°id∞lit. Na syntaktick² tvar t∞chto jmen p°itom nenφ t°eba klßst n∞jakΘ zvlßÜtnφ po₧adavky - samoz°ejm∞ krom∞ jejich jednoznaΦnosti - a nenφ ani nutnΘ tato jmΘna jakkoli strukturovat Φi Φlenit na Φßsti. VÜechna takovßto symbolickß jmΘna jsou pak pova₧ovßna za dßle ned∞litelnß (v angliΦtin∞ se °φkß, ₧e tvo°φ "flat namespace", doslova: ploch² prostor jmen). Udr₧et takov²to systΘm dßle ned∞liteln²ch jmen v konzistentnφm stavu vÜak vy₧aduje existenci centrßlnφ autority, kterß bude dbßt na p°φpustnost nov∞ p°id∞lovan²ch jmen - hlavn∞ podle toho, jestli nekolidujφ s n∞kter²m ji₧ p°id∞len²m jmΘnem. Se zvyÜovßnφm poΦtu p°id∞lovan²ch symbolick²ch jmen vÜak zaΦne nar∙stat administrativnφ i technickß zßt∞₧ tΘto centrßlnφ instituce, a problematickΘ se stßvß i hledßnφ nov²ch, dosud nepou₧it²ch symbolick²ch jmen. V takov²ch kolosech, jako je Internet, se prßv∞ naznaΦenΘ °eÜenφ stalo velmi brzy ne·nosnΘ.

Hierarchickß jmΘna

Uka₧me si to na hypotetickΘm p°φkladu sφt∞, propojujφcφ vysokΘ Ükoly v Praze, a na p°φkladu jmen o t°ech slo₧kßch, kterΘ vyjad°ujφ vysokou Ükolu jako takovou, fakultu v rßmci tΘto vysokΘ Ükoly, a jmΘno p°φsluÜnΘho poΦφtaΦe na tΘto fakult∞. Adresy tohoto typu by mohly vypadat nap°φklad takto:

aviion.mff.cuni

(poΦφtaΦ se jmΘnem aviion na Matematicko-fyzikßlnφ fakult∞ (mff) Univerzity Karlovy (cuni)), nebo:

vax.fel.cvut

Pro tento nßmi zvolen² p°φklad by stßle jeÜt∞ musela existovat centrßlnφ autorita, kterß by vÜak odpovφdala jen za jmΘna, resp. slo₧ky nejvyÜÜφ ·rovn∞, vyjad°ujφcφ jmΘna jednotliv²ch vysok²ch Ükol (tj. cvut, cuni atd.). Ka₧dß novß vysokß Ükola, kterß by se cht∞la zapojit do tohoto systΘmu jmen, by se musela obrßtit na tuto centrßlnφ autoritu pro p°id∞lenφ novΘho jmΘna (resp. jeho nejvyÜÜφ slo₧ky). Centrßlnφ autorita pak p°id∞lenφm ka₧dΘho novΘho jmΘna nejvyÜÜφ ·rovn∞ vlastn∞ vytvß°φ samostatn² prostor symbolick²ch jmen, kterΘmu se obvykle °φkß domΘna (v naÜem p°φpad∞ jde nap°. o domΘny cvut, cuni). Tφm vÜak odpov∞dnost centrßlnφ autority konΦφ, nebo¥ sprßvu ka₧dΘ domΘny - tj. odpov∞dnost za p°id∞lovßnφ dalÜφch slo₧ek jmen - deleguje jednotliv²m vysok²m Ükolßm, kterΘ se stßvajφ sprßvci p°φsluÜn²ch domΘn. Ti si pak sami volφ jmΘna (slo₧ky) druhΘ ·rovn∞, v naÜem p°φpad∞ odpovφdajφcφ jednotliv²m fakultßm (tj. nap°φklad mff, fel). Tφm vznikajφ dalÜφ domΘny ni₧Üφ ·rovn∞ (subdomΘny), kterΘ op∞t majφ svΘ sprßvce - v naÜem p°φpad∞ jednotlivΘ fakulty - kterΘ si zase samy volφ jmΘna t°etφ ·rovn∞. A jeliko₧ jsme se v naÜem hypotetickΘm p°φkladu omezili jen na t°i ·rovn∞, jde ji₧ o jmΘna konkrΘtnφch poΦφtaΦ∙ na p°φsluÜn²ch fakultßch. V praxi ovÜem nenφ poΦet ·rovnφ (resp. slo₧ek) omezen.

SystΘm domΘnov²ch jmen

Mechanismus, kter² v TCP/IP sφtφch implementuje prßv∞ naznaΦen² systΘm hierarchick²ch jmen, se jmenuje DNS (Domain Name System). Ten mß dv∞ Φßsti - prvnφ z nich p°edepisuje syntaxi hierarchick²ch jmen (oznaΦovan²ch nynφ jako domΘnovß jmΘna), a pravidla pro delegovßnφ pravomocφ a odpov∞dnosti za jejich p°id∞lovßnφ. Druhß Φßst pak urΦuje zp∙sob implementace distribuovanΘho systΘmu, kter² umo₧≥uje efektivn∞ p°evßd∞t domΘnovß jmΘna na jim odpovφdajφcφ IP adresy (o tom si budeme povφdat p°φÜt∞).

VÜechno podle Internetu

Standard DNS nep°edepisuje ₧ßdn² povinn² tvar jednotliv²ch slo₧ek domΘnov²ch jmen. Nep°edepisuje ani, ₧e Φlen∞nφ na domΘny r∙zn²ch ·rovnφ musφ odpovφdat organizaΦnφmu Φlen∞nφ - stejn∞ tak dob°e m∙₧e toto Φlen∞nφ vychßzet nap°φklad z ·zemnφho Φlen∞nφ.

SystΘm domΘnov²ch jmen, pou₧φvan² v "sφti" Internet, mß jeden pikantnφ rys - vznikl toti₧ v dob∞, kdy jeho auto°i v∙bec neuva₧ovali o tom, ₧e by se v∙bec n∞kdy rozÜφ°il mimo ·zemφ USA. Proto zavedli domΘny nejvyÜÜφ ·rovn∞ (tzv. top-level domains), kterΘ vyjad°ujφ charakter p°φsluÜn²ch organizacφ, ale jsou pou₧itelnΘ jen pro takovΘ organizace, kterΘ sφdlφ v USA (a v Φßsti Kanady). Jakmile se ale Internet dostal i mimo Spojen²ch stßt∙, musely se zavΘst jeÜt∞ dalÜφ domΘny nejvyÜÜφ ·rovn∞, odpovφdajφcφ jednotliv²m stßt∙m. JmΘna t∞chto domΘn nejvyÜÜφ ·rovn∞ tvo°φ dvoupφsmenovΘ nßrodnφ k≤dy (Country Code), kterΘ definuje standard ISO 3166, pro ╚eskoslovensko pak: cs. Tak₧e nap°φklad

xinu.cs.purdue.edu

je poΦφtaΦ (xinu) na kated°e computer science (cs) na Purdue University (purdue), kterß je vzd∞lßvacφ institucφ (edu), v USA. Naopak

aviion.mff.cuni.cs

NßÜ hypotetick² p°φklad tedy nebyl tak daleko od skuteΦnosti. Pouze jsme v n∞m neuva₧ovali, ₧e celΘ ╚eskoslovensko tvo°φ v rßmci Internetu jednu domΘnu nejvyÜÜφ ·rovn∞ (domΘnu cs), jejφm₧ sprßvcem je pra₧skß VèCHT. U nφ pak musφ b²t registrovßny vÜechny domΘny druhΘ ·rovn∞.

JmΘna v TCP/IP sφtφch - II.

V minulΘm dφlu jsme se zab²vali otßzkou symbolick²ch jmen poΦφtaΦ∙ a bran v TCP/IP sφtφch a dosp∞li jsme k tomu, jak²m zp∙sobem se p°id∞lujφ domΘnovß jmΘna v Internetu. Nynφ se budeme v∞novat otßzce, jak na zßklad∞ symbolick²ch jmen zφskßvat odpovφdajφcφ IP adresy.

P°ipome≥me si jeÜt∞ jednou, ₧e otßzku domΘnov²ch jmen v TCP/IP sφtφch °eÜφ standard DNS (Domain Name System), kter² mß dv∞ zßkladnφ Φßsti: prvnφ z nich urΦuje syntaxi domΘnov²ch jmen a pravidla pro delegovßnφ pravomoci a odpov∞dnosti za jejich p°id∞lovßnφ, zatφmco druhß Φßst se t²kß implementace mechanismu pro p°evod domΘnov²ch jmen na jim odpovφdajφcφ IP adresy.

Zajφmavou otßzkou je to, kam se mß ₧adatel o p°evod obrßtit nejprve - zda mß zaΦφt shora, a obrßtit se na ko°enov² server, nebo mß naopak postupovat naopak odspodu, a obrßtit se nejprve na "mφstnφ" server jmen? Ve prosp∞ch druhΘ mo₧nosti hovo°φ hned n∞kolik skuteΦnostφ: kdyby se vÜichni obraceli p°φmo na ko°enov² server, tento by byl brzy zahlcen. Navφc po₧adavky na p°evod domΘnov²ch jmen se nejΦast∞ji t²kajφ prßv∞ "mφstnφch" jmen, kterΘ dokß₧e p°evΘst mφstnφ server. Ten je krom∞ toho schopen fungovat i v p°φpad∞ eventußlnφho v²padku vyÜÜφch vrstev celΘho stromu name server∙ (i kdy₧ to je vzhledem k jejich zßlohovßnφ nep°φliÜ pravd∞podobnΘ).

Podobn∞ postupujφ i servery jmen. Krom∞ domΘnov²ch jmen, kterΘ jsou schopny (p°esn∞ji: oprßvn∞ny) p°evßd∞t samy, se p°i rekurzivnφch p°evodech dozvφdajφ i odpovφdajφcφ IP adresy k jin²m domΘnov²m jmΘn∙m. TakΘ ty si udr₧ujφ ve svΘ vyrovnßvacφ pam∞ti, a v p°φpad∞ ₧ßdosti o p°evod je mohou poskytnout - ovÜem s poznßmkou, ₧e nejsou k jejich p°evodu kompetentnφ (tj. ₧e jde o tzv. neautoritativnφ (nonauthoritative) p°evod). SouΦasn∞ s tφm poskytnou ₧adateli o p°evod i odkaz na ten server jmen, kter² je k p°evodu kompetentnφ. Inicißtor p°evodu pak nalo₧φ s touto informacφ podle vlastnφho uvß₧enφ. Jde-li mu o rychlost, pou₧ije tento neautoritativnφ p°evod, jde-li mu naopak o spolehlivost, obrßtφ se na p°φsluÜn² server jmen, kter² je pro dan² p°evod kompetentnφ.

JeÜt∞ v∞tÜφho zefektivn∞nφ celΘho mechanismu p°evodu domΘnov²ch jmen na IP adresy lze pak dosßhnout tφm, ₧e jednotlivΘ hostitelskΘ poΦφtaΦe si v okam₧iku svΘho spuÜt∞nφ vy₧ßdajφ od mφstnφho serveru jmen celou jeho databßzi domΘnov²ch jmen a jim odpovφdajφcφch IP adres. Z tΘ pak vychßzφ, a na server jmen se obracφ jen p°i jejφ aktualizaci (po "zastarßnφ" n∞kterΘ polo₧ky) Φi pro jejφ dopln∞nφ o novΘ domΘnovΘ jmΘno, jeho₧ odpovφdajφcφ IP adresa jeÜt∞ v databßzi nenφ.