Transportní vrstva: Porovnání verzí
(Nová stránka: S transportní vrstvou se u routování moc nesetkáme, ale pro další články, které budou zahrnovat nastavení firewallu, se s ní aspoň částečně seznámíme. Transportní...) |
Bez shrnutí editace |
||
Řádek 8: | Řádek 8: | ||
U UDP se takto složitý proces spojení nekoná, protože je bezestavový. Data prostě odcházejí a není jisté, jestli přijdou, v jakém pořadí přijdou a nemůžeme oddělovat ani stavy spojení. Nerozlišuje se ani, jestli druhá strana naslouchá nebo ne, data se pouze odesílají a možná přijímají. UDP se hodí všude tam, kde drobné nedokonalosti v přenosu nevadí. Běžně streamování hudby nebo videa. Na UDP je postavený i přenos dat přes NFS, ale tam se o samotnou bezpečnost dat stará NFS samotné. | U UDP se takto složitý proces spojení nekoná, protože je bezestavový. Data prostě odcházejí a není jisté, jestli přijdou, v jakém pořadí přijdou a nemůžeme oddělovat ani stavy spojení. Nerozlišuje se ani, jestli druhá strana naslouchá nebo ne, data se pouze odesílají a možná přijímají. UDP se hodí všude tam, kde drobné nedokonalosti v přenosu nevadí. Běžně streamování hudby nebo videa. Na UDP je postavený i přenos dat přes NFS, ale tam se o samotnou bezpečnost dat stará NFS samotné. | ||
*[[NAT]] | *[[NAT]] |
Aktuální verze z 6. 1. 2009, 10:15
S transportní vrstvou se u routování moc nesetkáme, ale pro další články, které budou zahrnovat nastavení firewallu, se s ní aspoň částečně seznámíme.
Transportní vrstvu představují protokoly UDP a TCP, přičemž první zmiňovaný nezaručuje doručení dat a jejich správnost, druhý pro změnu ano, i za cenu větší režie. Oba protokoly slouží primárně k odlišení jednotlivých spojení na jedné IP adrese. Představme si, že máme web server, kam se připojuje 100 uživatelů. Každý z nich se připojí na naši IP adresu a chce odpověď. Jak oddělíme jednotlivá spojení od možnosti další komunikace? Použijeme tzv. porty. Na každé IP adrese může být teoreticky navěšeno 65535 odchozích spojení, které je možné oddělit.
Abychom se dostali pod pokličku celkovému vytvořenému spojení, řekneme si, jak se k němu dostaneme. Vezměme si za příklad již zmíněnou komunikaci s web serverem. Pokud se rozhodneme poslat požadavek na server, náš počítač se začne "pídit" po IP adrese web serveru. Dejme tomu, že ji máme a nastává spojovací proces. Počítač pošle do sítě broadcast, kde se ptá pomocí protokolu ARP na MAC adresu, které patří IP adresa brány (pokud je webserver mimo náš segment sítě). Pokud se mu ji podaří zjistit, začne vytvářet dotaz. Zatím jsou nám data ke skutečnému požadavku k ničemu. Vytvoří TCP paket s cílovým portem číslo 80 a nějakým vybraným zdrojovým portem a nastaví mu flag SYN. Dále přilepí IP hlavičku se zdrojovou IP adresou (našeho počítače) a cílovou adresou webového serveru. Poté vezme svoji MAC adresu a MAC adresu brány a přilepí poslední hlavičku linkové vrstvy. Tento paket odešle do sítě, switch ho přehodí směrem k bráně, ta na paketu odlepí hlavičku linkové vrstvy, koukne do routovací tabulky, jestli v ní není něco o cílovém stroji a pokud ne, zeptá se opět na MAC adresu brány, přilepí novou linkovou hlavičku a odesílá paket dál. Takto paket projede blíže nespecifikovanou cestu a když se dostane do segmentu sítě, kde se nachází tento stroj, tak se místo na MAC adresu brány začne ptát router na adresu toho konkrétního stroje. Opět je linková hlavička odlepena a přidána nová, tentokrát s adresou konkrétního stroje. Když tam tento paket dorazí, stroj posílá paket zpět, kde hlavním rozdílem je flag v TCP paketu, který je tentokrát SYN. Hned za nim následuje paket ACK. Pokud oba dorazí, tak původní počítač posílá zpátky také ACK. Až v tuto chvíli může začít skutečná komunikace. Během tohoto tzv. čtyřcestného handshaku se vždy prohodí cílové IP adresy a porty. MAC adresy mohou být různé během celé komunikace, protože pakety nemusí vždy jet stejnou cestou.
Máme-li takto navázané spojení, počítač může vzít náš HTTP požadavek a poslat ho směrem na server, který na něj odpoví. Pokud už dále komunikovat nepotřebujeme, tak se posílá TCP paket s flagem FIN, který nepotřebuje potvrzení. Od strany, která FIN odeslala, už nepřijdou žádná data v rámci vytvořeného spojení. Pokud se FIN ztratí, platnost spojení časem vyprší.
U UDP se takto složitý proces spojení nekoná, protože je bezestavový. Data prostě odcházejí a není jisté, jestli přijdou, v jakém pořadí přijdou a nemůžeme oddělovat ani stavy spojení. Nerozlišuje se ani, jestli druhá strana naslouchá nebo ne, data se pouze odesílají a možná přijímají. UDP se hodí všude tam, kde drobné nedokonalosti v přenosu nevadí. Běžně streamování hudby nebo videa. Na UDP je postavený i přenos dat přes NFS, ale tam se o samotnou bezpečnost dat stará NFS samotné.