Protokół do zdalnego desktopu

Na rynku znajduje się kilka rozwiązań, które oferują dostęp do zdalnego desktopu. Jednym z kryteriów wyboru technologii jest zachowanie w sieciach o gorszej jakości połączeń.

W Polsce nadal bardzo często są stosowane usługi zdalnego pulpitu Windows, korzystające z protokołu RDP. Najnowsze wydanie usług terminalowych również korzysta z RDP, ale możliwa jest także instalacja z użyciem RemoteFX - technologii pozyskanej razem z firmą Calista Technologies i dostępnej w Windows Server 2008R2. Jej zadaniem jest poprawienie wrażeń pracy użytkownika połączonego za pomocą klienta pulpitu zdalnego do maszyny wirtualnej Windows 7 pracującej w środowisku Hyper-v. Usprawnienia obejmują obsługę grafiki 3D z akceleracją, OpenGL, wideo i przekierowanie USB.

W sieci LAN oba protokoły Microsoftu działają sprawnie, nawet standardowy RDP z powodzeniem wystarczy do obsługi typowej pracy biurowej. Przy pełnoekranowych prezentacjach również się sprawdza, nawet jeśli pojawiają się artefakty, nie pogarszają wrażenia pracy.

Protokoły te zużywają jednak bardzo dużo pasma, gdyż w szczycie przy animacjach Flash lub przy przesyłaniu dużych obrazów pasmo dochodzi do 60 Mbit/s, RemoteFX jest nieco lepszy, ale nadal potrzebuje do 50 Mbit/s.

W rzeczywistych warunkach firmy rzadko dysponuje się tak szerokim pasmem przy niskich obciążeniach. Jeśli wprowadzi się ograniczenie pasma do 2 Mbit/s i wprowadzi opóźnienia rzędu 50 ms, typowe dla WAN, RemoteFX działa o wiele lepiej od RDP przy pobieraniu nieresponsywnej zawartości. Jest to również dobry protokół do usług broadcast i akceleracji 3D, ale ma wysokie wymagania sprzętowe, gdyż niezbędny jest Hyper-V oraz odpowiednia karta graficzna.

Jak przesłać wideo

Protokołami wykorzystywanymi do dostępu do zdalnych desktopów są także HDX Citriksa, PcoIP, z którego korzysta VMware View, EOP Xtream w realizacji firmy Quest oraz Blaze w wykonaniu Ericom. O ile każdy z tych protokołów nadaje się do pracy w typowych środowiskach biurowych przy parametrach 2 MBit/50 ms opóźnienia, o tyle bardzo dużą różnicę widać przy transmisji wideo. Przy próbie przesłania wideo o rozdzielczości 720p i bitrate większym niż dostępne pasmo widać, że najlepiej sprawdził się HDX oraz EOP, gdyż w pełni wykorzystywał dostępne pasmo i dostosował odpowiednio obraz. Nieco gorsze wrażenie dawał PCoIP 5.0, wyświetlając niewiele artefaktów, chociaż ruch był bardzo dobry. Najgorzej wypada Blaze, który ma problemy z optymalnym wykorzystaniem pasma. Obciążenie procesora po stronie serwera jest najmniejsze w przypadku HDX, na drugim miejscu znajduje się EOP. Ze względu na renderowanie po stronie hosta, VMware PCoIP nakłada narzut w postaci około 10% CPU, ale można ten narzut całkowicie zlikwidować, stosując kartę akceleracji Teradici. Akceleracja sprzętowa przy renderowaniu po stronie hosta przynosi dobre efekty w praktyce, zmniejszając obciążenie serwera. Z kolei Blaze ma narzut dochodzący momentami do 50% CPU, co jest nieakceptowalne w praktyce.

Protokoły przy pracy przez WAN

Przy pracy biurowej każdy z protokołów (HDX, PCoIP, EOP czy Blaze) się sprawdzi, ale warto zastanowić się nad pasmem, które wykorzystuje każdy z nich. O ile HDX nie różni się znacząco między wersjami 5.5 i 5.0, o tyle bardzo dużą różnicę notuje PCoIP - wersja 5.0 zużywa o 68% mniej pasma przy przeglądaniu dokumentów biurowych. Podawane w raporcie wartości to około 175 kBit/s w przypadku HDX oraz PCoIP 5.0. W niektórych przypadkach PCoIP wyprzedza nawet HDX, ale ogólnie zapotrzebowanie na pasmo przy pracy biurowej jest podobne.

Znacząca różnica jest jednak w przypadku przesyłania pełnoekranowych obiektów, takich jak Flash Video - ponieważ HDX 5.5 ma możliwość przekierowania, zajmuje o wiele mniej pasma niż konkurencja. Jeśli zaś chodzi o obiekty, które wymagają dobrej responsywności, takie jak gry lub podobne aplikacje Flash, przydatne są PCoIP oraz EOP, chociaż potrzebują więcej pasma niż HDX 5.5.

Jaka sieć dla zdalnego desktopu?

Protokoły różnią się w praktyce przy transmisji bogatych mediów, takich jak wideo, ale w typowej pracy biurowej liczy się przede wszystkim dobrej jakości połączenie sieciowe. Chociaż producenci chwalą się niskim zapotrzebowaniem na pasmo, w praktyce potrzeby te zależą od treści, która ma być w tym protokole przesyłana. Zatem łącze powinno dysponować pasmem 2 Mbit/s, by wrażenia pracy były naprawdę dobre, opóźnienia nie mogą przekraczać 50 ms, przy czym niektóre protokoły (RDP na standardowych ustawieniach) zaczynają mieć problemy już przy 20 ms. Przyczyną problemów w pracy zdalnej są także utraty pakietów - parametr ten musi być o wiele niższy niż 1%, w praktyce 0,01% daje dobre efekty.

Zagadnienia związane z pracą zdalną w sieciach o różnej jakości były tematem jednej z sesji technicznych na konferencji Citrix Synergy 2011.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200