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
© Copyright 2024