Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Versjon 2.0 / 24.09.2004 Transportlaget3-1 Kapittel 3 Transport Layer Slides adapted from the slides accompanying the book of Kurose & Ross. © 1996-2004.

Liknende presentasjoner


Presentasjon om: "Versjon 2.0 / 24.09.2004 Transportlaget3-1 Kapittel 3 Transport Layer Slides adapted from the slides accompanying the book of Kurose & Ross. © 1996-2004."— Utskrift av presentasjonen:

1 Versjon 2.0 / Transportlaget3-1 Kapittel 3 Transport Layer Slides adapted from the slides accompanying the book of Kurose & Ross. © J.F Kurose and K.W. Ross, All Rights Reserved Norsk versjon: © Christian F Heide, Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

2 Versjon 2.0 / Transportlaget3-2 Kapittel 3: Transportlaget Mål: r forstå prinsippene bak trangsportlags- tjenester: m multipleksing/demulti- pleksing m pålitelig dataoverføring m flytkontroll m metningskontroll r lære om transportlags- protokoller i Internett: m UDP: forbindelsesløs transport m TCP: forbindelsesorientert, pålitelig transport m TCP metningskontroll

3 Versjon 2.0 / Transportlaget3-3 Kapittel 3 – oversikt r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

4 Versjon 2.0 / Transportlaget3-4 Transporttjenester og protokoller applikasjon transport nettlag linklag fysisk applikasjon transport nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk logisk ende til ende-transport

5 Versjon 2.0 / Transportlaget3-5 Transportlag vs. nettlag r nettlag: logisk kommunikasjon mellom maskiner r transportlag: logisk kommunikasjon mellom prosesser m benytter seg av og bygger videre på nettlagstjenester Analogi: 12 barn sender brev til 12 andre barn r prosesser = barn r app meldinger = brev i konvolutter r maskiner = hus r transportprotokoll = Anne og Bjørn r netlagsprotokoll = postens tjenester

6 Versjon 2.0 / Transportlaget3-6 Internett transportlagsprotokoller r pålitelig, i rekkefølge leveranse (TCP) m metningskontroll (congestion control) m flytkontroll (flow control) m oppsett av forbindelse r upålitelig, uordnet leveranse: UDP m enkel utvidelse av IP (“best-effort”) r tjenester som ikke gis: m forsinkelsesgaranti m båndbreddegaranti applikasjon transport nettlag linklag fysisk appliasjon transport nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk logisk ende til ende transport

7 Versjon 2.0 / Transportlaget3-7 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services è 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

8 Versjon 2.0 / Transportlaget3-8 Multipleksing/demultipleksing applikasjon transport nettlag linklag fysisk P1 applikasjon transport nettlag linklag fysisk applikasjon transport nettlag linklag fysisk P2 P3 P4 P1 maskin 1 maskin 2 maskin 3 = prosess= socket levere mottatte segmenter til korrekt socket Demultipleksing hos mottager: samle data fra flere sockets, sette på header som senere brukes for demultipleksing Multipleksing hos avsender:

9 Versjon 2.0 / Transportlaget3-9 Hvordan demultipleksing virker r maskin mottar IP-datagrammer m hvert datagram har avsenders og mottakers IP- adresse m hvert datagram bærer med seg ett transportlags- segment m hvert segment har avsenders og mottagers portnummer (“well-known” portnumre for spesifikke applikasjoner) r maskin bruker IP-adresser og portnumre for å dirigere hvert segment til riktig socket avs. portnrmott. portnr 32 bits applikasjons- data (melding) andre header-felter TCP/UDP segmentformat

10 Versjon 2.0 / Transportlaget3-10 Forbindelsesløs demultipleksing r Etablere sockets med portnumre: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); r UDP socket identifiseres ved følgende tallpar: (mott. IP-adresse, mott. portnummer) r Når maskin mottar UDP- segment: m sjekker mottagers portnummer i segmentet m sender UDP-segmentet til socket med angjeldende portnummer r IP-datagrammer med annen avsender IP- adresse og/eller avsender portnummer sendes til samme socket

11 Versjon 2.0 / Transportlaget3-11 Forbindelsesløs demultipleksing DatagramSocket serverSocket = new DatagramSocket(6000); klient IP:B P2 klient IP: A P1 P3 server IP: C SP: 6000 DP: 9000 SP: 9000 DP: 6000 SP: 6000 DP: 5000 SP: 5000 DP: 6000 SP angir “returadresse”

12 Versjon 2.0 / Transportlaget3-12 Forbindelsesorientert demux r TCP-socket identifisert ved 4-tuppel: m avsender IP-adresse m avsender portnummer m mott. IP-adresse m mott. portnummer r mottager bruker alle fire verdier for å levere segmenter til korrekt socket r Server maskin kan støtte mange samtidige TCP-sockets: m hver socket identifiseres ved sitt eget “4-tuppel” r Webservere har ulike sockets for hver klient som kobler seg til m ikke-persistent HTTP vil ha ulike sockets for hver forespørsel

13 Versjon 2.0 / Transportlaget3-13 Forbindelsorientert demultipleksing klient- IP: B P1 klient- IP: A P1P2P4 server- IP: C AP: 9157 MP: 80 AP: 9157 MP: 80 P5P6P3 M-IP: C A-IP: A M-IP: C A-IP: B AP: 5775 MP: 80 M-IP: C A-IP: B

14 Versjon 2.0 / Transportlaget3-14 Forbindelsesorientert demux: Threaded web server klient- IP:B P1 klient- IP: A P1P2 server- IP: C AP: 9157 MP: 80 AP: 9157 MP: 80 P4 P3 M-IP: C A-IP: A M-IP: C A-IP: B AP: 5775 MP: 80 M-IP: C A-IP: B

15 Versjon 2.0 / Transportlaget3-15 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing è 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

16 Versjon 2.0 / Transportlaget3-16 UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” Internett transport- protokoll r “best effort” tjeneste, UDP segmenter kan: m forsvinne på veien m leveres til applikasjonen i feil rekkefølge r forbindelsesløs: m ingen håndhilsing mellom avsender og mottager m hvert UDP-segment håndteres uavhengig av andre Hvorfor finnes UDP? r ikke noe oppsett av forbindelse (mindre forsinkelse) r enkel: ingen tilstandsinfo å passe på r liten segment-header r ingen metningskontroll: UDP kan pøse ut pakker så hurtig man ønsker

17 Versjon 2.0 / Transportlaget3-17 UDP: User Datagram Protocol [RFC 768] r benyttes ofte for streaming, som er m tapstolerant m følsom for bitrate r annen bruk av UDP m DNS m SNMP r pålitelig overføring over UDP: addér pålitelighet på applikasjonslaget m applikasjonsspesifikk feilhåndtering! senderport #mott.port # 32 bits Applikasjons- data (melding) Formatet til UDP-segmenter lengde sjekksum Lengde i byte av UDP- segment inklusive header

18 Versjon 2.0 / Transportlaget3-18 UDP sjekksum Sender: r håndtere innholdet i segmentet som sekvens av 16-bits heltall r sjekksum: eners komplement addisjon av segmentets innhold r sender legger sjekksum- verdi inn i sjekksumfeltet i UDP-headeren Mottager: r beregner sjekksummen til mottatt segment r sammenlign med verdien i sjekksumfeltet: m forskjellig  feil detektert m like  ingen feil detektert (men segmentet kan allikevel inneholde feil…) Mål: oppdage bitfeil i det overførte segmentet

19 Versjon 2.0 / Transportlaget3-19 Sjekksum-eksempel r Merk: m Når vi adderer tall, skal eventuell minne fra MSB adderes til resultatet r Eksempel: adder to 16-bits tall MSB minne sum sjekksum

20 Versjon 2.0 / Transportlaget3-20 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP è 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

21 Versjon 2.0 / Transportlaget3-21 Prinsipper for pålitelig dataoverføring r den upålitelige kanalens karakteristika vil bestemme kompleksiteten til “reliable data transfer” protkoll (rdt)

22 Versjon 2.0 / Transportlaget3-22 Reliable data transfer sender- side mottager- side rdt_send(): kalles ovenfra, (f.eks. av app.). Data skal leveres til mottagers applikasjonslag udt_send(): kalles av rdt for å sende data over den upålitelige kanalen rdt_rcv(): kalles når pakke ankommer på mottagersiden deliver_data(): kalles av rdt for å levere data til laget over

23 Versjon 2.0 / Transportlaget3-23 Tilstandsmaskin tilstand 1 tilstand 2 hendelse som medfører tilstandsendring aksjoner på bakgrunn av tilstandsendring tilstand: når man er i en tilstand, vil neste tilstand være endtydig bestemt av neste hendelse

24 Versjon 2.0 / Transportlaget3-24 rdt1.0: pålitelig overføring over en pålitelig kanal Vent på kall ovenfra packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Vent på kall nedenfra rdt_rcv(packet) sender mottager

25 Versjon 2.0 / Transportlaget3-25 rdt2.0: kanal med mulighet for bitfeil r kanalen kan gi bitfeil i overførte pakker m husk: UDP-sjekksum kan oppdage bitfeil r spørsmålet: hvordan håndtere bitfeil: m acknowledgements (ACK): kvittering. Mottager varsler senderen når pakken er mottatt uten feil m negative acknowledgements (NAK): Negativ kvittering. Mottager varsler senderen når pakken hadde bitfeil m sender retransmitterer pakken ved mottak av NAK m eksempler fra dagliglivet på bruk av ACK og NAK?  nye mekanismer i rdt2.0 : m feildeteksjon m feedback fra mottager: kontrollmeldinger (ACK, NAK) fra mottager til avsender

26 Versjon 2.0 / Transportlaget3-26 rdt2.0: tilstandsmaskin (bitfeil) vent på kall ovenfra snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) vent på ACK eller NAK vent på kall nedenfra sender mottager rdt_send(data) 

27 Versjon 2.0 / Transportlaget3-27 rdt2.0: operasjon uten feil vent på kall ovenfra snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) vent på ACK eller NAK vent på kall nedenfra rdt_send(data) 

28 Versjon 2.0 / Transportlaget3-28 rdt2.0: feilscenario vent på kall ovenfra snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) vent på ACK eller NAK vent på kall nedenfra rdt_send(data) 

29 Versjon 2.0 / Transportlaget3-29 rdt2.0 har en vesentlig feil! Hva skjer hvis ACK/NAK får bitfeil? r sender kan da ikke vite hva mottager ønsket å gi beskjed om! r kan ikke bare sende på nytt (retransmittere): mulighet for duplikater Hva kan gjøres?  sekvensnummer Håndtering av duplikater: r sender setter på sekvens- nummer på hver pakke r sender retransmitterer pakke ved feil i ACK/NAK r mottager kaster eventuelle duplikatpakker Senderen sender en pakke og stopper så og venter på respons fra mottager “stop and wait”

30 Versjon 2.0 / Transportlaget3-30 rdt2.1: Sender (m/sekvensnummer) vent på kall 0 ovenfra sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) vent på ACK eller NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) vent på kall 1 ovenfra vent på ACK eller NAK 1  

31 Versjon 2.0 / Transportlaget3-31 rdt2.1: Mottager (m/sekvensnummer) vent på 0 neden- fra sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) vent på 1 neden- fra rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)

32 Versjon 2.0 / Transportlaget3-32 rdt2.1: diskusjon Sender: r sekvensnummer på pakker r det er nok med to sekvensnumre (0 og 1). Hvorfor? r må sjekke om mottatt ACK/NAK har bitfeil r dobling av antall tilstander m tilstand må “huske” om forrige pakke har sekvensnummer 0 eller 1 Mottager: r må sjekke om mottatt pakke er duplikat m tilstand indikerer om 0 eller 1 er forventet sekvensnummer r merk: mottager kan ikke vite om dens sist sendte ACK/NAK ble korrekt mottatt av sender

33 Versjon 2.0 / Transportlaget3-33 rdt2.2: en NAK-fri protokoll r samme funksjonalitet som rdt2.1, uten bruk av NAK r istedenfor NAK, sender mottager ACK for siste pakke som er mottatt korrekt m mottager må inkludere sekvensnummeret til den pakken den ACKer r dupliserte ACK til sender har samme betydning som mottak av NAK ville hatt. Resultat: retransmisjon av forrige pakke

34 Versjon 2.0 / Transportlaget3-34 rdt2.2: deler av senders og mottagers tilstandsmaskiner (ikke NAK) vent på kall 0 ovenfra sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) vent på ACK 0 deler av senders tilstandsmaskin vent på 0 ned- enfra rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) deler av mottagers tilstandsmaskin 

35 Versjon 2.0 / Transportlaget3-35 rdt3.0: kanal med bitfeil og pakketap Ny antagelse: på underliggende kanal kan også ha pakketap (både data og ACK) m sjekksum, sekvensnr, ACK, retransmisjoner vil vært til help, men ikke tilstrekkelig Mulig løsning: sender venter en “rimelig” tid på ACK r retransmitterer dersom det ikke har kommet ACK i løpet av denne tiden r hvis pakke eller ACK bare er forsinket (ikke tapt): m retransmittert pakke vil være duplikat, men bruk av sekvensnummer håndterer dette m mottager må angi sekvens- nummeret til pakken den ACKer r krever bruk av timer (nedtellingsklokke)

36 Versjon 2.0 / Transportlaget3-36 rdt3.0 sender (pakketap) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) vent på ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) vent på kall 1 ovenfra sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) vent på kall 0 ovenfra vent på ACK1  rdt_rcv(rcvpkt)   

37 Versjon 2.0 / Transportlaget3-37 rdt3.0 i aksjon

38 Versjon 2.0 / Transportlaget3-38 rdt3.0 i aksjon

39 Versjon 2.0 / Transportlaget3-39 Ytelsen til rdt3.0 r rdt3.0 fungerer, men ytelsen er elendig r eksempel: 1 Gb/s link, 15 ms e-e gangtid, 1KB pakke: T transmit = 8kb 1 Gb/s = 8  s m U sender : utnyttelse (utilization) – andel av tiden som senderen sender data m 1KB pakke hvert 30 ms -> ca 260 kb/s over en 1 Gb/s link!  protokollen begrenser utnyttelsen av de fysiske ressursene L (pakkelengde i bit) R (datarate i b/s) =

40 Versjon 2.0 / Transportlaget3-40 rdt3.0: “stop-and-wait”-operasjon første bit sendt ved tiden, t = 0 sendermottager RTT siste bit i pakken sendt t = L / R første bit ankommer siste bit ankommer, sender så ACK ACK ankommer, send neste pakke, t = RTT + L / R

41 Versjon 2.0 / Transportlaget3-41 “Pipelined protocols” Pipelining: sender sende flere pakker etterhverandre før den må stoppe og vente på kvittering m antall sekvensnumre må økes m pakker må kunne bufres hos sender og/eller mottager r To generiske former for “pipelined protocols”: ”go-back-N” og “selective repeat”

42 Versjon 2.0 / Transportlaget3-42 Pipelining: øket utnyttelse av kapasiteten første bit sendt, t = 0 sendermottager RTT siste bit i pakken sendt, t = L / R første bit ankommer siste bit ankommer, send ACK ACK ankommer, send neste pakke, t = RTT + L / R siste bit i pakke 2 ankommer, send ACK siste bit i pakke 3 ankommer, send ACK Linjeutnyttelsen øker med en faktor 3!

43 Versjon 2.0 / Transportlaget3-43 Sliding window Pakker som er sendt Pakker som kan sendes (vindu) Sending av pakker krymper vinduet fra venstre Mottak av ACK gjør at høyre kant flyttes mot høyre Pakker Eksempel med tre bits sekvensnummer

44 Versjon 2.0 / Transportlaget3-44 Sliding window - senderside P7, P0, P ACK Eksempel med tre bits sekvensnummer

45 Versjon 2.0 / Transportlaget3-45 Go-Back-N (GBN) Sender: r k-bit sekvensnummer i pakkehode (vindusstørrelse: N=2 k pakker) r et “vindu” på opp til N = 2 k påfølgende, ukvitterte pakker tillatt r ACK(n): Kvittering for alle pakker t.o.m. sekvensnummer n  kumulativ ACK r timer for hver pakke som er underveis (sendt men ikke kvittert) r timeout(n): retransmittér pakke n og alle etterfølgende

46 Versjon 2.0 / Transportlaget3-46 GBN: tilstandsmaskin for sender vent start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) timeout rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) 

47 Versjon 2.0 / Transportlaget3-47 GBN: tilstandsmaskin for mottager ACK-only: send alltid ACK for korrekt mottatt pakke med høyeste sekvensnummer som er i rekkefølge m kan generere duplikatkvitteringer (ACK)  trenger bare å huske expectedseqnum r pakke som kommer utenom tur: m kast -> ingen bufring hos mottager! m Send ny ACK med sekvensnummer til siste pakke i riktig rekkefølge vent udt_send(sndpkt) default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) 

48 Versjon 2.0 / Transportlaget3-48 GBN i aksjon

49 Versjon 2.0 / Transportlaget3-49 Selective repeat (selective reject) r mottager kvitterer individuelt for korrekt mottatte pakker m bufrer pakker for leveranse i rett rekkefølge til laget over r sender retransmitterer bare pakker den ikke har fått kvittering for m sender må ha timer for hver ukvittert pakke r sendervindu m N konsekutive sekvensnumre m vinduet begrenser sekvensnumre til sendte men ukvitterte pakker

50 Versjon 2.0 / Transportlaget3-50 Selective repeat: sender- og mottagervinduer

51 Versjon 2.0 / Transportlaget3-51 Selective repeat data ovenfra: r hvis neste tilgjengelige sekvensnummer er i vinduet, send pakken timeout(n): r send pakke n på nytt, restart timer ACK(n) i [sendbase, sendbase+N]: r merk pakke n som mottatt r dersom n er minste ukvitterte pakke, flytt venstre kant av vinduet til neste ukvitterte sekvensnummer sender pakke n i [rcvbase, rcvbase+N-1] r send ACK(n) r utenom tur: legg pakke i buffer r i tur: lever til laget over, (også bufrede pakker i tur), flytt vindu til neste sekvensnummer som ikke er mottatt pakke n i [rcvbase-N, rcvbase-1] r send ACK(n) ellers: r ignorér mottager

52 Versjon 2.0 / Transportlaget3-52 Selective repeat i aksjon

53 Versjon 2.0 / Transportlaget3-53 Selective repeat: dilemma Eksempel: r sekvensnumre: 0, 1, 2, 3 r vindusstørrelse: 3 r mottager ser ingen forskjell på de to scenariene r videresender dupliserte data i (a)  relasjon mellom antall sekvensnummer og vindusstørrelse?

54 Versjon 2.0 / Transportlaget3-54 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer è 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

55 Versjon 2.0 / Transportlaget3-55 TCP: Oversikt RFC: 793, 1122, 1323, 2018, 2581 r full dupleks: m toveis datastrøm i samme forbindelse m MSS: maximum segment size r forbindelsesorientert: m håndhilsing (utveksling av kontrollmld) før data sendes r flytkontroll: m sender ovsersvømmer ikke mottager med data r punkt-til-punkt: m en sender, en mottager r pålitelig, leverer strøm: m ingen meldingsgrenser sett fra applikasjonen r “pipelined”: m TCP metnings- og flyt- kontroll setter vindus- størrelsen r sender og mottagerbuffer

56 Versjon 2.0 / Transportlaget3-56 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer  3.5 Connection-oriented transport: TCP è segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

57 Versjon 2.0 / Transportlaget3-57 TCP segmentstruktur senderport # mott.port # 32 bit applikasjons- data (variabel lengde) sekvensnummer kvitteringsnummer Mottagervindu Urg data pnter sjekksum F SR PAU head len not used Opsjoner (variabel lengde) URG: urgent data (normalt ikke brukt) ACK: ACK # gyldig PSH: send data nå (normalt ikke brukt) RST, SYN, FIN: etablering av og nedkobling av forbindelse antall byte mottager kan motta (“vindu”) angir byte (oktetter), ikke segmenter Sjekksum (som i UDP)

58 Versjon 2.0 / Transportlaget3-58 TCP sekvensnummer og ACK Sekvensnumre: m bytestrøm – nummeret til første byte i segmentets datafelt ACK: m sekvensnummer for neste byte som forventes fra den andre siden m kumulative ACK r Hvordan håndteres segmenter som kommer utenom tur (“out-of- order segments”) m A: TCP spes. angir ikke dette  opp til implementering Maskin A Maskin B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 Bruker taster ‘C’ maskin ACKer mottak av ekko (‘C’) tid enkelt “telnet”-scenario maskin ACKer mottak av ‘C’, returnerer ‘C’ (ekko)

59 Versjon 2.0 / Transportlaget3-59 TCP “Round Trip Time” og “Timeout” Q: hvordan sette TCPs timeout- verdi? r lengre enn RTT m men RTT varierer r for liten: for tidlig timeout m unødige omsendinger r for lang: sen reaksjon på segmenttap Q: hvordan estimere RTT?  SampleRTT : målt tid fra segment er sent til kvittering er mottatt m måling ignorerer omsendinger  SampleRTT vil variere, ønsker en “glattere” estimert RTT  midler over flere målinger istedenfor kun å bruke siste måling ( SampleRTT)

60 Versjon 2.0 / Transportlaget3-60 TCP “Round Trip Time” og “Timeout” EstimatedRTT = (1-  ) · EstimatedRTT +  · SampleRTT r Ekponentielt vektet gjennomsnitt r betydning av forrige sample reduseres eksponentielt hurtig  typisk verdi:  = 0.125

61 Versjon 2.0 / Transportlaget3-61 Eksempel på RTT-estimering:

62 Versjon 2.0 / Transportlaget3-62 TCP “Round Trip Time” og “Timeout” Setting av “timeout”  EstimtedRTT + “sikkerhetsmargin”  stor variasjon i EstimatedRTT  større sikkerhetsmargin r først estimeres hvor mye SampleRTT avviker fra EstimatedRTT: TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typisk:  = 0.25) Deretter settes “timeout”-tiden:

63 Versjon 2.0 / Transportlaget3-63 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure è reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

64 Versjon 2.0 / Transportlaget3-64 TCP: pålitelig dataoverføring r TCP gir en rdt-tjeneste basert oppå IPs upålitelige tjeneste r Pipelining av segmenter r Kumulative kvitteringer r TCP benytter bare én retransmisjonstimer r Retransmisjoner trigges av: m timeout m dupliserte kvitteringer r Ser først på en forenklet TCP-sender: m ignorér dupliserte ACK m ignorér flytkontroll og metningskontroll

65 Versjon 2.0 / Transportlaget3-65 TCP-sender hendelser: data mottatt fra appl: r Lag segment med sekvensnummer r sekvensnummer er “byte-stream”-nummer til første databyte i segmentet r start timer hvis den ikke alt går (timer er for det eldste ukvitterte segmentet  timer-tid: TimeOutInterval timeout: r retransmitter segmentet som forårsaket timeout r restart timer ACK mottatt: r Hvis den kvitterer for ukvitterte segmenter: m oppdater hva som er kvittert for m start timer hvis det finnes utestående segmenter

66 Versjon 2.0 / Transportlaget3-66 TCP sender (forenklet) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data mottatt fra applikasjonen lag TCP-segment med sekvensnummer NextSeqNum if (timer ikke går) start timer levér segment til IP NextSeqNum = NextSeqNum + lengde(data) event: timer timeout retransmittér ukvittert segment med minste sekvensnummer start timer event: ACK mottatt, med ACK-verdi y if (y > SendBase) { SendBase = y if (det er flere ukvitterte segmenter) start timer } } /* end of loop forever */ Kommentar: SendBase-1: siste kvitterte oktett Eksempel: SendBase-1 = 71; y = 73  mottager forventer da segment med sekvensnummer 73 y > SendBase: denne ACK er en kvittering for data det ikke er kvittert for tidligere

67 Versjon 2.0 / Transportlaget3-67 TCP: retransmisjon Maskin A Seq=100, 20 byte data ACK=100 tid “prematur timeout” Maskin B Seq=92, 8 byte data ACK=120 Seq=92, 8 byte data Seq=92 timeout ACK=120 Maskin A Seq=92, 8 byte data ACK=100 tap timeout lost ACK scenario Maskin B X Seq=92, 8 byte data ACK=100 tid Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

68 Versjon 2.0 / Transportlaget3-68 TCP retransmisjon (forts.) Maskin A Seq=92, 8 byte data ACK=100 tap timeout Kumulativ ACK scenario Maskin B X Seq=100, 20 byte data ACK=120 tid SendBase = 120

69 Versjon 2.0 / Transportlaget3-69 TCP generering av ACK [RFC 1122, RFC 2581] Hendelse hos mottager Ankomst av segment i rekkefølge med forventet sekvensnr. Alle data opp til forventet sekvensnr allerede ACKet Ankomst av segment i rekkefølge med forventet sekvensnr. Et annet segment har ventende ACK Mottak av segement utenom tur med segmentnr. høyere enn forventet. Gap oppdaget. Ankomst av segment som helt eller delvis fyller et gap TCP mottager aksjon Forsinket ACK. Vent inntil 500ms på neste segment. Hvis intet nytt segment, send ACK Send umiddelbart kumulativt ACK, for å kvittere for begge segmenter Send umiddelbart duplikat ACK som indikerer sekvensnummer til neste forventede oktett Send umiddelbart ACK, forutsatt at segmentet starter i “nedre ende” av gapet

70 Versjon 2.0 / Transportlaget3-70 Fast retransmit r Timeout perioden er ofte relativt lang: m stor forsinkelse før omsending av tapt segment r Man kan oppdage tapte segmenter v.hj.a. dupliserte ACK. m Sender vil ofte sende flere segmenter rett etter hverandre m Hvis segment går tapt, vil sender ofte motta dupliserte kvitteringer r Hvis sender mottar 4 kvitteringer for samme data, vil den anta at segmentet etter de kvitterte data er gått tapt: m fast retransmit: retransmittér segment umiddelbart uten å vente på timout

71 Versjon 2.0 / Transportlaget3-71 event: ACK mottatt, med ACK-felt satt til y if (y > SendBase) { SendBase = y if ( det er flere ukvitterte segmenter ) start timer } else { inkrementér antall dupliserte ACK mottatt for y if (antall dupliserte ACK mottatt for y = 3) { retransmitter segmentet som har sekvensnummer y } “Fast retransmit”-algoritme: en duplisert ACK for allerede kvittert segment fast retransmit

72 Versjon 2.0 / Transportlaget3-72 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer è flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

73 Versjon 2.0 / Transportlaget3-73 TCP flytkontroll r mottagersiden av TCP- forbindelsen har et mottagerbuffer: r hastighetstilpasning: tilpasser senderaten til den mottagende applikasjons “lesehastighet” r app prosess kan være sen med å lese fra bufferet hindrer sender i å oversvømme mottager med data flytkontroll

74 Versjon 2.0 / Transportlaget3-74 TCP flytkontroll: virkemåte  ledig plass i buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]  Mottager tilkjennegir ledig plass ved å inkludere verdien RcvWindow i hvert segment  Sender begrenser mengden ukvitterte data til verdien RcvWindow m garanterer at mottager- buffer ikke blir overfylt

75 Versjon 2.0 / Transportlaget3-75 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control è connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

76 Versjon 2.0 / Transportlaget3-76 TCP: Etablering av forbindelse Påminnelse: TCP-sender og – mottager etablerer en slags forbindelse før data utveksles r initialiserer TCP-variable: m sekvensnumre  buffere, flytkontroll- parametre (f.eks. RcvWindow ) r klient: den som tar initiativet til forbindelsen Socket clientSocket = new Socket("hostname","port number"); r server: kontaktes av klient Socket connectionSocket = welcomeSocket.accept(); Three way handshake: Trinn 1: klient sender TCP SYN- segment til server m spesifiserer initielt sekvensnummer m ingen data overføres Trinn 2: server mottar SYN, svarer med SYNACK m server allokerer buffere m spesifiserer servers initielle sekvensnummer Trinn 3: klient mottar SYNACK, svarer med ACK-segment som også kan inneholde data

77 Versjon 2.0 / Transportlaget3-77 TCP: Etablering av forbindelse (three-way handshake) Maskin A Maskin B SYN, Seq=1000 SYN, Seq=89, ACK=1001 Seq=1001, ACK=90, data Initiell kontakt (“active open”) kvitterer på aksepten, kan nå sende data Aksepterer og svarer på kontakten (“passive open”)

78 Versjon 2.0 / Transportlaget3-78 TCP: Terminering av forbindelse Terminering av forbindelse: klient lukker socket: clientSocket.close(); Trinn 1: klienten sender TCP FIN segment til tjener Trinn 2: tjener mottar FIN, svarer ned ACK. Sender sin egen FIN. klient FIN tjener ACK FIN close (active close) close (passive close) closed ventetid

79 Versjon 2.0 / Transportlaget3-79 TCP: Terminering av forbindelse (forts.) Trinn 3: klient mottar FIN, svarer med ACK. m Venter en tid (“timed wait”) - vil svare med ACK på mottatte FIN Trinn 4: tjener mottar ACK på sin FIN. Forbindelsen terminert. klient FIN tjener ACK FIN closing closed ventetid closed

80 Versjon 2.0 / Transportlaget3-80 TCP: etablering og terminering av forbindelser TCP klient livssyklus TCP tjener livssyklus

81 Versjon 2.0 / Transportlaget3-81 TCP tilstandsmaskin

82 Versjon 2.0 / Transportlaget3-82 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management è 3.6 Principles of congestion control r 3.7 TCP congestion control

83 Versjon 2.0 / Transportlaget3-83 Prinsipper for metningskontroll Metning: r uformelt: “for mange maskiner sender for mye data for hurtig til at nettet klarer å håndtere det” r ikke det samme som flytkontroll! r viser seg ved: m pakketap (ruteres buffere går fulle og pakke må kastes) m store forsinkelser (lange køer i ruteres buffere) r et viktig problem

84 Versjon 2.0 / Transportlaget3-84 Årsaker til og kostnader ved metning: scenario 1 r to sendere, to mottagere r én ruter, uendelig store buffere r ingen retransmisjon r store forsinkelser ved metning r maksimal oppnåelig gjennomstrømning ubegrenset utgansbuffer Host A in : originale data Host B out

85 Versjon 2.0 / Transportlaget3-85 Årsaker til og kostnader ved metning: scenario 2 r en ruter, begrenset bufferstørrelse r sender retransmitterer tapte pakker begrenset utgangsbuffer Host A in : originale data Host B out ' in : originale data pluss retransmitterte data

86 Versjon 2.0 / Transportlaget3-86 Årsaker til og kostnader ved metning : scenario 2 r alltid: (‘goodput’) r “perfekt” retransmisjon kun ved tap: r retransmisjon av forsinkede (ikke tapte) pakker gjør større (enn i det perfekte tilfellet) for samme in out = in out > in out “kostnader” ved metning: r mer arbeid (retransmittering) for gitt “goodput” r unødvendige retransmisjoner: link frakter flere kopier av en pakke

87 Versjon 2.0 / Transportlaget3-87 Årsaker til og kostnader ved metning: scenario 3 r fire sendere r multihopp-stier r timeout/retransmisjon in Spm: hva skjer når og øker ? in begrenset utgangsbuffer A in : originale data out ' in : originale data pluss retransmitterte data R1 R2 R3 R4 B C D

88 Versjon 2.0 / Transportlaget3-88 Årsaker til og kostnader ved metning: scenario 3 Annen kostnad ved metning: r når en pakke kastes, vil enhver oppstrøms transmisjonskapasitet som ble brukt for den pakken, være bortkastet A B out

89 Versjon 2.0 / Transportlaget3-89 Mulige måter å håndtere metning Ende til ende metningskontroll: r ingen eksplisitt tilbakemelding fra nettet r kunnskap om metning avledet fra observerte tap og forsinkelser r TCP benytter denne tilnærmingen Nettverks-assistert metningskontroll: r rutere gir tilbakemelding om metningen i nettet til endesystemene, f.eks. m ett-bits indikasjon (SNA, DECbit, TCP/IP ECN, ATM) m melding om hvilken bitrate senderen bør bruke To tilnærmingsmåter:

90 Versjon 2.0 / Transportlaget3-90 Kapittel 3 – hvor er vi? r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control è 3.7 TCP congestion control

91 Versjon 2.0 / Transportlaget3-91 TCP metningskontroll r ende til ende kontroll (ingen nettlags-assistanse) r sender begrenser transmisjon: LastByteSent-LastByteAcked  CongWin r Omtrentlig:  CongWin er en dynamisk funksjon av opplevd metning i nettet Hvordan vurderer senderen om det er metning? r segmenttap = timeout eller 3 duplikatkvitteringer  TCP-sender reduserer raten ( CongWin ) etter segmenttap tre mekanismer: m AIMD m slow start m reaksjon på timeout rate = CongWin RTT byte/s

92 Versjon 2.0 / Transportlaget3-92 TCP AIMD multiplikativ reduksjon (MD): halvér CongWin etter segmenttap (minimum én MSS) additiv økning (AI): CongWin økes med én MSS for hver RTT under fravær av segmenttap (congestion avoidance fase) Langlivet TCP-forbindelse

93 Versjon 2.0 / Transportlaget3-93 TCP Slow-start  Når forbindelsen opprettes, CongWin = 1 MSS m Eksempel: MSS = 500 oktetter og RTT = 200 ms m initiell rate = 20 kb/s r tilgjengelig datarate kan være >> MSS/RTT m ønskelig å øke rate kjapt opp til en rimelig rate r Når forbindelsen opprettes, øk raten eksponentielt inntil første segmenttap

94 Versjon 2.0 / Transportlaget3-94 TCP Slow-start r Ved starten på forbindelse økes raten eksponetielt inntil man opplever segmenttap:  dobler CongWin hver RTT  gjøres ved å øke CongWin for hver mottatt ACK r Oppsummert: initiell rate er lav, men øker eksponentielt Host A ett segment RTT Host B tid to segmenter fire segmenter

95 Versjon 2.0 / Transportlaget3-95 Reaksjon på segmenttap r Etter tre dupliserte kvitteringer:  CongWin halveres m vinduet vokser deretter lineært r Men etter en timeout:  CongWin settes til én MSS m vinduet vokser så eksponentielt opp til halvparten av verdien før timeout, og vokser deretter lineært 3 dupliserte ACK indikerer at nettet kan levere en del segmenter timeout før 3 dupliserte ACK er mer alarmerende Filosofi:

96 Versjon 2.0 / Transportlaget3-96 Reaksjon på segmenttap (forts) Q: Når skal eksponentiell økning endres til lineær? A: Når CongWin blir halvparten av dens verdi før timeout. Implementasjon: r Variabel terskel r Ved segmenttap settes terskelen til halvparten av det CongWin var før segmenttapet mottak av tre duplikatkvitteringer

97 Versjon 2.0 / Transportlaget3-97 Oppsummering: TCP metningskontroll  Når CongWin er lavere enn Threshold er senderen i slow-start fasen; vindu øker eksponentielt.  Når CongWin er større enn Threshold er senderen i congestion-avoidance fasen; vindu øker lineært.  Når sender mottar en trippel duplisert ACK, settes Threshold til CongWin/2 og CongWin settes til Threshold.  Når sender får timeout, settes Threshold til CongWin/2 og CongWin til én MSS.

98 Versjon 2.0 / Transportlaget3-98 TCP sender metningskontroll HendelseTilstandTCP-sender aksjonKommentar ACK mottatt for ukvitterte data Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) bytt tilstand til “Congestion Avoidance” Resulterer i en dobling av CongWin hver RTT ACK mottatt for ukvitterte data Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulterer i en økning av CongWin med 1 MSS hver RTT Tap opp- daget ved mottak av tre dupliserte ACK SS eller CAThreshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, multiplicative decrease. CongWin vil aldri reduseres til mindre enn 1 MSS TimeoutSS eller CAThreshold = CongWin/2, CongWin = 1 MSS, Bytt tilstand til “slow start” Går i slow start Duplisert ACK SS eller CAØke teller for antall dupliserte ACK Ingen endring i CongWin eller Threshold

99 Versjon 2.0 / Transportlaget3-99 TCP effektiv bitrate (throughput) r Effektiv bitrate for TCP som funksjon av vindus- størrelse og RTT? m Ignorer slow start r La W være vindusstørrelsen når segment-tap intreffer r Når vinduet er W, vil effektiv bitrate være W/RTT r Rett etter segmenttap, vil vinduet være redusert til W/2 og effektiv bitrate til W/2RTT. r Gjennomsnittlig effektiv bitrate: 3W/4RTT

100 Versjon 2.0 / Transportlaget3-100 TCP: framtid r Eksempel: 1500 byte segmenter, 100 ms RTT, ønsker 10 Gb/s effektiv bitrate r Krever vindusstørrelse på W = in-flight segments r Effektiv bitrate kan uttrykkes (L er tapsrate): r Ønskes 10 Gb/s, gir dette L = 2· Wow r Nye versjoner av TCP trengs for høye hastigheter!

101 Versjon 2.0 / Transportlaget3-101 Mål: dersom K TCP-sesjoner deler samme flaskehals-link med datarate R, skal hver av dem ha en gjennomsnittlig datarate på R/K TCP forbindelse 1 flaskehals- ruter, kapasitet R TCP forbindelse 2 TCP rettferdighet (fairness)

102 Versjon 2.0 / Transportlaget3-102 Hvorfor er TCP rettferdig? To konkurrerende sesjoner: r Additiv økning gir helning på 1, som øker etterhvert r multiplikativ reduksjon reduserer gjennomstrømning proporsjonalt R R likelig fordelt datarate Forbindelse 1 gjennomstrøming Forbindelse 2 gjennomstrømning congestion avoidance: additiv økning tap: reduserer vindu med faktor 2 congestion avoidance: additiv økning tap: reduserer vindu med faktor 2

103 Versjon 2.0 / Transportlaget3-103 Rettferdighet (forts) Rettferdighet og UDP r Multimedia appl benytter sjelden TCP m ønsker ikke datarate begrenset pga metningskontroll r Benytter isteden UDP: m pumper audio/video på konstant rate, tolererer pakketap r Forskningsområde: TCP-vennlig oppførsel Rettferdighet og parallelle TCP-forbindelser r ingenting forhindrer appl å åpne parallelle forbindelser mellom to maskiner. r Nettlesere gjør dette r Eksempel: link med rate R med 9 forbindelser: m ny appl ber om én TCP- forbindelse, får rate R/10 m ny appl ber om 11 TCP- forbindelser, får rate R/2 !

104 Versjon 2.0 / Transportlaget3-104 Kapittel 3: Oppsummering r prinsipper bak transport- lagstjenester: m multipleksing, demultipleksing m pålitelig dataoverføring m flytkontroll m metningskontroll r implementasjoner i Internett m UDP m TCP Neste: r forlater kanten av nettet (applikasjons- og transportlag) r inn i kjernen


Laste ned ppt "Versjon 2.0 / 24.09.2004 Transportlaget3-1 Kapittel 3 Transport Layer Slides adapted from the slides accompanying the book of Kurose & Ross. © 1996-2004."

Liknende presentasjoner


Annonser fra Google