internet ja tietoverkot 811338a 3 kuljetusprotokollat ... · pdf fileisnack(rcvpkt)_____...

Internet ja tietoverkot 811338A

3 Kuljetusprotokollat Luotettava ja epäluotettava tiedonsiirto

Oulun yliopisto

Tietojenkäsittelytieteiden laitos

Periodi 3 2014 / 2015

Kuljetuskerros

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).

Periodi 3

2014 / 2015

2 Internet ja tietoverkot

Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Mitä käsitellään? (2)

0. Johdanto


1.1 Kuljetuskerroksen ja verkkokerroksen suhde

1.2 Internetin kuljetuskerroksesta


2.1 Taustaa

2.2 Yhteydetön kanavointi

2.3 Yhteyspohjainen kanavointi


3.1 Taustaa

3.2 UDP:n segmentin rakenne

3.3 UDP:n tarkistussumma

Periodi 3

2014 / 2015


Kuljetuskerros



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.1 Taustaa

5.2 TCP – yhteys

5.3 TCP – segmentin rakenne

5.4 Kiertoviiveen arviointi ja aikamerkki

5.5 Luotettava tiedonsiirto

Periodi 3

2014 / 2015


Kuljetuskerros


5. Yhteyspohjainen tiedonsiirto: TCP (jatkuu)

5.6 Vuonohjaus

5.7 TCP – yhteyden hallinta


6.1 Taustaa

6.2 Ruuhkakontrolliin syyt ja kustannukset

6.3 Ruuhkakontrolli: eri lähestymistapoja

6.4 Esimerkki verkkopohjaisesta ruuhkakontrollista: ATM ABR –

ruuhkakontrolli


7.1 Taustaa ja mekanismeja

7.2 Reiluus

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 1. Kuljetuskerros tuottaa loogisen yhteyden

Periodi 3

2014 / 2015


Kuljetuskerros




Periodi 3

2014 / 2015


Kuljetuskerros


• 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

Periodi 3

2014 / 2015


Kuljetuskerros


• 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

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros


2.1 Taustaa



Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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ä) porttinume-

roita, 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 2. Monikanavointi ja kanavoinnin purkaminen

Periodi 3

2014 / 2015


Kuljetuskerros


• 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 IP-

osoite,kohdeportti)], määrittää kohteen UDP-liittimen

yksikäsitteisesti

• lähdeportin numero kertoo vastaanottajalle sen, mihin

porttiin vastataan

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 3. Lähde- ja kohdeportien vaihtuminen

Periodi 3

2014 / 2015


Kuljetuskerros


• 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ä TCP-

asiakassovelluksilta

• yhteydenperustamispyyntö on TCP-segmentti, jossa on

kohdeporttinro ja TCP-otsikon yhteydenperustamisbitin

(SYN-bitin) arvo yksi

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 4. Kaksi asiakasta käyttää samaa palvelinsovellusta

Periodi 3

2014 / 2015


Kuljetuskerros


3.1 Taustaa

3.2 UDP:n segmentin rakenne


Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 5. Internet-sovelluksia ja niiden kuljetusprotokollia

Periodi 3

2014 / 2015

25

TCP

TCP

Internet ja tietoverkot

Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 6. UDP-segmentti

Periodi 3

2014 / 2015


Kuljetuskerros


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 tarkistussumma-

kenttään

Periodi 3

2014 / 2015


Kuljetuskerros

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 sovel-lukselle varoituksella varustettuna

Periodi 3

2014 / 2015


Kuljetuskerros


4.1 Taustaa


4.3 Luotettavat tideonsiirtoprotokollat ja putkikuljetus

4.4 Go-Back-N (GBN)


Periodi 3

2014 / 2015


Kuljetuskerros

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 tiedon-

siirto (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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 7. Luotettava tiedonsiirto

Periodi 3

2014 / 2015


Kuljetuskerros


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 ...)

Periodi 3

2014 / 2015


Kuljetuskerros

Ää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 tilanmuu-

toksen ja tulostuksen; uusi tila ja tuloste riippuu siten

FSM:n aikaisemmasta tilasta ja syötteestä

• FSM:n alkutilaa merkitään katkonuolella

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 8 Täysin luotettava kanava (rdt1.0)

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

kutsua

alhaalta

rdt_rcv(rcvpkt) ___________________ extrack(packet,data) deliver_data(data)

rdt1.0: vastaanottaja rdt1.0: lähettäjä

Odota

kutsua

ylhäältä

rdt_send(data) ______________________ packet = make_pkt(data) udt_send(packet)

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 9 Kanava, jossa data voi korruptoitua (rdt2.0)

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

kutsua

yläpuolelta

Odota

ACK- tai

NACK-

viestiä

rdt_send(data) ________________________ sndpkt=make_pkt(data,checksum) ’ udt_send(sndpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt) ___________________________

rdt_rcv(rcvpkt) && isNACK(rcvpkt) ____________________ udt_send(sndpkt)

rdt2.0: lähettäjä

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

kutsua

alhaalta

rdt_rcv(rcvpkt) && corrupt(rcvpkt) ________________________ udt_send(NAK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) ______________________ extrackt(rcvpkt,data) deliver_data(data) udt_send(ACK)

rdt2.0: vastaanottaja

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

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)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 10 Kanava, jossa mikä tahansa paketti voi korruptoitua: lähettäjä (rdt2.1)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 11 Kanava, jossa mikä tahansa paketti voi korruptoitua: vastaanottaja (rdt2.1)

Periodi 3

2014 / 2015


Kuljetuskerros


Odota

kutsua 0

ylhäältä

Odota

ACK- tai

NAK-

viestiä 0

Odota

kutsua 1

ylhäältä

Odota

ACK- tai

NAK-

viestiä 1

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)] _______________

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || isNAK(rcvpkt)] ________________ udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)] ________________

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

viestiä 0

alhaalta

Odota

viestiä 1

alhaalta

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) ___________________________ sndpkt=make_pkt(ACK,checksum) ’ udt_send(sndpkt)


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) ___________________________ extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK,checksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) __________________________ sndpkt=make_pkt(ACK,checksum) ’ udt_send(sndpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt) __________________________ sndpkt=make_pkt(NAK,checksum) ’ udt_send(sndpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt) ___________________________ sndpkt=make_pkt(NAK,checksum) ’ udt_send(sndpkt)

Periodi 3

2014 / 2015 46 Internet ja tietoverkot

Kuljetuskerros

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 asianmu-

kaisesti sitä paketttia, joka seurasi kahdesti kuitattua

pakettia.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 12 Kanava, jossa mikä tahansa paketti voi turmeltua, kaksinkertainen ACK-viesti: lähettäjä (rdt2.2)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 13 Kanava, jossa mikä tahansa paketti voi turmeltua, kaksinkertainen ACK-viesti: vastaanottaja (rdt2.2)

Periodi 3

2014 / 2015


Kuljetuskerros


Odota

kutsua 0

ylhäältä

Odota

ACK-

viestiä 0

Odota

kutsua 1

ylhäältä

Odota

ACK-

viestiä 1


rdt_send(data) _____________________________ sndpkt=make_pkt(1, data,checksum) ’ udt_send(sndpkt)

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || isACK(rcvpkt,1)] ________________ udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)] ________________

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || isACK(rcvpkt,0)] ________________ udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)] ________________

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

viestiä 0

alhaalta

Odota

viestiä 1

alhaalta


rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) ___________________________ extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, 1 ,checksum) udt_send(sndpkt)


rdt_rcv(rcvpkt) &&[ corrupt(rcvpkt) || has_seq1(rcvpkt)] ___________________________ udt_send(sndpkt)

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || has_seq0(rcvpkt)] ___________________________ udt_send(sndpkt)

Periodi 3

2014 / 2015


Kuljetuskerros

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 pro-

tokollaan uusia mekanismeja.

Teemme seuraavan valinnan: vastuu pakettihävikin

havaitsemisesta ja siitä toipumisesta on lähettäjällä.

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

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) datapa-

ketin järjestysnumeron avulla; sen sisältö kertoo lähettäjälle

mitä datapakettia kuittaus koskee. (protokolla rdt3.0).

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 14 Kanava, jossa mikä tahansa paketti voi korruptoitua tai hävitä : lähettäjä (rdt3.0)

Periodi 3

2014 / 2015


Kuljetuskerros


Odota

kutsua 0

ylhäältä

Odota

ACK-

viestiä 0

Odota

kutsua 1

ylhäältä

Odota

ACK-

viestiä 1

rdt_send(data) _____________________________ sndpkt=make_pkt(0, data,checksum) ’ udt_send(sndpkt) start timer

rdt_send(data) _____________________________ sndpkt=make_pkt(1, data,checksum) ’ udt_send(sndpkt)

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || isACK(rcvpkt,1)] ________________

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)] ___________________ stop timer

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || isACK(rcvpkt,0)] ________________

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)] ___________________ stop timer

timeout _____________ udt_send(sndpkt) start timer

timeout ________________ udt_send(sndpkt) start timer

rdt_rcv(rcvpkt) ________________

rdt_rcv(rcvpkt) ________________

Periodi 3

2014 / 2015


Kuljetuskerros

Odota

viestiä 0

alhaalta

Odota

viestiä 1

alhaalta




rdt_rcv(rcvpkt) &&[ corrupt(rcvpkt) || has_seq1(rcvpkt)] ____________________________ udt_send(sndpkt)

rdt_rcv(rcvpkt) && [corrupt(rcvpkt) || has_seq0(rcvpkt)] ___________________________ udt_send(sndpkt)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 15 Protokollan rdt3.0 toiminta

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 16 Pysähdy ja odota – versus putkikuljetusprotokolla

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 17 Pysähdy ja odota – versus putkikuljetuslähetys

Periodi 3

2014 / 2015


Kuljetuskerros

Lähettäjän kanavan käyttöaste

L = paketin pituus bitteinä

R = kanavan välitysaste

välitysviive dtrans = L / R

Usender = lähettäjän kanavan käyttöaste

RLRTTRL

senderU/

/

Periodi 3

2014 / 2015


Kuljetuskerros

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)

Periodi 3

2014 / 2015


Kuljetuskerros

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ärjestysnumero-kenttä 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.

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 18 GBN: lähettäjän puskuri

Periodi 3

2014 / 2015


Kuljetuskerros

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ärjestysnumerol-taan n-1), vastaanottaja kuittaa paketin n viestillä ACK ja luovut-taa 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ä?)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 19 GBN toiminnassa (N = 4)

Periodi 3

2014 / 2015


Kuljetuskerros


• 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 20 SR - puskurit

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 22 SR - lähettäjän tapahtumat ja toiminnot

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 23 SR - vastaanottajan tapahtumat ja toiminnot

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 21 SR-toiminnot (N = 4)

Periodi 3

2014 / 2015


Kuljetuskerros

Liian suuri ikkuna SR:ssä: Onko 2. pkt0:n lähetys uusi paketti vai vanhan uusinta?

Periodi 3

2014 / 2015


Kuljetuskerros

Kohdan a ja b tapahtumat näkyvät vas-taanottajalle samanlaisina. Ikkunakoko saa olla korkeintaan puolet järjes-tysnumeroava-ruuden koosta.

Luotettava tiedonsiirto: yhteenveto mekanismeista ja niiden käytöstä

mekanismi käyttö ja kommentit

tarkistussumma virheiden havaitseminen paketeissa

ajastin aikamerkki ja pakettien uudelleenlähetys; datapaketti tai sen kuittaus katosi kanavassa; vastaanottaja voi saada useita kopioita samasta datapaketista

järjestysnumero lähteestä kohteseen virtaavien datapakettien järjestyksen määrää-

minen; vastaanottaja havaitsee puuttuvat ja toistuvat paketit

kuittaus kohde ilmoittaa lähteelle, että datapaketti on asianmukaisesti

saapunut perille; sisältää datapaketin järjestysnumeron

negatiivinen kuittaus kohde kertoo lähteelle, että datapakettia ei ole vastaanotettu

kunnolla; sisältää tavalliseti sen paketin järjestysluvun, jota ei ole

vastaanotettu asianmukaisesti

ikkuna, putkikuljetus 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

Periodi 3

2014 / 2015


Kuljetuskerros


5.1 Taustaa

5.2 TCP – yhteys

5.3 TCP – segmentin rakenne



5.6 Vuonohjaus

5.7 TCP – yhteyden hallinta

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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ädenpu-

ristuksella; kun yhteys on perustettu, datan lähetys voi

alkaa

• lähteessä prosessi lähettää dataa liitoksen (soketin) kautta

lähetyspuskuriin

Periodi 3

2014 / 2015


Kuljetuskerros

TCP-yhteys (2)

• lähetyspuskurin data segmentoidaan, MSS (Maximum Segment Size) ilmoittaa suurimman mahdollisen segment-tikoon 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 24 TCP:n lähetys- ja vastaanottopuskurit

Periodi 3

2014 / 2015


Kuljetuskerros

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) segmentti-

koko 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 25 TCP-segmentti

Periodi 3

2014 / 2015


Kuljetuskerros

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 sovelluskerrok-sen prosessin (16 bittiä)

• Sequence number: järjestysnumero, jota käytetään var-mistamaan saapuvan datan oikea järjestys; segmentin datakentän ensimmäisen tavun järjestysnumero (32 bittiä)

• Acknowledgement number: hyväksymis- eli kuittaus-numero; 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ä)

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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)

Periodi 3

2014 / 2015


Kuljetuskerros

Järjestys- ja kuittausnumerot

• tärkeimmät TCP-otsikon kentät

• TCP käsittelee dataa rakenteettomana, vaikkakin järjestet-

tynä tavuvirtana (0,1,2, ..., 232 – 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 26 Datan jako TCP-segmenteiksi (MSS = 1000)

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 27 Yksinkertaisen Telnet – sovelluksen järjestys- ja kuittausnumerot

Periodi 3

2014 / 2015


Kuljetuskerros


• 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)

Periodi 3

2014 / 2015


Kuljetuskerros

Kiertoviiveen arviointi ja aikamerkki (2)

• ArvioRTT on OtosRTT-arvojen painotettu keskiarvo, jossa

viimeisimmät otosarvot korostuvat: kyseessä on eksponen-

tiaalinen painotettu liikkuva keskiarvo (exponential weight-

ed moving average, EWMA)

ArvioRTTn = (1 – α) · ArvioRTTn – 1 + α · OtosRTTn

= (1 – α)2 · ArvioRTTn – 2 + (1 – α) α · OtosRTTn – 1 +

α · OtosRTTn

= . . .

= (1 – α)n · ArvioRTT0 + (1 – α) n – 1 α · OtosRTT1 +

(1 – α) n – 2 α · OtosRTT2 + · · · + (1 – α) α · OtosRTTn – 1 +

α · OtosRTTn

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 28 Kiertoviiveotokset ja –arviot

Periodi 3

2014 / 2015


Kuljetuskerros

Kiertoviiveen hajonnan arviointi

• kiertoviiveen hajontaa arvioidaan kaavalla

HajontaRTTn = (1 – β) · HajontaRTTn-1 + β · | OtosRTTn – ArvioRTTn |

• HajontaRTTn on pieni mikäli OtosRTTn:n ja ArvioRTTn:n

ero on pieni

• kertoimen β suositusarvo on 0.25 (RFC 2988)

• segmentin uudelleenlähettämisaika saadaan kaavasta

AikaVälin = ArvioRTTn+ 4 · HajontaRTTn

Periodi 3

2014 / 2015


Kuljetuskerros


• TCP rakentaa luotettavan tiedonsiirtopalvelun IP:n

epäluotettavan parhaan yrityksen palvelun päälle

• TCP käyttää yhtä ajastinta lähetettyjen, mutta kuittaa-

mattomien segmenttien uudelleenlähetykseen (RFC

2988)

• tarkastellaan yksinkertaistettua tilannetta, jossa A lähet-

tää 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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 29 Yksinkertainen TCP-lähettäjä

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 30 Kadonneen ACK-viestin aiheuttama uudelleenlähetys

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 31 Segmenttiä 100 ei lähetetä uudelleen

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 32 Kumulatiivinen kuittaus: 1. segmenttiä ei lähetetä uudelleen

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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ärjestysnu-

mero 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

Periodi 3

2014 / 2015


Kuljetuskerros

Nopea uudelleenlähetys: paketti lähetetään uudelleen ennekuin ajastin hälyttää

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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ärjestyk-

sessä 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)

Periodi 3

2014 / 2015


Kuljetuskerros

5.6 Vuonohjaus

• estää lähettäjää aiheuttamasta vastaanottajalle puskuri-ylivuotoa

• 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 Periodi 3

2014 / 2015


Kuljetuskerros

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 -muuttu-

jan arvostaa; tieto kulkee TCP-segmentin Receive window-kentässä

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 33 Vastaanottoikkuna ja vastaaanottopuskuri

Periodi 3

2014 / 2015

108

LastByteReceived LastByteRead


Kuljetuskerros

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


– SYN – bitti on asetettu ykköseksi

Periodi 3

2014 / 2015


Kuljetuskerros

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 ACK-viestin, 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.

Periodi 3

2014 / 2015


Kuljetuskerros


• TCP – yhteyttä perustettaessa suoritetaan n.s. kolminkertainen

kättely

• myöhemmissä yhteyden dataa sisältävissä segmenteissä on SYN

– bitti asetettu nollaksi

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 34 TCP – yhteyden perustaminen

Periodi 3

2014 / 2015


Kuljetuskerros


Kun TCP – yhteys lopetetaan, puskurit ja datamuuttujat deallokoidaan. Olet., että asiakas haluaa lopettaa yhteyden.

1. Asiakas lähettää palvelimelle FIN – viestin, segmentin, jossa


– 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


– FIN – bitti on asetettu ykköseksi

4. Asiakas lähettää palvelimelle hyväksymisviestin FIN ACK

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 35 TCP – yhteyden lopettaminen

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 36 TCP – asiakkaan toiminta tilakoneena

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 37 TCP – palvelimen toiminta tilakoneena

Periodi 3

2014 / 2015


Kuljetuskerros


6.1 Taustaa

6.2 Ruuhkakontrolliin syyt ja kustannukset

6.3 Ruuhkakontrolli: eri lähestymistapoja

6.4 Esimerkki verkkopohjaisesta ruuhkakontrollista: ATM

ABR – ruuhkakontrolli

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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)

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 38 Ruuhkan syntyminen. Esim 1

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 39 Läpivirtausnopeus ja viive lähetysnopeuden funktiona. Esim. 1.

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 40 Ruuhkan syntyminen. Esim. 2

Periodi 3

2014 / 2015


Kuljetuskerros


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 uudelleen-

lä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.

Periodi 3

2014 / 2015


Kuljetuskerros


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ä.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 41 Läpivirtausnopeus ja viive lähetys-nopeuden funktiona eri tapauksissa. Esim. 2.

Periodi 3

2014 / 2015


Kuljetuskerros

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

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 42 Ruuhkan syntyminen. Esim. 3

Periodi 3

2014 / 2015


Kuljetuskerros


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 juuri-

kaan 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.

Periodi 3

2014 / 2015


Kuljetuskerros


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 → , AC-

yhteydessä λout → 0 .

Fakta 4. Kun paketti hylätään jossakin polun reitittimessä,

kaikki polun aikaisemmat reitittimet ovat tehneet turhaa

työtä.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 43 Äärelliset puskurit, monta linkkiä Esim. 3

Periodi 3

2014 / 2015


Kuljetuskerros

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).

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 44 Verkkokerros tiedottaa ruuhkasta; kaksi reittiä

Periodi 3

2014 / 2015


Kuljetuskerros



7.2 Reiluus

Periodi 3

2014 / 2015


Kuljetuskerros


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.

Periodi 3

2014 / 2015


Kuljetuskerros

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.

Periodi 3

2014 / 2015


Kuljetuskerros

Ruuhkan selvillesaanti

Hävikkitapahtuma on (lähettäjän) • ajastimen hälytys

• kolmen kaksinkertaisen ACK-viestin vastaanotto

Kun verkossa on ruuhkaa, reitittimissä tapahtuu puskuri-

ylivuotoja 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’.

Periodi 3

2014 / 2015


Kuljetuskerros

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).

Periodi 3

2014 / 2015


Kuljetuskerros

TCP:n ruuhkakontrollialgoritmi (2)

TCP lisää lähetysastetta ruuhkan helpottaesa: muuttujan CongWin arvoa lisätään yhdellä MSS:llä RTT:ssä jos hävikki-

tapahtumia 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ä.

Periodi 3

2014 / 2015


Kuljetuskerros

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ä.

Periodi 3

2014 / 2015


Kuljetuskerros

TCP:n ruuhkankontrollialgoritmi (3)

Hidas alku (nopea kiihdytys)

TCP-yhteyden alkaessa muuttujan CongWin arvo on yksi

MSS. Yhteyden alussa TCP lisää lähetysastetta kaksin-kertaistamalla 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 segment-

tiä verkkoon. Jos nämä kuitataan, TCP kasvattaa ruuhkaikku-

nan koon 4 MSS:ksi, lähettää neljä segmenttiä verkkoon jne...

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 46 TCP:n hidas aloitus

Periodi 3

2014 / 2015


Kuljetuskerros

TCP:n ruuhkankontrollialgoritmi (4)

Aikamerkkitapahtumiin reagointi

Todellisuudessa TCP:n ruuhkakontrolli reagoi eri tavalla

(1) ajastimen hälytykseen ja (2) kolmen kaksinkertaisen ACK-

viestin 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 eksponen-tiaalisesti 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.

Periodi 3

2014 / 2015


Kuljetuskerros

147

TCP congestion control FSM: overview

hidas

aloitus ruuhkan

välttäminen

nopea

toipuminen

cwnd > ssthresh

hävikki: aikamerkki

hävikki: aikamerkki uusi ACK hävikki:

3dupACK

hävikki: 3dupACK

hävikki: aikamerkki

Periodi 3

2014 / 2015


Kuljetuskerros

148

TCP ruuhkanhallinta FSM: yksityiskohdat

hidas

aloitus ruuhkan

välttäminen

nopea

toipuminen

aikamerkki ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 lähetä puuttuva segmentti

aikamerkki

ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0

lähetä puuttuva segmentti

L

cwnd > ssthresh

cwnd = cwnd+MSS dupACKcount = 0 lähetä uudet segmentit sallit. rajoissa

uusi ACK cwnd = cwnd + MSS (MSS/cwnd) dupACKcount = 0 lähetä uudet segmentit sallit. rajoissa

new ACK

.

dupACKcount++

duplicate ACK

ssthresh= cwnd/2 cwnd = ssthresh + 3 lähetä puuttuva segmentti

dupACKcount == 3

dupACKcount++

duplicate ACK

ssthresh= cwnd/2 cwnd = ssthresh + 3

lähetä puuttuva segmentti

dupACKcount == 3

timeout ssthresh = cwnd/2 cwnd = 1 dupACKcount = 0 lähetä puuttuva segmentti

cwnd = cwnd + MSS lähetä uudet segmentit sallit. rajoissa

duplicate ACK

cwnd = ssthresh dupACKcount = 0

New ACK

L

cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0

Periodi 3

2014 / 2015 Internet ja tietoverkot

Kuljetuskerros

7.2. Reiluus

Tarkastellaan k kpl TCP-yhteyksiä. Oletetaan, että • kullakin yhteydellä eri polku

• kaikki käyttävät yhtä yhteistä linkkiä, ’pullonkaula’

• pullonkaulalinkin välitysaste on R bps

• ainoastaan pullonkaulalinkki on ruuhkainen, muissa runsaasti

(kaistanleveys ainakin R bps) resursseja käytettävissä

• jokainen yhteys siirtää suurta tiedostoa

• muuta liikennettä kuin k TCP-yhteyttä ei pullonkaulalinkin kautta

kulje

Ruuhkakontrollijärjestelmä on reilu, jos jokaisen yhteyden

keskimääräinen välitysaste on noin R/k bps.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 47 Kaksi TCP-yhteyttä, yhteinen linkki

Periodi 3

2014 / 2015


Kuljetuskerros

Reiluus (2)

Kysymys. Onko TCP:n AIMD – ruuhkakontrollialgoritmi

reilu, kun eri TCP-yhteydet voivat alkaa eri aikoina ja niillä

voi olla toisistaan poikkeavat ruuhkaikkunakoot?

Vastaus. On reilu siinä mielessä, että TCP:n ruuhkakont-

rolli suppenee kohden tilannetta, jossa kukin yhteys saa

samankokoisen osuuden pullonkaulalinkin kaistanle-

veydestä.

Huom. UDP-yhteydet eivät ole tasapuolisia (reiluja) eivät

myöskään rinnakkaiset TCP-yhteydet.

Periodi 3

2014 / 2015


Kuljetuskerros

Kuva 47 Läpipäästön suppeneminen reiluksi

Periodi 3

2014 / 2015


Kuljetuskerros

internet ja tietoverkot 811338a 3 kuljetusprotokollat ... · pdf fileisnack(rcvpkt)_____...

Documents