Proposed Standard,

Draft Standard, Internet Standard
proces vzniku standardů v Internetu je řešen na principu "zdola nahoru" a "od jednoduššího k dokonalejšímu". Každé řešení, které se má stát standardem, musí projít určitou předepsanou trajektorií - musí být předloženo ve formě tzv. navrhovaného standardu (Proposed Standard), a musí prokázat svou životaschopnost nejméně na dvou na sobě nezávislých implementacích. Nejdříve po půl roce pak může návrh přejít do stádia "Draft Standard" (předběžný standard), ve kterém se musí zdržet nejméně čtvrt roku, a k postupu do finálního stádia "definitivního standardu" (Internet Standard) musí být nashromážděny dostatečné provozní zkušenosti s příslušným řešením. Během všech tří těchto stádií jsou příslušné dokumenty samozřejmě publikovány jako dokumenty RFC.

Pro správné pochopení významu dokumentů RFC je potřebné si ještě uvědomit a náležitě zdůraznit, že jejich obsahem nejsou zdaleka jen standardy - tedy popisy řešení, která mají povahu závazných standardů (byť standardů "de facto", a nikoli "de jure", ale přesto velmi důsledně uznávaných a dodržovaných). Ve formě dokumentů RFC jsou vydávány i jiné dokumenty, například návody, doporučení, či vysvětlení, a v poslední době i stanoviska a názory. Do dnešního dne bylo vydáno více než 2000 dokumentů RFC, a početně mezi nimi převažují právě takovéto ne-standardy. Faktických standardů je tedy početně méně.

RFC number

Dokumenty RFC jsou číslovány - každý nově vydaný dokument je opatřen svým pořadovým číslem, a pod tímto číslem je také nejsnáze a přitom i jednoznačně identifikovatelný (k jednoznačnému určení stačí např. zápisy jako RFC1234, RFC2000 apod.). Další významnou vlastností dokumentů RFC je skutečnost, že se nikdy nemění - jakmile je konkrétní dokument jednou vydán, pod určitým pořadovým číslem, nemění se ani jeho číslo, ani jeho obsah (ani jeho slovní název). Lze jej tedy například "vypálit" na disk CD ROM, či zařadit do anonymního FTP archivu apod., bez obav že by bylo nutné jej někdy měnit. To je samozřejmě velmi výhodné pro distribuci dokumentů RFC, protože se nikdy nemůže stát, že by někdo měl neaktuální verzi nějakého dokumentu RFC - takováto neaktuální verze z principu nemůže existovat. Jak ale potom dokumenty RFC reagují na přirozený vývoj a potřebu změn? Co když je potřeba provést nějakou změnu v tom, co dokument RFC popisuje? Takovéto situace se neřeší změnou již existujícího dokumentu RFC, ale vydáním nového dokumentu, s novým pořadovým číslem (takovým, jaké je právě "na řadě". Tento nový dokument RFC pak ve svém záhlaví nese poznámku o tom, že "zneplatňuje" (činí neplatným) předchozí dokument RFC s příslušným číslem (ev. několik takovýchto dokumentů).

Tradice publikování dokumentů RFC vydržela až do dnešních dnů, a nezanikla ani tím, že z původních postgraduálních studentů se časem stali vážení páni profesoři a lidé, kteří sami rozhodují o věcech zásadních. Změnil se ale věcný obsah a celkový smysl dokumentů RFC - s postupem času to stále méně byly náměty a nápady, usilující o vznik nějakého řešení, a čím dál tím více to byla tato řešení jako taková. Dnes jsou dokumenty RFC používány jako specifická forma dokumentace, vydávána pro potřeby Internetu (ale nepřímo i pro potřeby mnohem širšího okruhu sítí a služeb).

RFC

(Request For Comment)
k soudobému Internetu se váže mnoho konvencí a zvyků, mezi které patří i způsob publikování nejrůznějších dokumentů, určených široké uživatelské veřejnosti. Historickým vývojem vznikla i tradice publikování dokumentů RFC. Její vznik se datuje do roku 1969, kdy byl uveden do provozu první zárodek sítě ARPANET, ze které se později vyvinul dnešní Internet. Kolem ARPANETu se samozřejmě "motalo" mnoho lidí, včetně postgraduálních studentů, kteří se podíleli na mnoha souvisejících projektech a výzkumných pracech. Jejich postavení jim ale neumožňovalo, aby své četné nápady a podněty, mnohdy velmi užitečné a podnětné, nějak vnucovali svým profesorům a intenzivněji se domáhali jejich pozornosti. Své návrhy proto začali sepisovat ve formě dokumentů, kterým dali výstižné pojmenování Request For Comment (doslova: žádost o komentář), a odpovídající "méně důraznou" formou (formou slušné žádosti a komentář, názor či reakci) je předkládali těm, kterých se týkaly, resp. kteří byli kompetentní je posuzovat, přijímat požadovaná rozhodnutí apod.

WHOIS
protokol, vyvinutý v prostředí TCP/IP pro potřeby vedení databází údajů o uživatelích, zejména o jejich adresách. Existuje i dokonalejší verze (tzv. referral WHOIS, neboli rWHOIS). Dnes ale převažuje použití protokolu LDAP.

Z39.50
protokol pro indexaci a vyhledávání, který se stal základem pro službu WAIS (umožňující plnotextové vyhledávání v databázích dokumentů).

NTP

(Network Time Protocol)
Protokol, sloužící potřebám synchronizace časových základen uzlových počítačů sítě. Lze si jej představit jako prostředek pro oznamování aktuálního času, na jehož základě si jednotlivé uzly "seřizují" svoje individuální hodinky.

LDAP (Lighweight Directory Access Protocol)
protokol určený pro udržování adresářů a práci s informacemi o uživatelích (např. pro vyhledávání adres konkrétních uživatelů v příslušných adresářích, resp. databázích). Protokol LDAP je založen na doporučení X.500, které bylo vyvinuto ve světě ISO/OSI, ale do praxe se ne zcela prosadilo, zejména pro svou "velikost" a následnou "těžkopádnost". Protokol LDAP již ve svém názvu zdůrazňuje fakt, že je "odlehčenou" (lightweight) verzí, odvozenou od X.500.

(Simple Network Management Protocol)
protokol sloužící potřebám správy sítí. Umožňuje průběžný sběr nejrůznějších informací pro potřeby správy sítě, a jejich následné vyhodnocování. Na tomto protokolu je dnes založena většina prostředků a nástrojů pro správu sítě.

rlogin

(remote login)
jednou z nevýhod protokolu Telnet je skutečnost, že při každém přihlášení ke vzdálenému počítači nutí uživatele, aby znovu zadal své "identifikační informace" (jméno a heslo) a sám se přihlásil ("zalogoval") do operačního systému vzdáleného počítače - protokol Telnet nedokáže takovéto přihlášení (login) zajistit sám a automaticky. Důvodem je právě fakt, že netrvá na žádné "příbuznosti" místního a vzdáleného počítače. Proto také nemůže předpokládat, že by se mu mohlo vždy podařit "vytáhnout" potřebné přihlašovací informace z místního počítače a pak je předložit vzdálenému počítači k automatickému přihlášení. Pokud například uživatel pracuje v prostředí MS DOS a prostřednictvím Telnetu se přihlašuje ke vzdálenému počítači (např. Unixovému), prostředí DOS vůbec nezná pojem uživatele, a protokol Telnet tedy ani nemá možnost zjistit jméno svého uživatele. Proto se musí uživatel přihlásit ("zalogovat") sám, ručně. Vedle protokolu Telnet však existuje obdobně zaměřený protokol rlogin (od: remote login, doslova: vzdálené přihlášení), který je schopen sám zajistit automatické přihlášení (zalogování) do vzdáleného počítače - ovšem za cenu toho, že obě komunikující strany musí stát na stejné platformě (v zásadě jen na platformě Unixu).

Telnet

protokol Telnet slouží pro tzv. vzdálené přihlašování, neboli k tomu, aby se uživatel jednoho počítače dostal do stejného postavení, jaké má uživatel jiného (vzdáleného) počítače - a mohl si zde například spouštět různé aplikace a pracovat s nimi, a využívat tak výpočetní kapacitu vzdáleného počítače, či jeho další zdroje (aplikace, soubory, periferie apod.). Protokol Telnet je koncipován tak, aby umožňoval "spolupráci" různých platforem - nepožaduje nic specifického na platformě počítače, ze které se uživatel přihlašuje ke vzdálenému počítači (nepožaduje například, aby to byly počítače se stejným operačním systémem). Díky tomu je například možné, aby se prostřednictvím protokolu Telnet uživatel počítače PC s MS Windows přihlásit na dálku k Unixovému počítači, a pracoval s Unixovými aplikacemi, které běží na tomto vzdáleném počítači (ale na jeho počítači PC by provozovány být nemohly).

NFS

(Network File System)
protokol NFS slouží potřebám plně transparentního sdílení souborů v sítích na bázi TCP/IP, a to zejména v sítích lokálních. Rozdíl mezi sdílením a přenosem souborů (který zajišťuje protokol FTP, ev. TFTP) je v tom, zda si klient uvědomuje rozdíl mezi "místními" a "vzdálenými" soubory či nikoli. V případě přenosu souborů je pro klienta zásadní rozdíl mezi "místními" soubory, které se nachází na jeho počítači, a soubory vzdálenými, které se nachází na jiném počítači (FTP serveru) - s těmito vzdálenými soubory musí manipulovat jinak, než s místními soubory (musí vědět, kde se nachází, a pak si je může přenést k sobě prostřednictvím protokolu FTP). Naproti tomu v případě sdílení souborů protokol NFS zajišťuje to, aby se i vzdálené soubory klientovi jevily jako soubory místní - aby klient nemusel vědět kde přesně se nachází, ani nemusel s nimi manipulovat zvláštním způsobem, ale aby se na ně mohl dívat stejně jako místní soubory a stejně tak s nimi manipulovat, jako kdyby to byly jeho místní soubory. Proto je také tento způsob sdílení označován jako plně transparentní (ve smyslu: neviditelný), protože z pohledu klienta skutečně zcela zakrývá fakt, že některé soubory ve skutečnosti jsou vzdálené.

v

(Trivial File Transfer Protocol)
protokol FTP je "plnohodnotný" přenosový protokol, v tom smyslu že je vybaven prakticky všemi mechanismy a vlastnostmi, které jsou zapotřebí pro přenosy celých souborů v počítačových sítích. V některých situacích však tato jeho "plnohodnotnost" může být spíše na závadu, a to kvůli jeho relativně velké složitosti a náročnosti na implementaci. To může vadit například bezdiskovým stanicím, které si potřebují pouze jednorázové stáhnout svůj tzv. boot image (soubor, obsahující vše potřebné k jejich startu), přičemž příslušný kód který toto zajistí musí být co možná nejmenší, tak aby jej bylo možné umístit do pevné paměti (např. paměti ROM) v bezdiskové stanici. Pro takovéto účely byl vyvinut protokol TFTP (Triviální FTP), jako maximálně odlehčená verze protofolu FTP. Odlehčená je například v tom, že nezná pojem uživatele a přístupových práv, nezná pojem aktuálního adresáře, a neumožňuje procházet adresáři serveru, ze kterého jsou soubory stahovány - TFTP klient nemůže na serveru nic vyhledávat, a místo toho musí "jít na jistotu" pro konkrétní soubor který potřebuje.

FTP

(File Transfer Protocol)
protokol pro přenos souborů mezi uzlovými počítači sítě. Předpokládá existenci FTP serverů (nazývaných též FTP archivy), což jsou v zásadě běžné uzlové počítače s možností přístupu do jejich systému souborů na dálku - uživatel jiného uzlového počítače v roli FTP klienta pak může z FTP serveru "stahovat" soubory směrem k sobě (provádět tzv. download"), nebo naopak soubory umisťovat na FTP server (provádět tzv."upload"), podle konkrétních přístupových oprávnění, která mohou být v rámci FTP nastavována pro jednotlivé konkrétní uživatele.

NNTP

(Network News Transfer Protocol)
protokol pro distribuci síťových novin, resp. jednotlivých příspěvků v rámci diskusních skupin (newsgroups) síťových novin (USENET-u). Tento protokol musel být vyvinut poté, co se síťové noviny "přestěhovaly" do Internetu - tj. začaly být šířeny především prostřednictvím Internetu.

SMTP

(Simple Mail Transfer Protocol)
poštovní protokol pro vzájemnou komunikaci mezi poštovními servery, prostřednictvím kterého si jednotlivé servery předávají mezi sebou konkrétní zprávy. Protokol SMTP předpokládá trvalou dostupnost příjemce i odesilatele - pokud se odesílajícímu poštovnímu serveru nepodaří zkontaktovat přijímající poštovní server, interpretuje to jako chybu a snaží se ji napravit opakováním pokusů o přenos. Kvůli této své vlastnosti protokol SMTP není použitelný pro přenos poštovních zpráv až ke koncovým poštovním klientům, kteří nemusí být trvale dostupní. Pro tyto účely musely být vyvinuty další protokoly, konkrétně protokoly POP3 (Post Office Protocol, verze 3) a IMAP (Internet Message Access Protocol).

Aplikační protokoly TCP/IP

HTTP (HyperText Transfer Protocol)
protokol pro komunikaci mezi WWW servery a jejich klienty (browsery). Umožňuje browseru vyžádat si na serveru konkrétní WWW stránku, kterou mu server následně zašle. Protokol HTTP je koncipován jako bezestavový, což znamená že každý požadavek je samostatný a nemá žádnou návaznost na žádný z případných předchozích požadavků - jinými slovy: WWW server si nemusí nic pamatovat o předchozí komunikaci s kterýmkoli klientem, a každý požadavek vyřizuje jako kdyby byl první (jediný).

DHCP

(Dynamic Host Control Protocol)
Protokol BOOTP je řešení, které je už delší dobu k dispozici, a v době jeho vzniku nemohly být anticipovány všechny potřeby v oblasti dynamického poskytování konfiguračních informací nejrůznějším síťovým uzlům a jejich správy. Proto je vcelku přirozené, že se časem objevily novější a propracovanější protokoly, schopné nahradit základní funkčnost protokolu BOOTP a poskytnout i mnoho dalších potřebných funkcí. Příkladem je protokol DHCP (Dynamic Host Control Protocol), často nesprávně považovaný za proprietární řešení firmy Microsoft - ta jej totiž implementovala ve svých produktech jako první (a podpora je DHCP standardní součástí všech implementací TCP/IP v prostředích MS Windows). Protokol DHCP (stejně jako BOOTP) přitom vychází z architektury klient/server a počítá s existencí konfiguračního serveru (DHCP serveru), který poskytuje potřebné konfigurační informace uzlům, které vůči němu vystupují jako jeho klienti. Jednou z jeho odlišností oproti protokolu BOOTP je například to, že dokáže "propůjčovat" svým klientům IP adresy pouze dočasně, jen na dobu jejich skutečné potřeby, a pak je zase odebírat a využívat jinak.

BOOTP

(Bootstrap Protocol)
Každý uzel v TCP/IP síti musí být vybaven určitou základní množinou konfiguračních informací - musí znát svou vlastní IP adresu, musí znát IP adresu alespoň jednoho směrovače, vedoucího ven z jeho dílčí sítě do ostatních sítí, dále musí znát adresu alespoň jednoho DNS serveru, aby věděl kam se má obracet se svými požadavky na převod symbolických doménových jmen na číselné IP adresy. Tyto informace mohou být každému uzlů doslova "vrozeny" - může si je uchovávat přímo u sebe, nejspíše na svém pevném disku, nebo je dokonce může mít "vypáleny" ve vhodné pevné paměti. Z hlediska správy sítě i správy aplikací to ale není nejvhodnější řešení, a v případě tzv. bezdiskových stanic dokonce řešení nemožné. Součástí rodiny protokolů TCP/IP jsou ale i takové protokoly, které umožňují aby si takovéto konfigurační informace každý uzel mohl dynamicky získat od někoho, kdo je ochoten mu je poskytnout - od specializovaného konfiguračního serveru, na kterém jsou potřebné informace uchovávány a kde mohou být také centrálně spravovány. Protokol BOOTP slouží právě tomuto účelu, a vychází vstříc dokonce i bezdiskovým stanicím, kterým umožňuje tzv. počáteční zavedení jejich operačního systému (tzv. bootstrap, odsud také jeho název) - protokol BOOTP poskytne startující (tzv. bootující) stanici přesný odkaz na místo, odkud si může vyzvednou svůj operační systém a vše, co potřebuje ke svému startu (tzv. boot image).