Keskustelu: Yleinen keskustelu: UDP ja NAT

Tämä on jatkoa "kilpailut" -aiheessa syntyneeseen offtopic -keskusteluun udp:n ja natin "ongelmasta".

Gaxx kirjoitti:

Grez kirjoitti:

Jos lähetät portista 7654 UDP paketin koneen 123.45.67.89 porttiin 5678, niin sen jälkeen tietyn ajan kuluessa koneelta 123.45.67.89 portista 5678 porttiisi 7654 tulevien UDP-pakettien katsotaan yleensä olevan "paluupaketteja". Vaikka protokolla itsessään on tilaton, niin mikään ei estä palomuuria tai NATia pitämään kirjaa tuollaisista asioista.

Kannattaa tutustua aiheeseen.

Mitenkäs homma toimii sitten seuraavanlaisessa tilanteessa? Minulla on kaksi konetta natin takana ja kumpikin on "yhteydessä" natin ulkopuolella olevaan "serveriin" UDP-protokollan välityksellä ja sattumoisin kumpikin kone lähettää viestinsä serverille portista 4321 (ip on tietty kummallakin se sama(vaikka 123.45.67.89), joka näkyy natin ulkopuoliseen verkkoon). Nyt serverin pitäisi lähettää "paluupaketti" kummallekin. No, serveri lähettää ne, mutta kummankin osoite on 123.45.67.89:4321. Mistä natti pystyy päättelemään, kummalle kukin paketti pitäisi lähettää?

Kyllä se taitaa olla niin, että tiettyyn porttii osoitetut paketit pitää aina ohjata natilta tietylle koneelle. Toinen vaihtoehto on tietty ohjata kaikki natille tulevat viestit jollekin tietylle koneelle, mutta silloinhan tilanne on sama, kuin nattia ei olisikaan.

Grez kirjoitti:

Gaxx kirjoitti:

Kyllä se taitaa olla niin

Jep jep, mutulla on hyvä mennä.

No jos kerran tiedät, miten väittämäsi toimii kyseisessä tilanteessa, voisit ehkä valaista minua ja mahdollisesti muitakin. Pistä vaikka joku lähde, josta tuo selviää, jos et jaksa raapustaa sitä tähän.

Jäi vähän sellainen kuva, ettet ole itsekään ihan varma asiasta :(

Edit: Toki muutkin voivat valaista :)

Gaxx kirjoitti:

Mitenkäs homma toimii sitten seuraavanlaisessa tilanteessa? Minulla on kaksi konetta natin takana ja kumpikin on "yhteydessä" natin ulkopuolella olevaan "serveriin" UDP-protokollan välityksellä ja sattumoisin kumpikin kone lähettää viestinsä serverille portista 4321 (ip on tietty kummallakin se sama(vaikka 123.45.67.89), joka näkyy natin ulkopuoliseen verkkoon). Nyt serverin pitäisi lähettää "paluupaketti" kummallekin. No, serveri lähettää ne, mutta kummankin osoite on 123.45.67.89:4321. Mistä natti pystyy päättelemään, kummalle kukin paketti pitäisi lähettää?

Niin, no siis yllättäen UDP voidaan toteuttaa ihan samalla tavalla kuin TCP:kin. Täsmälleen sama kuvailemasi "ongelma" kun tulee TCP:lläkin.

Eli jos koneesta a ja koneesta b otetaan TCP-yhteys tai lähetetään UDP-paketteja, joissa on sama lähdeportti, niin NAT arpoo ulospäin jälkimmäiselle jonkin muun lähdeportin, tai se voi arpoa kaikille ulosmeneville yhteyksille jonkin lähdeportin.

Tietenkään kaikissa NATeissa ei välttämättä ole toteutettu "tilallista UDP:tä", mutta kyllä se nyky-NATeissa useimmiten on.

Sitten joku NAT voi tietysti toimia niin, että ei käännä noita UDP-portteja vaan lähettää vaan ne siihen koneeseen josta viimeksi on liikennöity tms. Sitä varten oli siellä toisessa threadissa mainitsemani ohje Counter Strikeen, että konffataan eri koneille eri lähdeportti.

Ja enhän alun perin sanonutkaan, että NATin läpi pitäisi toimia useammalta koneelta yhtä aikaa (vaikka siis usein toimiikin). Kommentoin vaan, että aika natsi NAT, jos ei ollenkaan mahdollista paluu-UDP:tä. Esim. itse en voin ottaa oman NATtini läpi VPN-yhteyden vain yhdeltä koneelta kerrallaan. Tosin se ei johdu UDP:stä vaan siitä, että se käyttää TCP:n lisäksi GRE-protokollaa. Silti voisin sanoa että "aika kämäinen NAT jos ei mahdollista ollenkaan PPTP / L2TP -yhteyksiä". Tosin sellainenkin NAT on joskus aikaa sitten minulla ollut.

Gaxx kirjoitti:

Pistä vaikka joku lähde

En nyt äkkiseltään osaa sanoa mitään yksiselitteistä lähdettä, varsinkin kun toteutustapoja on varsin monia ja eri NATien lähestymistapa vaihtelee. Kuitenkin jos googletat vaikka "Stateful UDP", niin aiheesta löytyy runsaasti luettavaa.

Aivan, aivan... porttimuuntelu kävi itsellänikin jälkikäteen mielessä, mutta jäi vähän arveluttamaan. Käytännössä se kuitenkin toimii.

Kiitokset vaivannäöstä! Minulle valkeni myös se, miten TCP-yhteydet toteutetaan natin läpi.

PS. Itelläni on melko natsi NAT :)

http://www.b500.com/~hplus/nat-punch.html
UDP:llä on se etu TCP:hen verrattuna vielä, että sillä voidaan toteuttaa peer-to-peer yhteyksiä natin läpi, kun taas TCP ei tähän kykene. UDP:llä natti voidaan rei'ittää, jolloin kuka tahansa joka tietää reiästä voi lähettää sen läpi paketteja. Tässä käytetään apuna ulkopuolista matchmaking palvelinta, jonka avulla osapuolet saavat tietoonsa toistensa käyttämät osoitteet ja portit. TCP:llä clientin ja serverin välillä tehdyn yhteyden tilaa puolestaan ei voida siirtää peer-to-peer tyyppiseksi kahden clientin väliseksi, koska viestintä TCP:llä vaatii yhteyden muodostuksen, joka ei onnistu (molemminpuolisen) NAT:in läpi.

Lisätään nyt loppuun vähän syitä miksi reaaliaikaiset FPS pelit käyttävät UDP:tä TCP:n sijaan (tästä kysymyksestä keskustelu kai lähti).
UDP:llä on:
1. pienempi latenssi
2. pienempi header
3. peer-to-peer mahdollisuus

1. kohta lienee näistä merkittävin.
Oletaan, että reaaliaikapeli (kuten FPS)
lähettää pelaajaan liittyyvää tilatietoa esimerkiksi 10(-20) kertaa sekunnissa. Oletetaan lisäksi, että pelaajien välinen latenssi on suurehko eli 100ms luokkaa. Tällöin normaalitilanteessa vastustaja näkyy ruudulla paikassa jossa se oli 100-200ms sitten (riippuen tuliko paketti juuri vai onko seuraava tilapaketti juuri tulossa). Myös TCP:llä viiveet ovat samanlaisia normaalitilanteessa.

Eroa tulee kuitenkin silloin, kun yhteys on heikko ja paketteja alkaa tippuamaan. Yleensä tällainen tilainformaatio ei ole kriittistä eikä paketin tippuminen aiheuta ongelmia pelin tilan kannalta. UDP:llä yksittäisen paketin tippuminen ei siten suuremmin aiheuta huomattavaa ero. Tilainformaatio pakettien saapumisväli on vain yhdessä tapauksessa lähetysaikavälin verran pidempi eli noin 200-300ms. Tärkeille paketeille (kuten osuma / pelin loppuminen) voidaan lisäksi tehdä oma varmistusmenettely UDP:n päälle.

TCP:llä puolestaa paketin tippuminen aihettaa paketin uudelleen lähetyksen. Uudelleenlähetystarve havaitaan kuitenkin vasta suurehkon viiveen jälkeen. Viiveen pitää olla jonkin verran suurempi kuin viestin lähetykseen ja vastausviestin saapumiseen kuluva aika, oletetaan tässä, että se on noin 3*latenssi = 300ms. Tämän ajan kuluessa kaksi seuraavaa tilapakettia on jo saapunut kohdekoneelle, mutta niitä ei voida lukea, koska TCP-protokolla varmistaa pakettien perilletulon oikeassa järjestyksessä. Tippuneen paketin uudelleenlähetykseen ja sen perille menoon kuluu vielä latenssin verran aikaa, jolloin viimein saapunut paketti ilmoittaa pelaajan paikan 400-500 ms sitten. Vasta tämän jälkeen voidaan lukea seuraavat kolme tilapakettia, jotka ovat saapuneet jo aikaisemmin uudelleenlähetyksen aikana. Jos oletetaan, että yhteydessä 10% paketeista katoaa (aivan realistinen luku heikoissa yhteyksissä), niin kerran sekunnissa pelissä tapahtuu ylimääräinen 300ms viive/nykäys. Toki lagin vaikutusta pelaajan paikkaan yritetään pienetää erilaisilla ennustustekniikoilla, mutta silti 300ms poikkeus normaalista aiheuttaa merkittävää nykimistä.