JAK SE DOSPĚLO K INTERNETU

Dvě cesty, z nichž jen jedna vedla k vzniku Internetu

Jestli cokoli šlo podle pevně daného plánu, tak pro budování Internetu to rozhodně neplatilo. V žádném případě nebyl vytvářen naráz podle předem “nalinkovaného” plánu. Dvě cesty z názvu daného příspěvku, měly každá svůj vlastní průběh a výsledek.  Základem pro každou cestu byly jejich vzájemně odlišné standardy protokolů pro komunikace a výměnu informací. Na jedné straně to byl transportní protokol TCP (Transmission Control Protocol) a síťový protokol IP (Internet Protocol), v souhrnu TCP/IP, vyvinuté koncem 60. let minulého století jako výzkumný projekt vedený ministerstvem obrany USA. Na druhé straně to byl referenční model propojování otevřených systémů OSI (Open Systems Interconnection) vypracovaný v Mezinárodní organizaci pro standardizaci ISO (International Organization for Standardizaton) již v polovině 70. let minulého století. I když model OSI je lépe strukturovaný než TCP/IP má TCP/IP - starší ze dvou protokolových steků, který se stal základem Internetu - nesrovnatelně větší uživatelskou základnu a nezpochybnitelně dominuje na světovém trhu síťových produktů.

Protokolový stek TCP/IP si vybojoval své prioritní postavení i ve vojenské oblasti a stal se v soudobých systémech C4ISR základem datových i dalších digitálních komunikací. V moderních armádách je síťová architektura TCP/IP základem mobilního taktického internetu na nižších stupních velení, avšak i ostatních vojenských sítí (stacionárního i polního typu). Je na ní založena i komunikační infrastruktura moderních armád pro síťově centrické operace, a to jak v rámci NATO (NNEC), tak i v rámci národních armád (NEC).

Tak vypadá názorné ztvárnění současného Internetu - “celosvětová pavučina”

Úvod

Během 70. let minulého století se stalo zřejmým to, že v oblasti informačních a komunikačních systémů nastane éra budování počítačových sítí a jejich vzájemného propojování za účelem výměny dat a informací, jak na lokální, tak i na globální úrovni. Historie počítačových sítí sahá až do doby, kdy počítače (nejdříve sálové) byly ještě příliš velké a drahé. Pro jejich uživatele bylo výhodné dělit se o jejich výkon po komunikačních sítích. Skutečný bouřlivý rozvoj počítačových sítí však nastal až v době osobních počítačů (PC), které si mohl pořídit téměř každý. Tomu začal odpovídat i charakter a způsob využívání počítačových sítí. Od té doby sítě slouží jak pro sdílení dat a informací i využívání společných zařízení (paměťových polí a datových úložišť, síťových tiskáren a jiných zařízení, tak i pro vstup do podnikových a jiných sítí (typu extranetu) zejména však pro vstup do Internetu a činnost uživatelů v něm (pro účely tohoto článku je slovo Internet psáno s velkým počátečním písmenem).

V Evropě je s začátkem rozvoje počítačových sítí nerozlučně spjato standardizační úsilí věnované vytvoření modelu sedmivrstvé síťové architektury. Na počátku 80. let minulého století byly vytvářeny regionální počítačové sítě, jako byly výzkumné sítě EUNet (European Unix Network) a EARN  (European Academic and Research Network), které používaly  protokol Unix to Unix Copy Protocol (ta první) a Network Job Entry protokol (ta druhá). Růst těchto sítí zaostával daleko za americkou počítačovou sítí ARPANET. Na konci 80. let doporučili provozovatelé těchto sítí přejít na architekturu amerických počítačových sítí založenou na protokolech TCP/IP. I když byla Evropa často považována za baštu standardů ISO/OSI, v roce 1989 byla založena RIPE (Réseaux IP Européene pro koordinaci spolupráce s organizací pro Internet v Evropě. V té době již byly počítačové sítě velkého počtu evropských zemí, včetně Francie, Norska, Švédska, Německa, Itálie a Nizozemska propojeny s americkou sítí vědeckých institucí NSFNET.

Historický přehled

Od vzniku velkých počítačových systémů se pociťovala potřeba vytváření a propojování datových sítí v globálním, celosvětovém měřítku, tedy toho co dnes poskytuje globální Internet. Nyní je zřejmé, že pokud by se počítačové sítě vytvářely a propojovaly podle nějakého předem vypracovaného plánu, pak by Internet, jak jej dnes známe, nikdy nevznikl. Příslušný plán pro globální počítačové sítě byl vymýšlen koncem 70. let minulého století, avšak namísto toho svět dostal ucelenou sadu standardů týkající se počítačových sítí s označením OSI (Open System Interconnection), tj. propojovaní otevřených systémů. Architekty modelu ve formě standardů byli členové vybrané skupiny představitelů počítačového průmyslu Spojeného království, Francie a USA. Ti představili úplný, otevřený a mnohovrstvový systém, který měl umožnit uživatelům v celém světě snadnou výměnu dat, a tedy nové možnosti spolupráce a komerce.

Po nějakou dobu se jejich vize zdála být správnou věcí a skutečným přínosem. Tisíce inženýrů a dalších pracovníků v celém světě byly zapojeny do zavádění standardů OSI. Brzy došlo k jejich podpoře počítačovými a telekomunikačními společnostmi, regulačními orgány států, národními vládami, agenturami stanovícími mezinárodní standardy, akademickými badateli a dokonce i ministerstvem obrany USA. V polovině 80. let se celosvětové přijetí standardů OSI zdálo být neodvratným.

Na počátku 90. let však byl v reakci na levný a hbitý alternativní model s internetovými protokoly TCP a IP (i když zdaleka ne tak úplný jako konkurenční model), projekt OSI zastaven. Když projekt OSI oslábnul, jeden z hlavních stoupenců internetového modelu a průkopník Internetu Einar Stefferud škodolibě pronesl: “OSI je krásný sen, ale TCP/IP je živý”.

Co se stalo s krásným snem? Zatímco práce ve vítězném programu internetového modelu byly jeho tvůrci dobře dokumentovány (spolupracovali na tom i historici), model OSI byl všemi zapomenut, až na hrstku veteránů války mezi internetovým modelem a OSI. Pro pochopení toho, proč se sahá do rané historie tvorby počítačových sítí, pak je to proto, že doba ostrých a tíživých problémů digitální konvergence a globálního propojování značně ovlivňovala vědomí počítačových vědců, telekomunikačních inženýrů, pracovníků legislativy i průmyslových podnikatelů. Historický pohled má svoji důležitost. Jen si aspoň na chvíli představme to, že by Internet nikdy neexistoval.

Příběh se začal psát v 60. letech minulého století. V té době vyrostla Berlínská zeď. Americká vojska bojovala ve Vietnamu. A digitální systémy počítačových komunikací byly ve stavu zrodu, stejně jako předmět intenzivních, široce založených výzkumných prací s účastí tuctu a později stovek lidí v akademické sféře, průmyslu a státních organizacích věnujících se hlavním výzkumným programům.

Neslibnějším směrem z těch, které souvisely s novým přístupem k datovým komunikacím, dostal název přepojování paketů. Byl nezávisle na sobě vynalezen Američanem Paulem Baranem z Rand Corporation a Britem Donaldem Daviesem z anglické National Physical Laboratory a spočíval v tom, že zprávy (tok dat) se rozděloval na diskrétní bloky neboli pakety, které byly separátně směrovány po různých okruzích sítě. Počítač na přijímacím konci zpětně seřadil pakety do jejich původního toku. Oba výzkumní pracovníci, P. Baran a D. Davies věřili, že přepojování paketů je efektivnější a robustnější než přepojování okruhů, stará technologie používaná v telefonních sítích, u které je nutné mít pro každou konverzaci vyčleněný okruh.

V USA výzkumní pracovníci sponzorovaní agenturou ARPA (Advanced Research Projects Agency) ministerstva obrany USA vytvořili první síť s přepojováním paketů nazvanou ARPANET v roce 1969. Zanedlouho připravily své ambiciózní plány na paketově přepojované sítě další instituce, především počítačový obr IBM v USA a některé telefonní monopoly v Evropě. Tyto instituce dokonce zvažovaly digitální konvergenci počítačů a komunikací, znepokojovala je však obava o ochránění jejich tehdy existujících oblastí byznysu. Výsledkem bylo to, že IBM a telefonní monopoly daly přednost způsobu přepojování paketů, závislému na “virtuálních okruzích”, tj. takovému řešení, které napodobovalo technické a organizační praktiky přepojování okruhů.

Aby se zainteresované strany pohnuly dál, dosáhlo se poměrně široké shody o potřebě určité formy mezinárodní standardizace tak, aby se zajistilo, že přepojování paketů bude životné. První pokus byl zahájen v roce 1972 vytvořením mezinárodní pracovní skupiny pro sítě INWG (International Network Working Group). Prvním předsedou byl pozdější americký internetový velikán Vinton Cerf, mezi dalšími aktivními členy byli Alex McKenzie z USA, Donald Davies a Roger Scantlebury ze Spojeného království, a dále Louis Pouzin a Robert Zimmermann z Francie.

Smyslem činnosti INWG bylo prosadit “datagramovou” formu přepojování paketů tak, jak ji navrhl L. Pouzin. Podstata datagramu byla v jeho přenosu bez nutnosti průběžného ustavování spoje (connectionless). To znamená že není nutné žádné nastavení vztahu mezi vysílající a přijímající stranou. Proces přenosu datagramů probíhá separátně, jeden za druhým. To byl radikální návrh, zvláště při srovnání s přenosem s pokaždé ustavovaným spojem jako tomu bylo u virtuálních okruhů preferovaných IBM a telekomunikačními organizacemi.

Pracovní skupina INWG se pravidelně scházela a vyměňovala si technické zprávy, aby se dosáhlo shody jejích návrhů datagramových sítí, jmenovitě pro transportní protokol jako klíčový mechanizmus pro výměnu paketů mezi různými druhy sítí. Po několika letech diskusí dosáhla pracovní skupina v roce 1975 konečnou shodu. V. Cerf a L. Pouzin předložili jejich protokol mezinárodnímu orgánu odpovědnému za dozor a kontrolu telekomunikačních standardů - v tehdejší době CCITT (francouzská zkratka mezinárodního konzultačního výboru pro telegrafii a telefonii, nyní International Telecommunication Union - Telecommunication Standardization Sector ITU-T). Tento výbor, ve kterém převládali odborníci na klasické telekomunikace, odmítl návrh INWG jako příliš riskantní a nedostatečně otestovaný. V. Cerf a jeho kolegové byli tímto rozhodnutím silně rozčarováni. Vint Cerf byl událostmi souvisejícími s postojem CCITT tak znechucen, že koncem roku 1975 rezignoval na post  předsedy INWG. Přijal nabídku pracovat s  Robertem Kahnem v organizaci ARPA. V. Cerf a R. Kahn  využili Pouzinův návrh týkající se datagramů a publikovali podrobnosti jejich pojetí transportního protokolu TCP, uveřejněného rok předtím v prestižním časopise “IEEE Transactions on Communications”. To zajistilo technický základ Internetu (tento název by přijat později, když se jednalo o síť sítí, která by využívala model TCP/IP ARPA).

Odchod V. Cerfa byl příznakem sporů, které panovaly v INWG. Zatímco V. Cerf a další zúčastnění pracovníci z ARPA nakonec v 80. letech vytvořili  jádro americké internetové komunity, mnozí z dalších veteránů INWG se přeskupili a připojili k mezinárodní alianci jako zastánci modelu OSI. Tyto dva tábory se staly velkými rivaly.

V roce 1977 navrhli představitelé britského počítačového průmyslu vytvořit nový standardizační výbor věnující se sítím s přepojováním paketů v rámci mezinárodní organizace pro standardizaci ISO, nezávislé a nestátní asociace vytvořené po druhé světové válce v rámci OSN. Na rozdíl od CCITT se ISO nesoustřeďovala speciálně na telekomunikace, nýbrž v působnosti jejích technických výborů byl široký rozsah oblastí, od TC1 pro standardy na závity šroubů, po TC17 pro standardy na ocele. Rovněž, na rozdíl od CCITT, ISO již měla výbory pro počítačové standardy a bylo pravděpodobné že přijme k standardizaci problematiku přenosu datagramů bez ustavování spoje.

Britský návrh, který měl podporu představitelů USA a Francie prosazoval potřebu síťových standardů pro otevřené systémy, což mělo představovat alternativu tradičním samostatným, tedy “uzavřeným”, systémům, které byly vytvořeny bez ohledu na možnost jejich vzájemného propojení v síti. Koncept provozu otevřených systémů měl strategický význam a přinášel možnost konkurovat velkým hráčům, jakými byly např. IBM a telekomunikační monopoly. Jak se dalo očekávat, ISO schválilo britský návrh a předsedou příslušného výboru jmenovalo amerického databázového experta Charlese Bachmana, již předtím vyznamenaného prestižní Turingovou cenou. Pod jeho vedením byla zahájena specifikace referenčního modelu, který rozdělil různé operace počítačových komunikací do jednotlivých vrstev (jak bude zřejmé z dalšího textu). Po stanovení vrstvové architektury proběhl vývoj příslušných protokolů pro jednotlivé vrstvy. Průběh v čase s jednotlivými klíčovými body je graficky znázorněn níže na přehledovém obrázku historického procesu rozvoje síťových architektur.

Přehledový obrázek procesu rozvoje síťových architektur

Vrstvový referenční model OSI také zajistil důležitou organizační vlastnost pro práce na modelu - modularitu. Uspořádání do vrstev umožnilo výboru efektivní dělbu práce. Bachmanův referenční model se stal důležitým výchozím bodem. Ovšem k tomu, aby se mohl stát mezinárodním standardem musel, jako každý jiný návrh, projít procesem který zahrnoval čtyři kroky, počínaje pracovním dokumentem, pak předběžnou verzí návrhu mezinárodního standardu, dále návrhem mezinárodního standardu a nakonec teprve mezinárodním standardem. Dosažení konsenzu na referenčním modelu OSI a souvisejících standardech si vyžádalo značný počet zasedání výboru i pléna. Zúčastnily se tucty delegátů z 10 zemí a pozorovatelé ze čtyř mezinárodních organizací. Každý, kdo se zúčastnil, měl samozřejmě své obchodní zájmy související s konkrétními projekty zastupovaných organizací. I delegáti z téže země měli často odlišné programové přístupy. Mnozí byli veterány INWG, kteří si zachovali opatrný optimizmus v tom, že budoucnost datových sítí může být vyrvána z rukou IBM a telefonních monopolů, které měly jasné úmysly dominovat na důležitých trzích.

Bachmanovo vedení urychlilo postup OSI po riskantní cestě od vize k realitě. Charles Bachman a Hubert Zimmermann (veterán francouzské sítě “Cyclades” a pracovní skupiny INWG) zapomněli na nevydařené spojenectví  s telekomunikačními odborníky v CCITT. Bývalé partnerství umožnilo překonat zásadní nekompatibilitu mezi jejich názory na svět počítačových sítí. H. Zimmermann a jeho ‘počítačoví kolegové’, inspirovaní Pouzinovým datagramovým řešením, prosazovali protokoly bez ustavování spoje, i když telekomunikační odborníci setrvávali  na jejich “virtuálních okruzích”. Namísto vyřešení jejich sporu se dohodli na tom, aby se do modelu OSI zahrnula možnost volby z obou přístupů, tj. na zvětšení rozsahu a složitosti modelu.

V podmínkách problémového spojenectví počítačových a telekomunikačních odborníků se v roce 1984 publikoval referenční model OSI jako mezinárodní standard ISO. Brzy následovaly jednotlivé standardy OSI pro transportní protokoly, elektronickou počtu, elektronické adresáře, síťový management a mnohé další oblasti funkcí. Model OSI začal shromažďovat výhody plynoucí z jeho ostré potřeby. Tehdejší vedoucí počítačové společnosti, jako Digital Equipment Corp., Honeywell a IBM začaly v modelu OSI silně investovat, stejně tak, jako Evropské hospodářské společenství (předchůdce dnešní Evropské unie) a národní státy v celé Evropě, Severní Americe a Asii.

Dokonce i Spojené státy - hlavní sponzor internetových protokolů, které byly s modelem OSI nekompatibilní, se zainteresovaly do rozvoje OSI. Ministerstvo obrany USA, oficiálně přijalo závěry  z doporučení vládní výzkumné agentury USA NRC (National Research Council)  z roku 1985 o budoucím přechodu od TCP/IP k OSI. Mezitím ministerstvo obchodu USA vydalo v roce 1988 příkaz k tomu, aby byl po srpnu 1990 standard OSI používán ve všech počítačích zakupovaných americkými státními orgány.

I když v 80. letech byl Internet ještě výzkumnou sítí, se vydané dokumenty OSI mohly brát jako dílo vysoko postavených byrokratů. Růst Internetu byl rychlý, avšak jeho manažeři až do roku 1992 neumožňovali jeho využívání ke komerčním účelům, nebo pro ziskové provozovatele služeb. Pro byznys a různé velké organizace, které čekaly na možnost výměny dat mezi různými druhy počítačů nebo různými druhy sítí, se model OSI jevil jako hudba vzdálené budoucnosti.

Časový průběh význačných událostí tohoto období je rovněž zřejmý z výše uvedeného  přehledového obrázku historického procesu rozvoje síťových architektur.

To, samozřejmě, nebyl konec příběhu. Ke konci 80. let dosáhla frustrace z pomalého rozvoje a nízkého stupně praktického využívání modelu OSI kritické hranice. Na evropském zasedání v roce 1989 celkovou situaci charakterizoval vyznavač modelu OSI Brian E. Carpenter z evropského CERNu ve vystoupení s názvem “Je pro OSI příliš pozdě?”. O dva roky později rozebral francouzský expert na tvorbu sítí a bývalý člen INWG L. Pouzin neujasněnost v rozšiřování OSI v eseji “Deset let OSI - vyzrálost nebo stav v plenkách?”. Uvedl: “Zásady státu a společnosti uplatňované při doporučení OSI jako řešení, nikdy neselhaly. Homogenní sítě založené na proprietárních architekturách, nebo propojování heterogenních systémů, lze však snadno a rychle implementovat s produkty založenými na TCP/IP”. Dokonce i pro přívržence modelu OSI bylo internetové řešení stále atraktivnější.

V polovině 90.let se prohluboval pocit beznaděje a stagnace. “Krásný sen” OSI se nakonec rozplynul. Fatální chyba v celém vynaloženém úsilí paradoxně souvisela s věrností otevřenému řešení. Formální pravidla mezinárodní standardizace dávala každé zainteresované straně právo se zúčastnit v procesu návrhu, čímž vyvolávala strukturní pnutí, neslučitelné vize a rozporuplné taktické přístupy.

Události, které proběhly mezi léty 1988 a 1992 jsou vyjádřeny ve výše uvedeném přehledovém obrázku historického procesu rozvoje síťových architektur.

Na rozdíl od situace s modelem OSI, Internet vzkvétal. S finanční podporou od americké vlády, V. Cerf, R. Kahn a jejich kolegové, byli od vlivu situace v mezinárodní politice a ekonomice ohrazeni. Na začátku 80. let agentura ARPA a další orgány ministerstva obrany USA dotovaly výzkumné pracovníky pro implementaci internetových protokolů v populárních operačních systémech počítačů, zejména v Unixu modifikovaném kalifornskou univerzitou v Berkeley. Poté, od začátku ledna 1983, ARPA zastavila podporu protokolu počítačů ARPANET a přinutila jejich kontraktory přijmout protokolový stek TCP/IP (chtěli-li zůstat připojeni). 1. leden 1983 se tak stal známým jako den zrození Internetu.

I když mnoho uživatelů stále očekávalo, že model OSI se stane budoucím řešením pro propojování globálních sítí, aby se vyhovělo stoupajícímu tlaku na interoperabilitu, vzrůstal počet těch, kteří začali užívat protokolový stek TCP/IP. Američtí odborníci, kteří se v 80. letech přidružili k internetové komunitě, často nepochopili model OSI a nespravedlivě jej zesměšňovali jako pošetilou obludnost vytvořenou bezradnými evropskými byrokraty. Podle nich technologie, potřebné pro implementaci OSI, vypadaly ve srovnání s internetovou technologií velmi ošklivě.

Předpojatost americké internetové komunity, bohužel, vedla také k odmítnutí objektivně hodnotných technických pohledů z modelu OSI. Klasickým příkladem byla “palácová vzpoura” roku 1992. Na rozdíl od formálního úřednického přístupu uplatňovaného u OSI, Internet vytvořil jako svůj technický a poradní orgán IAB (Internet Activity Board) a tvorba internetové architektury a specifikací pro Internet (zveřejňovaných jako dokumenty RFC) byla v působnosti IETF (Internet Engineering Task Force). IETF dohlížel na zpracování a vydávání vnitřních standardů Internetu. Příslušné práce byly náplní zasedání, které proběhlo v červenci 1992 v Cambridge (Massachusetts). Mnozí vedoucí činitelé tlačili na provedení revize omezení ve směrování a adresaci, která nebyla předpokládána v návrhu TCP/IP. To bylo doporučeno, když orgány zvažovaly, nebo rovnou přijaly, některé technické protokoly vypracované v OSI. Stovky přítomných technických internetových odborníků křičely na protest a žádaly odvolání vedoucích činitelů za jejich kacířství.

Události, které proběhly mezi léty 1992 a 2013 jsou vyjádřeny ve výše uvedeném  přehledovém obrázku historického procesu rozvoje síťových architektur.

I když V. Cerf a R. Kahn nenavrhli protokolový stek TCP/IP pro používání ve světě komerce, desítky let subvencí jejich výzkumu různými společnostmi nakonec vytvořily zcela jinou situaci v oblasti komerčních výhod. Internetové protokoly mohly být implementovány pro bezplatné využívání. Na rozdíl od toho, pro využití standardů OSI si musely společnosti, které vyráběly a prodávaly síťové komponenty zakoupit standardy po jednom od standardizační skupiny ISO v tištěné (papírové) formě. Volbu mezi TCP/IP a OSI tak ovlivňovalo to, že na jedné straně bylo to, co bylo bezplatné, dostupné a bylo si to možné stáhnout. Na druhé straně bylo to, co mělo mnohem sofistikovanější architekturu, bylo mnohem úplnější, mnohem propracovanější, avšak nákladné. Ryze praktická hlediska tak převážila ve prospěch TCP/IP.

V polovině 90. let se internetový model a jeho protokoly staly pro tvorbu globálních počítačových sítí standardem de facto. Pro tvůrce modelu OSI bylo kruté to, že přívrženci Internetu se zmocnili vlastnosti systémové otevřenosti a prohlásili ji za jejich vlastní. Pak rutinně vedli kampaň za ochranu “otevřeného Internetu” před autoritativními vládami, regulátory, a organizacemi snažícími se získat monopolní postavení.

Ve světle úspěchu čiperného Internetu, je model OSI často představován jako varovný příběh přebyrokratizované “předjímající standardizace” na nevyzrálém a nestabilním trhu. Takové tvrzení o něm je chybné, jelikož přehlíží mnohé úspěchy OSI - model OSI zaměřil pozornost na otázky nejvyspělejších technologií a stal se pro generace síťových odborníků na celém světě příkladem toho, jak se učit vlastní prací, jak aplikovat teorii v tvořivé práci - včetně některých těžkých ran, kterým v takových programech dá obtížně vyhnout.

Za zjednodušujícími vyjádřeními “úspěchů” a “nezdarů”, je příběh OSI důležitým ponaučením v tom, že techničtí odborníci, tvůrci strategických rozhodnutí a uživatelé Internetu se musejí snažit věcem lépe porozumět. Zřejmě nejdůležitějším poučením je to, že systémová “otevřenost” je plná vnitřních rozporů. Model OSI ozřejmil hlubokou neslučitelnost mezi idealistickými vizemi otevřenosti na jedné straně, a politickou a ekonomickou realitou mezinárodního průmyslu v oblasti tvorby sítí a straně druhé. Model OSI nakonec propadl, jelikož nedokázal uvést v soulad rozdílné zájmy všech zainteresovaných stran.

Osobní poznámka autora příspěvku: Po mnoho let byl autor blogu v minulosti (70. až 90. letech minulého století) zaníceným vyznavačem modelu OSI pro řadu jeho charakteristických vlastností, jmenovitě pro jeho silnou a důslednou vnitřní logiku, systémovou ústrojnost, členění vrstev architektury s bohatstvím funkcí v nich i řadu dalších. Poněkud s despektem pohlížel na internetový architekturní model s jeho jádrem - TCP/IP a zejména potom na další rozšiřování systémových funkcí modelu. Model se mu jevil jako účelový “slepenec”, ke kterému se bez ladu a skladu stále “přilepovaly” další protokolové prvky a funkce se svými procesy. Uvažoval o tom, jak tohle může fungovat. A fungovalo, funguje a bude fungovat nadále. A umožnilo to dovést Internet a jeho přínosy až do dnešního stavu s úžasnými a nekončícími možnostmi. To způsobilo velký přerod v myšlení autora. O to větší obdiv a úctu cítí k průkopníkům a tvůrcům architektury Internetu a všem těm nadaným a pracovitým pokračovatelům s zásluhami o jeho další rozvoj. Přitom by ale autor nikdy nesklouzl na platformu laciného odsouzení a zatracení modelu OSI.

Vážený “otec Internetu” Vinton Gray Cerf (na snímku z roku 2010)

Síťová architektura a model OSI (evropský přístup)

Devadesátá léta minulého století byla počátečními léty počítačových sítí, které se vyznačovaly různými síťovými architekturami jako SNA (Systems Network Architecture) společnosti IBM, DNA (Digital Network Architecture) společnosti DEC a DSA (Distributed Systems Architecture) společnosti Honeywell. Sítě s těmito (samotnými o sobě významnými) architekturami byly technicky tak odlišné, že žádné vzájemné komunikace nebyly možné. Proto v roce 1977, z hlediska dalšího růstu potřeby výměny dat a nutnosti nezávislé síťové architektury, zahájila Mezinárodní organizace pro standardizaci ISO (International Standards Organization) vývoj rámce a sady standardů pro propojení počítačů různých typů a síťových architektur.

To je možné hodnotit jako začátek pohybu směrem k modelu propojování otevřených systémů OSI (Open Systems Interconnection). Tato iniciativa byla přidělena podvýboru 16 (SC16) Technického výboru  (TC97) ISO, odpovědnému za standardizaci v oblasti zpracování dat. Hlavní technické vstupní materiály přicházely do SC16 z evropské asociace výrobců počítačů ECMA (European Computer Manufacturers Association), Mezinárodního konzultačního výboru pro telegrafii a telefonii CCITT (International Telegraph and Telephone Consultative Committee) a amerického Institutu pro elektrotechniku a elektroniku IEEE (Institute of Electrical and Electronics Engineers).

Úzká spolupráce, která nastala mezi ISO a CCITT, přivedla ke společnému vývoji standardů ISO/OSI a odpovídajících mezinárodních doporučení CCITT. V roce 1984 byla publikována  první verze referenčního modelu propojování otevřených systémů OSI-RM (Open System Interconnection Reference Model), označená jako ISO 7498 a jako sada mezinárodních doporučení CCITT, řady X.200. Jádrem byl model sedmivrstvého protokolového steku cílený na budování budoucích stabilních sítí, s kterým byly možné obousměrné vzájemné komunikace. Tento model a jemu příslušné protokoly byly někdy charakterizovány jako prostředek pro vedení “svaté války” s protokoly TCP/IP.

Vrstvy architektury dle referenčního modelu ISO/OSI

Jelikož docházelo k stále většímu překrývání ve standardizačních aktivitách oblastí informačních a komunikačních technologií zřídily v roce 1985 ISO a IEC (Mezinárodní elektrotechnická komise) Společný technický výbor 1 (JTC1) pro koordinaci jejich aktivit při vypracovávání společných standardů informačních a komunikačních technologií (ICT). Mezitím byly aktivity SC16 nově rozděleny mezi dva podvýbory tak, že SC6 odpovídal za spodní vrstvy modelu OSI a SC31 za horní vrstvy. Další podvýbory vypracovávaly standardy pro pro specifickou tématiku ICT, jakými byly např. standardy pro MHS (Systém zprostředkování zpráv) X.400 a Architekturu otevřených dokumentů (ODA).

Po uvedení první verze standardu referenčního modelu ISO/OSI v roce 1984, byly vypracovány standardy (mezinárodní doporučení) pro další tři moduly - rámec pro správu a řízení X.700 (Management Framework), vydaný v roce 1992, pro bezpečnostní architekturu X.800 (Security Architecture), vydaný v roce 1989 a pro jmenný a adresní systém X.650 (Naming and Addressing), vydaný v roce 1996. Navíc, původní model přenosu dat orientovaný na ustavení spoje (connection-oriented) byl rozšířen tak, aby obsahoval i model bez ustavení spoje (connectionless). Výsledná verze byla publikována v roce 1994 jako standard ISO/IEC 7598-1.

Spojené státy v té době byly nezpochybnitelnou hlavní hnací silou rozvoje počítačových sítí, nejen proto že byly v čele vývoje internetových protokolů TCP/IP, ale také proto, že americké společnosti byly schopny pohotově dodávat odpovídající síťové produkty. Zbytek světa je s větším nebo menším zpožděním následoval. Navzdory tomu, evropské vlády a Evropská unie viděly v rozvoji referenčního modelu ISO/OSI příležitost pro posílení své pozice na počítačovém a telekomunikačním trhu, např. financováním výzkumných projektů zaměřených na vývoj a používání konkrétních produktů na bázi modelu ISO/OSI. V souladu s tímto přístupem byly americké produkty na bázi TCP/IP v Evropě ignorovány a někdy dokonce označovány jako technicky omezené a nekvalitní či méněcenné. Tento přístup byl navíc podporován směrnicemi vydávanými v některých státech uvádějícími, že se mají kupovat a používat pouze produkty založené na modelu OSI. Hlavní ustanovení těchto směrnic byla např. soustředěna v evropské příručce EPHOS (European Procurement Handbook for Open Systems) pro členské země Evropské unie a v americkém dokumentu GOSIP (Government Open Systems Inteeconnection Profile) pro různé další státy.

Model ISO/OSI ve formě amerického GOSIP

Takže dokonce vláda Spojených států, kolébky architektury TCP/IP, vydala GOSIP pro usnadnění integrace produktů OSI do státních systémů, obávaje se možné ztráty pro ně užitečných komponent OSI. V praxi však byl účinek GOSIPu nepatrný.

Vnitřní struktura dle GOSIP

Systémově-technická podstata referenčního modelu ISO/OSI

Referenční model ISO/OSI byl vypracován jako standard pro navrhování datových komunikací v počítačových sítích, jak bylo výše uvedeno, ISO-7498 z roku 1984. Hlavním důvodem jeho vzniku byla potřeba unifikovat přístup k navrhování a budování počítačových sítí tak, aby byly byly systémově a uživatelsky otevřené a umožňovaly vzájemnou výměnu dat a informací.

Vznikl tak standardizovaný referenční model s vrstvovou architekturou. Respektovala se hlediska co nejefektivnějšího a nejjednoduššího rozdělení komunikačních a souvisejících procesů do vrstev. Šlo o minimalizaci počtu vrstev, umístění rozhraní mezi vrstvami tak, aby bylo zajištění služeb poskytovaných vrstvami úsporné a počet interakcí přes rozhraní minimální. Vrstvy měly respektovat odlišnosti zajišťovaných funkcí a možnost soustředění příbuzných funkcí společné v příslušné  vrstvě. V rámci každé vrstvy mělo být zajištěno snadné vykonávání protokolů a běh odpovídajících procesů, bez dopadu na funkce ostatních vrstev.

Společným pravidlem bylo to, aby každá z vrstev nabízela své služby o stupeň vyšší vrstvě, nezatížené detaily o jejich realizaci ve vrstvě, kde jsou realizovány. Na jednotlivých úrovních tak mohly prvky sítí komunikovat přesně podle protokolů daných soubory pravidel a konvencí. Operace a služby, které nižší vrstva poskytovala vyšší vrstvě, byly pro rozhraní vrstev přesně definovány.

Ve shrnuté formě byly hlavními zásadami modelu OSI tyto:

• Každá vrstva využívá služeb vrstvy o jeden stupeň nižší.
• Každá vrstva poskytuje své služby vrstvě o jeden stupeň vyšší.
• Stejnolehlým partnerem vrstvy “N” ve výchozím uzlu sítě je vrstva “N” konečného (cílového) uzlu sítě.
• Spolupráci mezi entitami téže vrstvy řídí protokoly dané vrstvy (v rámci jedné vrstvy může být i více samostatných entit).

Referenční model ISO/OSI je níže na obrázku. Uvádějí se v něm i hlavní funkce a obsah činností v jednotlivých vrstvách. Obrázek znázorňuje i funkční vztah modelu OSI k architektuře počítačových sítí založených na protokolech TCP/IP.

Model síťové architektury OSI a vztah k modelu TCP/IP

Systémově technická podstata síťové architektury založené na protokolech TCP/IP

Dnes je to již více než padesát let co byla poprvé navržena internetová protokolová sada TCP/IP. Byla vyvinuta v rámci programu Výzkumné agentury pokročilých programů ministerstva obrany USA DARPA (Defense Advanced Research Project Agency) pro vojenské systémy a sítě a postupně se rozšířila i do komerčních systémů a sítí. Dokumentů a dalších materiálů, které protokolovou sadu podrobně popisují je nepřeberné množství (proto se tím zde nebudeme zabývat), obtížné však bývá vydedukovat to, proč jsou protokoly právě takové jaké jsou. Například protokol IP je založen na způsobu přenosu bez (předchozího) ustavení spoje, neboli datagramového režimu provozu sítě. Motivace k tomu byla mnohdy značně nejasná. Podívejme se tedy stručně na to, jaké dřívější důvody vedly k tvářnosti protokolové sady TCP/IP a návazných protokolů.

Všeobecný pohled

Sada protokolů vyvinutá v rámci projektu DARPA používala přepojování paketů dat. Protokolová sada jejímž základem jsou TCP/IP, se v dalším stala základem standardů ministerstva obrany USA (i když se jim později dostalo širokého užití i v prostředí komerčních sítí). Ideje z vývoje protokolů TCP/IP ovlivnily i vývoj jiných protokolových sad především protokolů ISO/OSI v část služeb bez ustavení spoje.

Filozofie dalšího rozvoje návrhu protokolů se výrazně odvíjela od původní verze návrhu pozdějších standardů, který se postupně zpřesňoval a dopracovával. Například idea datagramu, či služby přenosu bez ustavení spoje, nebyla zpočátku zvýrazňována, i když se stala určující charakteristikou protokolu. Dalším příkladem je uspořádání architektury do vrstev IP a TCP. I když se to stalo pro návrh základem, součástí původního návrhu to nebylo. Tyto změny v návrhu pozdějšího Internetu nastaly později v procesu implementace a testování, které předcházelo vydání standard.

Typová vnitřní struktura pro model TCP/IP (pro porovnání též OSI)

Architektura Internetu se stále rozvíjí. Každé nové vylepšení nebo rozšíření funkcí je tak či onak spojeno s historií rozvoje Internetu. I protokoly ISO/OSI byly ovlivněny historií rozvoje internetových protokolů. Názorným příkladem jsou protokoly OSI pro konfiguraci bez ustavení spoje. Takže je skutečností to, že filozofie návrhu internetových protokolů byla nápomocna pracím na protokolech OSI.

Hlavní cíl

“Nejvýše položeným” cílem internetové architektury DARPA bylo vytvořit efektivní způsob využívání existujících propojených počítačových sítí pro multiplexované přenosy. Součástí Internetu byly sítě, které měly být propojeny tak, aby zajistily více služeb. Původním hlavním cílem bylo propojit dohromady původní síť ARPANET s paketovou rádiovou sítí ARPA tak, aby bylo možné poskytnout uživatelům paketové rádiové sítě přístup k velkému množství služeb zajišťovaných počítači ARPANETu. Časem se stalo zřejmé, že mohou být připojeny i další druhy sítí, a to i v podmínkách, kdy lokální sítě (LAN) ještě nebyly rozšířené.

Schéma topologie původní sítě ARPANET

Alternativou propojených existujících sítí měl být návrh unifikovaného systému, který by zahrnoval i různorodá přenosová prostředí a multimediální sítě. I když to mohlo umožnit vysoký stupeň integrace, a tudíž i lepší výkonnost, bylo zřejmé že by to bylo nutné zahrnout do existujících architektur, měl-li by se Internet stát prakticky užitečným. Způsobem vybraným pro multiplexování bylo přepojování paketů. Byla zvažována alternativa - přepojování okruhů, avšak aplikace, které měly být podporovány, jako je dálkové přihlašování (login), byly přirozeně obsluhovány přepojováním paketů a sítě, které měly být spolu v daném projektu integrovány, byly paketově přepojované sítě. Takže přepojování paketů bylo přijato jako základní komponenta internetové architektury.

Konečným aspektem v plnění tohoto hlavního cíle byla úvaha o konkrétním způsobu vzájemného propojování těchto sítí. Jelikož způsob paketového přepojování na bázi ukládání datových paketů v uzlech sítě a jejich posílání dál (store and forward), jak byl demonstrován v předchozím  projektu DARPA - ARPANETu byl dobře známý a ověřený, prosadil se předpoklad, že sítě budou propojovány ve vrstvě internetových paketových přepojovačů nazvaných branami (gateways) a realizovaných směrovači.

Z toho vzešla základní struktura Internetu - paketově přepojované komunikace, ve kterých se propojovala dohromady řada navzájem odlišných počítačových sítí, v jejichž uzlových procesorech (tehdy nazývaných branami) se implementoval algoritmus ukládání a přeposílání paketů.

Další cíle

Ve výše uvedeném vrcholném cíli byl kladen důraz na efektivnost, aniž se uvedlo, co efektivní propojování sítí musí zajišťovat. To je možné sumarizovat formou přehledu cílů nižšího řádu, které bylo nutné v internetové architektuře zajistit. Ty byly vyjádřeny požadavky na:

1. Pokračování internetových komunikací i v případě výpadku části sítě nebo výpadku brány v uzlu sítě.
2. Podporu mnoha druhů komunikačních služeb.
3. Schopnost internetové architektury pojmout do sebe sítě různorodého charakteru.
4. Zajištění distribuované správy a řízení zdrojů sítí.
5. Ekonomickou efektivnost provozu sítě dané internetové architektury.
6. Umožnění snadného přidávání počítačů do sítě.
7. Přísnou registraci zdrojů použitých v síti internetového typu.

Na tuto sadu požadavků k cílovému řešení Internetu, lze pohlížet jako kontrolní seznam požadovaných vlastností sítě, v kterém mohlo, při nových požadavcích zadavatelů, docházet ke změnám. Síťová architektura byla navržena z hlediska vojenského využívání sítě internetového typu, kde se předpokládala možnost působení nepříznivého nebo nepřátelského prostředí pro provoz sítě. V takovém případě může například do popředí vystoupit požadavek vysoké odolnosti síťových komponent a protokolů, a některé z jiných požadavků vyjadřujících cíle se mohou upozadit.

Schopnost sítě zachovat provozuschopnost v reakci na vznik  poruch

Velmi důležitou položkou ve výše uvedeném seznamu je schopnost internetu pokračovat v plnění komunikačních služeb i tehdy, dojde-li v sítích  a branách k poruše. Konkrétně to znamená to, že když dvě entity spolu komunikují přes Internet, a nějaká porucha způsobí to, že provoz Internetu bude dočasně narušen a proběhne rekonfigurace pro obnovení služby, pak dvě komunikující entity musejí být schopny pokračovat  v provozu, znovunavázat či resetovat předchozí stav jejich konverzace.

Nebo ještě jinak, na rozhraní služby v transportní vrstvě architektura sítě sice nezajistí komunikace klienta transportní služby, neboť může dojít ke ztrátě synchronizace mezi vysílačem a přijímačem, síťová architektura se však pokusí zajistit, aby nikdy nedošlo ke ztrátě synchronizace, ledaže by nebyla k dispozici fyzická cesta, po které by bylo možné komunikovat. Jinými slovy, na vršku transportní vrstvy může být jen jedna kritická porucha a tou je totální selhání.

Aby se tohoto cíle dosáhlo, musejí se schraňovat stavové informace, které popisují probíhající konverzace. Specifickými příklady stavových informací mohou být počet potvrzených paketů, nebo počet nevyřízených povolení při řízení toku dat. Jestliže dolní vrstvy architektury ztratí tyto informace, nebudou moci sdělit byla-li data ztracena a aplikační vrstva  se bude muset vyrovnat se ztrátou synchronizace. Tato architektura vyžaduje, aby se taková narušení provozu nevyskytovala, což znamená že stavové informace musejí být chráněny před ztrátou.

Druhy služeb

Druhou v seznamu položek internetové architektury je ta, která se týká podpory na úrovni transportních služeb, tj. řady služeb různého druhu. Různé druhy služeb se liší různými požadavky na takové vlastnosti, jako jsou rychlost, skrytost a spolehlivost. Tradičním druhem služby je spolehlivé obousměrné doručování dat. Tato služba, kterou je možné označit jako služba “virtuálního okruhu”, je charakteristická pro takové aplikace jako je dálkové přihlašování nebo přenos souborů dat. Je to první služba, která byla v internetové architektuře zajištěna s použitím protokolu TCP. Již dřív bylo zřejmé, že tato služba může mít více variant, jelikož dálkové přihlašování, jako druh služby, vyžaduje např. malé zpoždění při doručování, ale má přitom mírné požadavky na propustnost (šíři pásma) přenosové cesty, zatímco přenos datových souborů neklade silný důraz na na malé zpoždění, ale vyvolává silný požadavek na zvýšenou propustnost přenosové cesty. Protokol TCP musel umět vyhovět požadavkům obou uvedených služeb.

Původní koncepce transportního protokolu TCP se snažila být obecnou tak, aby mohla podporovat jakýkoli požadovaný druh služby, avšak s tím jak se začal vyjasňovat plný rozsah potřebných služeb, začalo být zřejmé, že bude velmi obtížné, či nemožné, pokrýt podporu všech služeb jedním protokolem.

Službou, která nejde dohromady s transportním protokolem TCP, je přenos digitálních informací v reálném čase. Je to zejména případ přenosu digitalizovaných signálů řeči, který se stal již dříve nutným pro podporu telekonferenčního provozu v aplikacích velení a řízení. Při digitálním hovoru, přenášeném v reálném čase, není přednostním požadavkem spolehlivý přenos bitů dat (občas “vypadlý” nebo chybný bit či paket není až tak kritický), důležité ale je to, aby služba minimalizovala a “vyhlazovala” přenosová zpoždění při přenosu paketů digitalizovaných hovorových signálů.

V aplikační vrstvě se analogový signál řeči digitalizuje, výsledné bity se paketizují a regulérním způsobem přenášejí přes síť. Musejí být regulérně doručeny do přijímače, aby mohly být zpětně převedeny na analogový signál řeči. Když hovorové pakety v daném čase regulérně nedorazí, není možné hovorový signál řeči v reálném čase obnovit. Může být překvapivé to, že nejvýznačnějším zdrojem přenosového zpoždění v síti je samotný mechanizmus, který zajišťuje spolehlivé doručování dat na přijímací straně. Typický spolehlivý transportní protokol reaguje na ztracený paket dat vyžádáním jeho opakovaného vyslání a s ním se opakovaně odešlou i následující opožděně doručené pakety. Na přijímací stranu se doručí opakovaný ztracený paket a všechny další které po něm následovaly. Zpoždění, které tím nastane, může být několikanásobkem doručovací oběhové doby v síti a může zcela narušit algoritmus obnovení hovorového signálu. Na rozdíl od toho, s občasnou ztrátou paketu je možné se snadno vyrovnat. Chybějící úsek hovoru může být nahrazen krátkou dobou ticha, která většinou nemá  u posluchače vliv na srozumitelnost řeči. Kdyby přesto někdy měla vliv, pak může posluchač požádat hovořícího, aby porušenou nesrozumitelnou větu jednoduše zopakoval.

Bylo tedy, již v časném stádiu vývoje architektury internetu, rozhodnuto, že bude potřeba více než jedna transportní služba a architektura musí být připravena tolerovat více souběžných transportních procesů, které jsou založeny na omezení alespoň spolehlivosti přenosu, zpoždění nebo propustnosti.

Cíl vyvolaný protokoly TCP a IP, které byly původně zastoupeny v architektuře jedním protokolem, bylo nutné rozdělit do dvou vrstev. TCP, zajišťující jeden přesně daný typ služby (spolehlivý přenos řazeného toku dat), zatímco IP by zajistil základní stavební blok z kterého může být vytvořena řada různých služeb. Tímto stavebním blokem byl datagram, který byl přijat i pro podporu odolnosti přenosu. Spolehlivost, spojená s doručováním datagramů by nebyla zaručena, avšak bylo by možné zajistit při vytváření datagramu jak službu, která by byla spolehlivá (potvrzováním a opakovaným přenosem řízeným z vyšší úrovně), tak i službu, která by v příslušné sektoru sítě vyměnila spolehlivost za primitivní charakteristiky zpoždění. Na základě toho byl vytvořen protokol UDP (User Datagram Protocol), který zajišťuje rozhraní aplikační úrovně pro základní datagramovou službu Internetu.

Architektura nevyžaduje jako předpoklad to, že základní sítě samy o sobě podporují více druhů služeb, jelikož by to narušilo plnění dalšího cíle, kterým je zajištění možnosti využívání existujících sítí. Namísto toho se má za to, že více druhů služeb je možné vytvářet ze základního datagramového stavebního bloku s použitím algoritmů sídlících v počítači nebo uzlové bráně. I když nejde o případ většiny současných implementací, je například možné vzít datagramy, které jsou spojeny s řízeným zpožděním, ale patří do služby se sníženou spolehlivostí přenosu, a umístit je do čela přenosové fronty, takže i když by jejich doba života ještě nevypršela, v tom případě budou vyřazeny, přičemž pakety patřící do spolehlivě přenášených toků by byly umístěny na konci přenosových front a nikdy by vyřazeny nebyly (bez ohledu na to, jak dlouho by byly v síti).

Různorodost sítí

Pro úspěch internetové architektury bylo velmi důležité to, aby byla schopna do sebe zahrnout a využívat širokou paletu síťových technologií, včetně jejich vojenských i civilních možností. V plnění tohoto cíle byla od začátku internetová architektura velmi úspěšná. Provozovala se na široké paletě sítí (ARPANET samotné a různých sítích dle standardu X.25), lokálních sítích (LAN), dřívějších družicových sítích, širokopásmových pozemských i družicových sítích, paketových rádiových sítích i separátních úzko- a širokopásmových spojích.

Internetová architektura prokazuje svoji přizpůsobivost i tím, že se opírá o minimum předem daných předpokladů, které se týkají funkcí, které bude síť zajišťovat. Základním předpokladem je to, že síť bude zajišťovat transport paketů dat, či datagramů. Paket dat musí mít rozumnou velikost, třeba minimálně 100 byte a musí být doručen s rozumnou, avšak nikoli extrémní,  spolehlivostí. Síť musí umožňovat vhodný způsob adresace (rozumí se, že se nejedná o přenosy v dvoubodovém separátním spoji).

Je řada služeb, které se v sítích explicitně nepředpokládaly. Ty zahrnovaly vysoce spolehlivé nebo přesně řazené doručování, rozhlašovací režim na úrovni sítě nebo multicastový režim (odesílání datagramů z jednoho zdroje vybrané skupině více koncových stanic, přičemž týmiž datagramy v jednom datovém toku), přidělování priority paketům, podporu více druhů služeb a vnitřní znalost rychlostí nebo zpoždění, případně poruch. Byly-li takové nebo další podobné služby požadovány, pak k tomu, aby síť mohla být pojmuta do Internetu bylo nutné buď to, aby síť přímo podporovala tyto služby, nebo to, aby software v rozhraní sítě zajistil simulaci těchto služeb v koncovém uzlu sítě. Bylo zřejmé, že to byl nežádoucí přístup, jelikož tyto služby vyžadovaly radikální nahrazení existujících procesů jinými a novou implementaci  pro každou síť. Technické řešení těchto služeb pro transport paketů, např. vysoce přesné doručování datových paketů v protokolu TCP, se muselo uskutečnit pouze jednou a implementovat se muselo jednou v každém počítači. Poté byla implementace softwaru v rozhraní obvykle jednoduchá.

Další cíle

Další diskutované cíle byly ty, které silně ovlivňovaly návrh architektury. Zbývající cíle z výše uvedeného přehledu cílů měly menší důležitost a snad jim byla věnována menší pozornost, nebo nebyly úplně technicky řešeny. Cíl spočívající v umožnění distribuované správy a řízení Internetu byl samozřejmě pojímán s určitými ohledy. Například ne všechny brány v Internetu jsou implementovány a spravovány touž agenturou. V rozvinutém Internetu je řada odlišných řídících center. Každé odpovídá za správu a řízení určité skupiny bran kde funguje dvouúrovňový směrovací algoritmus, který umožňuje, aby si brány různých provozovatelů mohly vyměňovat směrovací tabulky (dokonce i tehdy, když při výměně dat mezi sebou nemají zcela zaručenou bezpečnost) a pro jednoduchou správu a řízení používat mezi bránami různé privátní směrovací algoritmy. Podobně různé organizace, které spravují brány, nemusejí být nutně týmiž organizacemi, které zajišťují správu sítí k nimž se brány připojují.

Na druhé straně k řešení některých podstatných problémů v Internetu nebyly odpovídající nástroje distribuovaného řízení, zvláště v oblasti směrování. V rozsáhlé internetové síti, která se provozovala, musí být rozhodování při směrování dáno zásadami pro využívání zdrojů. To se mohlo uskutečňovat pouze velmi omezeným způsobem, který vyžadoval manuální zpracováni směrovacích tabulek. Takový způsob je náchylný k chybám a navíc neefektivní. Nejdůležitější změnou v architektuře Internetu v dalších létech se stal vývoj nové generace nástrojů pro správu zdrojů v kontextu mnoha provozovatelských, příp. správcovských organizací.

Je zjevné, že za určitých okolností internetová architektura nezajišťuje ekonomicky efektivní a využitelné komunikační zdroje, jak to mohou zajistit architektury, které jsou více “šité na míru” konkrétních sítí. Záhlaví internetových paketů (i v původní verzi IPv4) je značně dlouhé (typicky 40 byte) a přenášejí-li se krátké datové pakety je velikost režie zřetelná. Nejhorším případem samozřejmě jsou jednoznakové pakety dálkového přihlašování, které nesou 40 byte záhlaví a jeden byte dat. Ve skutečnosti je od jakékoli protokolové sady velmi těžké požadovat, aby se takový druh výměny dat uskutečňoval s rozumnou efektivností. Při druhém extrému mohou mít pakety pro přenos velkých datových souborů třeba 1000 byte dat, takže  režie záhlaví bude pouhá čtyři procenta.

Dalším možným zdrojem neefektivnosti je opakování přenosu ztracených paketů. I když Internet nevyžaduje, aby ztracené pakety byly obnoveny na síťové úrovni, může být nutné, aby se opakovaný přenos ztracených paketů uskutečnil od jednoho koncového uzlu Internetu do druhého. To znamená, že opakovaně přenášený paket může putovat přes několik mezilehlých sítí podruhé, zatímco obnova na síťové úrovni by tento opakovaný přenos negenerovala. To je příklad výměny “něco za něco” vyplývající z výše uvedeného zajišťování služeb z koncových bodů. Software v rozhraní sítě je mnohem jednodušší, avšak celková efektivnost je potenciálně menší. Když však je výskyt opakovaného přenosu nízký (řekněme 1%), pak je možné cenu za to tolerovat. Jako hrubé pravidlo pro sítě pokrývané architekturou platí to, že ztráta jednoho paketu ze sta je v některých případech ještě přijatelná, ale ztráta jednoho paketu z deseti napovídá, že daný druh služby vyžaduje provést v síti opatření pro zvýšení spolehlivosti přenosu.

Cena přidání nového počítače do internetové sítě je snad poněkud vyšší než v jiných architekturách, jelikož všechny mechanizmy k zajištění požadovaného druhu služby, jako je strategie potvrzování a opakovaní přenosu musí být implementovány spíš v počítači než v síti. Zpočátku bylo pro programátory, kteří nebyli znalí implementace protokolu, úsilí o její zvládnutí dosti znepokojující. Implementátoři se pokoušeli o to, aby se přenesení transportních protokolů do předřazeného (front end) procesoru mohlo spíš provést jen jednou, než pro každý typ počítače stále znovu. To však vyžadovalo značnou invenci v řešení protokolu počítač - předřazený procesor, který mnozí považovali za stejně složitý jako původní transportní protokol. S tím, jak se zkušenosti s protokoly zvětšovaly, obavy z implementace sady protokolů v počítači padaly a staly se dostupnými implementace pro širokou paletu počítačů (postupně i pro PC), včetně těch s velmi omezenými výpočetními zdroji.

Související problém, který nastane při použití mechanizmů rezidentních v počítači, spočívá v tom, že špatná implementace mechanizmu může uškodit provozu v síti, stejně jako v počítači. Tento problém byl tolerován jelikož počáteční experimenty s omezeným počtem počítačových implementací ukázaly, že může být pod kontrolou. Avšak s tím, jak se rozsah využívání Internetu zvětšoval, nabýval problém na vážnosti. V tomto ohledu to mělo vliv na cíl zajištění robustnosti, což vedlo k “sdílení osudu”, kdy zachoval-li se počítač nepředvídatelně, algoritmy rezidentní v počítači přispívaly k ztrátě robustnosti.

Architektura a implementace

Z předchozího popisu cílů a způsobů jejich dosažení je zřejmé, že jeden z důležitých cílů internetové architektury musí zajišťovat velkou přizpůsobivost v nabízených službách. Pro zajištění různých druhů služeb musejí být použity různé transportní protokoly, navíc se zajišťuje začleňování různých navzájem odlišných přenosových sítí. Jinak řečeno, architektura se snaží neomezovat rozsah služeb, které mohou být v Internetu technicky zajištěny. To na druhé straně znamená, že pro pochopení služby, která může být nabídnuta konkrétní implementací Internetu, není nutné se zabývat architekturou, ale skutečným řešením software v konkrétních počítačích a bránách a konkrétními sítěmi, které mají být začleněny.

Pro popis konkrétní sady sítí, bran a počítačů, které se propojují dohromady v kontextu internetové architektury, použijeme termín “realizace”. Realizace se mohou lišit rozsahem služeb, které nabízejí. Uskutečňovaly se například tak, že postupně zajišťovaly přenosy rychlostmi 1200 bit/s po telefonních linkách, vně sítí pak vyššími rychlostmi, například většími než 1 Mbit/s. Očekávané hodnoty propustnosti se tak lišily zabezpečovanou rychlostí přenosu. Některé internetové realizace měly hodnoty zpoždění (spojeného s ukládáním datových paketů v uzlech a jejich přeposíláním dál) měřené v desítkách milisekund, u jiných se měřilo v sekundách. Realizace některých aplikací, jako třeba přenosu hovoru v reálném čase, se od základu lišily od uvedených dvou realizací. Některé internetové sítě byly technicky řešeny tak, že měly v bránách a přenosových cestách velkou redundanci. To zajišťovalo jejich odolnost, jelikož existovaly zdroje, které mohly být po vzniku poruchy rekonfigurovány. Další internetové realizace měly pro snížení nákladů realizované jednoduché body konektivity, takže porucha mohla rozštěpit internetovou síť na dvě vzájemně nepropojené části. Internetová architektura, tím jak byla navržena, umožňovala takovou různorodost tolerovat. Vyžadovala však od toho, kdo realizaci navrhl, spoustu technicky náročné práce.

Důležitým ukazatelem pro praktický provoz je provozní výkon sítě. Vztah mezi architekturou a výkonem byl pro tvůrce internetové architektury významnou výzvou. Pociťovali velmi silně to, že by bylo velikou chybou usilovat pouze o logickou korektnost a nestarat se o výkon sítě.  Uvědomovali si značnou obtížnost formalizování jakéhokoli aspektu v architektuře, který znamenal vymezení výkonu. Potíže vyvstávaly jak proto, že cílem architektury nebylo vymezení výkonu, ale umožnění variability, tak i proto (a možná o to více), že nebyly vhodné formální nástroje popisu výkonu.

Uvedený problém byl zvláště znepokojující, jelikož cílem projektování Internetu bylo vytvoření specifikačních dokumentů, které by se mohly stát vojenskými standardy. Soustředil-li by se projekt Internetu na výkon, požadavky na výkon by se nutně staly součástí specifikací zakázky na prováděné práce na architektuře. Bylo triviální vymyslet specifikace, které by vymezovaly výkon, například specifikovat to, že implementace musí být schopna zajistit propustnost tisíc paketů za sekundu. Takové vymezení se však nemohlo stát součástí architektury. Muselo být spíše součástí specifikace na konkrétní realizaci vyplývající z potřeb zajištění požadovaných druhů služeb.

Datagramy

Základní architekturní vlastností internetové sítě je používání datagramů, jako entity, která je předmětem transportu po základních přenosových sítích. Jak je v našem výkladu naznačeno, je několik důvodů proč jsou v architektuře datagramy tak důležité. Zaprvé, zbavují nutnosti mít neustále zajištěn stav ustaveného spojení v mezilehlých přepojovaných uzlech, což je důležité proto, že je po výskytu poruchy je možné změnit topologii nebo strukturu internetové sítě bez ohledu na to,  jaký je stav ustavení spojení. Zadruhé, datagram zajišťuje základní stavební blok s nímž je možné implementovat různé druhy služeb. Tím, že se odlišuje od virtuálního okruhu, který zpravidla předpokládá pevný (neměnný) druh služby, datagram zajišťuje takovou elementární službu, kterou je možné v koncových bodech sítě odpovídajícím způsobem kombinovat podle potřeb toho, jakou službu je potřebné poskytnout . Zatřetí, datagram představuje minimální předpoklad síťové služby, umožňované v širokém spektru různých sítí. Rozhodnutí o použití datagramu bylo mimořádně úspěšné a umožnilo, aby internetové sítě se zdarem splnily nejdůležitější stanovené cíle.

Pouzdření datového paketu v modelu TCP/IP

S datagramem bývá často spojován chybný předpoklad spočívající v tom, že motivací pro datagramy je podpora vyšší úrovně služeb, které jsou v podstatě ekvivalentní datagramovým službám. Jinými slovy, někdy se předpokládalo, že datagram se zajišťuje proto. že služba transportu, kterou aplikace potřebuje je datagramová služba. Ve skutečnosti je to nepříliš častý případ. I když některé internetové aplikace, jako např. jednoduché dotazy či požadavky na datové servery nebo jmenné servery používají metodu přístupu založenou na nespolehlivém datagramu, většina služeb v Internetu raději využívá sofistikovanější model transportu než je prostý datagram. V některých službách jde o větší spolehlivost, v některých o vyrovnané zpoždění a využití funkcí vyrovnávací paměti, avšak téměř ve všech se očekává  něco složitějšího a dokonalejšího než prostý datagram. V tomto ohledu je důležité pochopit to, že rolí datagramu je být stavebním kamenem a nikoli službou jako takovou.

Transportní funkce TCP

Původní protokol počítač-počítač v ARPANETu zajišťoval řízení datového toku založené jak na bytech (jako datových jednotkách), tak i na paketech. To se jevilo jako příliš složité, a tak tvůrci TCP pokládali za vhodné, aby byl pouze jeden způsob řízení. Volba padla raději na řízení doručování bytů než paketů. Řízení toku a potvrzování je tedy v protokolu TCP založeno na počtu bytů a nikoli počtu paketů. Pro TCP tedy není podstatné paketování dat.

Řešení bylo motivováno několika faktory, z nichž některé se ukázaly jako irelevantní, jiné byly důležité a byly akceptovány. Jedním z důvodů pro potvrzování bytů bylo umožnění toho, aby do sledu intervalů pro byty mohly být vkládány řídící informace, a tak se mohly řídící informace a data potvrzovat. Používaná sekvence intervalů byly rozdělena ve prospěch ad-hoc možností jak nakládat s řídící zprávou. I když původní myšlenka byla na pohled obecná, v praxi způsobovala komplikace.

Pro uvedené řešení byly i další důvody. Bylo nutné, aby tok bytů umožňoval rozdělení paketu TCP do menších paketů. Tato funkce však byla přesunuta do vrstvy IP (síťové), když IP byl vyčleněn z TCP a bylo nutné vymyslet odlišnou metodu fragmentace. Dalším důvodem pro potvrzování bytů namísto paketů bylo umožnit to, aby mohlo být několik malých paketů při přenosu do počítače sdruženo do jednoho většího paketu, a to zejména tehdy, když je při ztrátě paketů nutné opakované odeslání již přenesených dat. Praktický provoz je v tom případě efektivnější.

Z druhé strany, je to možné brát tak, že se potvrzováním bytů vytváří nový problém. Bylo-li základem řízení toku dat potvrzování paketů namísto bytů, tak se tento tok nikdy nemusel vyskytnout. Řízení na úrovni paketů přinášelo efekt, avšak při přenosu malých paketů vedlo k určitému omezení propustnosti. Specifikoval-li se pro přijímající počítač počet paketů pro příjem bez jakékoli znalosti počtu bytů v každém paketu, pak se mohlo skutečné množství přijatých dat měnit v řádu tisíce v závislosti na tom, zda odesílající počítač vkládá do každého paketu jeden byte nebo tisíc byte.

Z retrospektivního pohledu mohlo být správným řešením zajišťoval-li mechanizmus TCP efektivní podporu pro různorodost služeb, když v původní síťové struktuře ARPANET zajišťovaly protokoly to, aby byla možnost regulovat jak pakety, tak i byty.

K systémově-technické podstatě internetové architektury v souhrnu

Koncept TCP/IP je univerzální síťový standard pro internetové sítě a obecně pro tvorbu sítí. Od samého počátku byl navržen spíše pro ustanovování a správu konektivity mezi sítěmi než mezi zařízeními. Podíváme-li se zpětně do 70. let minulého století, pak tým, který TCP/IP vytvořil dal jasně vědět o jeho účelu - “V komunikacích mezi sítěmi musí být zřejmé, že mají dvě části: reléování zpráv po skocích a řízení konverzačního provozu od jednoho konce na druhý”.

I když nejdůležitějšími protokoly jsou ty, které vyplývají z jejich názvu - protokol pro řízení transportu dat (Transmission Control Protocol) a síťový internetový protokol (Internet Protocol), tj. TCP/IP, ve skutečnosti jde o celou sadu protokolů, z nichž některé jsou dobře známé z jiného kontextu (např. FTP, HTTP a jiné). TCP/IP směřuje k tomu, aby byl pro uživatele nenápadný, nevyvolával zbytečné nároky a při práci nerušil.

Filozofie TCP/IP pochází z projektu ministerstva obrany USA zahájeného proto, aby se zaručilo, že vojenský komunikační provoz bude moci pokračovat i po jaderném úderu a  zachová si použitelnou zbytkovou propustnost síťové struktury. Ministerstvo obrany sponzorovalo Stanfordskou univerzitu a tvůrce protokolu vyvíjející potřebnou sadu. TCP/IP se nejprve objevil jako vojenský standard před zavedením veřejné domény s operačním systémem BSD Unix. Praktické využívání zahájil TCP/IP s protokolem IP ve verzi 4, která je stále ještě nejrozšířenější.

Síťový protokol IP odpovídá třetí (síťové) vrstvě referenčního modelu ISO/OSI pro budování sítí, který se zabývá adresací, doručováním, fragmentací datového toku do paketů a jejich zpětnému skládání do původního toku na příjmu. Protokol TCP (ve čtvrté, transportní, vrstvě) zajišťuje konektivitu mezi koncovými uživatelskými zařízeními v koncových uzlech sítě. Formálně byl protokol TCP specifikován v prosinci 1974 Vintem Cerfem, Yogenem Dalalem a Carlem Sunshinem.

I když datagram posloužil velmi dobře při řešení nejdůležitějších cílů internetové sítě,  nelze říci, že sloužil dobře jednalo-li se o cíle, které byly mimo seznam priorit. Například splnění cílů správy zdrojů a uživatelských účtů se v kontextu datagramů ukázalo obtížným. Jak je uvedeno výše, většina datagramů je spíše součástí určitého sledu paketů proudících ze zdroje do místa určení než osamocených jednotek na aplikační úrovni. Avšak brána uzlu sítě nemůže přímo “vidět” existenci tohoto sledu, neboť jejím úkolem je obsloužit každý paket samostatně. Tudíž funkce správy zdrojů nebo uživatelských účtů se musejí odehrávat u každého paketu zvlášť. Působivý datagramový model na síťové úrovni byl v této vrstvě ochuzen o důležitý zdroj informací, které by v ní mohly být využity pro splnění daných cílů.

Uvedené naznačuje, že pro další generaci architektury může být lepší jiný stavební blok než datagram. Obecnou charakteristikou takového stavebního bloku je to, že by měl rozpoznat sled paketů proudících ze zdroje do místa určení bez předpokládání jakékoli konkrétního typu služby.

V kontextu jejích priorit byla internetová architektura značně úspěšná. Protokolům se dostalo širokého využití ve vojenském i komerčním prostředí a dala vznik řadě podobných architektur. Její úspěch současně ukázal, že v určitých situacích nejsou priority, které byly do ní zapracované, sladěny s potřebami konkrétních uživatelů. V oblastech zvláštní správy je nutné věnovat pozornost takovým věcem jako uživatelským účtům, správě zdrojů a oblastem separátní správy a řízení.

V internetových sítích je každému zařízení přiřazena jedinečná adresa, a jelikož TCP/IP funguje  ve středních až vyšších vrstvách referenčního modelu ISO/OSI, nejsou charakteristiky základní nosné sítě podstatné. I když by převodový a demokratický charakter internetové sítě mohl předpokládat způsob práce na stejnolehlých úrovních (peer-to-peer) používají služby TCP/IP model klient-server, v kterém počítač zajišťuje data jako odezvu na požadavek od klientů (např. z jejich internetových prohlížečů - webových browserů). Specifické pro TCP/IP je to, že používají zcela otevřené (neproprietární) standardy a mohou provozovat a propojovat  jakékoli druhy  technologií sítí  - veřejné nebo privátní, LAN, WAN, bezdrátové sítě, apod. Protokoly TCP/IP umožňují velkou škálovatelnost. I když standardy byly postupně zpřesňovány a dolaďovány, technologie, které podporují stále přibývající desítky milionů současných uživatelských připojení jsou v podstatě stejné jako ty, co byly vyvinuty v 70. létech minulého století.

Podívejme se, jak obtížné (či spíše jak snadné) je osvojit si protokoly TCP/IP a začít je používat. Pomineme-li jeden den potřebný na uvedení potenciálního uživatele do problematiky, praktické vyškolení v základech TCP/IP si vyžádá tak tři až čtyři dny. Závisí to na stavu základních zkušeností uživatele s prací v sítích. Školení v protokolech TCP/IP může být zajištěno od dodavatelů zařízení pro počítačové sítě nebo nezávislých školitelských organizací. Mnohé studijní materiály jsou volně dostupné na webu. Často jsou sice staršího data, avšak jsou stále platné. Jeden z nejúplnějších a aktualizovaných studijních materiálů je webový dokument na adrese www.tcpipguide.com.

Oblasti, ve kterých se protokoly TCP/IP využívají se postupně rozšiřují. Základními dnes jsou síťové přenosy dat, hovoru (hovor po IP, angl. zkratka VoIP) a stále přibývajících multimediálních informací. Bez ohledu na dodavatele se dnes systémy založené na TCP/IP provozují téměř v každé lokální síti a síti s dálkovými spoji, včetně bezdrátových sítí. V posledním období udělaly “díru do světa” cloudové technologie s daty, aplikacemi a dalšími zdroji sídlícími mimo počítač uživatele.

Možné scénáře budoucího rozvoje Internetu v grafickém vyjádření

Stručné porovnání referenčního modelu ISO/OSI s modelem TCP/IP

V modelu TCP/IP pro internetové sítě nabyly protokoly úmyslně vytvořeny tak, aby byly přísně (a tím i nepružně) včleněny  do vrstev tak, jak je tomu v referenčním modelu ISO/OSI. Dokument RFC 3439 (RFC je anglickou zkratkou Request for Comments, což jsou pracovní dokumenty ústředního internetového orgánu IETF - Internet Engineering Task Force a Internet Society, z nichž některé mají status internetového standardu) například obsahuje část s názvem “Členění do vrstev, které je považované za škodlivé”. Přesto model TCP/IP zná čtyři obsahově široké vrstvy s funkčností, která je odvozena z provozního charakteru protokolů jež obsahuje, tj. z charakteru softwarových aplikací, transportní konektivity z jednoho konce sítě do druhého konce (end-to-end), funkčního rozsahu propojovaných sítí (internetworkingu) a charakteru přímých spojů do dalších uzlů v lokálních sítích.

I když koncept TCP/IP není sadou protokolů povolenou mezinárodní standardizační organizací ISO a liší se od modelu ISO/OSI (jak již víme z výše uvedeného), jsou nicméně jeho vrstvy často porovnávány s vrstvovým schématem OSI v následujících ohledech:

• Internetová aplikační vrstva zahrnuje funkce aplikační, prezentační a z větší části i relační vrstvy ISO/OSI.
• Jeho transportní vrstva pro konektivitu “end-to-end” zahrnuje velmi blízké funkce relační a transportní vrstvy ISO/OSI.
• Mezisíťová vrstva představuje svého druhu podskupinu síťové vrstvy ISO/OSI (podrobněji viz výše v textu předchozích kapitol).
• Kombinovaná vrstva datového spoje zahrnuje vrstvu datového spoje ISO/OSI a fyzické vrstvy, k tomu ještě části síťové vrstvy ISO/OSI.

Tato porovnání jsou založena na sedmivrstvém protokolovém modelu, jak je definován ve standardu ISO 7498, spíše než na dokumentu zpřesňujícím takové věcí jako je vnitřní organizace síťové vrstvy.

Přísné stejnolehlé vrstvení v modelu ISO/OSI, jak se obvykle popisuje, přitom nepředstavuje vnitřní rozpor v TCP/IP, jelikož se připouští to, že použití protokolu se nemusí řídit hierarchií nepřímo vyjádřenou ve vrstvovém modelu. Takové příklady existují v některých směrovacích protokolech (např. OSPF), nebo v popisu tunelovacích protokolů, které zajišťují kombinovanou vrstvu datového spoje pro aplikaci, i když tunelovací protokol počítače může být stejně dobře protokolem transportní, nebo dokonce aplikační vrstvy.

Když byl vytvořen Internet jako síťová struktura, byly dva navzájem konkurenční modely pro síťovou architekturu. Smyslem obou bylo definovat strukturní a modulární řešení pro tvorbu sítí. Na jedné straně jsou zde vládní orgány a ISO, které vytvářejí standardy, závazné pro akceptování všemi členskými státy. Na druhé straně jsou skupiny technických pracovníků, kteří vytvoří protokol, testují jej, nacházejí a odstraňují chyby a opětně jej testují, dokud protokol není provozuschopný.

Na ISO/OSI se někdy pohlíží jako na případ v němž se práce na standardu odvádí na papíře a to důsledně na základě teorie, zatímco TCP/IP je výsledkem práce “party lidí”, kteří si sednou, mají ruce samý softwarový kód, učí se ze zkušeností a v tom co tvoří hned vidí, která část je provozuschopná a která ne.

To jsou krátce a pregnantně vyjádřené plusy a minusy obou modelů. Podíváme-li se např. na problém z dlouhodobého pohledu a budeme-li se na práci pečlivě připravovat, pak může být takový přístup dlouhodobým přínosem. Bude-li v budoucnu nutné přidávat do protokolu nové doplňky, může být obtížné spravovat protokol “záplatami”. Bez prozíravosti a obezřetnosti pro zahrnutí budoucích potřeb při plánování, se bude záplatování podobat spíše “nabourávání” než optimalizaci pomocí strukturovaného kódování. Je-li protokolový stek široce používán,  nejsou lidé zpravidla nějak zvlášť ochotní aktualizovat svůj systém a raději třeba i zůstanou nekompatibilní s jinými systémy. Důležitý poznatek svědčí o tom, že zajištěním možnosti pro širší okruh lidí moci si hned zpočátku vyzkoušet provozní možnosti, poklesne pravděpodobnost toho, že později v budoucnu bude nutné protokolový stek modifikovat.

Někdy má jednoduchý problém jednoduché řešení. V podobném případě je čas, věnovaný pečlivému plánování přístupu k řešení, zbytečnou časovou ztrátou neboť řešení může být jednoduché a časově nenáročné. Je možné, že problémy které se v “reálném světě sítí” vyskytnou, neukáží zda řešení musí být na papíře a musí být podpořené teorií. Bez zkušeností z řešení problémů a praktického ověření se nedá očekávat, že se podaří problém vyřešit pouze na papíře, navíc se tím práce neúměrně prodlužuje.

Ukončeme porovnání obou modelů několika závěrečnými poznámkami. Model ISO/OSI je teoretickým, avšak přitom nezpochybnitelným generickým konceptem sady architekturních vrstev tvorby sítí. Různé implementace modelu TCP/IP, vyvinuté pro různé operační systémy (např. Unix, Windows, Linux), hardware počítačů, atd., jsou zase plně provozuschopnými praktickými verzemi modelů pro tvorbu sítí, ve skutečnosti značně provázanými s modelem ISO/OSI. Model ISO/OSI je mezinárodním oficiálním a platným standardem de-jure, zatímco model TCP/IP takový charakter nemá, je však nezpochybnitelným standardem de-facto uchopeným průmyslem, softwarovými a dalšími společnostmi mnoha zemí. V praxi se stal celosvětově nejrozšířenějším komerčním produktem se stále větší škálou konkrétních hardwarových i softwarových verzí síťových prvků. Ve formě další generace s IPv6 je před TCP/IP velká perspektiva dalšího rozvoje. Ovšem v jistém smyslu však stále můžeme nahlížet model TCP/IP jako určitou modifikovanou ‘podmnožinu’ modelu ISO/OSI.

Význam modelu TCP/IP pro vojenské systémy C4ISR

Podíváme-li se na věc z aktuálního vojenského pohledu, pak z původního postavení TCP/IP, jako standardu ministerstva obrany USA, tento model dalším rozvojem pronikl do komunikačních a informačních systémů C4ISR armád NATO a ozbrojených sil Západu (mimochodem, stále více se rozšiřují oblasti jeho využívání i v nových systémech ozbrojených sil Ruské federace). V posledních několika letech si bez modelu TCP/IP, jako důležitého jednotícího systémového nástroje, nelze představit přechod moderních armád na koncept síťově centrických operací - NNEC na úrovni NATO a NEC na úrovni národních armád.

⧫⧫⧫⧫⧫

Výběr pramenů:

Andrew L. Russel: “OSI: The Internet that Wasn’t”, IEEE Spectrum, vol. 50, August 2013, No. 8

David D. Clark: “The Design Philosophy of the DARPA Internet Protocols”, Computer Communications Review, vol. 18, No. 4 August 1988 (ACM SIGCOMM)

Ivo Maathuis, Wim A. Smith: “The Battle between Standards:TCP/IP vs OSI Victory through Path Dependency or by Quality?”, SIIT2003 Conference Proceedings (IEEE)

David M. Piscitello, A. Lyman Chapin: “Open Systems Networking TCP and OSI”, Addison Wesley, 1993