Jedním z nejnov╪jτích marketingov∞ch hità v oblasti aktivních prvkà pro poƒítaƒové sít╪ je schopnost p²epínání na úrovni 4. vrstvy neboli tzv. "Layer 4 Switching". Je to n╪co, co má reáln∞ smysl a konkrétní p²ínos, nebo je to jen prázdné heslo, které nep²ináτí fakticky nic nového? A o co vlastn╪ jde?
Ano, ƒi ne?
P²enosové protokoly z rodiny protokolà TCP/IP nejsou schopné rozliτovat ràzné druhy provozu a ke vτem p²enáτen∞m datàm se chovají stejn╪, na principu "maximální snahy" (anglicky: best effort). Pokud je to moºné, snaºí se je p²enáτet co nejrychleji, ale pokud to nejde - nap²íklad kvàli momentáln╪ nedostateƒné p²enosové kapacit╪ - krátí vτechny poºadavky na p²enos rovnom╪rn╪. Kvàli tomu màºe docházet k ràzn∞m zdrºením v p²enosu dat, a dokonce i k jejich ztrát╪.
Vadí absence QoS?
To, co sít╪ TCP/IP postrádají, je obvykle oznaƒováno jako QoS (Quality of Service, doslova: "kvalita sluºeb"). Vysv╪tlení této skuteƒnosti je jednoduché: v dob╪, kdy protokoly TCP/IP vznikaly, nebyla takováto podpora pro "kvalitu sluºeb" vyºadována. Protokoly TCP/IP vznikaly v làn╪ rodícího se internetu, pro jeho pot²eby a sluºby, a ty v té dob╪ m╪ly tém╪² v∞hradn╪ charakter dávkového p²enosu souborà ƒi elektronické poτty a tzv. vzdáleného p²ihlaτování. Proto onen dàraz na maximáln╪ efektivní vyuºití p²enosov∞ch cest, by£ za cenu pouhé "maximální snahy" vàƒi p²enáτen∞m datàm, ale ºádné garance.
Dnes je ale situace dosti odliτná, a to nejen v internetu, ale i ve vτech sítích na bázi TCP/IP. Dnes se objevuje celá ²ada aplikací, které ke svému fungování vyºadují urƒité specifické chování p²enosové ƒásti sít╪. P²íkladem mohou b∞t snahy p²enáτet po sítích TCP/IP (které jsou ze své podstaty paketov∞mi sít╪mi) digitalizovan∞ lidsk∞ hlas, a to pro pot²eby telefonování, v rámci tzv. IP telefonie, resp. telefonie internetové. Pro takovéto "ºivé" sluºby, mezi které pat²í i ràzné druhy video- a audiokonferencí, je velmi dàleºitá rychlost a pravidelnost, s jakou jim budou doruƒovány jednotlivé ƒásti dat. Sít╪ na bázi TCP/IP ale nedokáºou dát t╪mto "ºiv∞m" datàm p²i jejich p²enosu p²ednost p²ed jin∞mi daty, u kter∞ch rychlost a pravidelnost doruƒování nemusí hrát p²íliτ velkou roli.
Jin∞m p²íkladem, kter∞ je asi nejƒast╪ji uvád╪n jako argument pro p²epojování na 4. vrstv╪, je moºnost rozkladu zát╪ºe v závislosti na aplikacích a probíhajících relacích. P²edstavíme-li si nap²íklad velk∞ poƒet uºivatelà, kte²í pouºívají urƒitou sluºbu souƒasn╪ (nap²íklad cht╪jí komunikovat se servery virtuálního m╪sta v eCity, abychom nechodili pro p²íklady daleko), pak veτker∞ provoz, kter∞ generují, je standardn╪ sm╪rován k jedinému v∞konnému serveru, kter∞ nemusí vºdy "stíhat" tak velkou zát╪º. Moºn∞m ²eτením je z²ídit n╪kolik serverà, které by se o zát╪º pod╪lily, ale otázkou je, jak to ud╪lat. Není dost dob²e moºné rozd╪lit uºivatele tak, aby se kaºd∞ sám obracel na nejmén╪ vytíºen∞ server, a tím se staral o rovnom╪rn∞ rozklad zát╪ºe. To musí b∞t realizováno automaticky a z pohledu uºivatele pln╪ transparentn╪ - tak aby se uºivatel vºdy obracel k jedinému poskytovateli urƒité sluºby, ale fakticky byl jeho poºadavek vyslyτen a realizován takov∞m poskytovatelem (serverem), kter∞ je momentáln╪ nejmén╪ vytíºen∞. Obecn╪ji pak màºe jít o takov∞to "rozklad" zát╪ºe i v závislosti na tom, jaká sluºba je poºadována - zda jde nap²íklad o poºadavek na WWW stránku, o dotaz do systému DNS, o poºadavek na soubor z FTP archivu apod.
Otázka ale je, jak takov∞mto poºadavkàm, závisl∞m na konkrétní aplikaci, co nejlépe vyhov╪t. To není moºné bez dostateƒné znalosti konkrétních aplikací ani bez schopnosti rozpoznat z p²enáτen∞ch dat dostateƒn╪ p²esn╪, kdy jde o jaké poºadavky. Celou v╪c p²itom komplikuje i fakt, ºe data tvo²ící konkrétní poºadavky mohou b∞t p²enáτena po jednotliv∞ch datov∞ch paketech, které vτak tvo²í urƒit∞ logick∞ celek - a tak není moºné zpracovávat kaºd∞ datov∞ paket nezávisle na ostatních, ale je nutné uvaºovat jejich vzájemné vazby (nap²íklad poºadavek p²enáτen∞ v podob╪ n╪kolika datov∞ch paketà je t²eba zpracovat vºdy stejn╪, nap². sm╪rovat jej stejnému serveru). Jeτt╪ dalτí komplikací jsou logické vazby, jeº vypl∞vají ze spojovaného charakteru ràzn∞ch relací na aplikaƒní úrovni: Pokud konkrétní uºivatel zaƒne komunikovat s konkrétním fyzick∞m serverem a tato komunikace má spojovan∞ charakter a podobu relace (tj. má n╪jakou historii a dalτí pràb╪h), pak vτechny dílƒí poºadavky musí b∞t fakticky sm╪rovány ke stejnému fyzickému serveru, aby byla zajiτt╪na pot²ebná logická kontinuita. A to opravdu není jednoduché, zejména pro za²ízení zajiτ£ující pot²ebn∞ rozklad zát╪ºe, protoºe to vyºaduje dosti hlubokou znalost konkrétní aplikace i pom╪rn╪ velkou inteligenci pro p²ísluτné rozhodování.
Moºné cesty k ²eτení
Neschopnost sítí postaven∞ch na bázi TCP/IP vyhov╪t v∞τe naznaƒen∞m poºadavkàm je samoz²ejm╪ známa jiº delτí dobu a snahy ²eτit tento problém také nejsou zcela nové. V souƒasné dob╪ existují dva hlavní p²ístupy k ²eτení, liτící se svou podstatou.
Prvním moºn∞m p²ístupem je modifikace p²enosov∞ch vlastností sítí TCP/IP, tak aby vedle dosavadního zpàsobu fungování p²enosové ƒásti sít╪ vznikl urƒit∞ "vyhrazen∞ kanál" s lepτími p²enosov∞mi vlastnostmi (hlavn╪: schopn∞ garantovat kvalitu p²enosov∞ch sluºeb). Konkrétní podoba je taková, ºe pomocí "rezervaƒního mechanismu" (konkrétn╪ protokolu RSVP) se v rámci sm╪rovaƒà (routerà) p²edem vyhradí urƒitá p²enosová kapacita pro takovéto p²enosy, jeº se pak realizují pomocí samostatného p²enosového protokolu (protokolu RTP, Real-Time Protocol). Celkov∞ efekt pak bude takov∞, jako kdyby vedle sebe existovaly paraleln╪ dv╪ na sob╪ nezávislé p²enosové sít╪, jedna fungující jako doposud (na principu "maximální snahy") a druhá na principu garantovan∞ch vlastností.
Princip p²epínání na 4. vrstv╪
Druh∞m moºn∞m p²ístupem, kter∞ se v souƒasnosti r∞suje a b∞vá oznaƒován práv╪ jako "p²epínání na úrovni 4. vrstvy" (Layer 4 Switching), je p²ístup zaloºen∞ na modifikaci celého mechanismu, kter∞ rozhoduje o dalτím osudu dat p²enáτen∞ch p²es ràzné "p²estupní uzly" v celé síti (jde tedy o jejich pràchod sm╪rovaƒi, switchi atd.). Takov∞ mechanismus lze nazvat mechanismem sm╪rování, p²epínání ƒi p²epojování. Podstata zm╪ny spoƒívá v tom, ºe tento mechanismus se vàƒi ràzn∞m druhàm provozu bude chovat ràzn╪ - n╪kter∞m datàm bude dávat p²ednost p²ed druh∞mi nebo je bude zpracovávat jinak (nap²íklad p²i rozkládání zát╪ºe je bude posílat ràzn∞mi sm╪ry, podle momentálního stavu zát╪ºe a dalτích kritérií).
Dàleºité ale je, ºe k n╪ƒemu takovému musí b∞t p²ísluτné rozhodování zaloºeno na dosti hluboké znalosti v∞znamu p²enáτen∞ch dat (a tím i aplikací, kter∞ch se tato data t∞kají). Nejde tedy jiº o klasické p²epojování (switching), jak je obvykle oznaƒováno fungování p²ísluτn∞ch mechanismà na úrovni 2. vrstvy (ve smyslu sedmivrstvého modelu ISO/OSI) - zde se tento mechanismus rozhoduje v∞luƒn╪ podle adres uzlà na úrovni 2. vrstvy (tedy nap²íklad podle ethernetov∞ch adres). Nejde ani o klasické sm╪rování (routing), jak je oznaƒováno fungování p²ísluτn∞ch mechanismà na úrovni 3. vrstvy (vrstvy sí£ové) - zde je p²ísluτné rozhodování zaloºeno v∞hradn╪ na sí£ov∞ch adresách, tedy na tzv. adresách IP. Místo toho je nutné zaloºit p²ísluτné rozhodovací mechanismy, které rozhodují o dalτím zpracování p²enáτen∞ch dat, na informacích, které logicky pat²í do vyττích vrstev. Konkrétn╪ to znamená, ºe rozhodovací mechanismus musí jít p²i své anal∞ze p²enáτen∞ch dat mnohem "hloub╪ji" a uv╪domovat si nejen adresy p²íjemcà a odesilatelà, ale také nap²íklad tzv. ƒísla portà (coº identifikuje druh aplikace, které se p²enáτená data t∞kají). N╪kdy vτak musí jít jeτt╪ hloub╪ji a podrobn╪ji analyzovat data "pat²ící" urƒité aplikaci - nap²íklad proto, aby v rámci zát╪ºe mohl respektovat logickou kontinuitu urƒité relace.
Pravda je, ºe informace, ze kter∞ch takovéto rozhodování vychází, odpovídají úrovni transportní vrstvy (p²edevτím tzv. ƒísla portà), a dokonce úrovni vrstvy aplikaƒní (data pat²ící p²ísluτné aplikaci). Proto má jisté opodstatn╪ní mluvit o "p²epojování" na úrovni 4. vrstvy.
Ano, ƒi ne?
P²i hodnocení celého konceptu "p²epínání na 4. vrstv╪" je dobré mít na pam╪ti, ºe tak jako u v╪tτiny podobn∞ch "hità" je zde urƒité racionální jádro a kolem n╪j "marketingov∞ obal", kter∞ se snaºí toto jádro prodat.
Racionálním jádrem je snaha jeτt╪ dále zlepτit p²enosové vlastnosti sítí TCP/IP, a to nikoli extenzivním zpàsobem neboli "p²ístupem hrubou silou" - tedy prost∞m zvyτováním celkové p²enosové kapacity a rychlosti p²epojování datov∞ch paketà bez uváºení jejich v∞znamu a charakteru. Jde naopak o snahy "zkvalitnit" p²enosové vlastnosti, sm╪²ující k respektování v∞znamu a povahy dat, tak aby byly respektovány ràznorodé poºadavky na jejich zpracování, samoz²ejm╪ vƒetn╪ celkové rychlosti tohoto zpracování. Na pot²eb╪ n╪ƒeho takového se odborné prameny vcelku shodují.
V ƒem se odborné prameny naopak liτí, je názor na to, jak k∞ºeného cíle dosáhnout, a zda to vàbec oznaƒovat jako "p²epínání na 4. vrstv╪" - kdyº podobn╪ jako u p²epínání na 2. a 3. vrstv╪ je skuteƒn∞m rozdílem pouze to, jaké informace se berou v úvahu p²i p²ísluτném rozhodování o dalτím osudu jednotliv∞ch datov∞ch blokà, které prochází p²es n╪jak∞ "p²estupní" uzel. P²itom i n╪která inteligentní za²ízení, oznaƒovaná jako "p²epínaƒe" na 2. ƒi 3. vrstv╪, mají jiº dnes zabudovány urƒité schopnosti reagovat na povahu p²enáτen∞ch dat a podle toho modifikovat své chování.
