Dohadov´an´ı vlastnost´ı spojen´ı m˚uˇze b´yt pouˇzito jak na TCP tak na UDP spojen´ı, ovˇsem ne vˇsechny vlastnosti m´a smysl dohadovat na TCP nebo na-opak UDP spojen´ı. Napˇr´ıklad je irelevantn´ı snaˇzit se dohadovat typ Conges-tion Control pro TCP spojen´ı a naopak nen´ı moˇzn´e dohadovat URL nov´eho UDP spojen´ı na jiˇz existuj´ıc´ım UDP spojen´ı.
Dohadov´an´ı o Flow Control a Congestion Control
Dohadov´an´ı o Flow Control (FC) a Congestion Control (CC) m˚uˇze pro-b´ıhat pouze na UDP spojen´ı bˇehem jeho handshaku. Klient a server se mus´ı
dohodnout jak´e algoritmy budou pouˇz´ıvat a z´aroveˇn je poˇzadov´ano, aby kli-ent i server pouˇz´ıvaly stejn´y algoritmus pro FC a stejn´y algoritmus pro CC.
Nen´ı moˇzn´e, aby klient pouˇz´ıval jin´y algoritmus pro FC neˇz jak´y pouˇz´ıv´a server. Pro dohadov´an´ı FC a CC jsou definov´any n´asleduj´ıc´ı hodnoty:
• FC RESERVED = 0 je rezervovan´a hodnota, kter´a by se nikdy nemˇela pouˇzita k nastaven´ı FC
• FC NONE = 1 je hodnota, kter´a ˇr´ık´a, ˇze klient i server nebudou pouˇz´ıvat FC
• FC TCP LIKE = 2 je hodnota, kter´a ˇr´ık´a, ˇze klient i server budou pouˇz´ıvat FC odvozen´y z TCP
• CC RESERVED = 0 je rezervovan´a hodnota, kter´a by se nikdy nemˇela pouˇzita k nastaven´ı CC
• CC NONE = 1 je hodnota, kter´a ˇr´ık´a, ˇze klient i server nebudou pouˇz´ıvat CC
• CC TCP LIKE = 2 je hodnota, kter´a ˇr´ık´a, ˇze klient i server budou pouˇz´ıvat CC odvozen´y z TCP
Dohadov´an´ı o FPS
Klient by si mˇel se serverem pr˚ubˇeˇznˇe dohadovat, jak´y je moment´alnˇe schopn´y pouˇz´ıvat FPS pro zobrazov´an´ı sd´ılen´ych dat. Hlavn´ı d˚uvod pouˇzit´ı dohadov´an´ı je ve spr´avn´em nastaven´ı ˇcasovaˇc˚u pro pˇrepos´ıl´an´ı paket˚u. Klien-tova hodnota FPS se m˚uˇze s ˇcasem mˇenit. D˚uvodem m˚uˇze b´yt velk´e zat´ıˇzen´ı poˇc´ıtaˇce, zmˇena nastaven´ı apod. Klient by mˇel dohadovat zmˇenu FPS jenom v pˇr´ıpadˇe, ˇze se zmˇen´ı v´ıce jak o 5 % a trv´a d´ele jak 2/FPS s.
Dalˇs´ı teoretick´e vyuˇzit´ı dohadov´an´ı o FPS je uk´az´ano v pˇr´ıkladu, kter´y je zn´azornˇen na obr´azku 4.16
V tomto pˇr´ıkladu bude prvn´ı klient pos´ılat pakety s frekvenc´ı, kter´a od-pov´ıd´a 120 FPS, protoˇze pouˇz´ıv´a zobrazovac´ı zaˇr´ızen´ı, kter´e to umoˇzˇnuje.
Dalˇs´ı klient je ovˇsem schopn´y zobrazovat informace maxim´alnˇe s 60 FPS.
Kdyˇz by server pˇrepos´ılal pakety obsahuj´ıc´ı polohu pohybuj´ıc´ıho se objektu s frekvenc´ı 120 Hz, tak by byl druh´y klient schopn´y zobrazit pouze kaˇzdou druhou polohu z obdrˇzen´ych paket˚u. Nav´ıc s´ıt’ov´y provoz generovan´y na lince od serveru ke druh´emu klientovi je dvojn´asobnˇe velk´y neˇz je potˇreba a m˚uˇze na dan´e lince zp˚usobit zahlcen´ı pˇrenosov´ych cest. Kdyˇz si druh´y klient do-hodne se serverem, ˇze je moment´alnˇe schopn´y zobrazovat pouze 60 FPS, server by tomu mˇel pˇrizp˚usobit frekvenci odes´ıl´an´ı paket˚u.
Obr´azek 4.16: Dva Verse klienti s r˚uzn´ym FPS Dohadov´an´ı o URL
Uniform Resource Locator (URL) [6] nov´eho datagramov´eho spojen´ı si mohou klient a server dohodnout pouze na TCP spojen´ı po autentizaci kli-enta. Z vlastn´ıho URL by mˇel klient a server vyuˇz´ıvat pouze sch´ema, ad-resu ve formˇe dom´enov´eho jm´ena nebo IP adresy a port. Ostatn´ı poloˇzky (uˇzivatelsk´e jm´eno, dokument, atd.) by nemˇely b´yt odes´ıl´any. Pˇri pˇrijet´ı pˇr´ıkazu obsahuj´ıc´ıho URL s nadbyteˇcn´ymi poloˇzkami by mˇely b´yt tyto po-loˇzky ignorov´any. Speci´aln´ı v´yznam m´a sch´ema URL, protoˇze v nˇem se nastavuj´ı z´akladn´ı vlastnosti nov´eho datagramov´eho spojen´ı. Sch´ema URL mus´ı zaˇc´ınat ˇretˇezcem verse. Za n´ım n´asleduje ˇretˇezec identifikuj´ıc´ı datagra-mov´y transportn´ı protokol. Na konci sch´ematu mus´ı b´yt uveden ˇretˇezec identifikuj´ıc´ı protokol pouˇz´ıvan´y pro zabezpeˇcen´ı datagramov´eho spojen´ı.
Vˇsechny tˇri ˇc´asti sch´ematu mus´ı b´yt oddˇeleny znakem pomlˇcky. Podporovan´y transportn´ı protokol je v souˇcasn´e dobˇe pouze UDP, kter´y je identifikov´an ˇretˇezcem upd. Pokud nen´ı vyˇzadov´ano zabezpeˇcen´ı datagramov´eho spojen´ı, pak je na konci sch´ematu ˇretˇezec none. Pˇri poˇzadavku na zabezpeˇcen´ı da-tagramov´eho spojen´ı je moˇzn´e pouˇz´ıt protokol DTLS [31] [28], kter´y je iden-tifikov´an ˇretˇezcem dtls. Cel´e sch´ema je dle specifikace ukonˇceno ˇretˇezcem ://. V souˇcasn´e verzi protokolu je tedy moˇzn´e pouˇz´ıt pouze dvˇe varianty sch´ematu:
• verse-udp-none://
• verse-udp-dtls://
C´ıslo portu m˚ˇ uˇze b´yt vyj´adˇreno bud’ jako ˇc´ıslo nebo jako textov´y identi-fik´ator standardizovan´y organizac´ı IANA.
Dohadov´an´ı o Cookie
Po dohodnut´ı nov´eho UDP spojen´ı zaˇcne server poslouchat na dohod-nut´em portu. Na tento port m˚uˇze kdokoliv odeslat paket a server by mˇel m´ıt moˇznost ovˇeˇrit, ˇze dan´y paket poch´az´ı od klienta, kter´y byl autentizov´an na TCP spojen´ı. Stejnˇe tak klient by mˇel m´ıt moˇznost ovˇeˇrit, ˇze server je ten za koho se vyd´av´a. K tomuto ´uˇcelu slouˇz´ı n´ahodnˇe vygenerovan´a hod-nota Cookie. Jej´ı doporuˇcen´a d´elka je 16 znak˚u. Dohadovan´a hodnota Cookie je pˇren´aˇsena jako string16 a m˚uˇze obsahovat i netisknuteln´e znaky. Pˇr´ıkazy Change a Confirm pro dohadov´an´ı Cookie lze pouˇz´ıvat jak na TCP, tak na UDP spojen´ı. Na TCP spojen´ı slouˇz´ı k dohadov´an´ı nov´ych hodnot Cookie a na UDP spojen´ı slouˇz´ı k prok´az´an´ı identity klienta a serveru.
Dohadov´an´ı o Data Exchange Definition
Data Exchange Definition (DED) je n´avrh mechanismu, kter´y by mˇel umoˇzˇnovat serveru kontrolovat konzistenci sd´ılen´ych dat. Pˇredchoz´ı verze protokolu Verse kladla nˇekter´a omezen´ı na strukturu sd´ılen´ych dat. U sou-ˇ
casn´eho protokolu tomu tak nen´ı a datov´y model je navrˇzen velmi obecnˇe.
Nˇekter´ym aplikac´ım tento pˇr´ıstup nemus´ı vyhovovat a mohou vyˇzadovat, aby se ostatn´ı Verse klienti ˇr´ıdili dalˇs´ımi pravidly pˇri sd´ılen´ı dat. M˚uˇze b´yt poˇzadov´ano, aby sd´ılen´a data mˇela omezen´e rozsahy hodnot, poˇcet poloˇzek, apod. K tomuto ´uˇcelu je urˇcen´y DED, coˇz je odkaz na dokument, kter´y by mˇel definovat tato pravidla.
Dohadov´an´ı o datagramov´em spojen´ı
Vlastn´ı dohadov´an´ı o nov´em datagramov´em spojen´ı zaˇcne server t´ım, ˇze do zpr´avy obsahuj´ıc´ı pˇr´ıkaz UserAuthSuccess pˇrid´a i pˇr´ıkaz Change L obsa-huj´ıc´ı jeden n´avrh Cookie a pˇr´ıkaz Change R obsahuj´ıc´ı jeden n´avrh DED.
Server zasl´an´ım tˇechto dvou zpr´av ˇr´ık´a klientovi, jakou bude vyˇzadovat Coo-kie pˇri posl´an´ı prvn´ıho prvn´ıho paketu na datagramov´em spojen´ı a jak´a jsou dalˇs´ı pravidla pˇri sd´ılen´ı dat na serveru.
Kdyˇz nen´ı klient schopen dodrˇzovat pravidla popsan´a v DED, tak by mˇel odpovˇedˇet pˇr´ıkazem uveden´ym na obr´azku 4.17 a server by mˇel s klientem ukonˇcit spojen´ı.
Pokud je klient schopn´y dodrˇzovat pravidla definovan´a v DED, tak by mˇel v n´asleduj´ıc´ı odpovˇedi serveru zaslat pˇr´ıkaz Confirm R obsahuj´ıc´ı navr-hovan´e DED a pˇr´ıkaz Confirm L potvrzuj´ıc´ı navrhovan´e Cookie. D´ale tato
. .
Obr´azek 4.17: Pˇr´ıklad odpovˇedi klienta na nepodporovan´e DED zpr´ava mus´ı obsahovat pˇr´ıkaz s n´avrhem URL, kter´e mus´ı obsahovat IP ad-resu serveru pomoc´ı kter´e je klient k tomuto serveru pˇripojen´y. M´ısto ˇc´ısla portu by mˇela b´yt v URL uvedena pouze hvˇezdiˇcka, protoˇze ˇc´ıslo portu vybere n´aslednˇe server. Nakonec zpr´ava m˚uˇze obsahovat pˇr´ıkaz Change R s n´avrhem Cookie pokud bude klient vyˇzadovat aby i server prok´azal na da-tagramov´em spojen´ı svoji identitu. Tato ˇc´ast dohadov´an´ı o nov´em spojen´ı je pops´ana na obr´azku 4.18.
. .
Obr´azek 4.18: Pˇr´ıklad odpovˇedi klienta na podporovan´e DED
Kdyˇz server pˇrijme zpr´avu s potvrzen´ım DED a Cookie, tak n´ahodnˇe vybere voln´y UDP port a zaˇcne na nˇem poslouchat. Server nemus´ı vyslyˇset poˇzadavek klienta na vytvoˇren´ı zabezpeˇcen´eho nebo nezabezpeˇcen´eho da-tagramov´eho spojen´ı a m˚uˇze se ˇr´ıdit vlastn´ı bezpeˇcnostn´ı politikou. Jedin´e, co je pro server z n´avrhu URL smˇerodatn´e, je navrhovan´a IP adresa, protoˇze tu server dopln´ı o platn´e sch´ema a pouˇzit´y port a poˇsle klientovi v nov´em n´avrhu. Server totiˇz nesm´ı potvrdit klient˚uv n´avrh na URL uˇz jen proto, ˇze klient mˇel ve sv´em n´avrhu m´ısto portu uveden znak hvˇezdiˇcky.
Server tedy odeˇsle klientovi zpr´avu s pˇr´ıkazem Confirm R(URL()), kter´y
klientovi signalizuje, ˇze neakceptuje jeho n´avrh URL obsahuj´ıc´ı m´ısto portu znak hvˇezdiˇcky. Server do paketu pˇrid´a pˇr´ıkaz Change L s vlastn´ım n´avrhem platn´eho URL a pokud to klient vyˇzadoval, tak i potvrzen´ı Cookie. Na tuto odpovˇed’ m´a server limit 30 sekund. Pˇri jeho nedodrˇzen´ı by mˇel klient spojen´ı se serverem ukonˇcit.
V pˇr´ıpadˇe, ˇze se serveru nepodaˇr´ı otevˇr´ıt voln´y UDP port, tak odeˇsle klientovi zpr´avu s pr´azdn´ym pˇr´ıkazem Confirm R(URL()) a ukonˇc´ı spojen´ı.
Klient se po pˇrijmut´ı zpr´avy obsahuj´ıc´ı n´avrh platn´eho URL pokus´ı prov´est handshake na UDP spojen´ı a teprve kdyˇz uspˇeje, tak serveru navrhovan´e URL potvrd´ı. Kdyby handshake na UDP spojen´ı z nˇejak´eho d˚uvodu selhal, tak klient odpov´ı serveru na jeho n´avrh URL zpr´avou obsahuj´ıc´ı pr´azdn´y pˇr´ıkaz Confirm L(URL()). Server a klient by mˇely n´aslednˇe uzavˇr´ıt spo-jen´ı. Handshake na UDP spojen´ı bude podrobnˇe pops´an v kapitole 4.6. Cel´y pr˚ubˇeh nav´az´an´ı spojen´ı mezi klientem a serverem je pops´an na obr´azku 4.21.
Server by mˇel ˇcekat na potvrzen´ı URL v´yjimeˇcnˇe 60 sekund, protoˇze handshake na UDP spojen´ı m´a tak´e nˇekolik f´az´ı a kaˇzd´a m´a sv˚uj 30 sekun-dov´y ˇcasov´y limit.
Delegace datagramov´eho spojen´ı
D˚uvodem pouˇzit´ı URL pro dohadov´an´ı nov´eho datagramov´eho spojen´ı je i teoretick´a moˇznost delegovat datagramov´e spojen´ı na jin´y server (Sla-veServer) a rozloˇzit z´atˇeˇz hlavn´ıho serveru (MasterServer). Dalˇs´ı vyuˇzit´ı to-hoto pˇr´ıstupu by mohlo b´yt pˇrepojov´an´ı klient˚u na SlaveServery podle geolo-kace, uˇzivatelsk´eho jm´ena, dohodnut´eho DED, apod. Touto problematikou se zab´yvaj´ı pr´ace [26] [8]. Delegov´an´ı datagramov´eho spojen´ı by komplikovalo dohadov´an´ı o nov´em spojen´ı. Pˇrednˇe by bylo nutn´e vytvoˇrit zabezpeˇcen´y ko-munikaˇcn´ı kan´al mezi MasterServerem a SlaveServerem pomoc´ı kter´eho by se pˇren´aˇsely informace o autentizovan´ych klientech, Cookie, apod. SlaveSer-ver by se nav´ıc musel v nˇekter´ych pˇr´ıpadech chovat v˚uˇci MasterServeru jako Verse klient, coˇz by d´ale komplikovalo n´avrh a implementaci tohoto proto-kolu.
Verifikace dohadov´an´ı datagramov´eho spojen´ı
C´ˇast handshaku dohaduj´ıc´ı nov´e datagramov´e spojen´ı byla verifikov´ana v samostatn´em modelu. Jelikoˇz je prim´arn´ım ´uˇcelem t´eto ˇc´asti handshaku dohodnout nov´e datagramov´e spojen´ı, tak byl proces dohadov´an´ı spojen´ı zjednoduˇsen pouze na dohadov´an´ı o URL. Cookie a DED jsou pouze dalˇs´ı vlastnosti, kter´e zlepˇsuj´ı zabezpeˇcen´ı a funkˇcn´ı vlastnosti protokolu. Pˇred vytvoˇren´ım modelu byly vytvoˇreny stavov´e modely klienta a serveru, kter´e
jsou uvedeny na obr´azc´ıch 4.19 a 4.20
AUTHENTICATED
PROPOSE URL
NEGOTIATE URL
END failure
END success auth_succ
timeout
timeout/connec failure
connect success TRY URL
Obr´azek 4.19: Stavov´y model dohadov´an´ı datagramov´eho spojen´ı na stranˇe klienta
AUTHENTICATED
CREATE URL
NEGOTIATE URL END
success END failure timeout
change_r:url
create failure
connect success
timeout/connect failure
Obr´azek 4.20: Stavov´y model dohadov´an´ı datagramov´eho spojen´ı na serveru Z tˇechto dvou stavov´ych model˚u byl vytvoˇren verifikaˇcn´ı model, kter´y je uveden v pˇr´ıloze na stranˇe 131. D´ıky v´yˇse uveden´ym zjednoduˇsen´ım bylo moˇzn´e zpr´avy mezi procesem klienta a serveru pˇren´aˇset pomoc´ı dvou syn-chronn´ıch kan´al˚u:
mtype = { none , c h a n g e l , c h a n g e r , c o n f i r m l , c o n f i r m r } /∗ cmd type , u r l , cmd type , u r l ∗/
chan q1 = [ 0 ] o f {mtype , byte , mtype , byte } ; chan q2 = [ 0 ] o f {mtype , byte , mtype , byte } ;
Pˇren´aˇsen´a zpr´ava mohla obsahovat bud’ jeden nebo dva pˇr´ıkazy Change L, Change R, Confirm L, Confirm R, kter´e mohly navrhovat nebo potvrzovat
URL vyj´adˇren´y jedn´ım bytem. URL mohlo nab´yvat tˇr´ı hodnot. Hodnota NONE URL byla pouˇzita v kombinaci s pˇr´ıkazy Confirm k zam´ıt´an´ı navr-hovan´ych hodnot. VALID URL vyjadˇrovala platn´e URL a UNVALID URL byla pouˇzita jako n´avrh klienta na URL nov´eho datagramov´eho spojen´ı.
V´ysledky verifikace uveden´e v pˇr´ıloze na stranˇe 135 prok´azaly, ˇze se v t´eto ˇ
c´asti protokolu nenach´az´ı ˇz´adn´y deadlock ani nevyv´ıjej´ıc´ı se cykly.
Bezpeˇcnostn´ı rizika dohadov´an´ı datagramov´eho spojen´ı
Pˇri vlastn´ım dohadov´an´ı nov´eho spojen´ı by nemˇela hrozit nˇejak´a re´aln´a bezpeˇcnostn´ı rizika. Probl´em m˚uˇze ovˇsem nastat v pˇr´ıpadˇe, ˇze server umoˇ z-ˇ
nuje pouˇz´ıt nezabezpeˇcen´e datagramov´e spojen´ı i na link´ach, kter´e nejsou zabezpeˇceny jin´ym zp˚usobem (IPsec, localhost, apod.). ´Utoˇcn´ık m˚uˇze na nezabezpeˇcen´e datagramov´e spojen´ı za´utoˇcit dvˇema zp˚usoby. M˚uˇze se po-kusit uh´adnout ˇc´ıslo port˚u novˇe otevˇren´eho spojen´ı a toto spojen´ı ukr´ast.
Tento zp˚usob by mˇel b´yt pˇredem odsouzen k nezdaru, protoˇze klient by mu-sel uhodnout s ˇc´ıslem portu souˇcasnˇe i hodnotu Cookie a takov´a moˇznost je krajnˇe nepravdˇepodobn´a. Vˇetˇs´ım rizikem je ´utok typu Man-in-the-middle, protoˇze ´utoˇcn´ık m˚uˇze zachytit paket obsahuj´ıc´ı ˇc´ıslo c´ılov´eho portu a Cookie.
Utoˇ´ cn´ık m˚uˇze n´aslednˇe tyto informace pouˇz´ıt k pˇripojen´ı se k serveru. Z to-hoto d˚uvodu se nedoporuˇcuje pouˇz´ıvat nezabezpeˇcen´e datagramov´e spojen´ı na s´ıti Internet.
(1.2.3.4) (5.6.7.8)
| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | V +----+<---+ RESPOND
| | Confirm_R(COOKIE(0DD31jPcZ6st)) | | |
| | | | | . | | Change_L(COOKIE(0DD31jPcZ6st)) . |
. | | . |
Obr´azek 4.21: Pˇr´ıklad kompletn´ıho handshaku
4.6 Datagramov´ e spojen´ı
Protoˇze v se v souˇcasn´em n´avrhu protokolu poˇc´ıt´a na transportn´ı vrstvˇe pouze s protokolem UDP, tak se bude nad´ale uvaˇzovat na datagramov´em spojen´ı pouze protokol UDP. Veˇsker´e pˇr´ıkazy pˇren´aˇsen´e na UDP spojen´ı je potˇreba pˇren´aˇset v paketech, kter´e maj´ı strukturu uvedenou na obr´azku 4.22.
0 0 0 1 1 2 3
Obr´azek 4.22: Struktura Verse paketu
Paket se skl´ad´a z hlaviˇcky za n´ıˇz mus´ı n´asledovat potvrzovac´ı pˇr´ıkazy.
Za potvrzovac´ımi pˇr´ıkazy n´asleduj´ı syst´emov´e pˇr´ıkazy a teprve po nich tzv.
uzlov´e pˇr´ıkazy pˇren´aˇsej´ıc´ı uˇziteˇcn´a data. Mezi potvrzovac´ımi pˇr´ıkazy, syst´ e-mov´ymi pˇr´ıkazy a ani uzlov´ymi pˇr´ıkazy nedoch´az´ı k ˇz´adn´emu vyplˇnov´an´ı.
Na obr´azku 4.22 je zarovn´an´ı na d´elku 4 byt˚u pouze pro lepˇs´ı pˇrehlednost.
Hlaviˇcka paketu zaˇc´ın´a verz´ı protokolu Version. Souˇcasn´a verze protokolu m´a Version = 1. N´asleduj´ı 4 bity, kter´e slouˇz´ı bud’ jako rezerva pro pˇr´ıliˇs velk´a ˇ
c´ısla verze protokolu nebo pˇr´ıpadnˇe pro dalˇs´ı pˇr´ıznaky. Za rezervou n´asleduj´ı pˇr´ıznaky:
• PAY znaˇc´ı, ˇze v paketu jsou pˇren´aˇsena uˇziteˇcn´a data (payload data) a poloˇzka Payload ID obsahuje platnou hodnotu. V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• ACK ud´av´a, ˇze paket obsahuje speci´aln´ı ACK nebo NAK pˇr´ıkazy a poloˇzka ACK ID obsahuje platnou hodnotu. V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• ANK je nastaven´y, kdyˇz poloˇzka ANK ID obsahuje platnou hodnotu.
V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• SYN se pouˇz´ıv´a bˇehem handshaku
• FIN se pouˇz´ıv´a bˇehem ukonˇcen´ı spojen´ı.
Kdyˇz si klient a server bˇehem handshaku na UDP spojen´ı dohodnou nˇejak´y algoritmus pro Flow Control, tak se pro signalizaci velikosti ok´enka pouˇz´ıv´a poloˇzka Windows Size. Pˇren´aˇsen´a hodnota m˚uˇze ud´avat velikost v bytech nebo jejich n´asobc´ıch podle dohodnut´eho algoritmu.
Payload ID se pouˇz´ıv´a jako jedineˇcn´y identifik´ator payload paket˚u. S kaˇ z-d´ym odeslan´ym payload paketem se inkrementuje pˇr´ısluˇsn´y ˇc´ıtaˇc. Kdyˇz jeho hodnota dos´ahne maxima: 232− 1, tak se hodnota ˇc´ıtaˇce nastav´ı na nulu.
Stejn´e pravidlo plat´ı i pro ACK ID, kter´e funguje jako jedineˇcn´y identifik´ator potvrzovac´ıch paket˚u. Poloˇzka ANK ID obsahuje identifik´ator naposledy po-tvrzen´eho payload paketu.
Pokud pˇr´ıjemce potˇrebuje potvrdit pˇrijet´ı nebo ztr´atu payload paketu, tak za hlaviˇckou vloˇz´ı potvrzovac´ı pˇr´ıkazy, kter´e se od ostatn´ıch pˇr´ıkaz˚u liˇs´ı v tom, ˇze se za jejich Op Code nenach´az´ı d´elka pˇr´ıkazu. Potvrzovac´ı pˇr´ıkazy maj´ı konstantn´ı d´elku a k jejich pˇr´ıpadn´e komprimaci doch´az´ı jin´ym zp˚usobem neˇz u ostatn´ıch pˇr´ıkaz˚u. Struktura potvrzovac´ıch pˇr´ıkaz˚u je uve-dena na obr´azku 4.23. Jejich funkce a pouˇzit´ı budou podrobnˇeji pops´any v n´asleduj´ıc´ıch ˇc´astech.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 2 3 4 5 6 7 8 9 +---+---+---+---+---+
| Op_Code=1 | Received Payload Packet ID | (a)
+---+---+---+---+---+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 2 3 4 5 6 7 8 9 +---+---+---+---+---+
| Op_Code=2 | Lost Payload Packet ID | (b)
+---+---+---+---+---+
Obr´azek 4.23: Struktura pˇr´ıkazu ACK (a) a NAK (b)
4.7 Handshake datagramov´ eho spojen´ı
Neˇz si mohou klient a server vymˇenit prvn´ı data, tak mezi nimi mus´ı probˇehnout ˇctyˇrcestn´y handshake, jehoˇz n´avrh byl inspirov´an handshakem protokolu DCCP. Handshake na datagramov´em spojen´ı umoˇzˇnuje klientovi i serveru provˇeˇrit pr˚uchodnost pˇrenosov´ych cest pˇred t´ım neˇz si alokuj´ı ne-zbytn´e syst´emov´e prostˇredky pro zajiˇstˇen´ı ˇc´asteˇcn´e spolehlivosti datagra-mov´eho spojen´ı. Bˇehem handshaku si tak´e mohou dohodnout dalˇs´ı vlastnosti spojen´ı jako jsou pouˇzit´e algoritmy pro FC a CC.
Klient m˚uˇze zaˇc´ıt handshake aˇz po t´e, co od serveru obdrˇz´ı na TCP spo-jen´ı n´avrh URL datagramov´eho spojen´ı. Vlastn´ımu handshaku mus´ı pˇred-ch´azet DTLS handshake, pokud je sch´ema serverem navrˇzen´eho URL za-konˇceno ˇretˇezcem dtls://. DTLS protokol i jeho handshake jsou detailnˇe pops´any v [31]. DTLS se pˇr´ıliˇs neliˇs´ı od TLS, kter´e bylo pops´ano v ˇc´asti TLS handshake. Hlavn´ı rozd´ıly mezi TLS a DTLS jsou pops´any v ˇcl´anku [28].
Souˇc´ast´ı DTLS handshaku je i objevov´an´ı PMTU, kter´e umoˇzˇnuje zjistit maxim´aln´ı MTU na obou link´ach mezi klientem a serverem. V pˇr´ıpadˇe, ˇze je pouˇzita nezabezpeˇcen´a varianta datagramov´eho spojen´ı, tak je vhodn´e, aby klient i server pouˇzili vlastn´ı PMTU. Na modern´ıch operaˇcn´ıch syst´emech k tomu nen´ı potˇreba m´ıt opr´avnˇen´ı administr´atora, ale je moˇzn´e zjistit PMTU pomoc´ı pˇr´ısluˇsn´ych syst´emov´ych vol´an´ı nad sokety dan´eho spojen´ı. Z´ısk´an´ı PMTU umoˇzˇnuje pos´ıl´an´ı velk´ych paket˚u bez rizika fragmentace paket˚u na dan´e lince. PMTU zabezpeˇcen´eho spojen´ı je vˇzdy menˇs´ı neˇz PMTU neza-bezpeˇcen´eho spojen´ı na stejn´e lince, protoˇze DTLS do vˇsech paket˚u pˇrid´av´a vlastn´ı hlaviˇcku. DTLS pˇrid´av´a do paketu kromˇe hlaviˇcky i MAC a t´ım d´ale zmenˇsuje prostor pro pˇren´aˇsen´a data, coˇz DTLS umoˇzˇnuje kompenzovat po-moc´ı komprese pˇren´aˇsen´ych dat.
Pˇr´ıklad v´ymˇeny paket˚u bˇehem handshaku je uveden na obr´azku 4.24.
V tomto pˇr´ıkladˇe nejsou pro pˇrehlednost uvedeny ˇz´adn´e dalˇs´ı syst´emov´e pˇr´ıkazy pro dohadov´an´ı vlastnosti spojen´ı (Cookie, Flow Control, Conges-tion Control).
4.7.1 Prvn´ı ˇ c´ ast handshaku
Bˇehem handshaku se klient i server nach´azej´ı v nˇekolika stavech. Spojen´ı zahajuje klient ve stavu REQUEST zasl´an´ım paketu, kter´y m´a nastaven pˇr´ıznaky PAY a SYN. Jedn´a se tud´ıˇz o pr´azdn´y payload paket, kter´y m´a poˇc´ateˇcn´ı Payload ID nastaveno na n´ahodnou hodnotu. Pˇr´ıznak SYN ˇr´ık´a, ˇ
ze se jedn´a o paket zahajuj´ıc´ı spojen´ı.
Pokud prvn´ı paket pˇrijat´y serverem obsahuje podporovanou verzi
pro-client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | V +----+<---+ RESPOND
| | |
V | PAY ACK ANK pay_id=42 ack_id=0 ank=41 ack=76 | PARTOPEN +--->+----+
| | |
| PAY ACK ANK pay_id=77 ack_id=1 ank=76 ack=42 | V +----+<---+ OPEN
| | |
V | ACK ANK ack_id=1 ank=42 ack=77 |
OPEN +--->+
| |
. .
Obr´azek 4.24: Pˇr´ıklad handshaku na datagramov´em spojen´ı
tokolu a pˇr´ıznaky PAY a SYN, tak by se mˇel server pˇrepnout ze stavu LISTEN do stavu RESPOND a odpovˇedˇet odesl´an´ım paketu obsahuj´ıc´ıho pˇr´ıznaky PAY, SYN a ACK. Jedn´a se opˇet o payload paket s n´ahodnˇe zvo-len´ym Payload ID, kter´y k sobˇe pˇribaluje i potvrzovac´ı paket s pˇr´ıkazem ACK potvrzuj´ıc´ı pˇrijet´ı prvn´ıho paketu. Poˇc´ateˇcn´ı hodnota ACK ID pˇribalen´eho
tokolu a pˇr´ıznaky PAY a SYN, tak by se mˇel server pˇrepnout ze stavu LISTEN do stavu RESPOND a odpovˇedˇet odesl´an´ım paketu obsahuj´ıc´ıho pˇr´ıznaky PAY, SYN a ACK. Jedn´a se opˇet o payload paket s n´ahodnˇe zvo-len´ym Payload ID, kter´y k sobˇe pˇribaluje i potvrzovac´ı paket s pˇr´ıkazem ACK potvrzuj´ıc´ı pˇrijet´ı prvn´ıho paketu. Poˇc´ateˇcn´ı hodnota ACK ID pˇribalen´eho