UDP Pålitlig byteström TCP 6558/G558 DATAKOMMUNIKATION UDP Pålitlig byteström TCP

End-to-End protokoll Underliggande best-effort nätverk paket försvinner data kommer fram i oordning data kommer fram i duplikat paketen har ändlig storlek nätverken kan fördröja vidarebefordringen nästan godtyckligt länge Krav i sista hand leveransgaranti av data datat kommer fram ungefär i önskad ordning precis ett exemplar av datat kommer fram stöd för godtyckligt stora datamängder stöd för synkronisering tillåt mottagaren att reglera sändaren dataflöde stöd flera applikationer samtidigt på varje nod

User Datagram Protocol UDP Enkel demultiplexing Opålitlig och oordnad datagramservice Har inbyggd multiplexering Ingen flödeskontroll Mottagarapplikationer identifierade via portar servrar har kända portnummer listas i /etc/services Headerformat Frivillig checksum: UDP header + data + pseudoheader (IP-headerns protokollnr, source-IP, destination-IP, UDP length)

Pålitlig byteström Innehåll Upprätta koppling / avsluta koppling Sliding window Flödeskontroll Adaptiv time-out

User Datagram Protocol UDP

Transmission Control Protocol TCP Kopplingsorienterad Byteström applikationer sänder bytes TCP skickar segment applikationer läser bytes Full duplex Flödeskontroll: mottagaren hindrar sändaren från att överbelasta mottagaren Rusningskontroll: hindrar sändaren från att fylla nätverket

TCP byteström Application process Write bytes TCP Send buffer Segment Transmit segments Read Receive buffer ■ ■ ■

Datalänk vs Transport Många värdar är samtidigt kopplade koppla upp och riva ner förbindelsen Varierande RTT adaptiv time-out Långa förseningar i nätverket Beredskap att få in mycket sena paket Sändare/mottagare har olika kapaciteter möjlighet att adaptera sändningshastigheten Nätverket är kapacitetsmässigt inhomogent beredskap för kongestion

TCP segmentformat

TCP segmentformat SrcPort, DstPort multiplexerindex (SrcPort,SrcIpAddr,DestPort,DestIpAddr) SequenceNum, Acknowledgement, AdvertisedWindow Sliding window, flow control HdrLen 32 bit words Flags SYN, FIN, RESET, PUSH, URG, ACK Checksum TCP header + data + pseudoheader (SrcIpAddr, DestIPAddr, IP length) UrgPtr Data från början till UrgPtr är av typ URG

TCP uppkoppling Active participant (client) (server) SYN, SequenceNum = x ACK, Acknowledgment =y+1 Acknowledgment =x+1 SYN+ACK, SequenceNum=y,

TCP dataöverföring

TCP tillståndsdiagram

TCP Sliding window protokollet

TCP Sliding window protokollet Sändaren LastByteAcked <= LastByteSent LastByteSent <= LastByteWritten buffra bytes mellan LastByteAcked och LastByteWritten Mottagaren LastByteRead < NextByteExpected NextByteExpected <= LastByteRcvd +1 buffra bytes mellan LastByteRead and LastByteRcvd

Flödeskontroll Sändarens bufferstorlek: MaxSendBuffer Mottagarens bufferstorlek: MaxRcvBuffer Mottagaren: AdvertisedWindow = MaxRcvBuffer –(NextByteExpected- NextByteRead) Sändaren: blockera protokollet ovanför transportnivån om (LastByteWritten-LastByteAcked) > MaxSendBuffer Kvittera allt inkommande data (skicka Ack) Var ihärdig då AdvertisedWindow = 0

Silly Window Syndrome Hur aggressivt skall sändaren skicka halvfulla segment eftersträva segment med data av storleken Maximum Segment Size MSS = MTU – IPheader-TCPHeader Sändaren kan styra Efter att ha meddelat AdvertizedWindow=0 vänta tills det finns utrymme för MSS panta med kvitteringarna Sender Receiver

Nagles’ algoritm Hur länge väntar sändaren med att sända data? för länge: interaktiva applikationer lider för kort: nätverket fylls av små segment strategier: sändarens klocka triggar eller mottagen ACK triggar När data kommer från högre nivå if ( mängden data >= MSS och de annonserade fönstren tillåter) then skicka else if (det finns okvitterat data i buffern) then vänta else skicka datat

TCP: adaptiv retransmission Uppmät SampleRTT för varje segment / ACK par Beräkna det vägda medeltalet av RTT EstRTT = a x EstRTT + b x SampleRTT a + b = 1 a mellan 0,8 och 0,9 b mellan 0,1 och 0,2 Sätt TimeOut på basen av EstRTT TimeOut = 2 x EstRTT

Karn/Partridge algoritm Mät inte RTT vid retransmission Dubblera timeout efter varje retransmission

Jacobson/Karels’ algoritm Ett annat sätt att beräkna medeltal för RTT som beaktar fluktuationer Diff = SampleRTT – EstRTT EstRtt = EstRtt + (d x Diff) Dev = Dev + d x ( |Diff| - Dev ) här är d mellan 0 och 1 Timeouten påverkas av variansen TimeOut = m x EstRTT + f x Dev där m = 1 och f = 4 Obs! algortimen beror på klockans granularitet (t.ex. 500 ms) noggranna timeout-mekanismer viktiga i samband med kongestionskontroll

Övning 5, exempel 1