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. Kuljetuskerros Tavoitteet: Ymmärtää periaatteet kuljetuskerroksen palvelujen taustalla: kanavointi (multipleksointi) luotettava tiedonsiirto ruuhkanhallinta Oppia Internetin kuljetuskerroksen protokollista: UDP: yhteydetön kuljetus TCP: yhteydellinen kuljetus All material copyright 1996-2004 J.F Kurose and K.W. Ross, All Rights Reserved Kuljetuskerros 1 Kuljetuskerros 2 Kuljetuskerros Kuljetuspalvelut ja -protokollat uotettavan tiedonsiirron periaatteet Kuljetuskerros 3 Tarjotaan looginen kommunikointi eri laitteissa toimivien sovellusprosessien välille Kuljetusprotokollat toimivat päätelaitteissa lähettäjä: pilkkoo sovelluksen viestit segmenteiksi ja välittää ne verkkokerrokselle vastaanottaja: kokoaa segmentit uudelleen viesteiksi ja välittää ne sovelluskerrokselle Yleisesti useampia vaihtoehtoja kuljetusprotokollaksi Internet: TCP ja UDP transport transport Kuljetuskerros 4 Kuljetuskerros vs. verkkokerros Internetin kuljetuskerroksen protokollat verkkokerros: looginen kommunikointi päätelaitteiden välillä kuljetuskerros: looginen kommunikointi prosessien välillä käyttää verkkokerroksen palveluita ja laajentaa/parantaa niitä Analogia: apset lähettävät kirjeitä toisille lapsille prosessit = lapset sovelluksen viestit = kirjeet kirjekuorissa päätelaitteet = postilaatikot kuljetusprotokolla = vanhemmat verkkoprotokolla = postilaitos uotettava, järjestyksen säilyttävä (TCP) yhteyden alustus ruuhkanhallinta Epäluotettava, järjestyksestä piittamaton (UDP) pelkistetty IP-protokollan laajennus Palvelut, joita ei tarjota: takeita viiveelle takeita kaistanleveydelle transport transport Kuljetuskerros 5 Kuljetuskerros 6 1
Kuljetuskerros uotettavan tiedonsiirron periaatteet Kanavointi (multipleksointi) Multipleksointi lähettäjällä: kerätään dataa soketeilta, kapseloidaan data otsikoilla (joita käytetään kanavoinnin purkamisessa) transport P3 P1 P1 Demultipleksointi vastaanottajalla: toimitetaan vastaanotetut segmentit oikeille soketeille transport = socket P2 P4 = process host 1 host 2 host 3 transport Kuljetuskerros 7 Kuljetuskerros 8 Kuinka demultipleksointi toimii Yhteydetön demultipleksointi Päätelaite vastaanottaa IPdatagrammin jokaisessa datagrammissa on lähteen ja kohteen IPosoitteet jokainen datagrammi kuljettaa yhtä kuljetuskerroksen segmenttiä jokaisessa segmentissä on lähteen ja kohteen porttinumerot Päätelaite käyttää IPosoitteita ja porttinumeroita ohjatakseen segmentin oikeaan sokettiin 32 bits source port # dest port # other header fields data (message) TCP/UDP segment format Kuljetuskerros 9 uodaan soketteja, joilla on porttinumerot: DatagramSocket mysocket1 = new DatagramSocket(99111); DatagramSocket mysocket2 = new DatagramSocket(99222); UDP-soketti tunnistetaan kahdella tunnisteella: kohteen IP-osoite kohteen porttinumero Kun päätelaite vastaanottaa UDPsegmentin: tarkistaa segmentistä kohteen porttinumeron ohjaa segmentin porttinumeron osoittamaan sokettiin IP-datagrammit, joilla eri lähde-ip-osoitteet ja/tai eri lähdeporttinumerot, ohjataan samaan sokettiin Kuljetuskerros 10 Yhteydetön demultipleksointi Yhteydellinen demultipleksointi DatagramSocket serversocket = new DatagramSocket(6428); P2 IP: A SP: 9157 DP: 6428 SP: 6428 DP: 9157 P3 server IP: C SP = lähdeportti, tarjoaa paluuosoitteen DP = kohdeportti SP: 6428 DP: 5775 SP: 5775 DP: 6428 P1P1 IP: B Kuljetuskerros 11 TCP-soketti tunnistetaan neljällä tunnisteella: lähteen IP-osoite lähteen porttinumero kohteen IP-osoite kohteen porttinumero Vastaanottava päätelaite käyttää kaikkia neljää tunnistetta ohjatakseen segmentin oikeaan sokettiin Palvelin voi tukea useita samanaikaisia TCPsoketteja: 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 pyynnölle Kuljetuskerros 12 2
Yhteydellinen demultipleksointi Yhteydellinen demultipleksointi: säikeistetty WWW-palvelin P1 P4 P5 P6 P2 P1P3 P1 P4 P2 P1P3 SP: 5775 DP: 80 SP: 5775 DP: 80 S-IP: B D-IP: C S-IP: B D-IP: C SP: 9157 SP: 9157 SP: 9157 SP: 9157 IP: A DP: 80 S-IP: A D-IP: C server IP: C DP: 80 S-IP: B D-IP: C IP: B IP: A DP: 80 S-IP: A D-IP: C server IP: C DP: 80 S-IP: B D-IP: C IP: B Kuljetuskerros 13 Kuljetuskerros 14 Kuljetuskerros UDP: yleiskatsaus [RFC 768] uotettavan tiedonsiirron periaatteet Pelkistetty Internetin kuljetusprotokolla Best effort -palvelu, UDP-segmentit voivat: hävitä matkalla saapua perille väärässä järjestyksessä Yhteydetön: ei kättelyä lähettäjän ja vastaanottajan välillä jokainen UDP-segmentti käsitellään muista riippumattomasti Miksi on olemassa UDP? ei yhteydenmuodostusta (joka voisi lisätä viivettä) yksinkertainen: ei säilytä tilatietoja lähettäjällä tai vastaanottajalla pieni otsikko segmentissä ei ruuhkanhallintaa: UDP voi lähettää niin nopeasti kuin halutaan Kuljetuskerros 15 Kuljetuskerros 16 UDP: yleiskatsaus Internet-tarkistussumma Käytetään usein suoratoistosovelluksissa (streaming) UDPsegmentin sietävät hävikkiä herkkiä nopeuden pituus suhteen tavuina, UDP:tä käyttävät myös mukaanlukien DNS otsikko SNMP uotettava tiedonsiirto ja UDP: lisätään luotettavuutta sovelluskerroksella virheistä toipuminen sovelluskohtaista 32 bits source port # dest port # length data (message) checksum UDP segment format Kuljetuskerros 17 Tavoite: havaita virheitä (esim. bittien vaihtuminen) lähetetyssä segmentissä ähettäjä: käsitellään segmentin sisältö jonona 16 bitin kokonaislukuja tarkistussumma: yhden komplementti kokonaislukujen yhden komplementti -summasta lähettäjä laittaa tarkistussumman arvon checksum-kenttään Vastaanottaja: laskee tarkistussumman vastaanotetusta segmentistä tarkistaa, vastaako laskettu tarkistussumma checksumkentässä olevaa arvoa: EI - virhe havaittu KYÄ - virhettä ei havaittu (mutta voi silti olla virheitä ) Kuljetuskerros 18 3
Internet-tarkistussumma: esimerkki Kun lukuja lasketaan yhteen, eniten merkitsevän bitin muistibitti täytyy lisätä summaan ( kierrättää ) Summan yhden komplementti: muutetaan bitit vastakkaisiksi Esimerkki: lasketaan yhteen kaksi 16 bitin kokonaislukua: tarkistussumma muistibitit kierrätys summa 1 1 1 1 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 1 Kuljetuskerros uotettavan tiedonsiirron periaatteet Kuljetuskerros 19 Kuljetuskerros 20 uotettavan tiedonsiirron periaatteet uotettava tiedonsiirto Erityisen tärkeää sovellus-, kuljetus- ja siirtoyhteyskerroksilla rdt_send(): kutsu yläpuolelta (esim. sovellus), siirtää dataa kuljetettavaksi vastaanottajalle deliver_data(): rdt kutsuu, toimittaa datan ylemmälle kerrokselle send side receive side Epäluotettavan kanavan ominaisuudet määrittävät luotettavan tiedonsiirtoprotokollan (reliable data transfer protocol, rdt) kompleksisuuden Kuljetuskerros 21 udt_send(): rdt kutsuu, siirtää paketin epäluotettavan kanavan yli vastaanottajalle rdt_rcv(): kutsu alapuolelta, kun paketti saapuu kanavan läpi vastaanottajalle Kuljetuskerros 22 uotettava tiedonsiirto Seuraavaksi: Kehitellään vaiheittain lähettäjä ja vastaanottaja luotettavalle tiedonsiirtoprotokollalle (rdt) Tarkastellaan vain yksisuuntaista tiedonsiirtoa mutta kontrolli-informaatio kulkee molempiin suuntiin! Käytetään äärellisiä tilakoneita (finite state machines, FSM) lähettäjän ja vastaanottajan määrittelemiseen Rdt1.0: luotettava tiedonsiirto luotettavassa kanavassa Alapuolella oleva kanava täysin luotettava ei bittivirheitä ei pakettien katoamisia Erilliset tilakoneet lähettäjälle ja vastaanottajalle: lähettäjä lähettää dataa kanavalle vastaanottaja lukee dataa kanavalta tila (state): kun ollaan tässä tilassa, tapahtuma (event) määrittelee yksikäsitteisesti toiminnot (actions) sekä seuraavan tilan state 1 event causing state transition actions taken on state transition event actions state 2 Kuljetuskerros 23 call from above packet = make_pkt(data) udt_send(packet) sender call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) receiver Kuljetuskerros 24 4
Rdt2.0: kanava jossa bittivirheitä Alapuolella oleva kanava voi muuttaa paketin bittejä tarkistussumma bittivirheiden havaitsemiseksi Kysymys: kuinka selvitään virheistä? kuittaukset (acknowledgements, ACKs): vastaanottaja eksplisiittisesti kertoo lähettäjälle, että paketti oli OK negatiiviset kuittaukset (negative acknowledgements, NAKs): vastaanottaja eksplisiittisesti kertoo lähettäjälle, että paketissa oli virheitä lähettäjä uudelleenlähettää paketin saatuaan NAK-viestin Protokollan rdt2.0 uudet mekanismit: virheiden havaitseminen vastaanottajan palaute: kontrolliviestit (ACK, NAK) vastaanottajalta lähettäjälle Kuljetuskerros 25 Rdt2.0: tilakoneen määrittely sndpkt = make_pkt(data, checksum) call from above isack(rcvpkt) sender ACK or NAK isnak(rcvpkt) receiver corrupt(rcvpkt) udt_send(nak) call from below notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Kuljetuskerros 26 Rdt2.0: toiminta ilman virheitä Rdt2.0: toiminta virheen sattuessa sndpkt = make_pkt(data, checksum) call from above ACK or NAK isnak(rcvpkt) receiver corrupt(rcvpkt) udt_send(nak) sndpkt = make_pkt(data, checksum) call from above ACK or NAK isnak(rcvpkt) receiver corrupt(rcvpkt) udt_send(nak) isack(rcvpkt) call from below isack(rcvpkt) call from below sender notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) sender notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Kuljetuskerros 27 Kuljetuskerros 28 Rdt2.0: kohtalokas vika! Mitä tapahtuu, jos ACK tai NAK on korruptoitunut? lähettäjä ei tiedä, mitä vastaanottajan puolella on tapahtunut! ei voida noin vain uudelleenlähettää: mahdollinen duplikaatti Duplikaattien käsittely: lähettäjä lisää sekvenssinumeron jokaiseen pakettiin lähettäjä uudelleenlähettää paketin, jos sen kuittaus (ACK/NAK) on epäselvä vastaanottaja hylkää duplikaatit (ei välitä niitä ylemmälle kerrokselle) stop and wait ähetetään yksi paketti ja odotetaan kuittausta ennen seuraavan paketin lähettämistä Rdt2.1: lähettäjä ja epäselvät kuittaukset rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from above ACK or NAK 1 ACK or NAK 0 call 1 from above ( corrupt(rcvpkt) isnak(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) Kuljetuskerros 29 Kuljetuskerros 30 5
Rdt2.1: vastaanottaja ja epäselvät kuittaukset corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(nak, 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) notcorrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(nak, chksum) Kuljetuskerros 31 Rdt2.1: kommentteja ähettäjä: pakettiin lisätään sekvenssinumero kaksi eri sekvenssinumeroa (0,1) riittää (miksi?) täytyy tarkistaa, onko vastaanotettu ACK/NAK korruptoitunut kaksinkertainen määrä tiloja tilan täytyy muistaa, onko nykyisen paketin numero 0 vai 1 Vastaanottaja: täytyy tarkistaa, onko vastaanotettu paketti duplikaatti tila ilmaisee, mikä seuraavan paketin numeron pitäisi olla Huom: vastaanottaja ei voi tietää, onko sen lähettämä ACK/NAK vastaanotettu OK lähettäjän puolella Kuljetuskerros 32 Rdt2.2: protokolla ilman NAK-viestejä Muutoin sama toiminnallisuus kuin rdt2.1:ssa, mutta käytetään vain ACK-viestejä Vastaanottaja lähettää ACK-viestin viimeisimmästä oikein vastaanotetusta paketista vastaanottajan täytyy eksplisiittisesti lisätä kuitattavan paketin sekvenssinumero ACK-viestiin Duplikaatti ACK lähettäjällä aiheuttaa saman toiminnon kuin NAK aikaisemmin: uudelleenlähetetään nykyinen paketti Kuljetuskerros 33 Rdt2.2: lähettäjä ja vastaanottaja (osa) ( corrupt(rcvpkt) has_seq1(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from above 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) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Kuljetuskerros 34 Rdt3.0: kanava jossa bittivirheitä ja viestien katoamisia Uusi oletus: alapuolella oleva kanava voi myös kadottaa paketteja (dataa tai ACKviestejä) tarkistussumma, sekvenssinumerot, ACK-viestit ja uudelleenlähetykset auttavat, mutta eivät riitä ähestymistapa: lähettäjä odottaa järkevän ajan ACKviestiä uudelleenlähettää, jos ACKviestiä ei saada tänä aikana jos paketti (tai ACK) on vain myöhässä (ei kadonnut): uudelleenlähetys aiheuttaa duplikaatin, mutta siitä selvitään sekvenssinumeroilla vastaanottajan täytyy ilmoittaa kuitattavan paketin sekvenssinumero vaatii ajastimen Rdt3.0: lähettäjä rdt_rcv(rcvpkt) call 0 from above rdt_rcv(rcvpkt) && 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 above sndpkt = make_pkt(1, data, checksum) start_timer ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) Kuljetuskerros 35 Kuljetuskerros 36 6
Rdt3.0 toiminnassa Rdt3.0 toiminnassa Kuljetuskerros 37 Kuljetuskerros 38 Rtd3.0: suorituskyky Rdt3.0: stop-and-wait-operaatio rdt3.0 toimii, mutta suorituskyky on surkea esimerkki: 1 Gbps linkki, 15 ms päästä-päähän etenemisviive, 1 kb (kilotavu) paketti: first packet bit transmitted, t = 0 last packet bit transmitted, t = / R sender receiver T transmit = (packet length in bits) R (transmission rate, bps) = 8 kb 1 Gb/s = 0.008 ms RTT first packet bit arrives last packet bit arrives, send ACK U sender = / R = 0.008 = 0.00027 RTT + / R 30.008 U sender : käyttöaste kuinka suuren osan ajasta lähettäjä lähettää 1 kb paketti kerran 30 ms -> 33 kb/s nopeus 1 Gbps linkillä verkon protokolla rajoittaa fyysisten resurssien käyttöä! ACK arrives, send next packet, t = RTT + / R U sender = / R = 0.008 = 0.00027 RTT + / R 30.008 Kuljetuskerros 39 Kuljetuskerros 40 Putkitetut protokollat Putkitus (pipelining): lähettäjä sallii useita matkalla olevia, vielä kuittaamattomia paketteja sekvenssinumeroiden määrää täytyy lisätä tarvitaan puskurointi lähettäjällä ja/tai vastaanottajalla Putkitus: käyttöaste kasvaa first packet bit transmitted, t = 0 last bit transmitted, t = / R RTT ACK arrives, send next packet, t = RTT + / R sender receiver first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Käyttöaste kasvaa kolminkertaiseksi! Kaksi yleistä menetelmää putkitetuille protokollille: go-back-n, selective repeat Kuljetuskerros 41 3* / R U 0.024 sender = = = 0.0008 RTT + / R 30.008 Kuljetuskerros 42 7
Go-Back-N ähettäjä: k bittinen sekvenssinumero paketin otsikossa ikkuna jonka koko N, eli sallitaan N peräkkäistä kuittaamatonta pakettia ACK(n): kuittaa kaikki paketit sekvenssinumeroon n saakka (mukaanlukien numero n) - kumulatiivinen ACK voi tulla duplikaattikuittauksia (katso vastaanottaja) yksi ajastin kuittaamattomille paketeille ( vanhimmalle ) timeout(n): uudelleenlähetetään paketti n sekä ikkunan kaikki suuremman sekvenssinumeron paketit Kuljetuskerros 43 GBN: lähettäjä, laajennettu tilakone send_base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) if (nextseqnum < send_base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (send_base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) Wait timeout notcorrupt(rcvpkt) if (getacknum(rcvpkt) >= send_base) { send_base = getacknum(rcvpkt)+1 if (send_base == nextseqnum) stop_timer else start_timer } start_timer udt_send(sndpkt[send_base]) udt_send(sndpkt[send_base+1]) udt_send(sndpkt[nextseqnum-1]) Kuljetuskerros 44 GBN: vastaanottaja, laajennettu tilakone default expectedseqnum=1 sndpkt = make_pkt(0,ack,chksum) Wait rdt_rcv(rcvpkt) && notcorrupt(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 oikein vastaanotetusta paketista, jolla on suurin oikeassa järjestyksessä oleva sekvenssinumero voi generoida duplikaattikuittauksia täytyy muistaa ainoastaan expectedseqnum Paketti, joka tulee väärässä järjestyksessä: hylätään (ei puskuroida) -> ei tarvita puskurointia vastaanottajalla! kuitataan uudestaan paketti, jolla suurin oikeassa järjestyksessä oleva sekvenssinumero Kuljetuskerros 45 GBN toiminnassa Kuljetuskerros 46 Selective Repeat Vastaanottaja kuittaa yksittäin kaikki oikein vastaanotetut paketit vastaanottaja puskuroi paketteja tarpeen mukaan, jotta voi välittää ne ylemmälle kerrokselle oikeassa järjestyksessä ähettäjä uudelleenlähettää vain paketit, joista ei ole saanut kuittausta lähettäjällä eri ajastin jokaiselle kuittaamattomalle paketille ähettäjän ikkuna N peräkkäistä sekvenssinumeroa rajoittaa lähetettyjen mutta kuittaamattomien pakettien sekvenssinumeroita Kuljetuskerros 47 Selective Repeat: lähettäjän ja vastaanottajan ikkunat Kuljetuskerros 48 8
Selective Repeat lähettäjä dataa yläpuolelta: jos seuraava vapaa sekvenssinumero ikkunassa, lähetä paketti timeout(n): uudelleenlähetä paketti n, käynnistä ajastin uudelleen ACK(n) välillä [send_base,send_base+n]: merkitse paketti n kuitatuksi jos n oli vanhin kuittaamaton paketti, siirrä ikkunan alaraja (send_base) seuraavan kuittaamattoman paketin kohdalle vastaanottaja paketti n välillä [rcv_base, rcv_base+n-1]: lähetä ACK(n) out-of-order: puskuroi in-order: välitä ylöspäin (myös puskuroidut in-order-paketit), siirrä ikkunan alaraja (rcv_base) seuraavan ei vielä vastaanotetun paketin kohdalle paketti n välillä [rcv_base-n,rcv_base-1]: lähetä ACK(n) muuten: älä tee mitään Selective Repeat toiminnassa Kuljetuskerros 49 Kuljetuskerros 50 Selective Repeat: dilemma Kuljetuskerros Esimerkki: sekvenssinumerot: 0, 1, 2, 3 ikkunan koko = 3 vastaanottaja ei näe eroa tapausten välillä! kohdassa (a) välittää duplikaattidatan virheellisesti uutena datana Q: Mikä pitäisi olla sekvenssinumeroiden ja ikkunan koon välinen suhde? Kuljetuskerros 51 uotettavan tiedonsiirron periaatteet Kuljetuskerros 52 socket door TCP: yleiskatsaus [RFC: 793, 1122, 1323, 2018, 2581] pisteestä pisteeseen: yksi lähettäjä, yksi vastaanottaja luotettava, järjestyksen säilyttävä tavuvirta: ei viestirajoja putkitettu: ja vuonvalvonta määrittävät ikkunoiden koot puskurointi lähettäjällä ja vastaanottajalla writes data TCP send buffer segment reads data TCP receive buffer full duplex data: kaksisuuntainen tiedonsiirto samassa yhteydessä datan suurin määrä yhdessä paketissa: MSS (maximum segment size) yhteydellinen: kättely (kontrolliviestien vaihto), alustaa lähettäjän ja vastaanottajan tilat ennen tiedonsiirtoa : lähettäjä ei tukahduta vastaanottajaa socket door Kuljetuskerros 53 TCP: 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 UDP) 32 bits source port # dest port # sequence number acknowledgement number head not UAP R S F receive window len used checksum urg data pnter options (variable length) data (variable length) counting by bytes of data (not segments!) # of bytes rcvr willing to accept Kuljetuskerros 54 9
RTT (milliseconds) TCP: sekvenssinumerot ja ACK-viestit TCP: Round Trip Time ja Timeout Sekvenssinumerot: segmentin datakentässä olevan tavuvirran ensimmäisen tavun numero ACK-viestit: seuraavana odotettavan tavun sekvenssinumero kumulatiivinen ACK Q: Kuinka vastaanottaja käsittelee out-oforder-segmentit? A: TCP ei määrittele - riippuu toteutuksesta 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 Q: Miten määritellään TCP:n timeout-arvo? pidempi kuin RTT mutta RTT vaihtelee liian lyhyt: ennenaikainen timeout tarpeettomia uudelleenlähetyksiä liian pitkä: hidas reagointi segmentien katoamiseen Q: Miten arvioidaan RTT:tä? SampleRTT: mitattu aika segmentin lähettämisestä ACKviestin vastaanottamiseen ei huomioida uudelleenlähetyksiä SampleRTT vaihtelee, joten halutaan pehmeämpi arvio RTT:lle ei pelkästään viimeisin SampleRTT, vaan keskiarvo useammasta viimeaikaisesta mittauksesta Kuljetuskerros 55 Kuljetuskerros 56 TCP: Round Trip Time ja Timeout RTT:n arviointi EstimatedRTT = (1 - )*EstimatedRTT + *SampleRTT eksponentialinen painotettu liukuva keskiarvo edellisten näytteiden vaikutus pienene eksponentiaalisella nopeudella tyypillinen arvo: = 0.125 Esimerkki: RTT:n arviointi RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 300 250 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT Kuljetuskerros 57 Kuljetuskerros 58 TCP: Round Trip Time ja Timeout Timeout-arvon asettaminen EstimatedRTT plus turvaväli suuri vaihtelu EstimatedRTT-arvossa -> suurempi turvaväli ensin arvio sille, miten paljon SampleRTT eroaa EstimatedRTT-arvosta: DevRTT = (1 - )*DevRTT + * SampleRTT - EstimatedRTT (tyypillisesti, = 0.25) Sitten asetetaan timeout-arvo: TimeoutInterval = EstimatedRTT + 4*DevRTT Kuljetuskerros uotettavan tiedonsiirron periaatteet Kuljetuskerros 59 Kuljetuskerros 60 10
Seq=92 timeout Seq=92 timeout timeout timeout TCP:n luotettava tiedonsiirto TCP luo luotettavan tiedonsiirtopalvelun IP:n epäluotettavan palvelun päälle Putkitetut segmentit Kumulatiiviset kuittaukset TCP käyttää yhtä uudelleenlähetysajastinta Uudelleenlähetykset johtuvat: ajastimen laukeamisista (timeout) duplikaattikuittauksista Tarkastellaan aluksi yksinkertaistettua TCP-lähettäjää: jätetään huomiotta duplikaattikuittaukset jätetään huomiotta vuonvalvonta ja ruuhkanhallinta TCP: lähettäjän tapahtumia dataa sovellukselta: luodaan segmentti ja sekvenssinumero sekvenssinumero on segmentissä olevan tavuvirran ensimmäisen datatavun numero käynnistetään ajastin, jos se ei jo ole käynnissä (vanhin kuittaamaton segmentti) asetetaan arvo ajastimen laukeamiselle: TimeOutInterval timeout: uudelleenlähetetään segmentti, joka aiheutti ajastimen laukeamisen käynnistetään ajastin uudelleen ack-viesti: jos kuittaa ennestään kuittaamattomia segmenttejä päivitetään tiedot kuitatuista segmenteistä käynnistetään ajastin, jos on vielä kuittaamattomia segmenttejä Kuljetuskerros 61 Kuljetuskerros 62 NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from above create TCP 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 */ TCP: lähettäjä (yksinkertaistettu) Kommentti: SendBase-1 on viimeisin kumulatiivisesti kuitattu tavu Esimerkki: SendBase-1 = 71; y = 73, joten vastaanottaja haluaa 73+; y > SendBase, joten uutta dataa kuitataan (tavu 72) Kuljetuskerros 63 TCP: uudelleenlähetykset SendBase = 100 Host A X loss Host B time ost ACK scenario Kuljetuskerros 64 TCP: uudelleenlähetykset TCP: uudelleenlähetykset Host A Host B Host A Host B Sendbase = 100 SendBase = 120 SendBase = 120 X loss SendBase = 120 time Premature timeout Kuljetuskerros 65 time Cumulative ACK scenario Kuljetuskerros 66 11
TCP: ACK-generointi [RFC: 1122, 2581] Fast Retransmit -menetelmä 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. TCP Receiver action Delayed ACK. Wait up to 500 ms 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. Immediately send ACK, provided that segment starts at lower end of gap. Timeout-aika on usein suhteellisen pitkä: pitkä viive ennen uudelleenlähetystä Segmenttien häviäminen voidaan havaita duplikaattikuittausten avulla: lähettäjä lähettää usein monta segmenttiä peräkkäin jos segmentti häviää, tulee todennäköisesti useita duplikaattikuittauksia Jos lähettäjä saa 3 duplikaattikuittausta, se olettaa, että kaikki kuitatun segmentin jälkeiset segmentit ovat hävinneet: fast retransmit: uudelleenlähetetään segmentti ennen ajastimen laukeamista Kuljetuskerros 67 Kuljetuskerros 68 Fast Retransmit -algoritmi Kuljetuskerros 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 } a duplicate ACK for already ACKed segment fast retransmit uotettavan tiedonsiirron periaatteet Kuljetuskerros 69 Kuljetuskerros 70 TCP:n vuonvalvonta TCP-yhteyden vastaanottajalla on vastaanottopuskuri: Sovellusprosessi voi olla hidas lukemaan dataa puskurista vuonvalvonta lähettäjä ei tukahduta vastaanottajan puskuria lähettämällä liian paljon, liian nopeasti Nopeudensovituspalvelu: sovitetaan lähetysnopeus vastaanottavan sovelluksen mukaan Kuljetuskerros 71 TCP:n vuonvalvonta: näin se toimii (Oletetaan, että TCPvastaanottaja hylkää out-of-order-segmentit) vapaata tilaa puskurissa Vastaanottaja mainostaa vapaata tilaa asettamalla RcvWindow-arvon segmentteihin ähettäjä rajoittaa kuittaamattomien segmenttien määrän RcvWindow-arvoon takaa sen, että vastaanottajan puskuri ei vuoda yli = RcvWindow = RcvBuffer [astbytercvd - astbyteread] Kuljetuskerros 72 12
timed wait Kuljetuskerros uotettavan tiedonsiirron periaatteet TCP:n yhteydenhallinta Yhteys: lähettäjä ja vastaanottaja muodostavat yhteyden ennen datan lähettämistä alustetaan TCP-muuttujat: sekvenssinumerot puskurit, vuonvalvonta-info (esim. RcvWindow) asiakas: yhteydenoton aloittaja Socket Socket = newsocket("hostname","portnumber"); palvelin: yhteydenoton kohde Socket connectionsocket = welcomesocket.accept(); Kuljetuskerros 73 Kuljetuskerros 74 TCP: yhteyden aloitus Kolmitiekättely: TCP: yhteyden lopetus Step 1: asiakas lähettää SYNsegmentin palvelimelle määrittelee asiakkaan aloitussekvenssinumeron ei dataa Step 2: palvelin vastaanottaa SYNviestin, vastaa SYNACKsegmentillä server Yhteyden sulkeminen: asiakas sulkee soketin: Socket.close(); Step 1: asiakas lähettää FIN-segmentin palvelimelle close server close palvelin alustaa puskurit määrittelee palvelimen aloitussekvenssinumeron Step 3: asiakas vastaanottaa SYNACK-viestin, vastaa ACKsegmentillä Step 2: palvelin vastaanottaa FIN-viestin, vastaa ACK-segmentillä, lähettää FIN-segmentin voi sisältää dataa Kuljetuskerros 75 Kuljetuskerros 76 TCP: yhteyden lopetus (jatkuu) TCP:n yhteydenhallinta Step 3: asiakas vastaanottaa FIN-viestin, vastaa ACK-segmentillä closing server menee timed wait tilaan kuittaa ACK-viesteillä mahdolliset FIN-viestit closing TCP server lifecycle sulkee yhteyden Step 4: palvelin vastaanottaa ACK-viestin, sulkee yhteyden closed TCP lifecycle Huom: pienillä muutoksilla voidaan käsitellä samanaikaiset FIN-viestit closed Kuljetuskerros 77 Kuljetuskerros 78 13
Kuljetuskerros uotettavan tiedonsiirron periaatteet Ruuhkanhallinnan periaatteet Ruuhka: Epämuodollisesti: liian monta lähdettä lähettää liian paljon dataa liian nopeasti, jotta verkko pystyisi käsittelemään kaiken Eri asia kuin vuonvalvonta! Ilmenemismuodot: kadonneet paketit (ylivuoto reitittimien puskureissa) pitkät viiveet (jonotus reitittimien puskureissa) Top 10 -ongelma! Kuljetuskerros 79 Kuljetuskerros 80 Ruuhkan syyt ja seuraukset: tapaus 1 Ruuhkan syyt ja seuraukset: tapaus 2 kaksi lähettäjää, kaksi vastaanottajaa yksi reititin, äärettömät puskurit ei uudelleenlähetyksiä Host B Host A l in : original data unlimited shared output link buffers l out yksi reititin, äärelliset puskurit lähettäjä uudelleenlähettää kadonneet paketit Host A l in : original data l' in : original data, plus retransmitted data l out suuret viiveet, kun on ruuhkaa maksimaalinen suoritusteho (throughput) Host B finite shared output link buffers Kuljetuskerros 81 Kuljetuskerros 82 l out Ruuhkan syyt ja seuraukset: tapaus 2 a: ei hävikkiä, ei uudelleenlähetyksiä: l = = l in l in out b: täydellinen uudelleenlähetys vain, jos hävikkiä: l > l in out c: viivästyneiden (ei kadonneiden) pakettien uudelleenlähetys johtaa suurempaan l (kuin täydellinen tapaus) samalle l in out C/2 C/2 C/2 C/3 C/4 l out l out Ruuhkan syyt ja seuraukset: tapaus 3 neljä lähettäjää monen hypyn polkuja timeout -> uudelleenlähetys Q: Mitä tapahtuu, kun l in ja l kasvavat? in l in : original data l' in : original data, plus retransmitted data finite shared output link buffers l in C/2 l in C/2 l in C/2 l out a b c Ruuhkan hinta : lisää työtä (uudelleenlähetykset) turhia uudelleenlähetyksiä: linkillä useita paketin kopioita Kuljetuskerros 83 Kuljetuskerros 84 14
RTT Ruuhkan syyt ja seuraukset: tapaus 3 ähestymistapoja ruuhkanhallintaan Kaksi yleistä lähestymistapaa: Vielä yksi ruuhkan hinta : kun paketti pudotetaan, kaikki siihen mennessä käytetty upstream tiedonsiirtokapasiteetti kyseiselle paketille menee hukkaan! Kuljetuskerros 85 Päästä-päähänruuhkanhallinta: ei eksplisiittistä palautetta verkolta ruuhka päätellään päätelaitteen havaitsemasta hävikistä ja viiveestä TCP:n lähestymistapa Verkkoavusteinen ruuhkanhallinta: reitittimet antavat palautetta päätelaitteille tietyt bitit paketissa kertovat ruuhkasta (esim. TCP/IP:n ECN-laajennus) eksplisiittinen nopeus, jolla lähettäjän pitäisi lähettää Kuljetuskerros 86 Kuljetuskerros TCP:n ruuhkanhallinta uotettavan tiedonsiirron periaatteet Päästä-päähän-kontrolli (ei avustusta verkolta) ähettäjä rajoittaa lähetystä: astbytesent-astbyteacked CongWin Arviolta, rate = CongWin Bytes/sec RTT CongWin on dynaaminen: muuttuu havaitun ruuhkautumisen mukaan Miten lähettäjä havaitsee ruuhkan? loss event = timeout tai 3 duplikaattikuittausta lähettäjä pienentää nopeutta (CongWin) loss event tapahtuman jälkeen Kolme mekanismia: AIMD (additive increase, multiplicative decrease) slow start conservative after timeout events Kuljetuskerros 87 Kuljetuskerros 88 TCP: AIMD additive increase: lisätään CongWin-arvoa yhdellä MSS:llä jokaista RTT:tä kohden, ellei tule loss eventejä 24 Kbytes 16 Kbytes 8 Kbytes congestion window Pitkäaikainen TCP-yhteys multiplicative decrease: pienennetään CongWinarvo puoleen jokaisen loss eventin jälkeen time Kuljetuskerros 89 TCP: Slow Start Aluksi CongWin = 1 MSS esimerkiksi: MSS = 500 tavua ja RTT = 200 ms, jolloin aloitusnopeus = 20 kbps mutta kaistanleveys voi olla paljon suurempi kuin MSS/RTT Nopeutta kasvatetaan eksponentiaalisesti kunnes tulee ensimmäinen loss event: kaksinkertaistetaan CongWin jokaisella RTT toteutetaan kasvattamalla CongWin-arvoa yhdellä MSS:llä jokaista ACK-viestiä kohden Yhteenveto: alussa hidas, mutta kiihtyy eksponentiaalisesti Host A Host B time Kuljetuskerros 90 15
Parannus Kolmen duplikaattikuittauksen jälkeen: CongWin puolitetaan sen jälkeen kasvaa lineaarisesti Mutta timeoutin jälkeen: CongWin asetetaan arvoon 1 MSS sen jälkeen kasvaa eksponentiaalisesti rajaarvoon (threshold) saakka minkä jälkeen taas lineaarisesti Filosofia: 3 duplikaattikuittausta merkitsee, että verkko kykenee kuljettamaan joitain segmenttejä timeout ennen kolmea duplikaattikuittausta on enemmän huolestuttavaa Parannus (jatkuu) Q: Milloin pitäisi vaihtaa eksponentiaalisesta kasvusta lineaariseen? A: Kun CongWin saavuttaa puolet arvostaan ennen timeoutia Toteutus: muuttuva threshold kun loss event, uudeksi threshold-arvoksi asetetaan puolet juuri ennen loss eventiä olleesta CongWin-arvosta Kuljetuskerros 91 Kuljetuskerros 92 TCP:n ruuhkanhallinta: yhteenveto Kun CongWin on alle Threshold-arvon, lähettäjä on slow-start-vaiheessa ja ikkuna kasvaa eksponentiaalisesti Kun CongWin on yli Threshold-arvon, lähettäjä on congestion-avoidance-vaiheessa ja ikkuna kasvaa lineaarisesti Kun kolmas duplikaattikuittaus tulee, Threshold asetetaan arvoon CongWin/2 ja CongWin asetetaan arvoon Threshold Kun timeout tapahtuu, Threshold asetetaan arvoon CongWin/2 ja CongWin asetetaan arvoon 1 MSS TCP: lähettäjän ruuhkanhallinta Event State TCP Sender Action Commentary 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 below 1 MSS) Enter slow start CongWin and Threshold not changed Kuljetuskerros 93 Kuljetuskerros 94 TCP:n suoritusteho Mikä on TCP:n keskimääräinen suoritusteho (throughput) ikkunan koon ja RTT:n funktiona? ei oteta huomioon slow start -vaihetta Olkoon W ikkunan koko, kun paketti katoaa Ennen katoamista ikkunan koko on W, suoritusteho on W*MSS/RTT Katoamisen jälkeen ikkunan koko on W/2, suoritusteho on 0.5*W*MSS/RTT Keskimääräinen suoritusteho: 0.75*W*MSS/RTT TCP:n tulevaisuudesta Suoritusteho: W*MSS/RTT Esimerkki: 1500 tavun segmentit (MSS), 100 ms RTT, halutaan 10 Gbps suoritusteho Vaatii ikkunan koon W = 83 333 matkalla oleville segmenteille Suoritusteho hävikin (prosentteina) avulla ilmaistuna: 1.22 MSS RTT = 2 10-10 Wow Tarvitaan TCP:n uusia versioita suurille nopeuksille! Kuljetuskerros 95 Kuljetuskerros 96 16
TCP: reiluus Tavoite: jos K eri TCP-yhteyttä jakaa saman pullonkaulalinkin, jonka kaistanleveys on R, jokaisen keskimääräinen tiedonsiirtonopeus tulisi olla R/K TCP connection 1 Miksi TCP on reilu? Kaksi kilpailevaa yhteyttä: Additive increase: kasvattaa lähetysnopeutta saman verran Multiplicative decrease: pienentää lähetysnopeutta suhteellisesti R equal bandwidth share TCP 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 Kuljetuskerros 97 Kuljetuskerros 98 Reiluus Viiveen mallinnus Reiluus ja UDP Multimediasovellukset käyttävät harvoin TCP:tä eivät halua, että ruuhkanhallinta rajoittaa lähetysnopeutta Sen sijaan käyttävät UDP:tä lähetetään audio/videodataa vakionopeudella siedetään pakettien katoamisia Tutkimusalue: miten UDP:stä TCP friendly Reiluus ja rinnakkaiset TCPyhteydet Mikään ei estä sovellusta avaamasta rinnakkaisia yhteyksiä kahden päätelaitteen välille WWW-selaimet tekevät näin Esimerkki: linkin nopeus R, käytössä 9 yhteyttä uusi sovellus pyytää yhden TCPyhteyden, saa nopeuden R/10 uusi sovellus pyytää 11 TCPyhteyttä, saa nopeuden R/2! Q: Kuinka kauan kestää pyydetyn objektin saaminen WWWpalvelimelta? Jos jätetään ruuhka huomioimatta,viiveeseen vaikuttaa: TCP-yhteyden muodostus lähetysviive slow start -vaihe Merkintöjä ja oletuksia: yksi linkki asiakkaan ja palvelimen välillä, nopeus R S: segmentin koko, MSS O: objektin koko ei uudelleenlähetyksiä (ei hävikkiä tai bittivirheitä) Ikkunan koko: Aluksi: kiinteä ikkuna, W segmenttiä Sitten: dynaaminen ikkuna, mallintaen slow start - vaihetta Kuljetuskerros 99 Kuljetuskerros 100 Kiinteä ruuhkaikkuna (1) Kiinteä ruuhkaikkuna (2) Ensimmäinen tapaus WS/R > RTT + S/R: Ensimmäisen segmentin kuittaus tulee ennen kuin koko ikkunallinen dataa on lähetetty viive = 2RTT + O/R Toinen tapaus WS/R < RTT + S/R: Odotetaan kuittausta, kun on lähetetty ikkunallinen dataa viive = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] missä K = O/WS (ikkunoiden lukumäärä) Kuljetuskerros 101 Kuljetuskerros 102 17
Dynaaminen ruuhkaikkuna (1) Oletetaan sitten, että ikkunan koko kasvaa kuten slow start -vaiheessa Osoitetaan, että viive yhdelle objektille on: O S P S atency 2RTT P RTT (2 1) R R R missä P on TCP-yhteyden idle-tilojen lukumäärä palvelimella: P min{ Q, K 1} - missä Q on idle-tilojen lukumäärä palvelimella, jos objektilla olisi ääretön koko - ja K on objektin lähetykseen tarvittavien ikkunoiden lukumäärä Kuljetuskerros 103 Dynaaminen ruuhkaikkuna (2) Viivekomponentit: 2 RTT yhteyden muodostukselle ja request-viestille O/R objektin lähettämiseen aika, jonka palvelin on idle-tilassa johtuen slow start -vaiheesta Palvelin idle-tilassa P = min{k-1,q} kertaa Esimerkki: O/S = 15 segmenttiä K = 4 ikkunaa Q = 2 P = min{k-1,q} = 2 Palvelin idle-tilassa P=2 kertaa initiate TCP connection request object object delivered RTT time at first window = S/R second window = 2S/R third window = 4S/R fourth window = 8S/R complete transmission time at server Kuljetuskerros 104 Dynaaminen ruuhkaikkuna (3) S RTT R time from when server starts to send segment S k S 2 1 RTT idle time after the kth window R R O delay 2RTT R until server receives acknowledgement k S 2 1 time to transmit the kth window R P p 1 idletime P O S k 1 S 2RTT [ RTT 2 ] R k 1 R R O S P S 2RTT P[ RTT ] (2 1) R R R p initiate TCP connection request object object delivered RTT time at first window = S/R second window = 2S/R third window = 4S/R fourth window = 8S/R complete transmission time at server Kuljetuskerros 105 Dynaaminen ruuhkaikkuna (4) K = objektin lähetykseen tarvittavien ikkunoiden lukumäärä Miten K lasketaan? 0 1 k K min{ k : 2 S 2 S 2 0 1 k min{ k : 2 2 2 1 k O min{ k : 2 1 } S O min{ k : k log 2( 1)} S O log 2( 1) S 1 S O} O / S} Q = idle-tilojen lukumäärä palvelimella, jos objektilla olisi ääretön koko: lasketaan samalla periaatteella Kuljetuskerros 106 HTTP: mallinnus Oletetaan, että WWW-sivulla on: 1 perus HTM-sivu (koko O bittiä) M kuvaa (jokaisen koko O bittiä) Non-persistent HTTP: M+1 TCP-yhteyttä sarjassa Vasteaika = (M+1)O/R + (M+1)2RTT + idle-aikojen summa Persistent HTTP: 2 RTT perus HTM-tiedoston pyytämiseen ja saantiin 1 RTT kaikkien kuvien pyytämiseen ja saantiin Vasteaika = (M+1)O/R + 3RTT + idle-aikojen summa Non-persistent HTTP ja X rinnakkaista yhteyttä: Oletetaan, että M/X on kokonaisluku 1 TCP-yhteys perus HTM-tiedostolle M/X rinnakkaistatcp-yhteyttä kuville Vasteaika = (M+1)O/R + (M/X+1)2RTT + idle-aikojen summa Kuljetuskerros 107 HTTP: vasteaika RTT = 100 ms, O = 5 KB, M = 10 ja X = 5 20 18 16 14 12 10 8 6 4 2 0 28 Kbps 100 Kbps 1 Mbps 10 Mbps non-persistent persistent parallel nonpersistent Pienellä kaistanleveydellä vasteaikaa dominoi lähetysaika. Persistentyhteydet ovat vain hieman parempia kuin rinnakkaiset yhteydet. Kuljetuskerros 108 18
HTTP: vasteaika RTT = 1 s, O = 5 KB, M = 10 ja X = 5 70 60 50 40 30 20 10 0 28 Kbps 100 Kbps 1 Mbps 10 Mbps non-persistent persistent parallel nonpersistent Suuremmalla RTT vasteaikaa dominoi TCP-yhteyden luominen ja slow start -vaihe. Persistent-yhteyksillä saadaan nyt merkittävä parannus. Kuljetuskerros: Yhteenveto Kuljetuskerroksen palvelujen periaatteet: kanavointi (multiplexing, demultiplexing) ruuhkanhallinta Toteutus Internetissä: UDP TCP Seuraavaksi: lähdetään verkon reunalta ja siirrytään verkon runkoon Kuljetuskerros 109 Kuljetuskerros 110 19