811338A 3 Kuljetusprotokollat Luotettava ja epäluotettava tiedonsiirto Oulun yliopisto Tietojenkäsittelytieteiden laitos
Luento pohjautuu kirjan James F. Kurose, Keith W. Ross, Computer Networking, A Top-Down Approach, 6th (International) ed., Pearson Education Limited, 2013, ISBN 10: 0-273- 76896-4, ISBN 13: 978-0-273-76896-4 kolmanteen lukuun (sivut 211 311). 2
Mitä käsitellään? 0. Johdanto 1. Kuljetuskerroksen palvelut 2. Monikanavointi ja kanavoinnin purkaminen 3. Yhteydetön tiedonsiirto: UDP 4. Luotettavan tiedonsiirron periaatteet 5. Yhteyspohjainen tiedonsiirto: TCP 6. Ruuhkakontrollin periaatteet 7. TCP:n ruuhkakontrolli 3
Mitä käsitellään? (2) 0. Johdanto 1. Kuljetuskerroksen palvelut 1.1 Kuljetuskerroksen ja verkkokerroksen suhde 1.2 Internetin kuljetuskerroksesta 2. Monikanavointi ja kanavoinnin purkaminen 2.1 Taustaa 2.2 Yhteydetön kanavointi 2.3 Yhteyspohjainen kanavointi 3. Yhteydetön tiedonsiirto: UDP 3.1 Taustaa 3.2 UDP:n segmentin rakenne 3.3 UDP:n tarkistussumma 4
Mitä käsitellään? (3) 4. Luotettavan tiedonsiirron periaatteet 4.1 Taustaa 4.2 Luotettavan tiedonsiirtoprotokollan rakentaminen 4.3 Luotettavat tideonsiirtoprotokollat ja putkikuljetus 4.4 Go-Back-N (GBN) 4.5 Valikoiva toisto (Selective Repeat, SR) 5. Yhteyspohjainen tiedonsiirto: TCP 5.1 Taustaa 5.2 TCP yhteys 5.3 TCP segmentin rakenne 5.4 Kiertoviiveen arviointi ja aikamerkki 5.5 Luotettava tiedonsiirto 5
Mitä käsitellään? (4) 5. Yhteyspohjainen tiedonsiirto: TCP (jatkuu) 5.6 Vuonohjaus 5.7 TCP yhteyden hallinta 6. Ruuhkakontrollin periaatteet 6.1 Taustaa 6.2 Ruuhkakontrolliin syyt ja kustannukset 6.3 Ruuhkakontrolli: eri lähestymistapoja 6.4 Esimerkki verkkopohjaisesta ruuhkakontrollista: ATM ABR ruuhkakontrolli 7. TCP:n ruuhkakontrolli 7.1 Taustaa ja mekanismeja 7.2 Reiluus 6
0. Johdanto kuljetuskerros tarjoaa loogisen kommunikoinnin isäntäkoneilla ajettavien prosessien välille kuljetuskerroksen protokollia sovelletaan päätelaitteissa, ei Internetin reitittimissä lähteessä kuljetuskerros muuttaa saamansa sovellusdatan segmenteiksi, kohteessa päinvastoin Internetin reitittimet ohjaavat IP-paketteja niissä olevan osoitteen mukaan 7
Kuva 1. tuottaa loogisen yhteyden 8
1. Kuljetuskerroksen palvelut 1.1 Kuljetuskerroksen ja verkkokerroksen suhde 1.2 Internetin kuljetuskerroksesta 9
1.1 Kuljetuskerroksen ja verkkokerroksen suhde verkkokerros tarjoaa loogisen kommunikoinnin isäntäkoneiden välillä eri sovellukset voivat käyttää eri kuljetusprotokollien palveluja suuri osa kuljetuskerroksen protokollan palveluista riippuvaisia verkkokerroksen protokollan palveluista (viive, kaistanleveys) kuljetusprotokolla voi tarjota sovellukselle luotettavan tiedonsiirron, vaikka verkkokerroksen protokolla olisi epäluotettava 10
1.2 Internetin kuljetuskerroksesta TCP/IP-tietoverkoissa (esim. Internet) kaksi kuljetusprotokollaa: UDP: epäluotettava, yhteydetön tiedonsiirto; ja TCP: luotettava yhteyspohjainen tiedonsiirto. kuljetuskerroksen PDU (Protocol Data Unit, protokollatietoyksikkö) on segmentti IP (Internet Protocol, verkkokeroksen protokolla) tarjoaa parhaan yrityksen (tiedonvälitys)palvelun: se ei takaa datan perillemenoa, järjestystä eikä eheyttä IP on epäluotettava protokolla 11
Internetin kuljetuskerroksesta (2) UDP:n ja TCP:n tärkein tehtävä: laajentaa IP:n tarjoama isäntäkoneiden välinen tiedonsiirto isäntäkoneilla ajettavien prosessien väliseksi tiedonsiirroksi kyseessä on kuljetuskerroksen kanavointi ja kanavoinnin purku (multiplexing / demultiplexing) UDP ja TCP: prosessikohtainen datan jakelu ja datan eheys TCP lisäksi: luotettava tiedonsiirto (tekniikat: vuonohjaus, järjestysnrot, kuittaukset, ajastimet) ja ruuhkanhallinta 12
2. Monikanavointi ja kanavoinnin purkaminen 2.1 Taustaa 2.2 Yhteydetön kanavointi 2.3 Yhteyspohjainen kanavointi 13
2.1 Taustaa kullakin prosessilla (osana verkkosovellusta) on (ainakin yksi) liitos (eli soketti): ovi, jota kautta data virtaa verkosta prosessiin ja takaisin jokaisellla soketilla yksikäsitteinen tunnistin, jonka muoto riippuu siitä, onko protokollana UDP vai TCP kanavointi: datalohkot kerätään eri liitoksista, segmentoidaan, varustetaan otsikolla ja välitetään verkkokerrokseen kanavoinnin purku: datasegmentit puretaan, otsikot poistetaan ja datalohkot ohjataan oikeaan liitokseen 14
Taustaa (2) liitos määrittyy lähdeportin ja kohdeportin avulla, jotka ilmoitetaan datasegmentissä porttinumero on 16-bittinen luku: 0 65535 0 1023 ovat ns. tunnettuja (eli kiinteitä) porttinumeroita, jotka on varattu tietyille sovellusprotokollille; (sovelluksen) palvelinpuoli kuuntelee yhteydenottoa tässä porttinumerossa numeroita >1023 voi käyttää itse rakennettuihin soveluksiin tunnetut porttinumerot: http://iana.org RFC 3232 15
Kuva 2. Monikanavointi ja kanavoinnin purkaminen 16
2.2 Yhteydetön kanavointi asiakassovellus luo soketin, jonka kautta prosessi lähettää ja vastaanottaa dataa palvelinprosessilta kuljetuskerros lisää UDP-liittimeen porttinumeron joko automaattisesti tai prosessin toimesta mikäli kyseessä on sovellus, jolla on (tavall. palvelinpuolella) kiinteä porttinumero, sitä käytetään asiakaspuolella kulj.kerros tavallisesti liittää porttinron kohteen IP-osoite ja kohdeportin numero [pari (kohteen IPosoite,kohdeportti)], määrittää kohteen UDP-liittimen yksikäsitteisesti lähdeportin numero kertoo vastaanottajalle sen, mihin porttiin vastataan 17
Kuva 3. Lähde- ja kohdeportien vaihtuminen 18
2.3 Yhteyspohjainen kanavointi TCP-soketin määrittää nelikkö (lähteen IP-osoite, lähdeportti, kohdeportti, kohteen IP-osoite) asiakassovellus luo soketin, jonka kautta prosessi lähettää ja vastaanottaa dataa palvelinprosessilta TCP-serverisovelluksella on tervetuliaisportti, joka odottaa yhteydenperustamispyyntöjä TCPasiakassovelluksilta yhteydenperustamispyyntö on TCP-segmentti, jossa on kohdeporttinro ja TCP-otsikon yhteydenperustamisbitin (SYN-bitin) arvo yksi 19
Yhteyspohjainen kanavointi (2) kun palvelin vastaanottaa yo. segmentin, se tunnistaa prosessin, joka odottaa ko. ja välittää yhteyspyynnön prosessille serveriprosessi hyväksyy yhteyden ja luo liitoksen (yhteysliitos) kommunikointia varten serveri huomioi yhteydenperustamissegmentistä soketin määrittävän nelikön 20
Kuva 4. Kaksi asiakasta käyttää samaa palvelinsovellusta 21
3. Yhteydetön tiedonsiirto: UDP 3.1 Taustaa 3.2 UDP:n segmentin rakenne 3.3 UDP:n tarkistussumma 22
3.1 Taustaa pelkistetty kuljetusprotokolla (RFC 768), kanavoinnin ja kevyen virheentarkastuksen lisäksi ei muita palveluja sovellus keskustelee lähes suoraan IP:n kanssa UDP ottaa viestin sovellusprosessilta, jakaa segmentteihin, lisää lähde- ja kohdeportin numerot (kanavointia ja sen purkua varten), lisää pari muuuta kenttää ja toimittaa tuotteen verkkokerrokselle IP kaplesloi segmentin IP-paketiksi ja tekeee parhaansa toimittaakseen tietosähkeen määränpäähänsä kohteessa UDP lukee kohdeportin numeron, riisuu osoitetiedot ja toimitaa datan oikealle sovellukselle 23
Taustaa (2) ei kädenpuristusta: UDP on yhteydetön Miksi UDP ei yhteydenperustamista ei yhteyden tilatietoja ei pitkiä otsikoita sovellus kontrolloi mitä dataa lähetetään ja milloin, sovellus voi jopa vastata luotettavasta tiedonsiirrosta sopii yksinkertaisiin ja reaaliaikasovelluksiin, jotka sietävät jonkin verran datahävikkiä sopii (periodisiin) päivitys ja verkonhallintasovelluksiin 24
Kuva 5. Internet-sovelluksia ja niiden kuljetusprotokollia TCP TCP 25
3.2 UDP-segmentin rakenne UDP-segmentin kentät lähdeportin numero (source port number), 16 bittiä kohdeportin numero (destination port number), 16 bittiä pituus (length), 16 bittiä ilmoittaa UDP-segmentin pituuden tavuina (otsikko mukaanlukien) tarkistussumma (check sum), 16 bittiä; vastaanottaja tarkistaa, onko data turmeltunut 26
Kuva 6. UDP-segmentti 27
3.3 UDP:n tarkistussumma Tarkistussumman määrittäminen lähteen UDP 1. laskee yhteen kaikki UDP-segmentin 16-bittiset sanat (tarkistussummakenttää lukuunottamatta), ylivuoto edessä kiertää loppuun 2. ottaa summasta bittikohtaisen komplementin 3. kirjoittaa tuloksen UDP-otsikon tarkistussummakenttään 28
UDP:n tarkistussumma (2) kohteen UDP 1. suorittaa saman laskutoimituksen kuin lähde yllä 1. kohdassa 2. laskee tuloksen bittikohtaisesti yhteen tarkistussumma-kentässä olevan arvon kanssa 3. mikäli tuloksena on pelkkiä ykkösiä, virhettä ei ole tapahtunut UDP ei virheen sattuessa suorita korjaustoimenpiteitä; tavallisesti korruptoitunut segmentti hylätään, joissakin tapauksissa virheelliset segmentit toimitetaan sovellukselle varoituksella varustettuna 29
4. Luotettavan tiedonsiirron periaatteet 4.1 Taustaa 4.2 Luotettavan tiedonsiirtoprotokollan rakentaminen 4.3 Luotettavat tideonsiirtoprotokollat ja putkikuljetus 4.4 Go-Back-N (GBN) 4.5 Valikoiva toisto (Selective Repeat, SR) 30
4.1. Taustaa luotettava tiedonsiirto tietoverkkojen tärkein ongelma luotettava tiedonsiirto: dataa ei turmellu eikä häviä ja se toimitetaan perille oikeassa järjestyksessä tarkastellaan yksisuuntaista (unidirectional) tiedonsiirtoa lähettäjältä vastaanottajalle; kaksisuuntainen tiedonsiirto (bidirectional) vaikeampi mallintaa käytetään asteittain tarkentuvaa tilatransitiomallia protokollan ominaisuuksien kuvaamiseen puhutaan (tieto)paketista segmentin sijasta; tarkastelu on yleisellä tasolla ja sitä voidaan soveltaa kaikkiin tietoverkkoihin 31
Kuva 7. Luotettava tiedonsiirto 32
4.2 Luotettavan tiedonsiirtoprotokollan rakentaminen Oletetaan aluksi, että tiedonsiirtokanava on täysin luotettava: pakettihävikkiä ei ole, pakettien sisältö ei muutu, ei tarvita vuonohjausta eikä ruuhkakontrollia (protokolla rdt1.0) Kumpaakin osapuolta (lähettäjä, vastaanottaja) voidaan kuvata yksitilaisella tilataransitiomallilla eli äärellisellä automaatilla (Finite State Machine, FSM). FSM koostuu äärellisestä määrästä tiloja ja transitioita (tilanmuutoksia). Tiloja kuvataan ympyröillä ja transitioita nuolilla. Transitio muodostuu syötteestä (merkkijono, joka voidaan tulkita viestiksi, pyynnöksi, toimenpiteeksi jne...) ja tulosteesta (merkkijono, joka voidaan tulkita kuten syötekin, vistiksi, pyynnöksi toimenpiteeksi, jne...) 33
Äärellinen automaatti: FSM FSM on koko toimintansa ajan jossakin tilassa kun FSM, jossakin tilassa ollessaan, saa (hyväksyttävää muotoa olevan) syötteen, se vaihtaa tilaa tai pysyy samassa tilassa (kuvataan nuolella) tulostaa jotakin (voi olla esim tyhjä sana ) transitio (tilanmuutos) kuvataan nuolella, joka nimetään syötteellä (viivan yläpuolella oleva merkkijono) ja tulosteeella (viivan alapuolella oleva merkkijono) tulkinta: tietyssä tilassa tuleva syöte aiheuttaa tilanmuutoksen ja tulostuksen; uusi tila ja tuloste riippuu siten FSM:n aikaisemmasta tilasta ja syötteestä FSM:n alkutilaa merkitään katkonuolella 34
Kuva 8 Täysin luotettava kanava (rdt1.0) 35
rdt_send(data) packet = make_pkt(data) udt_send(packet) rdt_rcv(rcvpkt) extrack(packet,data) deliver_data(data) Odota kutsua ylhäältä Odota kutsua alhaalta rdt1.0: lähettäjä rdt1.0: vastaanottaja 36
Luotettava tiedonsiirtoprotokolla: pakettien sisältö voi muuttua Realistisemmassa mallissa (protokolla rdt2.0) oletetaan, että pakettien sisältö voi muuttua (bitit voivat korruptoitua). Tarvitaan vastaanottajan kuittauksia (positiivisia ja /tai negatiivisia), jotta lähde voi lähettää korruptoituneen paketin uudelleen. Protokolla on ARQ-tyyppinen (Automatic Repeat request). ARQ-protokollan toimintoja virhekontrolli (tarkistussumma, lähettäjä muodostaa, vastaanottaja tarkastaa) vastaanottajan palaute: positiivinen kuittaus (ACK, ACKnowledgment), negatiivinen kuittaus (NAK, Negative AcKnowledgment); kuittaus voi olla vain yhden bitin mittainen pakettien uudelleenlähetys: negatiivisen kuittauksen saatuaan lähettäjä toimittaa paketin uudelleen vastaanottajalle 37
Kuva 9 Kanava, jossa data voi korruptoitua (rdt2.0) 38
rdt_send(data) sndpkt=make_pkt(data,checksum) udt_send(sndpkt) Odota kutsua yläpuolelta Odota ACK- tai NACKviestiä rdt2.0: lähettäjä rdt_rcv(rcvpkt) && isack(rcvpkt) rdt_rcv(rcvpkt) && isnack(rcvpkt) udt_send(sndpkt) 39
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Odota kutsua alhaalta rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extrackt(rcvpkt,data) deliver_data(data) udt_send(ack) rdt2.0: vastaanottaja 40
Luotettava tiedonsiirtoprotokolla: kuittauspaketit voivat korruptoitua Protokolla, joka odottaa kuittausta ennen seuraavan paketin lähettämistä (kuten rdt2.0) on pysähdy-ja-odota protokolla (stop-and-wait protocol). Entä jos kuittauspaketti korruptoituu? Tällöin lähettäjä ei tiedä, onko vastaanottaja saanut datan asianmukaisesti. Kuittauspaketin ollessa turmeltunut lähettäjä voi pyytää toistoa (voi aiheuttaa rajattoman pyyntöketjun) lisätä pakettiin redundanssia ja käyttää virheenkorjaavaa koodausta lähettää automaattisesti datapaketin uudestaan; tarvitaan järjestysnumerointi, josta vastaanottaja tietää että kyse on uusinnasta. 41
Luotettava tiedonsiirtoprotokolla: kuittauspaketit voivat korruptoitua Valitaan kolmas ratkaisu: lähetetään paketti automaattisesti uudelleen, jos kuittauspaketti on korruptoitunut. Ratkaisu vaatii sen, että jokaisessa datapaketissa on järjestysnumero, jotta vastaanottaja tietää, onko kyseessä on uudelleenlähetys vai uusi paketti. Lisätään pakettiin uusi kenttä, johon lähettäjä kirjoittaa paketin järjestysnumeron. Koska kyseessä pysähdy-ja-odota protokolla, on yhden bitin järjestysnumero riittävä. Koska paketteja ei katoa, kuittauspaketeihin ei tarvitse lisätä datapaketin järjestysnumeroa. (protokolla rdt2.1) 42
Kuva 10 Kanava, jossa mikä tahansa paketti voi korruptoitua: lähettäjä (rdt2.1) 43
Kuva 11 Kanava, jossa mikä tahansa paketti voi korruptoitua: vastaanottaja (rdt2.1) 44
rdt_send(data) sndpkt=make_pkt(0, data,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isnak(rcvpkt)] udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt)] Odota kutsua 0 ylhäältä Odota ACK- tai NAKviestiä 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt)] rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isnak(rcvpkt)] udt_send(sndpkt) rdt2.1: lähettäjä Odota ACK- tai NAKviestiä 1 Odota kutsua 1 ylhäältä rdt_send(data) sndpkt=make_pkt(1, data,checksum) udt_send(sndpkt) 45
rdt_rcv(rcvpkt) && corrupt(rcvpkt) sndpkt=make_pkt(nak,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack,checksum) udt_send(sndpkt) Odota viestiä 0 alhaalta Odota viestiä 1 alhaalta rdt_rcv(rcvpkt) && corrupt(rcvpkt) sndpkt=make_pkt(nak,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt=make_pkt(ack,checksum) udt_send(sndpkt) rdt2.1: vastaanottaja rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt=make_pkt(ack,checksum) udt_send(sndpkt) 46
Luotettava tiedonsiirtoprotokolla: käytetään vain ACK - kuittausta Jos kuittauspakettiin lisätään hyväksymiskenttä, tarvitsee käyttää vain ACK-tyyppisiä kuittauspaketteja; NAK-paketin sijasta vastaanottaja lähettää ACK-paketin, jossa hyväksymiskentässä on viimeisen vahingoittumattomana vastaanotetun datapaketin järjestysnumero. (protokolla rdt2.2) Saadessaan kaksi samaa pakettia koskevaa kuittausta lähettäjä tietää, että vastaanottaja ei ole saanut asianmukaisesti sitä paketttia, joka seurasi kahdesti kuitattua pakettia. 47
Kuva 12 Kanava, jossa mikä tahansa paketti voi turmeltua, kaksinkertainen ACK-viesti: lähettäjä (rdt2.2) 48
Kuva 13 Kanava, jossa mikä tahansa paketti voi turmeltua, kaksinkertainen ACK-viesti: vastaanottaja (rdt2.2) 49
rdt_send(data) sndpkt=make_pkt(0, data,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isack(rcvpkt,1)] udt_send(sndpkt) Odota kutsua 0 ylhäältä Odota ACKviestiä 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1)] rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0)] rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isack(rcvpkt,0)] udt_send(sndpkt) Odota ACKviestiä 1 Odota kutsua 1 ylhäältä rdt_send(data) sndpkt=make_pkt(1, data,checksum) udt_send(sndpkt) rdt2.2: lähettäjä 50
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, 0,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && [corrupt(rcvpkt) has_seq0(rcvpkt)] udt_send(sndpkt) Odota viestiä 0 alhaalta Odota viestiä 1 alhaalta rdt_rcv(rcvpkt) &&[ corrupt(rcvpkt) has_seq1(rcvpkt)] udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, 1,checksum) udt_send(sndpkt) rdt2.2: vastaanottaja 51
Luotettava tiedonsiirtoprotokolla: paketit voivat sekä kourruptoitua että kadota Oletetaan lopulta, että paketit voivat sekä korruptoitua että niitä myös voi kadota. Herää kaksi kysymystä: miten pakettihävikki havaitaan; ja pakettihävikistä toivutaan. Jälkimmäiseen kysymykseen löytyy ratkaisu jo esillä olleilla tekniikoilla: tarkistussummat, järjestysnumerot, ACK paketit ja uudelleenlähetykset. Ensimmäisen kysymyksen ratkaisemiseksi tarvitsemme protokollaan uusia mekanismeja. Teemme seuraavan valinnan: vastuu pakettihävikin havaitsemisesta ja siitä toipumisesta on lähettäjällä. 52
Luotettava tiedonsiirtoprotokolla: paketit voivat sekä kourruptoitua että kadota (2) Jos joko datapaketti tai sen kuittauspaketti häviää, lähettäjä ei saa tietoa datapaketin perillemenosta. Datapaketti täytyy lähettää uudelleen. Kuinka kauan pitää odottaa? Odotusaikaa vaikea arvioida, sen täytyy olla ainakin yhden RTT:n suuruinen (Round Trip Time, RTT on se aika, joka paketilta kuluu siirtyä lähettäjältä vastaanottajalle ja takaisin lähettäjälle). Käytännössä lähettäjä valitsee järkevän odotusajan: jos kuittausta ei kuulu sen kuluessa, paketin lähetys uusitaan. On mahdollista, että vastaanottajalle saapuu sama paketti kahteen kertaan; järjestysnumero auttaa tunnistuksessa. 53
Luotettava tiedonsiirtoprotokolla: paketit voivat sekä kourruptoitua että kadota (3) Lähettäjän kannalta uudelleenlähetys on ratkaisu kaikkiin ongelmiin, data- tai kuittauspaketin katoamiseen tai myöhästymiseen. Tarvitaan ajastin ilmoittamaan uudelleenlähetyksestä. Lähettäjän on kyettävä (i) käynnistämään ajastin; (ii) reagoimaan hälytykseen; ja (iii) pysäyttämään ajastin. Miten lähettäjälle välittyy tieto siitä, koskeeko kuittaus viimeksi lähetettyä datapakettia vai jotain aikaisempaa? Vastaus: kuittauspaketin hyväksymiskentässä olevan (viimeiseksi vahingoittumattomana vastaanotetun) datapaketin järjestysnumeron avulla; sen sisältö kertoo lähettäjälle mitä datapakettia kuittaus koskee. (protokolla rdt3.0). 54
Kuva 14 Kanava, jossa mikä tahansa paketti voi korruptoitua tai hävitä : lähettäjä (rdt3.0) 55
rdt_rcv(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1)] stop timer rdt_send(data) sndpkt=make_pkt(0, data,checksum) udt_send(sndpkt) start timer Odota kutsua 0 ylhäältä Odota ACKviestiä 0 rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isack(rcvpkt,1)] timeout udt_send(sndpkt) start timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0)] stop timer timeout udt_send(sndpkt) start timer Odota ACKviestiä 1 Odota kutsua 1 ylhäältä rdt_rcv(rcvpkt) && [corrupt(rcvpkt) isack(rcvpkt,0)] rdt3.0: lähettäjä rdt_send(data) sndpkt=make_pkt(1, data,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) 56
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, 0,checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && [corrupt(rcvpkt) has_seq0(rcvpkt)] udt_send(sndpkt) Odota viestiä 0 alhaalta Odota viestiä 1 alhaalta rdt_rcv(rcvpkt) &&[ corrupt(rcvpkt) has_seq1(rcvpkt)] udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, 1,checksum) udt_send(sndpkt) rdt3.0: vastaanottaja 57
Kuva 15 Protokollan rdt3.0 toiminta 58
4.3 Putkikuljetus Ongelma: Pysähdy-ja-odota protokolla on käytännössä liian hidas; kanavan käyttöaste (lähettäjän puolelta) jää pieneksi. Ratkaisu: putkikuljetus (pipelining), kanavaan voidaan lähettää useita datapaketteja odottamatta kuittausta. Putkikuljetus asettaa uusia vaatimuksia protokollallle: järjestysnumeroiden lukumäärää lisättävä; kaksi ei enää riitä, kuittaamattomia paketteja on enemmän kuin yksi sekä lähettäjän että vastaanottajan täytyy puskuroida paketteja; lähettäjän ainakin se määrä, joka on lähetetty, mutta ei vielä kuitattu 59
Kuva 16 Pysähdy ja odota versus putkikuljetusprotokolla 60
Kuva 17 Pysähdy ja odota versus putkikuljetuslähetys 61
Lähettäjän kanavan käyttöaste L = paketin pituus bitteinä R = kanavan välitysaste välitysviive d trans = L / R U sender = lähettäjän kanavan käyttöaste U L/ R sender RTT L/ R 62
Putkikuljetuksen toteuttaminen Järjestysnumerojen määrä ja puskurikoko riippuu tavasta, jolla turmeltuneita, kadonneita tai myöhästyneitä paketteja käsitellään. Kaksi periatteellista tapaa toteuttaa putkikuljetus: GBN (Go-Back-N) SR (Selective Repeat, valikoiva toisto) 63
4.4 Go-Back-N lähettäjä voi toimittaa verkkoon korkeintaan N pakettia kuittausta odottamatta; N on ikkunakoko, GBN on liukuvan ikkunan protokolla (liukuvaa ikkunaa käytetään myös vuonohjauksessa ja ruuhkakontrollissa) järjestysnumerot ovat välillä [0,N-1]; järjestysnumerokenttä paketin otsikossa GBN-lähettäjän täytyy vastata kolmenlaisiin tapahtumiin. Yläkerroksen datan vastaanotto. Lähettäjä tarkastaa, onko ikkuna täysi eli onko kuittaamattomia paketteja N kpl jos ikkuna ei ole täysi, paketti luodaan ja lähetetään; ja jos ikkuna on täysi, paketti palautetaan yläkerrokseen. ACK-viestin vastaanotto. GBN käyttää kumulatiivista kuittausta; lähettäjä tietää, että saadessaan kuittauksen paketista n, kaikki paketit numeroon n saakka, paketti n mukaanlukien, on asianmukaisesti vastaanotettu. 64
Go-Back-N (2) GBN-lähettäjän täytyy vastata... (jatkuu): Aikamerkki (timeout). GBN käyttää ajastinta pakettihävikistä toipumiseen. Ajastimen hälyttäessä lähettäjä lähettää uudelleen kaikki aikaisemmin toimitetut paketit, joita ei vielä ole kuitattu ja käynnistää ajastimen uudelleen. Ajastin käy vanhimmalle lähetetylle, mutta kuittaamattomalle paketille. Vastaanotettuaan ACK paketin, lähettäjä käynnistää ajastimen uudestaan, jos puskurissa on lähetettyjä, mutta kuittaamattomia paketteja; ja pysäyttää ajastimen, jos kuittaamattomia paketteja ei ole Huom. GBN-lähettäjän ikkuna liukuu eteenpäin, kun joku ikkunassa oleva lähetetyksi merkitty paketti tulee kuitatuksi. 65
Kuva 18 GBN: lähettäjän puskuri 66
Go-Back-N (3) Vastaanottajan toiminta GBN-protokollassa on yksinkertainen jos vastaanottaja saa paketin n turmeltumattomana ja oikeassa järjestyksessä (edellinen hyväksytty paketti oli järjestysnumeroltaan n-1), vastaanottaja kuittaa paketin n viestillä ACK ja luovuttaa sen ylemmälle kerrokselle; vastaanottaja ei puskuroi paketteja kaikissa muissa tapauksissa vastaanottaja hylkää paketin ja lähettää ACK-kuittauksen viimeisimmästä asiallisesti (turmeltumattomana ja järjestyksessä) perilletulleesta paketista GBN:ssä vastaanottaja hylkää epäjärjestyksessä tulevat paketit; jos paketti n katoaa (ja n +1 saapuu perille ja hylätään), sekä paketti n että n +1 lähetetään myöhemmin uudelleen GBN:ssä lähettäjä ylläpitää kolmea ikkunaparametria (mitkä ne ovat?) ja vastaanottaja yhtä (mitä?) 67
Kuva 19 GBN toiminnassa (N = 4) 68
4.5 Valikoiva toisto (Selective Repeat, SR) GBN:n toiminnan heikkous: joskus lähetetään uudelleen paljon paketteja, osa turhaan SR-protokollan lähettäjä toimittaa paketin uudelleen vain jos arvelee sen joko turmeltuneen tai hävinneen vastaanottajan tiedottaa yksilöllisesti jokaisesta oikein vastaanotetuista paketeista lähettäjä voi toimittaa korkeintaan N pakettia kuittausta odottamattta, N on ikkunakoko, se rajoittaa kuittaamattomien ja epäjärjestyksessä olevien pakettien lukumäärää vastaanottaja kuittaa turmeltumattomana perille tulleen paketin olipa se järjestyksessä tai ei 69
Kuva 20 SR - puskurit 70
Valikoiva toisto (2) epäjärjestyksessä tulevat paketit puskuroidaan, puskuria päivitetään ja järjestykseen saadut paketit toimitetaan ylempään kerrokseen SR-protokollassa lähettäjällä ja vastaanottajalla ei aina ole sama kuva siitä, mitkä paketit on oikein vastaanotettu: ikkunat voivat olla erilaiset SR-lähettäjän tapahtumat ja toiminnot: yläkerroksen datan vastaanotto aikamerkki: jokaisella paketilla oma ajastin ACK-kuittauksen vastaanotto: jos paketti, jota kuittaus koskee, kuuluu ikkunaan, ikkunaa päivitetään ja tarvittaessa liu utetaan eteenpäin; ikkunaan mahdollisesti tulevat välittämistä odottavat paketit lähetetään 71
Kuva 22 SR - lähettäjän tapahtumat ja toiminnot 72
Valikoiva toisto (3) SR-vastaanottajan tapahtumat ja toiminnot: ikkunaan kuuluva paketti vastaanotetaan turmeltumattomana: lähetetään ACK-kuittaus; jos paketti ei ole uusinta, se puskuroidaan; puskuria päivitetään siirtämällä ikkunaa ja luovuttamalla dataa yläkerrokseen silloin kun se on mahdollista vastaanotetaan paketti, jonka järjestysnumero on välillä [ikkunan alalaita N, ikkunan alalaita -1]: lähetetään ACK-kuittaus (vaikka paketti on jo aikaisemmin kuitattu) muissa tapauksissa: hylätään paketti 73
Kuva 23 SR - vastaanottajan tapahtumat ja toiminnot 74
Kuva 21 SR-toiminnot (N = 4) 75
Liian suuri ikkuna SR:ssä: Onko 2. pkt0:n lähetys uusi paketti vai vanhan uusinta? Kohdan a ja b tapahtumat näkyvät vastaanottajalle samanlaisina. Ikkunakoko saa olla korkeintaan puolet järjestysnumeroavaruuden koosta. 76
Luotettava tiedonsiirto: yhteenveto mekanismeista ja niiden käytöstä mekanismi tarkistussumma ajastin järjestysnumero kuittaus negatiivinen kuittaus ikkuna, putkikuljetus käyttö ja kommentit virheiden havaitseminen paketeissa aikamerkki ja pakettien uudelleenlähetys; datapaketti tai sen kuittaus katosi kanavassa; vastaanottaja voi saada useita kopioita samasta datapaketista lähteestä kohteseen virtaavien datapakettien järjestyksen määrääminen; vastaanottaja havaitsee puuttuvat ja toistuvat paketit kohde ilmoittaa lähteelle, että datapaketti on asianmukaisesti saapunut perille; sisältää datapaketin järjestysnumeron kohde kertoo lähteelle, että datapakettia ei ole vastaanotettu kunnolla; sisältää tavalliseti sen paketin järjestysluvun, jota ei ole vastaanotettu asianmukaisesti lähde lähettää vain paketteja, joiden järjestysluku kuuluu ikkunaan; sallimalla useiden datapakettien lähettämisen ilman kuittauksen vastaanottoa voidaan lähteen hyötyastetta nostaa 77
5. Yhteyspohjainen tiedonsiirto: TCP 5.1 Taustaa 5.2 TCP yhteys 5.3 TCP segmentin rakenne 5.4 Kiertoviiveen arviointi ja aikamerkki 5.5 Luotettava tiedonsiirto 5.6 Vuonohjaus 5.7 TCP yhteyden hallinta 78
5.1. Taustaa Transmission Control Prorocol (TCP) Internetin kuljetuskerroksen yhteyspohjainen, luotettava tiedonsiirtoprotokolla perustuu turvallisen tiedonsiirron periaatteisiin: virheenkorjaukseen uudelleenlähetykseen (kumuloituviin) kuittauksiin ajastimiin vuonohjaukseen ruuhkakontrolliin määritelty RFC-dokumenteissa RFC 793, RFC 1122, RFC 1323, RFC 2018 ja RFC 2581 79
5.2 TCP-yhteys TCP on yhteyspohjainen: kolminkertainen kädenpuristus tilatietoja yhteydestä ylläpidetään tilamuuttujien avulla kaksisuuntainen (full duplex) tiedonsiirto; dataa virtaa lähteestä kohteeseen ja kohteesta lähteeseen yhtä aikaa pisteestä pisteeseen yhteys (point-to-point); ryhmälähetys (multicasting) ei mahdollinen TCP-yhteys perustetaan kolminkertaisella kädenpuristuksella; kun yhteys on perustettu, datan lähetys voi alkaa lähteessä prosessi lähettää dataa liitoksen (soketin) kautta lähetyspuskuriin 80
TCP-yhteys (2) lähetyspuskurin data segmentoidaan, MSS (Maximum Segment Size) ilmoittaa suurimman mahdollisen segmenttikoon tavuina (1460, 536 ja 512 tavua yleisimmät) kukin segmentti varustetaan otsikolla ja toimitetaan verkkokerrokseen kohteen kuljetuskerroksessa segmenttien otsikot riisutaan ja data sijoitetaan yhteyden vastaanottopuskuriin, josta prosessi sen lukee sekä asiakas- että palvelinprosessilla on oma lähetys- ja vastaanottopuskurinsa TCP-yhteys koostuu puskureista, muuttujista ja liittimistä yhteyden kummassakin päässä, isäntien välillä olevissa verkon osissa näitä elementtejä ei ole 81
Kuva 24 TCP:n lähetys- ja vastaanottopuskurit 82
5.3 TCP-segmentin rakenne TCP-segmentti koostuu otsikkokentistä ja datakentästä datakenttä sisältää lohkon sovellusdataa MSS rajoittaa segmentin kokoa suurta tiedostoa siirrettäessä segmentit (viimeistä lukuunottamatta) MSS:n kokoisia interaktiivisissa sovelluksissa (esim. Telnet) segmenttikoko usein pienempi kuin MSS (voi olla esim. yksi tavu) TCP-segmentin otsikkokenttä tyypillisesti 20 tavua (Telnetin segmentti voi siis olla vain 21 tavua) UDP- ja TCP-segmenteissä samoja kenttiä: lähdeportti, kohdeportti ja tarkistussumma 83
Kuva 25 TCP-segmentti 84
TCP-segmentin kentät Source port #: lähdeportin numero, yhteyden ottava portti; identifioi segmentin lähteen sovelluskerroksen prosessin (16 bittiä) Destination port #: kohdeportin numero, portti, johon yhteys otetaan; identifioi segmentin kohteen sovelluskerroksen prosessin (16 bittiä) Sequence number: järjestysnumero, jota käytetään varmistamaan saapuvan datan oikea järjestys; segmentin datakentän ensimmäisen tavun järjestysnumero (32 bittiä) Acknowledgement number: hyväksymis- eli kuittausnumero; lähettäjän seuraavana saapuvaksi odottaman TCP-tavun järjestysnumero (32 bittiä) Header length: otsikon pituus 32-bittisinä sanoina (4 bittiä) Unused: ei käytössä, asetettu arvoon 0 (6 bittiä) 85
TCP-segmentin kentät (2) Flag field: lippukenttä (6 bittiä) URG ilmoittaa, että segmentti sisältää dataa, jonka ylempi kerros on määritellyt kiireelliseksi ACK ilmoittaa, että hyväksymiskenttä sisältää sallitun hyväksymisnumeron; segmentti sisältää kuittauksen asianmukaisesti vastaanotetusta segmentistä PSH kehottaa kohdetta toimittamaan datan ylemmälle kerrokselle välittömästi RST hälyttää yhteyden ongelmista; vastaanottaja joutuu luomaan yhteyden uudestaan alusta SYN pyytää kohdettaa synkronoimaan järjestysnumerot FIN ilmoittaa kohteelle, että lähde on lopettanut tietojen lähettämisen 86
TCP-segmentin kentät (3) Receive window: vastaanottoikkuna; niiden tavujen lukumäärä, jotka lähettäjä suostuu hyväksymään, käytetään vuonohjauksessa (16 bittiä) Internet checksum: Internet tarkistussumma; otsikosta ja datakentästä laskettu tiiviste (16 bittiä) Urgent data pointer: pikaosoitin; kiireellisen datan viimeisen tavun sijainnin kertova luku (16 bittiä) Options: optiot; käytetään, kun lähettäjä ja vastaanottaja neuvottelevat MSS:n koosta; myös aikaleimaoptio on määritelty (vaihtelevanpituinen) Data: sovelluksen data (vaihtelevanpituinen) 87
Järjestys- ja kuittausnumerot tärkeimmät TCP-otsikon kentät TCP käsittelee dataa rakenteettomana, vaikkakin järjestettynä tavuvirtana (0,1,2,..., 2 32 1) järjestysnumero ilmoittaa segmentin ensimmäisen tavun paikan tavuvirrassa TCP-yhteys on kaksisuuntainen: A lähettää dataa B:lle ja odottaa dataa B:ltä saman TCP-yhteyden aikana hyväksymisnumero A:n TCP-segmentissä ilmoittaa sen tavun järjestysnumeron, jota A seuraavaksi odottaa B:ltä TCP soveltaa kumulatiivista kuittausta: hyväksymisnumero on B:n ensimmäinen tavu, joka ei vielä ole saapunut A:lle 88
Kuva 26 Datan jako TCP-segmenteiksi (MSS = 1000) 89
Kuva 27 Yksinkertaisen Telnet sovelluksen järjestys- ja kuittausnumerot 90
5.4 Kiertoviiveen arviointi ja aikamerkki Round-Trip Time (RTT) = kiertoviive, timeout = aikamerkki TCP käyttää aikamerkki- ja uudelleenlähetysmekanismia luotettavaan tiedonsiirtoon miten RTT määritetään? kuinka pian tulee segmentti lähettää uudelleen? kiertoviivettä arvioidaan kaavalla ArvioRTT := (1 α) ArvioRTT + α OtosRTT missä 0 < α < 1 on painokerroin ja OtosRTT on tietyin aikavälein mitattu otossegmentin RTT arvo kertoimen α suositusarvo on 0.125 (RFC 2988) 91
Kiertoviiveen arviointi ja aikamerkki (2) ArvioRTT on OtosRTT-arvojen painotettu keskiarvo, jossa viimeisimmät otosarvot korostuvat: kyseessä on eksponentiaalinen painotettu liikkuva keskiarvo (exponential weighted moving average, EWMA) ArvioRTT n = (1 α) ArvioRTT n 1 + α OtosRTT n = (1 α) 2 ArvioRTT n 2 + (1 α) α OtosRTT n 1 + α OtosRTT n =... = (1 α) n ArvioRTT 0 + (1 α) n 1 α OtosRTT 1 + (1 α) n 2 α OtosRTT 2 + + (1 α) α OtosRTT n 1 + α OtosRTT n 92
Kuva 28 Kiertoviiveotokset ja arviot 93
Kiertoviiveen hajonnan arviointi kiertoviiveen hajontaa arvioidaan kaavalla HajontaRTT n = (1 β) HajontaRTT n-1 + β OtosRTT n ArvioRTT n HajontaRTT n on pieni mikäli OtosRTT n :n ja ArvioRTT n :n ero on pieni kertoimen β suositusarvo on 0.25 (RFC 2988) segmentin uudelleenlähettämisaika saadaan kaavasta AikaVäli n = ArvioRTT n + 4 HajontaRTT n 94
5.5 Luotettava tiedonsiirto TCP rakentaa luotettavan tiedonsiirtopalvelun IP:n epäluotettavan parhaan yrityksen palvelun päälle TCP käyttää yhtä ajastinta lähetettyjen, mutta kuittaamattomien segmenttien uudelleenlähetykseen (RFC 2988) tarkastellaan yksinkertaistettua tilannetta, jossa A lähettää ison tiedoston B:lle seur. kalvo esittää yksinkertaista TCP-lähettäjää, jossa on kolme tärkeää datan (uudelleen)lähettämistä koskevaa tapahtumaa: sovelluksen datan vastaanotto, ajastimen aikamerkki ja ACK-viestin vastaanotto 95
Kuva 29 Yksinkertainen TCP-lähettäjä 96
Luotettava tiedonsiirto (2) edellä oletetaan, että vuonohjausta ei tarvitse ottaa huomioon ruuhkakontrollia ei tarvitse ottaa huomioon sovellusdatan koko < MSS tietoa siirretään vain yhteen suuntaan: lähteestä A kohteeseen B seur. kalvoilla kolme erilaista tilannetta hävinneen ACK-viestin aiheuttama uudelleenlähetys segmenttiä 100 ei lähetetä uudelleen kumulatiivinen kuittaus välttää 1. segmentin uudelleenlähetyksen 97
Kuva 30 Kadonneen ACK-viestin aiheuttama uudelleenlähetys 98
Kuva 31 Segmenttiä 100 ei lähetetä uudelleen 99
Kuva 32 Kumulatiivinen kuittaus: 1. segmenttiä ei lähetetä uudelleen 100
Aikavälin kaksinkertaistaminen muunnos tavanomaiseen TCP:n implementointiin kun ajastin hälyttää ja segmentti uudelleenlähetetään, AikaVäli-muuttujan arvo kaksinkertaistetaan kun ajastin käynnistetään joko saataessa dataa sovelluskerroksesta tai vastaanotettaessa ACK-viesti, AikaVäli-muuttujan arvo lasketaan kaavalla AikaVäli = ArvioRTT + 4 HajontaRTT aikavälin kaksinkertaistaminen mahdollistaa rajoitetun ruuhkakontrollin 101
Nopea uudelleenlähetys aikamerkin laukaiseman uudelleenlähetyksen ongelma: AikaVäli arvoltaan usein suuri ratkaisu: kaksinkertainen ACK-viesti kaksinkertainen ACK-viesti: hyväksymisviesti, joka kuittaa uudelleen jo vastaanotetun paketin lähettäjälle kaksinkertainen ACK-viesti kertoo, että vastaanottaja on saanut segmentin, jonka järjestysnumero on suurempi kuin sen segmentin, jota hän odottaa; vastaanottajan saamassa datavirrassa on aukko saatuaan kolme kaksinkertaista ACK-viestiä, lähettäjä toimittaa nopeutetussa tahdissa puuttuvat segmentit 102
Nopea uudelleenlähetys: paketti lähetetään uudelleen ennekuin ajastin hälyttää 103
TCP:n ACK-viestien generointi [RFC 1122, RFC 2581] 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 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 104
Onko TCP tyypiltään GBN vai SR protokolla? TCP kuittaukset kumulatiivisia, epäjärjestyksessä tulevaa dataa ei segmenttikohtaisesti kuitata; TCP-lähettäjän tarvitsee muistaa viimeisimmäksi lähetetyn, vielä kuittaamattoman tavun järjestysnumero; ja lähetysvuorossa oleva tavun järjestysnumero TCP muistuttaa GBN-protokollaa useat TCP implementaatiot puskuroivat epäjärjestyksessä tulevat, asianmukaisesti vastaanotetut segmentit; TCP ei liioin uudelleenlähetä useita segmenttejä kerrallaan TCP muistuttaa SR protokollaa johtopäätös: TCP on sekoitus GBN:stä ja SR:stä (hybridi) 105
5.6 Vuonohjaus estää lähettäjää aiheuttamasta vastaanottajalle puskuriylivuotoa huom. vuonohjaus ja ruuhkakontrolli ovat eri asioita TCP on kaksisuuntainen, joten molemmat osapuolet ylläpitävät (periaatteessa) samoja tilamuuttujia yksinkertaisuuden vuoksi oletetaan seuraavassa, että lähde A lähettää suuren tiedoston kohteelle B kohde B hylkää epäjärjestyksessä saapuvat paketit vastaanottajalle tärkeitä tilamuuttujia RcvBuffer RcvWindow LastByteRead ja LastByteRcvd RcvBuffer vastaanottopuskurin koko 106
Vuonohjaus (2) LastByteRead sen tavun järjestysnumero, jonka sovellus on viimeksi lukenut vastaanottopuskurista LastByteRcvd sen tavun järjestysnumero, joka viimeksi on saapunut ja joka on asetettu vastaanottopuskuriin RcvWindow = RcvBuffer (LastByteReceived LastByteRead) RcvWindow muuttuu dynaamisesti lähettäjälle tärkeitä tilamuuttujia LastByteSent viimeiseksi lähetetyn tavun järj. nro LastByteAcked viimeiseksi hyväksytyn tavun järj. nro LastByteSent LastByteAcked RcvWindow lähettäjä ylläpitää tietoa vastaanottajan RcvWindow -muuttujan arvostaa; tieto kulkee TCP-segmentin Receive windowkentässä 107
Kuva 33 Vastaanottoikkuna ja vastaaanottopuskuri LastByteReceived LastByteRead 108
5.7 TCP yhteyden ylläpito TCP yhteys perustetaan seuraavasti 1. Asiakas lähettää palvelimelle TCP SYN viestin, segmentin, jossa ei ole sovellusdataa SYN bitti on asetettu ykköseksi järjestysnumerokentässä on asiakkaan valitsema alkujärjestysnumero (client_isn) 2. Palvelin, saatuaan TCP SYN viestin, alustaa puskurit sekä yhteysmuuttujat ja lähettää asiakkaalle TCP SYNACK viestin, segmentin, jossa ei ole sovellusdataa SYN bitti on asetettu ykköseksi 109
TCP yhteyden ylläpito (2) järjestysnumerokentässä on palvelimen valitsema alkujärjestysnumero (server_isn) hyväksymiskentässä on luku client_isn + 1 3. Asiakas, vastaanotettuaan TCP SYNACK viestin, alustaa puskurit sekä yhteysmuuttujat ja lähettää palvelimelle TCP ACKviestin, segmentin, jossa voi sisältää sovellusdataa SYN bitti on asetettu nollaksi järjestysnumerokentässä on luku client_isn + 1 hyväksymiskentässä on luku server_isn + 1 Askeleessa 1 asiakas suorittaa yhteyden synkronoinnin, askeleessa 2 palvelin hyväksyy yhteyden ja synkronoi sen omasta puolestaan, askeleessa kolme asiakas vielä kuittaa perustetun yhteyden. 110
TCP yhteyden ylläpito (3) TCP yhteyttä perustettaessa suoritetaan n.s. kolminkertainen kättely myöhemmissä yhteyden dataa sisältävissä segmenteissä on SYN bitti asetettu nollaksi 111
Kuva 34 TCP yhteyden perustaminen 112
TCP yhteyden ylläpito (4) Kun TCP yhteys lopetetaan, puskurit ja datamuuttujat deallokoidaan. Olet., että asiakas haluaa lopettaa yhteyden. 1. Asiakas lähettää palvelimelle FIN viestin, segmentin, jossa ei ole sovellusdataa FIN bitti on asetettu ykköseksi 2. Palvelin lähettää asiakkaalle hyväksymisviestin FIN ACK 3. Palvelin lähettää asiakkaalle oman FIN viestinsä, segmentin, jossa ei ole sovellusdataa FIN bitti on asetettu ykköseksi 4. Asiakas lähettää palvelimelle hyväksymisviestin FIN ACK 113
Kuva 35 TCP yhteyden lopettaminen 114
Kuva 36 TCP asiakkaan toiminta tilakoneena 115
Kuva 37 TCP palvelimen toiminta tilakoneena 116
6. Ruuhkakontrollin periaatteet 6.1 Taustaa 6.2 Ruuhkakontrolliin syyt ja kustannukset 6.3 Ruuhkakontrolli: eri lähestymistapoja 6.4 Esimerkki verkkopohjaisesta ruuhkakontrollista: ATM ABR ruuhkakontrolli 117
6.1 Taustaa ruuhkakontrolli on kuljetuskerroksen ja sen protokollan palvelu koko tietoverkolle ruuhkaa syntyy, kun suuri määrä dataa täytyy kuljettaa yli kapasiteetiltaan rajoitetun verkon ruuhka johtaa puskuriylivuotoihin reitittimissä tarkastellaan ruuhkakontrollin yleisiä periaatteita esimerkkejä ruuhkan syntymisestä eri lähestymistapoja ruuhkanhallintaan 118
6.2 Ruuhkakontrollin syyt ja kustannukset seuraavassa tarkastellaan kolmea ruuhkakontrolliesimerkkiä esimerkit ovat kompleksisuudeltaan nousevassa suuruusjätjestyksessä kussakin esimerkissä pyritään analysoimaan sitä miksi ruuhka alunperin syntyy ja mitkä ovat sen kustannukset (resursseja jää käyttämättä, huono palvelu loppukäyttäjille) 119
Ruuhkan syntyminen. Esim. 1 Isäntäkone A lähettää dataa C:lle ja isäntäkone B lähettää dataa D:lle, välissä reititin, jossa äärettömät puskurit. Oletetaan että A:lla ja B:llä (vastaavasti C.llä ja D:llä) yhteinen linkki reitittimeen A:n ja B:n prosessit tarjoavat molemmat liittymänsä kautta kuljetuskerrokselleen dataa nopeudella λ in tavua sekunnissa, molempien kuljetuskerrokset välittävät dataa verkkokerrokseen samalla nopeudella λ in tavua/sek. linkkien kapasiteetit ovat R tavua/sek. reititin puskuroi kaiken datan, jota ei kykene lähettämään 120
Kuva 38 Ruuhkan syntyminen. Esim 1 121
Ruuhkan syntyminen. Esim. 1 (2) C:n ja D:n kuljetuskerrokset ottavat vastaan dataa verkkokerroksiltaan samalla nopeudella (merk. λ out ) kuin välittävät sitä prosesseilleen λ out on yhteyskohtainen (datan) läpivirtausnopeus Tässä tilanteessa yhteyskohtainen datan läpivirtausnopeus ei koskaan ole enempää kuin R/2 tavua/sek. λ out = λ in (0 λ in R/2); λ out = R/2 (λ in > R/2) keskim. viive kasvaa voimakkaasti, kun λ in R/2 Fakta 1. Jonotusviiveet kasvavat, kun pakettien tulonopeus lähestyy linkin kapasiteettia. 122
Kuva 39 Läpivirtausnopeus ja viive lähetysnopeuden funktiona. Esim. 1. 123
Ruuhkan syntyminen. Esim. 2 Isäntäkone A lähettää dataa C:lle, isäntäkone B lähettää dataa D:lle, välissä reititin, jossa äärelliset puskurit. Oletetaan, että reititin hylkää paketin mikäli puskuri on täynnä jokainen yhteys on luotettava: jos paketti hylätään, se lähetetään uudelleen A:n ja B:n prosessit tarjoavat liittymänsä kautta kuljetuskerroksilleen dataa nopeudella λ in tavua sekunnissa, molempien kuljetuskerrokset välittävät dataa verkkokerrokseen nopeudella λ in tavua/sek. C:n ja D:n kuljetuskerrokset ottavat vastaan dataa verkkokerroksiltaan samalla nopeudella (merk. λ out ) kuin välittävät sitä prosesseilleen; yhteyskohtainen datan läpivirtausnopeus on λ out tavua/sek. 124
Kuva 40 Ruuhkan syntyminen. Esim. 2 125
Ruuhkan syntyminen. Esim. 2 (2) Olet. aluksi (epärealistisesti), että A tietää etukäteen onko reitittimen puskureissa tilaa. Tällöin (Kuva 41a, ylempi käyrä) λ in = λ in yhteyskohtainen datan läpivirtausnopeus ei koskaan ole enempää kuin R/2 tavua/sek. λ out = λ in, kun 0 λ in R/2; λ in > R/2 ei mahdollinen Olet. sitten (edell. epärealistisesti), että paketti uudelleenlähetetään vain, kun se varmasti tiedetään kadonneeksi. Kuvan 41 käyrä b kuvaa tätä tilannetta. Fakta 2. Ruuhkaisessa verkossa lähettäjän täytyy suorittaa uudelleenlähetyksiä korvatakseen pakettihävikin, joka johtuu puskuriylivuodoista. 126
Ruuhkan syntyminen. Esim. 2 (3) Oletetaan vielä, että lähettäjällä on ajastin, joka hälyttää paketeista, jotka ovat viivästyneet, mutta eivät välttämättä kadonneet. Fakta 3. Reititin käyttää linkkikapasiteetia hyödyttömästi turhien pakettien lähettämiseen. Tilannetta luonnehtii Kuvan 41a alempi käyrä. 127
Kuva 41 Läpivirtausnopeus ja viive lähetysnopeuden funktiona eri tapauksissa. Esim. 2. 128
Ruuhkan syntyminen. Esim 3 Isäntäkoneet A ja C lähettävät dataa toisilleen, samoin isäntäkoneet B ja D. Oletetaan, että kaikilla isäntäkoneilla on ajastin- ja uudelleenlähetysjärjestelmä luotettavan tiedonsiirron toteuttamiseen linkkien kapasiteetit ovat R tavua sekunnissa reititin hylkää paketin mikäli puskuri on täynnä ja välittää paketteja periaatteella ensin tullutta palvellaan ensin (first-come-first-served, FCFS) jokainen yhteys on luotettava: jos paketti hylätään, se lähetetään uudelleen 129
Ruuhkan syntyminen. Esim 3 (2) isäntien prosessit tarjoavat liittymänsä kautta kuljetuskerroksilleen dataa samalla nopeudella λ in tavua/sek. ja isäntien kuljetuskerrokset välittävät dataa verkkokerroksilleen samalla nopeudella λ in tavua/sek. isäntien kuljetuskerrokset ottavat vastaan dataa verkkokerroksiltaan samalla nopeudella (merk. λ out ) kuin välittävät sitä prosesseilleen; yhteyskohtainen datan läpivirtausnopeus on λ out tavua/sek. Kuva 42 luonnehtii tätä tilannetta. 130
Kuva 42 Ruuhkan syntyminen. Esim. 3 131
Ruuhkan syntyminen. Esim 3 (3) Seuraavassa XY-yhteys tarkoittaa liikennettä isännältä X isännälle Y aina, kun X,Y {A,B,C,D} ja X Y. Selvästi AC-yhteys jakaa reitittimen R1 yhteyden DB kanssa ja reitittimen R2 yhteyden BD kanssa. Pienillä parametrin λ in arvoilla ei puskuriylivuotoja juurikaan tapahdu, läpivirtausnopeus λ out on suunnilleen λ in :n suuruinen; lisäys λ in :ssä johtaa lisäykseen λ out :ssa. Oletetaan, että λ in (ja siis myös λ in ) on suuri. Tarkastellaan reititintä R2. Isännän A dataa voi tulla reitittimeen R2 korkeintaan nopeudella R tavua/sek. 132
Ruuhkan syntyminen. Esim 3 (4) Pidetään mielessä, että reititin R2 välittää paketteja ensin tullutta palvellaan ensin periaatteella. Koska λ in on hyvin suuri kaikilla yhteyksillä, BD-yhteyden osuus R2:een tulevasta liikennevirrasta kasvaa suhteessa AC-yhteyden osuuteen. Rajalla, siis kun λ in, ACyhteydessä λ out 0. Fakta 4. Kun paketti hylätään jossakin polun reitittimessä, kaikki polun aikaisemmat reitittimet ovat tehneet turhaa työtä. 133
Kuva 43 Äärelliset puskurit, monta linkkiä Esim. 3 134
6.3. Ruuhkakontrolli: eri lähestymistapoja Kaksi käytännön lähestymistapaa päästä-päähän ruuhkakontrolli verkkokerros ei tue ruuhkakontrollia kuljetuskerros kontrolloi ruuhkan syntymistä ja päättelee sen olemassaolon tarkkailemalla verkkotoimintaa TCP:n soveltama verkkopohjainen ruuhkakontrolli verkkokerroksen komponentit (esim. reitittimet) välittävät lähettäjälle tietoa verkon ruuhkatilanteesta Verkkopohjaisessa ruuhkakontrollissa on kaksi tapaa välittää ruuhkaa koskevaa tieto lähettäjälle (kuva 44). 135
Kuva 44 Verkkokerros tiedottaa ruuhkasta; kaksi reittiä 136
7. TCP:n ruuhkakontrolli 7.1 Taustaa ja mekanismeja 7.2 Reiluus 137
7.1 Taustaa ja mekanismeja TCP:n ruuhkakontrollimekanismi on päästä-päähän tyyppiä vähentää datan lähetysastetta ruuhkamäärän funktiona Herää kolme kysymystä miten TCP saa selville sen, että lähteen ja kohteen välillä on ruuhkaa miten TCP rajoittaa datan lähetysastetta mitä algoritmia TCP käyttää lähetysasteen muuntamisessa Seuraavassa oletetaan, että lähettäjä toimittaa vastanottajalle suuren tiedoston. 138
Lähetysasteen rajoittaminen Aikaisemmin todettiin, että TCP-yhteyden molemmissa päissä on vastaanotto- ja lähetyspuskuri ja ne pitävät yllä useita tilamuuttujia (RcvBuffer, RcvWindow, LastByteRead, LastByteRcvd, LastByteSent ja LastByteAcked). Näiden lisäksi molemmat päät ylläpitävät ruuhkaikkunaa (CongWin), joka rajoittaa astetta, jolla dataa voidaan verkkoon toimittaa. Kuittaamattoman datan määrä ei voi olla suurempi kuin pienempi luvuista CongWin, RcvWin : LastByteSent LastByteAcked min{congwin, RcvWin}. Olet. seur. että aina CongWin RcvWin. Datan lähetysaste on karkeasti CongWin/RTT tavua sekunnissa. 139
Ruuhkan selvillesaanti Hävikkitapahtuma on (lähettäjän) ajastimen hälytys kolmen kaksinkertaisen ACK-viestin vastaanotto Kun verkossa on ruuhkaa, reitittimissä tapahtuu puskuriylivuotoja ja paketteja häviää (hylätään). Hävinneet paketit aiheuttavat hävikkitapahtumia lähetyspäässä. Lähettäjä ymmärtää, että verkossa on ruuhkaa. Kun verkossa ei ole ruuhkaa, kuittaukset tulevat ajallaan ja hävikkitapahtumia ei satu, TCP kasvattaa ruuhkaikkunan kokoa. Ruuhkaikkunan koon kasvunopeus riippuu kuittausviestien saapumisnopeudesta, TCP on itsekellottuva. 140
TCP:n ruuhkakontrollialgoritmi Algoritmi koostuu kolmesta pääkomponentista additiivisesta lisäämisestä, multiplikatiivisesta vähentämisestä ; hitaasta alusta ; ja hävikkitapahtumiin reagoinnista Additiivinen lisääminen, multiplikatiivinen vähentäminen TCP kontrolloi ruuhkaa vähentämällä ruuhkaikkunan CongWin kokoa. TCP soveltaa multiplikatiivista vähentämistä: CongWin muuttujan arvo puolitetaan hävikkitapahtuman sattuessa. Muuttujan CongWin arvo ei saa mennä alle yhden MSS:n (segmentin maksimikoko). 141
TCP:n ruuhkakontrollialgoritmi (2) TCP lisää lähetysastetta ruuhkan helpottaesa: muuttujan CongWin arvoa lisätään yhdellä MSS:llä RTT:ssä jos hävikkitapahtumia ei satu. TCP soveltaa additiivista lisäämistä. TCP:n ruuhkankontrolli käyttää AIMD-algoritmia (Additive Increase Multiplicative Decrease). Lineaarinen lähetysasteen lisäys heijastaa ruuhkan välttämistä. 142
Kuva 45 AIMD algoritmin toiminta Muuttujan CongWin arvo kasvaa lineaarisesti (kun kuittauksia saapuu) ja putoaa yhtäkkiä puoleen (kun hävikkitapahuma sattuu); toiminta on syklistä. 143
TCP:n ruuhkankontrollialgoritmi (3) Hidas alku (nopea kiihdytys) TCP-yhteyden alkaessa muuttujan CongWin arvo on yksi MSS. Yhteyden alussa TCP lisää lähetysastetta kaksinkertaistamalla CongWin muuttujan arvon yhdessä RTT:ssä kunnes hävikkitapahtuma sattuu. TCP lähettää ensimmäisen segmentin verkkoon ja odottaa sen kuittausta. Kuittauksen tultua TCP kasvattaa ruuhkaikkunaa kahdeksi MSS:ksi ja lähettää kaksi maksimikokoista segmenttiä verkkoon. Jos nämä kuitataan, TCP kasvattaa ruuhkaikkunan koon 4 MSS:ksi, lähettää neljä segmenttiä verkkoon jne... 144
Kuva 46 TCP:n hidas aloitus 145
TCP:n ruuhkankontrollialgoritmi (4) Aikamerkkitapahtumiin reagointi Todellisuudessa TCP:n ruuhkakontrolli reagoi eri tavalla (1) ajastimen hälytykseen ja (2) kolmen kaksinkertaisen ACKviestin vastaanottoon. Vastaanottaessaan kolme kaksinkertaista ACK-viestiä TCP käyttäytyy kuten edellä kuvattiin; ruuhkaikkuna puolitetaan ja sen kokoa kasvatetaan vähitellen. Ajastimen hälyttäessä TCP asettaa ruuhkaikkunan arvoksi yhden MSS:n ja sen jälkeen kasvattaa sen kokoa eksponentiaalisesti kunnes CongWin muuttujan arvo on puolet siitä mitä se oli ennen ajastimen hälyttämistä. Tämän jälkeen CongWin kasvaa lineaarisesti kuten on edellä on kuvattu. 146
TCP congestion control FSM: overview hävikki: aikamerkki hidas aloitus cwnd > ssthresh hävikki: aikamerkki ruuhkan välttäminen hävikki: 3dupACK hävikki: aikamerkki uusi ACK hävikki: 3dupACK nopea toipuminen 147
TCP ruuhkanhallinta FSM: yksityiskohdat L cwnd = 1 MSS ssthresh = 64 KB dupackcount = 0 aikamerkki ssthresh = cwnd/2 cwnd = 1 MSS dupackcount = 0 lähetä puuttuva segmentti duplicate ACK dupackcount++ hidas aloitus dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3 lähetä puuttuva segmentti uusi ACK cwnd = cwnd+mss dupackcount = 0 lähetä uudet segmentit sallit. rajoissa cwnd > ssthresh L aikamerkki ssthresh = cwnd/2 cwnd = 1 MSS dupackcount = 0 lähetä puuttuva segmentti timeout ssthresh = cwnd/2 cwnd = 1 dupackcount = 0 lähetä puuttuva segmentti nopea toipuminen New ACK cwnd = ssthresh dupackcount = 0 new ACK cwnd = cwnd + MSS (MSS/cwnd) dupackcount = 0 lähetä uudet segmentit sallit. rajoissa ruuhkan välttäminen. duplicate ACK dupackcount++ dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3 lähetä puuttuva segmentti duplicate ACK cwnd = cwnd + MSS lähetä uudet segmentit sallit. rajoissa 148