Chapter 3 Transport ayer A note on the use of these ppt slides: We re making these slides freely available to all (faculty, students, readers). They re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. Tavoitteet: Ymmärtää kuljetuskerroksen palveluiden taustalla: multiplexing/ demultiplexing uotettava tiedonsiirto vuonvalvonta ruuhkanhallinta Oppia Internetin kuljetuskerroksen protokollista: : yhteydetön kuljetus : yhteydellinen kuljetus :n ruuhkanhallinta All material copyright 1996-2004 J.F Kurose and K.W. Ross, All Rights Reserved 1 2 Kuljetus ja -protokollat uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 3 Tarjotaan looginen kommunikaatioyhteys eri laitteissa toimivien sovellusprosessien välille Kuljetusprotokollat toimivat päätelaitteissa ähettäjä: pilkkoo sovelluksen viestit segmenteiksi, ja välittää verkkokerrokselle Vastaanottaja: uudelleen kokoaa segmentit viesteiksi ja välittää sovelluskerrokselle Yleisesti useita vaihtoehtoja kuljetusprotokollaksi Internet: ja transport transport 4 vs. verkkokerros Internetin kuljetuskerroksen protokollat verkkokerros: looginen kommunikaatioyhteys päätelaitteiden välille kuljetuskerros: looginen kommunikaatioyhteys prosessien välille Käyttää verkkokerroksen palveluita ja parantaa niitä Analogia kotoa: apset lähettävät kirjeitä serkuilleen prosessit = lapset sovelluksen viestit = kirjeet kuorissa päätelaitteet = postilaatikot kuljetuskerros = isä ja äiti verkkokerros = posti oy uotettava, järjestyksen säilyttävä kuljetus () Ruuhkanhallinta Yhteyden alustus Epäluotettava, järjestyksestä piittaamaton kuljetus: best-effort, IP:n suora laajennos Palvelut joita ei tarjota: Takeita viiveelle Takeita kaistanleveydelle transport transport 5 6 1
uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 7 User OS hardware Multiplexing/demultiplexing Multiplexing lähettäjällä: Kerätään dataa useilta soketeilta, kapseloidaan data otsikoilla (joita myöhemmin käytetään demultipleksointiin) transport link P3 = soketti P1 P1 transport link host 1 host 2 Demultiplexing vastaanottajalla: Toimitetaan vastaanotetut segmentit oikealle soketeille = prosessi P2 P4 transport host 3 link 8 Kuinka demultipleksointi toteutetaan Päätelaite vastaanottaa IP datagrammeja Jokaisessa datagrammissa on lähteen IP osoite sekä kohteen IP osoite Kukin datagrammi kuljettaa yhden kuljetuskerroksen segmentin Jokaisessa segmentissä on lähteen ja kohteen porttinumero Päätelaite käyttää IP osoitetta sekä porttinumeroa segmentin ohjaamiseksi oikealle soketille 32 bittiä source port # dest port # Muita otsikkokenttiä Sovelluksen data (viesti) / segmentin muoto Yhteydetön demultipleksointi uodaan soketteja joilla porttinumerot: DatagramSocket mysocket1 = new DatagramSocket(99111); DatagramSocket mysocket2 = new DatagramSocket(99222); soketti tunnistetaan kahdella tunnisteella: (kohteen IP osoite, kohteen porttinumero) Kun päätelaite vastaanottaa segmentin: Tarkistaa segmentistä kohdeporttinumeron ohjaa segmentin porttinumeron osoittamaan sokettiin IP datagrammit joilla eri lähde IP osoitteet ja/tai lähdeporttinumerot ohjataan samaan sokettiin 9 10 Yhteydetön demultipleksointi IPEndPoint ipep = new IPEndPoint(IPAddress.Any, 6428); Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); s.bind(ipep); Yhteydellinen demultipleksointi DatagramSocket serversocket = new DatagramSocket(6428); P2 client IP: A SP: 9157 DP: 6428 SP: 6428 DP: 9157 P3 server IP: C SP: 6428 DP: 5775 SP = lähdeportti, tarjoaa palautusosoitteen DP = Kohdeportti SP: 5775 DP: 6428 P1 P1 Client IP:B 11 soketti tunnistetaan neljällä numerolla: lähteen IP osoite lähteen porttinumero kohteen IP osoite kohteen porttinumero Vastaanottava päätelaite käyttää kaikkia neljää arvoa segmentin ohjaamiseksi oikealle soketille Palvelin voi tukea monia samanaikaisia soketteja: Jokainen soketti tunnistetaan em. neljän numeron avulla WWW palvelimilla on eri soketit jokaiselle yhteyden ottavalle asiakkaalle non-persistent HTTP käyttää eri sokettia jokaiselle request - pyynnölle 12 2
Yhteydellinen demultipleksointi Yhteydellinen demultipleksointi: säikeistetty WWW palvelin P1 P4 P5 P6 P2 P1 P3 P1 P4 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 5775 DP: 80 S-IP: B D-IP:C client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B 13 14 : User Datagram Protocol [RFC 768] uotettavan uotettava tiedonsiirto :n ruuhkanhallinta Yksinkertainen Internetin kuljetusprotokolla best effort palvelu, segmentit voivat: Katoda Saapua väärässä järjestyksessä sovellukselle yhteydetön: Ei kättelyä lähettäjän ja vastaanottajan välillä Jokainen segmentti käsitellään riippumattomasti Miksi on olemassa? Ei yhteydenmuodostusta (joka lisää viivettä) Yksinkertainen: ei säilytetä yhteyden tilaa lähettäjällä ja vastaanottajalla Pieni otsikko segmentissä Ei ruuhkanhallintaa: voi lähettää niin nopeasti kuin halutaan 15 16 : lisää Käytetään usein suoratoisto (streaming) multimedia sovelluksissa Sietävät hävikkiä Herkkiä nopeuden suhteen muita sovelluksia DNS SNMP (Simple Network Management Protocol) uotettava tiedonsiirto ja : isätään luotettavuutta sovelluskerroksella Sovelluskohtainen virheistä toipuminen segmentin pituus tavuina, sisältäen otsikon 32 bittiä source port # dest port # length Application data (message) checksum segmentin muoto 17 checksum - tarkistussumma Tavoite: havaita virheitä (eli vaihtuneita bittejä) lähetetyssä segmentissä ähettäjä: Käsitellään segmentin sisältöä sarjana 16 bittisiä lukuja checksum: summataan segmentin sisällöt (16 bittiset numerot) ja otetaan yhden komplementti (muutetaan bitit vastakkaisiksi) ähettäjä laittaa tarkistussumman arvon :n checksum kenttään Vastaanottaja: asketaan vastaanotetun segmentin tarkistussumma Verrataan vastaako laskettu tarkistusumma checksum kentän arvoa: Ei virhe havaittu Joo ei havaittu virhettä. Ehkäpä sittenkin virheitä? isää myöhemmin. 18 3
Muistibitit Esimerkki tarkistussummasta Huom Kun suoritetaan yhteenlaskua, eniten merkitsevän bitin muistibitti täytyy summata vastaukseen Esimerkki: summataan kaksi 16 bittistä lukua 1 1 1 1 1 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 + 0 = 0 1 + 0 = 1 0 + 1 = 1 1 + 1 = 10 1 + 1 + 1 = 11 Desimaaleina 58982 54613 kierrätys 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 113595 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 48059 summa 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 48060 Tarkistus- 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 17475 summa 19 uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 20 uotettavan Tärkeää sovellus-, kuljetus- ja linkkikerroksilla top-10 listalla tärkeiden verkkotekniikoiden aiheissa! uotettava tiedonsiirto: alkuun pääsemiseksi rdt_send(): kutsu yläpuolelta, (esim. sovellus). Siirtää dataa kuljetettavaksi vastaanottajan ylemmälle kerrokselle deliver_data(): rdt kutsuu toimittaakseen datan ylemmälle kerrokselle send side receive side Epäluotettavan kanavan ominaisuudet määrittävät luotettavan tiedonsiirtoprotokollan (reliable data transfer protocol (rdt)) kompleksisuuden 21 udt_send(): rdt kutsuu, siirtääkseen paketin epäluotettavan kanavan yli vastaanottajalle rdt_rcv(): kutsu alapuolelta kun paketti saapuu kanavan läpi vastaanottajalle 22 uotettava tiedonsiirto: alkuun pääsemiseksi Seuraavaksi: Vähitellen kehitellään lähettäjä ja vastaanottaja luotettavalle tiedonsiirtoprotokollalle (rdt) Tarkastellaan vain yksisuuntaista tiedonsiirtoa Kontrolli-informaatio kulkee molempiin suuntiin Käytetään äärellisiä tilakoneita (Finite State Machine - FSM) lähettäjän ja vastaanottajan määrittelemiseksi event causing state transition actions taken on state transition Tila (state): kun järjestelmä on ko. tilassa, seuraavan tilan määrää yksikäsitteisesti seuraava tapahtuma (event) state 1 event actions state 2 23 Rdt1.0: luotettava tiedonsiirto luotettavassa kanavassa Alapuolinen kanava on täysin luotettava Ei bittivirheitä Ei pakettien katoamista Erilliset tilakoneet lähettäjälle ja vastaanottajalle: ähettäjä lähettää dataa alapuolella olevaan kanavaan Vastaanottaja lukee dataa alapuolella olevasta kanavasta call from packet = make_pkt(data) udt_send(packet) sender call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) receiver 24 4
Rdt2.0: kanava jossa bittivirheitä Alapuolella oleva kanava voi muuttaa paketin bittejä Tarkistussummalla havaitaan bittivirheet Kysymys: kuinka selvitään virheistä: Kuittaukset (acknowledgements - ACKs): vastaanottaja explisiittisesti kertoo lähettäjälle että vastaanotettu paketti oli OK Negatiiviset kuittaukset (NAKs): vastaanottaja explisiittisesti kertoo lähettäjälle että paketissa oli virheitä ähettäjä uudelleenlähettää paketin vastaanotettuaan NAK - viestin Uudet mekanismit protokollassa rdt2.0: Virheiden havaitseminen Vastaanottajan palaute: kontrolliviestit (ACK,NAK) rdt2.0: tilakoneen määritelmä snkpkt = make_pkt(data, checksum) call from ACK or NAK isack(rcvpkt) sender isnak(rcvpkt) receiver corrupt(rcvpkt) udt_send(nak) call from below notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 25 26 rdt2.0: toiminta ilman virheitä snkpkt = make_pkt(data, checksum) call from ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) rdt2.0: toiminta virheen sattuessa snkpkt = make_pkt(data, checksum) call from ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) isack(rcvpkt) call from below isack(rcvpkt) call from below notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 27 28 rdt2.0 -> kohtalokas vika! Mitä tapahtuu jos ACK tai NAK on korruptoitunut? ähettäjä ei tiedä mitä vastaanottajalla tapahtui! Ei voida yksinkertaisesti uudelleenlähettää: mahdollinen duplikaatti Duplikaattien käsittely: ähettäjä lisää sekvenssinumeron jokaiseen pakettiin ähettäjä lähettää uudelleen paketin jos sen kuittaus (ACK/NAK) on epäselvä Vastaanottaja tuhoaa duplikaatin (ei välitä sitä ylemmälle kerrokselle) stop and wait ähetetään yksi paketti ja odotetaan kuittauksen saapumista ennen seuraavan paketin lähetystä 29 rdt2.1: lähettäjä selviää epämääräisistä kuittauksista && notcorrupt(rcvpkt) && isack(rcvpkt) ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from ACK or NAK 1 ACK or NAK 0 call 1 from ( corrupt(rcvpkt) isnak(rcvpkt) ) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) 30 5
rdt2.1: vastaanottaja selviää epämääräisistä kuittauksista (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) 0 from below 1 from below notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) 31 rdt2.1: discussion ähettäjä: Pakettiin lisätään sekvenssinumero Kaksi numeroa (0,1) riittää. Miksi? Täytyy tarkistaa onko vastaanotettu kuittaus (ACK/NAK) virheellinen Kaksinkertainen määrä tiloja Tilan pitää muistaa mikä on nykyisen paketin sekvenssinumero Vastaanottaja: Täytyy tarkistaa onko vastaanotettu paketti duplikaatti Tila ilmaisee tulisiko seuraavan sekvenssinumeron olla 0 vai 1 Huom: vastaanottaja ei voi tietää oliko sen lähettämä ACK/NAK viesti OK lähettäjän päässä 32 rdt2.2: protokolla ilman NAK -viestiä rdt2.2: sender, receiver fragments Muutoin sama toiminnallisuus kuin rdt2.1, mutta käytetään vain ACK -viestejä Vastaanottaja lähettää ACK viestin viimeisestä oikein vastaanottamastaan paketista. Vastaanottajan täytyy explisiittisesti lisätä kuitattavan paketin sekvenssinumero ACK -viestiin Duplikaatti ACK lähettäjällä johtaa samaan toimenpiteeseen kuin NAK: uudelleenlähetetään nykyinen paketti johon odotetaan kuittausta 33 (corrupt(rcvpkt) has_seq1(rcvpkt)) sndpkt = make_pkt(0, data, checksum) call 0 from 0 from below ACK 0 sender FSM fragment receiver FSM fragment notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) && notcorrupt(rcvpkt) && isack(rcvpkt,0) 34 rdt3.0: kanavat joissa on virheitä ja viestit voivat kadota Uusi oletus: Alapuolella oleva kanava voi myös kadottaa paketteja (data tai ACK - viestejä) tarkistussumma, sekvenssinumero, ACK viestit sekä uudelleenlähetykset auttavat, mutta eivät ole tarpeeksi ähestymistapa: lähettäjä odottaa järkevän ajan ACK - viestiä Uudelleenlähetys, jos ei vastaanoteta ACK viestiä tänä aikana Jos paketti (tai ACK) on vain myöhässä (ei kadonnut): Uudelleenlähetys tulee olemaan duplikaatti, mutta sekvenssinumerolla selvitään tästä Vastaanottajan tulee määrittää kuitattavan paketin sekvenssinumero Vaatii ajastimen rdt3.0 lähettäjä call 0from && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout start_timer ( corrupt(rcvpkt) isack(rcvpkt,0) ) sndpkt = make_pkt(0, data, checksum) start_timer Wait for ACK1 Wait for ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) start_timer ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout start_timer && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer 35 36 6
rdt3.0 toiminnassa rdt3.0 toiminnassa 37 38 rdt3.0 protokollan suorituskyky rdt3.0: stop-and-wait operation rdt3.0 toimii, mutta suorituskyky on surkea Esimerkki: 1 Gbps linkki, 15 ms päästä-päähän etenemisviive, 1 Kilotavun (8192 bitin) paketti: Ensimmäinen bitti lähetetään, t = 0 Viimeinen bitti lähetetään, t = / R sender receiver T transmit = (packet length in bits) R (transmission rate, bps) = U sender = / R RTT + / R =.008 30.008 8kb/pkt 10 9 b/sec = 0.00027 microsec onds = 8 microsec U sender : käyttöaste kuinka suuren osan ajasta lähettäjä lähettää 1KB paketti kerran 30 ms -> 33KB/s tiedonsiirtonopeus 1 Gbps linkillä Verkon protokolla rajoittaa fyysisten resurssien käyttöä! 39 RTT ACK saapuu, lähetetään seuraava paketti, t = RTT + / R U sender = / R RTT + / R =.008 30.008 Ensimmäinen bitti saapuu Viimeinen bitti saapuu, lähetetään ACK = 0.00027 microsec onds 40 Putkitettuja protokollia Putkitus (Pipelining): lähettäjä hyväksyy useita matkalla olevia, vielä kuittaamattomia paketteja Sekvenssinumeroiden määrää täytyy lisätä Tarvitaan puskurointia lähettäjällä ja/tai vastaanottajalla Pipelining: käyttöaste kasvaa Ensimmäinen bitti läh., t = 0 Viimeinen bitti läh., t = / R RTT ACK saapuu, lähetetään Neljäs paketti, t = RTT + / R Toinen ACK -> viides paketti Kolmas ACK -> kuudes paketti sender receiver Ensimmäinen bitti saapuu Viimeinen bitti saapuu, lähetetään ACK Toisen paketin viimeinen bitti, ACK Kolmannen paketin viimeinen bitti, ACK Käyttöaste kasvaa kolminkertaiseksi! Kaksi yleistä menetelmää putkitetuille protokollille: go-back-n ja selective repeat 41 U sender = 3 * / R RTT + / R =.024 30.008 = 0.0008 microsecon ds 42 7
isätehtävä: Opetta opettajalle go-back-n ja selective repeat menetelmien toiminta ja erot käyttäen apuna seuraavia esimerkkitapauksia Yksi datapaketti hukkuu Kaksi peräkkäistä datapakettia hukkuu Kaksi ei-peräkkäistä datapakettia hukkuu Yksi kuittauspaketti hukkuu Kaksi peräkkäistä kuittauspakettia hukkuu Kaksi ei-peräkkäistä kuittauspakettia hukkuu 0-1 pistettä Vastaukset sähköpostilla 43 Go-Back-N ähettäjä: k-bittinen sekvenssinumero paketin otsikossa ikkuna, jonka koko on N, eli hyväksytään N peräkkäistä ei-kuitattua pakettia ACK(n): kuittaa kaikki paketit sekvenssinumeroon n asti, sisältäen paketin n - kumulatiivinen ACK Voi vastaanottaa duplikaatti ACK -viestejä (ks. vastaanottaja) Yksi, sama ajastin kaikille matkalla oleville paketeille timeout(n): uudelleenlähetetään paketti n sekä ikkunan kaikki suuremman sekvenssinumeron paketit 44 GBN: lähettäjä, laajennettu FSM base=1 nextseqnum=1 && corrupt(rcvpkt) 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) Wait notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) 45 GBN: vastaanotin, laajennettu FSM default expectedseqnum=1 Wait sndpkt = make_pkt(expectedseqnum,ack,chksum) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ack,chksum) expectedseqnum++ Vain ACK -viesti: lähetetään aina ACK -viesti oikein vastaanotetusta paketista kuitaten suurimman oikeassa järjestyksessä vastaanotetun sekvenssinumeron Saattaa generoida duplikaatti ACK -viestejä Tarvitsee ainoastaan muistaa expectedseqnum Paketti joka ei tule oikeassa järjestyksessä: hylätään (ei puskuroida muistiin) -> ei puskurointia vastaanottajalla! Kuitataan uudestaan viimeisimmän oikeassa järjestyksessä tulleen paketin sekvenssinumerolla 46 GBN toiminnassa Ikkunan koko 4 pakettia Selective Repeat valikoiva toisto vastaanottaja yksittäin kuittaa kaikki oikein vastaanotetut paketit Puskuroidaan paketteja tarpeen mukaan, jotta voidaan välittää paketit järjestyksessä ylemmälle kerrokselle sitten kun kaikki välistä puuttuvat paketit on vastaanotettu ähettäjä uudelleenlähettää vain paketit joista se ei ole vastaanottanut kuittausta ähettäjällä ajastin jokaista kuittaamatonta pakettia varten ähettäjän ikkuna N peräkkäistä sekvenssinumeroa Rajoittaa lähetettyjen, ei-kuitattujen pakettien sekvenssinumeroita 47 48 8
Selective repeat: lähettäjän ja vastaanottajan ikkunat 49 Selective repeat sender Dataa yläpuolelta : Jos seuraava vapaa sekvenssinumero ikkunassa N -> lähetetään paketti timeout(n): Uudelleenlähetä paketti n, uudelleenkäynnistä ajastin ACK(n) välillä [sendbase,sendbase+n]: Merkataan paketti n vastaanotetuksi Jos n oli pienimmän sekvenssinumeron omaava eikuitattu paketti -> siirretään ikkunan alaraja (base) seuraavaan ei-kuitattuun sekvenssinumeroon receiver paketti n välillä [rcvbase, rcvbase+n-1] ähetetään ACK(n) out-of-order: puskuroidaan in-order: välitetään (myös puskuroidut in-order paketit), siirretään ikkuna seuraavaan ei vielä vastaanotettuun pakettiin paketti n välillä [rcvbase-n,rcvbase-1] ACK(n) muuten: Ei tehdä mitään 50 Selective repeat toiminnassa Selective repeat: dilemma Esimerkki: Sekvenssinumerot: 0, 1, 2, 3 Ikkunan koko = 3 Vastaanottaja ei näe eroa skenaarioiden välillä! Välittää duplikaatti datan uutena datana kohdassa (a) 51 Q: Mikä tulisi olla suhde sekvenssinumeroiden lukumäärän ja ikkunan koon välillä? 52 uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 53 socket door : yleiskuva RFC: 793, 1122, 1323, 2018, 2581 Pisteestä-pisteeseen: Yksi lähettäjä, yksi vastaanottaja luotettava, järjestyksen säilyttävä tavuvirta: Ei viestirajoja putkitettu: ruuhkanhallinta ja vuonvalvonta määrittelevät ikkunan koon ähetys- ja vastaanottopuskurit writes data send buffer segment reads data receive buffer full duplex data: Kaksisuuntainen tiedonsiirto samassa yhteydessä MSS: maximum segment size yhteydellinen: kättely (kontrolliviestien vaihtoa) alustaa lähettäjän ja vastaanottajan tilat ennen tiedonsiirtoa : ähettäjä ei tukahduta vastaanottajaa socket door 54 9
RTT (milliseconds) segmentin rakenne URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in ) 32 bits source port # dest port # sequence number acknowledgement number head not U A P R S Receive window len used F checksum Urg data pnter Options (variable length) data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept 55 sekvenssinumerot ja Ack -viestit Sekvenssinumerot: Virta tavuja; segmentin datakentässä olevan ensimmäisen tavun numero ACK -viestit: Oletus seuraavan tavun sekvenssinumerosta kumulatiivinen ACK Q: kuinka vastaanottaja selviää väärässä järjestyksessä saapuvista segmenteistä A: spesifikaatiot eivät määrittele implementoijan päätettävissä User types C host ACKs receipt of echoed C Host A Host B simple telnet scenario host ACKs receipt of C, echoes back C time 56 Round Trip Time ja Timeout Round Trip Time ja Timeout Q: Kuinka määritellään :n timeout arvo? Suurempi kuin RTT mutta RTT vaihtelee iian pieni: ennenaikainen timeout Turhia uudelleenlähetyksiä iian suuri: hidas reagointi segmenttien katoamiseen Q: kuinka arvioidaan RTT:tä? SampleRTT: mitataan aika segmentin lähetyksestä ACK viestin vastaanottoon Uudelleenlähetyksiä ei huomioida SampleRTT vaihtelee, halutaan RTT:n estimaatista pehmeämpi Otetaan keskiarvo useasta edellisestä mittauksesta EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponentiaalinen painotettu liikkuva keskiarvo Edellisten näytteiden vaikutus pienenee exponentiaalisen nopeasti tyypillinen arvo: = 0.125 57 58 Esimerkki RTT:n estimointi: Round Trip Time ja Timeout 350 300 250 200 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr Timeout arvon asettaminen EstimatedRTT plus turvaväli Suuri vaihtelu EstimatedRTT arvossa -> suuri turvaväli Ensimmäinen estimaatti siitä kuinka paljon SampleRTT eroaa EstimatedRTT arvosta: DevRTT = (1- )*DevRTT + * SampleRTT-EstimatedRTT 150 (tyypillisesti, = 0.25) Sitten asetetaan timeout -arvo: 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) TimeoutInterval = EstimatedRTT + 4*DevRTT SampleRTT Estimated RTT 59 60 10
Seq=92 timeout timeout Seq=92 timeout timeout :n luotettava tiedonsiirto uotettavan uotettava tiedonsiirto :n ruuhkanhallinta luo luotettavan tiedonsiirtopalvelun IP:n epäluotettavan palvelun päälle Putkitetut segmentit Kumulatiiviset kuittaukset käyttää yhtä uudelleenlähetysajastinta Uudelleenlähetykset johtuvat: Ajastimen laukeamisesta Duplikaattikuittauksista Tarkastellaan aluksi yksinkertaistettua lähettäjää: Jätetään huomiotta duplikaattikuittaukset Jätetään huomiotta vuonvalvonta sekä ruuhkanhallinta 61 62 lähettäjän tapahtumia: Dataa sovellukselta: uodaan segmentti ja sekvenssinumero Sekvenssinumero on segmentissä olevan tavuvirran ensimmäisen datatavun numero Käynnistetään ajastin jos se ei ole jo päällä (ajastin on päällä vanhimmalle eikuitatulle segmentille) expiration interval: TimeOutInterval timeout: Uudelleenlähetetään segmentti, joka aiheutti ajastimen laukeamisen Käynnistetään ajastin uudelleen Ack viestin vastaanotto: Jos kuittaa ennestään kuittaamattomia segmenttejä Päivitetään tieto mitkä segmentit on kuitattu Käynnistetään ajastin jos on vielä kuittaamattomia segmenttejä 63 NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from create segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ lähettäjä (simplified) Kommentti: SendBase-1: viimeisin kumulatiivisesti kuitattu tavu Esimerkki: SendBase-1 = 71; y= 73, eli vastaanottaja haluaa 73+ ; y > SendBase, joten ko. uusi data kuitataan 64 : skenaaroita uudelleenlähetyksestä : skenaaroita uudelleenlähetyksestä Host A Host B Host A Host B Host A Host B X loss X loss Sendbase = 100 SendBase = 120 SendBase = 120 SendBase = 100 time lost ACK scenario SendBase = 120 time premature timeout 65 time Cumulative ACK scenario 66 11
timeout ACK generointi [RFC 1122, RFC 2581] Fast Retransmit - metodi Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap 67 Timeout -aika monesti suhteellisen pitkä: Pitkä viive ennenkuin kadonnut paketti lähetetään uudelleen Havaitaan hävinneet segmentit duplikaatti ACK viestien avulla. ähettäjä usein lähettää monta segmenttiä peräkkäin Jos segmentti katoaa, tulee todennäköisesti monia duplikaattikuittauksia. Jos lähettäjä vastaanottaa 3 duplikaatti ACK viestiä samalle datalle, oletetaan että kuitattavan datan jälkeinen segmentti on kadonnut: fast retransmit: uudelleenlähetetään segmentti ennen kuin ajastin laukeaa 68 Fast retransmit algoritmi: : 3 duplikaatti ACK viestiä Host A Host B event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } 3 Duplicate ACKs X loss a duplicate ACK for already ACKed segment fast retransmit 69 time 70 uotettavan uotettava tiedonsiirto :n ruuhkanhallinta Flow Control - vuonvalvonta yhteyden vastaanottajalla on vastaanottopuskuri: Sovellusprosessi voi olla hidas lukemaan dataa puskurista vuonvalvonta ähettäjä ei tukahduta vastaanottajan puskuria lähettämällä liian paljon, liian nopeasti Nopeudensovitus - palvelu: sovitetaan lähetysnopeus vastaanottavan sovelluksen mukaan 71 72 12
vuonvalvonta: näin se toimii (Oletetaan vastaanottajan hylkäävän epäjärjestyksessä saapuvat segmentit) Vapaata tilaa puskurissa = RcvWindow = RcvBuffer-[astByteRcvd - astbyteread] Vastaanotin mainostaa vapaata tilaa asettamalla RcvWindow arvon segmentteihin ähettäjä rajoittaa eikuitattujen segmenttien määrän RcvWindow - arvoon Takaa sen ettei vastaanottajan puskuri vuoda yli uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 73 74 yhteydenhallinta Muistiksi: lähettäjä ja vastaanottaja muodostavat yhteyden enenkuin datasegmenttejä voidaan lähettää Alustetaan muuttujia: sekvenssinumerot puskurit, vuonvalvonta info (RcvWindow) asiakas: yhteyden alkuunpanija Socket clientsocket = new Socket("hostname","port number"); palvelin: yhteydenotto asiakkaalta Socket connectionsocket = welcomesocket.accept(); Kolmitiekättely: Step 1: asiakas lähettää SYN segmentin palvelimelle Määritellään ensimmäinen sekvenssinumero Ei dataa Step 2: palvelin vastaanottaa SYN -viestin, ja vastaa SYNACK segmentillä Palvelin allokoi puskurit Määrittää oman ensimmäisen sekvenssinumeron Step 3: asiakas vastaanottaa SYNACK -viestin, vastaa ACK segmentillä, jossa voi olla dataa mukana 75 yhteydenhallinta - SYN Transmission Control Protocol, Src Port: 1093 (1093), Dst Port: http (80), Seq: 2064440666, en: 0 Source port: 1093 (1093) Destination port: http (80) Sequence number: 2064440666 Header length: 24 bytes Flags: 0x02 (SYN) 0...... = Congestion Window Reduced (CWR): Not set.0..... = ECN-Echo: Not set..0.... = Urgent: Not set...0... = Acknowledgment: Not set... 0... = Push: Not set....0.. = Reset: Not set.....1. = Syn: Set......0 = Fin: Not set Window size: 65535 Checksum: 0x81cd [validation disabled] Options: (4 bytes) Maximum segment size: 1460 bytes 76 yhteydenhallinta SYN ACK yhteydenhallinta - ACK Transmission Control Protocol, Src Port: http (80), Dst Port: 1093 (1093), Seq: 508083459, Ack: 2064440667, en: 0 Source port: http (80) Destination port: 1093 (1093) Sequence number: 508083459 Acknowledgement number: 2064440667 Header length: 24 bytes Flags: 0x12 (SYN, ACK) 0...... = Congestion Window Reduced (CWR): Not set.0..... = ECN-Echo: Not set..0.... = Urgent: Not set...1... = Acknowledgment: Set... 0... = Push: Not set....0.. = Reset: Not set.....1. = Syn: Set......0 = Fin: Not set Window size: 5840 Checksum: 0x8fa0 [validation disabled] Options: (4 bytes) Maximum segment size: 1460 bytes [SEQ/ACK analysis] Transmission Control Protocol, Src Port: 1093 (1093), Dst Port: http (80), Seq: 2064440667, Ack: 508083460, en: 0 Source port: 1093 (1093) Destination port: http (80) Sequence number: 2064440667 Acknowledgement number: 508083460 Header length: 20 bytes Flags: 0x10 (ACK) 0...... = Congestion Window Reduced (CWR): Not set.0..... = ECN-Echo: Not set..0.... = Urgent: Not set...1... = Acknowledgment: Set... 0... = Push: Not set....0.. = Reset: Not set.....0. = Syn: Not set......0 = Fin: Not set Window size: 65535 Checksum: 0xbe2d [validation disabled] [SEQ/ACK analysis] 77 78 13
timed wait timed wait yhteydenhallinta (jatkuu) yhteydenhallinta (jatkuu) Yhteyden sulkeminen: Asiakas sulkee soketin: clientsocket.close(); Step 1: asiakas laite lähettää FIN kontrollisegmentin palvelimelle Step 2: palvelin vastaanottaa FIN -viestin, ja vastaa ACK -viestillä. Sulkee yhteyden ja lähettää FIN -viestin. close closed client server close Step 3: asiakas vastaanottaa FIN -viestin, ja kuittaa ACK -viestillä. Menee timed wait tilaan. Kuittaa ACK viestillä mahdolliset FIN -viestit Step 4: palvelin, vastaanottaa ACK -viestin. Yhteys suljettu. Huom: pienellä muutoksella voi käsitellä samanaikaiset FIN viestit. closing closed client server closing closed 79 80 yhteydenhallinta (jatkuu) asiakkaan elämänkaari palvelimen elämänkaari uotettavan uotettava tiedonsiirto :n ruuhkanhallinta 81 82 Ruuhkanhallinan Ruuhka: epävirallisesti: liian monta lähdettä lähettää liian paljon dataa liian nopeasti jotta verkko voisi käsitellä kaiken Eri asia kuin vuonvalvonta! Ilmenemismuodot: Kadonneet paketit (puskurin ylivuoto reitittimillä) Pitkät viiveet (jonotus reitittimien puskureissa) top-10 ongelma! ähestymistapoja ruuhkanhallintaan Kaksi laajaa lähestymistapaa ruuhkanhallintaan: Päästä-päähän ruuhkanhallinta: Ei eksplisiittistä palautetta verkolta Ruuhka päätellään päätelaitteen havaitsemasta hävikistä ja viiveestä :n lähestymistapa Verkon avustama ruuhkanhallinta: Reitittimet antavat palautetta päätelaitteille Yksi bitti on merkkinä ruuhkasta (SNA, DECbit, /IP ECN, ATM) Selkeä nopeus, jota lähettäjän tulisi käyttää 83 84 14
RTT RTT :n ruuhkanhallinta uotettavan uotettava tiedonsiirto :n ruuhkanhallinta Päästä-päähän kontrolli (ei avustusta verkolta) ähettäjä rajoittaa lähetystä: astbytesent-astbyteacked CongWin Arviolta, CongWin rate = Bytes/sec RTT CongWin on dynaaminen, riippuen havaitusta ruuhkasta Kuinka lähettäjä havaitsee ruuhkan? oss event = timeout tai 3 duplikaatti ACK -viestiä lähettäjä pienentää nopeutta (CongWin) loss event tapahtuman jälkeen Kolme mekanismia: AIMD (additive increase multiplicative decrease) slow start conservative after timeout events 85 86 AIMD additive increase: lisätään CongWin parametria 1 MSS - arvolla RTT:n välein kun ei ole loss event : congestion probing window 24 Kbytes 16 Kbytes 8 Kbytes multiplicative decrease: pienennetään CongWin parametrin arvo puoleen loss event tapahtuman jälkeen time Slow Start Kun yhteys alkaa, CongWin = 1 MSS Esimerkki: MSS = 500 tavua & RTT = 200 ms Alkuperäinen nopeus = 20 kbps Tarjolla oleva kaistanleveys voi olla >> MSS/RTT Suotavaa nopeasti kasvattaa tiedonsiirtonopeutta Host A Host B time Pitkäaikainen yhteys 87 88 Slow Start Yhteyden alussa, kasvatetaan nopeutta exponentiaalisen nopeasti tiettyyn rajaan asti: Käytännössä tuplataan CongWin arvo jokaisella RTT Toteutetaan kasvattamalla CongWin arvoa (yhdellä MSS:llä) jokaisesta vastaanotetusta ACK - viestistä Yhteenveto: Alkuperäinen lähetysnopeus on hidas mutta se kasvaa exponentiaalisesti Host A Host B time 89 Parannus Kolmen duplikaatti ACK viestin jälkeen: CongWin puolitetaan Ikkunan koko kasvaa sen jälkeen lineaarisesti Mutta timeout tapahtuman jälkeen: CongWin asetetaankin arvoon 1 MSS; Ikkuna kasvaa tämän jälkeen exponentiaalisesti Raja-arvoon asti, sitten kasvaa lineaarisesti filosofia: 3 duplikaatti ACK viestiä merkitsee että verkko kykenee kuljettamaan joitain segmenttejä timeout ennen kolmea duplikaatti ACK viestiä on enemmän huolestuttavaa 90 15
Parannus Q: Milloin exponentiaalisen kasvun tulisi vaihtua lineaariseksi? A: Kun CongWin saavuttaa puolet arvostaan ennen ajastimen laukeamista. Toteutus: Muuttuva Threshold -arvo loss tapahtuma -> Threshold asetetaan puoleen siitä CongWin arvosta mikä oli juuri ennen loss tapahtumaa 91 Yhteenveto: ruuhkanhallinta Kun CongWin on alle Threshold arvon, lähettäjä on slow-start vaiheessa, ikkuna kasvaa exponentiaalisesti. Kun CongWin on yli Threshold -arvon, lähettäjä on congestion-avoidance vaiheessa, ikkuna kasvaa lineaarisesti. Kun 3 duplikaatti ACK viestiä, Threshold asetetaan arvoon CongWin/2 ja CongWin asetetaan sitten arvoon Threshold. Kun timeout tapahtuu, Threshold asetetaan arvoon CongWin/2 ja CongWin asetetaan arvoon 1 MSS. 92 lähettäjän ruuhkanhallinta Tapahtuma Tila lähettäjän toimenpide kommentti ACK receipt for previously unacked data ACK receipt for previously unacked data oss event detected by triple duplicate ACK Slow Start (SS) Congestion Avoidance (CA) SS or CA CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance CongWin = CongWin+MSS * (MSS/CongWin) Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Timeout SS or CA Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start Duplicate ACK SS or CA Increment duplicate ACK count for segment being acked Resulting in a doubling of CongWin every RTT Additive increase, resulting in increase of CongWin by 1 MSS every RTT Fast recovery, implementing multiplicative decrease. CongWin will not drop to 1 MSS. Enter slow start CongWin and Threshold not changed :n suorituskyky Mikä on :n keskimääräinen suorituskyky ikkunan koon ja RTT:n funktiona? Ei oteta huomioon slow start -vaihetta Olkoon W ikkunan koko kun paketti katoaa. Kun ikkunan koko on W, tiedonsiirtonopeus on W/RTT Hävikin jälkeen, ikkunan koko pienenee arvoon W/2, tiedonsiirtonopeus W/2RTT. Keskimäääräinen tiedonsiirtonopeus : 0.75 W/RTT 93 94 Fairness Fairness goal: jos K yhteyttä jakaa saman pullonkaulalinkin kaistanleveyden R, jokaisen tulisi saada keskimäärin R/K tiedonsiirtonopeus Miksi on reilu? Kaksi kilpailevaa yhteyttä: Additive increase: molemmat lisäävät lähetysnopeuttaan multiplicative decrease: pienentää lähetysnopeutta suhteellisesti connection 1 R equal bandwidth share connection 2 bottleneck router capacity R loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R 95 96 16
Fairness Fairness ja Multimedia sovellukset harvoin käyttävät :tä Eivät halua ruuhkanhallinnan nopeuden sääntelyä Käyttävät sen sijaan :tä lähetetään audio/video virtaa vakio nopeudella, siedetään pakettien katoamista Tutkimusalue: friendly Fairness ja rinnakkaiset yhteydet Mikään ei estä sovelluksia avaamasta rinnakkaisia yhteyksiä kahden päätelaitteen välille. WWW selaimet toimivat näin Esimerkki: linkki, nopeus R, 9:n yhteyden käytössä; Uusi sovellus avaa yhden yhteyden, saa nopeuden R/10 Uusi sovellus avaa 11 yhteyttä, ja saa nopeuden R/2! : yhteenveto palveluiden : multiplexing, demultiplexing uotettettava tiedonsiirto vuonvalvonta ruuhkanhallinta Internetin kuljetuskerroksen toteutus Seuraavaksi: ähdetään verkon reunalta (sovellus- ja kuljetuskerrokset) Ja sukelletaan verkon ytimeen 97 98 17