Když prohlížeč zobrazuje webové stránky příslušející např. doméně http://www.python.org, z hlediska uživatele se toho zdánlivě moc nestane – prostě napíšeme do adresního řádku adresu (většinou i bez identifikace protokolu http://) a na obrazovce se nám „magicky“ objeví požadovaná stránka.

Z hlediska prohlížeče se toho ale musí (či může) stát mnohem více, než by člověk nejen na první pohled čekal. Podívejme se tomu na zoubek trošku podrobněji.

Předně – pro někoho asi trochu překvapivě – se vůbec nemusíme dívat na skutečně aktuální podobu příslušné stránky. Někde cestou od nás k cílovému zdroji totiž může být uložena starší kopie, které dosud nevypršela doba platnosti. Konkrétně:

1. Prohlížeč může požadovaný zdroj nalézt s dosud nevypršenou dobou platnosti ve své vlastní vyrovnávací paměti.
2. Nebo se kopie zdroje může nacházet kdesi cestou v některé ze síťových vyrovnávacích pamětí (typicky proxy-server vašeho poskytovatele připojení).

Teprve pokud nic z výše uvedeného nenastane, stáhne se požadovaný zdroj z původního umístění.

Dotaz k získání požadovaného zdroje je vyslán protokolem HTTP. Můžeme si ho názorně nasimulovat pomocí protokolu telnet. Přitom je třeba vědět, že (není-li uvedeno jinak) protokol HTTP je na cílovém počítači obsluhován službou (programem) naslouchajícím na portu 80. Proto (komentáře po znaku # nejsou součástí dotazu ani odpovědi!):

Odpověď na dotaz obsahuje nejdříve návratovou HTTP-hlavičku (s kódem odpovědi 200, tedy že požadovaný zdroj byl skutečně nalezen a bude vrácen) a po \r\n (tedy carriage return + line feed) vlastní data (o délce 18 915 bajtů, jak je též oboje uvedeno v hlavičce).

K zaslání dotazu jsme museli vědět, že HTTP-dotazy jsou na cílovém stroji obsluhovány na portu 80. Cílový stroj jsme přitom zadali pomocí jeho „lidského“ názvu. To ale není identifikace, kterou by použil počítač – ten si musel zjistit IP-adresu (ať už IPv4 nebo IPv6):

Pomocí jiného programu můžeme přijít i na to, od koho jsme danou odpověď získali:

Jak ale počítač vůbec zjistí, koho a jak se ptát?

V internetové prehistorii sloužil k překladu soubor hosts, který musel správce každého počítače připojeného do sítě pravidelně obnovovat z centrálního úložiště. Ještě dnes je tento soubor k dispozici, ale slouží už poněkud jinému účelu (pokud je vůbec nějak využit). Ale je jasné, že s přibývajícím počtem připojených počítačů to bylo neudržitelné.

Proto byl vynalezen protokol DNS (z Domain Name System). Podívejme se, jak vypadá dotaz na zjištění IP-adresy uvedené domény:

Vysvětlivky:

• Příznak any vrátí odpověď na všechny možné dotazy, které je možno položit.
• Příznak +multiline slouží (pouze) k úpravě výpisu SOA-záznamu do čitelnější podoby (kde SOA = Start Of Authority, tedy autoritativní údaje o příslušné DNS-zóně).
• AAAA je IPv6-adresa.
• A je IPv4-adresa.
• MX je odkaz na emailový server pro danou doménu.
• A konečně NS je Name Server, tedy počítač starající se o správu DNS-záznamů příslušné domény (nebo obecněji zóny).

Správa jmen na internetu je rozdělena podle logické úrovně – jiné stroje mají na starosti doménu nejvyšší úrovně (TLD = Top Level Domain) org, jiné zase doménu druhé úrovně python (pod doménou org) a případné jiné stroje další poddomény.

Přitom stroje spravující doménu jisté úrovně „ví“, kam (na jaké další DNS-stroje) mají přesměrovat dotazy na nižší podúrovně. Každá část této veliké a značně distribuované databáze se tak „stará“ pouze o svoji příslušnou podčást všech doménových jmen.

Kdyby každý překlad doménového jména na IP-adresu šel celou touto cestou od kořene až po poslední DNS-server, bylo by to strašlivá zátěž na všechny stroje po cestě a především na stroje starající se o kořenovou zónu. Ve skutečnosti se získané odpovědi ukládají do mezipamětí (vyrovnávacích pamětí, cache) spolu s údajem, do kdy jsou platné. Dotaz na překlad pak „probublá“ výše pouze tehdy, není-li příslušné jméno k dispozici v nějakém bližším DNS-serveru.

Jak tedy vypadá celý stromeček DNS-serverů zodpovědných za překlad uvedeného jména na IP-adresu?

Vidíme, že:

• O kořenovou zónu, tj. „tečku“, se stará 13 rozdílných logických strojů (které jsou rozeseté po celém světě a navíc samozřejmě každý z nich představuje celou armádu počítačů se stejnou adresou, které odpovídají na anycastové-dotazy podle nejvýhodnější aktuální dostupnosti).
• Tyto nás přepošlou na 6 logických strojů, které mají na starosti doménu nejvyšší úrovně org.
• Odtud už se dostaneme na name-servery, které obhospodařují doménu druhé úrovně python (jako subdoménu domény org). A vidíme, že se o to nestará organizace Python Software Foundation (která má jinak doménu python.org na starosti, jak bychom zjistili dotazem whois python.org), ale poskytovatel jejího internetového připojení XS4ALL. Není tudíž divu, že..
• ..adresování uvnitř domény python.org (tedy rozlišení mezi doménami třetí úrovně jako jsou např. www.python.org nebo docs.python.org) má na starosti také on.

Nyní už známe většinu částí „vysokoúrovňové“ komunikace na úrovni protokolu HTTP: Pro získání vstupní HTML-stránky na adrese http://www.python.org potřebujeme zaslat HTTP-dotaz (nezapomínejme na povinnou ukončovací prázdnou řádku)..

..na port 80 (základní port HTTP-protokolu) stroje identifikovaného IP-adresou 82.94.164.162 (kterou získáme z DNS překladem jména www.python.org).

Uvedený text HTTP-dotazu na port 80 je ovšem teprve začátek – daný dotaz se totiž musí dostat z našeho počítače (který má také svoji IP-adresu) na počítač cílový, kde bude vyhodnocen, a příslušná odpověď (zde vstupní HTML-stránka) bude vrácena na náš počítač, kde bude zobrazena. A tohle všechno dohromady není vůbec jednoduché:

• Už na první pohled je zřejmé, že výsledkem dotazu může být enormní množství dat (např. video z YouTube.com) – zřejmě uvedená data nebudou přenášena všechna najednou jako jeden „balík“.
• Za druhé data musí „téct“ po nějakém přenosovém médiu (což mohou být klasické nebo optické kabely, ale stejně tak dobře třeba vzduch).
• A za třetí mezi naším a cílovým počítačem téměř určitě (pokud to zrovna není kupříkladu náš přístupový bod do internetu) není přímá linka, data tudíž „tečou“ přes mnoho dalších síťových zařízení či počítačů. Zde je graficky (za pomoci programu Scapy) zobrazena jedna z možných cest:

Data na internetu si postupně předávají jednotlivé služby, které se starají o jejich přeposílání mezi zainteresovanými koncovými uzly:

1. Za „logické“ adresování (tj. od nás ke zdroji a zpět) je zodpovědný protokol IP (Internet Protocol).
2. Za rozložení dat na menší kousky (a pak zase jejich zpětné složení) plus jejich směřování na konkrétní službu je zodpovědný protokol TCP (Transmission Control Protocol).
3. Vlastní přeposílání těchto kousků mezi jednotlivými fyzickými zařízeními na cestě pak má na starosti protokol příslušné fyzické, spojovací vrstvy – pro případ „obyčejného“ síťového kabelu je to nejčastěji Ethernet.

Podívejme se na (zjednodušený) souhrnný diagram „cesty“ jednoho konkrétního HTTP-dotazu:

Od protokolu nejvyšší úrovně (HTTP) až po vlastní přenos signálu (fyzická vrstva) se odehraje následující:

1. Na nejvyšší vrstvě (aplikační vrstva) prohlížeč pomocí protokolu HTTP vyšle dotaz, resp. přijme odpověď, v podobě konkrétně formátovaného řetězce (výše uvedený kód s GET jako dotaz, HTTP-hlavička a HTML-podoba stránky plus obrázky atp. jako odpověď).
2. Na TCP-úrovni (transportní vrstva) jsou přenášená data „rozsekána“ na menší kousky, které jsou „zabaleny“ do „krabice“ (tzv. paket, z anglického packet) s označením pořadového čísla (zjednodušeně řečeno; ale obecně si protokol TCP hlídá, zda a v jakém stavu dorazily všechny odeslané pakety a případný ztracený paket si vyžádá znovu) a mimo jiné portu cílové služby (což je 80 pro protokol HTTP, není-li určeno jinak).
3. Na IP-úrovni (síťová vrstva) je TCP-paket z předchozí vrstvy zabalen do IP-paketu, který se stará o logické adresování v rámci internetu (tj. z jaké a na jakou IP-adresu byla vyslána příslušná data), ale též o to, aby se pakety po netu netoulaly nekonečně dlouho (pomocí pole TTL = Time To Live; viz další bod).
4. Na předposlední vrstvě nad vlastními kabely (nebo jiným médiem; jde o tzv. vrstvu síťového rozhraní) se odehrává fyzické adresování – přeposílání IP-paketů mezi jednotlivými fyzickými zařízeními na cestě mezi oběma komunikujícími počítači. Každý další počítač v cestě rozbalí ethernetový paket určený jemu (paket si nese hardwarovou adresu, tzv. MAC-adresu, následujícího počítače v řetězci síťových zařízení; k jejich nalezení v rámci místní sítě slouží pro IPv4 protokol ARP a pro IPv6 protokol NDP) a podívá se dovnitř na zabalený IP-paket:
   • Je-li určený jemu (odpovídá cílová IP-adresa), rozbalí IP-paket a předá uvnitř se schovávající TCP-paket na příslušnou službu (port).
   • Není-li určený jemu (cílová IP-adresa není jeho vlastní), zmenší pole TTL o jedničku a zabalí takto upravený IP-paket do nového ethernetového rámce (v němž je startovní MAC-adresou jeho vlastní a cílovou pro něj následující síťový stroj).
   IP-paket je tímto „přebalováním“ předáván dál a dál v řadě síťových strojů a to tak dlouho, dokud buď nedojde svého cíle nebo nevyprší jeho TTL.
5. Tyto poslední pakety – v našem případě ethernetové – jsou pak fyzicky přenášeny po nejrůznějších kabelech a skrz nejrůznější propojovací koncovky a další zařízení. Každé konkrétní „zasíťování“ má vlastní protokoly a způsoby přenosu, které nás už nemusí příliš trápit.

Výše popsaný princip zachycuje cestu jednoho konkrétního paketu, ale vlastní TCP-komunikace je podstatně složitější. V principu se dá rozložit na tři stupně:

1. navázání spojení; probíhá také třífázově – klient požádá o spojení (tzv. SYN-paket), server vrátí potvrzení požadavku (paket SYN-ACK), klient potvrdí jeho přijetí (ACK-paket)
2. vlastní přenos dat
3. ukončení spojení

Kromě výše uvedených protokolů můžete také někdy zaslechnout zkratku UDP (User Datagram Protocol):

V podstatě jde o protokol srovnatelný s TCP, ale narozdíl od něj zaručuje pouze integritu paketů (pomocí kontrolního součtu), nikoli už jejich doručení.