TCP ja UDP: kumpi varmistaa perillemenon ja kumpi ei

Kun jokin verkossa toimii huonosti, oire on harvoin sattumanvarainen. Videopuhelu rakeistuu ja ääni pätkii, mutta puhelu jatkuu. Suuri tiedosto latautuu, pysähtyy hetkeksi ja jatkaa. Nämä ovat saman ongelman kaksi eri oiretta, ja ero syntyy siitä, kumpaa kuljetusprotokollaa sovellus käyttää.

Kuljetuskerros on se osa verkon kerrosjaosta, joka vastaa kahteen kysymykseen: mille ohjelmalle tämä paketti kuuluu ja pitääkö perillemeno varmistaa. Ensimmäiseen kysymykseen vastaavat porttinumerot, toiseen vastaa protokollan valinta. TCP vastaa kyllä, UDP vastaa ei.

Yleinen käsitys, että TCP olisi hyvä ja UDP huono tai että UDP olisi nopea ja TCP hidas, menee pieleen. Molemmat kulkevat samaa verkkoa samalla nopeudella. Ero on siinä, mitä tapahtuu kun jokin menee vikaan.

Sama verkko, kaksi eri lupausta

Verkko ei lupaa mitään. IP-taso tekee parhaansa: se yrittää viedä paketin perille, mutta paketti voi kadota ruuhkassa, saapua väärässä järjestyksessä tai monistua. Tämä ei ole vika vaan suunnitteluperiaate, joka pitää verkon yksinkertaisena ja skaalautuvana.

Kuljetuskerros päättää, korjataanko tämä epävarmuus vai ei.

TCP lupaa neljä asiaa. Kaikki lähetetty tulee perille. Kaikki tulee siinä järjestyksessä kuin se lähetettiin. Kahteen kertaan saapuneet osat karsitaan. Lähettäjä hidastaa, jos verkko ruuhkautuu. Lupaus on vahva, ja sen lunastaminen vaatii kirjanpitoa ja odottelua.

UDP ei lupaa mitään näistä. Se lisää pakettiin lähtö- ja kohdeportin sekä tarkistussumman, ja siinä kaikki. Jos paketti katoaa, kukaan ei huomaa sitä protokollatasolla. Vastuu siirtyy sovellukselle, joka saa päättää itse mitä puuttuvalle osalle tehdään.

Kumpikin merkitään pakettiin samalla tavalla. IP-otsikossa on kenttä, joka kertoo mitä kuljetusprotokollaa sisältö käyttää, ja vastaanottava laite ohjaa paketin sen perusteella oikealle käsittelijälle. Verkon reitittimet eivät välitä asiasta lainkaan, koska ne katsovat vain osoitteita.

Verkko ei muutu luotettavaksi siitä, että valitaan TCP. Epävarmuus vain siirretään paikkaan, jossa se näkyy odotuksena eikä katoavana tietona.

Kolmivaiheinen kättely aloittaa yhteyden

TCP-yhteys ei ala datan lähettämisellä vaan sopimisella. Kättely on kolmivaiheinen, ja sen tarkoitus on varmistaa, että molemmat osapuolet ovat hereillä ja pystyvät sekä lähettämään että vastaanottamaan.

1. Asiakas pyytää yhteyttä. Laitteesi lähettää paketin, jossa on yhteydenavauslippu ja lähtönumero, josta sen oma numerointi alkaa.
2. Palvelin vastaa ja pyytää vuorostaan. Palvelin kuittaa saaneensa pyynnön ja lähettää samassa paketissa oman avauspyyntönsä ja oman lähtönumeronsa.
3. Asiakas kuittaa vastauksen. Kolmas paketti vahvistaa, että myös palvelimen puoli on kunnossa. Vasta tämän jälkeen lähtee ensimmäinen tavu varsinaista dataa.

Kättely maksaa yhden edestakaisen matkan verkossa ennen kuin mitään hyödyllistä on liikkunut. Lähipalvelimen kanssa se on huomaamaton, mutta toiselle mantereelle jokainen edestakainen matka on selvästi tuntuva. Kun päälle tulee vielä salatun yhteyden neuvottelu, alkuviive kasvaa. Juuri tämän alkuviiveen karsiminen on ollut yksi tärkeimmistä syistä kehittää TCP:n seuraajaa.

Yhteys myös suljetaan sovitusti. Kumpikin osapuoli ilmoittaa erikseen lopettavansa lähettämisen ja odottaa kuittausta, mikä varmistaa ettei viimeinen tavu jää matkalle. Tästä syystä juuri katkennut yhteys voi jäädä käyttöjärjestelmän listoihin hetkeksi odottamaan, vaikka sovellus on jo suljettu.

UDP:llä ei ole kättelyä lainkaan. Ensimmäinen paketti sisältää jo hyötykuormaa. Tämä on yksi syy siihen, miksi yksinkertaiset kyselyt kannattaa tehdä UDP:llä: koko keskustelu voi olla yksi kysymys ja yksi vastaus, jolloin kättely maksaisi enemmän kuin itse asia.

Järjestysnumerot, kuittaukset ja uudelleenlähetys

TCP:n luotettavuus perustuu numerointiin. Jokaisella lähetetyllä tavulla on juokseva numero, ja vastaanottaja kertoo kuittauksissaan, mihin asti se on saanut yhtenäisen jonon. Lähettäjä säilyttää lähettämänsä osat muistissa, kunnes kuittaus saapuu.

Kadonnut paketti havaitaan kahdella tavalla. Joko kuittausta ei kuulu tietyn ajan kuluessa, jolloin lähettäjä lähettää osan uudelleen, tai vastaanottaja kuittaa toistuvasti samaa kohtaa, mikä kertoo että jono katkesi juuri siitä. Jälkimmäinen on nopeampi tapa, koska sitä ei tarvitse odottaa kelloon asti.

Yhtä aikaa lähetettävän tiedon määrää säädellään ikkunalla. Yhteys ei aloita täydellä teholla vaan kasvattaa vauhtia asteittain ja perääntyy heti, kun merkkejä ruuhkasta ilmenee. Tämä on syy siihen, että lyhyet siirrot eivät koskaan saavuta liittymän nimellisnopeutta, ja se selittää osan siitä erosta, joka näkyy kun nopeustestin tulos poikkeaa arjen kokemuksesta.

Numerointi tuo mukanaan myös TCP:n tunnetuimman heikkouden. Koska data on luovutettava sovellukselle järjestyksessä, yksi puuttuva paketti pysäyttää kaiken sen jälkeen tulleen, vaikka nuo osat olisivat jo laitteen muistissa. Ilmiötä kutsutaan jonon kärjen tukkeutumiseksi, ja se on suora syy siihen, miksi lataus näyttää pysähtyvän ja jatkuvan nykäyksellä.

Sama häviö, kaksi eri oiretta

Pakettihäviö on hyvä esimerkki siitä, miksi protokollan valinta näkyy käyttäjälle asti.

Käytännön päättelysääntö: jos oire on odottaminen, kyseessä on todennäköisesti TCP. Jos oire on laadun heikkeneminen ilman odottamista, kyseessä on todennäköisesti UDP. Tämä auttaa myös silloin kun wifi katkeilee ja haluat päätellä, onko ongelma jatkuvaa vai satunnaista.

Reaaliaikaisessa puheessa uudelleenlähetys on hyödytön. Jos kymmenesosasekunnin pala ääntä katoaa, sen pyytäminen uudelleen tuottaisi palan, joka saapuu vasta kun keskustelu on jo edennyt ohi. Parempi ratkaisu on peittää aukko tai antaa sen kuulua. Tästä syystä puhe- ja videosovellukset käyttävät UDP:tä ja hoitavat virheenkorjauksen itse, omilla ehdoillaan.

Kumpi mihinkin

Nimipalvelu on hyvä esimerkki siitä, että valinta ei ole ehdoton. DNS-kysely tehdään tavallisesti UDP:llä, mutta jos vastaus ei mahdu yhteen pakettiin, sama kysely toistetaan TCP:llä. Salatut nimipalveluyhteydet kulkevat kokonaan eri tavalla.

Sama koskee sähköpostia. Viestin siirto käyttää TCP:tä, koska liitteestä ei saa puuttua tavuakaan ja rivien järjestys on olennainen. Jos haluat nähdä millainen ketju viestin taakse jää, se käydään läpi artikkelissa sähköpostin kulusta lähettäjältä perille.

Suoratoiston ja puhelun ero kannattaa huomata. Molemmissa liikkuu videokuvaa, mutta tallenteen katselussa muutaman sekunnin puskuri on täysin hyväksyttävä, kun taas puhelussa se tekisi keskustelusta mahdotonta. Sama sisältötyyppi, eri vaatimus, eri protokolla.

QUIC rakentaa luotettavuuden UDP:n päälle

Uusin kerros tähän tarinaan on QUIC. Se kulkee UDP:n sisällä, mutta se ei ole UDP:n kaltainen välinpitämätön protokolla. QUIC toteuttaa itse järjestyksen, uudelleenlähetykset ja ruuhkanhallinnan, ja lisäksi siihen on rakennettu salaus sisään. Verkon näkökulmasta liikenne on UDP-liikennettä, sovelluksen näkökulmasta se on luotettava ja salattu yhteys.

Kaksi syytä ovat ajaneet kehitystä. Ensimmäinen on alkuviive: kun yhteyden avaus ja salauksen neuvottelu tehdään samassa vaiheessa, edestakaisia matkoja tarvitaan vähemmän ennen ensimmäistä hyötytavua. Toinen on jonon kärjen tukkeutuminen: QUIC pystyy pitämään rinnakkaiset siirrot erillään, jolloin yhden osan katoaminen ei pysäytä muita.

Valinta rakentaa uusi kuljetusprotokolla UDP:n päälle eikä IP:n päälle on käytännöllinen. Maailman verkkolaitteet käsittelevät TCP:tä ja UDP:tä, mutta tuntematonta uutta protokollanumeroa moni niistä yksinkertaisesti pudottaisi. Kun uusi protokolla piilotetaan UDP:n sisään, se kulkee olemassa olevan verkon läpi ilman että mitään tarvitsee vaihtaa. Samalla protokollan kehitys siirtyy sovellusten mukana päivittyväksi, kun aiemmin kuljetuskerroksen muutokset odottivat käyttöjärjestelmien päivityksiä.

QUIC on määritelty julkisessa standardissa, ja HTTP:n uusin versio kulkee sen päällä. Tavallinen käyttäjä ei näe eroa mistään, koska selain ja palvelin valitsevat käytettävän tavan keskenään ja palaavat tarvittaessa vanhaan. Ainoa paikka, jossa asia voi tulla vastaan, on tiukasti rajattu verkko, jossa UDP-liikennettä on rajoitettu. Silloin yhteys putoaa takaisin TCP:hen ilman ilmoitusta.

Mitä tästä seuraa arjessa

• Älä yritä valita protokollaa itse. Sovellus valitsee sen puolestasi, eikä asetusta yleensä ole tarjolla.
• Tulkitse oiretta oikein. Odottaminen ja pysähtely viittaavat luotettavaan siirtoon huonolla linkillä. Rakeisuus ja pätkiminen viittaavat reaaliaikaiseen liikenteeseen.
• Muista, että pakettihäviö ei näy nopeustestissä samalla tavalla kuin puhelussa. Testi mittaa yleensä siirtonopeutta, ei viiveen vaihtelua.
• Jos puhelut pätkivät mutta lataukset toimivat, ongelma on todennäköisesti viiveen vaihtelussa eikä kaistassa. Silloin kannattaa katsoa langaton linkki ja verkon ruuhkaisuus ennen liittymän vaihtamista.
• Salattu yhteys ja luotettava yhteys ovat eri asioita. Jos haluat ymmärtää, mitä salaus peittää ja mitä ei, se selviää parhaiten VPN-yhteyden rajoista, jotka koskevat aivan eri kysymystä kuin perillemenon varmistus.