WS_Harj_4

Internet ja tietoverkot 2015
Harjoitus 4: Kuljetuskerros
Tämän harjoituksen tarkoituksena on tutustua lyhyesti TCP- ja UDP-protokollien toimintaan.
UDP
Tehtävä 1 - UDP-segmentin rakenne
TCP - Tutustuminen TCP:hen
Tehtävä 2 - Kolmitiekättely (Three-Way-Handshake) + Sekvenssinumerointi
Tehtävä 3 - TCP uudelleenlähetys: RTT:n arviointi, RTO:n laskeminen
TCP-liikenteen analyysi
Tehtävä 4 - “TCP Stream Graph”-työkalu
Tehtävä 5 - Erään sovelluksen verkkoliikennettä + Vastaanottoikkunan maksimikoko
UDP
UDP muistilista:
- Ei lähetys- tai vastaanottoikkunoita.
- Ei ruuhkanhallintaa.
- Ei yhteyden muodostusta / kättelyitä (esim. kolmitiekädenpuristus).
- Ei ylläpidetä yhteyden tilatietoja (kuljetuskerroksessa):
Ei tiedetä onko yhteys muodostettu vai ei.
Ei tiedetä saako vastaanottaja lähetettyjä UDP-segmenttejä.
- Epäluotettavaa tiedonsiirtoa.
Tehtävä 1 - UDP-segmentin rakenne
Nouda Kurose-Rossin kirjan oheismateriaaliin kuuluva tiedostopaketti osoitteesta
“http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip” ja pura se koneellesi.
Avaa Wiresharkissa paketista purettu tiedosto ”http-ethereal-trace-5”. Tiedosto sisältää verkosta
kaapattua verkon asiakkaiden hallintaa koskevaa liikennettä.
Suodata näkymästä pois muut kuin UDP- protokollaa käyttävät paketit.
A. Montako pakettia jää näkyville? Minkä sovellustason protokollien liikennettä UDPsegmentit sisältävät?
B. Tutki näkymän ensimmäisen paketin UDP-otsikkotietoja. Mitä kenttiä UDP-otsikko
sisältää? Mikä on kunkin kentän suuruus tavuissa? Kuinka suuri on tämän perusteella
UDP-otsikon koko yhteensä?
C. Vastaa edellisen otsikon kenttien suuruutta koskevan kysymyksen perusteella seuraaviin
kysymyksiin: Kuinka monta tavua hyötykuormaa UDP-segmentti voi korkeintaan
sisältää? Mikä on suurin mahdollinen UDP-portin numero?
D. Mikä on UDP:n protokollanumero IP-otsikossa? Anna vastaus myös
heksadesimaalijärjestelmässä.
TCP - Tutustuminen TCP:hen
TCP muistilista:
- Yhteyden muodostus (SYN → SYN,ACK → ACK)
- Yhteyden hallittu katkaisu (FIN → ACK → FIN → ACK ; FIN → FIN,ACK → ACK)
- Ylläpidetään yhteyden tilatietoja.
- Luotettavaa tiedonsiirtoa:
Kuitataan TCP-segmentit saapuneeksi.
Uudelleenlähetetään “kadonneita” paketteja.
Ruuhkakontrolli, Vuonohjaus (lähetys- ja vastaanottoikkunat), jne.
Tehtävä 2 - Kolmitiekättely (Three-Way-Handshake) + Sekvenssinumerointi
Avaa “wireshark-traces.zip”-paketista purettu tiedosto ”tcp-ethereal-trace-1”. Tiedosto sisältää
kaappauksen liikenteestä asiakkaan ja palvelimen välillä tapahtumasta, jossa asiakas lataa
HTTP-protokollaa käyttäen suurehkon tiedoston ”alice.txt” palvelimelle. Latauksen voi itsekin
suorittaa osoitteessa “http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html”.
Suodata näkymästä pois muut kuin TCP- ja HTTP-paketit. Näkyviin tulisi jäädä kaksi HTTPtapahtumaa ja useita TCP-tapahtumia.
Tarkastellaan tästä eteenpäin kaappauksen sisältämää verkkoliikennettä vain kuljetuskerroksen
tasolla, poistamalla käytöstä Wiresharkin HTTP-protokollan analyysi. Tämä tapahtuu “Analyze
→ Enabled Protocols”-valikossa (Kuva1), poistamalla HTTP analysoitavien protokollien joukosta
(Kuva2).
Kuva 1: Analyze-valikko + Enable protocols-valinta
Kuva 2: Poista HTTP-protokolla analysoitavien protokollien joukosta.
Muuta myös Wiresharkin sekvenssinumeroinnin tulkintaa siten että relatiivinen
sekvenssinumerointi (“http://wiki.wireshark.org/TCP_Relative_Sequence_Numbers) on poistettu
käytöstä. Tämä tapahtuu aukaisemalla Wiresharkin asetukset “Edit → Preferences” (Kuva3),
laajentamalla “Protocols”-vaihtoehto oikealla olevasta listasta ja valitsemalla TCP-asetukset.
Poista valinta “Relative sequence numbers” TCP-asetuksista (Kuva4). Oletusasetuksilla
Wireshark ei esitä sekvenssinumerointia absoluuttisina, TCP-segmenteistä löytyvinä arvoina,
vaan sekvenssinumerointi esitetään suhteessa jokaisen erillisen TCP-yhteyden aloituspakettiin,
siten että tämän TCP-yhteyden aloittavan paketin sekvenssinumero on nolla ja sitä seuraavien
pakettien sekvenssinumerointi esitetään suhteessa tähän pakettiin.
Kuva 3: Wiresharkin asetukset
Kuva 4: Poista relatiivinen TCP-sekvenssinumeroinnin tulkinta käytöstä
A. Mikä on ”alice.txt”-tiedoston lataamiseen käytetyn TCP-yhteyden aloittavan SYNsegmentin sekvenssinumero (sequence number; huom. arvo ei ole “0”)? Mistä
Wireshark voi tunnistaa paketin SYN-segmentiksi? (KTS. 3_Kuljetuskerros.pdf; s.84-86)
B. Mikä on tähän SYN-segmenttiin annettavan palvelimen vastauksen sekvenssinumero
(huom. arvo ei ole “0”)? Mistä Wireshark voi tunnistaa paketin SYNACK-segmentiksi?
Mikä on tämän SYNACK-segmentin kuittausnumero (acknowledgement number)? Miksi
sen arvo on juuri sellainen kuin se on?
C. Mikä on TCP-yhteyden “neuvoteltu” (https://tools.ietf.org/html/rfc879) MSS?
Huomioi että MSS (Maximum Segment Size) voi olla eri asiakkaalta palvelimelle ja
palvelimelta asiakkaalle.
D. Tarkastele TCP-otsikkotietojen sekvenssinumeron ilmoittavaa kenttää. Mikä on kentän
suuruus tavuina? Kuinka suuren arvon sekvenssinumero voi tämän tavumäärän
perusteella saada?
E. TCP-yhteyttä muodostettaessa kumpikin osapuolista määrittää yhteyden aloittavan
sekvenssinumeron satunnaisesti. Jos tämä satunnaisesti määritetty sekvenssinumero
on lähellä sekvenssinumeron maksimiarvoa, niin aiheutuuko tästä rajoituksia yhteyden
aikana siirrettävälle tavumäärälle? (ts. Mitä tapahtuu kun TCP-yhteyden
sekvenssinumerointi saavuttaa sekvenssinumeron maksimiarvon?)
F. Kerro millä kahdella tavalla TCP-yhteyden voi lopettaa. Tehdäänkö tässä
kaappauksessa TCP-yhteyden lopetustoimenpiteitä? Jos tehdään niin luettele niiden
pakettien järjestysnumerot joissa näitä toimenpiteitä tapahtuu.
Tehtävä 3 - TCP uudelleenlähetys: RTT:n arviointi, RTO:n laskeminen
TCP-yhteyden ensimmäinen RTT-arvo (initial Round-Trip-Time; iRTT) määritetään tyypillisesti
kolmitiekädenpuristuksesta. (https://blog.packet-foo.com/2014/07/determining-tcp-initial-roundtrip-time/). Viestijät käyttävät tätä iRTT-arvoa muun muassa määrittäessään segmenttien
uudelleenlähetysajastimelle (Retransmission Timeout; RTO) aloitusarvon.
Wireshark määrittää iRTT:n ja jokaisen ns.segmenttiparin (lähetetty TCP-segmentti + tämän
segmentin kuittaus) RTT arvon automaattisesti, eli RTT arvo ei sisälly TCP-segmenttiin, vaan se
päätellään lähetetyn TCP-segmentin ja tähän segmenttiin annetun ACK-segmentin välisestä
viiveestä (ts. “kuinka kauan aikaa kului segmentin lähetyksestä ACK-segmentin
vastaanottamiseen”). Huomioi että vain ACK-viesteistä voidaan laskea RTT-arvo.
Voit helpottaa RTT-arvojen määrittämistä kaapatusta liikenteestä, ottamalla käyttöön uuden
sarakkeen, joka kertoo Wiresharkin määrittämän RTT-arvon TCP-otsikkotietojen kentästä
“[SEQ/ACK analysis] → [The RTT to ACK the segment was: nn seconds]” ja segmenttiparien
määrittämistä, ottamalla käyttöön uuden sarakkeen TCP-otsikkotietojen kentästä “[SEQ/ACK
analysis] → [This is an ACK to the segment in frame: n]”, joka kertoo mihin TCP-segmenttiin
kukin ACK-segmentti kuittaa vastaanotetuksi.
A. Etsi liikenteestä paketti, joka sisältää HTTP POST-komennon. Pidetään em. segmenttiä
TCP-yhteyden ensimmäisenä segmenttinä.
- Etsi kolmea ensimmäistä lähetettävää segmenttiä vastaavat ACK-segmentit ja määritä
tai laske kiertoviive (merkitään alla OtosRTT) kussakin tapauksessa.
-
Laske arvioitu kiertoviive (merkitään alla ArvioRTT) kunkin ACK-segmentin saapumisen
jälkeen kaavalla:
“ArvioRTT := 0.875* ArvioRTT + 0.125*OtosRTT”
(http://tools.ietf.org/html/rfc6298, Kappale 2; 2.3; SRTT)
Ensimmäinen arvioitu kiertoviive on sama kuin ensimmäinen havaittu kiertoviive eli iRTT.
-
Laske kiertoviiveen varianssi (merkitään alla RTTVarianssi) kunkin ACK-segmentin
saapumisen jälkeen kaavalla:
“RTTVarianssi := 0.75* RTTVarianssi + 0.25* | ArvioRTT - OtosRTT |”.
(http://tools.ietf.org/html/rfc6298, Kappale 2; 2.3; RTTVAR)
Ensimmäinen kiertoviiveen varianssi arvo on ensimmäinen havaittu kiertoviive
puolitettuna (iRTT / 2).
-
Laske uudelleenlähetyksen ajastimen arvo jokaiselle kolmelle lähetettävälle segmentille
kaavalla:
“RTO := ArvioRTT + 4*RTTVarianssi”
-
Ilmoita vastauksessasi kaikki lähetetyn segmentin sisältävien pakettien järjestysnumerot
ja jokaista lähetettyä segmenttiä vastaavan ACK-segmentin sisältävien pakettien
järjestysnumerot, ns. segmenttiparina.
Esimerkiksi “#34 + #40” on segmenttipari, jossa #34 on lähetetyn segmentin sisältävän
paketin järjestysnumero ja #40 tämän lähetetyn segmentin kuittaavan ACK-segmentin
sisältävän paketin järjestysnumero.
-
Ilmoita vastauksessasi jokaista segmenttiparia vastaavat ArvioRTT, OtosRTT,
RTTVarianssi ja RTO.
Ilmoita myös kunkin lähetyn segmentin osalta, kuinka paljon aikaa olisi pitänyt vielä
kulua että asiakas olisi uudelleenlähettänyt ko.segmentin.
-
Segmenttipari
ArvioRTT
OtosRTT
RTTVarianssi
RTO
(sekuntia)
(sekuntia)
(sekuntia)
(sekuntia)
Uudelleenlähetys
ajastimen arvo
(sekuntia)
#34 + #40
0.240473
0.240473
0.1202365
0.1442838
0.1202365
#35 + #41
0.240473
0.272112
0.1091618125
0.67712025
0.40500825
#42 + #48
0.244427875
0.046018
0.1203178203
0.725699156
3
0.6796811563
Esimerkki vastauksesta tehtävään 3. Taulukon tiedot eivät ole oikein.
TCP-liikenteen analyysi
Tehtävä 4 - “TCP Stream Graph”-työkalu
Tarkastellaan edelleen “wireshark-traces.zip”-paketista purettua tiedostoa ”tcp-ethereal-trace-1”.
Palvelimelle lähtevän tai palvelimelta asiakkaalle tulevan liikenteen ominaisuuksia voidaan
tutkia valitsemalla jokin kaapatun liikenteen TCP-segmentin sisältävä paketti ja käynnistämällä
valikosta “Statistics → TCP Stream Graph → Time Sequence Graph(tcptrace)”.
Riippuen siitä onko valittuna ollut asiakkaalta palvelimelle vai palvelimelta asiakkaalle lähetetty
paketti, kuvaaja näyttää joko asiakkaalta palvelimelle tai palvelimelta asiakkaalle lähetettyjen
TCP-segmenttien sekvenssinumerot, näitä segmenttejä vastaavien ACK-segmenttien
sekvenssinumerot, sekä vastaanottajan ilmoittaman vastaanottoikkunan suuruuden ajan
funktiona. Kuvaaja ei näytä esimerkiksi lähettäjän “lähetysikkunan” suuruutta. Web-sivulla
“http://packetbomb.com/understanding-the-tcptrace-time-sequence-graph-in-wireshark/” on
varsin selkeä esittely siitä miten kuvaajaa tulisi tulkita ja tietoa mm. kuvaajatyökalun
pikanapeista zoomaukseen (“o” ja “i”).
Tutustu em. sivuun ja aukaise kuvaaja, joka kuvaa liikennettä asiakkaalta palvelimen suuntaan.
Tutki kuvaajaa.
A. Voiko siitä päätellä, milloin TCP-yhteyden “slow start”-vaihe päättyy ja milloin
ruuhkautumisen välttäminen (congest-avoidance) alkaa? Jos voi, niin kerro n.10ms
tarkkuudella milloin slow-start-vaihe päättyy ja milloin ruuhkautumisen välttäminen
(congest-avoidance) alkaa.
B. Miten vastaanottoikkunan koko kehittyy suhteessa asiakkaalta palvelimelle lähetettyjen
segmenttien määrään?
C. Rajoittaako vastaanottoikkunan koko (pois lukien “slow start”-vaihe) yhteyden
suoritustehoa (throughput)?
D. Rajoittaako “lähetysikkunan” koko yhteyden suoritustehoa (throughput)?
E. Onko paketteja kadonnut, ts. onko mitään pakettia jouduttu lähettämään uudelleen?
F. Tarkastele “Paketti listaus”-näkymää ja määritä mikä on pienin vastaanottajan ilmoittama
puskurin koko ottaen huomioon kaikki TCP-segmentit? Onko tämä tieto saatavilla /
pääteltävissä “Time Sequence Graph(tcptrace)”-kuvaajasta?
G. Tapahtuuko kaappauksessa kumulatiivinen kuittaus? Miten päättelit asian?
(Cumulative Acknowledgment;
“http://en.wikipedia.org/wiki/Retransmission_(data_networks)”)
Tehtävä 5 - Erään sovelluksen verkkoliikennettä + Vastaanottoikkunan maksimikoko
Lataa Optimasta ITV-kurssin työtilasta tiedosto “sendwin-bound.pcapng”. Tiedosto sisältää
erään sovelluksen verkkoliikennettä. Sovelluksen on tarkoitus lähettää dataa 128kt:n lohkoissa,
mutta sovelluksessa on kaksi bugia, joiden vuoksi tiedonsiirto ei toimi oikein.
A. Tunnista bugien aiheuttamat häiriöt tiedonsiirtoon, tarkkailemalla kaapattua liikennettä
joko graafeilla tai ilman. Selosta mitä bugit tekevät verkkoliikenteelle.
B. Miten voi olla mahdollista että vastaanottoikkunan koko on tässä kaappauksessa
huomattavasti suurempi kuin 16:sta bitillä esitettävissä oleva maksimiarvo “65535”?
Miksi tätä vastaanottoikkunan koon 16-bitin rajoitusta kiertävää mekanismia kutsutaan?
Lisätietoja:
http://ithitman.blogspot.fi/2013/02/understanding-tcp-window-window-scaling.html
http://en.wikipedia.org/wiki/Bitwise_operation