RDP UDP-n keresztül vs TCP: Teljesítmény, Finomhangolás és Legjobb Gyakorlatok

Bevezetés

A Távoli Asztali Protokoll (RDP) számos távoli hozzáférési telepítést alapoz meg, a kis IT támogatási beállításoktól kezdve a nagyvállalati környezetekig. Mégis, egy kulcsfontosságú teljesítményi tényező gyakran figyelmen kívül marad: hogy az RDP forgalom elsősorban TCP-n vagy UDP-n keresztül áramlik-e. Ez a választás közvetlen hatással van a késleltetésre, a reakcióidőre és a felhasználói élményre, különösen WAN-ok és VPN-ek esetén. Ebben az útmutatóban elmagyarázzuk, hogyan használja az RDP az UDP-t és a TCP-t, mikor teljesít a legjobban mindkét szállítás, és mit állíthat be a Windows-ban és a hálózatában a simább, megbízhatóbb távoli munkamenetek biztosítása érdekében.

Miért fontos az RDP szállítási választás a távoli teljesítmény szempontjából?

RDP már nem csak egy egyszerű „képernyőkaparó”. A modern RDP tömörített grafikát, multimédiát, bemeneti eseményeket, nyomtatási adatokat és vágólap tartalmat hordoz. Ezek közül a stream-ek közül mindegyik másképp reagál a késleltetésre és a csomagvesztésre. Ha a rossz szállítást használják, a felhasználók késlekedést, akadozó videót vagy lassú billentyűzet-választ tapasztalnak, még akkor is, ha a sávszélesség rendben van.

A RDP mikor preferálja az UDP-t a TCP-val szemben, segít az IT csapatoknak átjárók, VPN-ek és tűzfal szabályok ami valódi teljesítményt támogat, nem csupán „zöld pipa” a megfigyelő műszerfalakon. Ez különösen fontos vegyes környezetekben, ahol egyes felhasználók optikai kábelen csatlakoznak, míg mások forgalmas VPN koncentrátorokon vagy mobil hotspotokon keresztül.

Mik a TCP és UDP alapjai RDP esetén?

• A TCP garanciái
• Amit az UDP optimalizál

A TCP mit garantál (és miért költséges a késleltetés)

A Transmission Control Protocol (TCP) kapcsolat-orientált. TCP létrehozza a munkamenetet, csomagok számát, elismeri őket, és újraküldi az elveszett csomagokat. Ez a tervezés garantálja a sorrendben történő, megbízható kézbesítést, ami ideális fájlátvitelekhez, webforgalomhoz és e-mailekhez. Azonban minden újraküldés késleltetést ad hozzá, és a torlódáskezelő algoritmusok tovább lassítják a teljesítményt, amikor csomagvesztés történik.

Az RDP esetében ez azt jelenti, hogy egyetlen elveszett csomag blokkolhatja a további képernyőfrissítéseket, amíg a helyreállítás be nem fejeződik. Magas késleltetésű vagy veszteséges kapcsolatokon a TCP felnagyíthatja a jittert, és létrehozhat egy „ragadós” asztalt, ahol az egér és a billentyűzet késlekedve reagál, még akkor is, ha a kapcsolat technikailag működik.

Amit az UDP optimalizál (és ahol megszakadhat)

A Felhasználói Datagram Protokoll (UDP) kapcsolat nélküli és könnyű. Az UDP nem követi az állapotot, nem végez kézfogásokat, és nem garantálja a kézbesítést; egyszerűen datagramokat küld, és hagyja, hogy az alkalmazás foglalkozzon a veszteséggel vagy a sorrenddel. A többlet hiánya vonzóvá teszi az UDP-t a hang, a videó és a játékok számára, ahol az időzítés fontosabb, mint a tökéletes kézbesítés.

Amikor az RDP UDP-t használ, a grafika és a bemenet alacsonyabb késleltetéssel és magasabb áteresztőképességgel szállítható. Ha egy keret elveszik, az RDP küldhet egy újabbat a várakozás helyett. Ha azonban a csomagvesztés vagy a jitter magas, a munkamenet látható artefaktumokat vagy "blokkos" frissítéseket mutathat, mert a protokoll a frissességet részesíti előnyben a garantált rekonstrukcióval szemben.

Hogyan használja a modern RDP a TCP-t és az UDP-t együtt?

• Kettős szállítási architektúra az RDP 8.0-tól kezdődően
• RemoteFX, Grafika és Bemenet UDP-n keresztül

Kettős szállítási architektúra az RDP 8.0-tól kezdődően

Eredetileg az RDP kizárólag a TCP-re támaszkodott. A RDP 8.0-val (Windows 8 és Windows Server 2012) a Microsoft egy kettős szállítási modellt vezetett be, amely a TCP-t és az UDP-t együtt használja. Az RDP továbbra is egy TCP kapcsolattal kezdődik a képességek és a biztonság tárgyalására, majd megpróbál párhuzamos UDP csatornát létrehozni a média és a grafika számára.

Ha az UDP elérhető és a szabályzatok megengedik, az RDP a megfelelő forgalmat az UDP csatornára irányítja, miközben a TCP-t kontroll- és visszaállási útként megtartja. Ha az UDP nem hozható létre, az RDP teljesen TCP-n keresztül folytatódik, biztosítva a kompatibilitást a régebbi hálózatokkal és a korlátozó tűzfalakkal.

RemoteFX, Grafika és Bemenet UDP-n keresztül

A kettős csatornás modellel az RDP tömörített grafikákat, bitképeket és néhány bemeneti eseményt tud küldeni UDP-n keresztül. Ez javítja a válaszidőt a tipikus WAN forgatókönyvekben, különösen, amikor az asztalok gazdag felhasználói felületeket, streaming irányítópultokat vagy videót jelenítenek meg. A RemoteFX és a kapcsolódó optimalizálások ezt a viselkedést figyelembe véve lettek tervezve.

A gyakorlatban a felhasználók gyorsabb ablakmozgásokat, simább görgetést és gyorsabb képernyőfrissítéseket észlelnek, amikor az UDP aktív stabil hálózatokon. Az adminisztrátori oldalon ez a viselkedés többnyire automatikus; a fő feladat annak biztosítása, hogy az UDP engedélyezve legyen, és hogy a Csoportházirend ne tiltsa le.

Hogyan hasonlítható össze az UDP és a TCP teljesítménye?

• Mellékelt Összehasonlító Táblázat
• Gyakorlati forgatókönyvek: WAN, VPN és LAN

Mellékelt Összehasonlító Táblázat

Funkció / forgatókönyv	RDP TCP-n keresztül	RDP UDP-n keresztül
Megbízhatóság	Magas, megrendelt szállítás visszaküldéssel	Legjobb erőfeszítés, nincs szállítási vagy rendelési garancia
Késleltetés	Magasabb, különösen veszteség alatt	Alacsonyabb, toleránsabb a jitterrel szemben
Áteresztőképesség	Csökkentve az elismerések és a torlódás kezelésével	Magasabb, kevesebb protokolltúlterhelés
Legjobb hálózati feltételek	Magas veszteségű, kiszámíthatatlan vagy erősen formált linkek	Stabil, alacsony veszteségű, alacsony késleltetésű hálózatok
Tűzfal/VPN kompatibilitás	Kiváló; TCP 3389-et használ	Lehet, hogy explicit UDP 3391 szabályokra van szükség a tűzfalakon és a VPN-eken.
Visszaállítási viselkedés	Mindig elérhető	Használatkor elérhető; problémák esetén TCP-re vált.
Felhasználói észlelés	Biztonságos, de néha késlekedő.	“Gyors és folyékony”, amikor a körülmények megfelelőek.

A laboratóriumi és terepi tesztek során az RDP UDP-n keresztül többszörösére képes növelni a TCP hatékony átvitelét tiszta hálózatokon, ami magasabb felbontást, jobb videolejátszást és simább kurzormozgást eredményez. A tényleges javulás a sávszélességtől, a veszteségtől és attól függ, hogy a hálózat mennyire agresszíven formálja a forgalmat.

Gyakorlati forgatókönyvek: WAN, VPN és LAN

Alacsony késleltetésű és elhanyagolható csomagveszteségű vezetékes LAN-on az UDP általában a világos győztes. A felhasználók közel helyi válaszidőt élveznek, még akkor is, ha egy másik emeletről vagy épületből csatlakoznak. Kezelt WAN vagy SD-WAN kapcsolaton az UDP szintén jobban teljesít, amennyiben QoS be van állítva, és a csomagveszteség mérsékelt marad.

Túlterhelt VPN-eken, mobil hotspotokon vagy műholdas kapcsolatokon a TCP stabilabb élményt nyújthat. A torlódáskezelő mechanizmusai alkalmazkodni tudnak a változó körülményekhez, míg az UDP forgalom akadozóvá vagy vizuálisan romlottá válhat. Ezekben a helyzetekben a prioritás egy kiszámítható, ha kissé lassabb, munkamenet.

Mikor válasszuk a UDP-t a TCP helyett RDP munkamenetekhez?

• Ideális feltételek RDP-hez UDP-n keresztül
• Amikor a TCP a biztonságosabb alapértelmezett

Ideális feltételek RDP-hez UDP-n keresztül

A legtöbb modern telepítés esetén az UDP-t kell célozni, amikor csak lehetséges. Az UDP ideális, ha a hálózat stabil késleltetéssel, alacsony veszteséggel és ésszerű sávszélesség-tartalékkal rendelkezik. Nagy sebességű LAN-ok, jól kezelt MPLS vagy SD-WAN körök, és az adatközpont-az-ágak kapcsolatok jellemzően illeszkednek ehhez a profilhoz.

Az UDP szintén a jobb választás, amikor a végfelhasználók média-gazdag alkalmazásokkal, gyakori frissítésekkel rendelkező irányítópultokkal vagy olyan UI keretrendszerekkel dolgoznak, amelyek nagy részeket újrarajzolnak a képernyőn. Ezeknél a munkaterheléseknél a késleltetés csökkentése nagyobb hatással van a észlelt teljesítményre, mint a nyers megbízhatóság maximalizálása.

Amikor a TCP a biztonságosabb alapértelmezett

A TCP továbbra is értékes a barátságtalan vagy kiszámíthatatlan hálózatokban. Ha a felhasználók szállodai Wi-Fi-n, nyilvános hotspotokon vagy gyakori mikro-kiesésekkel rendelkező útvonalakon csatlakoznak, a TCP megbízhatósága és torlódási viselkedése elnézőbb lehet. Hasonlóképpen, néhány régebbi VPN eszköz, proxy vagy ellenőrző berendezés rosszul kezeli az UDP 3391-et, ami arra kényszeríti az RDP-t, hogy a konfigurációtól függetlenül TCP-t használjon.

Ha a szabályozási vagy audit követelmények egyszerű, könnyen magyarázható hálózati szabályokat igényelnek, az adminisztrátorok dönthetnek úgy, hogy bizonyos felhasználói csoportok számára a TCP-t standardizálják. Ezekben az esetekben a cél a világosság és a megfelelés, míg az UDP a megbízható helyek és kezelt végpontok számára van fenntartva.

Hogyan optimalizáljuk az RDP-t az optimális UDP-használathoz?

• Ellenőrizze az RDP verziót és képességeit
• Nyissa meg és érvényesítse a szükséges portokat
• Csoportházirend-beállítások UDP-hez és élményhez
• QoS és Hálózati Szintű Optimalizálások
• Monitor, hogy melyik RDP-t használja a szállítás.

Ellenőrizze az RDP verziót és képességeit

UDP támogatás az RDP 8.0-val kezdődik. Győződjön meg arról, hogy mind az RDP kliens, mind a gazda támogatott verziókat futtat, mint például a Windows 8 / 10 / 11 vagy a Windows Server 2012 és újabb. A Microsoft Learn szerint az újabb RDP funkciók engedélyezése gyakran speciális Windows frissítéseket és a Remote Desktop Services szerepköröket igényel.

Windows kliensen ellenőrizheti a fő RDP verziót a rendszerleíró adatbázisban:

reg query "HKLM\SOFTWARE\Microsoft\Terminal Server Client" /v RDPCoreVersion

Régebbi domainek esetén erősítse meg, hogy a csoportházirendek nem kényszerítik az RDP-t olyan kompatibilitási módokba, amelyek letiltják az UDP-t.

Nyissa meg és érvényesítse a szükséges portokat

RDP használja TCP port 3389 a bázis kapcsolatért és az UDP 3391 portért az optimalizált médiaútvonalhoz a standard konfigurációkban. A tűzfalaknak, routereknek és VPN átjáróknak mindkét irányban engedélyezniük kell ezeket a portokat, ahol alkalmazható.

Dokumentum, amely megmutatja, hogy mely eszközök végeznek NAT-ot vagy ellenőrzést, és ellenőrzi, hogy a UDP 3391 nem kerül-e csendben eldobásra vagy sebességkorlátozásra. Használjon egyszerű eszközöket, mint például Test-NetConnection vagy csomagok rögzítése annak megerősítésére, hogy az UDP csomagok elérik a szervert, és hogy a válaszok láthatók az ügyféloldalon.

Csoportházirend-beállítások UDP-hez és élményhez

Az RDP gazdán vagy a munkamenet gazdán nyissa meg a Csoportházirend-kezelőt, és navigáljon a következőhöz:

Számítógép konfiguráció > Adminisztratív sablonok > Windows összetevők > Távoli asztali szolgáltatások > Távoli asztali munkamenet gazda > Távoli munkamenet környezet

A kulcsbeállítások a következők:

• “Optimalizálja a tapasztalatot az RD Gateway helyett” vagy hasonló tapasztalatoptimalizálások.
• “Használja az UDP szállítást” → állítsa Engedélyezve.

Kerüld el az ellentmondásos irányelveket, amelyek letiltják az UDP-t, miközben engedélyezed a tapasztalatoptimalizálásokat. A változtatások után futtasd gpupdate /force és csatlakoztassa újra a tesztüléseket, hogy megerősítse, hogy a UDP most már használatban van.

QoS és Hálózati Szintű Optimalizálások

Nagyobb környezetekben a Szolgáltatásminőség (QoS) politikák drámaian javíthatják az RDP válaszidejét. Címkézze meg az RDP forgalmat, különösen az UDP áramlásokat, egy megfelelő DSCP értékkel, és biztosítsa, hogy a WAN routerek tiszteletben tartsák ezeket a megjelöléseket. Fontolja meg, hogy az RDP forgalmat egy prioritási vagy biztosított továbbítási osztályba helyezze, ahelyett, hogy hagyná, hogy versenyezzen a tömeges átvitelekkel.

Ugyanakkor tartsuk fenn az MTU-t a VPN-ek és WAN linkek között, hogy elkerüljük a fragmentálódást, ami rontja az UDP teljesítményét. A hálózati csapatoknak figyelniük kell a veszteséget és a jittert a távoli asztali forgalom által használt útvonalakon, hogy azonosítsák a problémás köröket.

Monitor, hogy melyik RDP-t használja a szállítás.

A Windows az RDP szállítási lehetőségeket naplózza az Eseménynézőben a RemoteDesktopServices-RdpCoreTS napló alatt. A gyakori események közé tartozik:

• Eseményazonosító 131: RDP munkamenet létrejött csak TCP használatával
• Event ID 132: UDP szállítás használatban
• Event ID 140: UDP kísérlet történt, de visszaesett TCP-re

Ezeket az eseményeket akkor vizsgálja meg, amikor a felhasználók „lassú” asztalokról számolnak be. Kombinálja őket a hálózati mutatókkal és a csomagok rögzítésével, hogy eldöntse, hogy a megoldás az UDP engedélyezése, a QoS finomhangolása vagy a hálózati útvonalak egyszerűsítése.

Miért tér vissza az RDP a TCP-hez a hibaelhárításhoz?

• Kapcsolódási és tűzfalproblémák
• Politikai, kliens és szerver eltérések

Kapcsolódási és tűzfalproblémák

Ha az RDP folyamatosan TCP-t használ, még modern klienseken és szervereken is, kezdje az alapvető kapcsolati ellenőrzésekkel. Ellenőrizze, hogy a UDP 3391 engedélyezve van-e végponttól végpontig, nem csak a Windows gazdagépen. Azok a tűzfalak, amelyek engedélyezik a TCP 3389-et, de csendben elutasítják a UDP 3391-et, az RDP-t csak TCP módba kényszerítik.

A távoli helyszínek esetében ellenőrizze, hogy a VPN irányelvek vagy az SD-WAN eszközök nem írják-e felül vagy blokkolják az UDP-t. Néhány biztonsági rendszer kifejezett szabályokat vagy "alkalmazásdefiníciókat" igényel az RDP UDP csatornájához. A csomagok rögzítése a alagút mindkét oldalán gyorsan felfedheti, hogy az UDP csomagok megteszik-e az oda-vissza utat.

Politikai, kliens és szerver eltérések

A Csoportházirend kifejezetten letilthatja az UDP szállítást, még akkor is, ha a hálózat engedélyezi azt. Ellenőrizze mind a Számítógép, mind a Felhasználói házirendeket az RDP beállításokhoz, és győződjön meg arról, hogy nincs régebbi sablon, amely felülírná az újabb alapértelmezetteket. Hasonlóképpen, a régi RDP kliensek esetleg nem rendelkeznek teljes UDP támogatással, vagy helyi házirend korlátozhatja őket.

Ellenőrizze, hogy a szerver Távoli Asztali Szolgáltatások konfigurációja összhangban van-e a tartomány biztonsági alapjaival. A korábbi projektekből származó megerősítési sablonok néha letiltják az újabb protokollfunkciókat. Kétség esetén hasonlítsa össze a beállításokat a jelenlegi Microsoft alapokkal és a dokumentációval a Windows Server verziójához.

Fokozza RDP élményét a TSplus Remote Access segítségével

RDP teljesítményének hibaelhárítása vagy egy skálázhatóbb távoli hozzáférési architektúra tervezése? TSplus Távhozzáférés lehetővé teszi asztalok és alkalmazások weben történő közzétételét egy könnyű átjárón, TLS biztonsággal és optimalizált RDP kezeléssel.

Szüksége van biztonságos, megfizethető alkalmazáskiadásra Citrix-szintű bonyolultság nélkül? Kezdje el ingyenes TSplus próbaverzióját, és nézze meg, milyen gyorsan telepítheti a gyors, UDP-optimalizált távoli munkameneteket.

Következtetés

Nincs egyetlen „győztes” az RDP UDP és TCP között. Az UDP a legjobb felhasználói élményt nyújtja tiszta, jól kezelt hálózatokon, alacsony késleltetésű, nagy áteresztőképességű munkamenetek biztosításával. A TCP továbbra is a kompatibilitás és a megbízhatóság alapja, amikor a körülmények kevésbé kiszámíthatóak.

A valódi cél az, hogy a modern RDP-t ott használhassuk UDP-n, ahol csak lehet, miközben megőrizzük az automatikus visszaállást TCP-re, amikor szükséges. A verziók érvényesítésével, a megfelelő portok megnyitásával, a Csoportházirend finomhangolásával és a szállítási használat figyelésével gyors, megbízható távoli asztalokat biztosíthat. TSplus Távhozzáférés segít átalakítani ezt a hangolást egy következetes, biztonságos platformmá a felhasználói számára.