UDP

Protokol UDP (User Datagram Protocol) je určený pro aplikační protokoly a procesy, které požadují rychlý a nezabezpečený přenos paketů bez potvrzování příjmu a opakování přenosu (datagramová služba).

Protokol se přenáší v datové části IP paketů.Protokol obsahuje mechanismus adresování kocových procesů, aby mohl vykonávat multiplex a demultiplex dat mezi koncovými procesy a sítí.

Na adresaci aplikačních procesů se používají celočíselné identifikátory (aplikační porty - socket) přidělené aplikacím před vlastní komunikací. Kombinace IP adresy s adresou aplikačního prortu tvoří úplný identifikátor koncového procesu v IP síti a nazývá se soketová adresa (IP-port). Rozlišujeme rezervované porty (well-know) s čísly, které jsou staticky přidělené konktrétním službám (serverům) do hodnoty 1023 a dynamické, podle potřeby přidělované klienstkým částím aplikací.

 

TCP

Protokol TCP (Transport Control Protocol) pracuje podle modelu OSI v transportní vrstvě. Hlavní funkcí protokolu je vytváření, udržování a rušení transportních spojení, prostřednictvím kterých komunikují aplikační procesy v koncových uzlech intersítě IP. Pro protokol TCp jsou charakteristické následující vlastnosti:

  1. poskytování spolehlivé spojové tranpsortní služby koncovým procesům
  2. multiplexní režim práce pro koncové procesy uzlů sítě (několik procesů současně)
  3. duplexní režim přenosu údajů mezi kocovými prcesy (piggybacking)
  4. služba přenosu dat v podobě proudu přenášených bytů, stream segmentů protokolu TCP
  5. potvrzování přenosu dat (ACK) a opakování přenosu segmentů
  6. adaptivní režim přizpůsobení parametrů protokolu podle stavu spojení
  7. řízení toku systémem klouzavého okna (Sliding window) a pomocí příjimacích a vysílacíh bufferů.

Porty důležitých protokolů:

Protokol TCP při zabezpečování jmenovaných služeb vykonává následující funkce:

  1. adresování aplikačních procesů v síti
  2. vytváření a rušení transportních spojení
  3. příjem údajů z vyšší vrstvy (z aplikačního procesu), vytváření paketů TCP
  4. řízení přenosu TCP paketů mezi koncovými uzly v síti

Adresování aplikačních precesů v síti:

Na adresování aplikačních procesů se používají, podobně jako na adresování v protokolu UDP, celočíselné identifikátory, tzv. aplikační porty (sekety). Ale protokol TCP používá vlastní systém přidělování čísel soketů komunikujícím aplikacím, takže čísla soketů UDP a TCP jsou vzájemně nezávislé. Podle číselného rozsahu rozdělujeme sokety TCP na:

  1. veřejné sokety (well-known) < 1023
  2. dynamické sokety > 1023

Veřejně známé sokety jsou vyhrazeny pro servery konkrétních aplikačních služeb, zatímco dynamické jsou klienty aplikačních protokolů a procesů používané neomezeně. Podobně jako u UDP je kombinace IP adresy s adresou soketu v rámci transportného spojení TCP úplným identifikátorem komunikujích procesů.

Vytváření a rušení transportních spojení:

Protokol TCP je spojevě orientovaný. Transportní spojení je definováno jako dvojice soketových adres (IPc,portc), (IPz,portz) komunikujích koncových procesů. Aplikace si potom vyměňují data prostřednictvím vytvořeného spojení formou proudu bytů.

Na vytvoření transportního spojení se používá koncepce Klient-server. Aplikační procesy odevzdají vrstvě TCP potřebné údaje pro vytvoření spojení napr. číslo zdrojového a cílového aplikačniho portu. Při vytváření spojení rozlišujeme dva režimy otevření:

  1. Pasivní režim - příjímá na veřejně známém aplikačním portě volání klientů, kteří požadují vytvoření transportního spojení se serverem.
  2. Aktivní režim - je aktivován klienty, kteří vysílají požadavky na aplikační port serveru, otevřený v pasivním režimu

Při vytváření TCP spojení se vykonává synchronizační procedura označovaná Three - Way Handshake (SYN, SYN/ACK, ACK), během které si vymění a potvrdí obě strany startovací sekvenční čísla SN (x,y), pak používané na zabezpečení přenosu transportním spojením. Takety TCP mají v poli řízení spojení nastavené bity SYN a ACK, které druhé straně signalizují žádost o vytvoření spojení. Procedura je dostatečně robustní a odolná proti výpadkům spojení a duplicitám sekvenčních čísel.  K rušení transportního spojení dochází po ukončení přenosu dat z podnětu libovolného procesu ve spojení. Při rušení spojení TCP uzel, rušící spojení, vyšle zprávu s nastaveným bitem FIN řídícího poel, které informuje druhý proces ve spojení o ukončení přenosu dat, které ještě nepřenesl transportním spojením a až po dokončení přenosu potvrdí ukončení spojení zprávou FIN.

Řízení přenosu dat:

Po zřízení transportního spojení vytváří TCP pro aplikační procesy virtuální kanál, kterým si procesy vyměňují data plně duplexním způsobem. Z hlediska aplikace se vytvořené spojení jeví jako přenos proudu (Stream) bytů. Transportní protokol musí umožnit zabezpečený přenos proudu bytů, což znamená, že přenášená data musí být přesené ve správném pořadí a nesmí dojít k jejich ztrátě nebo zahlcení příjimače. Protokol TCP zabezpečuje řízení přenosu následovně:

  1. Data aplikačního procesu jsou ukládána do vysílací paměti (Output Buffer), z které jich TCP odebírá postupně po segmentech, které se doplňují o hlavičku řídících údajů do TCP paketu.
  2. Integrita přenosu se zabezpečuje číslováním přenášených bytů proudu prostřednictvím sekvenčních čísel SN, které udávají pořadové číslo prvního bytu v segmentu.
  3. Příjimací strana potvrzuje příjem segmetnu pozitivním potvrzením ACK prostřednictvím sekvenčního čísla nejbližšího očekávaného bytu v segmentu AN.
  4. Aby nedošlo k zahlcení příjimače vyčerpáním příjimacího bufferu, příjimací strana odesílá při potvrzení příjmu vysílací straně informaci o dostupné velikosti bufferu, tzv. příjimacího okna W, čímž se ovlivní velikost odesílancýh segmentů (Sliding window).
  5. Výpadek, poškození nebo ztráta segmentu při přenosu se ošetří opakováním přenosu segmentu. Po vypršení časového intervalu T na příjem potvrzení segmentu (Retransmission Timeout) od příjimací strany, musí vysílač znovu zopakovat přeos ztraceného segmentu.

Hodnota čsového intervalu T na příjem potvrzení se mění dynamicky podle aktuálního stavu sítě adaptivním výpočtem (Karn-Jacobsonův algoritmus) na základě předpokládaného zpoždění SRTT (Smoothed Round Trip Time) a předpokládané průměrné odchylky od skutečného zpoždění SDEV (Smoothed Deviation).