RM2p2 (06/19)

2. Prijenosni sloj mreže

U ovom poglavlju iznosimo prikaz prijenosnog (transportnog) sloja računalne mreže. Protokoli toga sloja pružaju usluge prijenosa protokolima aplikacijskog sloja (iznad sebe); pritom svoje usluge ostvaruju koristeći usluge protokola mrežnog sloja (ispod sebe). Ovdje govorimo o funkcijama protokola transportne razine i o načelima njihovog rada; pritom iznosimo opise protokola UDP i TCP, koji zajedno sa protokolom mrežne razine IP, čine središnji dio računalne mreže Internet.

Protokol UDP odlikuje se jednostavnošću i brzinom prijenosa; pogodan je za one aplikacije kod kojih je brzina prijenosa važnija od potpune ispravnosti prijenosa sadržaja. Protokol TCP je znatno složeniji i pruža usluge pouzdanog prijenosa sadržaja (bez grešaka) koristeći nepouzdane usluge prijenosa sa mrežne (IP) razine računalne mreže.

Protokol TCP ujedno upravlja intenzitetom slanja sadržaja na temelju trenutnih mogućnosti primatelja tih sadržaja i trenutnih mogućnosti usmjerivača koji te sadržaje prenose do primatelja. U prikazu TCP protokola dan je opis metoda i načina upravljanja intenzitetom slanja; ciljevi takvog upravljanja su (1) prilagoditi intenzitet slanja mogućnostima primatelja, (2) zaštititi usmjerivače od zagušenja, i (3) dosegnuti optimalnu iskorištenost trenutnih prijenosnih mogućnosti mreže.

1

2.1 Funkcije i svojstva prijenosnog sloja

Prijenosnim slojem računalne mreže nazvali smo ono što se naziva "transport layer" (transportni sloj, ili sloj transporta). Prikladniji naziv za taj sloj bio bi sloj upravljanja prijenosom, ali usvojen je naziv "prijenosni" ili "transportni" sloj, pa ćemo taj naziv uglavnom koristiti i ovdje.

Sloj veze podataka (Data Link) izvodi prijenos između dvaju čvorova koji su međusobno izravno povezani; za prijenos na toj razini kažemo da je tipa točka-točka (point-to-point) jer radi se o prijenosu sadržaja (u okvirima) između mrežnih kartica dvaju računala, pri čemu su te kartice međusobno povezane izravnom vezom (žicom ili drukčije).

Mrežna razina računalne mreže vodi (usmjerava) prijenos između izvora i konačnog odredišta sadržaja kojeg prenosi; dakle, između završnih čvorova jedne komunikacije. Na temelju IP adrese konačnog odredišta (koja je zapisana u zaglavlju IP paketa) i tablice prosljeđivanja (na svakom usmjerivaču), mrežna razina na svakom usmjerivaču određuje na koji slijedeći (susjedni) čvor treba prenijeti IP paket da bi se kretao (optimalnim putem) prema svom odredištu. Mrežna razina onda predaje IP paket razini veze podataka, koja ga prenosi na zadani susjedni čvor. Dakle, mrežna razina "nalazi put" između međusobno udaljenih domaćina i tako vodi prijenos sadržaja (u paketima) između tih dvaju domaćina. Taj prijenos se fizički ostvaruje kao niz prijenosa tipa točka-točka, na razini veze podataka.

Protokoli transportne razine ostvaruju prijenos podataka između procesa koji se izvode na međusobno udaljenim čvorovima; ti procesi su obično klijentska i serverska strana neke mrežne aplikacije, kao što su web sustav, sustav računalne pošte, i druge. Dakle, pored prijenosa sadržaja između dvaju računala (završnih čvorova mreže), potrebno je uspostaviti i održavati komunikaciju (i prijenos sadržaja) između konkretnih procesa na tim računalima. Osnovni zadatak protokola transportne razine je da uspostavljaju i održavaju takvu komunikaciju (prijenos sadržaja) između odgovarajućih klijentskih i serverskih procesa aplikacijske razine. Dakle, protokoli transportne razine "vode" sadržaje jedan korak dalje od onog do kuda su te sadržaje doveli protokoli mrežne razine. Za protokole transportne razine kažemo da su tipa s-kraja-na-kraj, ili kraće, tipa kraj-kraj (end-to-end) protokoli, jer ostvaruju komunikaciju između procesa koji se izvode na završnim (krajnjim) čvorovima mreže. Protokoli nižih razina nisu toga tipa: mrežna razina određuje slijedeći čvor na putu, a razina veze podataka izvodi prijenos do tog čvora.

Protokoli transportnog sloja obavljaju i druge funkcije, kao što su upravljanje intenzitetom prijenosa, odnosno intenzitetom opterećivanja konačnog primatelja sadržaja i usmjerivača na putu prijenosa, o čemu govorimo u kasnijim odjeljcima ovog poglavlja.

Dakle, entiteti mrežne razine računalne mreže ostvaruju prijenos sadržaja između dvaju međusobno udaljenih domaćina. Entiteti transportne razine nastavljaju taj prijenos na taj način što prenose sadržaje između dvaju procesa, obično aplikacijske razine, koji se odvijaju na međusobno udaljenim završnim čvorovima mreže (domaćinima). Ovdje govorimo o entitetima (protokolima) transportne razine mreže Internet, uglavnom o protokolima UDP (User Datagram Protocol) i TCP (Transmission Control Protocol). Ta dva protokola transportne razine mreže Internet imaju različita svojstva.

Protokol UDP je jednostavan i omogućava veće brzine prijenosa; taj protokol otkriva neke greške koje nastaju u prijenosu, ali ih ne otklanja; zato se za UDP kaže da je nepouzdan protokol transportne razine. Protokol TCP je složeniji; taj protokol otkriva greške u prijenosu i ispravlja te greške; zato se za protokol TCP kaže da je pouzdan protokol transportne razine. TCP otklanja greške u prijenosu na taj način što ponavlja prijenos onih sadržaja (segmenata) za koje je utvrdio da su iskrivljeni ili izgubljeni u procesu prijenosa.

Otkrivanje grešaka i njihovo ispravljanje čini prijenos podataka kod TCP protokola sporijim u odnosu na prijenos kod UDP protokola. Kod nekih aplikacija bitna je brzina prijenosa, dok je

2

kod drugih aplikacija neophodna točnost prijenosa sadržaja. Zato su razvijena dva protokola na transportnoj razini mreže Internet.

Za TCP protokol kažemo da ostvaruje pouzdan prijenos koristeći usluge nepouzdanog prijenosa (ili nepouzdane usluge prijenosa) koje mu pruža mrežni sloj računalne mreže. Na mrežnoj razini (sloju) Interneta radi protokol IP; za taj protokol se kaže da radi po načelu "najbolje što može" (best effort). IP protokol omogućava da usmjerivači prosljeđuju IP paket prema njegovom odredištu, ali taj protokol ne ispravlja eventualne greške u prijenosu, kao što su iskrivljenja i gubici IP paketa. Neki protokoli razine veze podataka (ispod mrežne razine) otkrivaju i ispravljaju greške koje nastaju u prijenosu okvira između izravno povezanih čvorova, dok drugi protokoli te razine to ne rade. Ali otkrivanje i ispravljanje grešaka na razini veze podataka nije dovoljno, jer greške mogu nastati i na usmjerivačima. Zato je glavni (i odgovorni) otkrivač i ispravljač grešaka u prijenosu protokol transportne razine, koji upravlja prijenosom između dvaju aplikacijskih procesa koji se izvode na međusobno udaljenim završnim sustavima (domaćinima) koji (procesi) međusobno komuniciraju.

Kaže se da transportni sloj ostvaruje logičku komunikaciju između dvaju aplikacijskih procesa koji se izvode na međusobno udaljenim domaćinima. Komunikacija na transportnoj razini naziva se logičkom zato što protokoli te razine omogućuju aplikacijama (klijentima i serverima) da međusobno razmjenjuju poruke, bez da pritom vode računa o fizičkoj realizaciji prijenosa sadržaja između domaćina na kojima se izvode ti aplikacijski procesi. Na logičkoj razini komunikacije ne vide se usmjerivači, mrežne kartice i veze među njima, koji zajedno ostvaruju fizički prijenos sadržaja između komunikatora. Logička razina komunikacije, koju ostvaruju protokoli transportne razine, oslobađa aplikacije od potrebe da vode računa o fizičkim svojstvima mrežnih elemenata koji prenose njihove poruke od izvora do odredišta. Naravno, svojstva logičkih prijenosnih kanala, kao što su propusnost i vrijeme povratnog puta (RTT), bitno zavise od fizičkih svojstava (kapaciteta) mrežnih elemenata pomoću kojih se ti logički kanali ostvaruju. Dakle, od fizičkih elemenata i njihovih svojstava zavisi kakve logičke kanale mogu ostvariti (i ponuditi aplikacijama) protokoli transportne razine, ali ta fizička svojstva mrežnih elemenata nisu predmet bavljenja entiteta aplikacijske razine. Entiteti aplikacijske razine promatraju mrežu kao sredstvo koje nudi prijenosne kanale određenih svojstava, ne zalazeći u to na koji način su ta svojstva fizički realizirana.

Protokoli transportne razine rade na završnim čvorovima mreže, kao i aplikacije kojima pružaju usluge prijenosa. Na strani pošiljatelja, transportni protokol preuzima sadržaje (poruke) koje proizvodi aplikacija koja koristi njegove usluge prijenosa. Od tih sadržaja, transportni protokol tvori svoje segmente, koje onda predaje protokolu mrežne razine ispod sebe. Mrežna razina umeće te segmente u svoje pakete, koje onda predaje razini veze podataka, koja ih umeće u svoje okvire i izvodi fizički prijenos tih okvira do slijedećeg čvora na putu prema konačnom primatelju sadržaja koji se prenose u tim okvirima.

Poruke koje proizvode (šalju) aplikacije mogu biti velike (cijele datoteke), dok je veličina segmenata praktički određena (ograničena) veličinom okvira (na razini veze podataka), jer segmenti se prenose u paketima (mrežna razina), a paketi se prenose u okvirima. To znači da protokoli transportnog sloja dijele velike poruke u niz manjih segmenata, koji se onda prenose na njihovo odredište.

Usmjerivači rade na mrežnoj razini prijenosa. Oni određuju putove (taj proces naziva se usmjeravanjem) i izvode prosljeđivanje IP paketa na temelju IP adresa iz zaglavlja IP paketa koje prenose. Usmjerivači ne gledaju sadržaje zaglavlja UDP i TCP segmenata koje prenose IP paketi. Dakle, usmjerivači prenose IP pakete na završne čvorove (domaćine) na koje su upućeni, ali ne gledaju kojim procesima na tim domaćinima su upućeni sadržaji tih paketa.

Na odredišnom domaćinu, mrežna razina (IP protokol) prihvaća IP pakete, "izvlači" iz njih

3

segmente i te segmente predaje odgovarajućem protokolu transportne razine. Taj protokol procesira primljene segmente (na način na koji taj protokol to radi) i predaje njihove sadržaje onom procesu aplikacijske razine kojem su upućeni. O tome na koji način protokoli transporte razine (UDP i TCP) procesiraju segmente, govorimo u nastavku ovog poglavlja.

Dakle, transportna razina uspostavlja prijenosne kanale između procesa aplikacijske razine. Mrežna razina nalazi put od domaćina-izvora do domaćina-odredišta i u svojim paketima prenosi segmente transportne razine. Razina veze podataka izvodi prijenos paketa (u svojim okvirima) između čvorova koji su izravno međusobno povezani; od niza takvih "dionica" sastoje se put i prijenos od izvora do odredišta. Svi navedeni procesi izvode se na fizičkim napravama (sustavima) koje izvode prijenos fizičkih signala. Na taj način nastaje petoslojni model računalne mreže koji je prikazan na slici 1.3. Time smo ujedno opisali položaj i ulogu protokola transportnog sloja u tom sustavu.

Protokoli (softver) transportne razine rade na završnim čvorovima mreže (na domaćinima); ti protokoli ne rade na čvorovima (usmjerivačima) koji tvore unutrašnjost ili prijenosni sustav mreže. Usmjerivači općenito ne promatraju zaglavlja segmenata, koje protokoli transportne razine (na završnim čvorovima) dodaju sadržajima koje preuzimaju od aplikacijske razine. Usmjerivači promatraju upravljačke sadržaje mrežne razine, to jest, sadržaje zaglavlja IP paketa; ti sadržaji, prvenstveno IP adresa odredišta paketa, dovoljni su za prosljeđivanje tih paketa prema njihovom odredištu. Segment sa transportne razine je tijelo (koristan teret; payload) IP paketa; usmjerivači općenito ne promatraju sadržaje tijela IP paketa koje prosljeđuju.

Neka svojstva logičkih komunikacijskih kanala koje ostvaruje transportna razina, određena su fizičkim svojstvima (mogućnostima) entiteta na nižim razinama mreže; takva svojstva su propusnost fizičkih veza i zadržavanje na putu između dvaju završnih čvorova mreže. Ali neki protokoli transportne razine ostvaruju neka svojstva logičkih kanala, kakva prijenos na nižim slojevima mreže sam po sebi nema. Jedno važno svojstvo takve vrste je pouzdanost prijenosa. Pojmom pouzdanost ovdje se označava zajamčenu ispravnost prijenosa sadržaja. Dakle, neki protokol transportne razine može ostvariti logički kanal koji izvodi pouzdan prijenos sadržaja, koristeći usluge mrežnog sloja (ispod sebe), čiji prijenos nije pouzdan.

Sadržaji (paketi) koje se prenosi mogu biti iskrivljeni ili izgubljeni u procesu prijenosa; sadržaji mogu stići na odredište u krivom redoslijedu, što onda dovodi do pogrešne reprodukcije izvorne poruke na prijemnoj aplikaciji. Prijenosni sustav (ili protokol) nazivamo nepouzdanim ako ne ispravlja takve greške u prijenosu. IP protokol na mrežnoj razini Interneta je takav nepouzdan protokol. To ne znači da takav protokol "radi loše", nego samo da ne ispravlja greške, ako/kad se dogode u domeni njegovog rada.

Pouzdanost prijenosa pomoću nepouzdanih sredstava može se ostvariti na više načina, ali uvijek je potrebno definirati dvije osnovne stvari: (1) sredstva i postupke koji otkrivaju greške u prijenosu, i (2) način ispravljanja otkrivenih grešaka. Greške se otkrivaju na temelju kontrolnih zapisa (koji se dodaju sadržajima); greške se obično ispravljaju ponavljanjem slanja onih sadržaja (paketa) koji su iskrivljeni ili izgubljeni putem. Slanje se ponavlja sve dok se sadržaji ne prenesu na odredište u ispravnom stanju. Ovdje se ne ponavlja slanje cijelih (velikih) datoteka, nego samo onih dijelova (segmenata) koji su iskrivljeni ili izgubljeni u prijenosu, a takvih je obično vrlo malo.

U transportni sloj smještaju se i neki sustavi koji obavljaju poslove (1) zaštite povjerljivosti sadržaja (šifriranjem) koji se prenose mrežom, (2) zaštite integriteta poruke (od zlonamjernog mijenjanja njenog sadržaja), i (3) utvrđivanja autentičnosti (identiteta) komunikatora. Ali ti poslovi su specifični i bitno se razlikuju od osnovnih poslova transportnog sloja, koje smo opisali iznad. Protokole i sustave koji obavljaju poslove zaštite i sigurnosti mrežne komunikacije moglo bi se jednako smjestiti na razinu aplikacija, ili na jednu zasebnu "među-razinu" između aplikacijske i transportne razine.

4

Internet sadrži dva protokola transportne razine, koji pružaju usluge prijenosa mrežnim sustavima aplikacijske razine. Jedan od tih protokola je UDP (User Datagram Protocol), a drugi je TCP (Transmission Control Protocol).

UDP pruža aplikacijama nepouzdane (unreliable) usluge prijenosa, bez uspostavljanja postojane veze među komunikatorima. U engleskom se drugo svojstvo naziva "connectionless"; ovdje ćemo to svojstvo označiti kraćim nazivom nevezne (usluge prijenosa).

TCP pruža aplikacijama pouzdane (reliable) usluge prijenosa, uz prethodno uspostavljanje postojane veze među komunikatorima. U engleskom se drugo svojstvo naziva "connection oriented"; ovdje ćemo to svojstvo označiti kraćim nazivom vezne (usluge prijenosa).

Pojmovi "nevezne" i "vezne" usluge prijenosa ne zvuče naročito dobro, ali relativno dobro odražavaju stanje stvari koje označavaju; inače, nastavak "less" redovito pravi teškoće, a pojam "oriented" je redovito neprecizan.

Za prijenos nekih vrsta sadržaja (i za aplikacija koje ga prenose) prikladniji je UDP protokol jer je jednostavniji i omogućava veće brzine prijenosa. Za druge vrste sadržaja (i aplikacija) neophodna je pouzdanost prijenosa, to jest, stalna (sigurna) točnost prenijetih sadržaja; zato te aplikacije koriste TCP protokol. Proizvođač aplikacije bira koji će protokol transportne razine koristiti njegova aplikacija. Taj izbor vrši se kod pisanja softverskog sučelja koje definira (i izvodi) proces razmjene sadržaja između entiteta (protokola) aplikacijske razine i transportne razine. Ta sučelja nazivaju se utičnicama (sockets). Riječ "socket" znači "utičnica", a riječ "plug" znači "utikač"; ali kao i obično, u engleskom jeziku riječi imaju više značenja, a različite riječi mogu imati ista značenja.

Utičnica je poput vratiju između jednog aplikacijskog procesa i jednog protokola (TCP ili UDP) sa transportne razine. Onaj tko piše aplikaciju (softver), piše i utičnicu prema odabranom entitetu transportne razine. Kod oblikovanja utičnice, sa aplikacijske razine mogu se postaviti (zadati) neki osnovni parametri TCP veze sa kojom ta utičnica povezuje danu aplikaciju. Takvi parametri su veličina memorijskog prostora (bafera) te veze; to je onaj memorijski prostor u kojeg aplikacija upisuje sadržaje koji trebaju biti prenijeti danom vezom, odnosno prostor iz kojeg aplikacija čita (preuzima) sadržaje koji su stigli (prenijeti) danom vezom u tu utičnicu. Takav parametar je i veličina segmenata (kao jedinica podataka) koje dani entitet transportne razine prenosi između komunikatora. Biranje veličina takvih parametara je ono što mogu činiti oni koji izrađuju neku mrežnu aplikaciju i njene utičnice; dalje od toga spada u transportni sustav i nije u dosegu onih koji izrađuju mrežne aplikacije.

Na mrežnoj razini Interneta radi Internet Protocol (IP). Za taj protokol rekli smo da radi po načelu "najbolje što može" (best effort; "ulaganje maksimalnog napora"). To znači da IP protokol (softver) nastoji prenijeti sadržaje (u IP paketima) sa izvora na odredište, ali ne ispravlja greške koje nastaju u tom prijenosu. Zato se kaže da IP protokol (i mrežna razina prijenosa) pruža uslugu nepouzdanog prijenosa, ili nepouzdanu uslugu prijenosa. Pored usluge vođenja prijenosa od domaćina-izvora do domaćina-odredišta, IP protokol definira sustav jedinstvenog adresiranja čvorova mreže na mrežnoj (IP) razini. U tom sustavu adresiranja svaki čvor mreže Internet ima jedinstvenu IP adresu koja ga jednoznačno identificira u toj globalnoj mreži. Postoje sustavi koji omogućuju da više domaćina naizmjenično u jednoj mreži koristi istu IP adresu, ali to ovdje nije važno; takav je sustav NAT (Network Address Translation) kojeg smo spomenuli u predmetu "Računalne mreže 1" (odjeljak 4.7).

IP adresa je logička oznaka čvora; fizičkom adresom čvora može se zvati fizička adresa mrežne kartice preko koje je taj čvor vezan u mrežu. Mrežna kartica i njena adresa spadaju na razinu veze podataka, na kojoj se izvode konkretni prijenosi sadržaja - ili točnije, prijenosi signala koji predstavljaju i prenose sadržaje. Logičnost IP adrese odražava se u tome što se neku IP adresu može dodijeliti bilo kojem čvoru; fizička adresa je hardverski zapisana u mrežnoj kartici i ne može se odvojiti od te kartice (ali se karticu može prenijeti na drugi čvor).

5

Protokol mrežne razine vodi prijenos sadržaja između dvaju završnih čvorova (domaćina) mreže. Protokoli transportne razine koriste uslugu prijenosa sa mrežne razine i na temelju učinaka te usluge ostvaruju prijenos sadržaja između aplikacijskih procesa koji se izvode na međusobno udaljenim čvorovima. Pritom, protokol TCP ostvaruje pouzdan prijenos među aplikacijskim procesima na temelju nepouzdanog prijenosa među mrežnim čvorovima (domaćinima) kojeg izvodi mrežna razina.

Protokol TCP ujedno vodi računa o optimalnom intenzitetu prijenosa sadržaja između aplikacijskih procesa koji međusobno komuniciraju. Kontrolom intenziteta prijenosa štiti se primatelja od toga da mu pošiljatelj šalje sadržaje (IP pakete) brže nego što ih primatelj može prihvaćati; time se ujedno štiti pošiljatelja od toga da mora ponovno slati one poslane sadržaje (pakete) koje primatelj nije uspio prihvatiti.

Protokol TCP isto tako omogućava upravljanje intenzitetom prometa u mreži; cilj takvog upravljanja intenzitetom je da se spriječi zagušenje usmjerivača. Pitanje optimalnog intenziteta prijenosa između dvaju aplikacijskih procesa važno je za te procese. Sprječavanje zagušenja usmjerivača važno je za računalnu mrežu u cjelini, jer zagušenje usmjerivača ugrožava sve prijenose, odnosno rad računalne mreže u cjelini - ili barem onog dijela mreže u kojem je došlo do zagušenja.

Zagušenje usmjerivača sprječava se na taj način da se ograniči intenzitet slanja svakog izvora na onu mjeru koju usmjerivači mogu prenositi. Protokol TCP sadrži mogućnost upravljanja intenzitetom prijenosa (među procesima) i sprječavanja zagušenja usmjerivača. S druge strane, protokol UDP (koji teži jednostavnosti i brzini), ne vodi računa o pitanjima intenziteta slanja i zagušenja. Postoje prijedlozi da se taj protokol modificira na način da vodi računa o tim stvarima. Jer u suprotnom, oni prijenosi koje izvodi protokol UDP troše kapacitete usmjerivača bez ikakvih ograničenja, i time dovode u nepovoljan položaj one prijenose koje izvodi TCP protokol. Ako TCP štiti usmjerivače od zagušenja na taj način što smanjuje intenzitet svojih prijenosa, a UDP to ne čini, onda se ta zaštita svodi na usporavanje TCP prijenosa, dok prijenosi koje izvodi UDP ne obraćaju pažnju ni na što. O tim stvarima govorimo u odjeljcima u 5 i 6 ovog poglavlja.

Multipleksiranje i demultipleksiranje

Na odredišnom domaćinu transportni sloj prima segmente od mrežnog sloja ispod sebe. Osnovni posao transportnog sloja je da sadržaje tih segmenata predaje onim procesima aplikacijske razine kojima su ti sadržaji namijenjeni. Protokol transportne razine predaje sadržaj aplikaciji na taj način da taj sadržaj upisuje u utičnicu te aplikacije: dakle, u utičnicu koja tu aplikaciju povezuje sa tim protokolom transportne razine koji izvodi prijenos za tu aplikaciju. Utičnica nalikuje vratima kroz koja aplikacija predaje svoje sadržaje odabranom protokolu transportne razine, i kroz koja taj protokol transportne razine predaje aplikaciji sadržaje koje prima za nju. Predavanje i preuzimanje sadržaja se općenito izvodi na taj način da jedna strana upisuje sadržaje u neki memorijski prostor, a druga strana čita sadržaje iz tog memorijskog prostora (i briše pročitano).

Kod pisanja aplikacije, piše se i utičnicu za tu aplikaciju; kod pisanja utičnice određuje se sa kojim protokolom transportne razine ta utičnica spaja tu aplikaciju; tada se utičnici dodjeljuje i jednu numeričku oznaku koja se naziva portom (port). Ta oznaka, zajedno sa IP adresom domaćina na kojem ta aplikacija radi, tvori jedinstvenu oznaku jedne utičnice u računalnoj mreži.

Protokol transportnog sloja preuzima sadržaje iz utičnica raznih aplikacija (za koje radi), umeće te sadržaje u svoje segmente i predaje te segmente mrežnom sloju ispod sebe radi daljnjeg prijenosa do njihovog odredišta. "Umetati sadržaje u segmente" znači dodavati tim sadržajima zaglavlja kakva dodaje dani protokol transportne razine. Različiti protokoli koriste različita zaglavlja, ali ta zaglavlja uvijek sadrže broj porta (utičnice) sa kojeg su sadržaji preuzeti (na izvoru) i broj porta (utičnice) kojem su ti sadržaji upućeni (na odredištu). Taj proces preuzimanja sadržaja iz utičnica i tvorbe segmenata, naziva se multipleksiranjem (multiplexing).

6

Kad mrežni sloj preda segment (iz primljenog IP paketa) protokolu transportne razine iznad sebe, onda taj protokol upisuje sadržaj (tijelo) tog segmenta u onu utičnicu (na tom domaćinu) čiji je broj (port) zapisan u zaglavlju primljenog segmenta. Taj proces predavanja sadržaja iz primljenih segmenata u zadane utičnice (od aplikacija) naziva se demultipleksiranjem (demultiplexing).

Dakle, multipleksiranje je ovdje proces koji obuhvaća: (1) čitanje sadržaja iz utičnica, (2) tvorbu segmenata dodavanjem zaglavlja transportne razine (koje sadrži broj porta pošiljatelja i broj porta primatelja), i (3) predavanje tako formiranog segmenta mrežnom sloju za daljnje "pakiranje" i prijenos. Demultipleksiranje je proces koji obuhvaća: (1) preuzimanje segmenata od protokola mrežne razine, (2) čitanje sadržaja zaglavlja segmenta u kojem su dani brojevi portova pošiljatelja i primatelja, i (3) upisivanje sadržaja iz primljenog segmenta u onu utičnicu čiji je broj (port) zadan u zaglavlju segmenta. Slika 2.1 ilustrira procese multipleksiranja i demultipleksiranja, koje smo opisali iznad.

Slika 2.1 Multipleksiranje i demultipleksiranje

Transportni protokol na domaćinu D2 demultipleksira sadržaje koje prima (u segmentima), na taj način da te sadržaje upisuje u zadane utičnice (portove) od aplikacije A1 ili od aplikacije A2. Demultipleksiranje se izvodi na temelju broja porta (utičnice) koji je zapisan u zaglavlju segmenta.

Transportni protokol multipleksira sadržaje (koji idu sa D2) na taj način da čita te sadržaje iz raznih utičnica aplikacija, tvori iz njih segmente i predaje te segmente mrežnom sloju, kako je to opisano iznad. Strelice na slici 2.1 pokazuju u oba smjera jer aplikacije sa D2 mogu slati sadržaje (odgovore) aplikacijama sa D1 i D3.

Slika 2.2 prikazuje osnovnu strukturu segmenta, kao jedinice podataka transportne razine.

7

Slika 2.2 Osnovna struktura segmenta

Sadržaj (tijelo) segmenta je poruka (ili dio veće poruke) koju je proizvela neka aplikacija. Zaglavlje segmenta sadrži broj utičnice na domaćinu-izvoru, iz koje dolazi dani sadržaj, i broj utičnice na domaćinu-odredištu, u koju treba upisati taj sadržaj. Prvi broj utičnice naziva se portom izvora (source port), a drugi broj utičnice naziva se portom odredišta (destination port). Zaglavlje segmenta može imati i niz drugih polja, čiji sadržaji služe raznim upravljačkim procesima, kao što su provjeravanje ispravnosti prijenosa, sprječavanje zatrpavanja domaćina-primatelja i sprječavanje zagušenja usmjerivača na putu između pošiljatelja i primatelja. U nastavku ovog poglavlja iznosimo strukture zaglavlja segmenata kod UDP protokola i kod TCP protokola.

Da bi poruka koju neka aplikacija upisuje u svoju utičnicu stigla u utičnicu neke aplikacije na nekom udaljenom domaćinu, pored broja utičnice (porta) te prijemne aplikacije potrebna je i IP adresa domaćina na kojem se nalazi prijemna aplikacija. Nalaženje domaćina (za danu IP adresu) i dostava sadržaja na tog domaćina je posao mrežne razine računale mreže. Posao transportnog sloja je da preuzima sadržaje iz utičnica aplikacija i da upisuje sadržaje u te utičnice. Taj posao izvodi se na završnim čvorovima mreže, na kojima rade protokoli transportne razine.

Broj porta zapisuje se u 16-bitno polje zaglavlja segmenta, što znači da portovi mogu imati dekadske vrijednosti od 0 do 65535 (to jest, do 216-1); to je raspon mogućih vrijednosti (brojeva) portova na transportnoj razini. Proizvođač mrežne aplikacije može dodijeliti utičnici te aplikacije onaj broj (port) kojeg želi, ali neke brojeve su već zauzele druge aplikacije. Pored toga, svi brojevi portova od 0 do 1023 rezervirani su za najpoznatije i najkorištenije aplikacije: ti brojevi nazivaju se dobro poznatim brojevima portova tih aplikacija. To su pristupni portovi dobro poznatih aplikacija, koje mogu koristiti i druge portove u pojedinačnim komunikacijama, o čemu govorimo u slijedećem poglavlju. Naprimjer, dobro poznat port vrlo korištenog aplikacijskog protokola HTTP je 80; dobro poznat port protokola (i sustava) FTP je 21. Lista poznatih aplikacija i njihovih dobro poznatih portova dana je u RFC 1700 i u RFC 3232, a može se vidjeti i na adresi http://www.ina.org.

Dakle, kod pisanja aplikacije, valja napisati i utičnicu koja tu aplikaciju povezuje sa odabranim protokolom transportnog sloja; tada se toj utičnici dodjeljuje neki slobodan broj iz zadanog raspona, kao oznaku; taj broj onda postaje portom te aplikacije. Na temelju portova (iz zaglavlja segmenata), protokoli transportne razine znaju u koje utičnice trebaju upisati sadržaje segmenata koje primaju sa mrežne razine, kako je to opisano iznad.

Na temelju IP adrese odredišta, IP protokol (mrežna razina) prenosi IP paket sa domaćina-izvora na domaćina-odredište. U IP paketu prenosi se segment, kojeg IP protokol predaje protokolu

8

transportne razine; na temelju porta odredišta (koji je zapisan u zaglavlju segmenta), protokol transportne razine upisuje sadržaj iz segmenta u utičnicu (port) odgovarajuće aplikacije.

Dakle, svaka konkretna utičnica jednoznačno je određena (adresirana) sa parom kojeg tvore (1) IP adresa domaćina na kojem se nalazi ta utičnica, i (2) sa svojom numeričkom oznakom (portom). U osnovnoj strukturi zaglavlja segmenta na slici 2.2 navedeni su port pošiljatelja i port primatelja. U zaglavlju IP paketa koji prenosi taj segment dane su IP adrese domaćina-izvora i domaćina-odredišta IP paketa. IP adresa domaćina-izvora i port pošiljatelja nisu neophodni za prijenos IP paketa do primatelja, ali ta IP adresa i taj port kazuju primatelju kamo treba poslati odgovor na sadržaj kojeg je primio. Naprimjer, kad web server primi neki zahtjev od nekog web preglednika, onda na temelju IP adrese izvora i porta pošiljatelja zahtjeva, zna kamo treba poslati odgovor na taj zahtjev. Kod tvorbe odgovora na neki upit, IP adresa pošiljatelja upita postaje IP adresa primatelja odgovora na taj upit, a port pošiljatelja upita postaje portom primatelja odgovora.

Klijent šalje prvi IP paket serveru, sa kojim traži uspostavu komunikacije; klijent to čini sa neke IP adrese IP(k) i sa nekog porta P(k), a vezu uspostavlja sa serverom na adresi IP(s) i to na poznatom portu toga servera P(s). Server prihvaća taj zahtjev za uspostavu komunikacije (i TCP veze) na svom poznatom portu, ali u postupku uspostavljanja TCP veze, server za svakog klijenta stvara novu utičnicu (kao novi objekt iste klase). Komunikacija sa svakim od klijenata odvija se zatim preko one utičnice (porta) koju je server kreirao za tog klijenta (na njegov poticaj). Na taj način server stalno oslobađa svoj dobro poznati port, tako da mu novi klijenti mogu na taj port slati svoje zahtjeve za uspostavu komunikacije.

Domaćin na kojem radi neki server, omogućava tvorbu i paralelan rad mnogo utičnica. Na taj način održavaju se TCP veze i dvosmjerna razmjena sadržaja između jednog servera i njegovih mnogo klijenata. Svaka od tih TCP veza određena (i uspostavljena) je sa svojom utičnicom na strani klijenta i sa svojom utičnicom na strani servera. Tako je svaka TCP veza definirana sa četvorkom parametara, koju čine IP adresa i port klijenta, te IP adresa i port servera.

9

Slika 2.3 Komunikacija između klijenata i servera

Slika 2.3 ilustrira ulogu portova, te poslove klijenata i servera u postupku uspostavljanja i održavanja međusobne komunikacije. Web klijent K1 (preglednik) pokrenuo je proces uspostave TCP veze sa web serverom S; svoj zahtjev za uspostavu veze uputio je na IP adresu domaćina na kojem radi S i na port 80 na tom domaćinu, kao dobro poznatom portu web servera. Istodobno, web klijent K2 pokrenuo je uspostavu dviju paralelnih TCP veza sa istim web serverom S na istom dobro poznatom portu toga servera (80). Klijent K2 je pokrenuo uspostavu tih dviju TCP veza sa dvaju svojih portova.

U postupku uspostavljanja tih triju veza, protokol TCP na domaćinu na kojem radi web server, upisuje sve tri zahtjeve za uspostavu veze u istu utičnicu: u dobro poznati port web servera (80). U postupku izvršenja tih zahtjeva i uspostavljanja traženih veza, server kreira po jednu

10

novu utičnicu za svaki od zahtjeva, odnosno za svaku od triju TCP veza koje se uspostavljaju.Dakle, svi početni zahtjevi klijenata imaju istu IP adresu odredišta i isti port odredišta; ti

zahtjevi razlikuju se po IP adresi izvora i/ili po portu izvora. U postupku uspostave traženih TCP veza, server svakoj od tih veza dodijeljuje zaseban broj porta na odredištu (serveru S).

Svaki zahtjev klijenta (naprimjer, web preglednika) za uspostavu TCP veze sa serverom pokreće jedan novi proces na serveru; u tom procesu stvara se na serveru jedna nova utičnica prema TCP protokolu; preko te utičnice uspostavlja se (nova) TCP veza sa klijentom koji je tražio njeno uspostavljanje i čiji je zahtjev pokrenuo dani proces kreiranja TCP utičnice (i veze) na serveru.

Preko te veze, klijent sad može slati konkretne zahtjeve serveru; TCP veza je dvosmjerna, tako da preko iste veze server šalje odgovore klijentu na njegove zahtjeve. TCP veza je obično persistentna, što znači da traje sve dok klijent ili server ne dadu zahtjev TCP protokolu da prekine tu vezu. Dakle, TCP veza se ne prekida nakon što server odgovori na prvi zahtjev klijenta, tako da klijent može slati nove zahtjeve serveru preko iste veze (i preko istih utičnica).

U načelu, svaki zahtjev klijenta za uspostavu TCP veze pokreće na serveru jedno novo izvođenje procesa stvaranja nove utičnice i uspostavljanja nove TCP veze. Kod novijih web servera odvija se samo jedan proces te vrste; umjesto mnoštva istovrsnih procesa, na tim serverima odvija se mnogo programskih niti koje ostvaruju iste učinke. Dakle, umjesto novih procesa, zahtjevi klijenata pokreću nove programske niti koje kreiraju nove utičnice i uspostavljaju nove TCP veze. Takve promjene spadaju u područje implementacije protokola, dok njegova suština ostaje ista. O svojstvima i radu TCP protokola govorimo u odjeljku 2.4.

2.2 Nepouzdan prijenos: protokol UDP

Osnovni posao transportnog sloja je da izvodi multipleksiranje i demultipleksiranje. To ovdje znači da protokol transportne razine preuzima poruke (sadržaje) koje proizvodi aplikacija, tvori iz njih svoje segmente i predaje ih mrežnom sloju, koji te segmente prenosi na odredišnog domaćina. Zaglavlja segmenata mogu sadržavati razne podatke koji služe za otkrivanje grešaka u prijenosu i za upravljanje prijenosom. Zaglavlje treba svakako sadržavati port primatelja sadržaja segmenta i port pošiljatelja sadržaja segmenta. Na temelju prvog podatka, transportni protokol na odredištu zna u koju utičnicu treba upisati sadržaj tog segmenta: to jest, kojoj aplikaciji treba predati sadržaj tog segmenta. Na temelju drugog podatka, primatelj sadržaja zna od kojeg procesa (klijenta) je stigao neki sadržaj, i kome treba poslati odgovor na primljeni zahtjev.

UDP (User Datagram Protocol) je jednostavan protokol čiji se posao uvelike svodi na izvođenje procesa multipleksiranja i demultipleksiranja, koje smo opisali ranije. Dakle, UDP preuzima sadržaje (poruke) od aplikacijskog procesa (preko utičnice), dodaje tim sadržajima svoje zaglavlje koje se sastoji od ukupno četiri polja, i time tvori svoj UDP segment. Zatim taj segment predaje IP protokolu sa mrežne razine, koji ga umeće u svoj paket (to jest, dodaje mu svoje zaglavlje) i prenosi ga na onog domaćina na kojem radi aplikacija kojoj je taj segment (sadržaj) upućen. Na slici 2.4 dana je struktura zaglavlja UDP segmenata.

11

Slika 2.4 Segment UDP protokola

Zaglavlje UDP segmenta sastoji se od svega četiri polja, koja su velika svako po dva bajta (16 bitova). Polje "Port izvora" sadrži port na domaćinu-izvoru poruke; sa tog porta (utičnice), UDP je preuzeo sadržaj kojeg prenosi u tijelu ovog segmenta. "Port odredišta" sadrži broj porta na domaćinu-odredištu, kojem UDP treba predati sadržaj danog segmenta. Port odredišta je broj utičnice u koju protokol UDP upisuje sadržaj iz tijela primljenog segmenta; time port određuje i proces kojem se predaje taj sadržaj u postupku demultipleksiranja. Dakle, na temelju para portova ostvaruje se prijenos sadržaja između aplikacijskih procesa na međusobno udaljenim domaćinima; prijenos sadržaja između tih domaćina izvodi IP protokol sa mrežne razine.

Polje "Kontrolni zapis" sadrži niz od 16 bitova, na osnovu kojeg protokol UDP na strani primatelja može utvrditi (s velikom vjerojatnošću) da li je sadržaj primljenog segmenta iskrivljen u procesu prijenosa. Kontrolni zapis izračunava pošiljatelj i zapisuje ga u dano polje zaglavlja segmenta. Načelno govoreći, primatelj segmenta izvodi jednak proces računanja na segmentu kojeg je primio; ako dobije rezultat jednak onome kojeg je poslao pošiljatelj (i zapisao ga u dano polje zaglavlja), onda je vrlo vjerojatno da taj segment nije iskrivljen u procesu prijenosa. Ako rezultat računanja na odredištu segmenta nije jednak sadržaju polja "Kontrolni zapis", onda je sigurno da je u procesu prijenosa došlo do iskrivljenja toga segmenta. Postoje razne metode (algoritmi) izračunavanja kontrolnih zapisa, ali ta tema nije predmet ovog prikaza. Kod UDP protokola, kontrolni zapis računa se na UDP segmentu (kao nizu bitova), kojem se dodaju IP adresa izvora i IP adresa odredišta, koje se inače zapisuju u zaglavlje IP paketa u kojem se taj segment prenosi mrežom. Dakle, protokol UDP definira zapise (i procedure) koji omogućuju otkrivanje iskrivljenja sadržaja u prijenosu njegovih segmenata, ali ne ispravlja greške koje otkriva.

U polju "Dužina" zapisana je ukupna dužina danog segmenta (zaglavlja i tijela) izražena u bajtovima.

Konačno, u tijelu segmenta zapisan je sadržaj (poruka) kojeg je proizvela neka aplikacija i kojeg se ovim segmentom prenosi na njegovo odredište.

UDP preuzima sadržaje (poruke) koje aplikacije upisuju u svoje utičnice prema UDP protokolu. Tim sadržajima dodaje UDP zaglavlje, i tako tvori UDP segmente. Te segmente predaje mrežnoj razini, na kojoj radi IP protokol; taj protokol smješta segmente u svoje IP pakete, koje onda prenosi na njihovo odredište. IP protokol na domaćinu-odredištu predaje protokolu UDP segmente koje je prenio na tog domaćina u IP paketima. Protokol UDP upisuje sadržaje iz primljenih segmenata u utičnice onih aplikacija čiji su portovi zapisani u polju za upis porta odredišta u zaglavljima primljenih segmenata. Time protokol UDP izvodi demultipleksiranje primljenih

12

segmenata na domaćinu-odredištu.UDP ne vrši pouzdan prijenos sadržaja; to ovdje znači da ne ispravlja greške (iskrivljenja i

gubitke sadržaja) koje nastaju u procesu prijenosa; takve greške obično nastaju na nižim razinama mrežnog sustava, ali mogu nastati na svim razinama; mogu nastati na vezama, na usmjerivačima, i na domaćinima. Protokol UDP ne vodi računa o intenzitetu slanja u pojedinim prijenosima koje izvodi, niti o opterećenju usmjerivača u dijelu mreže kroz kojeg se prenose njegovi segmenti. Ako pošiljatelj šalje sadržaje brzinom kojom ih primatelj ne može primati, onda primatelj odbacuje dio paketa koji stižu na njega. Velik intenzitet slanja većeg broja izvora može dovesti do zagušenja usmjerivača i do bitnog pada performansi mreže. Protokol TCP sa transportne razine Interneta, o kojem govorimo kasnije, vodi računa o takvim stvarima; UDP, kao drugi protokol transportne razine Interneta, ne vodi računa o tim stvarima. UDP preuzima sadržaje koje proizvode aplikacije, i te sadržaje šalje prema njihovim odredištima najvećim intenzitetom kojim to može činiti.

UDP izvodi prijenos segmenata između aplikacija bez da prethodno uspostavi postojanu vezu među njima. U engleskom se takav prijenos opisuje kao "connectionless"; ovdje ćemo to svojstvo označiti kraćim nazivom neveznom uslugom prijenosa. Dakle, UDP šalje segmente od procesa-pošiljatelja na proces-primatelja bez da prethodno uspostavi neki oblik veze (logičkog kanala) između pošiljatelja i primatelja. Drugi protokol transportne razine, TCP, uspostavlja vezu (logički kanal) između komunikatora prije početka prenošenja sadržaja između tih komunikatora.

To što ne uspostavlja posebnu vezu (logički kanal) između komunikatora, omogućava UDP protokolu da sadržaje koje aplikacije upisuju u svoje utičnice (prema UDP protokolu) šalje odmah primateljima, bez da troši vrijeme na uspostavljanje logičkih kanala između pošiljatelja i primatelja.

Inače, "uspostavljanje logičkog kanala" znači da komunikatori razmjenjuju nekoliko upravljačkih poruka prije početka prijenosa podatkovnih sadržaja: u toj komunikaciji rezerviraju neke memorijske prostore i definiraju neka svojstva budućeg prijenosa, kao što su brzina, i druga. Razmjenu takvih upravljačkih poruka među komunikatorima prije prijenosa sadržaja, nazivamo uspostavljanjem veze, odnosno logičkog kanala; takva veza ili kanal traju dok traje jedan prijenos.

Dakle, UDP ne radi na takav način: ne uspostavlja logičke veze ni kanale, nego prenosi (uz pomoć slojeva ispod sebe) sa domaćina i porta na domaćina i port, smjesta i najvećim intenzitetom kojim može.

Protokol UDP ne ispravlja greške koje nastaju u prijenosu; to ovdje znači da ne izvodi ponovni prijenos onih segmenata čiji su sadržaji iskrivljeni ili izgubljeni u procesu prijenosa. Zato kažemo da UDP pruža nepouzdanu (unreliable) uslugu prijenosa, ili uslugu nepouzdanog prijenosa. Nasuprot tome, protokol TCP pruža aplikacijama pouzdane (reliable) usluge prijenosa, uz prethodno uspostavljanje (trajne) logičke veze ili kanala među komunikatorima.

Kontrolni zapis iz UDP zaglavlja omogućava tom protokolu da otkriva (s određenom vjerojatnošću) iskrivljenja zapisa segmenata, koja se dogode u procesu njihovog prijenosa. Ali UDP ne ispravlja greške koje može otkriti na temelju takvih zapisa. Nepouzdanost prijenosa općenito zvuči nepovoljno, ali donosi neke pogodnosti. Protokol je jednostavan i oslobođen je izvođenja onih procesa koji su potrebni za ispravljanje grešaka; to mu omogućava brži prijenos i oslobađa ga potrebe ponavljanja prijenosa sadržaja. Nadalje, kod video prijenosa, promptan (brz) prijenos, bez izvođenja procesa koji povećavaju kašnjenje i bez ponavljanja slanja, je svakako važniji od potpune točnosti prijenosa.

Jednostavnost protokola UDP znači da taj protokol (kao softver) sadrži manji broj varijabli, memorijskih prostora i procesa. Jednostavnost zaglavlja njegovog segmenta znači da je i proces obrade segmenta kod slanja i primanja (multipleksiranja i demultipleksiranja) jednostavan i brz u usporedbi sa protokolom TCP, kao drugim protokolom transportne razine Interneta.

Jednostavnost UDP protokola omogućava veću brzinu njegova rada i veću brzinu onih prijenosa koji se izvode pomoću tog protokola. Mala količina poslova koje izvodi, čine UDP

13

protokol prikladnim za potrebe prijenosa kod nekih vrsta aplikacija. Naprimjer, to što ne troši vrijeme ni prijenosne kapacitete na ispravljanje grešaka u prijenosu, čini UDP prikladnim za izravne video prijenose događaja koji se upravo odvijaju. Kod takvih prijenosa ne bi imalo smisla ponavljati prijenos iskrivljenog dijela neke snimke (iz niza snimki), jer događaj se odvija dalje, tako da naknadno prenijeta ispravna snimka (donijeta ponavljanjem prijenosa) ne bi služila ničemu.

Protokol UDP je općenito prikladan za one aplikacije kod kojih je brzina prijenosa važnija od potpune točnosti; dakle, za aplikacije koje nisu osjetljive na gubitak određenog dijela sadržaja u prijenosu, ali su obično osjetljive na zadržavanje na putu (kašnjenje u prijenosu). U tablici koja je dana na slici 2.5 navedena je jedna lista mrežnih (Internet) aplikacija, uz transportne protokole koje te aplikacije koriste.

Slika 2.5 Aplikacije i pripadni protokoli

Aplikacije kao što su računalna pošta (protokol SMTP), rad na udaljenom računalu (protokol Telnet), web sustav (protokol HTTP), i sustav za prijenos datoteka (protokol FTP), koriste usluge TCPa, jer za ispravan rad tih aplikacija potrebna je pouzdana usluga prijenosa. Ali brojne važne aplikacije koriste usluge protokola UDP za prijenos podataka; taj prijenosni protokol koriste aplikacije s kojima rade obični korisnici, kao i aplikacije s kojima rade operateri mreže, pomoću kojih se održava rad računalne mreže. Navedimo nekoliko primjera.

Protokol SNMP (Simple Network Management Protocol = jednostavni protokol za upravljanje mrežom) namijenjen je nadziranju rada računalne mreže i upravljanju radom te mreže. Taj protokol koristi usluge protokola UDP za prijenos svojih upravljačkih sadržaja; SNMP to čini zato što je UDP jednostavniji nego TCP. Intervencije upravljačkog sustava SNMP često su potrebne onda kad u mreži nešto ne radi dobro; zato SNMP koristi čim jednostavniji prijenosni protokol, jer to povećava izglede da će uspjeti uspostaviti komunikaciju sa nekim udaljenim čvorom i prenijeti na taj čvor one upravljačke sadržaje (naredbe, podatke) pomoću kojih će biti otklonjene slabosti u radu toga čvora.

Sustav DNS (Domain Name System = sustav imena domena) nalazi numeričku IP adresu za danu tekstualnu (mnemoničku) IP adresu. DNS je hijerarhijski sustav globalnih razmjera, koji se sastoji od mnoštva DNS servera; o tom sustavu govorimo u poglavlju o aplikacijama. Sustav DNS

14

koristi usluge UDP protokola zbog toga što taj protokol omogućava razmjenu sadržaja između DNS klijenata i servera bez da se prethodno uspostavi vezu (kanal) između njih; na taj način postiže se veća brzina rada sustava DNS. Eventualni gubitak nekog paketa u radu DNS sustava nema posebno nepovoljne posljedice, jer će pošiljatelj upita, koji ne dobije traženi odgovor, ponoviti svoj upit istom serveru, ili nekom drugom serveru iste razine, koji sadrži iste podatke i može dati odgovor na isti upit.

Protokol RIP (Routing Information Protocol) prenosi podatke između usmjerivača o stanju njihovih veza. Na temelju takvih podataka, koje svaki usmjerivač šalje susjedima (izravnim, ili na nekom području), usmjerivači tvore i mijenjaju svoje tablice usmjeravanja i prosljeđivanja IP paketa, u skladu sa promjenama stanja usmjerivača i veza, za koje (promjene) saznaju razmjenom podataka sa susjedima. Usmjerivači razmjenjuju pakete s ovakvim podacima kontinuirano, svakih nekoliko minuta; eventualni gubitak nekog od takvih paketa obično nema veće posljedice, jer se za par minuta stanje mreže (na lokalnom području) vjerojatno nije bitno promijenilo. Nakon par minuta šalje se novi paket s novim podacima za ažuriranje tablica usmjeravanja, čime prethodni paket i njegovi podaci postaju zastarjeli i nevažni. Zato protokol RIP koristi protokol UDP za prijenos svojih podataka.

Dakle, razne vrste aplikacija mogu imati razne razloge za to da koriste usluge prijenosa protokola UDP. Prijenos tog protokola nije pouzdan, ali su struktura njegovih segmenata i način njegova rada znatno jednostavniji nego kod TCP protokola, što onda ujedno omogućava veću brzinu rada.

Tokovne (streaming) aplikacije su aplikacije koje izvode preuzimanje video sadržaja sa mreže (na neki klijentski sustav), ili izvode izravan video-prijenos nekog događaja koji se upravo odvija. Takve aplikacije mogu općenito koristiti UDP ili TCP protokol. TCP može biti prikladan kod preuzimanja snimljenog materijala s mreže, dok je UDP prikladniji kod izravnog prijenosa događanja.

Interaktivne aplikacije u realnom vremenu, kao što su telefoniranje preko Interneta i telekonferencije, mogu isto tako koristiti usluge UDP protokola ili TCP protokola za prijenos svojih video-sadržaja. Spomenimo da su takve aplikacije često vlasničke (proprietary), tako da njihova unutarnja struktura i način rada često nisu javno poznati.

Protokol UDP ne vodi računa o trenutnom stanju (opterećenju) primatelja kojem šalje sadržaje, niti o stanju usmjerivača preko kojih se ti sadržaji kreću na svom putu od pošiljatelja do primatelja. To može dovesti do toga da primatelj ne može prihvaćati sadržaje (u IP paketima) onim intenzitetom kojim ih pošiljatelj šalje; tada neki IP paketi bivaju odbačeni na domaćinu primatelja, jer ih primatelj ne može prihvatiti.

Protokol UDP ne vodi računa o stupnju opterećenja usmjerivača, tako da svojim intenzivnim slanjem može dovesti do zagušenja nekih usmjerivača. Zagušenje ovdje znači da usmjerivač duže vrijeme prima IP pakete većim intenzitetom nego što ih prosljeđuje dalje, tako da su dolazeći paketi potpuno ispunili prijemnu memoriju usmjerivača. Zbog toga neki (ili mnogi) od paketa koji stižu na ovako zagušen usmjerivač moraju biti odbačeni.

Zagušenje usmjerivača i odbacivanje paketa (na usmjerivačima) čini da mreža postane neučinkovita. Ako mnogi intenzivni prijenosi zagušuju usmjerivače, i ako usmjerivači odbacuju pakete zbog zagušenja, onda će relativno mali broj paketa uspjeti proći kroz veći broj usmjerivača (na svom putu do odredišta) jer će vjerojatno biti odbačeni na jednom od njih. Zbog toga mreža sa zagušenim usmjerivačima čini malo korisnog posla. Povrh toga, sadržaji izgubljenih paketa su trajno izgubljeni, ili pak treba ponoviti njihovo slanje, čime se dodatno opterećuje veze i usmjerivače.

UDP protokol ne vodi računa o tim stvarima, dok TCP protokol vodi računa o tim stvarima. Zbog toga, kad su usmjervači preopterećeni i približavaju se stanju zagušenja, onda UDP promet istiskuje TCP prijenose. Naime, kad TCP protokol utvrdi da se opterećenje usmjerivača približava

15

točki njihovog zagušenja, onda TCP smanjuje intenzitet svog prijenosa. UDP ne vidi te probleme, tako da nastavlja sa svojim prijenosima jednakim intenzitetom. Na taj način UDP promet istiskuje TCP promet u kritičnim situacijama (pred zagušenje). To nije dobro, ni za TCP prijenose, ni za mrežu u cjelini; zato postoje prijedlozi da se UDP protokolu doda neke elemente (upravljačke podatke) i da se na temelju njih definira neki proces upravljanja intenzitetom prijenosa, na temelju trenutnog stanja (mogućnosti) usmjerivača i veza.

IP protokol, koji prenosi segmente u svojim paketima, ne provodi kontrolu ispravnosti prijenosa. Zaglavlje IP paketa (verzija 4) sadrži polje za upis kontrolnog zapisa, ali taj zapis izračunava se samo na zaglavlju IP paketa. Proces izračunavanja tog kontrolnog zapisa ne obuhvaća tijelo IP paketa, tako da se na temelju takvog kontrolnog zapisa ne mogu otkriti iskrivljenja u tijelu paketa. Ako se na temelju kontrolnog zapisa utvrdi da je došlo do iskrivljenja zapisa u zaglavlju IP paketa, onda se taj IP paket odbacuje.

Neki protokoli razine veze podataka (koji prenose IP pakete u svojim okvirima), izvode pouzdan prijenos podataka na toj razini; drugi protokoli te razine izvode neke kontrole ispravnosti prijenosa okvira, ali ne otklanjaju greške u prijenosu. Na svom putu od izvora do odredišta, IP paket može na nekim dionicama puta biti prenošen u okvirima sustava razine veze podataka koji izvodi pouzdan prijenos, dok na drugim dionicama isti IP paket može biti prenošen u okvirima sustava čiji prijenos nije pouzdan. Ako se na svim dionicama preko kojih je prenijet neki IP paket od izvora do odredišta, izvodi pouzdan prijenos na razini veze podataka, time još nije ostvaren pouzdan prijenos paketa od pošiljatelja do primatelja. Naime, pouzdanost na razini veze podataka znači pouzdanost prijenosa između dvaju čvorova, odnosno između njihovih mrežnih kartica; ali greške u prijenosu mogu se dogoditi u čvorovima; naprimjer, na usmjerivaču, u procesu usmjeravanja. Zato je za otkrivanje grešaka u prijenosu potrebno da postoji kontrola ispravnosti na razini s-kraja-na-kraj komunikacije, a to je ovdje razina transporta.

Dakle, UDP protokol i zaglavlje njegovog segmenta sadrže podatke i procese koji omogućuju otkrivanje grešaka u prijenosu. Ali UDP protokol ne ispravlja greške koje otkriva. Neke implementacije UDP protokola odbacuju one segmente za koje je utvrđeno da su iskrivljeni; druge implementacije predaju sadržaje iskrivljenih segmenata aplikacijama, uz upozorenje da je u tim segmentima došlo do nekih iskrivljenja sadržaja.

2.3 Pouzdanost sustava nepouzdanih elemenata

Jedna od središnjih tema u govoru o komunikacijskim sustavima je na koji način ostvariti pouzdanost (postojanu i zajamčenu točnost) prijenosa koristeći prijenosne usluge nepouzdanog sustava, odnosno nepouzdane usluge prijenosnog sustava. Ukratko, pouzdanost prijenosa pomoću nepouzdanih sredstava ostvaruje se na taj način da se definira (1) podsustav za utvrđivanje da li je došlo do greške u prijenosu, i (2) podsustav za otklanjanje otkrivenih grešaka. Pritom se otklanjanje grešaka redovito izvodi na taj način da se ponovi prijenos onih dijelova sadržaja koji su iskrivljeni u prijenosu.

Iskrivljenja koja su nastala u prijenosu otkriva se na temelju kontrolnih zapisa, kako je to opisano ranije. Postoje razne vrste kontrolnih zapisa i razne metode (algoritmi) njihovog računanja. Kod izbora kontrolnog zapisa i metode njegovog izračunavanja, općenito se teži postizanju čim veće vjerojatnosti otkrivanja iskrivljenja jednog ili više bitova u nekom paketu, uz korištenje čim kraćeg kontrolnog zapisa (u bitovima). Takvi zapisi su obično dužine od 8 do 32 bita; duži kontrolni zapisi (i kraći paketi podataka) omogućuju da se postignu bolji rezultati u otkrivanju iskrivljenja bitova u tim paketima.

Slika 2.6 ilustrira osnovnu strukturu mrežnog sustava u kojem se ostvaruje pouzdan prijenos

16

pomoću nepouzdanih sredstava.

Slika 2.6 Pouzdan prijenos pomoću nepouzdanih usluga

Ponavljanje prijenosa segmenata (i IP paketa koji ih prenose) može se izvoditi na razne načine, o čemu govorimo u odjeljku o TCP protokolu. Računalna mreža ima više slojeva nego što je prikazano na slici 2.6, ali to ovdje nije bitno. Ovdje je bitno to, da računalna mreža treba ostvariti na transportnoj razini mogućnost pouzdanog prijenosa, koristeći nepouzdane usluge prijenosa sa mrežne razine sustava.

Aplikacija započinje proces prijenosa koristeći uslugu (protokol) pouzdanog prijenosa, koju aplikacijama nudi transportna razina. Transportna razina ostvaruje tu pouzdanu uslugu koristeći nepouzdane usluge prijenosa mrežnog sloja ispod sebe.

Za ostvarenje pouzdanog prijenosa u jednom smjeru, potrebna je dvosmjerna komunikacija na razini transportnog sloja jer se na toj razini podatkovni sadržaji kreću u jednom smjeru, a potvrde o njihovom primitku u drugom smjeru. Pouzdanost prijenosa na transportnoj razini ostvaruje se na taj način što primatelj šalje povratne obavijesti pošiljatelju o primitku onih segmenata koje je primio u ispravnom stanju. Ako protokol transportne razine utvrdi da je došlo do iskrivljenja ili gubitka nekog segmenta u procesu njegovog prijenosa (na mrežnoj razini, ili niže), onda protokol transportne razine traži od protokola mrežne razine da ponovi prijenos tog segmenta (u svom IP paketu).

Dakle, za ostvarenje pouzdanog prijenosa na transportnoj razini uz upotrebu nepouzdanih usluga prijenosa na mrežnoj razini, protokol transportne razine treba sadržavati neke elemente i izvoditi neke procese, koje smo spomenuli iznad.

Prvo, potrebno je da definira podsustav koji otkriva: (1) iskrivljenja segmenata u prijenosu, (2) gubitak segmenata u prijenosu, i (3) dolazak segmenata na odredište u različitom redoslijedu od onog u kojem su bili poslani.

Drugo, protokol treba definirati proceduru kojom primatelj izvještava pošiljatelja o ishodu

17

njegovog pokušaja prijenosa segmenta; taj ishod može biti obavijest o uspješnom prijenosu, ili obavijest o neuspjehu, sa kojom se ujedno zahtjeva ponovno slanje određenog segmenta.

Konačno, treba definirati način (proceduru) ponovnog slanja onih sadržaja (segmenata) u čijem je prijenosu došlo do greške.

Postoje razne mogućnosti oblikovanja i realizacije triju navedenih podprocesa, ali ovdje se ne trebamo podrobnije baviti tim mogućnostima. U slijedećem odjeljku iznosimo prikaz na koji način su ti podprocesi definirani i realizirani u TCP protokolu transportne razine računalne mreže Internet.

Kod otklanjanja grešaka ponavljanjem prijenosa potrebno je odrediti način razlikovanja izvornog sadržaja (IP paketa) od sadržaja (IP paketa) čije se slanje ponavlja. Takvo razlikovanje zasniva se na uvođenju slijednog broja (sequence number): svaki segment ima svoj slijedni broj, koji je zapisan u pripadnom polju njegovog zaglavlja. Na temelju tog broja, kad primi segment, primatelj vidi da li je to novi segment, ili je primatelj već primio segment sa tim sadržajem.

Pošiljatelj može ponoviti slanje segmenta kojeg je primatelj već primio, onda kad pošiljatelj nije primio povratnu potvrdu od primatelja da je taj segment primio u ispravnom stanju. Ovakvu povratnu potvrdu u engleskom se naziva acknowledgment (i koristi se kraticu ACK); taj pojam ima više značenja; ovdje to znači priznavanje (ili potvrda) primitka segmenta.

Postoji više razloga zbog kojih pošiljatelj može ne primiti povratnu potvrdu koju mu je primatelj poslao. Takva potvrda može se izgubiti putem i ne stići na svoje odredište. Potvrda može biti iskrivljena putem, tako da je njen primatelj ne prepoznaje kao potvrdu. Potvrda može kasniti u odnosu na očekivanje pošiljatelja, tako da pošiljatelj zaključuje da potvrda neće ni stići, odnosno da segment kojeg je poslao nije stigao na odredište u ispravnom stanju.

U sva tri slučaja pošiljatelj šalje ponovno segment (u IP paketu), jer zaključuje da primatelj nije primio prethodni primjerak toga segmenta kojeg mu je poslao. U slučaju kad je problem nastao s povratnom potvrdom, a ne sa izvornim segmentom, primatelj će dobiti segment čiji sadržaj je već primio. Primatelj će to utvrditi na temelju toga što novi segment ima isti slijedni broj kao jedan od segmenata koje je već primio. Primatelj tada odbacuje novu kopiju segmenta kojeg već ima, ali potvrđuje njegov primitak. Jer ako pošiljatelj šalje ponovno isti segment, čiji je primitak primatelj već ranije potvrdio, onda znači da pošiljatelj nije primio tu potvrdu. Zato primatelj odbacuje segment, ali šalje (ponovno) potvrdu o njegovom primitku.

Jedan od trajnih problema kod potvrđivanja primitka je pitanje kako odrediti koliko dugo treba pošiljatelj čekati na povratnu potvrdu za neki poslani segment, prije nego zaključi da ta potvrda neće stići, i onda ponovi slanje segmenta. Pošiljatelj treba svakako čekati barem onoliko dugo koliko iznosi vrijeme povratnog puta (RTT) između njega i primatelja. Minimalna vrijednost tog vremena je ono vrijeme koje je potrebno signalu (kao nosiocu sadržaja) da prijeđe dani put od pošiljatelja do primatelja i natrag. Tome treba dodati (procijenjeno) vrijeme zadržavanja IP paketa na usmjerivačima na putu od izvora do odredišta; treba dodati i neko vrijeme koje je potrebno primatelju da prihvati segment i da proizvede povratnu potvrdu o njegovom primitku. Jer i povratne potvrde su zasebni segmenti, ili se prenose u nekim drugim segmentima koje šalje pošiljatelj takve potvrde.

Teško je procijeniti (izračunati) optimalno vrijeme čekanja na povratnu potvrdu, pogotovo na velikim udaljenostima i kod promjenljivog stanja mreže. To vrijeme se stalno mijenja, zajedno sa promjenama u opterećenju domaćina (koji primaju segmente), usmjerivača i veza na putu. Sustav pošiljatelja stalno prati stanje mreže i izračunava optimalno vrijeme čekanja na povratnu potvrdu za poslani paket u okviru neke komunikacije. Ako povratna potvrda ne stigne u očekivanom vremenu, onda pošiljatelj šalje ponovno isti sadržaj (isti segment u novom IP paketu), iako postoji mogućnost (1) da je prethodni IP paket stigao primatelju u ispravnom stanju i (2) da je primatelj poslao o tome povratnu potvrdu; (3) da će primatelj primiti ponovno isti sadržaj (segment), i (4) da će pošiljatelj primiti potvrdu o primitku toga segmenta nakon što taj segment ponovno pošalje primatelju.

18

Ponovna slanja koja nisu bila neophodna dovode do dupliciranja sadržaja (segmenata) na primatelju. Međutim, svaki segment ima svoj slijedni broj, na temelju kojeg primatelj utvrđuje da li je prispjeli segment kopija nekog segmenta kojeg je već primio.

Polje za zapis slijednog broja je ograničene dužine; naprimjer, 32 bita. Kad slijedni broj dosegne najveću vrijednost koju se može upisati u to polje, onda taj broj kreće opet od 0; to znači da se slijedni brojevi ciklički ponavljaju. To može dovesti do problema. Ako se ponavlja slanje segmenta čiji slijedni broj glasi s1, i ako se to ponavljanje izvodi sa velikim kašnjenjem, onda se (u načelu) može dogoditi da ponovljeni segment s1 stigne na primatelja onda kad primatelj očekuje segment sa slijednim brojem s1 iz novog ciklusa slijednih brojeva. Tada bi primatelj uvrstio ponovljeni s1 tamo kamo ne spada, i tako predao aplikaciji neispravan sadržaj. Postoji više načina da se izbjegne pojavu takve greške; neke od tih mogućnosti spomenuti ćemo u prikazu TCP protokola, u slijedećem odjeljku. Ukratko, potrebno je da polje za upis slijednog broja bude relativno veliko, i potrebno je ograničiti veličinu raspona slijednih brojeva segmenata koje pošiljatelj smije imati poslane a nepotvrđene. Kad pošiljatelj dosegne taj raspon ("prozor"), onda ne smije više slati nove segmente dok ne dobije potvrdu o primitku najstarijeg poslanog a nepotvrđenog segmenta.

Za ponavljanje slanja segmenata nakon isteka određenog vremena, potrebno je uvesti "odbrojač vremena" (countdown timer) ili "tajmer" za svaki poslani segment. Takav tajmer uključuje se kod slanja segmenta i pokazuje kad istekne predviđeno vrijeme čekanja na povratnu potvrdu primitka tog segmenta, koja treba stići od njegovog primatelja. Ako potvrda primitka ne stigne do isteka tog odbrojača ili tajmera, onda segment treba poslati ponovno.

Uvođenje tajmera znači dopunu protokola transportne razine koji se izvodi na strani pošiljatelja, a time i izvođenje novih procesa na pošiljatelju segmenata. Među te dodatne procese spadaju:

- Uključivanje pripadnog tajmera za svaki segment kojeg se pošalje.- Zaustavljanje tajmera za svaki segment za kojeg je stigla povratna potvrda od primatelja o

njegovom primitku.- Izvođenje određenih operacija svaki put kad istekne tajmer nekog segmenta (za kojeg nije

stigla povratna potvrda o njegovom primitku).

Postoje dva osnovna načina rada kod slanja segmenata za koje primatelj potvrđuje primitak. Prvi način naziva se metodom stani-i-čekaj (stop-and-wait), a drugi način nazvali smo metodom cjevovoda (pipelining); potonji naziv ne zvuči naročito lijepo, ali poslužiti će svrsi.

Kod prvog načina rada, pošiljatelj pošalje jedan segment i onda čeka na primitak povratne potvrde kojom primatelj potvrđuje da je primio taj segment (u paketu). Ako pošiljatelj ne primi takvu potvrdu u nekom zadanom vremenu, onda šalje ponovno isti segment. Kad pošiljatelj primi povratnu potvrdu o primitku poslanog segmenta, onda šalje novi segment. Slika 2.7 ilustrira način rada kod metode stani-i-čekaj.

19

Slika 2.7 Metoda stani-i-čekaj

Kod metode cjevovoda, pošiljatelj šalje veći broj segmenata za redom, bez da čeka na povratne potvrde o njihovom primitku. Slika 2.8 ilustrira način rada kod metode cjevovoda.

20

Slika 2.8 Metoda punjenja cjevovoda

Slanje metodom cjevovoda omogućava postizanje znatno veće brzine slanja nego kod metode stani-i-čekaj. Ali kod metode cjevovoda postoje i neka ograničenja; osnovno ograničenje je broj nepotvrđenih segmenata koje pošiljatelj smije imati u procesu slanja. Nakon što pošalje toliki broj segmenata, pošiljatelj prestaje slati i čeka da primi potvrdu o primitku nekog od tih segmenata; točnije, onog koji je poslan prvi. Kad primi takvu potvrdu, pošiljatelj smije poslati jedan novi segment. Ako potvrda ne stigne u zadanom vremenu, pošiljatelj ponavlja slanje najstarijeg segmenta, čiju potvrdu o primitku treba primiti, da bi mogao nastaviti slati nove segmente. Ako stigne niz potvrda za redom, onda pošiljatelj može poslati više novih segmenata za redom. Dakle,

21

ovdje pošiljatelj šalje više segmenata bez čekanja na potvrde, ali postoje određena ograničenja u toj brzini slanja.

Metoda cjevovoda izgleda dobro, ali potrebno je definirati još nekoliko situacija koje mogu nastati kod ovakvog načina rada. Prije svega, transportni protokol koji radi na pošiljatelju, treba čuvati (u svojoj memoriji) zapise onih segmenata koje je poslao, a čiji primitak mu nije još potvrđen. Svaki od tih segmenata može biti izgubljen na putu; ako potvrda o njegovom primitku ne stigne (u zadanom vremenu), onda transportni protokol pošiljatelja treba poslati taj segment ponovno. Zato transportni protokol pošiljatelja treba čuvati kopiju svakog poslanog segmenta, sve dok ne primi povratnu potvrdu od primatelja o primitku tog segmenta.

Pitanje je što treba primatelj činiti sa segmentima koje prima izvan redoslijeda. Segmenti stižu primatelju izvan redoslijeda onda kad se dogode gubici (iskrivljenja) nekih drugih segmenata; tada nastaju praznine u nizu primljenih segmenata na primatelju, što čini da neki segmenti budu "izvan redoslijeda". Primatelj može odbacivati takve segmente i time prisiliti pošiljatelja da mu ponovno pošalje najstariji segment kojeg primatelj nije primio. Nakon što pošalje taj segment i primi potvrdu o njegovom primitku, pošiljatelj će poslati ponovno i one segmente koje je primatelj odbacio jer su bili "izvan redoslijeda". Primatelj može i memorirati segmente koje prima izvan redoslijeda; time se izbjegava potrebu po njihovom ponovnom slanju. Kad primi zaostali segment kojim se popunjava praznina u nizu, primatelj može potvrditi primitak ponovno poslanog segmenta i svih onih segmenata koji su ranije bili izvan redoslijeda, ali više nisu. Takvo potvrđivanje može se izvesti kumulativno, tako da se potvrdi primitak zadnjeg segmenta u neprekinutom nizu, čime se potvrđuje i primitak svih segmenata koji mu prethode.

Segmenti koje pošiljatelj šalje imaju slijedne brojeve; to je neprekinut rastući niz cijelih brojeva, koji počinje od vrijednosti 0 i raste do broja 2n-1, pri čemu je n dužina polja (u bitovima) u koje se upisuje slijedni broj. Ako zamislimo slijedne brojeve kao jedan niz u prostoru, onda broj nepotvrđenih paketa n koje pošiljatelj smije imati "na putu", izgleda poput jednog prozora na zamišljeni niz slijednih brojeva. Primatelj potvrđuje primitke segmenata, a pošiljatelj mu šalje nove segmente; pritom, svaki novi segment ima veći slijedni broj od prethodnog, a potvrda o primitku stiže za segment sa najnižim slijednim brojem od svih poslanih (a nepotvrđenih) segmenata. Tako pošiljateljev "prozor" na niz slijednih brojeva, koji je maksimalne širine n, stalno "klizi" prema gore, ili točnije rečeno, po kružnici. Tako je navodno nastao naziv klizni ili klizeći prozor (sliding window).

Prostor za zapis slijednog broja (u zaglavlju segmenta) je ograničene veličine; kad dosegne najveću vrijednost koja može biti zapisana u taj prostor, onda vrijednost slijednog broja kreće opet od nule. Ako želimo da se klizni prozor kreće "naprijed" (umjesto skoka natrag na nulu), onda treba da niz slijednih brojeva promatramo kao kružnicu, u kojoj se najviši slijedni broj "spaja" na početak niza slijednih brojeva; dakle, iza 2n-1 slijede brojevi 0, 1, 2, .... Postoje i druga objašnjenja naziva klizni prozor, ali čini se da ovo objašnjenje prevladava.

Kod slanja metodom cjevovoda, postoje dva osnovna načina ponašanja pošiljatelja u situaciji kad ne primi povratnu potvrdu do isteka tajmera za poslani segment. Prvi način naziva se vraćanje-za-N (Go-Back-N - GBN), a drugi način naziva se selektivnim ponavljanjem (selective repeat - SR).

Metoda GBN

Kod metode GBN postoje tri osnovna događaja koji čine da ta metoda izvede određene procese.

(1) Poziv sa aplikacijske razine - Aplikacija je upisala neki sadržaj u svoju utičnicu prema protokolu transportne razine, koji izvodi pouzdan prijenos. Transportni protokol provjerava da li trenutno stanje njegovog kliznog prozora dopušta slanje: dakle, da li već ima poslanih n segmenata (u toj TCP vezi) za koje još nije primio potvrdu o njihovom primitku. Ako n još nije dosegnut

22

(dakle, prozor nije maksimalno otvoren), onda protokol uzima sadržaj iz utičnice, formira segment i predaje ga mrežnom sloju, koji ga prenosi na odredišnog domaćina. Pritom transportni protokol ujedno mijenja zapis o "otvorenosti" svog prozora i druge parametre. Ako je prozor transportnog protokola (za tu aplikaciju) maksimalno otvoren, onda transportni protokol ne preuzima sadržaj iz utičnice, čime implicitno obavještava aplikaciju (koja želi slati) da su njegove mogućnosti slanja trenutno potpuno zauzete i da trenutno ne može preuzeti (i prenijeti) dani sadržaj. Što učiniti dalje u takvoj situaciji, može se riješiti na razini implementacije metode GBN. Naprimjer, sadržaj (od aplikacije) može ostati zapisan u utičnici (u odgovarajućem baferu) dok transportni protokol ne bude u mogućnosti preuzeti i prenijeti taj sadržaj.

(2) Primitak povratne potvrde - Transportni protokol prima potvrdu (od primatelja) o primitku segmenta kojeg je ranije poslao. Ovdje se uzima da primatelj potvrđuje kumulativno; to znači da potvrdom o primitku segmenta čiji slijedni broj glasi Sn, primatelj potvrđuje i primitak svih segmenata čiji slijedni brojevi prethode broju Sn. Takav način potvrđivanja naziva se kumulativnim potvrđivanjem (cumulative acknowledgment). Kad primi potvrdu o primitku segmenta, transportni protokol (na strani pošiljatelja) mijenja stanje svog kliznog prozora i drugih parametara; tada može i preuzeti (i poslati) nove sadržaje iz utičnice aplikacije, koje ranije nije mogao preuzeti.

(3) Istek vremenskog odbrojača (tajmera) - Pošiljatelj može koristiti poseban tajmer za svaki poslani segment, ali to čini proces slanja složenijim; zato pošiljatelj obično koristi samo jedan tajmer, koji je pokrenut u trenutku slanja prvog segmenta iz danog kliznog prozora; dakle, kod slanja prvog u nizu segmenata koji su poslani, a čiji primitak nije potvrđen. Možemo uzeti da tajmer odbrojava vrijeme za najstariji segment. Ako istekne taj tajmer, a primatelj ne primi povratnu potvrdu (ACK) za najstariji segment, onda pošiljatelj ponavlja slanje svih segmenata iz svog prozora; dakle, svih segmenata koje je poslao, a za koje nije primio povratnu potvrdu primitka (ACK). Takvih segmenata može biti najviše N (koliko iznosi širina prozora); zato se ova metoda naziva vraćanje za n ("idi-natrag-n"; go-back-n - GBN).

Kod metode GBN ima nepotrebnih ponavljanja slanja segmenata; naime, kad istekne tajmer za prvi segment u prozoru, pošiljatelj ponavlja slanje svih segmenata iz prozora. Postoje praktički razlozi za takav način rada. Glavni među tim razlozima je taj, da se ponavljanjem slanja cijelog prozora oslobađa primatelja obaveze da "pamti" one segmente koje je primio "izvan redoslijeda" (jer nedostaje mu barem jedan u nizu). O tome će biti još riječi u nastavku.

Kod metode GBN može se koristiti zaseban tajmer za svaki segment, ali se obično koristi jedan tajmer za sve segmente (iz danog prozora) i kumulativno potvrđivanje primitka segmenata. Kod slanja prvog segmenta, "otvara" se prozor i pokreće se tajmer. Svaki put kad stigne potvrda ACK za najstariji segment, tajmer se pokreće iz početka ako ima još poslanih a nepotvrđenih segmenata (prozor nije zatvoren); ako nema nepotvrđenih segmenata, onda se tajmer zaustavlja.

Kod GBN metode, na strani primatelja odvija se slijedeći proces. Nakon što je primio segment sa slijednim brojem Sn, protokol transportne razine očekuje segment sa slijednim brojem Sn+1. Ako primatelj ne primi segment Sn+1 kojeg očekuje (u ispravnom stanju), nego neki drugi segment, onda odbacuje taj drugi segment i šalje pošiljatelju ponovno potvrdu (ACK) o primitku prethodnog ispravno primljenog segmenta Sn. Na taj način javlja pošiljatelju koji segment je primio zadnji u ispravnom stanju i koji segment očekuje kao slijedeći.

Dakle, metoda GBN odbacuje i ispravne segmente, ako ispred ispravno primljenog segmenta nedostaje neki segment u nizu. Odbacivanje ispravno prenijetih segmenata iziskuje naknadno ponavljanje njihovog prijenosa (što nije dobro), ali takav način rada pojednostavljuje proces slanja i primanja segmenata. Sadržaj (poruka) treba biti prenijet prijemnoj aplikaciji u cijelosti; pritom, segmenti koji prenose taj sadržaj trebaju na odredištu biti poredani onako kako su bili poredani na izvoru. GBN metoda jamči da će to biti učinjeno, makar i uz neka nepotrebna ponavljanja prijenosa segmenata.

23

Dakle, kod GBN metode, ako se dogodi gubitak nekog segmenta, ili gubitak (kašnjenje) potvrde o njegovom primitku, onda pošiljatelj ponavlja slanje svih segmenata iz svog prozora. S druge strane, primatelj odbacuje sve segmente čiji slijedni brojevi nisu jednaki slijednom broju kojeg očekuje. To izaziva neka nepotrebna ponavljanja slanja, ali bitno pojednostavljuje procese slanja i primanja segmenata.

Kad gubitak nekog segmenta dovede do prekida niza segmenata na strani primatelja, onda (prema GBN metodi), primatelj odbacuje segmente koje (nakon toga) prima "izvan redoslijeda" i za svaki takav segment šalje potvrdu o primitku zadnjeg segmenta kojeg je primio u ispravnom stanju i redoslijedu. Slika 2.9 ilustrira ponašanje pošiljatelja i primatelja kod protokola transportne razine koji radi prema metodi GBN i ima prozor veličine 4; u danom primjeru, izgubljen je treći segment (S2; numeracija počinje od 0).

Slika 2.9 Metoda GBN

Kod metode GBN, pošiljatelj nastavlja slati segmente Sn+i bez da čeka povratnu potvrdu (ACKn) za segment Sn. Pošiljatelj postupa tako do ispunjenja svog kliznog prozora za slanje, ili do isteka tajmera za segment Sn.

Na slici 2.9 primatelj očekuje segment S2, ali umjesto toga dobiva druge segmente. U toj

24

situaciji, primatelj odbacuje svaki segment kojeg prima (ovdje S3, S4, S5) nakon segmenta S1, i za svaki od tih segmenata ponovno šalje potvrdu ACK1 (za S1). Ponavljanjem potvrde primitka za S1, primatelj obavještava pošiljatelja da prima segmente izvan redoslijeda i da očekuje segment S2, koji je vjerojatno izgubljen u prijenosu i treba ga poslati ponovno.

U primjeru sa slike 2.9 pošiljatelj ponavlja slanje trećeg segmenta (S2) nakon što je isteklo vrijeme (tajmer) u kojem je trebao primiti povratnu potvrdu (ACK2) od primatelja o primitku toga segmenta (paketa), a ta potvrda nije stigla. Nakon toga ponavlja slanje i svih ostalih (poslanih) segmenata iz svog kliznog prozora.

Inače, po primitku tri ponovljene potvrde (ukupno četiri) za Sn (ovdje ACK1) pošiljatelj obično ponavlja slanje segmenta Sn+1, bez da čeka da istekne tajmer za taj segment.

Selektivno ponavljanje (SR)

Da bi punjenje cjevovoda (veze) bilo učinkovito, klizni prozor treba biti relativno velik; dakle, pošiljatelj treba imati mogućnost da pošalje veći broj segmenata bez da čeka na potvrde o njihovom primitku. Ali ako je veličina kliznog prozora velika, onda kod GBN metode, gubitak jednog segmenta Si dovodi do toga da primatelj odbacuje velik broj segmenata koji su prenijeti u ispravnom stanju: dakle, svih segmenata koje primi nakon izgubljenog segmenta Si.

Kod metode selektivnog ponavljanja slanja (selective repeat - SR) primatelj ne odbacuje ispravne segmente koje prima nakon nekog nedostajućeg segmenta (u nizu), nego ih zapisuje u svoju memoriju i zasebno potvrđuje primitak svakog od tih segmenata. To znači da pošiljatelj ne treba ponavljati slanje onih segmenata čiji je ispravan primitak potvrđen; ponavlja se samo slanje onog segmenata za kojeg nije primljena potvrda ACK, nakon isteka njegovog tajmera.

Kod SR metode isto postoji klizni prozor za slanje (veličine n). Pošiljatelj ne šalje segment čiji slijedni broj prelazi gornju granicu njegovog trenutnog kliznog prozora; kao i kod metode GBN, donja granica prozora određena je najnižim slijednim brojem poslanog segmenta čiji primitak nije još potvrđen.

Kod SR metode, primatelj zapisuje u svoju memoriju segmente koje prima u ispravnom stanju (i potvrđuje njihov primitak), bez obzira na to da li mu nedostaje neki segment koji prethodi tim segmentima. Praznine u nizu primljenih segmenata na primatelju pokazuju da su ti segmenti iskrivljeni ili izgubljeni u prijenosu. S obzirom da primatelj nije potvrdio njihov primitak, pošiljatelj će te segmente poslati ponovno. Na taj način biti će ispunjene praznine u nizu segmenata na strani primatelja; kad se taj niz (ili njegov početni dio) popuni, onda transportni protokol na primatelju upisuje taj ispunjeni niz sadržaja segmenata u utičnicu one aplikacije kojoj su namijenjeni.

Dakle, metoda rada sa selektivnim ponavljanjem slanja zasniva se na složenijim procesima nego metoda GBN (na strani pošiljatelja i na strani primatelja), ali kod te metode nema nepotrebnih ponavljanja prijenosa segmenata. Kod metode SR svaki segment treba imati svoj tajmer, jer ovdje se ponavlja slanje pojedinačnih segmenata, a ne nizova segmenata (svih iz prozora) kao kod metode GBN.

Kod selektivnog ponavljanja može se dogoditi da neki ponovljeni segment sa slijednim brojem Sn stigne primatelju s velikim zakašnjenjem, tako da ga primatelj prihvati kao segment Sn iz novog (slijedećeg) ciklusa slijednih brojeva. Postoje sredstva i postupci pomoću kojih se može spriječiti da se događaju takve greške. Prije svega, niz slijednih brojeva treba biti višestruko duži od veličine kliznog prozora; veličina kliznog prozora ograničava mogućnost slanja novih segmenata dok poslani segmenti nisu potvrđeni.

Primjenom takvih elemenata i postupaka onemogućava se da primatelju stižu segmenti (u IP paketima) koji kasne za cijeli ciklus slijednih brojeva. Samim izborom veličine kliznog prozora može se praktički riješiti taj problem. Klizni prozor pokazuje koji je najniži slijedni broj poslanog a nepotvrđenog segmenta, i koji se najveći slijedni broj može poslati u tom trenutku. Dakle, klizni prozor na pošiljatelju ne dopušta slanje novih segmenata (preko zadanog broja), dok primatelj ne

25

primi potvrdu o primitku prvog segmenta iz svog prozora - to jest, iz niza poslanih a nepotvrđenih segmenata.

Saberimo ukratko koji su elementi i procesi potrebni za definiranje i za realizaciju protokola koji izvodi pouzdan prijenos koristeći usluge nepouzdanog prijenosnog sustava.

- Kontrolni zapis - taj niz bitova omogućava primatelju da otkrije iskrivljenje segmenta (IP paketa) u procesu njegova prijenosa. Segmenti imaju svoje kontrolne zapise.

- Tajmer - mjeri vrijeme od trenutka slanja nekog segmenta; tajmer je "odbrojač vremena" koji se kreće od neke zadane vrijednosti prema nuli. Polazna vrijednost tajmera je veličina vremena koju se smatra dovoljnom da segment stigne od pošiljatelja do primatelja, i da povratna potvrda o primitku tog segmenta stigne od primatelja do pošiljatelja segmenta. Ako povratna potvrda ne stigne do isteka tajmera (iz bilo kojeg razloga), onda pošiljatelj ponavlja slanje jednog ili više segmenata, zavisno od načina njegova rada (GBN ili SR).

- Slijedni broj - omogućava da primatelj utvrdi da li je došlo do gubitka nekog segmenta u prijenosu. Slijedni brojevi tvore neprekinut niz (uz skok s kraja na početak niza); ako primatelj primi segment sa slijednim brojem Sn a nije primio segment sa slijednim brojem Sn-1, onda je segment Sn-1 vjerojatno izgubljen u prijenosu; u svakom slučaju, primatelj vidi da taj segment nedostaje u nizu segmenata koje je primio. Slijedni brojevi potrebni su i za rad pošiljatelja.

- Povratna potvrda (ACK) - poruka kojom primatelj potvrđuje pošiljatelju primitak određenog segmenta. Povratne poruke mogu općenito biti pozitivne i negativne; pozitivne poruke potvrđuju da se nešto dogodilo (segment je stigao); negativne poruke javljaju da se nešto nije dogodilo (segment nije stigao). Ovdje smo koristili pozitivne poruke; izostanak pozitivne poruke (nakon zadanog vremena) uzima se kao negativna poruka o tome da se očekivani dolazak segmenta na odredište nije dogodio.

- Klizni prozor - klizni (ili klizeći) prozor je najveći dopušteni raspon slijednih brojeva segmenata koje je pošiljatelj poslao, a za koje još nije primio povratnu potvrdu od primatelja. Klizni prozor primorava pošiljatelja da ponovi (i dovrši) slanje starih izgubljenih segmenata, prije nego što pošalje previše novih segmenata.

U slijedećem odjeljku opisujemo kako se ovi elementi koriste u protokolu transportne razine TCP, koji pruža usluge pouzdanog prijenosa u globalnoj mreži Internet.

2.4 Pouzdan prijenos: protokol TCP

Protokol TCP (Transmission Control Protocol) je protokol transportne razine mreže Internet, koji izvodi pouzdan prijenos sadržaja. Taj protokol je veznog tipa, ili vezno orijentiran (connection-oriented); to znači da komunikatori najprije uspostavljaju vezu između sebe, koju se naziva i logičkim kanalom, a onda po toj vezi međusobno razmjenjuju sadržaje. Protokol TCP je definiran i dopunjavan u nekoliko RFCa, od RFC 739 do RFC 2581. Protokol mrežne razine IP (Internet Protocol) i protokol TCP čine središnji dio globalne mreže Internet. U stvari, može se reći da par protokola TCP/IP "čini Internet", ali tom paru treba ipak dodati mnoštvo mrežnih aplikacija bez kojih taj par ne bi imao što raditi, i neku fizičku osnovu (sloj veze podataka i popratni hardver) na kojoj može raditi.

Kod aplikacija koje koriste TCP protokol, klijent i server uspostavljaju TCP vezu između sebe prije razmjene sadržaja. Takvo uspostavljanje TCP veze naziva se rukovanjem u tri koraka (three-way handshake). U tom rukovanju, klijent i server se međusobno predstavljaju (jedan drugome) i određuju razne parametre (varijable, memorijske prostore) koje će koristiti u radu te veze, u međusobnoj razmjeni sadržaja u TCP segmentima, koja slijedi.

26

Dakle, sustavi koji stupaju u komunikaciju najprije razmjenjuju nekoliko segmenata koji sadrže njihove osobne podatke i neke upravljačke sadržaje, na temelju kojih uspostavljaju jednu TCP vezu (ili logički kanal) između sebe. Nakon toga, komunikatori mogu po toj vezi slati i primati podatkovne sadržaje.

Uspostaviti TCP vezu znači pokrenuti jedan par procesa kojima su dodijeljeni odgovarajući memorijski prostori. Jedan od procesa odvija se na jednom domaćinu, a drugi na drugom; taj par procesa tvori jednu TCP vezu (ili jedan logički kanal) između dvaju komunikatora i izvodi prijenos sadržaja među njima.

TCP protokol radi samo na završnim čvorovima mreže; na usmjerivačima kroz koje "prolazi" jedna TCP veza (kanal) nema nikakvih zapisa o toj vezi, a takvi zapisi nisu ni mogući. Prijenos TCP segmenata između dvaju domaćina izvodi se u IP paketima na mrežnoj razini. Internet radi prema načelu usmjeravanja paketa, tako da u njemu nema stvarnih putova ni veza tipa kraj-kraj (s-kraja-na-kraj). Usmjerivači prenose IP pakete od točke do točke, bez uspostavljanja veza tipa kraj-kraj.

Konkretnu TCP vezu (koja je tipa kraj-kraj) ne čini fizički put između dvaju komunikatora, jer takav put ni ne postoji. TCP vezu čine dva međusobno povezana (uparena) procesa, od kojih se jedan odvija na jednom domaćinu (klijentu) a drugi na drugom domaćinu (serveru). Parametri tih dvaju procesa, koji su određeni kod njihovog pokretanja (to jest, kod uspostavljanja te TCP veze), određuju operativna svojstva TCP veze koju ti procesi tvore i održavaju.

TCP veze su dvosmjerne (full-duplex); to znači da ako postoji TCP veza između procesa P1 i procesa P2 (koji se izvode na međusobno udaljenim domaćinima), onda postoji i TCP veza između procesa P2 i procesa P1. Oba komunikatora koje povezuje jedna TCP veza mogu tom vezom slati sadržaje i primati sadržaje istodobno (paralelno).

TCP veza je veza tipa kraj-kraj (ili s-kraja-na-kraj) jer se ta veza uspostavlja između izvornog pošiljatelja i konačnog primatelja sadržaja u nekoj komunikaciji. TCP veza uspostavlja se između dva komunikatora, ne između grupe komunikatora. To znači da TCP ne omogućava slanje istog sadržaja na više odredišta sa jednom operacijom slanja; dakle, ne podržava multicast način slanja. Isto vrijedi i za IP protokol, na mrežnoj razini Interneta. Zato se za distribuciju radijskih i televizijskih programa, koji koriste multicast prijenos, preko Interneta trebaju tražiti dodatna rješenja (kao nadgradnja TCP/IP sustava), sa kojima se ovdje ne bavimo.

Uzmimo da neki proces na nekom domaćinu hoće uspostaviti TCP vezu sa nekim procesom na nekom drugom domaćinu. Proces koji pokreće postupak uspostavljanja veze naziva se klijentskim procesom; proces sa kojim klijent uspostavlja vezu naziva se serverskim procesom.

Uspostavljanje veze počinje sa nekim događajem u procesu izvođenja neke aplikacije; takav događaj može biti pritisak miša na neku URL adresu na web stranici koju proizvodi preglednik. Taj događaj pokreće izvođenje utičnice (kao klase/procesa) od te aplikacije prema TCP protokolu transportne razine. Utičnica je komunikacijsko sučelje između aplikacije i TCP protokola: utičnica je softverski entitet koji definira i izvodi prijenos sadržaja između aplikacije i TCP protokola.

Klijentski proces (naprimjer, web preglednik) pokreće uspostavu TCP veze izvođenjem određenih operacija koje definira i izvodi njegova utičnica. Programska definicija takve utičnice prema TCP protokolu sadrži stavke slijedećeg oblika:

Socket clientSocket = new Socket ("domaćin", port);

Izvršenjem takvog stavka (iz svoje utičnice prema TCP protokolu) klijent zahtijeva od TCP protokola (na svom domaćinu) da uspostavi TCP vezu sa udaljenim domaćinom čije je ime (adresa) dano parametrom "domaćin", i to sa procesom (na tom domaćinu) koji prima poruke na portu koji je dan parametrom "port".

TCP protokol izvršava taj zahtjev i uspostavlja traženu TCP vezu između klijenta i servera.

27

Na kraju ovog odjeljka iznosimo kraći opis na koji način TCP protokol uspostavlja TCP vezu. Za sada recimo da se proces uspostavljanja TCP veze naziva "rukovanjem u tri koraka" i da se sastoji od slijedeća tri koraka: (1) klijent šalje serveru prvi segment s kojim zahtijeva uspostavu veze; (2) server šalje segment s kojim odgovara na taj zahtjev; (3) klijent šalje segment s kojim odgovara na serverov odgovor.

Time je uspostavljena jedna TCP veza između tog klijenta i tog servera. Klijent i server mogu sad po toj vezi slati podatke jedan drugome. Klijent šalje sadržaje na taj način da ih upisuje u onu instancu svoje utičnice prema TCP protokolu koja je stvorena (kao novi objekt klase Socket) prigodom uspostave te TCP veze. "Upisati u utičnicu" znači upisati u memoriju (bafer) za slanje, koja je dodijeljena toj TCP vezi u postupku njena uspostavljanja.

TCP protokol uzima sadržaje iz tog bafera, dodaje im odgovarajuća TCP zaglavlja i time stvara TCP segmente, koje onda upućuje na njihovo odredište. Na odredištu se ti segmenti zapisuju u memoriju (bafer) za primanje, koja je toj TCP vezi dodijeljena na strani primatelja, kako to ilustrira slika 2.10. TCP protokol upisuje sadržaje segmenata koje prima, u pripadnu instancu utičnice prijemne aplikacije, što znači u prijemni bafer dane TCP veze. Tako sadržaji stižu na aplikaciju kojoj su upućeni.

Svaka strana u svakoj TCP vezi ima svoj bafer za slanje i svoj bafer za primanje. To su memorijski prostori koje TCP protokol dodjeljuje TCP vezi u postupku njena uspostavljanja; prvi prostor (bafer) služi za zapisivanje sadržaja kojeg se tom vezom šalje, a drugi prostor služi za zapisivanje sadržaja kojeg se tom vezom prima.

Slika 2.10 TCP veza: utičnice i baferi

Podsjetimo da prijenos segmenata između bafera za slanje i bafera za primanje nije tako izravan kako to sugerira dana ilustracija. TCP protokol na strani pošiljatelja uzima sadržaje iz bafera za slanje (koje proizvodi aplikacija) i pravi od njih TCP segmente; te segmente onda predaje IP protokolu (mrežnoj razini) ispod sebe.

IP protokol dodaje segmentima svoje zaglavlje i tako pravi IP pakete; te pakete onda predaje razini veze podataka, ispod sebe.

Razina veze podataka dodaje IP paketima svoja zaglavlja i tako proizvodi svoje okvire. Koristeći usluge fizičke razine sustava, razina veze podataka prenosi svoje okvire sa čvora na kojem radi, na susjedni čvor sa kojim je taj čvor izravno povezan (pomoću mrežnih kartica i vodiča).

Kad okviri stignu na mrežnu karticu završnog čvora (domaćina) koji je njihovo konačno

28

odredište, onda se odvija proces koji je obrnut njihovoj tvorbi: iz okvira se vade IP paketi, a iz njih TCP segmenti. TCP protokol zapisuje sadržaje primljenih segmenata u prijemni bafer dane TCP veze. Aplikacija čita sadržaje iz prijemnog bafera svoje TCP veze i time preuzima sadržaje koje joj donosi ta TCP veza.

TCP vezu uspostavlja se pokretanjem procesa kojeg smo nazvali utičnicom. U procesu uspostave TCP veze, toj utičnici dodjeljuje se memorijski prostor u kojeg aplikacija upisuje sadržaje koje treba poslati tom vezom, i memorijski prostor u kojeg TCP protokol upisuje sadržaje koji dolaze tom vezom; takve memorijske prostore naziva se baferima. Bafer često služi za razmjenu sadržaja među procesima: jedan proces upisuje sadržaje u neki bafer, dok drugi proces čita sadržaje iz tog bafera, i na taj način ih preuzima.

Aplikacija "piše u utičnicu" na taj način da upisuje svoje sadržaje u bafer za slanje od pripadne utičnice; TCP protokol preuzima sadržaje iz tog bafera i prenosi ih na njihovo odredište. Aplikacija "čita iz utičnice" na taj način da čita sadržaje iz prijemnog bafera dane utičnice. TCP protokol prima sadržaje koji stižu preko dane TCP veze i upisuje ih u prijemni bafer zadane utičnice. Tako TCP izvodi prijenos za potrebe one aplikacije koja je pokrenula njeno uspostavljanje i stvaranje pripadne utičnice.

Dakle, TCP veza prenosi sadržaje između instance utičnice na domaćinu jednog komunikatora i instance utičnice na domaćinu drugog komunikatora. Pritom, jednu TCP vezu tvore dva procesa koji se izvode na međusobno udaljenim domaćinima na kojima se nalaze krajevi te veze. Svaki od tih procesa obuhvaća nekoliko memorijskih prostora (bafera) i varijabli koje su dio te TCP veze i pripadnih utičnica, i sudjeluju u njenom radu.

Kod tvorbe segmenata često se javljaju dva pojma:- maximum segment size (MSS) - maksimalna veličina segmenta,- maximum transition unit (MTU) - maksimalna jedinica prijenosa (ili prijenosna

jedinica).Naziv MSS označava maksimalnu veličinu tijela segmenta; dakle, maksimalnu količinu

sadržaja koju se može prenijeti u jednom segmentu. Veličinu segmenta dobije se kad se broju MSS doda veličinu zaglavlja segmenta. Zaglavlje UDP segmenta veliko je 8 bajtova, dok je zaglavlje TCP segmenta veliko 20 bajtova.

MTU je veličina tijela okvira (na razini veze podataka) u kojem se prenosi IP paket, u kojem se prenosi segment, u kojem se prenosi sadržaj sa aplikacijske razine. Različiti sustavi veze podataka imaju različite MTU. Naprimjer, ako u nekom sustavu razine veze podataka tijelo okvira može biti veliko do 1500 bajtova, onda je MTU toga sustava 1500 bajtova. Tada je MSS jednako MTU umanjeno za veličinu zaglavlja IP paketa (20 bajtova) i za veličinu zaglavlja TCP segmenta (20 bajtova). Dakle, MSS u tom slučaju iznosi 1460 bajtova. U IP paketu ukupne dužine 1500 bajtova, prenosi se TCP segment ukupne dužine 1480 bajtova, u kojem se prenosi 1460 bajtova korisnog tereta, odnosno sadržaja s aplikacijske razine.

Ako IP paket, krećući se od izvora do odredišta, treba biti prenijet nekom vezom između dva čvora (kao dionicom puta) čiji MTU nije dovoljno velik da IP paket stane u okvire te veze, onda se IP paket dijeli na dva ili više dijelova, i svaki dio prenosi se u zasebnom okviru. Taj proces naziva se fragmentiranjem i opisan je u prethodnoj knjizi.

Struktura TCP segmenta

TCP segment sastoji se od dva osnovna dijela: zaglavlja i tijela. Zaglavlje sadrži brojeve portova i druge upravljačke sadržaje, dok se u tijelo segmenta upisuje podatkovni sadržaj kojeg segment prenosi. Na slici 2.11 dana je struktura TCP segmenta. Hrvatske nazive polja odabrali smo onako kako nam se činilo najbolje; engleski nazivi navedeni su u objašnjenjima koja slijede.

29

Slika 2.11 Struktura TCP segmenta

Segmenti prenose poruke aplikacija; te poruke mogu biti proizvoljne veličine. Veličina segmenta ograničena je veličinom MTU onih veza (sustava veze podataka) preko kojih se taj segment prenosi od pošiljatelja do primatelja. Dakle, količina sadržaja koja se prenosi jednim segmentom određena je sa MTU onih okvira u kojima se prenose IP paketi koji prenose TCP segmente na putu od njihova izvora do njihova odredišta. Tijelo segmenta može biti manje od tako zadane maksimalne veličine; kod aplikacija kao što je Telnet, tijelo segmenta često sadrži samo jedan bajt. Kad prenosi poruke (datoteke) aplikacija, čija je veličina veća od veličine jednog segmenta (od MSS i od MTU), onda TCP protokol prenosi tu poruku po dijelovima, jedan dio za drugim, svaki dio u svom segmentu.

Zaglavlje TCP segmenta veliko je 20 bajtova (kao i zaglavlje IP paketa, verzija 4). Tom zaglavlju mogu se dodati neki opcionalni (neobavezni) upravljački sadržaji, čime se zaglavlje povećava, na račun prostora koji je namijenjen za prijenos podatkovnih sadržaja (kao kod IPv4 paketa).

Na početku segmenta nalazi se 16-bitno polje u koje se upisuje port pošiljatelja (izvora) segmenta; slijedi još jedno takvo polje u koje se upisuje port primatelja (odredišta) segmenta. Portove upisuje TCP protokol koji radi na domaćinu-izvoru segmenata; taj TCP protokol tvori segmente (iz poruka aplikacija) i formira njihova zaglavlja. Proces slanja segmenata nazvali smo multipleksiranjem jer jedan element (TCP protokol) paralelno opslužuje više korisnika njegovih usluga; korisnici su ovdje aplikacije i njihovi prijenosi podataka TCP vezama.

Na domaćinu-odredištu, port služi za demultipleksiranje. To je ovdje proces u kojem TCP protokol prihvaća segmente koji stižu preko mnogo TCP veza i prenosi njihove sadržaje u prijemne bafere tih veza. Demultipleksiranje na domaćinu-primatelju izvodi se prema portu primatelja. Kod TCP sustava, veze su određene sa četvorkama < IP izvora, Port izvora, IP odredišta, Port odredišta >; prva dva parametra određuju jednu stranu TCP veze, a druga dva parametra drugu stranu te veze.

30

Bilo bi dobro koristiti pojmove "izvor" i "odredište" za domaćina sa kojeg je poslan neki sadržaj, odnosno na kojeg je poslan neki sadržaj. Pojmovima "pošiljatelj" i "primatelj" bi se onda označavalo procese (na domaćinima) koji šalju, odnosno primaju sadržaje. Ovdje to vjerojatno nismo činili dosljedno, jer pojmovi "izvor" (source) i "odredište" (destination) prevladavaju svugdje, ali to može otežati razumijevanje nekih objašnjenja.

Jedinice podataka se često prikazuju kao kvadrati; tako je učinjeno i na slici 2.11, ali jedinice podataka su ovdje nizovi bitova. Niz bitova koji tvori jedan segment počinje sa prvim retkom na vrhu slike, i to sa prvim bitom s lijeva u tom retku. Slijede ostali bitovi prvog retka, do zadnjeg bita na desnoj strani toga retka; zatim slijedi prvi bit s lijeva u drugom retku, i tako dalje. Segment završava sa najdonjim retkom (na slici), i to sa zadnjim bitom na desnoj strani toga retka.

Slijede dva 32-bitna polja; prvo od tih polja (Slijedni broj) sadrži slijedni broj ovog segmenta; drugo polje ("Potvrda primitka") sadrži slijedni broj s kojim pošiljatelj ovog segmenta potvrđuje primitak nekog drugog segmenta. U prethodnom odjeljku opisano je na koji način se slijedni brojevi općenito koriste za ostvarenje pouzdanog prijenosa pomoću nepouzdanih usluga prijenosa; u nastavku ovog odjeljka opisano je na koji način se ta polja koriste za ostvarenje pouzdanog prijenosa u konkretnom sustavu TCP.

U polje Dzagl (dužina zaglavlja) zapisuje se broj 32-bitnih riječi od kojih se sastoji zaglavlje segmenta. Ako zaglavlje nema opcionalnih stavaka, onda u tom polju piše 5, jer zaglavlje ima 5 riječi od 4 bajta, odnosno ukupno 20 bajtova. Ako zaglavlje sadrži i neke opcionalne stavke, onda se to vidi po tome što polje Dzagl sadrži vrijednost koja je veća od 5. Opcionalni stavci (naredbe i podaci) mogu se koristiti za neka specifična "dogovaranja" između pošiljatelja i primatelja poruka (oko veličine poruka i sličnih stvari), ali se u praksi opcionalni stavci obično ne koriste.

Slijedi jedno polje koje se ne koristi (Prazno). Nakon tog polja slijedi 6-bitno polje oznaka (flag field). Vrijednost svakog od tih bitova-oznaka (0 ili 1) ukazuje na neko stanje, koje je dodatno definirano drugdje.

Prvi bit-oznaka URG pokazuje da li se na početku tijela ovog segmenta nalazi neki sadržaj kojeg je aplikacija-pošiljatelj označila kao "urgentan". Kad je bit URG postavljen na "1", onda polje Urgentni podaci sadrži pokazatelja (pointer) na zadnji bajt onog sadržaja kojeg je pošiljatelj označio kao urgentnog. Dakle, taj sadržaj počinje od prvog bajta tijela segmenta i ide do onog bajta čija je pozicija (redni broj) zadana (pointerom) u polju Urgentni podaci. TCP protokol na prijemnoj strani skida i troši TCP zaglavlje, a u prijemni bafer veze (i aplikacije) zapisuje samo sadržaj iz tijela segmenta. Zato u slučaju kad u tijelu segmenta postoji urgentni sadržaj, TCP protokol treba obavijestiti o tome pripadnu aplikaciju i predati toj aplikaciji vrijednost polja koje pokazuje na završetak urgentnog sadržaja. Spomenimo da se opcija URG u praksi ne koristi; to znači da je vrijednost bita-oznake redovito "0", čime i vrijednost u polju "Urgentni podaci" postaje nevažna.

Svaki TCP segment ima polje "Potvrda primitka" (Acknowledgment number) u kojem se nalazi neki niz bitova. Ali komunikatori mogu slati segmente s podacima, bez da sa tim segmentima išta potvrđuju. Zato je potrebna oznaka (jedno-bitno polje) ACK sa kojom pošiljatelj segmenta javlja primatelju toga segmenta da li se sa tim segmentom ujedno potvrđuje primitak nekog drugog segmenta: to jest, da li je sadržaj polja "Potvrda primitka" slijedni broj nekog segmenta.

Ako je vrijednost polja ACK jednaka "1", onda to znači da je vrijednost u polju "Potvrda primitka" slijedni broj s kojim se potvrđuje primitak nekog segmenta. Ako je vrijednost polja ACK jednaka "0", onda se vrijednost u polju "Potvrda primitka" zanemaruje, jer (slučajni) niz bitova u tom polju nije slijedni broj s kojim se potvrđuje primitak nekog segmenta. Kod TCP protokola, u segmentu kojeg primatelj B šalje pošiljatelju A, B navodi slijedni broj slijedećeg segmenta kojeg očekuje od A. Time B potvrđuje da je primio (od A) onaj segment koji prethodi onom segmentu čiji slijedni broj navodi, i kojeg očekuje kao slijedećeg.

31

Postavljanjem bita PSH (push; gurnuti) na vrijednost "1" TCP na strani pošiljatelja poručuje TCPu na strani primatelja da sadržaj tog segmenta treba odmah predati aplikaciji kojoj je upućen. U praksi se opcija PSH uglavnom ne koristi, kao ni opcija URG koju smo opisali iznad.

Bitovi-oznake RST, SYN i FIN koriste se u procesu uspostavljanja i prekidanja TCP veze; o tome govorimo kasnije.

Polje Prijemni prozor (receive window) sadrži 16-bitni broj koji kazuje koliko bajtova može trenutno primiti pošiljatelj ovog TCP segmenta (to jest, primatelj sadržaja). Vrijednost tog polja ("veličina prozora za primanje") služi pošiljatelju za to da prilagodi intenzitet svog slanja i da ne zatrpa primatelja, jer takvo zatrpavanje dovodi do odbacivanja segmenata (IP paketa) koje primatelj trenutno nije u mogućnosti primiti. O tome govorimo kasnije.

Polje Kontrolni zapis (Internet checksum) sadrži jedan niz od 16 bitova koji je izveden (izračunat) iz sadržaja danog segmenta. Taj zapis omogućava primatelju da utvrdi da li je u procesu prijenosa tog segmenta došlo do iskrivljenja njegovog sadržaja.

TCP protokol promatra sadržaj kojeg prima od aplikacije kao niz bajtova. TCP protokol tvori TCP segmente iz tog niza bajtova; pritom svakom segmentu dodjeljuje kao slijedni broj onu vrijednost koja je jednaka poziciji (rednom broju) prvog bajta iz tog segmenta u (većem) nizu bajtova koje proizvodi aplikacija i koje njena TCP veza prenosi na odredište.

Ilustrirajmo to primjerom; uzmimo da aplikacijski proces na domaćinu A šalje 400 000 bajtova aplikacijskom procesu na domaćinu B; neka pritom MSS za TCP vezu između tih dvaju procesa bude 1000 bajtova. Ako prvom bajtu u nizu od 400 tisuća bajtova dodijelimo redni broj 0, onda će slijedni broj prvog TCP segmenta biti redni broj njegovog prvog bajta: dakle, 0.

Prvi segment prenosi (u tijelu) 1000 bajtova; dakle, bajtove čiji redni brojevi idu od 0 do 999. To znači da će redni broj prvog bajta drugog segmenta biti 1000; tada će i slijedni broj drugog segmenta biti 1000. Slijedni broj trećeg segmenta biti će 2000, i tako redom dok se ne prenese sav sadržaj od 400 000 bajtova koje treba prenijeti; slijedni broj zadnjeg segmenta u tom prijenosu biti će 399 000.

Slijedni broj segmenta upisuje se u polje "Slijedni broj" (od 32 bita) u zaglavlju tog segmenta. Primatelj B potvrđuje primitak prvog segmenta na taj način da pošalje svoj segment pošiljatelju A, pri čemu u polje "Potvrda primitka" tog segmenta upisuje slijedni broj segmenta kojeg očekuje (od A) kao slijedećeg. U danom primjeru, B će potvrditi primitak prvog segmenta tako, da pošiljatelju A pošalje segment u čijem će polju "Potvrda primitka" biti upisano "1000", a vrijednost bita-oznake ACK biti će postavljena na "1", kako je to objašnjeno iznad. Na taj način primatelj B potvrđuje primitak segmenata koje prima preko TCP veze.

TCP veza je dvosmjerna (full-duplex), tako da procesi A i B mogu istodobno slati sadržaje (segmente) jedan drugom i primati segmente jedan od drugog. Slijedni brojevi segmenata koje A šalje Bu su nezavisni od slijednih brojeva segmenata koje B šalje Au; pritom numeracija bajtova obično ne počinje od 0, tako da ni slijedni brojevi ne počinju od 0.

Ako se prijenos između A i B odvija u oba smjera, onda A može u svojim segmentima koje šalje Bu, slati potvrde primitka segmenata koje A dobiva od Ba; na isti način B potvrđuje primitak segmenata od A. Dakle, B može slati povratne potvrde Au (o primitku segmenata) u zasebnim segmentima (koji ne prenose podatkovni sadržaj), ali takve potvrde može slati i u segmentima koji sadrže podatkovne sadržaje koje B šalje Au.

Kod TCP protokola primatelj potvrđuje primitak segmenta na taj način da pošiljatelju pošalje (u polju "Potvrda primitka" svog segmenta) redni broj bajta kojeg očekuje kao slijedećeg; s obzirom na opisani način numeriranja segmenata, to je ujedno slijedni broj slijedećeg segmenta kojeg primatelj očekuje.

Opisali smo na koji način TCP računa (dodjeljuje) slijedne brojeve segmentima na strani pošiljatelja i na koji način primatelj potvrđuje primitak tih segmenata. U specifikaciji TCP

32

protokola (koja je sadržana u više RFCa) nije striktno određeno (predpisano) na koji način treba TCP postupati kod iskrivljenja i gubitaka segmenata, te u situaciji kad primatelju stižu ispravni segmenti izvan redoslijeda. Kako je to ranije rečeno, postoje dvije osnovne mogućnosti: (1) da primatelj odbacuje sve segmente dok ne primi (u ispravnom stanju) onaj segment koji treba stići slijedeći po redu, i (2) da primatelj pohranjuje ispravne segmente koje prima izvan redoslijeda, te da načinom potvrđivanja primitka segmenata daje pošiljatelju do znanja koji mu segment nedostaje u nizu. Pošiljatelj treba i bez takvih "poticanja" ponovno poslati segment za kojeg nije primio potvrdu o primitku, nakon što istekne tajmer za taj segment.

Prva metoda rada je procesno jednostavnija za TCP sustav, ali kod te metode odbacuju se ispravno prenijeti segmenti, čiji prijenos treba kasnije ponoviti (što nije dobro). Kod druge metode, implementacija TCP protokola je procesno složenija na strani pošiljatelja i na strani primatelja, ali se kod te metode ne odbacuje segmente koji su prenijeti u ispravnom stanju. RFCi sa kojima je definiran TCP protokol ne određuju koju od tih dviju metoda treba usvojiti (i implementirati). U praksi, u implementaciji TCP protokola koristi se drugu metodu; dakle, pohranjuje se ispravne segmente koji su primljeni izvan redoslijeda. Kod ovakvog načina rada ne troše se prijenosni kapaciteti mreže na nepotrebno ponavljanje prijenosa segmenata.

Procjenjivanje vrijednosti tajmera

Protokol TCP ostvaruje pouzdan prijenos na taj način što ponavlja slanje onih segmenata koji su iskrivljeni ili izgubljeni na putu. Slanje segmenta ponavlja se kad istekne vrijeme (tajmer) u kojem se smatra da pošiljatelju treba stići povratna potvrda kojom primatelj potvrđuje da je primio segment u ispravnom stanju. Postavlja se pitanje na temelju čega i kako treba odrediti prikladno vrijeme čekanja na povratnu potvrdu o primitku, prije ponovnog slanja nekog segmenta; dakle, kako odrediti pravo vrijeme na tajmeru (odbrojaču).

Prekratko vrijeme čekanja dovodilo bi do velikog broja ponovljenih slanja koja nisu bila potrebna; događalo bi se da povratna potvrda o primitku segmenta stigne malo nakon što je segment proglašen izgubljenim i poslan ponovno. Preveliko vrijeme čekanja na potvrdu o primitku usporava prijenos. Kad je neki segment zaista iskrivljen ili izgubljen u prijenosu, onda za njega neće stići potvrda o primitku; ako pošiljatelj dugo čeka prije njegovog ponovnog slanja, onda će proći dugo vremena dok se taj segment uspješno prenese primatelju (i dok o tome stigne povratna potvrda pošiljatelju). Dok pošiljatelj ne primi potvrdu da je taj problematični segment uspješno prenijet primatelju, pošiljatelj ne može pomaknuti dalje svoj klizni prozor; to praktički znači da ne može slati nove segmente. Najstariji (najranije poslani) nepotvrđeni segment čini donju granicu prozora za slanje; time taj segment određuje i poziciju gornje granice toga prozora, a time i broj novih segmenata koje pošiljatelj smije poslati u nekom trenutku.

Vrijeme čekanja izračunava se na temelju povremenih mjerenja konkretnih vremena povratnog puta (round-trip time - RTT). Takva mjerenja izvode se za svaku TCP vezu posebno, za konkretan prijenos segmenata koji se prenose tom vezom u danom trenutku. RTT je općenito različit u različitim vezama, ali RTT varira s vremenom u istoj vezi, u zavisnosti od trenutnog opterećenja fizičkih veza i usmjerivača preko kojih ta logička veza (logički kanal) prolazi.

Vrijeme čekanja (timeout) na potvrdu primitka segmenta (prije njegovog ponovnog slanja) treba biti nešto veće nego što iznosi izmjereno RTT, jer bi u suprotnom bilo puno nepotrebnih ponavljanja slanja. Pitanje je koliko veće treba biti to vrijeme. U nastavku iznosimo nekoliko formula prema kojima TCP protokol izračunava vrijeme čekanja na potvrdu primitka segmenta, prije nego ponovi slanje toga segmenta.

RTT i optimalno vrijeme čekanja na potvrdu primitka različiti su za svaku TCP vezu; to znači da TCP protokol izvodi proces izračunavanja tih vrijednosti za svaku TCP vezu posebno, i taj proces izvodi kontinuirano jer se stanje mreže mijenja. U nastavku opisujemo proces izračunavanja vremena čekanja koje se smatra optimalnim, a time i vrijednosti tajmera za TCP

33

veze.

Kod uspostavljanja TCP veze, TCP protokol uzima neku procijenjenu vrijednost RTT za tu TCP vezu; označimo to vrijeme sa ProcRTT te veze u tom trenutku. Svakih nekoliko ProcRTT sekundi, TCP mjeri vrijeme koje je proteklo od trenutka kad je jedan segment predan mrežnom sloju (IP) za prijenos, do trenutka kad je pošiljatelj primio povratnu potvrdu (od primatelja) o primitku toga segmenta. To izmjereno vrijeme uzima se kao trenutni konkretni RTT za danu vezu; označimo to vrijeme sa UzorakRTT. Veličina takvih uzoraka (trenutnih RTT) varira s vremenom (za istu TCP vezu), u zavisnosti od trenutne opterećenosti usmjerivača i veza preko kojih se odvija fizički prijenos sadržaja u toj TCP vezi (kao jednom logičkom kanalu). RTT zavisi i od trenutne opterećenosti domaćina na kojima rade procesi aplikacijske razine za koje se izvodi prijenos TCP vezom na transportnoj razini.

Na temelju trenutne vrijednosti ProcRTT i izmjerene vrijednosti UzorakRTT, TCP protokol izračunava novu vrijednost ProcRTT prema slijedećoj formuli.

ProcRTT <= (1 - a) x ProcRTT + a x UzorakRTT

Pritom se za vrijednost parametra a uzima 1/8, odnosno 0.125; tada gornja formula glasi:

ProcRTT <= 0,875 x ProcRTT + 0,125 x UzorakRTT

Dakle, nova vrijednost ProcRTT iznosi 87,5% prethodne vrijednosti ProcRTT, plus 12,5% zadnje izmjerene vrijednosti RTT. Ovakvim načinom računanja postiže se da nove (izmjerene) vrijednosti RTT stalno mijenjaju veličinu procijenjene (očekivane) veličine RTT, ali te promjene nisu jako skokovite, jer novu procijenjenu vrijednost RTT čini 87,5% od prethodne vrijednosti, a samo 12,5% od trenutno izmjerene vrijednosti.

Na slici 2.12 dan je jedan ilustrativni grafički prikaz kretanja veličina izmjerenih uzoraka RTT i veličina procijenjenih RTT.

34

Slika 2.12 Mjereni i procijenjeni RTT

Pored kontinuiranog mjerenja i izračunavanja procijenjene vrijednosti RTT, prati se i varijabilnost (veličinu promjenljivosti) od RTT. To je veličina uobičajenog (ili očekivanog) odstupanja vrijednosti uzoraka RTT od procijenjenih vrijednosti RTT. Ta veličina (ili mjera) odstupanja, označimo je sa DevRTT, izračunava se prema formuli:

DevRTT <= (1 - b) x DevRTT + b x aps(ProcRTT - UzorakRTT)

Pritom se za vrijednost parametra b uzima 0,25. Dakle, nova vrijednost veličine odstupanja jednaka je 75% od prethodne vrijednosti, plus 25% razlike između trenutne procijenjene vrijednosti RTT i vrijednosti najnovijeg izmjerenog uzorka RTT. Pritom se tu razliku uzima u apsolutnoj vrijednosti (bez predznaka, odnosno kao pozitivnu vrijednost).

Ako je vrijednost RTT relativno stabilna, onda će razlike između procijenjenih RTT i izmjerenih RTT (uzorka) biti male; tada će i vrijednosti DevRTT biti relativno male. S druge strane, ako vrijednosti uzoraka RTT jako variraju, onda će razlike između procijenjenih i izmjerenih vrijednosti RTT biti velike, čime će i vrijednosti DevRTT postati velike.

Na temelju procijenjene vrijednosti RTT (ProcRTT) i veličine odstupanja RTT od procijenjene vrijednosti (DevRTT), TCP protokol izračunava vrijeme čekanja na povratnu potvrdu primitka segmenta prema slijedećoj formuli:

VrijemeCekanja = ProcRTT + 4 DevRTT

Vrijeme čekanja na povratnu potvrdu (od primatelja) o primitku segmenta naziva se "timeout interval"; to je "vrijeme odbrojavanja", odnosno vrijeme isteka tajmera, nakon kojeg pošiljatelj proglašava segment izgubljenim i ponavlja njegovo slanje.

Vrijeme čekanja na povratnu potvrdu u TCP sustavu treba biti veliko barem onoliko koliko iznosi trenutno procijenjeno vrijeme povratnog puta za tu vezu (ProcRTT). Ali taj iznos treba uvećati jer stvarno RTT varira u odnosu na procijenjeno RTT, tako da neke povratne potvrde ne stižu u tom vremenu. Prema danoj formuli, taj iznos uvećava se za četiri vrijednosti trenutne veličine odstupanja (ili promjenljivosti) RTTa, to jest za četiri DevRTT.

Takve formule zasnivaju se na iskustvu, promatranju i mjerenju, tako da se s vremenom mogu mijenjati. To se ovdje može lako učiniti odabirom drugih vrijednosti faktora a i b, kao i odabirom neke druge vrijednosti umjesto faktora 4.

Odbrojavanje i potvrđivanje primitka

Prijenos IP paketa na mrežnoj razini Interneta je nepouzdan; TCP protokol oblikovan je na način da koristeći nepouzdane usluge prijenosa sa mrežne razine (ispod sebe), ostvaruje pouzdane usluge prijenosa za sustave aplikacijske razine (iznad sebe). TCP protokol ostvaruje svoj zadatak pouzdanog prijenosa uz pomoć nepouzdanih usluga koristeći elemente i metode rada koje smo opisali u prethodnom odjeljku.

TCP sadrži elemente za otkrivanje grešaka u prijenosu; takve greške mogu biti iskrivljenje i gubitak bitova segmenta, gubitak cijelog segmenta, i dolazak segmenata na odredište u krivom redoslijedu (u odnosu na njihovo polazno uređenje).

TCP protokol definira metodu otklanjanja otkrivenih grešaka, i to ponavljanjem slanja onih segmenata u čijem je prijenosu došlo do greške. O načinu ostvarivanja pouzdanog prijenosa pomoću nepouzdanih usluga mrežne razine govorili smo u prethodnom odjeljku; u nastavku ovog odjeljka iznosimo neka specifična rješenja koja se koriste kod TCP protokola. Neka od tih rješenja

35

određena su sa RFCima sa kojima je definiran TCP protokol, ali opisi u RFCima ponekad ostavljaju mogućnost da se neke stvari odaberu i oblikuju na razini implementacije TCP protokola, kao jednog konkretnog softverskog elementa računalne mreže.

Za precizan rad s vremenom (odbrojavanjem), trebalo bi da svaki TCP segment kojeg se predaje mrežnoj razini za prijenos, pokreće svoj tajmer (vremenski odbrojač). Tajmer za dani TCP segment pokreće se kod predavanja tog segmenta IP (mrežnoj) razini; tajmer se zaustavlja kad pošiljatelj segmenta primi povratnu potvrdu od primatelja da je taj segment primio u ispravnom stanju. Ako takva potvrda ne stigne do isteka tajmera za taj segment, onda pošiljatelj uzima da je taj segment izgubljen na putu i šalje taj segment ponovno.

Procesno je mnogo jednostavnije koristiti samo jedan tajmer za sve poslane segmente; RFC 2988 preporuča da se tako učini; kod implementacije TCP protokola je tako i učinjeno. Uz jedan tajmer često ima mnogo poslanih segmenata čiji primitak još nije potvrđen; tada se uzima da se taj tajmer odnosi na onaj segment koji je poslan prvi u nizu poslanih segmenata čiji primitak nije još potvrđen. Ako tajmer istekne, onda se ponavlja slanje tog (najranije poslanog) segmenta, koji ujedno "drži" donju stranu kliznog prozora i ne dopušta da se taj prozor pomakne naprijed.

Kad tajmer istekne, TCP protokol ponavlja slanje najstarijeg nepotvrđenog segmenta i pokreće tajmer iz početka. U nastavku ćemo vidjeti da kod isteka tajmera, TCP ujedno povećava (udvostručuje) vrijeme čekanja (timeout interval), koje se računa prema formulama koje smo iznijeli iznad. Dakle, izračunato vrijeme čekanja koristi se dok se ne pojavi problem kao što je gubitak segmenta, gubitak povratne potvrde, ili istek tajmera zbog kašnjenja. Kad se dogodi nešto od toga, onda se vrijednost vremena čekanja (ili polazna vrijednost tajmera) udvostručava. U opisima koji slijede, ponavljaju se neke stvari koje su rečene u prethodnom odjeljku; to je zato što se tamo govorilo o načelima rada na temelju kojih se ostvaruje pouzdan prijenos, a ovdje govorimo kako su ta načela primijenjena u protokolu TCP.

Ponašanje pošiljatelja određuju tri osnovne vrste događaja: (1) primitak sadržaja od aplikacije, (2) istek tajmera, i (3) primitak potvrde (od primatelja) o primitku poslanog segmenta.

Kod primitka sadržaja od aplikacije, TCP protokol tvori segmente (od tog sadržaja), dodjeljuje im slijedne brojeve, i predaje te segmente mrežnom sloju (IP protokolu) ispod sebe. Ako tajmer nije već uključen (kod slanja nekog ranijeg segmenta), onda TCP ujedno pokreće tajmer.

TCP koristi jedan tajmer (a ne poseban tajmer za svaki segment); odbrojavanje na tajmeru počinje od vrijednosti VrijemeCekanja, koja se periodički izračunava prema formulama koje smo iznijeli iznad. Vrijeme čekanja izračunava se na temelju trenutne procijenjene vrijednosti RTT i na temelju varijacije izmjerenih uzoraka RTT, kako je to opisano ranije.

Drugi događaj koji pokreće akciju TCP protokola je istek tajmera. Kod isteka tajmera, TCP ponavlja slanje najstarijeg poslanog segmenta za kojeg nije primio potvrdu o njegovu primitku; to je onaj segment koji je najranije poslan i koji određuje donju granicu kliznog prozora za slanje na pošiljatelju. TCP tada ujedno pokreće tajmer iz početka.

Treća vrsta događaja na TCP pošiljatelju je primitak potvrde o ispravom primitku nekog poslanog segmenta; takvu potvrdu označava se sa ACK (acknowledgment = priznanje; potvrda primitka). TCP pošiljatelja sadrži slijedni broj najstarijeg poslanog segmenta čiji primitak nije potvrđen; uzmimo da je taj slijedni broj zapisan u varijabli SendBase. Ako primljeni ACK potvrđuje primitak tog (najstarijeg) segmenta, onda TCP protokol mijenja vrijednost varijable SendBase: vrijednost te varijable postaje slijedni broj novog najstarijeg segmenta čiju potvrdu primitka (ACK) pošiljatelj sad očekuje.

TCP koristi metodu kumulativnog potvrđivanja. To znači da ako neki ACK potvrđuje primitak nekog segmenta koji je poslan nakon onog segmenta čiji je slijedni broj zapisan u varijabli SendBase, onda taj ACK potvrđuje primitak svih segmenata koji su poslani prije onog segmenta čiji primitak izravno potvrđuje taj ACK. Dakle, takav ACK potvrđuje i primitak segmenta čiji slijedni broj je zapisan u SendBase. Tada TCP pošiljatelja mijenja vrijednost varijable u SendBase u skladu sa primljenim ACK i pokreće tajmer iz početka (ako ima još poslanih segmenata čiji primitak nije

36

potvrđen).

Kod TCP protokola slijedni broj segmenta je redni broj prvog bajta u tom segmentu, u izvornom nizu bajtova koji dolaze od aplikacije. Primatelj potvrđuje primitak segmenta na taj način da u svom segmentu (kojim potvrđuje primitak) navede redni broj bajta (u izvornom nizu) kojeg očekuje kao slijedećeg. S obzirom na način kako TCP dodjeljuje slijedne brojeve segmentima (kojeg smo opisali ranije), to je ujedno slijedni broj slijedećeg segmenta kojeg primatelj očekuje.

Naprimjer, ako u varijabli SendBase stoji vrijednost 1000, to znači: (1) da je primatelj ranije potvrdio primitak prvih 1000 bajtova (od 0 do 999), i da (2) najstariji poslani (nepotvrđeni) segment počinje sa bajtom broj 1000, tako da mu pripada slijedni broj 1000. Ako je taj segment imao tisuću bajtova (od 1000 do 1999), onda primatelj potvrđuje primitak tog segmenta na taj način da pošalje ACK sa slijednim brojem 2000. To je redni broj slijedećeg bajta (u nizu) kojeg očekuje, i slijedni broj segmenta kojeg očekuje; time primatelj potvrđuje primitak svih bajtova (i segmenata) do onih čiji redni i slijedni broj navodi u svom ACK segmentu.

Po primitku ACKa sa vrijednošću slijednog broja 2000, TCP pošiljatelja postavlja vrijednost SendBase na 2000, ako je već poslao segment 2000; ako ga nije još poslao, onda će vrijednost SendBase postaviti na 2000 kad pošalje segment sa tim slijednim brojem.

Ako primatelj kumulativno potvrdi primitak većeg broja segmenata, onda pošiljatelj mijenja vrijednost varijable SendBase u skladu sa tom kumulativnom potvrdom. Primatelj potvrđuje primitak većeg broja segmenata na taj način da potvrdi primitak zadnjeg segmenta u neprekinutom nizu; to čini navođenjem (u ACK) rednog broja onog bajta kojeg očekuje slijedećeg. To je ujedno redni broj prvog bajta slijedećeg segmenta i slijedni broj slijedećeg segmenta kojeg očekuje. Time primatelj potvrđuje primitak svih segmenata do onog kojeg očekuje.

Primatelj može slati pošiljatelju potvrde o primitku segmenata (ACK) u posebnim segmentima; tada u polje "Potvrda primitka" takvog segmenta upisuje slijedni broj onog segmenta čiji primitak potvrđuje; dakle, upisuje slijedni broj segmenta kojeg očekuje kao slijedećeg. U segmentu s kojim se potvrđuje primitak segmenta, bit-oznaka ACK treba imati vrijednost "1"; time se pokazuje da polje "Potvrda primitka" sadrži slijedni broj segmenta čiji se primitak potvrđuje.

TCP veze su dvosmjerne, tako da kad A šalje segmente Bu, B može istodobno slati segmente Au. Tada B može u svojim segmentima koje šalje Au ujedno potvrđivati primitke segmenata koje A šalje Bu; isto tako, A može u svojim segmentima potvrđivati primitke segmenata od Ba. Na taj način se u segmentima šalju podatkovni sadržaji i potvrde primitaka segmenata od druge strane u komunikaciji.

Ako se za neki segment izgubi potvrda o njegovu primitku (ACK), onda po isteku tajmera, pošiljatelj šalje taj segment ponovno. Tako se događa da primatelj primi isti segment (i isti sadržaj) dva puta. Na temelju slijednog broja segmenta, primatelj utvrđuje da je taj segment već primio i da je potvrdio njegov primitak. Zato primatelj odbacuje taj segment, jer ne bi valjalo predavati aplikaciji dvostruke sadržaje. Ali primatelj ponovno šalje potvrdu o primitku tog (ponovljenog) segmenta pošiljatelju. Jer iz toga što je pošiljatelj ponovio slanje segmenta, primatelj zaključuje da pošiljatelj nije primio prethodnu potvrdu (ACK) o primitku tog segmenta; zato pošiljatelj šalje tu potvrdu ponovno.

U literaturi se koriste izrazi kao što je "mnoge implementacije TCP protokola"; to znači da ima više implementacija toga protokola koje nisu sasvim jednake. TCP specifikacije (dane u RFCima) definiraju središnje elemente (strukture podataka i procese) toga protokola, ali neke pojedinosti nisu sasvim precizno određene, tako da se kod implementacije (programske realizacije) mogu odabrati različite mogućnosti, bez da se time ugrozi međusobnu kompatibilnost tih implementacija.

Kod većine implementacija TCP protokola, vrijeme čekanja izračunava se prema formulama koje smo iznijeli iznad; to vrijeme postavlja se kao polazno vrijeme tajmera od kojeg

37

počinje odbrojavanje. Kada se dogodi da tajmer istekne (padne na vrijednost 0, a očekivani ACK nije stigao), onda TCP ponavlja slanje najstarijeg segmenta čiji primitak nije potvrđen; pritom TCP pokreće tajmer iz početka, ali sada postavlja dvostruko vrijeme čekanja od trenutnog vremena čekanja s kojim je bio pokrenut tajmer koji je istekao. Naprimjer, ako je izračunato vrijeme čekanja (vrijednost od VrijemeCekanja) sa kojim je bio pokrenut tajmer koji je istekao iznosilo 1 sekundu, kod ponovnog slanja segmenta tajmer se pokreće sa vrijednošću (vremenom čekanja) od 2 sekunde. Ako tajmer ponovno istekne bez da stigne očekivani ACK od primatelja, onda se vrijeme čekanja (polazna vrijednost tajmera) opet udvostručava i postaje 4 sekunde. I tako sve dok se ne postigne slijedeće: (1) segment je prenijet primatelju u ispravnom stanju, (2) pošiljatelj je primio potvrdu (ACK) o primitku toga segmenta, i (3) tajmer nije istekao. Tada se vrijeme čekanja (kao polazna vrijednost tajmera) opet računa prema formulama koje smo iznijeli ranije.

Dakle, vrijeme čekanja računa se prema danim formulama onda kad se prijenos odvija uspješno (bez gubitaka segmenata i/ili kašnjenja potvrda ACK). Ako se dogode gubici ili kašnjenja, onda se vrijeme čekanja udvostručava sve dok se problem ne riješi; zatim se od tako dosegnutog vremena čekanja pokreće novi ciklus računanja na način kako je to opisano ranije. Prema danim formulama računa se vrijeme čekanja i na početku slanja (rada dane veze), sve dok se ne dogodi prvo istjecanje tajmera (zbog gubitaka i/ili kašnjenja).

Udvostručavanjem vremena čekanja nakon isteka tajmera, TCP pošiljatelja usporava slanje i time štiti mrežu (usmjerivače) od zagušenja. Gubici IP paketa na putu i kašnjenja odgovora o primitku segmenata koje oni prenose, obično se događaju zato što su neki usmjerivači preko kojih prolazi dana komunikacija preopterećeni. To znači da se na njima stvaraju dugi redovi IP paketa koji trebaju biti proslijeđeni prema njihovom odredištu, što povećava vrijeme zadržavanja (kašnjenja) paketa na putu. Ako je prijemna memorija usmjerivača sasvim ispunjena u trenutku dolaska IP paketa, onda taj paket biva odbačen na tom usmjerivaču. Putovanje tog paketa je time završeno; taj paket je time izgubljen i pošiljatelj ga treba poslati ponovno.

Ponavljanje slanja IP paketa preko zagušenih usmjerivača ne pomaže puno: paketi će vjerojatno biti opet odbačeni na nekom od usmjerivača. Zbog toga TCP protokol udvostručava vrijeme čekanja na odgovor (to jest, polazno vrijeme tajmera), čime ujedno prepolovljuje intenzitet svog slanja. Ako svi pošiljatelji postupaju na takav način, onda time smanjuju pritisak na usmjerivače, daju im mogućnost da prosljeđuju pakete bez odbacivanja i bez velikih zadržavanja. Time pošiljatelji ujedno povećavaju izglede da njihovi paketi budu uspješno prenijeti na odredište, te da povratne potvrde o tom prijenosu (ACK) stižu do pošiljatelja u zadanom vremenu (prije isteka tajmera).

Ranije smo rekli da protokol UDP ne vodi računa o zagušenju mreže (usmjerivača i/ili primatelja), što dovodi u nepovoljan položaj prijenose koji koriste TCP protokol. O pitanjima upravljanja intenzitetom prijenosa i izbjegavanja zagušenja mreže govorimo u slijedeća dva odjeljka ovog poglavlja.

Ubrzano ponavljanje slanja

Protokol TCP sadrži jednu metodu (proceduru) koja pošiljatelju omogućava da ponovi slanje izgubljenog segmenta prije nego istekne vrijeme čekanja (na tajmeru) na dolazak povratne potvrde (ACK) za taj segment. Takvo ubrzano ponavljanje slanja (fast retransmit) odvija se na slijedeći način.

Kad primatelj primi segment čiji slijedni broj je veći od onog kojeg primatelj očekuje (s obzirom na prethodni slijedni broj), onda primatelj zaključuje da je onaj segment kojeg je očekivao izgubljen na putu. Time je na primatelju nastala "rupa" (praznina) u nizu segmenata koje je primio. Primatelj tada ponavlja potvrdu primitka zadnjeg segmenta kojeg je primio u neprekinutom nizu, prije praznine koju je stvorio dolazak segmenta izvan redoslijeda. Primatelj je ranije već potvrdio primitak tog segmenta; ponavljanjem potvrde primitka tog segmenta primatelj javlja

38

pošiljatelju koji segment treba poslati ponovno.Bez obzira hoće li primatelj odbaciti segment kojeg je primio izvan redoslijeda, ili će taj

segment zadržati (pohraniti ga dok se niz ne popuni), onaj segment koji nedostaje u nizu treba poslati ponovno. Ponovnim slanjem potvrde ACK za segment koji mu prethodi, primatelj poziva pošiljatelja da to slanje ponovi odmah, bez čekanja na istek tajmera.

Pošiljatelj obično šalje veći broj segmenata jednog za drugim, bez da čeka na potvrde o njihovom primitku. Ako se jedan segment u takvom nizu poslanih segmenata izgubi, primatelj prima veći broj segmenata nakon praznine koja je nastala zbog gubitka jednog segmenta. Kod primitka svakog od tih segmenata, pošiljatelj šalje potvrdu (ACK) o primitku onog segmenta koji neposredno prethodi praznini u nizu segmenata koje je primatelj primio. Kad pošiljatelj primi tri ponovljene potvrde (to znači, četiri uzastopne potvrde) primitka segmenta n, onda smjesta ponavlja slanje segmenta n+1, bez obzira što njegovo vrijeme čekanja (tajmer) još nije isteklo.

Ponavljanje slanja koje se odvija prema opisanoj proceduri naziva se ubrzanim ponavljanjem, zato što se izvodi prije isteka vremena čekanja (tajmera) na pošiljatelju. Slika 2.13 ilustrira proces ubrzanog ponavljanja slanja, kojeg smo ovdje opisali. Uzgred, opisana metoda je zanimljiva, ali čini se neobičnim da pošiljatelj uspijeva poslati nekoliko segmenata (nakon onog izgubljenog) i primiti nekoliko ponovljenih potvrda (ACK) kao odgovore na te segmente, prije isteka tajmera. Da bi se to dogodilo, tajmer treba biti postavljen prilično (pre)visoko.

Slika 2.13 Ubrzano ponavljanje slanja segmenata

39

TCP protokol ne potvrđuje primitak onih segmenata koje prima izvan redoslijeda; dakle, onih ispred kojih postoji neka praznina u nizu. Umjesto tih segmenata, TCP ponavlja potvrdu primitka zadnjeg segmenta kojeg je primio u nizu; to jest, zadnjeg segmenta prije praznine.

Specifikacija TCP protokola (dana sa RFCima) ne određuje striktno što treba učiniti sa segmentima koje primatelj primi nakon nekog segmenta koji mu nedostaje (u nizu). Uzmimo da implementacija TCP protokola pohranjuje takve segmente; kad pošiljatelj dostavi onaj segment koji nedostaje u nizu, tada niz postaje popunjen (neprekinut). Primatelj tada potvrđuje primitak zadnjeg segmenta u tom nizu, čime ujedno potvrđuje (kumulativno) i primitak svih segmenata koji prethode tom segmentu. Takav način rada značio bi da je TCP implementiran tako, da radi po metodi selektivnog ponavljanja slanja. Kod te metode, ponavlja se slanje samo onih segmenata koji nisu uspješno prenijeti; segmenti koji su uspješno prenijeti izvan redoslijeda, pohranjuju se na primatelju i njihov prijenos se ne ponavlja.

Protokoli i implementacije razvijaju se i dorađuju prema iskustvima u njihovoj primjeni i prema razvoju novih tehnoloških mogućnosti. Naprimjer, postoje preporuke da primatelj ne šalje potvrdu o primitku (ACK) odmah za svaki primljeni segment. Umjesto toga, primatelj može sačekati (naprimjer 0,5 sekundi) jer u tom vremenu može primiti od pošiljatelja još nekoliko segmenata; tada potvrdom zadnjeg primljenog segmenta u tom nizu, kumulativno potvrđuje primitak cijelog niza od nekoliko segmenata. Na taj način smanjuje se broj povratnih potvrda (ACK) koje primatelj treba poslati pošiljatelju.

Ako u roku od 0,5 sekundi primatelj ne primi novih segmenata od pošiljatelja, onda šalje potvrdu za onaj (jedan) segment kojeg je primio. Dakle, odgađanjem potvrđivanja primitka nastoji se smanjiti broj povratnih potvrda primatelja. Ali takvim odgađanjem slanja povratnih potvrda općenito se usporava proces slanja (prijenosa podataka), jer na taj način povećava se izmjereni RTT, a onda i izračunato vrijeme čekanja za danu TCP vezu, od kojeg počinje odbrojavanje na tajmeru pošiljatelja. To znači da kad se neki paket izgubi na putu, onda će pošiljatelj duže čekati prije njegovog ponovnog slanja; to će usporiti pomicanje njegovog kliznog prozora, a time i umanjiti intenzitet slanja.

Dobro rješenje moglo bi biti da primatelj odgađa odgovor kad se prijenos odvija u redu, a da smjesta reagira (ponavljanjem prethodne potvrde) kad se pojavi praznina u nizu segmenata. Na taj način primatelj poziva pošiljatelja da smjesta (ubrzano) ponovi prijenos nedostajućeg (izgubljenog) segmenta, bez obzira na stanje tajmera, kako smo to opisali iznad.

Rukovanje u tri koraka

U nastavku iznosimo opis procedure uspostavljanja i procedure raskidanja TCP veze. Opis tih procedura ujedno pokazuje uloge preostalih bitova-oznaka iz zaglavlja TCP segmenta. Uzmimo da neka aplikacija (klijent) sa domaćina D1 hoće uspostaviti komunikaciju sa nekom aplikacijom (serverom) na domaćinu D2. Klijentski proces (to jest, aplikacija) koji se izvodi na D1, daje zahtjev TCP protokolu na D1 da za njega uspostaviti TCP vezu sa zadanim serverskim procesom koji radi na domaćinu D2. Takav zahtjev sadrži IP adresu domaćina D2 i port onog servera (na D2) sa kojim dana aplikacija (klijent) sa D1 hoće uspostaviti TCP vezu.

Aplikacija daje zahtjev za uspostavu nove TCP veze na taj način da stvori jedan novi objekt klase Socket (utičnica); dakle, novi objekt one klase koja tu aplikaciju povezuje sa TCP protokolom na tom domaćinu. Kad primi takav zahtjev od nekog aplikacijskog procesa na D1, TCP protokol na D1 pokreće proces uspostave tražene TCP veze sa TCP protokolom na onom domaćinu (D2) sa kojim D1 traži uspostavu veze. Taj proces, koji je shematski prikazan na slici 2.14, sastoji se od tri koraka, tako da se naziva rukovanjem u tri koraka (ili trojnim rukovanjem; three-way handshake).

40

Slika 2.14 Uspostavljanje TCP veze: rukovanje u tri koraka

Korak 1 - TCP protokol sa klijenta (D1) šalje jedan upravljački segment TCP protokolu na serveru (D2); u tom segmentu, bit-oznaka SYN postavljena je na vrijednost "1", tako da se taj segment naziva SYN segmentom. Klijent pritom bira (metodom slučajnosti) svoj početni slijedni broj (klijent-psb) i upisuje taj broj u polje "Slijedni broj" u zaglavlje svog SYN segmenta, kojeg šalje TCP protokolu servera (na D2). TCP klijenta predaje taj segment IP protokolu ispod sebe, koji ga postavlja u IP paket i prenosi na D2.

Korak 2 - TCP protokol na D2 (server) prima TCP SYN segment sa kojim TCP protokol sa D1 (klijent) traži uspostavu TCP veze. Kad primi takav zahtjev, TCP na D2 dodjeljuje toj budućoj TCP vezi odgovarajuće memorijske prostore (bafere za prijem i slanje segmenata) i varijable koje će sadržavati vrijednosti raznih veličina u toj vezi i u procesu prijenosa tom vezom. TCP na D2 (server) ujedno šalje TCPu na D1 (klijentu) segment sa kojim mu javlja da prihvaća uspostavu TCP veze čiju je uspostavu tražio TCP sa D1. Taj segment je upravljački segment i ne sadrži nikakve korisničke sadržaje, kao što ih nije sadržavao ni prvi segment, kojeg je TCP protokol sa D1 poslao TCP protokolu na D2.

U zaglavlje tog upravljačkog segmenta, TCP sa D2 upisuje tri podatka:- Bit-oznaku SYN postavlja na vrijednost "1".- U polje "Potvrda primitka" upisuje vrijednost slijednog broja segmenta kojeg je primio od

D1, uvećanu za 1; dakle, upisuje vrijednost (klijent-psb + 1).- TCP na D2 bira (metodom slučajnosti) svoj početni slijedni broj (server-psb) i upisuje ga

u polje "Slijedni broj" iz zaglavlja svog TCP segmenta kojeg šalje TCPu na D1 (klijentu).Taj segment naziva se SYNACK segmentom (to jest, potvrdom SYN segmenta). Tim

segmentom, pozvani TCP na D2 (server) javlja TCP-pozivatelju na D1 (klijentu) da je primio njegov zahtjev za uspostavu TCP veze sa početnim slijednim brojem klijent-psb. Pozvani TCP

41

javlja da prihvaća uspostavu te veze i šalje klijentu svoj polazni slijedni broj server-psb u polju "Slijedni broj" svog SYNACK segmenta.

Korak 3 - Po primitku SYNACK segmenta od TCP protokola sa D2, TCP protokol na D1 isto tako dodjeljuje memorijski prostor i varijable toj novoj TCP vezi (na domaćinu D1), koju se uspostavlja između TCPa na D1 i TCPa na D2. TCP na D1 ujedno šalje segment TCPu na D2 sa kojim potvrđuje primitak SYNACK segmenta sa D2; TCP na D1 to čini na taj način da u polje "Potvrda primitka" svog segmenta upiše vrijednost slijednog broja segmenta kojeg je primio od TCP sa D2, uvećanu za 1; dakle, vrijednost (server-psb + 1).

U tom segmentu vrijednost bita SYN postavljena je na 0, jer se smatra da je samim slanjem trećeg segmenta (kao trećim korakom u rukovanju) ta nova TCP veza između TCPa na domaćinu D1 (klijenta) i TCPa na domaćinu D2 (servera) uspostavljena. Zato u ovom segmentu klijent smije slati i podatkovne sadržaje serveru.

Nakon uspostave TCP veze između klijenta (TCP protokola na D1) i servera (TCP protokola na D2), klijent i server mogu tom vezom slati podatke u oba smjera istodobno. U segmentima koji prenose podatkovne sadržaje, bit-oznaka SYN postavlja se na vrijednost "0".

Raskid TCP veze može zatražiti bilo koji od dvaju aplikacijskih procesa koje povezuje ta veza i koji razmjenjuju sadržaje preko nje. Kod raskida TCP veze, svi resursi koji su bili dodijeljeni toj vezi - memorijski prostori (baferi) i varijable, na oba domaćina - oslobađaju se. Na slici 2.15 dan je prikaz postupka raskida TCP veze, kojeg je pokrenuo klijent.

Slika 2.15 Prekidanje TCP veze

42

Klijentski aplikacijski proces (na D1) zatražio je prekid dane TCP veze sa serverskim aplikacijskim procesom (na D2). Taj zahtjev (kojeg prima TCP na D1) čini da TCP na D1 pošalje jedan upravljački TCP segment TCP protokolu na D2, u kojem je bit-oznaka FIN postavljena na vrijednost "1". Tom oznakom označava se segment koji je zahtjev za prekid TCP veze.

Kad TCP na D2 (server) primi taj zahtjev, onda potvrđuje njegov primitak. TCP na D2 zatim šalje svoj zahtjev za prekidom te iste TCP veze; TCP na D1 (klijent) potvrđuje primitak tog zahtjeva. Nakon što pošalje serverskoj strani TCP veze (na D2) potvrdu o primitku njenog zahtjeva za raskid, klijentska strana TCP veze (na D1) ostaje aktivna (čeka) još neko vrijeme, za slučaj da se njena potvrda primitka (ACK) segmenta, koju je poslao serveru, izgubi. U slučaju takvog gubitka, server bi ponovio slanje svog FIN segmenta.

Ako klijent ne primi ponovljeni FIN zahtjev od servera u nekom zadanom vremenu (obično 30 sekundi, 1 minuta ili 2 minute), onda klijent uzima da je server primio njegovu potvrdu primitka (ACK) serverovog FIN segmenta, i tada raskida tu TCP vezu. Time se oslobađaju svi resursi na oba domaćina (memorije, varijable) koji su bili dodijeljeni toj TCP vezi u procesu njena uspostavljanja.

Spomenimo ovdje i bit-oznaku RST. Uzmimo da je neka aplikacija (klijent sa D1) dala zahtjev da se uspostavi TCP vezu sa nekom aplikacijom na domaćinu D2 (serveru), koja prima pozive na portu Pi. TCP sa D1 šalje zahtjev (SYN segment) za uspostavom tražene TCP veze TCP protokolu na D2. Takav zahtjev stiže TCPu na D2, ali nijedna aplikacija na D2 ne prima pozive (zahtjeve) na portu Pi, kojeg je tražio (zadao) tražitelj sa D1. Tada TCP sa D2 šalje upravljački segment TCPu na D1, u kojem je bit-oznaka RST postavljena na vrijednost "1". Time primatelj zahtjeva (TCP na D2) javlja pošiljatelju zahtjeva (TCPu na D1) da je primio njegov zahtjev, ali ga ne može izvršiti jer nijedna aplikacija na D2 ne prima pozive na portu Pi koji je naveden u danom zahtjevu za uspostavu TCP veze.

Bez takve povratne obavijesti, tražitelj bi slao isti zahtjev ponovno, jer bi smatrao da je njegov zahtjev izgubljen putem, ili da je primatelj trenutno zauzet i da zato nije prihvatio njegov zahtjev za uspostavom TCP veze.

Poznati i radni portovi

Komunikacija klijenta (preglednika) sa web serverom počinje uspostavljanjem TCP veze među njima. Klijent (kao aplikacija) pokreće proces uspostavljanja TCP veze sa serverom na taj način da pokrene program (klasu) koji kreira jednu utičnicu (kao novi objekt te klase) između toga klijenta i TCP protokola. Kod pokretanja toga procesa, klijent zadaje procesu adresu servera sa kojim hoće uspostaviti TCP vezu: to znači da zadaje IP adresu domaćina na kojem se nalazi taj server i port na kojem taj server prima nove poruke.

Kad klijentska aplikacija kreira novu utičnicu prema TCP protokolu, onda TCP protokol koji radi na klijentu, pokreće proces rukovanja u tri koraka sa TCP sustavom na zadanom domaćinu servera, i tako uspostavlja TCP vezu između klijenta i servera.

U procesu rukovanja u tri koraka, TCP sustav na domaćinu klijenta šalje svoju poruku na onaj port (na domaćinu od servera) na kojem dani server prima zahtjeve klijenata za uspostavu veze. Kad na taj port stigne zahtjev sa nekog klijenta, server smjesta kreira jednu novu utičnicu samo za ovu komunikaciju (sesiju) sa ovim klijentom. Na taj način server drži uvijek slobodan svoj osnovni (dobro poznati) port, tako da novi klijenti mogu uvijek slati svoje zahtjeve za uspostavu TCP veze na taj osnovni (poznati) port danog servera. Na taj način se u procesu rukovanja u tri koraka između sustava klijenta i servera, uspostavlja jedna nova TCP veza između polazne utičnice (porta) klijenta i nove utičnice (porta) na serveru, koju je za tu komunikaciju (sesiju) sa tim klijentom kreirao TCP sustav na strani servera.

Osnovna utičnica (dobro poznati port) na serverskoj strani, kojoj se klijenti obraćaju u prvom koraku procesa uspostavljanja TCP veze s tim serverom, naziva se i prijemnom utičnicom

43

(welcoming socket). Programska definicija te utičnice sadrži jednu metodu (proceduru) koja za svaki zahtjev koji stigne na tu utičnicu, kreira jednu novu utičnicu (novi objekt te klase) za taj zahtjev; dakle, za tu komunikacijsku seansu toga klijenta. Ta nova utičnica naziva se serverskom utičnicom veze (connection socket). Tako proces sa kojim TCP sustav klijenta pokreće uspostavu veze između dane utičnice klijenta i prijemne utičnice danog servera, završava uspostavom TCP veze između polazne utičnice klijenta i jedne posebne "utičnice veze" na serveru, preko koje se uspostavlja jedna TCP veza između danog klijentskog procesa i serverskog procesa s kojim taj klijentski proces želi komunicirati.

Opisani proces uspostavljanja TCP veze između klijenta i servera ilustrira grafički prikaz na slici 2.16.

Slika 2.16 Prijemna utičnica i utičnica veze

TCP vezu između klijenta i servera može se promatrati kao izravan spoj ("cijev") između pripadne utičnice klijenta i pripadne utičnice te veze na serveru. Pisanje utičnice na klijentskoj i na serverskoj strani je važan dio posla kod izrade mrežne aplikacije. Utičnice se mogu pisati u raznim programskim jezicima; kod pisanja utičnica koriste se odgovarajuće sistemske klase i metode koje su sadržane u pakiranjima (packages) kao što su java.io i java.net u jeziku Java. Izraz "package" može se prevesti kao "pakiranje", ali i kao "svežanj" klasa.

44

2.5 Upravljanje intenzitetom prijenosa

Govor o upravljanju intenzitetom prijenosa (flow control) odnosi se na usklađivanje brzine slanja pošiljatelja sa mogućnostima primanja primatelja u jednoj TCP vezi. Dakle, ovdje se radi o optimizaciji ponašanja dvaju komunikatora.

Govor o izbjegavanju zagušenja mreže (congestion control) odnosi se na upravljanje ponašanjem (brzinom slanja) svih pošiljatelja, sa ciljem da se izbjegne (spriječi) zagušenje usmjerivača i mreže u cjelini. U ovom odjeljku govorimo o upravljanju intenzitetom prijenosa; u slijedećem odjeljku govorimo o izbjegavanju zagušenja mreže.

Prigodom uspostavljanja TCP veze, TCP protokol na svakoj strani te veze (na domaćinima) dodjeljuje određeni memorijski prostor toj TCP vezi za potrebe primanja i slanja sadržaja preko te veze. Kad preko te TCP veze stigne primatelju segment koji je prihvatljiv (ispravan), onda se sadržaj tog segmenta zapisuje u određeni dio tog memorijskog prostora; taj dio možemo zvati prijemnom memorijom ili prijemnim baferom te TCP veze. Aplikacija kojoj je taj sadržaj namijenjen, čita (preuzima) sadržaj iz tog memorijskog prostora (prijemnog bafera).

Segmenti mogu stizati primatelju različitim intenzitetom; aplikacija kojoj se ti sadržaji donose (i koja ih treba preuzeti), može biti spora ili opterećena drugim poslovima. To može dovesti do toga da sadržaji stižu TCP vezom i bivaju upisani u prijemni bafer te veze većim intenzitetom nego što ih aplikacija preuzima (i briše iz bafera). Ako takvo stanje potraje - naprimjer, ako se vezom prenosi velika datoteka - onda će prijemni bafer primatelja postati sasvim ispunjen. Kad se to dogodi, onda će TCP na strani primatelja odbacivati TCP segmente koje prima jer ih neće više imati kamo upisivati.

Da se to ne bi događalo, TCP protokol sadrži sustav upravljanja intenzitetom prijenosa koji usklađuje intenzitet slanja pošiljatelja sa mogućnostima primanja primatelja. Ukratko, posao tog sustava je da ograniči brzinu kojom pošiljatelj šalje segmente, na onu mjeru u kojoj primatelj može trenutno primati njegove sadržaje. Ta mogućnost primanja je ovdje određena prvenstveno veličinom slobodnog prostora u prijemnom baferu TCP veze na strani primatelja.

Ranije smo rekli da specifikacije TCP protokola (koje su sadržane u više RFCa) ne pretpisuju striktno na koji način treba postupati sa segmentima koji stižu primatelju u ispravnom stanju, ali izvan redoslijeda. "Izvan redoslijeda" ovdje obično znači da je stiglo nekoliko segmenata sa slijednim brojevima n+1, n+2, ..., n+i, a da primatelj nije primio segment sa slijednim brojem n. Rekli smo da implementacije TCP protokola obično pohranjuju takve segmente dok ne prime one segmente koji nedostaju u nizu ispred njih; zatim kumulativno potvrđuju primitak svih segmenata u nizu (do uključno n+i), i ispunjen niz segmenata predaju aplikaciji.

Da bi prikaz načina rada sustava za upravljanje intenzitetom prijenosa bio jednostavniji, ovdje ćemo uzeti da je TCP implementiran na način da odbacuje segmente koje primi izvan redoslijeda. Time se ne mijenja suštinu načina rada sustava za upravljanje intenzitetom prijenosa u TCP protokolu, ali to omogućava da opis tog načina rada bude jednostavniji. Na slici 2.17 dana je skica prijemnog bafera jedne TCP veze na strani primatelja; na slici su navedene neke veličine koje su važne za upravljanje intenzitetom prijenosa sadržaja, koje koristimo u nastavku.

45

Slika 2.17 Prijemni bafer TCP veze

Svakoj TCP vezi dodijeljeni su određeni memorijski prostori na svakom kraju (domaćinu) te veze. VelPrimBafera je veličina (u bajtovima) onog memorijskog prostora neke TCP veze u kojeg se zapisuju sadržaji koji stižu tom vezom; taj memorijski prostor nazvali smo prijemnim baferom. Prijemni bafer dijeli se na dva dijela: (1) dio koji je zauzet primljenim sadržajima koje aplikacija (za koju ta TCP veza vrši prijenos) nije još preuzela, i (2) dio koji je slobodan i u kojeg se može vršiti upis novih sadržaja. Slobodni dio prijemnog bafera naziva se prozorom za primanje; veličinu tog dijela bafera (prozora za primanje) označili smo sa VelPrimProzora.

Veličina prozora za primanje se stalno mijenja. Primitkom novih segmenata i upisom novih sadržaja u prijemni bafer, veličina prozora za primanje se smanjuje; kad aplikacija preuzima sadržaje iz prijemnog bafera, prozor za primanje se povećava. U tom kontekstu važne su dvije veličine:

- ZadPrimBajt - redni broj zadnjeg bajta koji je primljen i upisan u prijemni bafer.- ZadPreuzBajt - redni broj zadnjeg bajta kojeg je aplikacija preuzela iz prijemnog bafera.Veličinu slobodnog prostora u baferu (prozora za primanje) označili smo sa

VelPrimProzora; tu veličinu izračunava se na slijedeći način:

VelPrimProzora = VelPrimBafera - (ZadPrimBajt - ZadPreuzBajt)

Dakle, to je veličina cijelog prijemnog bafera, umanjena za onaj dio tog bafera u kojem su zapisani oni primljeni sadržaji koje aplikacija još nije preuzela. Oni sadržaji koje aplikacija preuzme iz bafera, brišu se iz bafera.

U zaglavlju TCP segmenta postoji polje "Prijemni prozor". U svakom segmentu kojeg primatelj B šalje (povratno) pošiljatelju A, primatelj upisuje trenutnu vrijednost svoje varijable VelPrimProzora u polje "Prijemni prozor" tog segmenta. Na taj način primatelj obavještava pošiljatelja o veličini svog prijemnog prozora.

TCP veza je dvosmjerna; segmenti koje primatelj B povratno šalje pošiljatelju A mogu biti samo potvrde primitaka (ACK) segmenata koje B prima od A. Ali B može isto tako slati neke svoje sadržaje Au, i u segmentima koji prenose te sadržaje Au, potvrđivati primitak segmenata od A i ujedno obavještavati A o veličini svog prijemnog prozora. U svakom slučaju, pošiljatelj ima stalan uvid u trenutnu veličinu prijemnog prozora primatelja (to jest, veličinu slobodnog prostora u njegovom prijemnom baferu) kojem šalje sadržaje.

Pošiljatelj A prilagođava intenzitet svog slanja veličini prijemnog prozora od B, tako da količinom svog slanja ne prekorači veličinu tog prozora, jer bi onda primatelj odbacivao njegove

46

segmente za koje ne bi bilo mjesta u njegovom prozoru za primanje.

Da bi intenzitet svog slanja držao u onim granicama koje dopušta veličina prijemnog prozora primatelja B, pošiljatelj A vodi računa o dvjema svojim veličinama:

- ZadPoslBajt - redni broj zadnjeg bajta kojeg je poslao primatelju B; - ZadPotvrBajt - redni broj zadnjeg bajta čiji je primitak potvrdio primatelj B.Razlika između tih dviju veličina je količina (broj) bajtova koje je A poslao u TCP vezu, a

za koje još nije primio potvrdu o primitku. Pošiljatelj treba prilagođavati brzinu svog slanja na takav način da ta razlika (vrijednost) nikad ne prijeđe veličinu prijemnog prozora primatelja. Takvim načinom rada pošiljatelj neće nikad "zatrpati" primatelja većom količinom sadržaja nego što može biti upisana u primateljev prijemni prozor. Pošiljatelj će na taj način ujedno izbjeći da primatelj odbacuje njegove segmente, koje bi onda morao ponovno slati.

Dakle, na pošiljatelju treba uvijek vrijediti odnos:

ZadPoslBajt - ZadPotvrBajt =< VelPrimProzora

VelPrimProzora je veličina prijemnog prozora na primatelju. Pošiljatelj A preuzima tu veličinu iz polja "Prijemni prozor" koje se nalazi u zaglavlju TCP segmenata koje A prima od primatelja B. Ti segmenti od B mogu biti samo potvrde primitka (ACK), ali mogu sadržavati i druge sadržaje koje B šalje Au. Dakle, primatelj segmenata potvrđuje njihov primitak i pritom u polje "Prijemni prozor" u zaglavlju svojih segmenata-potvrda upisuje trenutnu vrijednost svoje varijable VelPrimProzora - to jest, trenutnu veličinu svog prijemnog prozora.

Pošiljatelj A uzima tu veličinu i prema njoj određuje intenzitet svog slanja segmenata primatelju B, tako da ne izazove prekoračenje prijemnog prozora od Ba.

TCP veza je dvosmjerna, tako da istodobno dok A šalje sadržaje Bu, B može slati svoje sadržaje Au. Gornji opis odnosi se na smjer TCP veze od A prema B; prigodom uspostavljanja TCP veze, na Au je toj vezi dodijeljen memorijski prostor koji uključuje prijemni bafer za zapisivanje sadržaja koje B šalje Au. To znači da se na strani A te TCP veze odvija proces računanja veličine prijemnog prozora, jednak onome kojeg smo opisali za stranu B. Strana A isto tako obavještava stranu B o veličini svog prozora za primanje. Ti istovrsni procesi računanja na A i na B su nezavisni jedan od drugoga: prijemni prozor na jednoj strani može biti velik, a na drugoj može biti mali, ili sasvim zatvoren.

Poseban problem javlja se u situaciji kad veličina prijemnog prozora na primatelju padne na vrijednost 0; dakle, primatelj trenutno nema ništa slobodnog prostora za primanje. Uzmimo slijedeću situaciju. Strana A šalje veliku datoteku strani B u segmentima; strana B ne šalje strani A ništa, osim potvrda o primitku segmenata od A, u kojima strana B ujedno javlja strani A veličinu svog prijemnog prozora. Aplikacija na B sporo preuzima sadržaje iz prijemnog bafera, tako da se taj bafer sve više ispunjava. Kod potvrde primitka (ACK) posljednjeg primljenog segmenta, strana B javlja strani A da je veličina njenog prijemnog prozora pala na vrijednost 0. U tom trenutku, A prestaje slati segmente jer zna da B ne bi imao kamo zapisati njihove sadržaje.

Dok pošiljatelj A stoji, aplikacija na B počinje čitati sadržaje iz prijemnog bafera dane TCP veze između A i B, tako da se prijemni bafer te veze na B prazni. Time se prijemni prozor na B "otvara"; dakle, poprima vrijednosti veće od 0. Taj prozor porasti će na veličinu jednog segmenta, a zatim i na više segmenata, tako da bi A sad mogao nastaviti sa slanjem. Ali A to ne zna; B mu to ne javlja jer strana B nema razloga za to da šalje segmente strani A. Strana B potvrdila je primitak segmenata od A ranije, a trenutno nema svojih sadržaja za slati strani A.

Taj problem (zastoj) može se riješiti na razne načine; prema specifikaciji TCP protokola, taj problem riješen je na slijedeći način. Nakon što je A primio podatak da je prijemni prozor od B pao na vrijednost 0, A nastavlja povremeno slati strani B segmente sa jednim bajtom sadržaja. Ako je prozor na B pao točno na 0, a ne naprimjer na 5 ili 10 bajtova, onda će ti segmenti biti odbačeni na

47

primatelju B. Ali kad se prijemni prozor na B otvori (jer je aplikacija počela preuzimati sadržaje), onda će B potvrditi primitak jedno-bajtnog segmenta od A; to će učiniti slanjem segmenta ACK, u čijem će zaglavlju ujedno poslati strani A novu veličinu svog prijemnog prozora, koja je sada veća od nule. Kad taj prozor postane dovoljno velik da primi jedan segment, onda strana A može nastaviti sa slanjem segmenata, kako je to činila prije zastoja. Naravno, intenzitet slanja zavisiti će od veličine prijemnog prozora na primatelju, kako je to bilo i ranije.

Na taj način rješava se problem zastoja u prijenosu, koji nastaje u trenutku kad je prijemni prostor na primatelju sasvim potrošen (ispunjen).

Dani opis upravljanja intenzitetom slanja odnosi se na TCP protokol; UDP protokol ne sadrži elemente za upravljanje intenzitetom prijenosa. Kod UDP protokola ne uspostavljaju se veze prije prijenosa (kao kod TCPa), nego se prijenos vrši izravno na zadanu IP adresu i broj porta na toj adresi. Port ima svoj prijemni memorijski prostor u kojeg se zapisuju sadržaji primljenih segmenata. Aplikacija preuzima sadržaje iz tog memorijskog prostora i time oslobađa taj prostor za upis novih segmenata. Ali kod protokola UDP nema kontrole intenziteta slanja. Ako neki UDP prijenos ispunjava prijemni prostor primatelja brže nego ga aplikacija prazni, onda se taj prostor zapuni, tako da UDP na primatelju odbacuje segmente koji stižu u trenutku kad je prijemni prostor primatelja ispunjen i kad se njihovi sadržaji nemaju kamo zapisati.

Kad je prijemni bafer neke TCP veze ispunjen, onda se segmenti odbacuju i kod prijenosa kojeg izvodi TCP protokol. Ali TCP protokol sadrži sustav za upravljanje intenzitetom slanja, koji ima za cilj izbjegavanje (sprječavanje) situacija u kojima dolazi do odbacivanja segmenata. To što UDP nema sustav za upravljanje intenzitetom slanja dovodi i do zagušenja usmjerivača, što je još veći problem; o izbjegavanju zagušenja usmjerivača govorimo u slijedećem odjeljku.

2.6 Sprječavanje zagušenja mreže

Velika kašnjenja IP paketa na putu obično nastaju zbog dugih redova čekanja na usmjerivačima preko kojih ti paketi prolaze na putu do svog odredišta. Gubici paketa na putu obično nastaju kad paketi stignu do nekog usmjerivača čiji je memorijski prostor za primanje dolazećih paketa sasvim ispunjen, tako da taj usmjerivač odbacuje dolazeće pakete. Zbog velikog kašnjenja paketa, kod pouzdanog prijenosa (TCP), pošiljatelj ponavlja slanje paketa; kad ne dobije potvrdu o primitku paketa (ACK) u zadanom vremenu; tada pošiljatelj zaključuje da je taj paket izgubljen, pa ponavlja njegovo slanje. Ovdje govorimo o paketima, iako transportni protokoli rade sa segmentima, ali segmenti se prenose u IP paketima. Usmjerivači rade na mrežnoj razini sustava, sa IP paketima; gubitak segmenta nastaje kao posljedica gubitka (odbacivanja) IP paketa.

Kod gubitka (odbacivanja) IP paketa, protokol TCP ponavlja slanje onog segmenta kojeg je taj paket prenosio. Jer odbačeni segment (paket) je izgubljen. Ponavljanjem slanja paketa pokušava se otkloniti posljedice zagušenja mreže (usmjerivača), ali se time ne otklanja uzrok tog zagušenja. Štoviše, ponavljanjem slanja paketa dodatno se opterećuje preopterećene usmjerivače i time se povećava vjerojatnost da neki paketi budu (ponovno) odbačeni.

Osnovni uzrok zagušenja usmjerivača i odbacivanja paketa na putu je u tome što prevelik broj pošiljatelja šalje u mrežu pakete prevelikim intenzitetom, u odnosu na trenutne mogućnosti prijenosa onih usmjerivača i veza preko kojih trebaju biti prenijeti ti paketi na svom putu od izvora do odredišta. Problem zagušenja mreže (usmjerivača) treba rješavati na taj način da se otklanja uzrok toga problema. To znači da treba definirati (i implementirati) sustav koji smanjuje intenzitet kojim pošiljatelji šalju pakete u mrežu onda kad se neki usmjerivači približavaju stanju zagušenja, ili su to stanje upravo dosegnuli.

48

Podsjetimo ovdje na razliku između upravljanja intenzitetom prijenosa (toka), o čemu smo govorili u prethodnom odjeljku, i sprječavanja zagušenja mreže, o čemu govorimo u ovom odjeljku. Kod upravljanja intenzitetom slanja usklađuje se brzinu slanja jednog pošiljatelja A sa mogućnošću primanja jednog primatelja B; pritom su A i B povezani TCP vezom preko koje se izvodi prijenos sadržaja između njih. Jednak proces upravljanja intenzitetom slanja odvija se i za slanje u obrnutom smjeru, od B prema A, jer TCP veza je dvosmjerna. Dakle, upravljanje intenzitetom slanja (prijenosa ili toka; flow control) bavi se usklađivanjem rada dvaju procesa koji se odvijaju na dvama završnim čvorovima mreže (domaćinima), između kojih (procesa) se odvija prijenos sadržaja.

S druge strane, problematika sprječavanja zagušenja mreže bavi se pitanjem na koji način zaštititi mnoštvo usmjerivača u "unutrašnjosti mreže" od zagušenja, koje se događa kad na neki usmjerivač stiže (duže vremena) više paketa nego što ih taj usmjerivač može proslijediti dalje. Dakle, u prvom slučaju upravlja se intenzitetom prijenosa između jednog pošiljatelja i jednog primatelja (koji su međusobno povezani TCP vezom), sa ciljem da se spriječi da pošiljatelj šalje većom brzinom nego što primatelj može primati, jer bi paketi bili odbacivani na primatelju. U drugom slučaju, nastoji se uspostaviti sustav koji štiti mnogo usmjerivača od prevelikog dotoka paketa koje šalje mnogo pošiljatelja sa završnih sustava mreže (domaćina).

Problematika sprječavanja (izbjegavanja) zagušenja mreže, uz optimalno iskorištenje njenih kapaciteta, spada među najvažnije teme u području istraživanja i razvoja računalnih mreža. U nastavku ovog odjeljka najprije iznosimo opća načela prema kojima se oblikuju sustavi za izbjegavanje zagušenja usmjerivača, a zatim iznosimo prikaz sustava za izbjegavanje zagušenja kod transportnog protokola TCP. Protokol UDP, kao drugi protokol transportne razine Interneta, ne vodi računa o zagušenju usmjerivača, niti o izbjegavanju toga zagušenja. To predstavlja problem, kojeg se može riješiti na razne načine, ali uz neke nepovoljne posljedice; o tome je rečeno nešto više u završnom dijelu ovog odjeljka.

Prijenosna moć (snaga) mreže

Količina segmenata koje transportni sloj šalje u mrežu (to jest, daje ih mrežnom sloju, koji onda šalje pakete u mrežu) naziva se ponuđenim teretom mreži, odnosno teretom koji je ponuđen mreži (offered load). Ako je ponuđeni teret mreži veći od mogućnosti prijenosa te mreže, onda dolazi do odbacivanja paketa na putu. Mogućnost prijenosa mreže može se zvati prijenosnom moći mreže, ili propusnošću mreže; tu veličinu je teško točno kvantificirati na razini mreže, ali služi tome da se opiše jedan bitan problem koji se javlja u radu mreže.

Odbačeni paketi ne stižu na odredište. Ako su ti paketi prenošeni UDP protokolom, onda su njihovi sadržaji trajno izgubljeni za primatelja, jer UDP ne ponavlja prijenos paketa koji se izgube (odbace) u prijenosu (na putu). Ako se paketi prenose TCP vezom, onda pošiljatelj ponavlja slanje izgubljenog (odbačenog) paketa, sve dok mreža ne uspije prenijeti jednu njegovu kopija primatelju u ispravnom stanju.

Međutim, ako je ponuđeni teret mreži trajno veći od prijenosne moći mreže, onda to nužno dovodi do odbacivanja paketa u mreži (u prijenosu). Kada se odbačene pakete šalje ponovno, onda se time dodatno opterećuje mrežu (usmjerivače), što onda dovodi do toga da bude odbačen još veći postotak paketa. Čim više raste ponuđeni teret mreži u odnosu na prijenosnu moć mreže, to se veći dio (postotak) paketa odbacuje i gubi na putu. Tako rast ponuđenog tereta preko određene mjere, dovodi do stalnog opadanja količine paketa koju mreža uspijeva prenijeti do njihovih odredišta. Graf na slici 2.18 ilustrira kretanje (tendenciju) koje smo opisali iznad.

49

Slika 2.18 Opterećenje i snaga mreže

Graf pokazuje da sa porastom ponuđenog tereta raste i količina prenijetog sadržaja u jedinici vremena, sve dok se ta ponuda ne približi maksimalnoj moći prijenosa mreže, Pmax. Kad se ponuđeni teret (u jedinici vremena) približi toj veličini (Pmax), daljnji rast ponuđenog tereta ne povećava količinu sadržaja kojeg mreža uspijeva prenijeti na odredište, nego dovodi do naglog pada te količine, kako to pokazuje dani graf. Razlog pada količine prijenosa na odredište je u tome što s porastom ponuđenog tereta (preko Pmax), raste stupanj zagušenja usmjerivača, na kojima se onda odbacuje sve veći postotak paketa, čime opadaju izgledi svakog pojedinog paketa da uspije proći kroz više usmjerivača (za redom) na putu, bez da bude odbačen.

Tako s porastom veličine ponude pošiljatelja, preko određene granice, dolazi do naglog pada količine paketa koji uspijevaju biti prenijeti mrežom do njihovih odredišta. Zato je problematika izbjegavanja zagušenja mrežnih elemenata (usmjerivača) i mreže kao sustava, iznimno važna za optimalno oblikovanje i rad elemenata mreže, i mreže u cjelini. Graf sa slike 2.18 pokazuje da prevelika ponuda tereta može dovesti do skoro potpunog zagušenja mreže, tako da se preko mreže (u tom stanju) ne uspijeva prenijeti skoro ništa.

Kada graf sa slike 2.18 prikazuje kretanja u opsežnijoj mreži, onda je taj graf uvelike kvalitativne prirode. Za svaki usmjerivač može se utvrditi (mjeriti) koliki teret prima na svojim ulazima, i koliki teret uspijeva proslijediti dalje na svojim izlazima. Ali za mrežu kao cjelinu, teško je utvrditi takve veličine. U nekim dijelovima mreže, ponuđeni teret može biti veći, a u drugim dijelovima manji; mogućnosti prijenosa u nekim dijelovima mreže mogu biti veće, a u drugim dijelovima manje; neki dijelovi mreže mogu biti preopterećeni, dok mogućnosti drugih dijelova mreže mogu ne biti sasvim iskorištene. U svakom slučaju, dani graf jasno pokazuje tendenciju

50

kretanja u odnosu između (1) ponuđenog tereta (opterećenja) mreže, i (2) prijenosne moći mreže. Graf posebno ukazuje na izrazito nepovoljne posljedice (pad učinkovitosti mreže), koje nastaju kad ponuđeni teret (opterećenje) prijeđe veličinu prijenosne moći mreže.

Do toga pada dolazi jer usmjerivači sve više rade posao od kojeg nema nikakve koristi: posao koji ne dovodi do konačnog rezultata. Ako je neki paket odbačen na četvrtom usmjerivaču na putu prema svom odredištu, onda je posao prethodnih triju usmjerivača (koji su taj paket uspješno prenijeli) postao beskoristan: konačni učinak (koristan prijenos) kojeg su ostvarili prijenosom tog paketa je jednak nuli. Sa porastom ponuđenog tereta mreži preko određene granice, opada veličina ostvarenog prijenosa na odredište, jer raste postotak (ne samo broj) odbačenih paketa na zagušenim usmjerivačima. Sa svakim odbačenim paketom poništava se i rad onih usmjerivača koji su uspješno prenijeli taj paket do mjesta njegovog odbacivanja.

Načela upravljanja zagušenjem

Pristupe problematici izbjegavanja zagušenja dijeli se u dvije skupine. U prvu skupinu spadaju pristupi i sustavi koji izvode upravljanje zagušenjem na razini transportnog sloja, bez da primaju eksplicitne obavijesti od protokola mrežne razine. S obzirom da protokoli transportnog sloja rade samo na završnim sustavima mreže (domaćinima), kažemo da je kod ovakvog načina rada proces izbjegavanja zagušenja vođen sa ruba mreže.

U drugu skupinu spadaju pristupi i sustavi kod kojih se izbjegavanje zagušenja izvodi na transportnoj razini, ali na temelju izravnih obavijesti koje transportnom protokolu šalju elementi mrežne razine (usmjerivači). Usmjerivači se nalaze "u unutrašnjosti mreže"; zato kažemo da je kod ovakvih sustava proces izbjegavanja zagušenja vođen iz unutrašnjosti mreže. Kod tih sustava intenzitetom slanja se i dalje upravlja na transportnoj razini, ali ovdje se to čini na osnovu obavijesti koje elementi iz unutrašnjosti mreže (usmjerivači) eksplicitno šalju transportnom protokolu na završnim sustavima mreže (domaćinima).

Upravljanje zagušenjem sa ruba mreže izvodi se samo sredstvima transportnog sloja; ovdje mrežni sloj (unutrašnjost mreže) ne daje eksplicitne podatke o stanju i opterećenosti usmjerivača i veza. Transportni protokol radi samo na završnim čvorovima mreže; na usmjerivačima (koji čine unutrašnjost mreže) rade samo slojevi do uključno mrežnog sloja. Kod upravljanja zagušenjem sa ruba mreže, transportni protokol zaključuje kakvo je stanje u unutrašnjosti mreže na osnovu toga koliko uspješno se odvija prijenos njegovih segmenata: da li se odvija sve sporije (RTT raste) i da li se njegovi segmenti gube u prijenosu.

Transportni protokol može reagirati na rast RTTa, a svakako treba reagirati na gubitak paketa. Jedino što transportni sloj (TCP) može učiniti je smanjiti intenzitet svog slanja segmenata, a to i treba učiniti u takvim situacijama. Transportni sloj ne vidi izravno zagušenje usmjerivača (koji rade na mrežnoj razini), niti od njih dobiva eksplicitne obavijesti o njihovom stanju. Transportni sloj izvodi kontrolu zagušenja unutrašnjosti mreže (usmjerivača) sa ruba mreže na temelju onih učinaka mreže koje sam uočava.

Konkretno, kod Interneta, protokol mrežne razine IP, koji vrši prijenos TCP segmenata (u IP paketima), ne šalje obavijesti TCP protokolu (kao pošiljatelju tih segmenata) o stanju usmjerivača i veza preko kojih se ti segmenti (paketi) kreću na svom putu od izvora do odredišta. Usporavanje prijenosa (rast RTTa) i gubici segmenata su jedini pokazatelji stanja usmjerivača, na temelju kojih TCP zaključuje da su usmjerivači preko kojih se kreću njegovi segmenti zagušeni. Zato TCP reagira na svaki gubitak segmenta oštrim smanjenjem svog intenziteta slanja segmenata. Na taj način TCP štiti usmjerivače od (daljnjeg, većeg) zagušenja, i sebe od potrebe da mora ponovno slati segmente koje odbacuju zagušeni usmjerivači.

Kod pristupa i sustava kod kojih se proces izbjegavanja zagušenja izvodi na temelju obavijesti iz unutrašnjosti mreže, usmjerivači šalju eksplicitne obavijesti pošiljateljima

51

segmenata (u paketima) o tome da se približavaju stanju zagušenosti. Ovdje postoji više mogućih načina na koje usmjerivači mogu slati takve obavijesti transportnim protokolima na završnim čvorovima mreže, koji onda postupaju u skladu sa tim obavijestima.

Usmjerivač je zagušen kad je njegov memorijski prostor za primanje dolazećih paketa potpuno ispunjen, tako da mora odbacivati nove pakete koji stižu na njegove ulaze. Usmjerivač može slati obavijesti (završnim čvorovima) o tome da se približava stanju zagušenja na taj način da postavlja vrijednost jednog bita u zaglavlju segmenta na vrijednost "1". Nazovimo taj bit bitom zagušenja. Usmjerivač prosljeđuje segment (paket) sa bitom zagušenja postavljenim na "1" prema njegovom odredištu.

Transportni protokol na primatelju ne može izravno smanjiti intenzitet kojim pošiljatelj šalje segmente, ali kad primi segment u kojem je bit zagušenja postavljen na vrijednost "1", onda primatelj može (i treba) poslati povratnu obavijest pošiljatelju da smanji intenzitet slanja jer se neki usmjerivač preko kojeg se prenose njegovi segmenti približava stanju zagušenosti.

Druga mogućnost je da usmjerivač pošalje izravnu poruku pošiljatelju o tome da se približava stanju zagušenja. Slika 2.19 ilustrira dva navedena načina na koje usmjerivači (iz unutrašnjosti mreže) mogu obavještavati pošiljatelje (sa ruba mreže) o svom trenutnom stanju. U prvom slučaju to čine izravnim porukama pošiljateljima, a u drugom slučaju to čine preko primatelja segmenata.

Slika 2.19 Slanje povratne poruke pošiljatelju

Kod slanja obavijesti preko primatelja segmenata, obavijest o stanju usmjerivača stiže do pošiljatelja barem jedan RTT nakon što je pošiljatelj uputio u mrežu onaj segment u čijem je zaglavlju usmjerivač postavio bit zagušenja na vrijednost "1". Zato u tom slučaju usmjerivači trebaju pravodobno početi postavljati bitove zagušenja, da bi spriječili da se zagušenje dogodi.

Kad usmjerivači izravno šalju obavijesti pošiljateljima o svom stanju, onda te obavijesti stižu pošiljateljima ranije; koliko ranije, zavisi od toga koliko je usmjerivač daleko od pošiljatelja. Ali izravan način obavještavanja iziskuje više rada. Usmjerivač treba formirati zasebnu (novu) poruku, i tu poruku treba poslati pošiljatelju (na čije se slanje reagira); to dodatno opterećuje

52

usmjerivač (koji formira i šalje poruku) i mrežu koja tu poruku prenosi pošiljatelju.

Konačno, usmjerivači mogu štititi sebe i mrežu od zagušenja slanjem implicitnih poruka pošiljateljima da uspore slanje. To mogu činiti namjernim odbacivanjem jednog ili više paketa onda kad se približe stanju zagušenja. Pošiljatelji reagiraju na gubitke (odbacivanje) njihovih paketa na taj način da uspore svoje slanje paketa. Takvim unaprijednim odbacivanjem nekoliko paketa, usmjerivači mogu usporiti pošiljatelje i time izbjeći svoje potpuno zagušenje, koje dovodi do odbacivanja daleko većeg broja paketa.

Kod unaprijednog odbacivanja, usmjerivači mogu birati koje će pakete odbaciti po načelu slučajnosti. Druga mogućnost je da usmjerivači odbacuju pakete onih pošiljatelja koji šalju pakete najvećim intenzitetom. Slučajno odbacivanje je jednostavnije, jer usmjerivači ne moraju voditi računa o intenzitetu slanja pojedinih pošiljatelja. Usto, kod slučajnog odbacivanja, veća je vjerojatnost da će biti odbačeni upravo paketi onih pošiljatelja koji šalju najviše paketa.

Gornji prikaz odnosi se prvenstveno na mreže koje rade prema načelu usmjeravanja paketa; Internet radi prema tom načelu. Kod mreža koje rade prema načelu uspostavljanja virtualnih putova, mogu se koristiti drukčiji načini praćenja stanja usmjerivača i obavještavanja pošiljatelja o tom stanju. Podsjetimo, virtualni put uspostavlja se na taj način da začetnik komunikacije pošalje jedan signalni paket domaćinu s kojim hoće uspostaviti komunikaciju. Krećući se od svog izvora do svog odredišta, preko raznih usmjerivača, taj signalni paket uspostavlja jedan virtualni put od izvora do odredišta; da bi taj put bio sasvim definiran, paket se treba vratiti svom pošiljatelju. Proces uspostavljanja virtualnog puta podrobnije je opisan u knjizi Računalne mreže (1).

Zapisi o virtualnom putu postoje na svakom usmjerivaču preko kojeg taj put prolazi; točnije rečeno, zapisi na usmjerivačima tvore virtualne putove; bez tih zapisa ne bi bilo virtualnih putova. S druge strane, TCP veza je definirana sa dva procesa od kojih se svaki izvodi na jednom kraju te veze (na domaćinu) i tvori jedan kraj te veze. Na usmjerivačima koji se nalaze (i vrše prijenos) između krajeva TCP veze, nema nikakvih zapisa o toj vezi ni o njenom postojanju. Dakle, jedan virtualni put i jedna TCP veza su oba "virtualni" u smislu da se uspostavljaju i raskidaju (softverski) za potrebe jedne komunikacije, ali se međusobno bitno razlikuju.

Postojanje zapisa o svakom virtualnom putu na svakom usmjerivaču preko kojeg taj put prolazi, daje dvije osnovne mogućnosti:

- Usmjerivač može voditi evidenciju o intenzitetu i načinu slanja (ravnomjerno, ili na mahove) za svaki od virtualnih putova koji trenutno prolaze preko njega.

- Usmjerivač može slati precizne obavijesti pojedinim pošiljateljima sa zahtjevima da prilagode svoje ponašanje (intenzitet slanja) onome što je "dogovoreno" kod uspostavljanja danog virtualnog puta, kao i trenutnim mogućnostima toga usmjerivača.

U mrežama koje rade prema načelu uspostavljanja virtualnih putova mogu se koristiti posebni paketi za ispitivanje stanja mreže, odnosno za saznavanje stanja usmjerivača kroz koje prolazi dani virtualni put. Mreža ATM radi sa uspostavljanjem virtualnih putova i koristi svoje pakete za ispitivanje virtualnih putova. U ATM sustavu takvi paketi nazivaju se ćelijama za upravljanje resursima (resource-management cells; skraćeno, RM cells). Ćelije su dio ATM terminologije; ćelije su kratke jedinice podataka (53 bajta) u kojima se prenose veće jedinice podataka (IP paketi) koje su uvrštene u jedan niz ćelija.

Pošiljatelj povremeno šalje RM ćeliju danim virtualnim putem primatelju; ta ćelija ne prenosi podatkovne sadržaje, nego krećući se danim virtualnim putem od izvora do odredišta, skuplja relevantne podatke o stanju toga puta. To su uglavnom podaci o stanju usmjerivača kroz koje ćelija prolazi, odnosno o kapacitetima (propusnosti) koje ti usmjerivači mogu trenutno dodijeliti tom virtualnom putu. Kad RM ćelija stigne na odredište, primatelj vraća tu ćeliju istim putem njenom pošiljatelju. Primatelj može tom prigodom upisati neki svoj upravljački podatak u tu ćeliju, ali ne mora. Na taj način pošiljatelj RM ćelije skuplja podatke o virtualnom putu preko kojeg vrši prijenos.

53

ATM sustav šalje (po difoltu) jednu RM ćeliju na svake 32 podatkovne ćelije. Frekvencija slanja RM ćelija može se mijenjati, odabirom postavki na sustavu. RM ćelije mogu generirati i usmjerivači kroz koje prolaze virtualni putovi. Usmjerivači šalju takve ćelije izravno pošiljatelju sadržaja u tekućem prijenosu; usmjerivači to čine onda kad treba hitno upozoriti nekog pošiljatelja na neku situaciju i kad taj pošiljatelj treba hitno prilagoditi svoje ponašanje toj situaciji. Naprimjer, kod uspostavljanja virtualnog puta, svaki usmjerivač dodjeljuje (jamči) neku propusnost za taj put. Ako pošiljatelj šalje većim intenzitetom od onog kojeg mu je neki usmjerivač odobrio za taj put, onda usmjerivač može to tolerirati, ako ima raspoloživih kapaciteta; u suprotnom, usmjerivač može poslati pošiljatelju RM ćeliju s upozorenjem da ne prekoračuje dopuštenu mjeru, koja mu je odobrena kod uspostavljanja puta.

Izbjegavanje zagušenja kod TCP protokola

Iznijeli smo niz općih načela i metoda prema kojima se štiti usmjerivače od toga da budu zagušeni preintenzivnim slanjem paketa od strane pošiljatelja. Usmjerivače može štititi sam transportni protokol (koji radi na rubu mreže) promatranjem uspješnosti vlastitog prijenosa. Usmjerivači mogu izravno sudjelovati u toj zaštiti, slanjem obavijesti transportnom protokolu o vlastitom stanju. U nastavku govorimo o tome na koji način se izbjegavanje zagušenja mreže izvodi (provodi) kod TCP protokola.

TCP je protokol transportne razine, čija je osnovna odlika da pruža usluge pouzdanog prijenosa. Druga važna odlika TCP protokola je da vodi računa o intenzitetu kojim pošiljatelj šalje TCP vezom segmente primatelju; time štiti primatelja od toga da bude zatrpan IP paketima koje ne može primati onom brzinom kojom ih pošiljatelj šalje, jer nema dovoljno slobodnog prostora u svom prijemnom baferu; time ujedno štiti pošiljatelja od toga da mora ponavljati slanje onih segmenata koje primatelj nije mogao primiti. Ovdje se radi o usklađivanju odnosa između dvaju konkretnih procesa koji se izvode na domaćinima (na pošiljatelju i na primatelju).

Treća važna odlika TCP protokola je da vodi računa o stanju usmjerivača preko kojih se prenose njegovi segmenti (u IP paketima). TCP nastoji prilagoditi intenzitet slanja trenutnim mogućnostima usmjerivača i na taj način izbjeći njihovo zagušenje. Pošiljatelj nema izravan uvid u procese na usmjerivačima, ali stalno procjenjuje stanje usmjerivača na temelju promatranja uspješnosti vlastitog prijenosa.

TCP kao protokol transportne razine, radi samo na završnim sustavima mreže (domaćinima), tako da provodi izbjegavanje zagušenja mreže sa ruba mreže. TCP to čini bez izravne pomoći protokola mrežne razine, jer IP protokol (koji prenosi njegove segmente) ne šalje povratne obavijesti TCPu na završnim sustavima o stanju (opterećenosti, zagušenju) pojedinih usmjerivača u mreži.

Upravljanje intenzitetom slanja, sa ciljem izbjegavanja zagušenja usmjerivača, koje se izvodi na rubu mreže, može se izvoditi na razne načine i na temelju raznih pokazatelja o trenutnom stanju mreže između pošiljatelja i primatelja. Ali ta vrsta upravljanja (sa ruba mreže) uvijek se zasniva na promatranju uspješnosti vlastitog prijenosa, i na procjeni transportnog protokola na kakvo stanje mreže (usmjerivača) ukazuje trenutna uspješnost toga prijenosa.

Svaka strana (završetak) TCP veze je jedan proces koji uključuje memorijske prostore (bafer za prijem segmenata i bafer za slanje segmenata) i niz varijabli, od kojih smo neke spomenuli ranije. Jedna od tih varijabli je veličina slobodnog prostora u prijemnom baferu primatelja; ta veličina naziva se prijemnim prozorom primatelja, a zapisana je u varijabli VelPrimProzora. Primatelj stalno šalje (u potvrdama primitka - ACK) pošiljatelju podatak o veličini svog prijemnog prozora. Na temelju te veličine pošiljatelj izračunava kojim intenzitetom smije slati sadržaje primatelju, a da time ne prekorači veličinu slobodnog prostora u njegovom prijemnom baferu.

Pored veličine prijemnog prozora primatelja (koju saznaje od primatelja), TCP pošiljatelja

54

nastoji sam utvrditi trenutno stanje onih usmjerivača (njihove mogućnosti prijenosa) preko kojih se odvija prijenos njegovih segmenata u danoj TCP vezi. TCP ne zna koji su to usmjerivači, ali vidi kako se odvija njegov prijenos preko njih. Na temelju promatranja uspješnosti svog prijenosa danom TCP vezom, TCP protokol pošiljatelja utvrđuje jednu veličinu koja se naziva prozorom zagušenja (congestion window). Veličina tog prozora pokazuje koliko poslanih a nepotvrđenih segmenata (bajtova) pošiljatelj smije imati u danom trenutku, s obzirom na njegovu procjenu trenutnih mogućnosti prijenosa usmjerivača.

Veličinu prozora za primanje označili smo (ranije) varijablom VelPrimProzora; označimo sada veličinu prozora zagušenja varijablom VelZagProzora. Tada je bilo rečeno da pošiljatelj treba voditi računa o tome da uvijek vrijedi slijedeći odnos:

ZadPoslBajt - ZadPotvrBajt =< VelPrimProzora

To načelo (zahtjev) ograničava količinu poslanih a nepotvrđenih segmenata (bajtova) na pošiljatelju; time se ujedno ograničava intenzitet njegovog slanja segmenata u danoj TCP vezi. Ograničavanjem intenziteta svog slanja na način da uvijek vrijedi gornji odnos, pošiljatelj se osigurava da neće poslati primatelju više segmenata nego ih primatelj može trenutno primiti i da neće doći do odbacivanja njegovih segmenata na primatelju. Uvođenjem prozora zagušenja, gornji odnos treba izmijeniti na slijedeći način:

ZadPoslBajt - ZadPotvrBajt =< min(VelPrimProzora, VelZagProzora)

Dakle, pošiljatelj treba prilagoditi intenzitet svog slanja manjoj od dviju veličina: prijemni prozor primatelja, i prozor zagušenja.

Prilagođavanjem intenziteta slanja gornjem iskazu (načelu rada), TCP protokol na pošiljatelju je siguran da svojim slanjem neće zatrpati primatelja. Poštivanje danog načela rada ujedno daje dobre izglede pošiljatelju da neće zatrpati usmjerivače. Veličina prijemnog prozora je promjenljiva, ali egzaktna veličina; s druge strane, veličina prozora zagušenja je procijenjena veličina. Tu veličinu stalno procjenjuje sam pošiljatelj, prema načelima koje smo iznijeli iznad i na način koji podrobnije opisujemo u nastavku. Ako TCP pošiljatelja dobro procjenjuje veličinu prozora zagušenja za danu TCP vezu, onda svojim slanjem neće izazivati zagušenja usmjerivača. TCP pošiljatelja procjenjuje veličinu prozora zagušenja prvenstveno na temelju kretanja veličine RTT (raste ili opada) i na temelju gubitaka (odbacivanja) segmenata u prijenosu.

U cilju pojednostavljenja opisa, u nastavku uzimamo da je prijemni prozor primatelja uvijek dovoljno velik, tako da govorimo samo o načinu utvrđivanja veličine prozora zagušenja i o tome kako veličina toga prozora utječe na ponašanje pošiljatelja.

Osnovno pitanje u sustavu izbjegavanja zagušenja mreže (usmjerivača) je kako odrediti optimalan intenzitet slanja - to jest, optimalnu veličinu prozora zagušenja. Ako pošiljatelji šalju prevelikim intenzitetom, onda će to dovesti do zagušenja usmjerivača i do pada ukupne količine uspješnog prijenosa, kako smo to opisali ranije. Ako pošiljatelji šalju manjim intenzitetom nego što mreža može prenositi, onda prijenosni kapaciteti mreže neće biti iskorišteni u cijelosti. Dakle, prozor zagušenja ne smije biti prevelik, jer to dovodi do zagušenja usmjerivača, ali nije dobro ni da bude premalen, jer to dovodi do loše iskorištenosti prijenosnih kapaciteta usmjerivača. TCP protokol pokušava utvrditi optimalnu veličinu prozora zagušenja (i time intenziteta slanja) na temelju dvije vrste događaja koje izravno opaža.

Gubitak segmenta u prijenosu - To ukazuje na pojavu zagušenja; gubici segmenata obično se događaju zbog odbacivanja IP paketa (koji ih prenose); takvo odbacivanje događa se na nekom usmjerivaču koji je dosegnuo stanje zagušenja. Pošiljatelj treba oštro smanjiti intenzitet slanja kad dođe do gubitka paketa: to znači da treba smanjiti veličinu svog prozora zagušenja. Ovdje treba odrediti (odabrati) koliko oštro će se smanjiti prozor zagušenja kod gubitka jednog segmenta.

Dolazak nove potvrde o primitku segmenta - Svaki dolazak nove potvrde od primatelja

55

(ACK) o primitku poslanog segmenta pokazuje da mreža nije zagušena i da se prijenos danom TCP vezom odvija uspješno. Tada pošiljatelj može pokušati povećati svoj prozor zagušenja (i intenzitet slanja); pošiljatelj ujedno treba izvršiti takvo povećanje da bi dosegnuo optimalno iskorištenje prijenosnih kapaciteta dane TCP veze i mreže kao cjeline. Ovdje se opet postavlja pitanje koliko povećati veličinu prozora zagušenja za jednu primljenu potvrdu o primitku (ACK).

Za svaku TCP vezu, njen optimalni intenzitet slanja se stalno mijenja sa mijenjanjem stanja mreže i opterećenosti usmjerivača preko kojih se izvodi prijenos IP paketa za tu vezu. TCP protokol pokušava otkrivati optimalni intenzitet slanja (za danu TCP vezu) na taj način da kad primi ACK onda linearno (sporo) poveća prozor zagušenja, a kad se dogodi gubitak segmenta onda oštro (skokovito) smanjuje veličinu prozora zagušenja za tu vezu. Taj proces odvija se stalno, cijelo vrijeme trajanja TCP veze. U TCP protokolu postoji više varijanti računanja prozora zagušenja, o kojima govorimo u nastavku, ali osnovno načelo rada je zajedničko svim varijantama. Prozor zagušenja povećava se polako, za jedan MSS na svakih desetak novih ACK potvrda za redom; prozor zagušenja smanjuje se skokovito kod svakog gubitka segmenta; veličina tog prozora se prepolavlja, ili čak smanjuje na jedan MSS, zavisno od okolnosti o kojima govorimo u nastavku. Nakon oštrog smanjenja prozora zagušenja, taj prozor se opet linearno povećava, sve dok opet ne dosegne stanje zagušenja nekog od usmjerivača, koje se manifestira gubitkom (odbacivanjem) segmenta dane TCP veze.

Takav proces traženja optimalne veličine prozora zagušenja odvija se stalno za svaku TCP vezu posebno. TCP veze općenito povezuju procese na različitim domaćinima, koji mogu biti vrlo blizu jedan drugome (u istoj prostoriji), ali i vrlo daleko jedan od drugoga (na različitim stranama svijeta). Prijenosi mogu prolaziti kroz vrlo malo usmjerivača, ili kroz mnogo (IP protokol dopušta do 64); zato se optimalne veličine prozora zagušenja računaju zasebno za svaku TCP vezu i ta računanja su međusobno nezavisna.

Iznesimo opis procesa (algoritam) prema kojem se određuje veličinu prozora zagušenja kod protokola TCP. Ovdje je teško dati precizan i potpun opis jer postoji više varijanti i implementacija tog procesa računanja, koje se međusobno razlikuju u nekim stvarima. Osnovni način računanja prozora zagušenja kod TCP protokola je jednostavan i njega opisujemo u nastavku; sa specifičnostima raznih varijanti ne moramo se ovdje baviti.

Dakle, proces izračunavanja veličine prozora zagušenja kod TCP protokola sastoji se od tri dijela koji se nazivaju: (1) spori početak, (2) izbjegavanje zagušenja, i (3) brzo oporavljanje. Prva dva dijela procesa (algoritma) su obavezna i trebaju biti sadržana u svakoj implementaciji TCP protokola; treći dio je opcionalan, što znači neobavezan. TCP specifikacije preporučaju da se uključi i taj dio, ali to ne zahtijevaju.

Treći dio služi uglavnom za to, što se različito tretiraju (1) gubitak paketa (segmenta) na kojeg ukazuje istek tajmera, i (2) gubitak paketa na kojeg ukazuje primitak triju uzastopnih ponovljenih potvrda primitka segmenta n, čime primatelj javlja (pošiljatelju) da je došlo do gubitka segmenta n+1. Taj izraz "primitak triju uzastopnih ponovljenih potvrda primitka segmenta n" se često javlja u nastavku, pa ćemo ga zamijeniti sa izrazom "primitak (+3 ACK)"

Istek tajmera obično ukazuje na veći stupanj zagušenja mreže (usmjerivača) i/ili domaćina na kojeg se vrši prijenos. Primitak (+3 ACK) pokazuje da je došlo do gubitka segmenta, ali isto tako pokazuje da je nakon izgubljenog segmenta primatelj primio još barem tri segmenta, što znači da se prijenos ipak odvija relativno dobro. Zato se kod gubitka segmenta zbog isteka tajmera prijenos usporava mnogo jače nego kod gubitka segmenta na kojeg pokazuje primitak (+3 ACK). Zato je uveden treći dio procesa računanja veličine prozora zagušenja, koji se naziva brzo oporavljanje; u tom dijelu se slučajevi primitka (+3 ACK) tretiraju različito od slučajeva sa istjecanjem tajmera. U nastavku iznosimo opise tih stvari, uz izostavljanje nekih pojedinosti koje nisu neophodne.

Spori početak - Kod uspostavljanja TCP veze, početna veličina prozora zagušenja

56

postavlja se na vrijednost 1 MSS; podsjetimo, to je jedna najveća dužina segmenta (maximal segment size). Ako je domaćin vezan na Internet preko lokalne mreže Ethernet, onda MSS početne dionice TCP veze koja kreće sa tog domaćina iznosi 1460 bajtova. To praktički znači da u početku prijenosa, pošiljatelj šalje u TCP vezu samo jedan segment, a zatim čeka da dobije povratnu potvrdu (ACK) o njegovu primitku.

TCP pošiljatelja želi slati čim brže, zato želi čim prije saznati (i dosegnuti) najveću brzinu slanja koju mreža omogućava u danom trenutku. Zato za svaki primljeni ACK, pošiljatelj smjesta šalje dva segmenta; taj proces udvostručavanja broja segmenata prikazuje slika 2.20.

Slika 2.20 Spori početak kod TCP veze

Dakle, u fazi sporog početka, prijenos počinje slanjem jednog segmenta; nakon toga za svaki primljeni ACK, pošiljatelj šalje dva segmenta. Takav način rada znači da se broj poslanih segmenata udvostručava otprilike svakih RTT sekundi. Takvo udvostručavanje broja poslanih segmenata odvija se sve dok se ne dogodi prvi gubitak segmenta (to jest, IP paketa koji ga prenosi). Tu sad postoje dvije osnovne mogućnosti koje smo spomenuli iznad.

Ako na gubitak segmenta ukazuje istek tajmera (teži slučaj), onda TCP protokol pošiljatelja čini slijedeće:

- Postavlja prozor zagušenje na 1 MSS.- U varijablu PragSP (prag sporog početka) zapisuje vrijednost koja je jednaka polovici

veličine koju je dosegnuo prozor zagušenja u trenutku kad je došlo do isteka tajmera (i gubitka segmenta).

- Izvodi ponovno proces sporog početka; pritom najprije ponavlja slanje onog segmenta koji je izgubljen.

57

Ponovljeni spori početak odvija se kao i ranije, a završava kad nova veličina prozora zagušenja dosegne (ili prekorači) vrijednost varijable PragSP. Tada bi bilo previše riskantno udvostručiti broj poslanih segmenata (u slijedećem RTT), jer je takvo udvostručenje dovelo do zagušenja nekog usmjerivača i do gubitka segmenta kod prvog pokretanja procesa sporog početka. Zato kad vrijednost prozora zagušenja dosegne (ili prijeđe) vrijednost varijable PragSP, proces sporog početka je završen. Završetkom faze sporog početka, proces računanja prozora zagušenja ulazi u fazu koja se naziva izbjegavanjem zagušenja. U toj fazi, veličina prozora zagušenja povećava se mnogo sporije (po 1 MSS) nego u fazi sporog početka.

Ako se u fazi sporog početka dogodi gubitak segmenta, na kojeg ukazuje primitak (+3 ACK), onda TCP ponavlja slanje izgubljenog segmenta i ulazi u treću fazu, koju se naziva "brzim oporavljanjem". Kad na gubitak segmenta ukazuje primitak (+3 ACK), onda se smatra da stanje mreže (usmjerivača) nije jako loše; zato se u fazi brzog oporavljanja, veličinu novog prozora zagušenja ne postavlja na 1 MSS (kao iznad), nego na polovicu veličine koju je taj prozor imao u trenutku kad je došlo do gubitka segmenta na kojeg ukazuje primitak (+3 ACK).

Izbjegavanje zagušenja - Na završetku faze sporog početka, veličina prozora zagušenja iznosi polovicu (ili malo više) od one veličine toga prozora kod koje je došlo do prethodnog gubitka segmenta. Zato sada ne bi valjalo povećavati veličinu toga prozora njegovim udvostručenjem (kao u početnoj fazi) jer bi to vjerojatno odmah dovelo do zagušenja i do odbacivanja IP paketa (koji nose TCP segmente). Umjesto udvostručavanja, prozor zagušenja se sada povećava za jedan MSS svakih nekoliko RTT vremena.

Zavisno od veličine prozora zagušenja, TCP pošiljatelja može poslati veći broj segmenata u jednom RTT vremenu; ako se u tom vremenu ne dogodi gubitak nekog od segmenata (u toj TCP vezi u tom smjeru), onda TCP pošiljatelja povećava prozor zagušenja te TCP veze za 1 MSS (to jest, za jednu maksimalnu veličinu segmenta u toj TCP vezi). U fazi izbjegavanja zagušenja, TCP pošiljatelja postupa stalno na taj način: svakih nekoliko RTT vremena povećava svoj prozor zagušenja za 1 MSS.

Povećavajući na taj način (dakle, polako, linearno) prozor zagušenja na pošiljatelju u fazi izbjegavanja zagušenja, veličina tog prozora će u jednom trenutku porasti toliko, da će dovesti do gubitka segmenta. U toj fazi se opet razlikuje slučaj kad na gubitak segmenta ukazuje istek tajmera, od situacije kad na gubitak segmenta ukazuje primitak (+3 ACK). Istek tajmera smatra se većim problemom. Jer primitak (+3 ACK) pokazuje da je jedan segment izgubljen, ali pokazuje i da su tri segmenta koja su poslana nakon njega, uspješno prenijeta na odredište. To znači da mreža nije jako zagušena (jer su tri segmenta prenijeta), ali ipak jest zagušena (jer je jedan segment vjerojatno odbačen na putu).

Rekli smo da postoji više varijanti (implementacija) TCP protokola, sa čijim specifičnostima ne trebamo se ovdje baviti. U načelu, ako na gubitak segmenta ukazuje istjecanje tajmera, onda TCP protokol u fazi izbjegavanja zagušenja postupa jednako kao kad se takav gubitak dogodi u fazi sporog početka. Dakle, TCP čini slijedeće:

- Postavlja veličinu prozora zagušenja na 1 MSS.- U varijablu PragSP (prag sporog početka) zapisuje vrijednost koja je jednaka polovici

veličine koju je dosegnuo prozor zagušenja u trenutku kad je došlo do isteka tajmera (i gubitka segmenta).

- Izvodi proces sporog početka; najprije ponavlja slanje onog segmenta koji je izgubljen, a zatim nastavlja povećavati prozor zagušenja slanjem po dva segmenta za svaki primljeni ACK - to jest, udvostručavanjem količine poslanih segmenata svakih RTT sekundi. Tako postupa dok ne dosegne veličinu PragSP; nakon toga povećava prozor zagušenja za 1 MSS svakih nekoliko RTT vremena, kako je to činio ranije.

Ako se gubitak segmenta utvrdi primitkom (+3 ACK), onda TCP ponavlja slanje izgubljenog segmenta, a veličinu prozora zagušenja postavlja na polovicu veličine toga prozora u trenutku gubitka segmenta. Zatim nastavlja slati nove segmente, uz povećavanje prozora za 1 MSS

58

svakih nekoliko RTT vremena.

Brzo oporavljanje - Ovo je neobavezan dio procesa računanja veličine prozora zagušenja kod TCP protokola. Specifikacije TCP protokola (RFCi) preporučaju da se taj dio uključi u proces računanja veličine prozora zagušenja, ali ne zahtijevaju da taj dio bude uključen. Taj podproces uvodi razne varijacije u načinu smanjivanja i povećavanja veličine prozora zagušenja, zavisno od okolnosti, s kojima se ovdje ne trebamo baviti. Kod gubitka segmenta, TCP protokol postupa na slijedeći osnovni način:

(1) Kad na gubitak segmenta ukaže istek tajmera, onda se veličina prozora zagušenja smanjuje na 1 MSS; nakon toga kreće proces povećavanja toga prozora na način kako je to opisano iznad: udvostručavanjem do vrijednosti PragSP, a zatim linearno.

(2) Kad na gubitak segmenta ukaže primitak (+3 ACK), onda se veličina prozora zagušenja smanjuje na polovicu trenutne vrijednosti toga prozora; nakon toga se veličina tog prozora povećava linearno, za 1 MSS svakih RTT sekundi.

Ali postoje razne varijante TCP protokola. Starija varijanta zvana TCP Tahoe smanjuje veličinu prozora zagušenja na 1 MSS kod svakog gubitka segmenta (i zatim kreće sa sporim početkom) bez obzira da li je na taj gubitak ukazao istek tajmera, ili primitak (+3 ACK). Novija varijanta zvana TCP Reno ponaša se drukčije. Ako je na gubitak segmenta ukazao primitak (+3 ACK), prozor zagušenja postavlja se na pola trenutne vrijednosti, a zatim se linearno povećava.

Varijanti ima još; u nastavku ćemo spomenuti i TCP Vegas, koja uvodi neke svoje specifičnosti. Graf na slici 2.21 pokazuje kretanje veličine prozora zagušenja kod TCP Tahoe i kod TCP Reno u situaciji kad je na gubitak segmenta ukazao primitak (+3 ACK).

59

Slika 2.21 Kretanja prozora zagušenja kod TCP Tahoe i TCP Reno

Različite varijante računanja veličine prozora zagušenja nastaju kao rezultat pokušaja da se novu veličinu toga prozora (nakon gubitka segmenta) postavi čim prije na čim veću vrijednost, ali ne na preveliku vrijednost. Čim veća vrijednost prozora zagušenja poželjna je zato što veći prozor zagušenja dopušta veću brzinu slanja. Prevelika vrijednost prozora zagušenja nije dobra jer dovodi do gubitka segmenata, a onda i do (barem) prepolavljanja prozora zagušenja, a time i brzine slanja segmenata, što nije dobro.

Osim u početnoj fazi (spori početak), TCP protokol povećava prozor zagušenja linearno, za 1 MSS svakih nekoliko RTT vremena (intervala). Kod gubitka segmenta, TCP smanjuje prozor zagušenja skokovito. Veličina skoka može biti različita, zavisno od vrste gubitka segmenta i od varijante TCPa, kako smo to opisali iznad. Ali bez obzira na različite varijante računanja veličine prozora zagušenja, kretanje veličine tog prozora (nakon početne faze) ima uvijek oblik obrnute pile, kako to ilustrira graf na slici 2.22. Na toj slici, veličina prozora zagušenja prepolavlja se kod gubitaka segmenata, što znači da na te gubitke ovdje ukazuje primitak (+3 ACK).

60

Slika 2.22 Osvovni oblik kretanja veličine prozora zagušenja

TCP općenito povećava prozor zagušenja pribrajanjem, a smanjuje taj prozor dijeljenjem. Na engleskom to zvuči malo složenije: "additive-increase, multiplicative-decrease" (AIMD). Izraz "multiplicative" ne zvuči primjereno, jer se veličina prozora prepolavlja (dijeli, a ne množi), ali ovdje taj izraz možemo shvatiti kao "višestruko smanjivanje": dakle, prozor se smanjuje za više MSSa.

U svakom slučaju, nakon početne faze, veličina prozora povećava se linearno, za 1 MSS svakih nekoliko RTT vremena; kad se dogodi gubitak segmenta, veličina prozora se prepolavlja (primitak (+3 ACK)), ili smanjuje na 1 MSS (istek tajmera). U prvom slučaju slijedi linearno povećavanje prozora zagušenja; u drugom slučaju slijedi faza sporog početka (sa udvostručavanjem prozora zagušenja do vrijednosti PragSP), a zatim linearno povećavanje, kako je to opisano iznad.

Većina implementacija TCP protokola koristi varijantu TCP Reno računanja veličine prozora zagušenja. Kod instaliranja TCP protokola može se odabrati koju verziju TCPa će se instalirati (koristiti) na nekom domaćinu. Postojanje različitih verzija TCP protokola ne ometa komunikaciju TCPa sa jednog domaćina sa TCPima na drugim domaćinima. Jer one stvari koje su specifične za pojedine verzije TCPa - naprimjer, način računanja veličine prozora zagušenja - imaju samo lakalan učinak na način rada TCPa.

Veličina prozora zagušenja na pošiljatelju određuje koliko poslanih a nepotvrđenih segmenata smije pošiljatelj imati u danom trenutku. To ujedno određuje najveću brzinu kojom taj pošiljatelj smije slati segmente. Problem nalaženja najboljeg načina utvrđivanja veličine prozora zagušenja je predmet stalnih istraživanja i isprobavanja. Spomenimo još jednu mogućnost s tim u vezi, koju uvodi varijanta TCP protokola zvana Vegas. Ta varijanta TCP protokola nastoji doseći

61

optimalnu veličinu prozora zagušenja, bez da pritom prekorači granicu trenutno mogućeg i da izazove gubitak segmenta, odnosno zagušenje usmjerivača.

TCP Vegas promatra kretanje veličine RTT za segmente koje šalje. Rast RTTa ukazuje na to da su redovi čekanja na usmjerivačima sve duži; dakle, prijemni prostori na usmjerivačima su sve više ispunjeni, tako da bi uskoro moglo doći do odbacivanja segmenata kad stignu (u IP paketima) na neki usmjerivač čiji je prijemni prostor sasvim zauzet. Zato kad TCP Vegas zaključi da je RTT postao prevelik, onda smanjuje veličinu prozora zagušenja za 1 MSS. Dakle, smanjivanje se ovdje izvodi prije gubitka segmenta, i to linearno, a ne skokovito.

Kada treba smatrati da je RTT postao prevelik, tako da je vrijeme za smanjenje prozora zagušenja? To se ne može znati precizno, jer se stanje prometa u mreži mijenja, ali ako se RTT približi vrijednosti kod koje je ranije bio izgubljen (odbačen) neki segment (u toj vezi), onda je vjerojatno vrijeme da se smanji prozor zagušenja za 1 MSS, i time malo uspori intenzitet slanja.

Strukturne osobine protokola TCP i njegov način rada se stalno promatraju i ispituju. Među razloge za takva ispitivanja spadaju stalan porast memorijskih kapaciteta čvorova, brzine rada procesnih jedinica, i propusnosti veza. U primjerima koji se navode u literaturi, segmenti su obično veliki oko 1 KB, a prozori zagušenja obično dosežu veličine od nekoliko desetaka segmenata (to jest, nekoliko desetaka kilobajtova).

Veličinu segmenata određuje veličina okvira (na razini veze podataka) u kojima se prenose IP paketi, koji prenose TCP segmente, koji prenose sadržaje (poruke) aplikacijske razine. Veličina okvira je obično mala; naprimjer, tijelo okvira u mreži Ethernet može sadržavati do 1500 bajtova; to praktički znači da može prenositi segmente koji nose 1460 bajtova sadržaja (poruke), jer 20 bajtova zauzima zaglavlje IP paketa, a 20 bajtova zaglavlje TCP segmenta. To onda znači da za prijenos nekog video sadržaja od 2 GB treba prenijeti ogroman broj TCP segmenata. Ako se veličinu segmenta (u postojećim mrežama) ne može lako mijenjati (povećati), onda valja tražiti načine optimalnog dimenzioniranja bafera za primanje segmenata, bafera za slanje segmenata i prozora zagušenja, tako da se iskoriste velike propusnosti usmjerivača i veza, na najbolji način.

Opisali smo na koji način TCP protokol usporava prijenos TCP vezama, sa ciljem da se izbjegne zagušenje usmjerivača (mreže). Takav način rada TCP protokola je općenito "dobar za mrežu", ali takav način rada je ujedno razlog što neke aplikacije ne koriste usluge TCP protokola, nego koriste UDP protokol, koji ne vodi računa o zagušenju mreže, niti ograničava brzinu svog prijenosa. Takve su naprimjer aplikacije koje za telefoniranje preko Interneta i aplikacije za izravni video-prijenos. Takve aplikacije nisu osjetljive na manje gubitke sadržaja, tako da im nije potreban pouzdan prijenos kakav nudi TCP; nadalje, ponovno poslani segmenti stigli bi prekasno i ne bi mogli biti upotrijebljeni, jer razgovor i događaj su otišli dalje. Zbog toga takve aplikacije ne žele da se njihov prijenos usporava zbog postizanja pouzdanosti prijenosa, ili iz bilo kojeg drugog razloga, bez obzira na stanje mreže, jer je kod takvih aplikacija brzina važnija od potpune točnosti.

TCP protokol usporava prijenos da bi izbjegao zagušenja usmjerivača, a UDP to ne čini; zato se događa da UDP prijenosi istiskuju TCP prijenose s kojima se susreću na usmjerivačima. Obje vrste prijenosa troše kapacitete usmjerivača i veza, ali TCP vodi računa o stanju mreže i smanjuje intenzitet svog prijenosa kad je to potrebno. UDP to ne čini, nego koristi kapacitete koje TCP oslobađa usporavanjem svog slanja. Jedan od problema u području upravljanja intenzitetom prijenosa i izbjegavanja zagušenja usmjerivača je kako ograničiti intenzitet slanja UDP protokola, tako da se spriječi (pretjerano) istiskivanje TCP prijenosa, i zagušenje usmjerivača. Potrebno je da postoje dva transportna protokola, TCP i UDP, koji imaju različita svojstva, jer različitim vrstama aplikacija trebaju prijenosni protokoli različitih svojstava. Ali pritom ti protokoli ne bi smjeli biti takvi da prijenosi jednog protokola previše istiskuju druge.

Konačno, i TCP protokol omogućava "varanje" po pitanju kontrole intenziteta prijenosa i izbjegavanja zagušenja mreže. TCP protokol omogućava uspostavljanje više paralelnih TCP

62

veza između istih komunikatora. Naprimjer, web preglednik može uspostaviti više TCP veza paralelno (istodobno) sa istim web serverom, i preko svake od tih veza zatražiti (i dobiti) od servera jedan od objekata (datoteka) koji su mu potrebni za tvorbu jedne web stranice. Preglednici obično omogućuju da se u konfiguraciji odabere koliko (broj) paralelnih veza (prema istom serveru) preglednik može uspostaviti. Uspostavljanjem deset paralelnih TCP veza sa nekim serverom, neki preglednik može trošiti kapacitete usmjerivača daleko natprosječno, bez obzira na to što se u prijenosu svakom od tih veza ponaša "suzdržano", kao i svi drugi komunikatori koji koriste TCP veze.

Dakle, sustav za ograničavanje intenziteta prijenosa zbog zaštite usmjerivača od zagušenja, kojeg smo opisali iznad, odnosi se na jednu vezu. Ali ako preglednik P1 prenosi (prima) sadržaje sa servera S preko jedne TCP veze, a preglednik P2 prima sadržaje od istog servera preko pet ili deset paralelnih TCP veza, onda će preglednik P2 trošiti višestruko više kapaciteta veza, usmjerivača i servera S, nego što to čini P1. To ne znači da je govor o optimiziranju prometa u mreži beskoristan, jer UDP ne podliježe optimizaciji, a TCP može izbjeći njena ograničenja korištenjem većeg broja paralelnih veza. Ali to pokazuje da su pitanja (1) upravljanja intenzitetom slanja, (2) optimalnog korištenja kapaciteta mreže, i (3) sprječavanja zagušenja usmjerivača uvelike otvorena. Stvaraju se nove tehnološke mogućnosti i ispituju se nova rješenja.

+

63