Miért nem tudok küldeni, UDP csomagokat böngészőn keresztül
háttér
Állás böngésző alapú HTTP protokollon (a protokoll kérések és válaszok hontalan). Eredetileg hivatott szolgálni statikus weboldalak. HTTP fut TCP, akkor alacsony szintű protokoll, amely garantálja a megbízható szállítás és a megfelelő sorrendben az adatok átvitele az interneten keresztül.
Mindez nagyon jól működött évekig, de weboldalak az utóbbi időben több interaktív és megállt megválaszolása paradigmát „challenge-response» HTTP protokoll. Hogy oldja meg ezt a problémát, feltalálta a modern webes protokollok, mint például WebSockets, WebRTC, HTTP 2.0 és QUIC, képesek arra, hogy jelentősen javítja a hálózati interaktivitás.
Sajnos, egy sor új webfejlesztés szabványok nem felelnek meg az igényeinek multi-player játék, vagy túl nehéz megvalósítani.
Ez okozza a frusztrációt között játékfejlesztők, mert ők csak azt szeretném tudni, hogy küldeni és fogadni UDP-csomagokat a böngészőn keresztül.
Web létrehozott TCP, hogy melyik az a protokoll, miközben csomag sorrendben. A megbízható szállítási adatokat a megfelelő sorrendben a TCP packet loss feltételeket kell tárolni a legfrissebb adatok a sorban, várva, hogy küldje el újra az elveszett csomagok. Ellenkező esetben az adatok fogják szállítani a megfelelő sorrendben.
Ez az elv az úgynevezett blokkoló a sorban. Ez megteremti irritáló generálkivitelezők és szinte tragikomikus helyzet. A legfrissebb adatok szükséges, várja ismételt megküldése a régi adatokat, de abban az időben az adatokat továbbítják a már elavult, és használhatatlanná válnak.
Sajnos ez az eljárás nem lehet rögzíteni keretében a TCP, benne az összes adatot kell beszerezni simán és a megfelelő sorrendben. Ezért a szokásos megoldás az szerencsejáték-ipar az elmúlt 20 év óta átadása UDP adatokat.
A gyakorlatban ez azt jelentette, hogy minden játék, hogy saját protokoll tetején a UDP, amely végrehajtja az összes szükséges funkciót, és elküldi a legtöbb adat megbízhatatlan módon mentés nélkül a sorrendben. Ez biztosította a maximális gyors szállítási idő adatok nem várja meg az újraküldés elveszett csomagok.
És mit kell tenni abban az esetben, webes játékok?
A fő probléma az internetes játékok ma, hogy a játék fejlesztői nem tudják kihasználni a böngésző a legjobb megoldás által választott szerencsejáték-ipar. Ehelyett egy internetes játék adatokat küld a TCP, ami a rossz érzékenységet.
TCP feltétlenül szükséges, ezt a problémát meg lehet oldani „a kattintás ujjaival,” ha az internetes játékok a lehetőséget, hogy küldeni és fogadni az UDP-csomagokat.
És mi van a WebSockets?
WebSockets - egy kiterjesztése a HTTP protokoll, a HTTP-módosító vegyület oly módon, hogy az adatokat lehet továbbítani mindkét irányban. Ez nem egy szabványos mintát „challenge-response”.
Ez a technika lehetővé teszi, hogy elegánsan megoldani a problémát a webhelyek a megjeleníteni kívánt dinamikusan változó tartalommal, mert telepítése után WebSocket kapcsolat a szerver küld adatokat a böngésző figyelmeztetés nélkül.
Sajnos, mint WebSockets végrehajtott TCP, az adatok továbbra is sebezhető elzáródása a sorban.
Mi QUIC?
QUIC - kísérleti protokoll célja az UDP és leváltására fejlesztették ki a szállítási réteg a HTTP. Ő jelenleg csak a Google Chrome.
A legfontosabb jellemzője a QUIC - támogatja a több adatfolyamot. Az ügyfél vagy a szerver hallgatólagosan új csatornákat, növeli csatorna azonosítóját (csatorna id).
csatorna koncepciója két fő előnye van:
- Ahhoz, hogy ne küldjön megerősítést kér a kapcsolat minden alkalommal, amikor új lekérdezést.
- Megszünteti a zár a sorban egymástól független adatfolyamok.
Sajnos annak ellenére, hogy megszüntesse a sorban blokkoló problémát külön áramban, de még mindig létezik az egyes patak.
Mi WebRTC?
Vegye figyelembe, hogy támogatja a WebRTC-csatornán lehet állítani, hogy „megbízhatatlan” mód, amely lehetővé teszi, hogy a böngésző nem megbízható adatátvitelt mentés nélkül a sorrendben.
Ennek oka, hogy a többszereplős játékokban van egy tendencia távol a transzfer peer-to-peer, hogy a kliens-szerver modell. Bár WebRTC lehetővé teszi, hogy kényelmesen küldjön megbízhatatlan „véletlen” adatokat böngésző böngésző összeomlik, amikor szükség van az adatátvitel a böngésző és a dedikált szerver.
A probléma akkor keletkezik, mivel a rendkívül összetett a WebRTC. Ennek oka a nehéz egyértelmű: WebRTC célja elsősorban az volt, hogy adatokat cseréljenek peer-to-peer böngészők között, ezért, hogy megkerülje a NAT és a csomagkapcsolt átvitel a legrosszabb esetben van szükség, mert a támogatást elkábítani ICE és forgassa.
„Úgy éreztem, hogy mi szükség van egy UDP-változata WebSockets. Ez az egyetlen dolog, amit akart. "
Matheus Valadares (Matheus Valadares), alkotója agar.io
Röviden, a játékfejlesztők szeretem az egyszerűséget, és az oldatot típusú «WebSockets UDP» vonzza őket sokkal több, mint a komplexitás a WebRTC.
Miért nem teszi lehetővé, hogy küldjön UDP?
Az utolsó megoldás a problémára - egyszerűen lehetővé teszi a felhasználók küldeni és fogadni UDP-csomagokat közvetlenül a böngészőn keresztül. Persze, ez teljesen rossz ötlet, és jó oka van, hogy miért ezt soha nem szabad megengedni, hogy megtörténjen.
Mi lehet a megoldás?
De mi van, ha jön a másik végén? Ahelyett, hogy hidat építsünk a világ az interneten, hogy a játékok kezdhetjük a megfelelő technikákat és játékokat, hogy véglegesítsék a döntést, hogy jól működik az interneten.
A nevem Glenn Fiedler (Glenn Fiedler), én a fejlődő játékok az elmúlt 15 évben. A legtöbb az időben már szakosodott hálózati programozás. Van egy nagy élmény dolgozik dinamikus akciójátékok. Az utolsó játék dolgoztam volt Titanfall 2.
Körülbelül egy hónappal olvastam ezt a cikket a Hacker News: WebRTC: a jövőben a webes játékok.
Megteremtette agar.io Mateus Valadares azt mondta, hogy a WebRTC túl nehéz neki, és ő továbbra is használja a játékokat WebSockets.
Azt gondoltam: biztosan kell egy egyszerűbb megoldás, mint a WebRTC?
Csodálkoztam, hogyan nézne egy ilyen döntés?
Véleményem az oldatot kell a következő tulajdonságokkal rendelkezik:
Szeretném bemutatni az én verzióm a döntést. Ne szórakoztat magunkat illúziókkal, hogy teljes mértékben elfogadott, mint a standard böngészők, nem vagyok egy web-programozó, írok a játékot. De remélem, hogy legalább segít böngésző döntéshozók és a webes fejlesztők számára valóban szükséges a kliens-szerver játékokat. Azt akarom javasolt megoldás legalább részben segített áthidalni a szakadékot a játékok és internetes böngészés.
Remélhetőleg az eredmény lenne a közeljövőben egy sokkal jobb munkát multiplayer böngészős játékok.
netcode.io
A döntés, hogy mely azért jöttem - ez netcode.io
Úgy tervezték, a játékok, mint a agar.io. amelyek előírják a játékosok, hogy elterjedt az elsődleges helyszínen esetekben a dedikált szerverek. Minden szerver van egy limit maximális játékosok száma (az alap végrehajtására - akár 256 játékos a szerveren például).
netcode.io nyer WebRTC egyszerűség. A rendszer alkalmazása esetén ez csak a dedikált szerverek, így a használata ICE, kábító, és viszont nem szükséges. Végrehajtása révén titkosítás, aláírás és hitelesítés után libsodium elkerüli a bonyolult a teljes körű végrehajtása DTLS, miközben ugyanazt a biztonsági szintet.
Az elmúlt hónapban hoztam létre az alap végrehajtására netcode.io a C. alatt kiadott BSD licenc a három pontot. Alig néhány hónap, remélem, hogy javítsa a kivitelezésben levelet leírásban és az együttműködést más fejlesztők portolásával netcode.io különböző nyelvekre.
Ez hogy működik
Token kapcsolat két részből áll:
Amikor csatlakozik egy dedikált szerver, a kliens rendszeresen küld UDP kéréscsomagból kapcsolatot. Ez a csomag tartalmazza a token privát adatkapcsolatot, valamint további adatokat AEAD, mint például a verzió információkat netcode.io, protokoll azonosító (64 bites szám, amely egyedi minden játék), időbélyeggel token érvényessége a kapcsolatot, és a sorozatszám a primitív AEAD .
Amikor egy dedikált szerver kap egy UDP kapcsolat kérés, akkor először a segítségével primitív AEAD ellenőrzi az érvényességét a csomag tartalmát. Ha bármely nyilvános adatokat a kérelem csomagot a kapcsolat már megváltozott, az aláírás ellenőrzését emelni fogja a hibát. Ez nem teszi lehetővé az ügyfelek, hogy módosítsa a időbélyege érvényességének időtartama a token kapcsolatot, és lehetővé teszi, hogy gyorsan elutasítja tokeneket lejárt.
A szerver ellenőrzi, hogy a token már csatlakozáshoz használt keresésével rövid története HMAC jelzőt. Ha egyezést talál, akkor a csatlakozási kérelmet figyelmen kívül hagyja. Köszönhetően ez token nem használható csatlakozni több ügyfél.
A szerver ellenőrzi, hogy van-e hely a szerver a kliens. Minden szerver támogat bizonyos maximális ügyfelek. Például a játék 64 játékos lesz a 64 ülőhely csatlakoztatására ügyfelek. Ha a szerver tele van, válaszol, nem a csatlakozási kérelmet. Ez lehetővé teszi, hogy az ügyfelek gyorsan felismerik, hogy a szerver tele van, és meg kell mozgatni, hogy a következő kiszolgálót a listában.
Randomizálás kulcs biztosítja, hogy nincs biztonsági problémák akkor jelentkeznek, amikor titkosítására token hívás több szerver egy sorszám (szerverek nincsenek összehangolva egymással). Ezen túlmenően, a hívás kapcsolat sokkal kisebb csomagban kéréscsomagból kapcsolatban, hogy elkerüli az „megerősítése” protokoll a DDoS-támadások ellen.
Amikor a kiszolgáló választ kap csomagot a kapcsolatot. ő keresi a megfelelő bejegyzést az ügyfél várható, és ha létezik, akkor azt keresi ismét egy szobát egy ügyfél kapcsolatot. Ha nem álló terek, válaszol, hiba a csatlakozási kérelmet. mert az a hely korábban szabad idején első kérelemfogadásra kapcsolat már foglalt.
Ellenkező esetben a szerver kijelöli az ügyfél helyet a szerveren, és válaszol a csatlakozást támogató. amely közli az ügyféllel, hogy elkülönített helyet a szerveren. Ez a hely az úgynevezett ügyfél-index. A multiplayer játékokat, akkor tipikusan azonosítására használják az ügyfelek csatlakozik a szerverhez. Például a kliensek 0, 1, 2, 3, négy játékos a mérkőzés játékos 1, 2, 3 és 4.
Most a szerver úgy véli, hogy a kliens csatlakozik, és hogy lehetséges csomagokat küldeni a rakomány. Ezek a csomagok tartalmazzák kapcsolatos adatokat a játékot. Csomagok kézbesítése mentés nélkül a sorrendben. Az egyetlen hátránya ennek a módszernek, hogy azért, mert az ügyfél előtt, hogy az ügyfél-index és teljes körű kapcsolatot, először meg kell, hogy a kapcsolat a támogatási csomag. és a szerver nyomon követi, hogy az ügyfél megerősíti ellenőrzi a hely minden ügyfél számára.
megerősítést zászlót minden ügyfél kezdetben hamis és igaz lesz, ha a szerver kap egy ügyfélszolgálati csomag kapcsolat vagy csomag hasznos. Míg az ügyfél nem erősítették meg, minden alkalommal elküldi a csomag hasznos küldeni az ügyfél előre csomagolt és fenntartása kapcsolat. Ez biztosítja, hogy a statisztikai valószínűsége annak, hogy az ügyfél tudja az index, és teljes mértékben csatlakozik az átvételét az első csomag hasznos, ami minimálisra csökkenti a kapcsolatok száma telepítési ciklust.
Miután a kliens és a szerver kapcsolat teljes mértékben végre tudják cserélni UDP-csomagok mindkét irányban. Normális szerencsejáték protokollok küld a megadott játékosnak adatokat az ügyfél és a kiszolgáló nagy sebességgel, például másodpercenként 60-szor, és az állam a világ a szerver a kliens egy kicsit ritkábban, például másodpercenként 20-szor. Azonban a legtöbb modern játékok AAA-szerver adatok frissítési sebesség megnő.
Ha a szerver, vagy az ügyfél nem adja át a folyamatos stream a csomagokat, amelyek automatikusan generált a kapcsolatot támogató csomagokat a kapcsolat nem szakad meg időtúllépés miatt. Ha rövid időn belül, például öt másodperc, mindkét fél nem kapott csomagot, megszakítja a kapcsolatot timeout.
Ha valamelyik fél kifejezetten akarja szakítani a kapcsolatot, a csomagok száma küldött-kapcsolat befejeződött. hogy a magas statisztikai valószínűsége a csomagok még abban az esetben részleges elvesztése. Ez lehetővé teszi, hogy gyorsan befejezni a kapcsolatot a másik fél nem számíthat timeout.
következtetés
A népszerű internetes játékok, mint agar.io adat átvitele révén WebSockets TCP, akkor a kliens-szerver struktúra keretében dedikált szerverek használata WebRTC nehéz.
Az egyik megoldás, hogy a Google -, hogy az integráció támogatása WebRTC adatcsatornáinak dedikált szerverek sokkal könnyebb a játékfejlesztők.
Vagy használhatja netcode.io. alkalmazásával egy sokkal egyszerűbb megoldás, mint a «WebSockets UDP». Ha szabványosítása, és beépített böngésző, akkor is megoldja a problémát.
Glenn Fiedler (Glenn Fiedler) - alapítója és elnöke a hálózati protokoll Company. Szolgáltatásokat nyújt hálózat létrehozásáról a játék. Mielőtt a céget Glenn volt, a vezető programozó Respawn Entertainment, ahol ő dolgozott Titanfall 1. és 2..