- L4 vrstva
- porty
- tcp, udp
- adresování
- end-to-end správa spojení
- QoS (zotavení z chyb. spolehlivost, řízení toku a zahlcení)
- spousta výzkumu v aktuální době
- berkley sockets
- ip je best effort
- pokud je problém musí řešit vrstva né L2 L3
- chci const bitrate, const zpoždění, 0 věcí ztracených -> musíme mít buffer
- fixní buffer - co když buffer bude plný
- proměnné buffery = není vhodně pro routery, ale pro koncová zařízení
- sdílené buffery
- dichotomie cílů
- end-to-end systémy = servery, laptopy, …
- síť
- problém je, že buffery jsou konečné velikosti
- kapacity příjemce a síťě -> flow a congestion control
-
goodput
- v internetu mnoho routerů s různými parametry
- od určitého bodu se nám goodput začne rozpadat místo toho, aby se blížil k limitu propustnosti
-
delay
- od určitého bodu skáče na dlouhé zpoždění
-
alokace band width
- pokud chceme řešit problémy, musíme mít chytřejší routery - to se v 60. letech nechtělo, kvůli implementaci a monopolu nad routery
- je potřeba v síti, neboť omezení 1 uživatele tyto problémy nevyřeší
- problém s ip adresou je identifikátor rozhraní, stejné jako
- bitové chyby
- paketové chyby
- vytvoření spojení, zrušení spojení, pak nové spojení, a se zpožděním přijde paket z prvního spojení
- navázání spojení
- poslání balíku
- zrušení balíku
- nový request -> ack
- starý duplikát -> reject
- duplikátní connection request a duplikátní ACK -> reject
- ztratí se ACK - máme timer
- Timeout
- Negativní potvrzení - pro spolehlivé spojení!, spíš nepoužíváme
- fixní je nepraktický - ping v counter striku
- lze odvodit z Route Trip Time!
- problémy:
- dlouho čekáme na ztracený paket
- příliš malý - hází do sítě duplicitní pakety
- bere route trip time
- konstanta a
- zjemněný timeout srrt
- nejvíc ovlivňuje konstanta a a srtt0!
- znovu zaslání
- ARQ = Automatic Repeat/Request - čeká na 1 balík s time outem
- rychleji
- Stop and wait ARQ - špatná efektivita, klouzavé okno velikost 1
- Go back N ARQ
- buffer na straně odesílatele, posíláme N zpráv
- cíl = mít na cestě tolik balíku, jaké je velikost okna
- plýtvá šířku pásma
- Selektivní znovu zaslání ARQ
- 2 okna na straně příjemce a odesílatele
- fast retransmit - hned pošle který přijal
- bitová maska - pošle se na konci timeoutu / přijetí všech, které byly přijaty
- negativ ack - po nějaké době pošlu negativní ack
- SMART
- bitová maska v každém acku
- error-control window
- sliding window = klouzavé okno
- nenarůstá delay
- redundance bytů
- klesá goodput - k + m bytu
- repair vs avoid
- avoid není jenom možný - prostě někdy selže - všichni uživatelé F5
- vyhlazuji stream paketů na stejný stream
- hodně bufferů
- potřeba virtuálních okruhů
- reliable transfer
- inorder byte stream - pouze množství bytů co v balíku je
- flow control
- connection oriented
- ECN = explicit congestion notification bit
- zahájení : SYN, SYN + ACK, ACK
- ukončení : FIN, FIN + ACK, ACK
- potvrzení
- kumulativní - potvrzuji vše byty před danou velikostí
- selektivní - pokud 3x ack, nečeká na timeout a znovu pošle
- nevýhody
- head-of-line blocking
- vše je blokováno 1 ztraceným paketem (protože in order
- nepodporuje multihome - napojeno na IP
- velká režie
- ssthresh = slow start threshold, pomalejší nárůst okna
- tcp tahoe - když dolezlo na strop, tak window size na 0
- tcp westwood
- když 3 duplic ack, tak snížím na 1/2, komunikace je, jen ztrácím pakety
- pokud timeout - síť zahlcena
- tcp cubic - kubické křivky, asymptoticky se blížím ke kapacitě síťě, pak rychle zvednu
- connection less - problém se zahlcením, trpí TCP
- UDP s congestion control
- minimální overhead pouze pro congestion control
- best effort
- žádné znovu posílání
- ustanovení spojení - connection oriented
- 3way handshake
- Request + response + ack, data + ack, Close req + close + reset
- řízení zahlcení - ccid2 = tcp, ccid3 =
- TCP neumí využít více síťovek na jednom pc
- Bez HoL blockingem
- TCP problém s inorder byte streamem!
- -> message stream (hranice aplikačních dat jsou respektovány)
- zvětšila signalizační režie
- connection management
- multihoming
- 4-way handshake (zabraňuje syn-flood - spam vytvoření připojení)
- path MTU discovery - obrana proti fragmentaci
- komunikace
- spojení: INT, INT + ack, cookie echo, cookie ack
- data paket (seriove číslo + délka) + SACK
- multiplexing tcp
- použití příjmu/poslání paketů, přes více rozhraní
- řízení spojení
- při navázání dodatečný option s “tokenem”
- 2 druhy sekvenčních čísel - subflow a data
- subflow = tcp hlavička
- data = pro celková data pro poskládání dohromady
- nezávislá sliding window
- řízení zahlcení
- férové s tcp
- vlastní algoritmy
- nevýhoda = in-order byte stream!!
- over optimalizace webových služeb googlu - přenést míň dat, zrychlit doručování služby
- problém s tcp a tls -> 3x rtt před začátkem komunikace
- běží nad UDP -> problém s NATem, nechci nový protokol a učit routery
- multiplexing před UDP (do několika streamů)
- lepší než spdy - streamovat obsah webu v podobě, co není čistá txtová verze webu
- packet pacing predikce bandwith
- proaktivní znovu posílání
- zpráva
- je vědom hranic aplikačních zpráv oproti TCP
- rámec 1 obalím hlavičkou a pošlu, taky přidám rámec 1 do paketu 2 (do jiného streamu)
- “shape-shiftovací hlavičku” - hlavička má variabilní velikost!, daná public flags
- Forward error correction
- data které se ztratí, tak jsme schopni odvodit z dalších paketů. podle parity - ale posíláme více dat
- řízení toku
- znovu posílání - largest observed, missing
- odstranění ssl handshaku - stk
- znovu použití komunikace/nastavení při opakovaném připojení
- řízení zahlcení
- tcp cubic - zkoušíme se blížit thresholdu, pak zkusíme větší
- všechny spojení jsou neustálé - zbytečné počatí a ukončení spojení
- synchronizace stavu
-
- send = 3*delta t- odesílací časovač
- receive = 2*delta t - přijímací časovač
- pozoruje parametr delta t u časovačů
- management spojení
- resetování/ukončení - podle vypršení časovače - smažeme hodnoty
- podmínky pro otevření
- žádné spojení neexistuje, zahazujeme paket, které by vytvořili spojení nebo jsou duplikáty dat
- pokud spojení existuje, zahazujeme pakety z předchozího spojení
-
- randezvous mechanismu
- pomocí flow control received není schopen přijímat
- v aktuální síti neimplementovatelné
- nejsem zaručit real time čas u časovačů - časovače narostou