{"id":306,"date":"2020-04-05T23:57:48","date_gmt":"2020-04-05T21:57:48","guid":{"rendered":"http:\/\/tech.sosthe.sk\/?p=306"},"modified":"2020-04-06T16:52:03","modified_gmt":"2020-04-06T14:52:03","slug":"3-4-transportny-protokol-tcp","status":"publish","type":"post","link":"http:\/\/tech.sosthe.sk\/index.php\/2020\/04\/05\/3-4-transportny-protokol-tcp\/","title":{"rendered":"3.4.\u2002Transportn\u00fd protokol TCP"},"content":{"rendered":"<p><strong>TCP: transmission control protocol<\/strong>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc768.txt\">RFC 793<\/a>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc1122.txt\">RFC 1122<\/a>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc1323.txt\">RFC 1323<\/a>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2018.txt\">RFC 2018<\/a>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2581.txt\">RFC 2581<\/a><\/p>\n<p>Protokol TCP je najpou\u017e\u00edvanej\u0161\u00edm transportn\u00fdm protokolom na internete. Na rozdiel od protokolu UDP realizuje potvrdzovan\u00fd prenos d\u00e1t medzi soketmi. To znamen\u00e1, \u017ee odoslan\u00e9 d\u00e1ta z jedn\u00e9ho soketu sa dostan\u00fa v\u0161etky a v rovnakom porad\u00ed do druh\u00e9ho soketu. Nako\u013eko aj protokol TCP vyu\u017e\u00edva nespo\u013eahliv\u00fd prenos d\u00e1t ni\u017e\u0161\u00edch vrstiev (pakety sa m\u00f4\u017eu strati\u0165 alebo pr\u00eds\u0165 v inom porad\u00ed) mus\u00ed zav\u00e1dza\u0165 mechanizmy na overovanie toho, \u010di segmenty do\u0161li v\u0161etky a nepo\u0161koden\u00e9. V pr\u00edpade, \u017ee nie, tak mus\u00ed vyn\u00fati\u0165 ich op\u00e4tovn\u00e9 zaslanie. Tomuto princ\u00edpu je podriaden\u00fd takmer cel\u00fd n\u00e1vrh protokolu.<\/p>\n<p>Hlavi\u010dka TCP segmentu je vo\u010di hlavi\u010dke UDP segmentu o dos\u0165 bohat\u0161ia.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-307 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_p02.png\" alt=\"\" width=\"430\" height=\"330\" srcset=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_p02.png 430w, http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_p02-300x230.png 300w\" sizes=\"(max-width: 430px) 100vw, 430px\" \/><\/p>\n<p>V\u00fdznam jednotliv\u00fdch \u010dast\u00ed TCP hlavi\u010dky:<\/p>\n<ul>\n<li><strong>source port<\/strong>\u00a0\u2013\u00a0<em>zdrojov\u00fd port<\/em>\u00a0alebo aj port odosielate\u013ea tohto segmentu<\/li>\n<li><strong>destination port<\/strong>\u00a0\u2013\u00a0<em>cie\u013eov\u00fd port<\/em>\u00a0alebo aj port pr\u00edjemcu tohto segmentu<\/li>\n<li><strong>sequence number<\/strong>\u00a0\u2013\u00a0<em>sekven\u010dn\u00e9 \u010d\u00edslo<\/em>\u00a0\u2013 Ur\u010duje poradie prv\u00e9ho bajtu segmentu v pr\u00fade d\u00e1t aplika\u010dnej vrstvy. \u010c\u00edslovanie pr\u00fadu d\u00e1t sa za\u010d\u00edna n\u00e1hodn\u00fdm \u010d\u00edslom a po dosiahnut\u00ed maxim\u00e1lnej hodnoty 2<sup>32<\/sup>-1 pokra\u010duje op\u00e4\u0165 od nuly.<\/li>\n<li><strong>acknowledgement number<\/strong>\u00a0\u2013\u00a0<em>\u010d\u00edslo potvrdenia<\/em>\u00a0alebo\u00a0<em>\u010d\u00edslo ACK<\/em>\u00a0\u2013 Ur\u010duje o\u010dak\u00e1van\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo nasleduj\u00faceho, doteraz nedoru\u010den\u00e9ho segmentu.<\/li>\n<li><strong>data offset<\/strong>\u00a0\u2013\u00a0<em>d\u013a\u017eka hlavi\u010dky<\/em>\u00a0v bajtoch<\/li>\n<li><strong>reserved<\/strong>\u00a0\u2013\u00a0<em>rezervovan\u00e9<\/em>\u00a0\u2013 neobsahuje ni\u010d.<\/li>\n<li><strong>pr\u00edznaky<\/strong>\u00a0\u2013 Ak maj\u00fa hodnotu 1 tak s\u00fa aktivovan\u00e9, ak 0 tak s\u00fa vypnut\u00e9. Pop\u00ed\u0161eme \u010do znamen\u00e1, ke\u010f maj\u00fa hodnotu 1.\n<ul>\n<li><strong>URG<\/strong>\u00a0zo slova urgentn\u00e9 \u2013 Niektor\u00e9 aplika\u010dn\u00e9 protokoly m\u00f4\u017eu vyu\u017e\u00edva\u0165 tento pr\u00edznak na ozna\u010denie toho, \u017ee sa preru\u0161uje zasielan\u00fd pr\u00fad d\u00e1t, aby sa ozn\u00e1mila nejak\u00e1 spr\u00e1va. Napr\u00edklad po\u010das posielania ve\u013ek\u00e9ho s\u00faboru chceme robi\u0165 nejak\u00e9 riadiace pr\u00edkazy (preru\u0161i\u0165 posielanie, informova\u0165 o nejakej udalosti na stanici odosielate\u013ea). Hodnota urgent pointer je v tomto pr\u00edpade nastaven\u00e1 na poz\u00edciu posledn\u00e9ho bajtu urgentnej spr\u00e1vy v segmente. (urgentn\u00e9 spr\u00e1vy s\u00fa sk\u00f4r v\u00fdnimkou)<\/li>\n<li><strong>ACK<\/strong>\u00a0\u2013 Hodnota \u201eacknowledgement number\u201c, teda \u010d\u00edslo potvrdenia, je relevantn\u00e1.<\/li>\n<li><strong>PSH<\/strong>\u00a0zo slova \u201epush\u201c t. j. posu\u0148. \u2013 Hovor\u00ed, \u017ee d\u00e1ta maj\u00fa by\u0165 okam\u017eite posunut\u00e9 aplika\u010dnej vrstve. Napr\u00edklad to m\u00f4\u017ee znamena\u0165, \u017ee ide o posledn\u00fd segment aktu\u00e1lne odosielanej spr\u00e1vy.<\/li>\n<li><strong>RST<\/strong>\u00a0\u2013 \u201ereset\u201c \u2013 n\u00e1siln\u00e9 ukon\u010denie spojenia<\/li>\n<li><strong>SYN<\/strong>\u00a0\u2013 \u201esynchronize\u201c \u2013 ozna\u010denie segmentov pou\u017eit\u00fdch pri za\u010diatku spojenia (vi\u010f ni\u017e\u0161ie)<\/li>\n<li><strong>FIN<\/strong>\u00a0\u2013 \u201efinalize\u201c \u2013 ozna\u010denie segmentov pou\u017eit\u00fdch pri uzatv\u00e1ran\u00ed spojenia (vi\u010f ni\u017e\u0161ie)<\/li>\n<\/ul>\n<\/li>\n<li><strong>window<\/strong>\u00a0\u2013\u00a0<em>ve\u013ekos\u0165 okna<\/em>\u00a0\u2013 Buffer pr\u00edjemcu obsahuje prijat\u00fd s\u00favisl\u00fd blok d\u00e1t, ktor\u00e9 aplika\u010dn\u00e1 vrstva e\u0161te nespracovala, a zvy\u0161n\u00e9 miesto zvan\u00e9 okno pr\u00edjemcu. Ve\u013ekos\u0165 okna pr\u00edjemcu je zasielan\u00e1 v hodnote\u00a0<strong>window<\/strong>\u00a0odosielate\u013eovi. Ke\u010f\u017ee oba komunikuj\u00face sokety m\u00f4\u017eu by\u0165 pr\u00edjemcovia aj odosielatelia, ka\u017ed\u00fd m\u00e1 svoje okno prijat\u00fdch spr\u00e1v.<\/li>\n<li><strong>checksum<\/strong>\u00a0\u2013\u00a0<em>kontroln\u00fd s\u00fa\u010det<\/em>\u00a0\u2013 M\u00e1 rovnak\u00e9 vyu\u017eitie ako pri UDP segmentoch.<\/li>\n<li><strong>urgent pointer<\/strong>\u00a0\u2013\u00a0<em>poradie bajtu, kde kon\u010dia urgentn\u00e9 d\u00e1ta<\/em><\/li>\n<li><strong>options and padding<\/strong>\u00a0\u2013\u00a0<em>vo\u013eby a v\u00fdpl\u0148 do n\u00e1sobku 16 bitov<\/em>\u00a0\u2013 Dodato\u010dn\u00e9 nastavenia, vyu\u017eit\u00e9 na:\n<ul>\n<li>dohadovanie\u00a0<strong>MSS<\/strong>\u00a0(maximum segment size) pri nadv\u00e4zovan\u00ed spojenia. MSS je maxim\u00e1lna ve\u013ekos\u0165 d\u00e1t v tele TCP segmentu. Keby sa hodnota neuviedla, MSS by bolo 536 bajtov, be\u017ene sa v\u0161ak pou\u017e\u00edva 1460 bajtov.<\/li>\n<li><strong>Window Scale (WSCALE)<\/strong>\u00a0\u2013 n\u00e1sobok ve\u013ekosti okna \u2013 Hodnota \u201ewindow\u201c m\u00e1 iba 16 bitov, \u010do znamen\u00e1, \u017ee bez n\u00e1sobku by mohla by\u0165 maxim\u00e1lna ve\u013ekos\u0165 okna 64 kB (maxim\u00e1lne \u010d\u00edslo zap\u00edsate\u013en\u00e9 16 bitmi je 65535). Pri prenose na ve\u013ek\u00e9 vzdialenosti je potrebn\u00e9 v\u00e4\u010d\u0161ie okno, aby sa vyu\u017eila cel\u00e1 \u0161\u00edrka p\u00e1sma. Pomocou tejto vo\u013eby vieme pri nadv\u00e4zovan\u00ed spojenia poveda\u0165, ak\u00fdm n\u00e1sobkom dvojky sa m\u00e1 hodnota \u201ewindow\u201c n\u00e1sobi\u0165. Takto vieme dosiahnu\u0165 ve\u013ekos\u0165 okna a\u017e do 1 GB.<\/li>\n<li>\u010eal\u0161ie dodato\u010dn\u00e9 nastavenia si m\u00f4\u017eete pozrie\u0165 v\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc1323.txt\">RFC 1323<\/a>\u00a0alebo stru\u010dnej\u0161ie napr\u00edklad v\u00a0<a href=\"http:\/\/www.securityfocus.com\/infocus\/1223\">http:\/\/www.securityfocus.com\/infocus\/1223<\/a>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3>3.4.1\u2002 Mana\u017ement nadviazania spojenia<\/h3>\n<p>Pred samotn\u00fdm odosielan\u00edm d\u00e1t je potrebn\u00e9, aby sa nadviazalo spojenie. Pri nadv\u00e4zovan\u00ed spojenia si obidva konce musia pripravi\u0165 nieko\u013eko premenn\u00fdch, na z\u00e1klade ktor\u00fdch sa po\u010das prenosu bude riadi\u0165 prij\u00edmanie a odosielanie d\u00e1t, potvrdzovanie prijat\u00fdch segmentov a op\u00e4tovn\u00e9 preposielanie straten\u00fdch segmentov. V popise nadviazania spojenia uv\u00e1dzame aj hodnoty window, MSS a WSCALE, ktor\u00e9 s\u00fa bli\u017e\u0161ie vysvetlen\u00e9 v \u010dasti\u00a0Prenos d\u00e1t.<\/p>\n<p>Nadviazanie TCP spojenia je realizovan\u00e9 trojf\u00e1zov\u00fdm \u201epotrasen\u00edm r\u00fak\u201c (<strong>three-way handshake<\/strong>).<\/p>\n<ol>\n<li><strong>Odoslanie SYN segmentu k serveru.<\/strong>\u00a0V prvej f\u00e1ze si klient vygeneruje n\u00e1hodn\u00e9 \u00favodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo, od ktor\u00e9ho sa za\u010dn\u00fa \u010d\u00edslova\u0165 bajty odosielan\u00fdch d\u00e1t z aplika\u010dnej vrstvy. Okrem tohto \u010d\u00edsla si vytvor\u00ed aj buffre na okn\u00e1 odosielan\u00fdch a prijat\u00fdch segmentov nejakej \u00favodnej ve\u013ekosti. \u00davodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo sa vlo\u017e\u00ed do hlavi\u010dky. Samozrejme sa do hlavi\u010dky nap\u00ed\u0161e \u010d\u00edslo zdrojov\u00e9ho a cie\u013eov\u00e9ho portu a ostatn\u00e9 s\u00fa\u010dasti hlavi\u010dky. Okrem toho je v hlavi\u010dke e\u0161te nastaven\u00fd pr\u00edznak SYN na 1 ozna\u010duj\u00faci, \u017ee ide o prv\u00fd segment nadv\u00e4zovania spojenia. V \u010dasti options sa nastav\u00ed MSS a WSCALE. Hodnota polo\u017eky window sa nastav\u00ed pod\u013ea ve\u013ekosti vytvoren\u00e9ho okna pr\u00edjemcu a hodnoty WSCALE.<\/li>\n<li><strong>Odoslanie SYN\/ACK segmentu ku klientovi,<\/strong>\u00a0t. j. s\u00fa zapnut\u00e9 pr\u00edznaky SYN aj ACK. Serverov\u00fd soket akceptoval spojenie a vytvoril nov\u00fd soket, ktor\u00fd bude komunikova\u0165 s t\u00fdmto klientom. K tomuto nov\u00e9mu soketu sa tie\u017e vygeneruj\u00fa \u00favodn\u00e9 premenn\u00e9, t.j n\u00e1hodn\u00e9 \u00favodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo pre d\u00e1ta odosielan\u00e9 na klienta, buffre pre okn\u00e1 prijat\u00fdch a odoslan\u00fdch segmentov. V hlavi\u010dke sa nastav\u00ed cie\u013eov\u00fd port pod\u013ea zdrojov\u00e9ho portu z prijat\u00e9ho segmentu a zdrojov\u00fd port pod\u013ea cie\u013eov\u00e9ho portu prijat\u00e9ho segmentu. Sekven\u010dn\u00e9 \u010d\u00edslo je serverom vygenerovan\u00e9 jeho \u00favodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo. \u010c\u00edslo potvrdenia je o 1 v\u00e4\u010d\u0161ie ako sekven\u010dn\u00e9 \u010d\u00edslo z prijat\u00e9ho segmentu. Z toho vieme napr\u00edklad to, \u017ee v najbli\u017e\u0161om prijatom segmente o\u010dak\u00e1va, \u017ee ako sekven\u010dn\u00e9 \u010d\u00edslo bude uveden\u00e9 pr\u00e1ve toto \u010d\u00edslo. V \u010dasti options nastav\u00ed svoje MSS a WSCALE. Hodnotu polo\u017eky window nastav\u00ed pod\u013ea ve\u013ekosti vytvoren\u00e9ho okna pr\u00edjemcu a hodnoty WSCALE.<\/li>\n<li><strong>Odoslanie ACK segmentu k serveru.<\/strong>\u00a0V poslednej, tretej f\u00e1ze klient po\u0161le serveru segment so zapnut\u00fdm ACK pr\u00edznakom. Sekven\u010dn\u00e9 \u010d\u00edslo je o 1 v\u00e4\u010d\u0161ie ako v prvom segmente a \u010d\u00edslo potvrdenia je o 1 v\u00e4\u010d\u0161ie ako sekven\u010dn\u00e9 \u010d\u00edslo v segmente, ktor\u00fd pri\u0161iel zo servera.<\/li>\n<\/ol>\n<p>Po inicializ\u00e1cii m\u00f4\u017ee klient aj server u\u017e posiela\u0165 segmenty obsahuj\u00face d\u00e1ta aplika\u010dnej vrstvy. Klient ich m\u00f4\u017ee za\u010da\u0165 posiela\u0165 u\u017e ako s\u00fa\u010das\u0165 ACK segmentu tretej f\u00e1zy nadv\u00e4zovania spojenia. Server a\u017e po prijat\u00ed tohto ACK segmentu. Kto za\u010dne posiela\u0165 d\u00e1ta, z\u00e1vis\u00ed od aplika\u010dn\u00e9ho protokolu (m\u00f4\u017eu aj obaja s\u00fa\u010dasne).<\/p>\n<p>Pr\u00edklad nadviazania spojenia (uv\u00e1dzame iba podstatn\u00e9 polo\u017eky):<\/p>\n<ol>\n<li>Klient posiela: source port:\u00a0<strong>12345<\/strong>, destination port:\u00a0<strong>80<\/strong>, sequence number\u00a0<strong>300000<\/strong>\u00a0<em>(n\u00e1hodne vygenerovan\u00e9)<\/em>, acknowledgement number:\u00a0<strong>0<\/strong>, SYN=<strong>1<\/strong>, ACK=<strong>0<\/strong><\/li>\n<li>Server posiela: source port:\u00a0<strong>80<\/strong>, destination port:\u00a0<strong>12345<\/strong>, sequence number\u00a0<strong>200000<\/strong>\u00a0<em>(n\u00e1hodne vygenerovan\u00e9)<\/em>, acknowledgement number:\u00a0<strong>300001<\/strong>, SYN=<strong>1<\/strong>, ACK=<strong>1<\/strong><\/li>\n<li>Klient posiela: source port:\u00a0<strong>12345<\/strong>, destination port:\u00a0<strong>80<\/strong>, sequence number\u00a0<strong>300001<\/strong>, acknowledgement number:\u00a0<strong>200001<\/strong>, SYN=<strong>0<\/strong>, ACK=<strong>1<\/strong><\/li>\n<\/ol>\n<p><em>Pozn\u00e1mka: \u00davodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edsla sa vyberaj\u00fa n\u00e1hodne, aby sa zabr\u00e1nilo pomie\u0161aniu dvoch po sebe nasleduj\u00facich rovnak\u00fdch spojeniach, ale aj aby sa zabr\u00e1nilo\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/TCP_Sequence_Prediction_Attack\">zn\u00e1memu \u00fatoku<\/a>\u00a0zalo\u017eenom na tom, \u017ee ak by som dopredu poznal sekven\u010dn\u00e9 \u010d\u00edsla TCP komunik\u00e1cie, mohol by som \u013eahko filtrova\u0165 TCP segmenty ved\u00face okolo m\u00f4jho na\u010d\u00favacieho zariadenia a vklada\u0165 svoje segmenty do u\u017e existuj\u00facich spojen\u00ed, pr\u00edpadne \u00faplne prevzia\u0165 kontrolu nad otvoren\u00fdm spojen\u00edm, alebo tie\u017e z\u00e1kerne uzatv\u00e1ra\u0165 otvoren\u00e9 spojenia.<\/em><\/p>\n<h3>3.4.2\u2002 Mana\u017ement ukon\u010denia spojenia<\/h3>\n<p>Korektn\u00e9 ukon\u010denie TCP spojenia je potrebn\u00e9 urobi\u0165 tak, aby obe komunikuj\u00face strany\u00a0<strong>vedeli<\/strong>, \u017ee druh\u00e1 strana vie, \u017ee spojenie sa kon\u010d\u00ed. Po\u017eiadavka na ukon\u010denie spojenia m\u00f4\u017ee pr\u00eds\u0165 od klienta aj od servera \u2013 \u010dasto z\u00e1le\u017e\u00ed aj na aplika\u010dnom protokole, lebo TCP protokol ich u\u017e nerozli\u0161uje.<\/p>\n<ol>\n<li><strong>Prv\u00e1 stanica (inici\u00e1tor ukon\u010denia) posiela FIN segment.<\/strong>\u00a0Tento segment m\u00e1 nastaven\u00fd pr\u00edznak FIN na 1. Pr\u00edznak ACK m\u00f4\u017ee by\u0165 0 alebo 1 pod\u013ea toho, \u010di bol pred t\u00fdm zaslan\u00fd nejak\u00fd d\u00e1tov\u00fd segment z druhej stanice.<\/li>\n<li><strong>Druh\u00e1 stanica posiela ACK segment<\/strong>, t.j. potvrdenie prijatia FIN (alebo FIN\/ACK) segmentu. Ke\u010f druh\u00e1 stanica e\u0161te potrebuje doposiela\u0165 nejak\u00e9 d\u00e1ta, tak aj po prijat\u00ed FIN segmentu m\u00f4\u017ee pokra\u010dova\u0165 s posielan\u00edm d\u00e1t.<\/li>\n<li><strong>Druh\u00e1 stanica posiela FIN\/ACK segment,<\/strong>\u00a0t.j. pr\u00edznaky FIN aj ACK s\u00fa nastaven\u00e9 na 1.<\/li>\n<li><strong>Prv\u00e1 stanica odosiela ACK segment<\/strong>. FIN je nastaven\u00e9 na 0 a ACK na 1. V tejto chv\u00edli prv\u00e1 stanica zapne \u010dasova\u010d na \u201edos\u0165 dlh\u00fd \u010das\u201c (\u010dasto 30 s, min\u00fata, alebo dve min\u00faty). Ak po\u010das tohto \u010dasu dostane FIN\/ACK segment, znamen\u00e1 to, \u017ee sa jeho ACK segment stratil a posiela ho znova (vi\u010f. Prenos d\u00e1t ni\u017e\u0161ie). Ak nedostane u\u017e \u017eiadne segmenty, po zastaven\u00ed \u010dasova\u010da sa soket definit\u00edvne uzatv\u00e1ra.<\/li>\n<li><strong>Druh\u00e1 stanica prijme ACK segment<\/strong>. Jej soket sa zavrie.<\/li>\n<\/ol>\n<h3>3.4.3\u2002 Prenos d\u00e1t (met\u00f3da sliding window \u2013 posuvn\u00e9 okno)<\/h3>\n<p>TCP protokol poskytuje sie\u0165ov\u00fdm aplik\u00e1ci\u00e1m spo\u013eahliv\u00fd, potvrdzovan\u00fd prenos d\u00e1t. Vyu\u017e\u00edva na to nespo\u013eahliv\u00fd prenos svojich segmentov sie\u0165ov\u00fdm protokolom IP. IP datagramy sa m\u00f4\u017eu strati\u0165 alebo pr\u00eds\u0165 do cie\u013eovej stanice v inom porad\u00ed, ne\u017e v akom boli vyslan\u00e9.<\/p>\n<h3>Sekven\u010dn\u00e9 \u010d\u00edsla<\/h3>\n<p>Segmenty vytv\u00e1ran\u00e9 transportnou vrstvou sa skladaj\u00fa z hlavi\u010dky a tela. Telo segmentu m\u00e1 ur\u010den\u00fa maxim\u00e1lnu ve\u013ekos\u0165 hodnotou MSS (maximum segment size) dohodnut\u00fa pri nadv\u00e4zovan\u00ed spojenia. Ke\u010f aplika\u010dn\u00e1 vrstva po\u0161le spr\u00e1vu (d\u00e1ta), ktor\u00e1 je v\u00e4\u010d\u0161ia ako MSS, je nutn\u00e9 t\u00fato spr\u00e1vu rozdeli\u0165 do viacer\u00fdch segmentov. Ka\u017ed\u00fd z t\u00fdchto segmentov m\u00e1 jednozna\u010dne pridelen\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo, ktor\u00e9 sa uv\u00e1dza v hlavi\u010dke segmentu.<\/p>\n<p>Napr\u00edklad, ak MSS je 1400 a spr\u00e1va m\u00e1 5000 bajtov, vytvoria sa 4 segmenty. V tele prv\u00e9ho segmentu s\u00fa bajty 1 a\u017e 1400, v tele druh\u00e9ho 1401 a\u017e 2800, v tele tretieho 2801 a\u017e 4200 a v tele \u0161tvrt\u00e9ho 4201 a\u017e 5000. Ak ide o \u00faplne prv\u00fa spr\u00e1vu spojenia a pri nadv\u00e4zovan\u00ed spojenia sa vytvorilo \u00favodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo napr. 300000, tak na\u0161e segmenty maj\u00fa sekven\u010dn\u00e9 \u010d\u00edsla 300001, 301401, 302801 a 304201. Ak by ne\u0161lo o prv\u00fa spr\u00e1vu, tak k t\u00fdmto \u010d\u00edslam by sme e\u0161te museli pripo\u010d\u00edta\u0165 po\u010det pred t\u00fdm odoslan\u00fdch bajtov aplika\u010dnej vrstvy cez tento soket. Napr\u00edklad, ak \u00favodn\u00e9 sekven\u010dn\u00e9 je \u010d\u00edslo 300000, a pred touto spr\u00e1vou sa u\u017e odoslali spr\u00e1vy, ktor\u00e9 mali dokopy 10000 bajtov, tak tieto na\u0161e \u0161tyri segmenty by mali sekven\u010dn\u00e9 \u010d\u00edsla 310001, 311401, 312801 a 314201. Maxim\u00e1lne sekven\u010dn\u00e9 \u010d\u00edslo je 2<sup>32<\/sup>-1, nasleduj\u00face segmenty s\u00fa u\u017e \u010d\u00edslovan\u00e9 modulo 2<sup>32<\/sup>.<\/p>\n<p>Aby sme to zov\u0161eobecnili, ke\u010f \u00favodn\u00e9 sekven\u010dn\u00e9 \u010d\u00edslo ozna\u010d\u00edme US\u010c, ve\u013ekos\u0165 d\u00e1t vo v\u0161etk\u00fdch predch\u00e1dzaj\u00facich segmentoch dokopy ozna\u010d\u00edme ako D, tak\u00a0<strong>sekven\u010dn\u00e9 \u010d\u00edslo \u010fal\u0161ieho d\u00e1tov\u00e9ho segmentu<\/strong>\u00a0sa rovn\u00e1 (US\u010c + D) mod 2<sup>32<\/sup>-1. Re\u00e1lne sa to po\u010d\u00edta iba zo s\u00fa\u010dtu sekven\u010dn\u00e9ho \u010d\u00edsla predch\u00e1dzaj\u00faceho segmentu a ve\u013ekosti d\u00e1t v \u0148om modulo 2<sup>32<\/sup>, ktor\u00fd sa ulo\u017e\u00ed v premennej\u00a0<em>\u010fal\u0161ieSekven\u010dn\u00e9\u010c\u00edslo<\/em>.<\/p>\n<h3>Kumulat\u00edvne potvrdenie<\/h3>\n<p>Ke\u010f\u017ee odosielate\u013e d\u00e1t mus\u00ed by\u0165 nejak\u00fdm sp\u00f4sobom informovan\u00fd pr\u00edjemcom o tom, ktor\u00e9 odoslan\u00e9 segmenty do\u0161li k pr\u00edjemcovi, pr\u00edjemca mu to oznamuje cez \u010d\u00edsla potvrdenia. V protokole TCP sa pou\u017e\u00edva takzvan\u00e9\u00a0<strong>kumulat\u00edvne potvrdenie<\/strong>: ak odosielate\u013e dostane potvrdzovac\u00ed segment s \u010d\u00edslom potvrdenia\u00a0<em>X<\/em>, tak to znamen\u00e1, \u017ee pr\u00edjemca prijal v poriadku\u00a0<em>v\u0161etky segmenty s \u010d\u00edslami men\u0161\u00edmi ako X<\/em>\u00a0a o\u010dak\u00e1va, \u017ee mu pr\u00edde segment so sekven\u010dn\u00fdm \u010d\u00edslom\u00a0<em>X<\/em>, ktor\u00fd zatia\u013e nedostal.<\/p>\n<h3>Okno odosielate\u013ea<\/h3>\n<p>Ak by sme museli po ka\u017edom odoslanom d\u00e1tovom segmente \u010daka\u0165 na pr\u00edslu\u0161n\u00e9 potvrdenie e\u0161te pred odoslan\u00edm \u010fal\u0161ieho d\u00e1tov\u00e9ho segmentu, mohli by sme by\u0165 v\u00fdrazne obmedzovan\u00ed pri komunik\u00e1cii na ve\u013ek\u00e9 vzdialenosti. Nie je v\u00fdnimkou, \u017ee \u010das od odoslania segmentu a\u017e po doru\u010denie pr\u00edslu\u0161n\u00e9ho potvrdenia, naz\u00fdvan\u00fd \u201eround trip time\u201c (RTT), m\u00f4\u017ee by\u0165 aj v\u00fdrazne viac ako 100 ms. Ke\u010f\u017ee ve\u013ekos\u0165 tela segmentu je typicky zhruba 1,5 kB, vedeli by sme pri RTT 100 ms prenies\u0165 iba asi 15 kB za sekundu, bez oh\u013eadu na \u0161\u00edrku p\u00e1sma.<\/p>\n<p>Z tohto d\u00f4vodu TCP umo\u017e\u0148uje posla\u0165 viac segmentov bez doru\u010denia potvrdenia ist\u00e9ho mno\u017estva pred t\u00fdm odoslan\u00fdch segmentov. Tomuto \u201ehromadn\u00e9mu\u201c sp\u00f4sobu odosielania hovor\u00edme\u00a0<strong>pipelining<\/strong>. St\u00e1le v\u0161ak plat\u00ed, \u017ee potrebujeme ma\u0165 potvrden\u00e9 prijatie v\u0161etk\u00fdch odoslan\u00fdch segmentov, len k tomu doch\u00e1dza oneskorene. Obe komunikuj\u00face stanice maj\u00fa svoje\u00a0<strong>okno odosielate\u013ea<\/strong>\u00a0\u2013 vyhraden\u00e9 miesto v pam\u00e4ti, v ktorom si uchov\u00e1vaj\u00fa postupnos\u0165 odoslan\u00fdch, ale zatia\u013e nepotvrden\u00fdch segmentov. Odosielate\u013e m\u00f4\u017ee odosla\u0165 maxim\u00e1lne to\u013eko segmentov, ko\u013eko vojde do okna odosielate\u013ea bez toho, aby hociktor\u00fd z nich bol potvrden\u00fd. Ke\u010f pr\u00edde potvrdenie, tak z okna sa odstr\u00e1nia v\u0161etky segmenty so sekven\u010dn\u00fdm \u010d\u00edslom men\u0161\u00edm ako \u010d\u00edslo potvrdenia. Okno sa akoby posunie v rade odosielan\u00fdch segmentov a vznikne tak priestor pre nov\u00e9 segmenty, ktor\u00e9 sa m\u00f4\u017eu ulo\u017ei\u0165 do okna odosielate\u013ea a odosla\u0165 pr\u00edjemcovi, ak aplik\u00e1cia m\u00e1 e\u0161te nejak\u00e9 \u010dasti spr\u00e1vy, ktor\u00e9 neboli odoslan\u00e9.<\/p>\n<p>Napr\u00edklad m\u00e1me okno ve\u013ekosti 3 segmentov a chceme odosla\u0165 segmenty, ktor\u00e9 maj\u00fa sekven\u010dn\u00e9 \u010d\u00edsla 300001, 301401, 302801 a 304201, m\u00f4\u017eeme odosla\u0165 prv\u00e9 tri, ktor\u00e9 potom \u201e\u010dakaj\u00fa\u201c v okne odosielate\u013ea na potvrdenie. Posledn\u00fd segment posla\u0165 nem\u00f4\u017eeme, lebo nevo\u0161iel do okna odosielate\u013ea. Ak teraz pr\u00edde napr\u00edklad potvrdenie s \u010d\u00edslom 302801, odstr\u00e1nime z okna prv\u00e9 dva segmenty, preto\u017ee TCP protokol pou\u017e\u00edva kumulat\u00edvne potvrdenie. Tak\u017ee ke\u010f n\u00e1m pr\u00edde potvrdenie s \u010d\u00edslom 302801, vieme, \u017ee pr\u00edjemca u\u017e prijal v\u0161etky segmenty so sekven\u010dn\u00fdmi \u010d\u00edslami men\u0161\u00edmi ako 302801. Posunut\u00edm okna, teda vyhoden\u00edm segmentov so sekven\u010dn\u00fdmi \u010d\u00edslami 300001 a 301401, vznikne priestor v okne aj pre segment so sekven\u010dn\u00fdm \u010d\u00edslom 304201, tak\u017ee ho m\u00f4\u017eeme odosla\u0165. Okno teda bude obsahova\u0165 segmenty so sekven\u010dn\u00fdmi \u010d\u00edslami 302801 a 304201 a\u017e pokia\u013e nepr\u00edde nov\u00e9 potvrdenie s \u010d\u00edslom potvrdenia v\u00e4\u010d\u0161\u00edm ako 302801. Druh\u00e1 mo\u017enos\u0165 je, \u017ee aplika\u010dn\u00e1 vrstva bude medzi t\u00fdm u\u017e chcie\u0165 posla\u0165 \u010fal\u0161iu spr\u00e1vu (nov\u00e9 d\u00e1ta), kedy by sa dalo vyu\u017ei\u0165 e\u0161te jedno miesto v okne odosielate\u013ea.<\/p>\n<h3>Okno pr\u00edjemcu<\/h3>\n<p>Obe strany komunik\u00e1cie maj\u00fa okrem okna odosielate\u013ea aj okno pr\u00edjemcu. Prv\u00e1 poz\u00edcia v okne pr\u00edjemcu predstavuje najstar\u0161\u00ed doteraz nedoru\u010den\u00fd segment v postupnosti prij\u00edman\u00fdch segmentov. Jeho \u010d\u00edslo segmentu ozna\u010dme\u00a0<em>rcv_base<\/em>. V okne pr\u00edjemcu sa uchov\u00e1vaj\u00fa iba segmenty doru\u010den\u00e9 mimo poradia (s v\u00e4\u010d\u0161\u00edmi sekven\u010dn\u00fdmi \u010d\u00edslami ako\u00a0<em>rcv_base<\/em>). Cel\u00fd \u00favodn\u00fd s\u00favisl\u00fd blok doru\u010den\u00fdch segmentov, teda v\u0161etky segmenty so sekven\u010dn\u00fdmi \u010d\u00edslami men\u0161\u00edmi ako\u00a0<em>rcv_base<\/em>\u00a0u\u017e boli odoslan\u00e9 pr\u00edjemcovmu soketu v minulosti. V pr\u00edpade, \u017ee pr\u00edde segment so sekven\u010dn\u00fdm \u010d\u00edslom\u00a0<em>rcv_base<\/em>, s\u00fa pr\u00edjemcovmu soketu odoslan\u00e9 okrem d\u00e1t z tohto segmentu aj d\u00e1ta v\u0161etk\u00fdch nasleduj\u00facich segmentov z okna pr\u00edjemcu a\u017e po prv\u00fd nedoru\u010den\u00fd segment, ktor\u00e9ho sekven\u010dn\u00e9 \u010d\u00edslo sa stane novou hodnotou\u00a0<em>rcv_base<\/em>.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-308 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/okno_prijemcu.png\" alt=\"\" width=\"502\" height=\"278\" srcset=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/okno_prijemcu.png 502w, http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/okno_prijemcu-300x166.png 300w\" sizes=\"(max-width: 502px) 100vw, 502px\" \/><\/p>\n<p>Pozrime sa na pr\u00edklad zn\u00e1zornen\u00fd vy\u0161\u0161ie. Na obr\u00e1zku a) m\u00e1me hodnotu rcv_base = 200000 a v okne pr\u00edjemcu 2 prijat\u00e9 segmenty mimo poradia, kde prv\u00fd m\u00e1 sekven\u010dn\u00e9 \u010d\u00edslo 202000 a ve\u013ekos\u0165 500 bajtov a druh\u00fd m\u00e1 sekven\u010dn\u00e9 \u010d\u00edslo 203000 a ve\u013ekos\u0165 1000. D\u00e1ta v\u0161etk\u00fdch segmentov s \u010d\u00edslami men\u0161\u00edmi ako 200000 u\u017e boli odoslan\u00e9 pr\u00edjemcovmu soketu. E\u0161te n\u00e1m ch\u00fdbaj\u00fa d\u00e1ta 200000 a\u017e 201999 a 202500 a\u017e 202999.<\/p>\n<p>Obr\u00e1zok b) zn\u00e1zor\u0148uje, \u017ee pri\u0161iel datagram so sekven\u010dn\u00fdm \u010d\u00edslom 200000 a ve\u013ekos\u0165ou 1000 bajtov. Po\u0161leme d\u00e1ta z tohto datagramu pr\u00edjemcovmu soketu a zv\u00fd\u0161ime hodnotu rcv_base na 201000. Potvrdenie zaslan\u00e9 odosielate\u013eovi bude ma\u0165 \u010d\u00edslo potvrdenia 201000. Teraz m\u00e1me ch\u00fdbaj\u00face d\u00e1ta 201000 a\u017e 201999 a 202500 a\u017e 202999.<\/p>\n<p>Na obr\u00e1zku c) vid\u00edme, \u017ee n\u00e1m pri\u0161iel datagram so sekven\u010dn\u00fdm \u010d\u00edslom 201000 a ve\u013ekos\u0165ou 1000 bajtov, po\u0161leme teda d\u00e1ta z tohto datagramu pr\u00edjemcovmu soketu, ale u\u017e aj spolu s d\u00e1tami z datagramu so sekven\u010dn\u00fdm \u010d\u00edslom 202000, lebo sme vyplnili cel\u00fa oblas\u0165 ch\u00fdbaj\u00facich d\u00e1t a\u017e po bajt s \u010d\u00edslom 202499. Datagram so sekven\u010dn\u00fdm \u010d\u00edslom 202000 n\u00e1sledne odstr\u00e1nime z okna pr\u00edjemcu. Hodnota rcv_base sa zv\u00fd\u0161i na 202500 (prv\u00fd neprijat\u00fd bajt). Potvrdenie zaslan\u00e9 odosielate\u013eovi bude ma\u0165 \u010d\u00edslo potvrdenia tie\u017e 202500. Teraz m\u00e1me ch\u00fdbaj\u00face d\u00e1ta u\u017e iba 202500 a\u017e 202999. Ak by hocikedy pri\u0161iel datagram so sekven\u010dn\u00fdm \u010d\u00edslom v\u00e4\u010d\u0161\u00edm ako rcv_base, je zaraden\u00fd do okna pr\u00edjemcu.<\/p>\n<h3>Op\u00e4tovn\u00e9 posielanie segmentov<\/h3>\n<p>Vieme, \u017ee sie\u0165ov\u00e1 vrstva neposkytuje spo\u013eahliv\u00fd prenos d\u00e1t. To znamen\u00e1, \u017ee ak chceme zabezpe\u010di\u0165 spo\u013eahliv\u00fd prenos d\u00e1t, mus\u00edme sa vedie\u0165 zotavi\u0165 zo straty segmentu. Hlavn\u00fd probl\u00e9m je v identifikovan\u00ed samotnej udalosti straty segmentu, ktor\u00e1 sa stala niekde na ceste medzi cie\u013eov\u00fdmi stanicami. Stratu mus\u00ed registrova\u0165 hlavne odosielate\u013e, aby vedel, \u017ee m\u00e1 op\u00e4tovne posla\u0165 straten\u00fd segment. Odosielate\u013e pova\u017euje za stratu jednu z dvoch udalost\u00ed:<\/p>\n<ul>\n<li><strong>Pri\u0161li aspo\u0148 3 potvrdenia s rovnak\u00fdm \u010d\u00edslom potvrdenia.<\/strong>\u00a0Vieme, \u017ee TCP protokol pou\u017e\u00edva kumulat\u00edvne potvrdenie, t. j. v\u017edy sa potvrdzuje \u010d\u00edslom rcv_base, \u010do je \u010d\u00edslo prv\u00e9ho bajtu najstar\u0161ieho nedoru\u010den\u00e9ho segmentu. Ak teda u pr\u00edjemcu nastane situ\u00e1cia, \u017ee mu pr\u00eddu segmenty s v\u00e4\u010d\u0161\u00edm sekven\u010dn\u00fdm \u010d\u00edslom ako\u00a0<em>rcv_base<\/em>, tak sa ka\u017ed\u00fd z nich potvrdzuje \u010d\u00edslom\u00a0<em>rcv_base<\/em>. Odosielate\u013e pri prijat\u00ed viacer\u00fdch potvrden\u00ed s rovnak\u00fdm \u010d\u00edslom potvrdenia teda vydedukuje, \u017ee segment so sekven\u010dn\u00fdm \u010d\u00edslom rovn\u00fdm tomuto mnohon\u00e1sobn\u00e9mu \u010d\u00edslu potvrdenia je potrebn\u00e9 posla\u0165 znova, lebo pr\u00edjemca ho neprijal sk\u00f4r ako segmenty s v\u00e4\u010d\u0161\u00edmi \u010d\u00edslami, a teda sa pravdepodobne stratil (mohol aj iba me\u0161ka\u0165, lebo i\u0161iel pomal\u0161ou trasou po internete). Preposlanie na z\u00e1klade 3 rovnak\u00fdch potvrden\u00ed naz\u00fdvame\u00a0<strong>r\u00fdchle preposlanie<\/strong>.<\/li>\n<li><strong>Nastal timeout.<\/strong>\u00a0Odosielate\u013e zap\u00edna \u010dasova\u010d v\u017edy vtedy, ke\u010f sa zmen\u00ed najstar\u0161\u00ed segment v okne odosielan\u00fdch segmentov. Toto m\u00f4\u017ee nasta\u0165, ak vlo\u017e\u00edme pr\u00e1ve odoslan\u00fd segment do pr\u00e1zdneho okna odosielate\u013ea, alebo ak do\u0161lo potvrdenie, ktor\u00e9 potvrdilo doru\u010denie dovtedy najstar\u0161ieho segmentu (niektor\u00e9 segmenty sa odstr\u00e1nili) a in\u00fd segment v okne sa stal najstar\u0161\u00edm. \u010casova\u010d sa v\u017edy zapne s nejak\u00fdm intervalom \u010dasova\u010da (<em>TimeOutInterval<\/em>). Ak po\u010das tohto intervalu ned\u00f4jde potvrdenie, ktor\u00e9 by potvrdilo doru\u010denie najstar\u0161ieho segmentu, nastane timeout a tento segment sa po\u0161le znova.<\/li>\n<\/ul>\n<p>Na nasleduj\u00facom obr\u00e1zku m\u00f4\u017eeme vidie\u0165 situ\u00e1ciu, kde okno odosielate\u013ea (Stanica A) m\u00e1 kapacitu na 5 segmentov. Druh\u00fd segment so sekven\u010dn\u00fdm \u010d\u00edslom 100 sa stratil na ceste k pr\u00edjemcovi. Pr\u00edjemca (Stanica B) dostane segmenty s \u010d\u00edslami 92, 120, 135 a 141. Segment s \u010d\u00edslom 92 po\u0161le aplika\u010dnej vrstve a o\u010dak\u00e1va segment so sekven\u010dn\u00fdm \u010d\u00edslom 100, lebo ve\u013ekos\u0165 d\u00e1t v tomto segmente bola 8 bajtov. Po\u0161le teda potvrdenie s \u010d\u00edslom potvrdenia 100. N\u00e1sledne dostane segmenty so sekven\u010dn\u00fdmi \u010d\u00edslami 120, 135 a 141. Ke\u010f\u017ee st\u00e1le o\u010dak\u00e1va, ako najstar\u0161\u00ed neprijat\u00fd segment, segment so sekven\u010dn\u00fdm \u010d\u00edslom 100, ulo\u017e\u00ed si tieto nov\u00e9 segmenty prijat\u00e9 mimo poradia do okna pr\u00edjemcu a pre ka\u017ed\u00fd z nich po\u0161le potvrdenie s \u010d\u00edslom potvrdenia 100. Odosielate\u013e d\u00e1t (Stanica A) dostane viackr\u00e1t potvrdenie s rovnak\u00fdm \u010d\u00edslom potvrdenia a vykon\u00e1 r\u00fdchle preposlanie segmentu so sekven\u010dn\u00fdm \u010d\u00edslom 100 e\u0161te pred timeoutom po troch potvrdeniach s rovnak\u00fdm \u010d\u00edslom potvrdenia.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-309 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_37.gif\" alt=\"\" width=\"438\" height=\"549\" \/><\/p>\n<p>Niektor\u00e9 implement\u00e1cie protokolu TCP robia e\u0161te to, \u017ee ak pr\u00edjemca dostane segment mimo poradia, po\u0161le ihne\u010f dve rovnak\u00e9 potvrdenia, aby sa e\u0161te viac ur\u00fdchlilo preposlanie straten\u00e9ho segmentu.<\/p>\n<h3>Nastavenie timeout intervalu<\/h3>\n<p>Hodnota timeout intervalu pre \u010dasova\u010d by mala by\u0165 dostato\u010dne ve\u013ek\u00e1, aby nedoch\u00e1dzalo k zbyto\u010dn\u00fdm op\u00e4tovn\u00fdm poslaniam segmentov, pokia\u013e nedo\u0161lo k strate, len segmenty mali v\u00e4\u010d\u0161ie zdr\u017eanie. Tie\u017e by nemala by\u0165 pr\u00edli\u0161 ve\u013ek\u00e1, aby sme zabr\u00e1nili pomal\u00fdm reakci\u00e1m na stratu segmentu.<\/p>\n<p>U\u017e sme povedali, \u017ee \u010das, za ktor\u00fd od\u00edde segment k pr\u00edjemcovi a vr\u00e1ti sa potvrdenie, naz\u00fdvame round trip time (RTT). Je jasn\u00e9, \u017ee timeout by mal by\u0165 v\u00e4\u010d\u0161\u00ed ako RTT. V pr\u00edpade, \u017ee by RTT bol v\u017edy rovnak\u00fd, sta\u010dilo by nastavi\u0165 timeout o m\u00e1lo (napr. jednu nanosekundu\u00a0\ud83d\ude42\u00a0) viac ako RTT a vedeli by sme \u017ee po uplynut\u00ed timeout intervalu ur\u010dite nastala strata.<\/p>\n<p>RTT je zaka\u017ed\u00fdm in\u00fd. Na ur\u010denie ve\u013ekosti okna potrebujeme sn\u00edmkova\u0165 ka\u017ed\u00fd RTT. Ozna\u010dme posledn\u00fd odmeran\u00fd RTT ako\u00a0<em>SampleRTT<\/em>. Ke\u010f\u017ee jednotliv\u00e9 RTT sa menia \u010dasto v\u00fdrazne, potrebujeme nejak\u00fa stabilnej\u0161iu hodnotu, ktor\u00e1 je podobn\u00e1 priemeru \u201eposledn\u00fdch\u201c RTT. Na tento \u00fa\u010del sa pou\u017e\u00edva premenn\u00e1\u00a0<em>EstimatedRTT<\/em>, predstavuj\u00faca o\u010dak\u00e1van\u00fa hodnotu RTT, definovan\u00e1 nasledovne.<\/p>\n<p><em>EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT<\/em>, kde\u00a0<em>a<\/em>\u00a0je typicky 0,125.<\/p>\n<p>Hodnota\u00a0<em>EstimatedRTT<\/em>\u00a0e\u0161te nie je vhodn\u00e1 na to, aby predstavovala ve\u013ekos\u0165 okna, preto\u017ee pribli\u017ene polovica segmentov by bola potvrden\u00e1 neskoro, lebo by u\u017e do\u0161lo k timeoutu a preposlaniu.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-310 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_32.gif\" alt=\"\" width=\"801\" height=\"509\" \/><\/p>\n<p>Odch\u00fdlka\u00a0<em>EstimatedRTT<\/em>\u00a0od poslednej hodnoty\u00a0<em>SampleRTT<\/em>\u00a0sa d\u00e1 vypo\u010d\u00edta\u0165 ako absol\u00fatna hodnota rozdielu\u00a0<em>SampleRTT \u2013 EstimatedRTT<\/em>. Na ur\u010denie o\u010dak\u00e1vanej odch\u00fdlky , ozna\u010denej\u00a0<em>DevRTT<\/em>, pou\u017eijeme vzorec:<\/p>\n<p><em>DevRTT = (1-b)*DevRTT + b* |SampleRTT \u2013 EstimatedRTT|<\/em>, kde\u00a0<em>b<\/em>\u00a0je typicky 0,25.<\/p>\n<p>Ako v\u00fdsledn\u00fd timeout interval \u010dasova\u010da sa potom pou\u017e\u00edva:\u00a0<em>TimeOutInterval = EstimatedRTT + 4*DevRTT<\/em><\/p>\n<p>T\u00fdm z\u00edskame nov\u00fd interval \u010dasova\u010da pri ka\u017edom prijat\u00ed potvrdenia.<\/p>\n<h3>3.4.4\u2002 Kontrola toku d\u00e1t<\/h3>\n<p>Cie\u013eom kontroly toku d\u00e1t je zabr\u00e1ni\u0165 situ\u00e1cii, ke\u010f pr\u00edjemca nest\u00edha spracov\u00e1va\u0165 prijat\u00e9 d\u00e1ta. Typick\u00fdm pr\u00edkladom by mohlo by\u0165 to, \u017ee pr\u00edjemca v\u0161etky prijat\u00e9 d\u00e1ta posiela rovno na disk a v pr\u00edpade pln\u00e9ho vyu\u017eitia spojenia so \u0161\u00edrkou p\u00e1sma 1 Gb\/s by disk nest\u00edhal tieto d\u00e1ta uklada\u0165.<\/p>\n<p>Ka\u017ed\u00fd soket m\u00e1 pridelen\u00e9 pam\u00e4\u0165ov\u00e9 miesto (buffer pr\u00edjemcu). Na obr\u00e1zku ni\u017e\u0161ie je ve\u013ekos\u0165 tohto pam\u00e4\u0165ov\u00e9ho miesta ozna\u010den\u00e1 ako\u00a0<em>RcvBuffer<\/em>. Toto pam\u00e4\u0165ov\u00e9 miesto sa del\u00ed na okno pr\u00edjemcu (<em>Spare room<\/em>\u00a0ve\u013ekosti\u00a0<em>RcvWindow<\/em>) a na rad segmentov ur\u010den\u00fdch na spracovanie prij\u00edmaj\u00facou aplik\u00e1ciou (<em>TCP data in buffer<\/em>), ktor\u00e9 m\u00f4\u017ee, ale e\u0161te nestihla spracova\u0165. Ke\u010f aplik\u00e1cia nest\u00edha spracov\u00e1va\u0165 d\u00e1ta, zv\u00e4\u010d\u0161uje sa rad segmentov pre prij\u00edmaj\u00facu aplik\u00e1ciu a zmen\u0161uje sa okno pr\u00edjemcu.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-311 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_38.gif\" alt=\"\" width=\"642\" height=\"327\" \/><\/p>\n<p>Keby sa ve\u013ekos\u0165 okna pr\u00edjemcu zmen\u0161ila na nulu, za\u010dali by sa zahadzova\u0165 spr\u00e1vne doru\u010den\u00e9 segmenty. Aby sa tomu zabr\u00e1nilo, oba komunikuj\u00face sokety sa navz\u00e1jom informuj\u00fa o ve\u013ekosti svojho okna pr\u00edjemcu (hodnota\u00a0<em>RcvWindow<\/em>) v hlavi\u010dke TCP segmentu v \u010dasti\u00a0<strong>window<\/strong>.<\/p>\n<p>Odosielate\u013e si pod\u013ea tejto hodnoty m\u00f4\u017ee zmen\u0161i\u0165 svoje okno odosielate\u013ea, ke\u010f\u017ee ve\u013ekos\u0165 okna odosielate\u013ea ur\u010duje maxim\u00e1lny po\u010det odoslan\u00fdch segmentov za \u010das RTT. \u013dudovo povedan\u00e9, ur\u010duje \u201enajvy\u0161\u0161iu povolen\u00fa r\u00fdchlos\u0165\u201c odosielania, teda zmen\u0161enie okna odosielate\u013ea zmen\u0161\u00ed aj prenosov\u00fa r\u00fdchlos\u0165 a t\u00fdm umo\u017en\u00ed pr\u00edjemcovi spracovanie takou r\u00fdchlos\u0165ou, ak\u00fa zvl\u00e1dne.<\/p>\n<h3>3.4.5\u2002 Kontrola zahltenia siete<\/h3>\n<p>Pri intenz\u00edvnej komunik\u00e1cii viacer\u00fdch stan\u00edc cez jeden router a jeden spoj sa m\u00f4\u017ee sta\u0165, \u017ee sa v\u00fdstupn\u00fd buffer routra na niektorom jeho rozhran\u00ed m\u00f4\u017ee zahlti\u0165 a za\u010dne zahadzova\u0165 pakety. Jeden z najjednoduch\u0161\u00edch pr\u00edpadov zahltenia je zobrazen\u00fd na nasleduj\u00facom obr\u00e1zku.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-312 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_54.gif\" alt=\"\" width=\"592\" height=\"260\" \/><\/p>\n<p>Sta\u010d\u00ed, ak v\u0161etky tri spoje maj\u00fa rovnak\u00fa \u0161\u00edrku p\u00e1sma povedzme 100 Mb\/s. Ak by obe vysielaj\u00face stanice vysielali r\u00fdchlos\u0165ou 100Mb\/s, router by nemohol vysiela\u0165 r\u00fdchlos\u0165ou 200 Mb\/s, nutne by sa zahltil a za\u010dal pakety zahadzova\u0165.<\/p>\n<p>U\u017e sme si povedali, \u017ee na zn\u00ed\u017eenie r\u00fdchlosti odosielania je potrebn\u00e9 zmen\u0161i\u0165 okno odosielate\u013ea. Pri kontrole zahltenia budeme pou\u017e\u00edva\u0165 rovnak\u00fd princ\u00edp. Budeme pou\u017e\u00edva\u0165 premenn\u00fa\u00a0<em>Congwin<\/em>\u00a0(Congestion window = okno zahltenia) na ozna\u010denie maxim\u00e1lnej povolenej ve\u013ekosti okna odosielate\u013ea ur\u010denej mechanizmom kontroly zahltenia. V tejto kapitole budeme predpoklada\u0165, \u017ee ve\u013ekos\u0165 okna prijat\u00fdch spr\u00e1v pr\u00edjemcu je v\u017edy v\u00e4\u010d\u0161ia ako\u00a0<em>Congwin<\/em>. Re\u00e1lne je ve\u013ekos\u0165 okna odosielate\u013ea minimum hodn\u00f4t\u00a0<em>Congwin<\/em>\u00a0a\u00a0<em>window<\/em>\u00a0z hlavi\u010dky posledn\u00e9ho prijat\u00e9ho TCP segmentu.<\/p>\n<p>Protokol TCP odhal\u00ed zahltenie siete iba tak, \u017ee zaregistruje str\u00e1canie segmentov. To znamen\u00e1, \u017ee nastane situ\u00e1cia, ke\u010f mus\u00ed op\u00e4tovne posiela\u0165 segmenty: bu\u010f do\u0161li 3 segmenty s rovnak\u00fdm \u010d\u00edslom potvrdenia alebo nastal timeout. TCP to vezme ako sign\u00e1l na to, \u017ee je potrebn\u00e9 spomali\u0165 odosielanie segmentov, teda zmen\u0161i\u0165\u00a0<em>Congwin<\/em>. Na druhej strane, ak sa segmenty nestr\u00e1caj\u00fa, tak je mo\u017en\u00e9, \u017ee r\u00fdchlos\u0165 prenosu sa m\u00f4\u017ee zv\u00fd\u0161i\u0165 a mohlo by sa vyplati\u0165 ve\u013ekos\u0165 okna, t.j.\u00a0<em>Congwin<\/em>\u00a0zv\u00e4\u010d\u0161ova\u0165.<\/p>\n<p>Presne na t\u00fdchto pokusoch o zv\u00e4\u010d\u0161ovanie okna a zmen\u0161en\u00ed okna pri strate je zalo\u017een\u00fd algoritmus kontroly zahltenia siete v TCP, ktor\u00fd sa sklad\u00e1 z 3 hlavn\u00fdch \u010dast\u00ed: 1,\u00a0<strong>Algoritmus AIMD<\/strong>\u00a0= additive increase, multiplicative decrease (zv\u00e4\u010d\u0161ovanie pripo\u010d\u00edtavan\u00edm, zmen\u0161ovanie delen\u00edm), 2,\u00a0<strong>Algoritmus Slow start<\/strong>\u00a0(pomal\u00fd \u0161tart) a 3,\u00a0<strong>prep\u00ednanie<\/strong>\u00a0medzi t\u00fdmito postupmi.<\/p>\n<p><strong>Algoritmus AIMD<\/strong>\u00a0funguje tak, \u017ee pokia\u013e neevidujeme stratu, tak zv\u00e4\u010d\u0161\u00edme\u00a0<em>Congwin<\/em>\u00a0o maxim\u00e1lnu ve\u013ekos\u0165 jedn\u00e9ho segmentu (MSS) v\u017edy po tom, ke\u010f pr\u00edde\u00a0<em>Congwin<\/em>\u00a0potvrden\u00ed. Napr\u00edklad majme\u00a0<em>Congwin<\/em>\u00a0rovn\u00e9 4 MSS. Odo\u0161leme 4 segmenty a \u010dak\u00e1me na ich potvrdenie. Po potvrden\u00ed ka\u017ed\u00e9ho segmentu z okna odosielate\u013ea zv\u00fd\u0161ime ve\u013ekos\u0165 okna\u00a0<em>Congwin<\/em>\u00a0o 1\/4 MSS. Po potvrden\u00ed v\u0161etk\u00fdch 4 segmentov sa n\u00e1m teda zv\u00e4\u010d\u0161\u00ed\u00a0<em>Congwin<\/em>\u00a0o 1 MSS na 5 MSS. Pri potvrdeniach \u010fal\u0161\u00edch 5 segmentov budeme zv\u00e4\u010d\u0161ova\u0165\u00a0<em>Congwin<\/em>\u00a0o 1\/5 MSS. To znamen\u00e1, \u017ee ak je Congwin rovn\u00fd 4 MSS, odo\u0161leme 4 segmenty a po ich potvrden\u00ed zv\u00e4\u010d\u0161\u00edme Congwin na 5 MSS. Potom odo\u0161leme 5 segmentov a po ich potvrden\u00ed zv\u00e4\u010d\u0161\u00edme Congwin na 6 MSS, a tak \u010falej. Tak\u017ee po potvrden\u00ed cel\u00e9ho predch\u00e1dzaj\u00faceho okna segmentov zv\u00e4\u010d\u0161ujeme Congwin o 1 MSS.<\/p>\n<p>Tak\u00e9to zv\u00e4\u010d\u0161ovanie uskuto\u010d\u0148ujeme dovtedy, pokia\u013e nezaregistrujeme stratu segmentu. V takom pr\u00edpade samozrejme po\u0161leme op\u00e4\u0165 straten\u00fd segment, ale hlavne zmen\u0161\u00edme\u00a0<em>Congwin<\/em>\u00a0na polovicu \u2013\u00a0<em>zmen\u0161ovanie delen\u00edm<\/em>. Keby na\u010falej doch\u00e1dzalo k strat\u00e1m, del\u00edme st\u00e1le na polovicu a\u017e na minimum\u00a0<em>Congwin<\/em>\u00a0= 1 MSS.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-313 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_51.gif\" alt=\"\" width=\"636\" height=\"336\" \/><\/p>\n<p><strong>Algoritmus Slow start<\/strong>\u00a0sa pou\u017e\u00edva na r\u00fdchle zistenie priepustnosti spojenia. Napr\u00edklad, ak by sme mali re\u00e1lnu priepustnos\u0165 100 Mb\/s a MSS rovn\u00e9 1500 bajtov = 12000 bitov, tak by sme na dosiahnutie plnej prenosovej r\u00fdchlosti spoja (a teda na prv\u00fa stratu) \u010dakali 83 cyklov zv\u00e4\u010d\u0161ovania Congwin v algoritme AIMD. Pri RTT 200 ms by to bolo a\u017e 16 sek\u00fand. Algoritmus\u00a0<em>Slow start<\/em>\u00a0zv\u00e4\u010d\u0161uje\u00a0<em>Congwin<\/em>\u00a0o 1 MSS pri potvrden\u00ed ka\u017ed\u00e9ho segmentu. To znamen\u00e1, \u017ee po odoslan\u00ed a potvrden\u00ed cel\u00e9ho okna segmentov ve\u013ekos\u0165 okna zdvojn\u00e1sob\u00ed.\u00a0<em>Slow start<\/em>\u00a0za\u010d\u00edna pri ve\u013ekosti okna 1 MSS. Po potvrden\u00ed prv\u00e9ho odoslan\u00e9ho segmentu m\u00e1 ve\u013ekos\u0165 2 MSS, po potvrden\u00ed nasleduj\u00facich 2 segmentov m\u00e1 ve\u013ekos\u0165 u\u017e 4 MSS a tak \u010falej. V na\u0161om predch\u00e1dzaj\u00facom pr\u00edklade by sme dosiahli maxim\u00e1lnu priepustnos\u0165 (a prv\u00fa stratu) u\u017e po siedmom odoslan\u00ed a potvrden\u00ed cel\u00e9ho okna, t. j. po 1,4 sekunde.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-314 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig03_52.gif\" alt=\"\" width=\"502\" height=\"569\" \/><\/p>\n<p>Re\u00e1lne sa v\u0161ak tak\u00fdto exponenci\u00e1lny n\u00e1rast ve\u013ekosti okna reguluje hodnotou\u00a0<em>Threshold<\/em>\u00a0(v preklade prah). Ke\u010f pri algoritme\u00a0<em>Slow start<\/em>\u00a0dosiahneme ve\u013ekos\u0165 okna rovn\u00fa hodnote\u00a0<em>Threshold<\/em>, prech\u00e1dzame na algoritmus\u00a0<em>AIMD<\/em>.\u00a0<em>Threshold<\/em>\u00a0sa na za\u010diatku nastavuje v z\u00e1vislosti od \u0161\u00edrky p\u00e1sma pripojenia tak, aby sa exponenci\u00e1lnym n\u00e1rastom nepresiahla \u0161\u00edrka p\u00e1sma. Ak d\u00f4jde k strate, men\u00ed sa hodnota\u00a0<em>Threshold<\/em>\u00a0na\u00a0<em>Congwin<\/em>\/2 .<\/p>\n<p><strong>Prep\u00ednanie<\/strong>\u00a0medzi t\u00fdmito dvoma pr\u00edstupmi a nastavovanie premenn\u00fdch\u00a0<em>Congwin<\/em>\u00a0a\u00a0<em>Threshold<\/em>\u00a0je riaden\u00e9 udalos\u0165ami. Na za\u010diatku sme v stave\u00a0<em>Slow start<\/em>, ve\u013ekos\u0165 okna\u00a0<em>Congwin<\/em>\u00a0je 1 a poslali sme prv\u00fd segment. M\u00f4\u017eu nasta\u0165 tieto udalosti:<\/p>\n<ul>\n<li>pri\u0161lo potvrdenie pre 1 segment v okne odosielate\u013ea\n<ul>\n<li>ak sme v stave\u00a0<em>Slow start<\/em>\n<ul>\n<li><em>Congwin<\/em>\u00a0=\u00a0<em>Congwin<\/em>\u00a0+ MSS<\/li>\n<\/ul>\n<p>Ak\u00a0<em>Congwin<\/em>\u00a0&gt;\u00a0<em>Threshold<\/em>, prepni sa do stavu\u00a0<em>AIMD<\/em><\/li>\n<li>ak sme v stave\u00a0<em>AIMD<\/em>\n<ul>\n<li><em>pocetCelychMSS<\/em>\u00a0=\u00a0<em>Congwin<\/em>\u00a0celo\u010d\u00edselne vydelen\u00e9 \u010d\u00edslom MSS<\/li>\n<\/ul>\n<p><em>Congwin<\/em>\u00a0=\u00a0<em>Congwin<\/em>\u00a0+ MSS\/\u00a0<em>pocetCelychMSS<\/em><\/li>\n<\/ul>\n<\/li>\n<li>strata identifikovan\u00e1 troma segmentmi s rovnak\u00fdm \u010d\u00edslom potvrdenia\n<ul>\n<li><em>Threshold<\/em>\u00a0=\u00a0<em>Congwin<\/em>\/2<\/li>\n<\/ul>\n<p><em>Congwin<\/em>\u00a0=\u00a0<em>Threshold<\/em>\u00a0prepni sa do stavu\u00a0<em>AIMD<\/em><\/li>\n<li>strata identifikovan\u00e1 timeout-om\n<ul>\n<li><em>Threshold<\/em>\u00a0=\u00a0<em>Congwin<\/em>\/2<\/li>\n<\/ul>\n<p><em>Congwin<\/em>\u00a0= 1 MSS prepni sa do stavu\u00a0<em>Slow start<\/em><\/li>\n<\/ul>\n<h3>3.4.6\u2002 Priepustnos\u0165 TCP protokolu<\/h3>\n<p>Optimisticky predpokladajme, \u017ee k strate doch\u00e1dza v\u017edy pri rovnakej ve\u013ekosti okna W a \u017ee strata nie je nikdy identifikovan\u00e1 timeout-om. Ak ignorujeme aj \u00favodn\u00fd algoritmus\u00a0<em>Slow start<\/em>, tak ve\u013ekos\u0165 okna sa pohybuje medzi W\/2 a W. Ke\u010f si uvedom\u00edme, \u017ee ve\u013ekos\u0165 okna v \u010dase rovnomerne rastie medzi t\u00fdmito dvoma hodnotami, potom klesne na W\/2 a op\u00e4\u0165 pomaly rastie k W, tak zist\u00edme, \u017ee priemern\u00e1 ve\u013ekos\u0165 okna je 0,75 W a teda priepustnos\u0165 0,75 W\/ RTT.<\/p>\n<p>\u010eal\u0161ou zauj\u00edmavou skuto\u010dnos\u0165ou je to, \u017ee ak by sme chceli posiela\u0165 d\u00e1ta r\u00fdchlos\u0165ou napr\u00edklad 10 Gb\/s pri RTT 0,1 sekundy, potrebovali by sme okno ve\u013ekosti 10<sup>9<\/sup>\u00a0b = 128 MB. Ke\u010f sa pozrieme na TCP hlavi\u010dku, m\u00e1me k dispoz\u00edcii 16 bitov na inform\u00e1ciu o ve\u013ekosti vo\u013enej \u010dasti okna pr\u00edjemcu, ktor\u00e9 by malo by\u0165 v\u00e4\u010d\u0161ie alebo rovn\u00e9 ve\u013ekosti okna odosielate\u013ea. Pomocou 16 bitov v\u0161ak vieme vyjadri\u0165 najv\u00e4\u010d\u0161ie \u010d\u00edslo iba 2<sup>16<\/sup>-1=65535 B = 64 KiB. Pri nadv\u00e4zovan\u00ed spojenia sa v\u0161ak cie\u013eov\u00e9 stanice m\u00f4\u017eu dohodn\u00fa\u0165 na mocnine dvojky, ktor\u00fdm sa bude po\u010das celej komunik\u00e1cie n\u00e1sobi\u0165 \u010d\u00edslo uveden\u00e9 v hlavi\u010dke v \u010dasti\u00a0<em>window<\/em>. T\u00e1to mocnina dvojky sa uv\u00e1dza v premennej WSCALE. Najv\u00e4\u010d\u0161ia hodnota WSCALE je 14, teda maxim\u00e1lna ve\u013ekos\u0165 okna m\u00f4\u017ee by\u0165 a\u017e 2<sup>14<\/sup>\u00a0* (2<sup>16<\/sup>-1) t. j. takmer 1 GiB.<\/p>\n<h3>3.4.7\u2002 Spravodlivos\u0165 TCP protokolu<\/h3>\n<p>Spravodlivos\u0165 TCP protokolu znamen\u00e1, \u017ee ak cez rovnak\u00fd spoj (\u00fazke miesto) s prenosovou r\u00fdchlos\u0165ou\u00a0<em>R<\/em>\u00a0prech\u00e1dza\u00a0<em>k<\/em>\u00a0TCP spojen\u00ed (a \u017eiadna \u010fal\u0161ia komunik\u00e1cia), tak ka\u017ed\u00e9 z t\u00fdchto TCP spojen\u00ed vyu\u017e\u00edva rovnak\u00fa prenosov\u00fa r\u00fdchlos\u0165\u00a0<em>R<\/em>\/<em>k<\/em>. Samotn\u00e1 spo\u013eahlivos\u0165 je d\u00f4sledkom kontroly zahltenia siete protokolu TCP, ktor\u00e1 sp\u00f4sob\u00ed, \u017ee pri strate segmentu sa zn\u00ed\u017ei r\u00fdchlos\u0165 odosielania zmen\u0161en\u00edm okna odosielate\u013ea na polovicu (menej \u010dasto na ve\u013ekos\u0165 1 MSS). Pri odosielan\u00ed paketov cez \u00fazke miesto doch\u00e1dza k strat\u00e1m na smerova\u010di pred t\u00fdmto \u00fazkym miestom. Tieto straty zaznamen\u00e1vaj\u00fa v\u0161etci odosielatelia. Ke\u010f ka\u017ed\u00fd z nich pri strate zn\u00ed\u017ei r\u00fdchlos\u0165 odosielania na polovicu, nie je toto spomalenie u v\u0161etk\u00fdch rovnak\u00e9 \u2013 t\u00ed, ktor\u00ed odosielali r\u00fdchlej\u0161ie zn\u00ed\u017eia r\u00fdchlos\u0165 viac ako t\u00ed, ktor\u00ed odosielali pomal\u0161ie (ka\u017ed\u00fd na polovicu svojej r\u00fdchlosti). Postupn\u00fdm opakovan\u00edm str\u00e1t, nerovnak\u00e9ho spomalenia a n\u00e1sledn\u00e9ho rovnak\u00e9ho zvy\u0161ovania r\u00fdchlosti doch\u00e1dza k vyrovnaniu prenosov\u00fdch r\u00fdchlost\u00ed.<\/p>\n<p>T\u00e1to spravodlivos\u0165 sa t\u00fdka iba TCP spojen\u00ed a nem\u00e1 ni\u010d spolo\u010dn\u00e9 s rovnak\u00fdm vyu\u017e\u00edvan\u00edm prenosovej r\u00fdchlosti koncov\u00fdmi stanicami. Ka\u017ed\u00e1 stanica m\u00f4\u017ee ma\u0165 naraz otvoren\u00fd r\u00f4zny po\u010det TCP spojen\u00ed. T\u00e1 stanica, ktor\u00e1 ich m\u00e1 otvoren\u00fdch viac, bude vyu\u017e\u00edva\u0165 v\u00e4\u010d\u0161iu \u010das\u0165 prenosov\u00e9ho p\u00e1sma. Na tomto princ\u00edpe funguj\u00fa aj akceler\u00e1tory s\u0165ahovania napr. s\u00faborov z webov\u00fdch str\u00e1nok. Jednoducho otvoria viac paraleln\u00fdch TCP spojen\u00ed s rovnak\u00fdm serverom a \u201eukradn\u00fa\u201c tak pre seba viac prenosovej r\u00fdchlosti na \u00fakor ostatn\u00fdch TCP spojen\u00ed prech\u00e1dzaj\u00facich cez spolo\u010dn\u00e9 \u00fazke miesto.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>TCP: transmission control protocol,\u00a0RFC 793,\u00a0RFC 1122,\u00a0RFC 1323,\u00a0RFC 2018,\u00a0RFC 2581 Protokol TCP je najpou\u017e\u00edvanej\u0161\u00edm transportn\u00fdm protokolom na internete. Na rozdiel od protokolu UDP realizuje potvrdzovan\u00fd prenos&hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"_links":{"self":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/306"}],"collection":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/comments?post=306"}],"version-history":[{"count":2,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/306\/revisions"}],"predecessor-version":[{"id":469,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/306\/revisions\/469"}],"wp:attachment":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/media?parent=306"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/categories?post=306"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/tags?post=306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}