A QUIC protokollt rendkívül érdekes nézni, ezért szeretünk írni róla. De ha a QUIC-ról szóló korábbi publikációk inkább történelmi (ha úgy tetszik, helytörténeti) jellegűek és hardver jellegűek voltak, akkor ma egy másfajta fordítást is szívesen publikálunk - a protokoll valós alkalmazásáról 2019-ben fogunk beszélni. Ráadásul nem egy úgynevezett garázsban épült kis infrastruktúráról beszélünk, hanem a szinte az egész világon működő Uberről. Hogyan jutottak el a cég mérnökei arra a döntésre, hogy a QUIC-ot a gyártásban használják, hogyan végezték el a teszteket, és mit láttak a gyártásban való bevezetése után - a vágás alatt.
A képek kattinthatóak. Élvezd az olvasást!
Az Uber globális léptékű, nevezetesen 600 jelenléti város, amelyek mindegyikében az alkalmazás teljes mértékben több mint 4500 mobilszolgáltató vezeték nélküli internetére támaszkodik. A felhasználók azt várják, hogy az alkalmazás ne csak gyors, hanem valós időben működjön – ennek eléréséhez az Uber alkalmazásnak alacsony késleltetésre és nagyon megbízható kapcsolatra van szüksége. Jaj, de a verem nem működik jól dinamikus és veszteséges vezeték nélküli hálózatokban. Felismertük, hogy ebben az esetben az alacsony teljesítmény közvetlenül összefügg az operációs rendszermagokban található TCP-megvalósításokkal.
A probléma megoldására jelentkeztünk , egy modern csatorna multiplexelési protokoll, amely nagyobb ellenőrzést biztosít a szállítási protokoll teljesítménye felett. Jelenleg a munkacsoport szabványosítja a QUIC-ot mint .
Kiterjedt tesztelés után arra a következtetésre jutottunk, hogy a QUIC alkalmazása az alkalmazásunkban alacsonyabb késleltetést eredményezne a TCP-hez képest. 10-30%-os csökkenést figyeltünk meg a HTTPS-forgalomban a vezető és az utasok alkalmazásában. A QUIC ezenkívül teljes körű vezérlést adott a felhasználói csomagok felett.
Ebben a cikkben megosztjuk tapasztalatainkat a TCP Uber-alkalmazásokhoz való optimalizálásával kapcsolatban egy olyan verem használatával, amely támogatja a QUIC-ot.
A legújabb technológia: TCP
Manapság a TCP a leggyakrabban használt szállítási protokoll a HTTPS forgalom interneten történő továbbítására. A TCP megbízható bájtfolyamot biztosít, ezáltal megbirkózik a hálózati torlódásokkal és a kapcsolati réteg veszteségeivel. A TCP elterjedt használata HTTPS-forgalomhoz annak köszönhető, hogy az előbbi mindenütt jelen van (majdnem minden operációs rendszer tartalmaz TCP-t), a legtöbb infrastruktúra rendelkezésre állása (például terheléselosztók, HTTPS-proxy-k és CDN-ek), valamint a rendelkezésre álló készenléti funkcionalitás. szinte a legtöbb platformon és hálózaton.
A legtöbb felhasználó útközben használja alkalmazásunkat, és a TCP-végek késése közel sem felelt meg a valós idejű HTTPS-forgalom követelményeinek. Egyszerűen fogalmazva, a felhasználók világszerte tapasztalták ezt – az 1. ábra a nagyobb városokban tapasztalható késéseket mutatja:
1. ábra: A farok késése az Uber fő városaiban eltérő.
Bár az indiai és brazil hálózatok késleltetése magasabb volt, mint az Egyesült Államokban és az Egyesült Királyságban, a farok késleltetése lényegesen magasabb az átlagos késleltetésnél. És ez még az Egyesült Államokra és az Egyesült Királyságra is igaz.
TCP over the air teljesítmény
A TCP ehhez jött létre vezetékes hálózatok, vagyis a nagy hangsúlyt fektetve a jól kiszámítható linkekre. Azonban, vezeték nélküli a hálózatoknak megvannak a maguk sajátosságai és nehézségei. Először is, a vezeték nélküli hálózatok érzékenyek az interferencia és a jelgyengülés miatti veszteségekre. Például a Wi-Fi hálózatok érzékenyek a mikrohullámú, bluetooth és egyéb rádióhullámokra. A mobilhálózatok jelveszteségtől szenvednek () a jel tárgyak és épületek általi visszaverődése/elnyelése miatt, valamint a a szomszédból . Ez jelentősebb (4-10-szeres) és változatosabb eredményhez vezet és csomagvesztés a vezetékes kapcsolathoz képest.
A sávszélesség-ingadozások és -veszteségek leküzdésére a mobilhálózatok általában nagy puffereket használnak a forgalmi hullámokhoz. Ez túlzott sorban álláshoz vezethet, ami hosszabb késéseket jelent. A TCP nagyon gyakran pazarlásként kezeli ezt a sorban állást a meghosszabbított időtúllépés miatt, így a TCP hajlamos közvetíteni és ezáltal kitölteni a puffert. Ez a probléma az úgynevezett (), és ez nagyon modern internet.
Végül a mobilhálózat teljesítménye szolgáltatónként, régiónként és időnként változik. A 2. ábrán összegyűjtöttük a HTTPS-forgalom medián késését a cellák között 2 kilométeres tartományon belül. Az indiai Delhi két nagy mobilszolgáltatójáról gyűjtött adatok. Mint látható, a teljesítmény cellánként változik. Ezenkívül az egyik operátor termelékenysége eltér a másodikétól. Ezt olyan tényezők befolyásolják, mint a hálózati belépési minták az időt és a helyet figyelembe véve, a felhasználók mobilitása, valamint a hálózati infrastruktúra a torony sűrűségét és a hálózattípusok arányát (LTE, 3G stb.) figyelembe véve.
2. ábra Késések példaként 2 km-es sugárral. Delhi, India.
Ezenkívül a mobilhálózatok teljesítménye idővel változik. A 3. ábra a medián késleltetést mutatja a hét napjai szerint. Kisebb skálán, egyetlen napon és órán belül is megfigyeltünk különbségeket.
3. ábra. A farok késleltetése napok között jelentősen eltérhet, de ugyanazon kezelő esetében.
A fentiek mindegyike hatástalanná teszi a TCP teljesítményét a vezeték nélküli hálózatokban. Mielőtt azonban a TCP alternatíváit keresnénk, a következő pontokat szerettük volna pontosítani:
- vajon a TCP a fő bűnös az alkalmazásaink késleltetése mögött?
- A modern hálózatok jelentős és változatos oda-vissza késéseket (RTT) tartalmaznak?
- Milyen hatással van az RTT és a veszteség a TCP teljesítményére?
TCP teljesítményelemzés
Ahhoz, hogy megértsük, hogyan elemeztük a TCP teljesítményét, vessünk egy rövid pillantást arra, hogy a TCP hogyan továbbítja az adatokat a küldőtől a vevőhöz. Először a küldő háromirányú TCP-kapcsolatot hoz létre : A küldő SYN csomagot küld, megvárja a SYN-ACK csomagot a fogadótól, majd küld egy ACK csomagot. További második és harmadik lépést a TCP-kapcsolat létrehozása tölt el. A címzett minden egyes csomag átvételét nyugtázza (ACK) a megbízható kézbesítés biztosítása érdekében.
Ha egy csomag vagy ACK elveszik, a küldő egy időkorlát után újraküldi (RTO, ). Az RTO kiszámítása különféle tényezők, például a küldő és a címzett közötti várható RTT-késleltetés alapján dinamikusan történik.
4. ábra: TCP/TLS-en keresztüli csomagcsere tartalmaz egy újraküldési mechanizmust.
Annak meghatározásához, hogy a TCP hogyan teljesít az alkalmazásainkban, a TCP-csomagokat figyeltük egy hétig az indiai szélső szerverekről érkező harci forgalomról. Ezután elemeztük a TCP-kapcsolatokat a segítségével . Ezenkívül létrehoztunk egy Android alkalmazást, amely emulált forgalmat küld egy tesztszervernek, amennyire csak lehetséges, utánozva a valódi forgalmat. Az ezzel az alkalmazással rendelkező okostelefonokat több alkalmazottnak osztották ki, akik több napon keresztül gyűjtötték a naplókat.
A két kísérlet eredményei összhangban voltak egymással. Magas RTT késéseket láttunk; a farokértékek közel hatszor magasabbak voltak, mint a medián érték; a késések számtani átlaga több mint 6 másodperc. Sok kapcsolat veszteséges volt, ami miatt a TCP az összes csomag 1%-át küldte újra. A zsúfolt területeken, például repülőtereken és vasútállomásokon 3,5%-os veszteséget tapasztaltunk. Ezek az eredmények megkérdőjelezik azt a hagyományos bölcsességet, amelyet a mobilhálózatokban használnak jelentősen csökkenti a veszteségeket a szállítás szintjén. Az alábbiakban a „szimulátor” alkalmazás teszteredményei találhatók:
Hálózati mutatók
jelentés
RTT, ezredmásodperc [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT eltérés, másodperc
Átlagosan ~1,2 s
Csomagvesztés instabil kapcsolatokon
Átlagosan ~3.5% (7% túlterhelt területeken)
Ezeknek a kapcsolatoknak csaknem felében volt legalább egy csomagvesztés, legtöbbjük SYN és SYN-ACK csomag. A legtöbb TCP-megvalósítás 1 másodperces RTO-értéket használ a SYN-csomagokhoz, amely exponenciálisan növekszik a későbbi veszteségek esetén. Az alkalmazások betöltési ideje megnőhet, mivel a TCP-vel hosszabb ideig tart a kapcsolatok létrehozása.
Adatcsomagok esetén a magas RTO értékek nagymértékben csökkentik a hálózat hasznos kihasználását a vezeték nélküli hálózatok átmeneti veszteségei esetén. Azt találtuk, hogy az átlagos újraadási idő körülbelül 1 másodperc, a farok késleltetése pedig csaknem 30 másodperc. Ezek a magas TCP-szintű késések HTTPS-időtúllépéseket és újbóli kéréseket okoztak, tovább növelve a hálózati késést és a hatékonyságot.
Míg a mért RTT 75. percentilis 425 ms körül volt, addig a TCP 75. percentilis majdnem 3 másodperc volt. Ez arra utal, hogy a veszteség miatt a TCP-nek 7-10 lépést kellett megtennie az adatok sikeres továbbításához. Ez a nem hatékony RTO-számítás következménye lehet, a TCP képtelensége gyorsan reagálni a veszteségre ablakban, valamint a torlódás-ellenőrző algoritmus hatékonyságának hiánya, amely nem tesz különbséget a vezeték nélküli és a hálózati torlódás miatti veszteségek között. Az alábbiakban a TCP-vesztési tesztek eredményei vannak:
TCP csomagvesztési statisztika
Érték
A legalább 1 csomagvesztést mutató kapcsolatok százalékos aránya
45%
A kapcsolat felállítása során veszteséges kapcsolatok százalékos aránya
30%
Az adatcsere során veszteséges kapcsolatok százalékos aránya
76%
Az újraadási késések megoszlása, másodperc [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Az újraküldések számának megoszlása egy csomagra vagy TCP-szegmensre
[1,3,6,7]
A QUIC alkalmazása
Az eredetileg a Google által kifejlesztett QUIC egy többszálas modern szállítási protokoll, amely UDP-n fut. Jelenleg a QUIC be van kapcsolva (Már írtuk, hogy a QUIC-nak két verziója van, érdekes – kb. fordító). Amint az 5. ábrán látható, a QUIC a HTTP/3 alá van helyezve (valójában a QUIC feletti HTTP/2 a HTTP/3, amelyet jelenleg intenzíven szabványosítanak). Részben lecseréli a HTTPS és TCP rétegeket azáltal, hogy UDP-t használ a csomagok létrehozására. A QUIC csak a biztonságos adatátvitelt támogatja, mivel a TLS teljes mértékben be van építve a QUIC-ba.
5. ábra: A QUIC HTTP/3 alatt fut, felváltva a TLS-t, amely korábban HTTP/2 alatt futott.
Az alábbiakban felsoroljuk azokat az okokat, amelyek meggyőztek minket a QUIC használatáról a TCP-erősítéshez:
- 0-RTT kapcsolat létrehozása. A QUIC lehetővé teszi a korábbi kapcsolatokból származó jogosultságok újrafelhasználását, csökkentve a biztonsági kézfogások számát. A jövőben támogatja a 0-RTT-t, de háromutas TCP-kézfogásra továbbra is szükség lesz.
- a HoL-blokkolás leküzdése. A HTTP/2 ügyfelenként egy TCP-kapcsolatot használ a teljesítmény javítása érdekében, de ez HoL (head-of-line) blokkoláshoz vezethet. A QUIC leegyszerűsíti a multiplexelést, és függetlenül kézbesíti a kéréseket az alkalmazáshoz.
- torlódások szabályozása. A QUIC az alkalmazási rétegben található, így könnyebben frissíthető a fő szállítási algoritmus, amely a hálózati paraméterek (a veszteségek száma vagy RTT) alapján vezérli a küldést. A legtöbb TCP-megvalósítás ezt az algoritmust használja , ami nem optimális a késleltetésre érzékeny forgalom számára. A közelmúltban kifejlesztett algoritmusok, mint pl , pontosabban modellezi a hálózatot és optimalizálja a késleltetést. A QUIC lehetővé teszi a BBR használatát és az algoritmus frissítését a használat során. .
- veszteségek pótlása. A QUIC két TLP-t hív meg () az RTO aktiválása előtt – még akkor is, ha a veszteségek nagyon észrevehetők. Ez eltér a TCP-megvalósításoktól. A TLP elsősorban az utolsó csomagot (vagy az újat, ha van) újraküldi, hogy gyors feltöltést indítson el. A farokkésések kezelése különösen hasznos az Uber hálózatának működésében, nevezetesen a rövid, szórványos és késleltetésre érzékeny adatátvitelek esetén.
- optimalizált ACK. Mivel minden csomagnak egyedi sorszáma van, nincs probléma csomagokat, amikor újraküldik. Az ACK-csomagok időt is tartalmaznak a csomag feldolgozására és az ügyféloldalon ACK generálására. Ezek a funkciók biztosítják, hogy a QUIC pontosabban számítsa ki az RTT-t. Az ACK a QUIC-ban legfeljebb 256 sávot támogat , segítve a küldőt, hogy ellenállóbb legyen a csomagkeveréssel szemben, és kevesebb bájtot használjon fel a folyamat során. Szelektív ACK () a TCP-ben nem minden esetben oldja meg ezt a problémát.
- kapcsolat migráció. A QUIC kapcsolatokat egy 64 bites azonosító azonosítja, így ha egy kliens megváltoztatja az IP-címet, a régi kapcsolatazonosító továbbra is megszakítás nélkül használható az új IP-címen. Ez nagyon gyakori gyakorlat a mobilalkalmazásoknál, ahol a felhasználó Wi-Fi és mobil kapcsolat között vált.
A QUIC alternatívái
A QUIC választása előtt fontolóra vettük a probléma megoldásának alternatív megközelítéseit.
Az első dolog, amit megpróbáltunk, a TPC PoP-ok (Points of Presence) telepítése volt, hogy a TCP-kapcsolatokat a felhasználókhoz közelebb szüntessék meg. Lényegében a PoP-ok egy TCP-kapcsolatot zárnak le egy mobileszközzel, amely közelebb van a mobilhálózathoz, és a forgalmat visszaküldi az eredeti infrastruktúrához. A TCP közelebbi lezárásával potenciálisan csökkenthetjük az RTT-t, és biztosíthatjuk, hogy a TCP jobban reagáljon a dinamikus vezeték nélküli környezetre. Kísérleteink azonban kimutatták, hogy az RTT és a veszteség nagy része a mobilhálózatokból származik, és a PoP-ok használata nem eredményez jelentős teljesítménynövekedést.
Megvizsgáltuk a TCP paraméterek hangolását is. A TCP-verem beállítása a heterogén peremszervereinken nehéz volt, mert a TCP-nek eltérő implementációi vannak a különböző operációs rendszer-verziókban. Nehéz volt ezt megvalósítani és különböző hálózati konfigurációkat tesztelni. A TCP közvetlen konfigurálása mobileszközökön nem volt lehetséges az engedélyek hiánya miatt. Ennél is fontosabb, hogy az olyan szolgáltatások, mint a 0-RTT kapcsolatok és a továbbfejlesztett RTT előrejelzés kritikus fontosságúak a protokoll architektúrája szempontjából, ezért lehetetlen jelentős előnyöket elérni a TCP önmagában történő hangolásával.
Végül kiértékeltünk több UDP-alapú protokollt, amelyek a videostreaming hibaelhárítására szolgálnak – azt akartuk látni, hogy ezek a protokollok segítenek-e a mi esetünkben. Sajnos sok biztonsági beállításból súlyos hiányosságok mutatkoztak, és további TCP-kapcsolatra volt szükség a metaadatokhoz és a vezérlőinformációkhoz.
Kutatásunk kimutatta, hogy a QUIC talán az egyetlen protokoll, amely segíthet az internetes forgalom problémáján, miközben a biztonságot és a teljesítményt is figyelembe veszi.
A QUIC integrálása a platformba
A QUIC sikeres beágyazása és az alkalmazások teljesítményének javítása érdekében gyenge csatlakozási környezetben a régi verem (HTTP/2 over TLS/TCP) helyett a QUIC protokollt. A hálózati könyvtárat használtuk A , amely tartalmazza a protokoll eredeti, Google verzióját - gQUIC. Ezt a megvalósítást is folyamatosan fejlesztik, hogy kövesse a legújabb IETF specifikációt.
Először integráltuk a Cronetet Android-alkalmazásainkba, hogy a QUIC-t is támogassuk. Az integrációt úgy hajtották végre, hogy a migrációs költségeket a lehető legnagyobb mértékben csökkentsék. Ahelyett, hogy teljesen lecserélné a könyvtárat használó régi hálózati veremet , integráltuk a Cronetet az OkHttp API keretrendszerébe. Az integráció ilyen módon történő végrehajtásával elkerültük a hálózati hívásaink módosítását (amelyeket a ) API-szinten.
Hasonlóan az Android-eszközökhöz, a Cronetet az Uber-alkalmazásokban implementáltuk iOS rendszeren, elfogva a hálózat HTTP-forgalmát. segítségével . Ez az iOS Foundation által biztosított absztrakció a protokoll-specifikus URL-adatokat kezeli, és biztosítja, hogy jelentős migrációs költségek nélkül tudjuk integrálni a Cronetet iOS-alkalmazásainkba.
A QUIC befejezése a Google Cloud Balancers szolgáltatásban
A háttéroldalon a QUIC kiegészítést a Google Cloud Load terheléselosztási infrastruktúra biztosítja, amely fejlécek a válaszokban a QUIC támogatására. Általában a kiegyenlítő minden HTTP-kéréshez hozzáad egy alt-svc fejlécet, és ez már érvényesíti a tartomány QUIC-támogatását. Amikor egy Cronet-ügyfél HTTP-választ kap ezzel a fejléccel, akkor a QUIC-t használja az adott tartományba irányuló további HTTP-kérésekhez. Amint a kiegyenlítő befejezte a QUIC-t, infrastruktúránk kifejezetten elküldi ezt a műveletet HTTP2/TCP-n keresztül adatközpontjainknak.
Teljesítmény: Eredmények
A kimeneti teljesítmény a fő oka annak, hogy jobb protokollt keresünk. Kezdésként létrehoztunk egy állványt hogy megtudja, hogyan fog viselkedni a QUIC különböző hálózati profilokban. A QUIC valós hálózatokon való teljesítményének tesztelése érdekében kísérleteket futtattunk Újdelhiben járva, emulált hálózati forgalom felhasználásával, amely nagyon hasonlít az utasalkalmazás HTTP-hívásaihoz.
1. kísérlet
A kísérlethez szükséges felszerelések:
- Android-eszközök tesztelése OkHttp és Cronet veremekkel, hogy megbizonyosodjon arról, hogy engedélyezzük a HTTPS-forgalmat TCP-n és QUIC-n keresztül;
- egy Java-alapú emulációs szerver, amely válaszokban ugyanolyan típusú HTTPS-fejléceket küld, és betölti az ügyféleszközöket, hogy kéréseket fogadjon tőlük;
- felhő-proxy, amelyek fizikailag India közelében találhatók a TCP- és QUIC-kapcsolatok megszüntetésére. Míg a TCP-lezáráshoz fordított proxyt használtunk , nehéz volt nyílt forráskódú fordított proxyt találni a QUIC számára. Mi magunk építettünk egy fordított proxyt a QUIC számára a Chromium és az alapvető QUIC verem segítségével krómmá nyílt forráskódként.
6. ábra: A TCP vs QUIC közúti tesztcsomag OkHttp-vel és Cronet-tel rendelkező Android-eszközökből, a kapcsolatok lezárására szolgáló felhőproxyból és egy emulációs szerverből állt.
2. kísérlet
Amikor a Google elérhetővé tette a QUIC-ot a következővel , ugyanazt a leltárt használtuk, de egyetlen módosítással: az NGINX helyett a Google terheléselosztókat vettük igénybe, hogy megszakítsák a TCP és QUIC kapcsolatokat az eszközökről, valamint a HTTPS forgalmat irányítsák az emulációs szerverre. A kiegyenlítők az egész világon el vannak terjesztve, de az eszközhöz legközelebb eső PoP szervert használják (hála a földrajzi helymeghatározásnak).
7. ábra A második kísérletben a TCP és a QUIC befejezési késleltetését szerettük volna összehasonlítani: a Google Cloud és a felhőproxy használatával.
Ennek eredményeként számos kinyilatkoztatás várt ránk:
- a PoP-n keresztüli leállítás javította a TCP teljesítményét. Mivel a kiegyenlítők a felhasználókhoz közelebb zárják le a TCP-kapcsolatokat, és nagyon optimalizáltak, ez alacsonyabb RTT-t eredményez, ami javítja a TCP teljesítményét. És bár a QUIC kevésbé volt érintett, még mindig felülmúlta a TCP-t a farok késleltetésének csökkentésében (10-30 százalékkal).
- a farok érintett . Bár a QUIC-proxy távolabb volt az eszközöktől (körülbelül 50 ms-mal nagyobb késleltetés), mint a Google terheléselosztói, hasonló teljesítményt nyújtott – 15%-kal csökkentette a késleltetést, szemben a TCP 20. percentilisének 99%-os csökkenésével. Ez arra utal, hogy az utolsó mérföldes átmenet szűk keresztmetszet a hálózatban.
8. ábra: Két kísérlet eredménye azt mutatja, hogy a QUIC jelentősen felülmúlja a TCP-t.
Harci forgalom
A kísérletezés ihletésére bevezettük a QUIC támogatást Android és iOS alkalmazásainkban. A/B tesztelést végeztünk, hogy meghatározzuk a QUIC hatását azokban a városokban, ahol az Uber működik. Általánosságban elmondható, hogy mindkét régióban, a távközlési szolgáltatóknál és a hálózattípusnál jelentősen csökkent a késések száma.
Az alábbi grafikonok a sávok (95 és 99 percentilis) százalékos javulását mutatják makrorégiók és különböző hálózattípusok szerint – LTE, 3G, 2G.
9. ábra: A harci tesztekben a QUIC felülmúlta a TCP-t a várakozási idő tekintetében.
Csak előre
Talán ez még csak a kezdet - a QUIC éles kiadása elképesztő lehetőségeket kínált az alkalmazások teljesítményének javítására mind a stabil, mind az instabil hálózatokban, nevezetesen:
Megnövelt lefedettség
A protokoll valós forgalomra vonatkozó teljesítményének elemzése után azt láttuk, hogy a munkamenetek körülbelül 80%-a sikeresen használta a QUIC-ot minden kéréseket, míg a munkamenetek 15%-a a QUIC és a TCP kombinációját használta. Feltételezzük, hogy a kombináció annak köszönhető, hogy a Cronet könyvtár időtúllépése visszatér a TCP-hez, mivel nem tud különbséget tenni a valódi UDP-hibák és a rossz hálózati feltételek között. Jelenleg keressük a megoldást erre a problémára, miközben a QUIC későbbi megvalósításán dolgozunk.
QUIC optimalizálás
A mobilalkalmazásokból származó forgalom késleltetésérzékeny, de nem érzékeny a sávszélességre. Ezenkívül alkalmazásainkat elsősorban mobilhálózatokon használják. A kísérletek alapján a késleltetési idő még mindig magas, még akkor is, ha proxyt használnak a TCP és a QUIC leállítására a felhasználók közelében. Aktívan keressük a torlódáskezelés javításának és a QUIC veszteség-helyreállítási algoritmusok hatékonyságának javításának módjait.
Ezekkel és számos további fejlesztéssel azt tervezzük, hogy hálózattól és régiótól függetlenül javítjuk a felhasználói élményt, így a kényelmes és zökkenőmentes csomagszállítást világszerte elérhetőbbé tesszük.
Forrás: will.com