![]() |
Huomaa! Tämä mallivastaus on viitteellinen. Vastaukset eivät välttämättä ole täysin kattavia, mutta suuntaa-antavia kuitenkin. Lisäksi tässä on korostettu vain niitä asioita jotka arvostelussa olivat tärkeitä. Joskus mallivastauksiin on myös hiipinyt virhe, jos huomaat sellaisen, ilmoita toki kurssin assareille.
Yleisesti kierros meni hyvin (paljon ensimmäistä paremmin) ja lähes kaikki läpäisivät kierroksen. Palaute jakautui kahtia ja toiset katsoivat kysymykset liian hajanaiseksi aihealueeltaan ja toiset taas pitivät iänikuisten TCP 3-way-handshakejen ja congestion controlin pois jättämistä hyvänä ideana.
Tehtävien 2a ja 4 perässä olleet viittaukset kurssikirjaan viittasivat kirjassa julkaistuihin harjoitustehtäviin, ei kirjan kappaleisiin (ko. 2 tehtävää olivat siis suoraan kirjasta). Tämän olisi tietysti voinut esittää paljon paremmin ja monilla kului turhaa aikaa kappaleiden 13.8 ja 13.19 selaamiseen suurennuslasin kanssa. Olen pahoillani tästä mogasta ja korjaan merkinnän lopuissa laatimissani kotitehtävissä.
Mitä hyötyä on TCP:n "sliding windows"-ominaisuudesta? (noin 2-3 riviä)
TCP:n käyttämä "sliding windows"-menetelmä mahdollistaa useamman paketin lähettämisen ilman kuittausten odottamista tehostaen näin tiedonsiirtoa. Menetelmällä hoituu myös yhteyden vuonvalvonta ja lähetysnopeuden säätäminen verkon ruuhkaisuuden mukaan.
Tapahtumaketju:
Kone A on ESTABLISHED tilassa ja lähettää FIN
viestin koneelle B. B kuittaa viestin ja siirtyy CLOSE WAIT tilaan. A
ottaa ACK:n vastaan ja siirtyy FIN WAIT-2 tilaan odottamaan
FIN-viestiä B:ltä. Jos nyt jotain tapahtuu koneelle B (esimerkiksi
virtakatko tai ohjelmointivirhe) niin A ei koskaan pääse siirtymään
tilasta eteenpäin.
TCP:ssä on kaksi tehtävään liittyvää heikkoutta: Ensimmäinen on että RST viestistä ei lähetetä kuittausta vaikka TCP onkin yhteydellinen protokolla. Toiseksi kaikki TCP-pakettien otsakkeet ovat kaikkien verkossaolijoiden luettavissa.
TCP:tä voitaisiin muuttaa esimerkiksi siten että RST viestit olisi kuitattava. Tällöin huijattavana oleva kone huomaa että jotain on väärässä saadessaan odottamattoman kuittauksen.
Radikaalimpi ratkaisu on sitten TCP-pakettien salaaminen IPSecin menetelmillä ja kryptografisen autentikoinnin (avaintenvaihto ym)lisääminen yhteyden muodostukseen.
Karnin algoritmi tarkkailee pakettien edestakaista kulkuviivettä ja säätelee kuittausten odotusaikaa, jonka kuluttua kuittaamaton paketti lähetetään uudelleen. Algoritmi mittaa vain onnistuneiden lähetysten viivettä, jolloin uudelleenlähetettyjen pakettien kuittaukset eivät tule mukaan vääristämään laskuja. Uudelleenlähetysten aikana odotusaikaa kasvatetaan portaittain kunnes onnistuneita lähetyksiä saadaan taas suoritettua. Karnin algoritmi kehitettiin alunperin pakettiradioverkkoja varten ja se sietää hyvin pakettien katoamista. Karnin algoritmin ongelmat ilmenevät pakettien viiveen vaihdellessa voimakkaasti, mihin se ei pysty sopeutumaan.
Nykyisin TCP-standardi arvioi kulkuviiveen lisäksi myös sen varianssia jolla arvioitu kulkuviive kerrotaan kuittausten odotusajan asettamiseksi. Kulkuviivearvio lasketaan viimeisimmän mittausarvon ja vanhan arvion painotettuna keskiarvona. Tämä uusi algoritmi sopeutuu Karnin algoritmia paremmin tietoverkkoihin joissa kuormitus ja näin ollen kulkuviive vaihtelee runsaasti.
Mitä hyötyä ja haittaa näet seisovien yhteyksien (idle connection) automaattisessa sulkemisessa?(Comer 13.8) (noin 6-10 riviä)
Seisovia yhteyksiä syntyy esimerkiksi yhteyden toisen osapuolen tai joku osapuolien välisen reitin kone äkillisesti kaatuu tai kun laitteen TCP/IP-pinossa on ohjelmointivirheitä. Nämä kuluttavat jatkuvasti yhteyden toisen pään resursseja (lähinnä muistia ja socketteja) ja saattavat muodostaa tietoturvauhan ko. koneelle. (Esim jos joku kaappaa kaatuneen telnet-yhteyden)
Seisovia yhteyksiä pyritään karsimaan automaattisesti pudottamalla yhteydet, joilla ei johonkin määriteltyyn aikaan ole ollut liikennettä (siirtokerroshan ei voi tietää miten ylempien tasojen sovellukset oikeasti yhteyttä käyttävät).
Seisovien yhteyksien katkaisemisesta on hyötyä, koska silloin laitteen resursseja ei kulu hukkaan turhanpäiten. Haittana taas on se että mikäli hiljainen yhteys ei ollutkaan katkennut, joudutaan yhteys avaamaan uudestaan, mikä voi olla hyvinkin raskas prosessi mahdollisten tunnelointien takia. Lisäksi jotkin aikakriittiset sovellukset pyrkivät pitämään yhteyden jatkuvasti auki nopeiden ohjausviestien lähettämistä varten. Huonosti valittu timeout-aika voi myöskin katkaista verkkovirheistä kärsivän yhteyden seisovana yhteytenä.
UDP-paketin otsakkeesta (RFC xxxx, erittäin kompakti esitys) löytyy vain vastaanottajan porttinumero. Pseudo-otsakkeella laskettavaan tarkistussummaan otetaan mukaan IP-paketin source- ja destination-osoitteet. Pseudo-otsakkeita tarvitaan varmistamaan että paketti päätyi oikeaan osoitteeseen.
Ko. protokollat toteuttavat itse yhteyksien yhteydellisyyden ja luotettavuuden ja sivuuttavat näin kokonaan TCP:n (riittämättömät) palvelut. Hyötynä tästä ko. protokollat ovat riippumattomampia käytetystä siirtoprotokollasta ja kykenevät mahdollisesti toimimaan tehokkaammin kuin TCP:n palveluja käyttäen (UDP on hyvin kevyt ja nopea protokolla). Omaan protokollaan pystyy myös sisällyttämään muita tarpeelliseksi näkemiään lisäpalveluja.
Haittapuolella on uuden protokollan suunnittelun ja virheettömän toteutuksen vaikeus.
Virheenkorjaus (checksum) informaation käyttö on UDP:ssä valinnaista. Miksi tähän on päädytty ko. standardia laadittaessa? Mitä ongelmia tästä voi aiheutua? (noin 4-8 riviä)
Tarkistussummat voidaan jättää pois siksi että protokollaa voitaisiin käyttää hyvin vähillä laskennallisilla resursseilla. Luonnollisesti tällöin menetetään tieto UDP-paketin oikeellisuudesta joten menetelmä toimii vain äärimmäisen luotettavilla siirtoteillä tai aikakriittisissä sovelluksissa, joissa aikataulussa pysyminen on pakettien hukkumista tärkeämpää.