Báječný svět počítačových sítí

Část XII: Transportní vrstva

Transportní vrstva je první vrstvou, se kterou se setkáme pouze v koncových uzlech sítě, ale nikoli v jejích vnitřních uzlech (ve směrovačích). Však také hlavním úkolem transportní vrstvy je zajišťovat vzájemnou komunikaci koncových uzlů (tzv. end-to-end komunikaci). Je také první vrstvou, která v rámci uzlu rozlišuje jednotlivé entity (procesy), prostřednictvím tzv. portů. Nižší vrstvy se na jednotlivé uzly dívají vždy jako na dále nedělitelný celek.

V našem průchodu sedmi vrstvami Referenčního modelu ISO/OSI jsme se dostali až na úroveň vrstvy transportní. Ta je v rámci RM ISO/OSI čtvrtou v pořadí, ať již vrstvy počítáme "zdola", nebo "shora". Na transportní vrstvu se přitom můžeme dívat jako na jakousi přizpůsobovací vrstvu mezi trojicí nižších vrstev, orientovaných na přenos dat (vrstev fyzické, linkové a síťové), a trojicí vyšších vrstev, orientovaných už spíše na aplikace a jejich podporu. Naznačuje to ostatně i dnešní první obrázek.

Transportní vrstva v rámci Referenčního modelu ISO/OSI

V rámci síťového modelu TCP/IP transportní vrstva samozřejmě existuje také, ale je teprve druhou (počítáno odshora), resp. třetí vrstvou (odspodu). Jde o důsledek skutečnosti, kterou bychom měli dobře znát již z předchozích dílů tohoto seriálu: že zatímco referenční model ISO/OSI má sedm vrstev, TCP/IP má pouze čtyři vrstvy. A také s nimi vystačí. Navíc svou nejnižší vrstvu, vrstvu síťového rozhraní, TCP/IP samo nijak nedefinuje (ale používá zde řešení pocházející odjinud).

Transportní vrstva v TCP/IP

Ani menší počet vrstev v TCP/IP však nemění nic na tom, že transportní vrstva je první vrstvou (počítáno odspodu), která je přítomná až v koncových uzlech, a nikoli ve vnitřních uzlech sítě (ve směrovačích). Vzhledem k tomu má na starosti vzájemnou komunikaci koncových uzlů, pro kterou se i češtině vžilo označení, pocházející z angličtiny: end-to-end komunikace (doslova: komunikace "konec-konec").

Představa end-to-end komunikace

To, aby se transportní vrstva mohla soustředit na vzájemnou komunikaci koncových uzlů, jí umožňuje bezprostředně nižší vrstva - vrstva síťová. Ta má na starosti hledání vhodných cest v síti, resp. v soustavách vzájemně propojených sítí (přes jednotlivé směrovače), a samozřejmě i doručování dat po takovýchto cestách. Tím vlastně vytváří iluzi (určenou transportní vrstvě), že všechny koncové uzly jsou mezi sebou propojeny přímo, stylem "každý s každým". Takže transportní vrstva se pak již může soustředit na další aspekty toho, jak si koncové uzly vzájemně vyměňují (předávají) svá data a komunikují mezi sebou. Ale jaké aspekty to vlastně jsou? Co přesně transportní vrstva dělá?

To záleží i na tom, co a jak nabízí a poskytuje vrstva síťová - a co a jak na tom má či nemá transportní vrstva měnit, zda a co k tomu má přidávat atd.

Síťová vs. transportní vrstva ISO/OSI

Referenční model ISO/OSI a síťový model TCP/IP se liší i v tom, jakou mají představu o fungování své síťové vrstvy. RM ISO/OSI má blíže k "telekomunikačnímu paradigmatu", v rámci kterého vítězí představa inteligentní a na funkce bohaté sítě ("chytré sítě"), a třeba i jednoduchých ("hloupých") koncových uzlů. Součástí této představy je i to, že přenosy dat na všech úrovních (vrstvách) by měly probíhat spojovaným způsobem, a tedy s navazováním spojení mezi odesilatelem a příjemcem. Dále představa, že přenosy dat na jednotlivých vrstvách by měly být řešeny jako spolehlivé, a tedy starat se o nápravu toho, co se pokazí - jak eventuelních ztrát dat, tak i eventuelních výpadků spojení. Ovšem ne vždy bude tato náprava dokonalá (stoprocentní). Proto se počítá s tím, že tato "náprava" bude pokračovat i na vyšších vrstvách, které se také budou snažit o zajištění (lepší, resp. vyšší) spolehlivosti.

Autoři ISO/OSI přitom správně předpokládali, že jejich síťová vrstva bude nasazována v různém prostředí, které se liší četností výpadků spojení a ztrát dat. Například v prostředí lokálních sítí, kde asi lze očekávat relativně málo takovýchto výpadků a ztrát. Nebo v prostředí veřejných datových sítí, kde mohou být nějaké výpadky spojení, ale data by se ztrácet neměla. A stejně tak v prostředí rozlehlých sítí, kde se data mohou ztrácet relativně častěji, a stejně tak může častěji vypadávat spojení.

Kvůli tomu se autoři ISO/OSI rozhodli zavést tři různé varianty (kategorie) síťových protokolů,

• kategorie A: pro prostředí, kde dochází k minimálním (žádným) ztrátám paketů a minimálním (žádným) výpadkům spojení
• kategorie B: pro minimální (žádné) ztráty paketů, a občasné výpadky spojení
• kategorie C: pro prostředí kde jsou občasné ztráty paketů a občasné výpadky spojení

Od transportní vrstvy se pak ve světě ISO/OSI očekává, že bude zachovávat spojovaný způsob fungování, a také že se bude snažit ještě lépe kompenzovat eventuelní výpadky spojení a ztráty dat. Dokonce se od ní očekává i určitá optimalizace, v tom smyslu že se může snažit navazovat více transportních spojení skrze jedno jediné síťové spojení. Motivace pro tuto optimalizaci pochází z prostředí veřejných datových sítí, kde se platilo za zřizování každého jednotlivého (síťového) spojení. Takže schopnost využít jedno takové spojení pro více spojení transportních mohla ušetřit náklady.

Celkově pak transportní vrstva ISO/OSI předpokládala pět různých variant (tříd) transportních protokolů, označovaných TP0 až TP4:

• třída TP0: je pouze jednoduchou nadstavbou nad síťovým protokolem kategorie A, nemění jeho vlastnosti
• třída TP1: je nadstavbou nad síťovým protokolem kategorie B, omezuje případné výpadky spojení
• třída TP2: je nadstavbou nad A, dokáže využít jedno síťové spojení pro více transportních spojení
• třída TP3: je nadstavbou nad B, omezuje případné výpadky spojení a dokáže využít jedno síťové spojení pro více transportních spojení
• třída TP4: je nadstavbou nad C, omezuje případné výpadky spojení a ztráty paketů

Celou představu ilustruje čtvrtý obrázek.

Představa síťových a transportních protokolů ISO/OSI

Síťová vs. transportní vrstva TCP/IP

Ve světě TCP/IP se uplatňuje "počítačové" paradigma, volající po "hloupé síti a chytrých uzlech". Tedy po maximálním zefektivnění přenosové části sítě, která bude nabízet jen minimum funkcí v co nejjednodušším provedení (proto "hloupá síť"), ale zato je bude realizovat velmi efektivně (rychle). O všechno ostatní, pokud je to vůbec požadováno, by se měly starat až koncové uzly, na úrovni transportní (nebo aplikační) vrstvy, a nikoli přenosová část sítě (na úrovni vrstvy síťové).

Konkrétním příkladem toho, co je ve světě TCP/IP považováno za něco "ne zcela nezbytného", čím by se síťová vrstva neměla zatěžovat a zpomalovat, je zajištění spolehlivosti přenosů. Tedy kompenzace (náprava) případných ztrát paketů, pokud k nim vůbec dojde. Je-li vůbec spolehlivost přenosů požadována, měly by si ji zajistit koncové uzly samy. Vzhledem k celému paradigmatu ("hloupá síť, chytré uzly") k tomu mají lepší předpoklady než síť jako taková, resp. její síťová vrstva.

Dalším rozdílem oproti ISO/OSI je to, že v TCP/IP se na úrovni síťové vrstvy jednoznačně preferuje nespojovaný způsob fungování, a tedy bez navazování spojení mezi odesilatelem a příjemcem. To má významný důsledek v tom, že nemůže docházet k žádným výpadkům spojení (když žádné takové ani není navazováno). A také není třeba (na síťové vrstvě) ani žádné takové výpadky kompenzovat.

Společným důsledkem obou výše uvedených skutečností (preference nespolehlivé a nespojované komunikace na úrovni síťové vrstvy) je pak to, že TCP/IP nepotřebuje rozlišovat různé kategorie síťových přenosových protokolů, jako RM ISO/OSI (viz jeho kategorie A, B a C). Místo toho vystačí jen s jedním jediným síťovým protokolem, a to protokolem IP. Snad netřeba už tolik zdůrazňovat, že funguje nespojovaně a nespolehlivě - a že dokáže fungovat snad v jakémkoli prostředí (nad jakoukoli přenosovou technologií linkové vrstvy, resp. vrstvy síťového rozhraní).

Představa síťových a transportních protokolů v TCP/IP

V TCP/IP pak nad takto koncipovanou síťovou vrstvou existuje transportní vrstva, která nabízí dva různé transportní protokoly (místo pěti v ISO/OSI). Liší se v tom, zda zachovávají celkový způsob fungování síťového protokolu IP (tj. jeho nespojovaný a nespolehlivý charakter komunikace), nebo zda se jej snaží měnit - na spojovaný a spolehlivý. S oběma takto koncipovanými transportními protokoly jsme se už v předchozích dílech setkali:

• protokol UDP (User Datagram Protocol): je pouze jednouchou nadstavbou nad protokolem IP a funguje stejně jako on (tj. nespojovaně a nespolehlivě)
• protokol TCP (Transmission Control Protocol): je už složitější nadstavbou nad protokolem IP, a mění jeho způsob fungování - na spojitý a spolehlivý

Logika existence dvou transportních protokolů, které jsou vzájemně alternativní, je v tom že aplikace si mohou samy svobodně vybrat, který z nich chtějí používat. Například "klasické" počítačové aplikace, jako například přenos souborů, el. pošta atd., preferují zajištění spolehlivosti, a dávají přednost protokolu TCP. Naproti tomu novější multimediální aplikace dávají přednost spíše protokolu UDP, protože ten se nezdržuje zajišťováním spolehlivosti, a dokáže tak přenášet data rovnoměrněji a s menší prodlevou (latencí), než protokol TCP. Příklad preferencí některých aplikací naznačuje obrázek č. 6.

Volba transportních protokolů v TCP/IP

Další úkol transportní vrstvy

Transportní vrstva má obecně (v RM ISO/OSI i v TCP/IP) ještě další úkoly, kromě toho co jsme si popisovali v předchozích odstavcích. Vlastně jsme si to naznačili již v perexu: transportní vrstva je první vrstvou (měřeno "odspodu"), která se již nedívá na jednotlivé uzly jako na dále nedělitelné celky, ale rozlišuje v nich jednotlivé entity, které vystupují buď jako příjemci, nebo jako odesilatelé dat.

Abychom si trochu přiblížili, o co vlastně jde: na jednom počítači může běžet několik aplikací, které komunikují s dalšími uzly v síti, a to nezávisle na sobě. Například uživatel může mít na svém osobním počítači puštěný WWW browser, skrze který právě brouzdá báječným světem WWW. Vedle toho má puštěného i klienta elektronické pošty, skrze kterého přijímá svou elektronickou korespondenci. Tím výčet možností samozřejmě zdaleka nekončí, ale pro nástin podstaty problému stačí alespoň dva různé běžící programy, resp. aplikace. Představme si totiž, co se má stát v okamžiku, kdy uživatelův počítač přijme nějaká data. Komu mají být předána? Webovému browseru? Nebo emailovému klientovi? Jistě by to mělo záviset na tom, zda přijatá data představují nějakou WWW stránku, zprávu el. pošty, nebo třeba soubory, přenášené prostřednictvím protokolu FTP či něco ještě jiného. Ale kdo by to měl zkoumat, a podle čeho?

Síťová vrstva takovéto otázky neřeší. Pro ni je každý uzel sítě dále nedělitelný celek. Takže když přijme nějaká data pro daný uzel, nezajímá se o to, komu (které aplikaci) patří, a vždy je předá své bezprostředně vyšší vrstvě - vrstvě transportní. Teprve transportní vrstva pak má za úkol rozlišovat, komu - v rámci daného počítače - přijatá data patří, a předat je právě a pouze jemu. Obdobně při odesílaní, kdy transportní vrstva přijímá data - zde také rozlišuje, od koho jsou (a tuto informaci musí vhodným způsobem zachovat pro koncového příjemce dat).

Můžeme si to celé představit také tak, že síťová vrstva vytváří přenosový kanál, který je společně využíván všemi odesilateli, resp. příjemci na daném uzlu, s tím že až transportní vrstva zajišťuje na straně odesilatele potřebné "sloučení" (multiplex) dat od různých odesilatelů, do jednoho datového toku, a na straně příjemce zase potřebné "rozbočení" (demultiplex) těchto dat podle toho, komu jsou určena. Vše naznačuje i následující obrázek č. 7, který je oproti obvyklým konvencím jakoby pootočen o 90 stupňů.

Představa multiplexu a demultiplexu na transportní vrstvě

Jinou představu téhož ukazuje i další obrázek (č. 8), na kterém již lze názorně ukázat jeden významný aspekt, týkající se adresování. Je opět společný pro RM ISO/OSI i TCP/IP, a týká se adresování na úrovni transportní vrstvy.

Představa multiplexu a demultiplexu na transportní vrstvě

Porty a body SAP

Jak již víme, na úrovni síťové vrstvy se používají síťové adresy (v TCP/IP tzv. IP adresy), které identifikují jednotlivé uzly jako celky. Přesněji: identifikují jedno síťové rozhraní, s tím že některé uzly (například směrovače) jich mohou mít více. Rozhodně ale tyto síťové adresy nerozlišují jednotlivé příjemce a odesilatele v rámci daného uzlu.

Rozlišování jednotlivých příjemců a odesilatelů má na starosti až transportní vrstva. K tomu také musí používat nějaké konkrétní adresy (transportní adresy), které by měly mít relativní charakter (měly by se vztahovat jen k danému uzlu, resp. rozlišovat jen v rámci tohoto uzlu). Jak by ale tyto transportní adresy měly vypadat?

Problém je v tom, že na různých systémových platformách (například v prostředí MS Windows, Unixu, Linuxu, MAC OS a dalších) mohou být odesilatelé a příjemci obecně různého typu - mohou to být různé procesy, eventuelně systémové úlohy, vlákna, nebo třeba i rezidentní programy (ještě ve starém MS DOSu). Jejich identifikace v rámci příslušné platformy se může i diametrálně lišit. Někdy mohou být identifikováni čísly, jindy znakovými identifikátory apod. Hlavně ale: příslušné entity (procesy, úlohy atd.) vznikají a zase zanikají dynamicky. Takže není dopředu známo, kdo (jaký proces, úloha atd.) bude kde existovat, a měl by přijímat data, určená například WWW serveru (nebo poštovnímu serveru apod.).

Všimněte si dobře jedné věci: na straně příjemce nejde ani tak o to, kdo je ten kdo nějaká data přijímá, jako spíše o to, že "ten někdo" poskytuje určitou službu - a tudíž přijímá data, určená poskytovateli příslušné služby. Tomu, kdo je v roli klienta (například WWW klienta, a vznáší požadavek na nějakou WWW stránku), může být celkem jedno, jaký konkrétní proces na druhé straně plní roli WWW serveru. Důležité pro něj je, aby někdo takový existoval a fungoval, a aby klient věděl, kam mu poslat svůj požadavek. Takže by se vlastně hodila spíše nějaká adresace ve stylu "příjemcem je ten, kdo poskytuje službu AB", místo adresace ve smyslu "příjemcem je proces s identifikátorem XY". A tak to také v praxi (ve světě RM ISO/OSI i TCP/IP) skutečně chodí.

Příslušné adresování, používané na úrovni transportní vrstvy, však není založeno přímo na představě poskytovatelů služeb. To by nemuselo být až tak šikovné, a třeba by to bylo někdy i omezující. Místo toho je použit jiný koncept, založený na představě "přechodových bodů" mezi transportní vrstvou a vrstvou bezprostředně vyšší (což je ISO/OSI vrstva relační), a u TCP/IP vrstva aplikační. Tyto přechodové body jsou určitou abstrakcí, kterou je nejlépe si připodobnit k vyrovnávají paměti (bufferu) s režimem fronty: z jedné strany se do přechodového bodu určitá data vkládají (zapisují), a z druhé strany se z ní ve stejném pořadí vyjímají (čtou). Představu ilustruje následující obrázek (č. 9).

Představa přechodového bodu (portu) jako fronty

Přechodové body jsou obecně obousměrné (lze si je představit jako dvě samostatné fronty s opačným "směrem"). V prostředí RM ISO/OSI se jim říká "body přístupu ke službám" (SAP, Service Access Points), ale známější asi jsou pod svým označením z prostředí TCP/IP, kde se o nich mluví jako o portech.

Porty vs. procesy

Výhodou portů (přechodových bodů SAP) je tedy to, že jsou abstrakcí - a jako takové mohou být všude (na všech platformách) stejné. To má zásadní výhodu v tom, že s jejich existencí je pak možné počítat "dopředu" (apriori), stejně jako s tím, že mají stejné vlastnosti. Konkrétní způsob jejich realizace na každém jednotlivém uzlu sítě naopak může zůstat skryt.

Jednotné (všude stejné) může být i označení portů, resp. bodů SAP, a tím i jejich adresování (na úrovni transportní vrstvy). V prostředí TCP/IP jsou jednotlivé porty adresovány skrze pořadová čísla. Přesněji: pomocí celých nezáporných čísel (0,1, 2, 3, 4 atd.). V praxi se pak hovoří o číslech portů. Třeba o portu číslo 80, o portu č. 25 apod. Takže transportními adresami (relativními adresami na úrovni transportní vrstvy) jsou v TCP/IPO právě tato čísla portů.

Důležité ale je uvědomit si, že port (bod SAP) ještě není to samé, jako proces (úloha, vlákno atd.), které skutečně přijímá a zpracovává nějaká data, nebo je naopak generuje. Port je skutečně jen jakýsi "průchozí bod" (s režimem fronty), za kterým je teprve "schována" příslušný proces (úloha atd.). Ovšem když porty existují "dopředu" (apriori), zatímco aplikační entity (procesy, úlohy) vznikají dynamicky, podle momentálních potřeb, musí i jejich vzájemná vazba být dynamická. V praxi to vypadá tak, že když je vytvořen nějaký proces, a ten má nějak komunikovat v prostředí sítě, musí se nejprve "sdružit" (tzv. asociovat) s některým portem. Teprve pak může odesílat svá data (skrze tento port), a také je (skrze tento port) přijímat. Protistrana, která s takovýmto procesem komunikuje, musí znát číslo příslušného portu, a svá data také adresuje tomuto portu (přesněji: na daný cílový uzel, a v rámci tohoto cílového uzlu příslušnému portu).

Obecně přitom platí, že jeden proces (úloha atd.) může být asociován (sdružen) s více porty. Naopak to ale neplatí: s jedním portem může být sdružen (asociován) nejvýše jeden proces. Důvod je jednoduchý: copak by asi takový port dělal, kdyby přijal nějaká příchozí data? Jak by vybíral mezi dvěma (či dokonce více) procesy, kterým by tato data měl předat?

Představa asociování procesů k portům (v TCP/IP)

Servery a jejich klienti

Ukažme si nyní na konkrétním příkladu, jak celá představa o portech a procesech zapadá do běžné praxe, kdy spolu v prostředí sítě spolu komunikují aplikace a procesy v roli serverů a jejich klientů. Třeba když si uživatel na svém osobním počítači pustí WWW browser, a tomu zadá, že chce navštívit nějakou konkrétní WWW stránku, např. na adrese www.earchiv.cz (kde má svůj osobní archiv autor tohoto seriálu). Webový browser si nejprve nechá přeložit symbolické doménové jméno (www.earchiv.cz) na odpovídající IP adresu, a na ni pak pošle požadavek na stažení konkrétní stránky (např. index.php3). Na cílovém počítači je ale třeba předat příslušný požadavek tomu procesu, který zde plní roli WWW serveru.

Klient (uživatelův browser) přitom dopředu ví, že takovýto proces je sdružen (asociován) s portem číslo 80, a tak jej adresuje právě tomuto portu. Proces, který na adrese www.earchiv.cz funguje jako WWW server, tak požadavek dostane, a v odpovědi na něj zašle klientovi požadovanou WWW stránku (index.php3). Přitom také musí uvést nějaké číslo portu, na které má být odpověď klientovi doručena. Server tedy standardně posílá svou odpověď na stejný port (na straně klienta), ze které mu přišel původní požadavek.

Představa aplikačního spojení

Celou situaci s komunikací klienta a serveru názorně ukazuje předchozí obrázek (č. 11), kterým si můžeme znovu připomenout jiný úkol transportní vrstvy, popisovaným v úvodu: měnit nespolehlivý a nespojovaný způsob komunikace (na úrovni síťové vrstvy, pomocí protokolu IP) na spojovaný a spolehlivý (na úrovni transportní vrstvy, pomocí protokolu TCP), nebo jej ponechávat beze změny, jako nespolehlivý a nespojovaný (pomocí protokolu UDP) - podle toho, co si vybere příslušná alikace. Přitom služba World Wide Web (WWW) je příkladem aplikace, která dává přednost spojovanému a spolehlivému přenosu, a využívá tedy služeb transportního protokolu TCP.

Jen pro ilustraci si naznačme ještě to, jak může jeden WWW server současně poskytovat své služby, skrze jeden a ten samý port (číslo 80), více klientům. Když mu všichni posílají své požadavky na stejnou adresu (IP adresa, port č. 80), jak pozná od koho co pochází a kam má zaslat požadovanou WWW stránku? Odpověď je principiálně jednoduchá a stejná pro všechny druhy serverů: u každého požadavku si pamatují, ze kterého spojení přišel. A toto spojení je obecně určeno pěticí údajů:

• transportním protokolem (v případě WWW jde o TCP)
• IP adresou a portem na straně klienta
• IP adresou na portem na straně serveru

Takže když server dostane dva požadavky od klientů na různých počítačích, liší se příslušná spojení už IP adresou klienta. A pokud by snad šlo o požadavky od dvou různých klientů, běžících na stejném počítači (například když má uživatel puštěny dva browsery, případně jen dvě okna či záložky ve stejném browseru), rozliší je alespoň podle různého čísla portu, použitého na straně klienta. Vše ilustruje i následující obrázek (č. 12)

Představa více spojení, vedoucích ke stejnému serveru

V případě, že komunikace mezi klientem a serverem probíhá nespojovaně (prostřednictvím transportního protokolu UDP), je identifikace odesilatelů a příjemců obdobná. Server dokáže rozlišit požadavky různých klientů podle IP adresy a čísla portu (na straně odesilatele), i když zde žádné spojení vůbec nevzniká.

Konvence o tzv. dobře známých portech

Zastavme se na závěr u jedné důležité drobnosti: jak může webový klient (browser) dopředu vědět, že své požadavky má posílat "svému" serveru na port číslo 80? Jak může vědět poštovní klient, že má odesílanou poštu posílat "svému" serveru na port číslo 25? Jak je tomu pro ostatní služby a aplikace?

Odpověď je taková, že musí existovat určitá konvence, ve výše naznačeném smyslu, a ta musí být dopředu známá všem, kteří ji potřebují znát. To jsou jak ti, kteří programují a provozují servery, tak i ti, kteří píší jejich klienty. Naopak tato konvence nemusí být známa běžným uživatelům. Proč? Například když WWW klient (browser) dostane od svého uživatele pokyn k načtení nějaké konkrétní WWW stránky, automaticky předpokládá, že jej má poslat serveru na port číslo 80, a tak to také dělá. To mu naordinoval (naprogramoval do něj) už jeho autor.

Samozřejmě, pokud by uživatel měl jiné přání, a explicitně by si vyžádal zaslání svého požadavku na nějaký jiný port (např. na port č. 8080, skrze URL ve tvaru http://www.earchiv.cz:8080/index.php3), browser by to respektoval. Ovšem aby takový požadavek mohl být korektně přijat a vyřízen, musel by i na cílovém počítači existovat WWW server, asociovaný s příslušným portem (zde: s portem číslo 8080). Při nějakém testování či ladění tomu tak může být, při běžném rutinním provozu to ale už není zvykem (a WWW server "sedí" na standardním portu č. 80).

Zpět ale k samotné konvenci o tom, který port je k čemu předem vyhrazen: portům, jejichž význam je dopředu stanoven, se v TCP/IP říká příznačně: dobře známé porty (anglicky: well-known ports). Jde obecně o porty v rozsahu od 0 do 1023, a příslušnou konvenci spravuje orgán jménem IANA (Internet Assigned Numbers Autority). Dříve ji publikoval pravidelně (jednou za rok, později každých 6 měsíců) ve formě dokumentu RFC. Dnes je tato konvence zveřejňována již průběžně, na WWW stránkách IANA. Konkrétně na adrese http://www.iana.org/assignments/port-numbers. Malou část této konvence vidíte v následující tabulce.

---