Elektronickß poÜta v TCP/IP Φas¥ druhß


Vrstvy TCP/IP

ReferenΦn² model ISO OSI je vlastne abstrakciou a rozÜφrenφm usporiadania protokolov TCP/IP. NajΦastejÜie sa reprezentßcia vrstiev TCP/IP znßzor≥uje pod╛a obr. 1:



Obr. 1: Stσpec vrstiev TCP/IP

Vrstva sie¥ovΘho rozhrania je najni₧Üou vrstvou v stσpci a zodpovedß dvom najni₧Üφm vrstvßm modelu ISO OSI. Funkcie a parametre tejto vrstvy s· u vΣΦÜiny sie¥ov²ch adaptΘrov pevne zabudovanΘ v hardvΘri a firmvΘri.

Hlavn² rozdiel medzi stσpcom protokolov TCP/IP a ISO OSI je v tom, ₧e posledn² menovan² model mß nad transportnou vrstvou eÜte tri ∩alÜie, zatia╛ Φo TCP/IP mß na tomto mieste iba jednu vrstvu. Monolitick² prφstup TCP/IP v princφpe vedie ku k≤du, ktor² sφce m⌠₧e by¥ r²chlejÜφ, ale nie je tak preh╛adn² a opakovane pou₧ite╛n².


Tok dßt medzi vrstvami

Spoluprßca medzi vrstvami je zalo₧enß na tom, ₧e vrstvy vyÜÜej ·rovne vyu₧φvaj· dopredu definovanΘ slu₧by, ktorΘ poskytuje niektorß z ni₧Üφch vrstiev. Pritom spravidla vyÜÜia vrstva spolupracuje priamo iba s tou, ktorß sa nachßdza bezprostredne pod ≥ou. SkutoΦn² tok dßt pri komunikßcii je znßzornen² na obr. 2. Na zdrojovej stanici A prechßdzaj· dßta vrstvami smerom dole a₧ do vrstvy sie¥ovΘho rozhrania, kde sa uskutoΦnφ ich prenos do cie╛ovej stanice B, odtia╛ postupuj· vrstvami v opaΦnom smere, teda zdola nahor. V∩aka dßtovej abstrakcii danej vrstvenφm protokolov sa pre obidva programy v aplikaΦnej vrstve vytvßra predstava, ako keby spolu priamo komunikovali.



Obr. 2: Znßzornenie toku dßt pri sie¥ovej komunikßcii


Pozrime sa teraz trochu podrobnejÜie na to, Φo sa deje s dßtami, ktorΘ si protokoly v susedn²ch vrstvßch medzi sebou odovzdßvaj·. Predpokladajme, ₧e nejak² program v aplikaΦnej vrstve vytvßra urΦitΘ dßta, ktorΘ chce posla¥ partnerskΘmu programu, s ktor²m komunikuje. Pou₧ije teda naprφklad slu₧by protokolu TCP na nadviazanie spojenia medzi obidvoma poΦφtaΦmi a na vytvorenie logickΘho pr·du dßt. Dßta vÜak musia by¥ prenßÜanΘ v diskrΘtnych paketoch, tak₧e TCP najprv odhadne optimßlnu ve╛kos¥ takΘhoto paketu, a potom rozdelφ spojit² pr·d dßt na segmenty s touto ve╛kos¥ou. Segmenty s· doplnenΘ identifikaΦn²mi ·dajmi, tvoriacimi hlaviΦku TCP a s· odovzdanΘ ni₧Üej vrstve - protokolu IP. Protokol IP zoberie obsah segmentu, ktor² pova₧uje za indiferentnΘ dßta a pripojφ k nemu vlastnΘ identifikaΦnΘ ·daje - hlaviΦku IP, Φφm vznikne IP datagram. Ten je odovzdan² sie¥ovΘmu rozhraniu, naprφklad Ethernetu, kde je postup ·plne analogick²: Datagram sa umiestni do dßtovej Φasti ethernetovskΘho rßmca, v ktorom sa eÜte ∩alej vyplnia identifikaΦnΘ dßta ÜpecifickΘ pre Ethernet, a potom je rßmec odoslan² na prenosovΘ mΘdium. Na cie╛ovej stanici je postup opaΦn²: Protokol ni₧Üej vrstvy odstrßni identifikaΦnΘ ·daje a vlastn² dßtov² obsah odovzdß protokolu vo vyÜÜej vrstve. Ke∩₧e v ka₧dej vrstve sa nachßdza nieko╛ko protokolov, mohol by vznikn·¥ problΘm, ktorΘmu protokolu vyÜÜej vrstvy je potrebnΘ dßta odovzda¥. Preto ka₧d² protokol ni₧Üej ·rovne mß vo svojej hlaviΦke okrem inΘho uvedenΘ, ktorΘmu z mo₧n²ch kandidßtov vo vyÜÜej vrstve mß dßta odovzda¥.



Obr. 3 Prφklad zapuzdrenia dßt protokolu SMTP


Vlastnosti protokolov
  • Spojovanß slu₧ba (Connection - oriented Service)
    Pou₧φva podobn² princφp ako klasick² telef≤n. Entity na rovnakej ·rovni musia najprv nadviaza¥ spojenie, prostrednφctvom ktorΘho potom komunikuj·. Toto spojenie sa po ukonΦenφ komunikßcie musφ zruÜi¥. Spojenie sa chovß v urΦitom zmysle ako r·ra (pipe), napr. zachovßva sa poradie prenßÜan²ch dßt. S vytvorenφm spojenia a s jeho zruÜenφm je spojenß urΦitß rΘ₧ia, preto sa tento druh slu₧by odpor·Φa pou₧i¥ pri vΣΦÜom objeme prenßÜan²ch dßt.

  • Nespojovanß slu₧ba (Connectionless Service)
    Pou₧φva princφp ako listovß poÜta. JednotlivΘ prenßÜanΘ Φasti dßt m⌠₧u pou₧i¥ r⌠zne cesty a m⌠₧u dorazi¥ v r⌠znom poradφ. Tßto slu₧ba nemß prakticky ₧iadnu rΘ₧iu na zaΦiatku a konci komunikßcie, ale mß vyÜÜiu rΘ₧iu pri prenose jednotliv²ch Φastφ dßt. Je v²hodnΘ ju pou₧i¥ pri menÜom mno₧stve dßt.

  • Spo╛ahlivß slu₧ba (Reliavle Service)
    Nikdy nestrßca ₧iadne dßta. ZvyΦajne sa pou₧φva mechanizmus potvrdzovania (ok - opakova¥ prenos). Tento vÜak zvyÜuje rΘ₧iu a Φasto m⌠₧e by¥ opakovanie prenosu nevhodnΘ, napr. pri digitßlnom prenose zvuku (real time).

  • Nespo╛ahlivß slu₧ba (Unreliable Service)
    PresnejÜie slu₧ba zabezpeΦuj·ca vysok·, ale nie stopercentn· spo╛ahlivos¥. Mß vÜak menÜiu rΘ₧iu a preto je r²chlejÜia. Nespo╛ahliv²m typom protokolu je napr. UDP.

  • ZabezpeΦenie dßt pri prenose
    Pri prenose dßt m⌠₧e d⌠js¥ k chybßm. Na ich detekciu, prφpadne opravu, sa pripßjaj· k prenßÜan²m dßtam ∩alÜie dßta, prφpadne sa dßta transformuj· pod╛a presne definovan²ch pravidiel. Prφjemca m⌠₧e po prijatφ a dek≤dovanφ urΦi¥, Φi s· prijatΘ dßta sprßvne, prφpadne ich opravi¥.
BezpeΦnostnΘ k≤dy s· v zßsade dvojakΘho druhu:

1. detekΦnΘ (error - detection code),
2. samoopravnΘ (self - corecting code).

DetekΦnΘ k≤dy sa lφÜia od samoopravn²ch k≤dov v tom, ₧e umo₧≥uj· len rozpoznanie chyby. Poznßme tieto zßkladnΘ typy:
  • ZabezpeΦenie paritou - jednoduch² sp⌠sob, nie je vÜak dostatoΦne spo╛ahliv² (rozpoznßva len nepßrny poΦet ch²b).

  • Hammingov k≤d - patrφ k samoopravn²m k≤dom (na 8 bitov dßt + 5 bitov, na 16 bitov dßt + 6 bitov). ╚asto v praxi nezabezpeΦuje ka₧d² znak, ale cel² blok dßt.

  • Kontroln² s·Φet (CheckSum) - zabezpeΦuje cel² blok dßt. Robφ sa ako s·Φet modulo 28 alebo 216. V²sledkom je kontroln² s·Φet o dσ₧ke 1 alebo 2 bitov.

  • CyklickΘ k≤dy CRC (Cyclic Redundancy Check) - naj·ΦinnejÜia forma zabezpeΦenia. Naprφklad zabezpeΦenie pomocov 16 bitov CRC dokß₧e stopercentne odhali¥ chyby a₧ v 16 po sebe nasleduj·cich bitoch, z chyby po vΣΦÜom poΦte bitov na 99,9984%. Na realizßciu sa pou₧φva posuvn² register EX-OR s pevnou maskou, ktorej hodnota je urΦenß generuj·cim polyn≤mom. Napr. pod╛a CCITT (Consultative Committee for International Telegraphy and Telephony) sa odpor·Φa x16+x12+x5+1.

Nespojovanß datagramovß slu₧ba (IP)

Je zßkladnß slu₧ba poskytovanß IP protokolom na ·rovni IP vrstvy. Jeho Üpecifikßcia bola spracovanß v dokumente RFC 791. Ide o nepotvrdzovan· slu₧bu, t.j. IP protokol nezaruΦuje spo╛ahlivΘ doruΦenie datagramu adresßtovi. Ka₧d² paket je smerovan² samostatne.

HlavnΘ funkcie IP protokolu:

  1. Definuje zßkladn· dßtov· jednotku, ktorß je prenßÜanß sie¥ou (IP datagram) a jeho presn² formßt.

  2. Vykonßva smerovanie paketov (v²ber cesty ktorou bude paket vyslan²).

  3. Definuje pravidlß prenosu datagramov - rozhoduje ako maj· routery spracovßva¥ pakety, za ak²ch okolnostφ s· generovanΘ chybovΘ sprßvy a pod.

  4. Prepojenie internetovej a transportnej vrstvy stσpca protokolov TCP/IP. V hlaviΦke IP datagramu je pole identifikuj·ce pomocou Φφsla protokol transportnej vrstvy, pre ktor² s· dßta urΦenΘ. Znßmym protokolom s· priradenΘ pevnΘ Φφsla Ütandardom Assigned Number (RFC 1340). Naprφklad TCP mß Φφslo 6, UDP Φφslo 17.

  5. Fragmentßcia a opΣtovnΘ zostavovanie datagramov. Ide o to, ₧e r⌠zne siete sa okrem inΘho lφÜia tie₧ maximßlnou ve╛kos¥ou paketu, ktor² s· schopnΘ prenies¥. Tento parameter sa oznaΦuje MTU (Maximum Transmission Unit). Minimßlne MTU, ktorΘ musφ ka₧d² poΦφtaΦ/router podporova¥, je 576 oktetov. Pri prechode datagramu routerom zo siete s vΣΦÜφm MTU do siete s menÜφm MTU sa musφ vykona¥ fragmentßcia (rozdelenie) p⌠vodnΘho datagramu na nieko╛ko menÜφch Φastφ. Ak bol raz datagram fragmentovan², pokraΦuj· tieto fragmenty po cel² zvyÜok cesty ku koneΦnΘmu adresßtovi ako nezßvislΘ datagramy (aj ke∩ prechßdzaj· sie¥ou, ktorß mß dostatoΦne ve╛kΘ MTU na znovuzostavenie do p⌠vodnΘho datagramu). OpΣtovnΘ znovuzostavenie fragmentovan²ch datagramov v TCP/IP vykonßva v₧dy a₧ koncov² poΦφtaΦ-adresßt.

Formßt IP datagramu

Podobne, ako ka₧d² in² druh paketu, mß IP datagram (obr. 4) dve Φasti:

  1. Riadiaca Φas¥ - je tvorenß hlaviΦkou datagramu.

  2. Dßtovß Φas¥ - obsahuje dßta.



Obr. 4: Formßt IP datagramu

V²znam jednotliv²ch polo₧iek IP datagramu je nasledovn²:

VERSION - prvΘ Ütyri bity tvoria verziu protokolu (v s·Φasnosti sa pou₧φva verzia 4),

HEADER LENGTH - dσ₧ka zßhlavia datagramu v 32-bitov²ch slovßch,

TYPE OF SERVICE - typ po₧adovanej slu₧by, ktorß mß by¥ pou₧itß pre prenos datagramu,

TOTAL LENGTH - celkovß dσ₧ka datagramu v oktetoch,

IDENTIFICATION - jednoznaΦnß identifikßcia datagramu, poradovΘ Φφslo,

FLAGS - prφznaky ovplyv≥uj·ce fragmentßciu, m⌠₧u to by¥ dve hodnoty:
D - zßkaz fragmentßcie datagramu,

M - nasleduj· ∩alÜie fragmenty danΘho datagramu.
FRAGMENT OFFSET - pozφcia od zaΦiatku dßtovej Φasti fragmentu vzh╛adom k p⌠vodnΘmu datagramu, z ktorΘho tento fragment vznikol (nßsobok 8 oktetov),

TIME-TO-LIVE - ₧ivotnos¥ datagramu v sekundßch. Po ka₧dom prechode routerom sa tßto hodnota dekrementuje o 1; ak sa znφ₧i na 0 je datagram zniΦen²,

PROTOCOL - urΦuje protokol vyÜÜej vrstvy,

HEADER CHECKSUM - kontroln² s·Φet IP hlaviΦky (nie dßt),

SOURCE IP ADDRESS - zdrojovß adresa odosielate╛a,

DESTINATION IP ADDRESS - cie╛ovß adresa prijφmate╛a,

OPTIONS - volite╛nΘ polo₧ky; nepovinnß Φas¥, m⌠₧e obsahova¥ nieko╛ko nastavenφ:
  1. Record route - zaznamenßvanie cesty datagramu internetom.
  2. Strict source route - odosielate╛ striktne predpφÜe cel· cestu datagramu.
  3. Loose source route - odosielate╛ predpφÜe minimßlnu cestu datagramu.
  4. Timestamp - zaznamenßvanie cesty datagramu internetom so zaznamenßvanφm Φasu prechodu jednotliv²mi routrami.
  5. Security - stupe≥ utajenia.
PADDING - zarovnßvanie na 32-bitov· hranicu.

Spojovanß transportnß slu₧ba (TCP)

Protokol TCP realizuje spojovan· slu₧bu na ·rovni transportnej vrstvy, zabezpeΦuje spo╛ahlivΘ doruΦenie sprßvy adresßtovi. èpecifikßcia TCP je obsiahnutß v RFC 793. Na protokole TCP je zalo₧en² aj SMTP protokol, pou₧φvan² pre prenos sprßv elektronickej poÜty.

Vlastnosti TCP protokolu:

  • spo╛ahlivß transportnß slu₧ba zabezpeΦuj·ca doruΦenie vÜetk²ch prenßÜan²ch dßt, tak ako ich odosielate╛ vyslal (tzn. bez straty a skreslenia dßt alebo bez duplicitn²ch paketov),

  • spojovanß slu₧ba (existuje fßza spojenia medzi dvomi procesmi, fßza prenosu dßt a fßza ukonΦenia spojenia),

  • bufferovanΘ vysielanie zabezpeΦuj·ce efektφvne vyu₧itie prenosov²ch kanßlov, t.j. odosielate╛ zaΦne vysiela¥ a₧ vtedy, ke∩ sa nazbiera dostatoΦnΘ mno₧stvo dßt,

  • transparentn² prenos ╛ubovo╛n²ch dßt,

  • plne duplexnΘ spojenie - s·Φasn² obojsmern² prenos dßt,

  • rozliÜuje medzi viacer²mi potencißlnymi adresßtmi na danom poΦφtaΦi (pomocou portov). Porty sa rozde╛uj· na vyhradenΘ, ktor²ch Φφsla s· menÜie ne₧ 1024 a efemΘrne, ktorΘ s· volenΘ ╛ubovo╛ne a umo₧≥uj· naprφklad na jednom poΦφtaΦi s·Φastne spusti¥ viacej klientov rovnakej sie¥ovej slu₧by. SMTP protokol mß vyhraden² port 25, POP3 protokol PORT 110.



Obr. 5: Formßt TCP segmentu

V²znam jednotliv²ch polo₧iek TCP segmentu je nasledovn²:
DESTINATION PORT - identifikßtor cie╛ovΘho procesu adresßta,

SEQUENCE NUMBER - je offset prvΘho dßtovΘho oktetu tohoto segmentu vzh╛adom k celej sekvencii dßt urΦen²ch k vysielaniu,

ACKNOWLEDGEMENT NUMBER - ak je nastaven² prφznak ACK, obsahuje tßto polo₧ka sekvenΦnΘ Φφslo nasleduj·ceho oktetu, ktor² je prφjemca pripraven² prija¥,

HEADER LENGTH - dσ₧ka hlaviΦky TCP v 32-bitov²ch slovßch,

FLAGS - predstavuj· nasleduj·ce prφznaky:
  1. URG - tento segment by mal by¥ doruΦen² prφjemcovi Φo najr²chlejÜie. ako to je len mo₧nΘ, polo₧ka Urgent pointer je platnß.
  2. ACK - potvrdzuje platnos¥ polo₧ky.
  3. PSH - po₧iadavka okam₧itΘho doruΦenia tohoto segmentu protokolu vyÜÜej vrstvy.
  4. RST - reset spojenia.
  5. SYN - aktφvna ₧iados¥ o zriadenie spojenia, tzv. synchronizßcia sekvenΦn²ch Φφsel prijφmaΦa a vysielaΦa.
  6. FIN - ukonΦenie spojenia (odosielate╛ vyslal vÜetky dßta).
WINDOW - je ve╛kos¥ okna v oktetoch (odosielate╛ oznamuje, ak² poΦet oktetov je schopn² prija¥),

CHECKSUM - kontroln² s·Φet,

URGENT POINTER - Üpecifikuje posledn² oktet urgentn²ch dßt (s·Φet Urgent pointer a Sequence number dßva sekvenΦnΘ Φφslo poslednΘho oktetu urgentn²ch dßt),

OPTIONS - volite╛nΘ polo₧ky (napr. maximßlna ve╛kos¥ segmentu, ktor² m⌠₧e by¥ prijat²).

Nespojovanß transportnß slu₧ba (UDP)

UDP (User Datagram Protokol) podobne ako protokol IP, poskytuje nespojovan· slu₧bu prenosu dßt s nezaruΦenou spo╛ahlivos¥ou a vyu₧φva na tento ·Φel vrstvu IP. Oproti protokolu IP pridßva schopnos¥ rozlφÜi¥ viacej adresßtov vo vn·tri cie╛ovΘho adresßta. UDP protokol bol zverejnen² v dokumente RFC 768.

┌Φelom UDP protokolu je:

  • primßrny mechanizmus pre posielanie datagramov medzi aplikaΦn²mi procesmi,
  • rozliÜuje procesy na danom poΦφtaΦi pomocou portov.



Obr. 6: Formßt UDP datagramu

V²znam jednotliv²ch polo₧iek UDP paketu je nasledovn²:
SOURCE PORT - identifikßtor volaj·ceho procesu (nepovinn², vypl≥uje sa len v prφpade, ke∩ je po₧adovanß odpove∩),

DESTINATION PORT - identifikßtor cie╛ovΘho procesu,

LENGTH - dσ₧ka celΘho UDP paketu v oktetoch,

CHECKSUM - kontroln² s·Φet.
U₧Üφ vz¥ah a vzßjomnß zßvislos¥ spomφnan²ch protokolov je graficky znßzornenß na obr. 7. Z obrßzku je vidie¥, ktorΘ protokoly vyu₧φvaj· slu₧by TCP, ktorΘ UDP, a ktorΘ s· zalo₧enΘ na priamej komunikßcii s fyzickou vrstvou.



Obr. 7: Vzßjomnß zßvislos¥ zßkladn²ch protokolov rodiny TCP/IP


Adresovanie v TCP/IP

Ka₧d² poΦφtaΦ TCP/IP siete mß pridelen· jednoznaΦn· 32 bitov· IP adresu, ktorß je pou₧φvanß pri komunikßcii s t²mto poΦφtaΦom. Pokia╛ mß poΦφtaΦ viacej sie¥ov²ch rozhranφ (naprφklad router), potom ka₧dΘ toto rozhranie musφ ma¥ jednoznaΦn· IP adresu. KoncepΦne je ka₧dß IP adresa tvorenß dvojicou (NetID, HostID), kde NetID (Network identifier) Üpecifikuje sie¥ a HostID (Host identifier) Üpecifikuje poΦφtaΦ pripojen² do tejto siete.

Adresn² priestor je rozdelen² do nasleduj·cich tried (obr. 8):

Trieda A
Prv² bit adresy v tejto triede je 0; v Ütandardnom zßpise IP adresy je teda prvß zo Ütvorice bajtov v rozmedzφ 0 - 127. Prv² bajt je tu NetID a zvyÜnΘ tri HostID. Trieda A umo₧≥uje adresova¥ 125 sietφ a ka₧dß z nich m⌠₧e ma¥ presne 16 777 214 stanφc.

Trieda B
PrvΘ dva bity s· 10; prv² bajt je v rozmedzφ 128 - 191. V tejto triede s· ╛avΘ dva bajty NetID a pravΘ dva HostID. Trieda B umo₧≥uje adresova¥ 16 382 sietφ a v ka₧dej z nich m⌠₧e by¥ a₧ 65 534 stanφc. Tieto adresy sa hodia pre siete ve╛k²ch inÜtit·ciφ, ako s· univerzity a pod. Sie¥ovΘ adresy tohto typu s· vÜak dnes u₧ prakticky vyΦerpanΘ.

Trieda C
PrvΘ tri bity s· 110; prv² bajt je v rozmedzφ 192 - 223. Tri bajty z╛ava predstavuj· NetID a iba posledn² bajt napravo je HostID. Trieda C pokr²va 2 097 150 sietφ, ale priestor pre stanice je obmedzen² Φφslom 254.

Trieda D
PrvΘ Ütyri bity s· 1110; prv² bajt je v rozmedzφ 224 - 239. Trieda D sa pou₧φva pre adresovanie skupiny poΦφtaΦov zßrove≥.

Trieda E
PrvΘ Ütyri bity s· 1111; prv² bajt je v rozmedzφ 240 - 255. Tßto trieda sl·₧i ako rezerva pre bud·ce pou₧itie.

IP adresy sa zapisuj· v tvare Ütyroch dekadick²ch Φφsel navzßjom oddelen²ch bodkou, z ktor²ch ka₧dΘ reprezentuje jeden oktet 32-bitovej IP adresy. Naprφklad: binßrna IP adresa 11000011 10010010 10000000 00111101 sa v dekadickej notßcii zapφÜe 195.146.128.61.

Ka₧dΘ smerovanie paketov medzi jednotliv²mi sie¥ami vykonßvaj· routery v²hradne pod╛a sie¥ovej Φasti IP adresy NetID. Pravidlß pre siete triedy A, B, C je Φasto mo₧nΘ obφs¥ pomocou masky podsiete. To nßm umo₧≥uje ∩alej deli¥ sie¥ tak, ₧e pou₧ijeme viacej bitov pre Φφslo siete a menej bitov pre Φφslo hostite╛a.



Obr. 8: Formßt IP adresy


èpecißlne IP adresy

V adresnom priestore IP adries s· niektorΘ adresy vyhradenΘ pre Üpecißlne ·Φely. S· to adresy urΦenΘ naprφklad pre broadcast, ladenie komunikaΦn²ch programov a pod. Tieto adresy s· rezervovanΘ. OznaΦenie bitov²ch polo₧iek: "0" znamenß "tento/tßto" (poΦφtaΦ, sie¥), "1" znamenß "vÜetky" (poΦφtaΦe).

RozliÜujeme tieto prφpady:

  • Adresa 0.0.0.0 sa interpretuje "tento" poΦφtaΦ na "tejto" sieti. Pou₧φva sa v ·vodnej fßze IP komunikßcie bezdiskovej stanice, ktorß zatia╛ nepoznß svoju IP adresu, ale musφ komunikova¥ napr. pri zavßdzanφ systΘmu cez sie¥ zo servera. Takßto adresa sa nikdy nesmie objavi¥ v poli cie╛ovej adresy.

  • (NetID, HostID = 0): adresa siete naprφklad: 195.146.0.0.

  • Adresa 255.255.255.255 je hromadnß IP adresa (limited broadcast). Pakety s touto adresou s· urΦenΘ vÜetk²m staniciam, ktorΘ sa nachßdzaj· na rovnakej lokßlnej sieti ako odosielate╛. T·to adresu nie je mo₧nΘ nikdy pou₧i¥ ako identifikßciu odosielate╛a.

  • Adresy, ktorΘ maj· Üpecifikovan² NetID a HostID sa skladaj· zo sam²ch jednotiek, naprφklad: 10.255.255.255, 150.111.255.255 Φi 200.111.222.255, s· tzv. riadenΘ hromadnΘ adresy (directed broadcast).

  • 127.x.x.x: softvΘrovß spΣtne vΣzobnß adresa (loopback), lokßlna medziprocesorovß komunikßcia v rßmci jednΘho poΦφtaΦa (bez vysielania do siete), obvykle 127.0.0.1. Ka₧d² paket odovzdan² protokolom TCP alebo UDP je vrßten² spΣ¥, akoby prßve priÜiel z nejakej siete. To umo₧≥uje vyvφja¥ a testova¥ sie¥ov² softvΘr, priΦom nepotrebujete skutoΦn· sie¥. Tßto adresa by sa nikdy nemala objavi¥ v sieti.

Hierarchick² systΘm domΘnov²ch mien (DNS)

Ka₧d² uzol siete Internet je identifikovan² pomocou IP adresy. Tieto adresy pou₧φvaj· vÜetky protokoly. Pre Φloveka je ╛ahÜie zapamΣtate╛nΘ meno ako Φφslica, preto sa zaviedli tzv. domΘnovΘ menß. DNS zabezpeΦuje efektφvne mapovanie a auton≤mne pride╛ovanie mien a je zalo₧en² na hierarchickom decentralizovanom systΘme menn²ch domΘn so stromovou reprezentßciou. Ka₧d² uzol v tomto strome je oznaΦen² re¥azcom dσ₧ky 0 a₧ 63 znakov (doporuΦuje sa pou₧φva¥ sedembitov² ASCII k≤d). HierarchickΘ meno pou₧φva ako separßtor znak "." (naprφklad sun.mtf.stuba.sk).

Tieto re¥azce m⌠₧u obsahova¥ malΘ aj ve╛kΘ pφsmenß, ale pri ich porovnßvanφ, prφpadne inom spracovanφ funkciami operaΦnΘho systΘmu, sa malΘ a ve╛kΘ pφsmenß nerozliÜuj·.

RovnakΘ menß sa nedaj· pou₧i¥ pre uzly, ktorΘ s· s·rodencami, inak je viacnßsobn² v²skyt oznaΦenia uzlov mo₧n².

Uzly nachßdzaj·ce sa bezprostredne pod hlavn²m uzlom ROOT (obr. 9) sa naz²vaj· domΘny najvyÜÜej ·rovne (TLD). Nasleduj·ce domΘny (TLD) oznaΦuj· jednotlivΘ Ütßty, naprφklad .sk znamenß Slovensko, .at Rak·sko, .de Nemecko, .cz ╚esko a pod. ètrukt·ra ∩alej pokraΦuje domΘnami druhej ·rovne (SLD) (u nßs napr. stuba), domΘnami tretej ·rovne (mtf, elf) a menom poΦφtaΦa (sun, decef).



Obr. 9: ètrukt·ra DNS adresy

V USA, v mieste zrodu Internetu, sa na rovnakej ·rovni pou₧φvaj· domΘny oznaΦuj·ce typ uzlov do nich zdru₧en²ch. Ich preh╛ad je uveden² v tab. 1.

Tab. 1: DomΘny najvyÜÜej ·rovne

DomΘna V²znam DomΘna V²znam
edu  Vzdelßvacie inÜtit·cie v USA org  NeziskovΘ organizßcie v USA
gov  Vlßdne inÜtit·cie v USA net  Brßny (gateways) medzi sie¥ami
mil  VojenskΘ inÜtit·cie v USA int  MedzinßrodnΘ organizßcie
com  KomerΦnΘ organizßcie v USA xxx  K≤d Ütßtu (pod╛a ISO 3166)


Vysvetlivky

RFC (Request for Comments) - Sada Φlßnkov, v ktor²ch sa dokumentuj· a zverej≥uj· Ütandardy Internetu, nßvrhy Ütandardov a obecne ods·hlasenΘ myÜlienky.

ISO (International Organization for Standard) - Medzinßrodnß organizßcia pre Ütandardy, tie₧ organizßcia, ktorß definovala r⌠znorod· skupinu sie¥ov²ch protokolov, naz²van²ch protokoly ISO/OSI.

IP (Internet Protocol) - Jeden z najd⌠le₧itejÜφch protokolov, na ktor²ch je Internet zalo₧en². Umo₧≥uje, aby pakety na ceste k svojmu koneΦnΘmu cie╛u prekonali nieko╛ko r⌠znych sietφ.

DNS (Domain Name System) - SystΘm domΘnov²ch mien. Distribuovan² hierarchick² informaΦn² systΘm vyu₧φvan² v IP sie¥ach, umo₧≥uj·ci preklad symbolick²ch domΘnov²ch mien (napr.: www.zoznam.sk) na ΦφselnΘ IP adresy (napr.: 195.85.36.45).

(c) 2004 Ing. Peter GaÜparoviΦ - www.pgasparovic.com

Literat·ra

[1]  Feiber, W.: Encyklopedie poΦφtaΦov²ch sφtφ, Praha, Computer Press, 1996.
[2]  B°ehovsk², P.: Praktick² ·vod TCP/IP, ╚eskΘ Bud∞jovice, KOPP, 1994 .
[3]  èmrha, P. - Rudolf, V.: Internetworking pomocφ TCP/IP, ╚eskΘ Bud∞jovice, KOPP, 1995.
[4]  Hejna, L.: Lokßlnφ poΦφtaΦovΘ sφte, Praha, GRADA, 1994.
[5]  Falk, B.: Pr∙vodce sv∞tem Internetu, Praha, Computer Press, 1995.
[6]  Lhotka, L.: SERVER v INTERNETU, ╚eskΘ Bud∞jovice, KOPP, 1997.
[7]  Peterka, J.: Co je Φφm ... v poΦφtaΦov²ch sφtφch, COMPUTERWORLD, 1994, Φ. 4, 7, 9, 17, 21, 35, 44.
[8]  Sterling, B.: Short History of the Internet, The Magazine of Fantasy and Science Fiction, 1993.
[9]  Dostßlek, L. - Kabelovß, A.: MIME - Multipurpose Internet Mail Extension. http://info.pvt.net/mime.htm, 1997.