Transportní vrstva RNDr. Ing. Vladimir Smotlacha, Ph.D. Katedra počítačových systémů Fakulta informačních technologií České vysoké učení technické v Praze Vladimír Smotlacha, 2011 Počítačové sít ě BI-PSI LS 2010/11, Předn. 6 https://edux.fit.cvut.cz/bi-psi Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti
Obsah přednášky transportní vrstva druhy služeb protokoly vytvoření a uzavření spojení řízení toku TCP UDP RTP, RTCP 2
Problém dvou armád A zvítězí, pokud A1 i A2 zaútočí najednou A1 pošle zprávu není jisté že projde A2 odešle potvrzení co když se ztratí zpráva nebo potvrzení? A1 odpoví dalším potvrzením stále není jisté, že A1 i A2 se dohodli další potvrzení,... atd Důkaz neexistence řešení: sporem nechť n je délka nejkratšího protokolu, je poslední potvrzení nezbytné? 3
Služby transportní vrstva hranice mezi aplikací (software) a sítí (technologie) transparentní přenos dat mezi koncovými uživateli spolehlivost řízení datového toku segmentace dat oprava chyb 4
Adresace služba musí mít adresu TSAP Transport Service Access Point předdefinované TSAP ( well-known ) např. port 80 pro http dynamicky přidělované portmapper registruje TSAP pro služby např. BitTorrent 5
Navázání spojení triviální řešeni: CONNECTION REQUEST ---> <--- CONNECTION ACCEPTED problém: zpožděný duplikovaný paket CR vylepšení unikátní identifikátor každé relace omezená životnost paketu 6
Navázání spojení (2) three-way handshake CONECTION REQUEST ---> (seq = x) DATA ---> (seq = x+1, ack = y) <--- ACKNOWLEDGE (seq = y, ack = x) 7
Ukončení spojení asymetrické ukončení jeden účastník ukončí spojení příklad: telefonní hovor symetrické ukončení obě strany se musí dohodnout neexistuje řešení, pokud komunikace není bezpečná Problém dvou armád (Two Armies Problem / Coordinated Attack Problem / Two Generals' Problem) 8
Řízení toku princip stejný jako v linkové vrstvě detekce chybných paketů eliminace duplikovaných paketů sekvenční číslo omezený počet nepotvrzených paketů plovoucí okénko (sliding window) 9
TCP Transmission Control Protocol služba v L4 spojově orientovaná zabezpečená duplexní mnoho implementací různé vylepšení (kontrola zahlcení,...) Reno Tahoe Vegas 10
Hlavička TCP verze IP délka záhlaví typ služby celková délka idetifikace IP datagramu příznaky posunutí fragmentu TTL protokol vyšší vrstvy kontrolní součet IP záhlaví IP adresa odesílatele IP adresa příjemce volitelné položky IP hlavičky zdrojový port TCP cílový port TCP pořadové číslo odesílaného bajtu pořadové číslo očekávaného bajtu délka záhlaví rezerva U A P R S F délka okna kontrolní součet TCP ukazatel naléhavých dat volitelné položky TCP hlavičky data 11
TCP navázání spojení SYN_SENT sn 100; S ; mss1460 LISTEN sn 10; ack 101; AS; mss1460 SYN_RCVD ESTABLISHED sn 101; ack 11; A ; sn 11-20; ack 101; AP sn 101; ack 21; A ESTABLISHED 12
Ukončení spojení FIN_WAIT1 sn 50; ack 70; AF ; sn 70; ack 51; AP; CLOSE_WAIT FIN_WAIT2 sn 51; ack 81; A 11,25min TIME_WAIT 2min, 30s CLOSED sn 81; ack 51; AP sn 181; ack 51; AF sn 51; ack 182; A LAST_ACK CLOSED 13
Zabezpečení kontrolní součty detekce duplicitních paketů opakované odeslání správné seřazení timeout 14
TCP stavový diagram. 15
Socket standardní programátorské rozhraní poprvé v Berkeley UNIX 4.2BSD primitiva SOCKET vytvoření koncového bodu BIND přiřazení adresy k socketu LISTEN schopnost akceptovat spojení ACCEPT pasivní akceptace spojení CONNECT aktivní pokus o spojení SEND odeslání dat RECEIVE přijetí dat CLOSE uvolnění spojení 16
Okénko příjemce rezervuje buffer okénko pro přijímaná data příjemce v odpovědi uvádí aktuální velikost okna okno zmenšuje, pokud data nestíhá zpracovat odesílatel nesmí vyslat více dat 17
Sliding window zdroj: http://condor.depaul.edu/jkristof/technotes/tcp.html 18
Potvrzování (acknowledge) příjemce odesílá ACK uvede pořadové číslo byte, který se očekává tím potvrdí, že všechny předešlé byte byly přijaty není nutné všechny potvrzovat pakety jednotlivě timeout (u odesílatele) nepřišlo potvrzení do očekávané doby vysílání se vrátí k prvnímu nepotvrzenému paketu 19
Potvrzování (2) duplicitní ACK pokud některý paket nepřijde, ale následující ano, příjemce zopakuje poslední ACK využije se jako indikátor, že paket se možná ztratil timeout (u příjemce) do očekávaného okamžiku nepřišel nový paket odešle se znovu poslední ACK max. 3x opakovat 20
Proměnné Některé proměnné využité v kontrole zahlcení: MSS (Maximum Segment Size) max. velikost posílaného paketu definuje příjemce SSTHRESH (Slow-start Threshold) hranice pravděpodobného zahlcení odhad, kolik nepotvrzených dat lze odeslat v násobcích MSS CWND (Congestion Window) okénko odesílatele kolik dosud nepotvrzených dat odesílatel vyšle 21
Kontrola zahlcení okénko odesílatele (Congestion Window) pomalý start ( slow start ) počáteční hodnota CWND je 1 zpočátku se okénko odesílatele (CWND) zvětšuje o 1 po každém ACK velikost okénka roste exponenciálně!! po dosažení SSTHRESH se CWND zvětšuje lineárně 22
Kontrola zahlcení (2) zahlcení (congestion) ztratil se buď paket nebo jeho ACK pokud ACK nepřijde vůbec (timeout) opakuje se vysílání od potvrzeného paketu opakuje se slow start pokud 3x přijde opakované ACK staršího paketu (duplicitní ACK), aktivuje se fast retransmit a fast recovery ztracený paket je znovu odeslán (nikoliv ale následující) tzv. selective retransmit CWND se zmenší na polovinu 23
Využití TCP všude, kde je nutný zabezpečený datový kanál není nutné pro malé bloky dat má velkou režii (čas i data) nevhodné pro real-time aplikace: VOIP, streaming paket je doručen za každou cenu nežádoucí zpoždění vestavné systémy (embedded-systems) příliš komplexní 24
UDP User Datagram Protocol služba v L4 nespojovaná nezabezpečená porty max 64 kb dat fragmentace v IP je nežádoucí např. DNS přenáší nejvíce 512 Byte 25
Hlavička UDP verze IP délka záhlaví typ služby celková délka idetifikace IP datagramu příznaky posunutí fragmentu TTL protokol vyšší vrstvy kontrolní součet IP záhlaví IP adresa odesílatele IP adresa příjemce volitelné položky IP hlavičky zdrojový port UDP délka dat cílový port UDP kontrolní součet UDP záhlaví data 26
Využití UDP malé bloky dat, pokud nevadí případná ztráta je nežádoucí režie TCP real-time aplikace je lepší ztratit část dat než čekat 27
RTP Real-time Transport Protocol přenos proudu (stream) dat mezi koncovými body v reálném čase hlavička obsahuje timestamp čas od začátku streamu jednotka závisí na aplikaci umožní interpretovat přijatý blok implementováno většinou nad UDP 28
Využiti RTP libovolné multimediální formáty H.264, MPEG-4, MJPEG, MPEG,... videokonference data streaming IP telefonie 29
Poděkování Janu Kubrovi z FEL ČVUT za poskytnutí slajdů, z nichž některé byly částečně využity v této přednášce 30
Děkuji za pozornost 31