> Tech > RDP ou ICA : encore une victime de la vitesse

RDP ou ICA : encore une victime de la vitesse

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

Tout le monde le sait dans le domaine automobile, la vitesse tue. Mais ce qui est vrai pour les voitures s'applique également à  l'informatique, particulièrement aux deux principales technologies de clients légers offertes aux utilisateurs de Windows NT.Le slogan " la vitesse tue " convient très bien aujourd'hui à  la technologie du client léger ou thin client, bien que dans un registre légèrement différent (je doute que quiconque ne succombe pour avoir utilisé un produit trop rapide ou trop lent). Le slogan colle particulièrement bien à  la rivalité entre deux implémentations concurrentes des clients légers pour Windows NT : ICA (Independent Computing Architecture) de Citrix et RDP (Remote Desktop Protocol) de Microsoft. En effet, si l'un des deux (ou en l'occurrence les protocoles sous-jacents) l'emporte par la vitesse, le client le plus lent mourra, sera enterré et vite oublié.

Pourquoi la vitesse est-elle si importante sur ce marché ? Dans la technologie du client léger, un serveur central pousse tous les bits, qui composent l'image du bureau, jusqu'au client via le réseau. Par exemple, lorsque l'on démarre, redimensionne ou arrête les applications du bureau, le serveur doit pousser tous les bits affectés pour repeindre l'écran du client léger. Il n'est pas difficile d'imaginer qu'il faut une bonne dose de bande passante pour déplacer des bits d'affichage.

Comme l'interaction client-serveur est très gourmande en bande passante, l'efficacité du client est extrêmement importante. On peut convenir sans risque que dans un environnement de type réseau local, le client ICA et le client RDP offrent des performances similaires. Dans un environnement WAN ou dans un environnement commuté, le client ICA offre de meilleures performances que le client RDP, car Citrix a développé son client ICA pour les connexions modem lentes.

Comme l'interaction client-serveur est très gourmande en bande passante, l'efficacité du client est extrêmement importante

Une fois dressé ce tableau général, l'examen détaillé de chaque client se complique. Par exemple, le client ICA supporte le son, mais pas le client RDP. Or l'ajout du son demande plus de bande passante. De même le client ICA pour Windows 32 bits peut mettre en mémoire cache les bits des icônes, ce qui, théoriquement, accélère les opérations d'affichage. Les clients RDP pour Windows 16 et 32 bits ne peuvent pas mettre en mémoire ces mêmes bitmaps.

Un autre facteur vient compliquer l'étude des performances : le système d'exploitation des clients. Par exemple, un client ICA tournant sur un terminal avec un OS propriétaire risque d'être plus rapide qu'un client ICA tournant sur un terminal Windows CE. De même un client RDP tournant sur un terminal Windows NT ou Windows 95 sera sans doute plus rapide que ce même client RDP sur un terminal Windows CE. Comparer la rapidité de différentes implémentations de client léger n'est donc pas évident.

RDP ou ICA : encore une victime de la vitesse

Le labo a décidé de
répondre à  la litanie des questions de performances concernant
les clients et les protocoles ICA et RDP. Nous allons explorer
les performances relatives des deux clients et des deux
protocoles avec différentes vitesses de réseau, différentes
charges de clients, et différentes configurations.

Tout d’abord
nous avons voulu absolument répondre à  une question :
quelle est la meilleure implémentation pour les lignes
lentes ? Pour y répondre nous avons effectué des tests
client-serveur un-pour-un qui ont permis d’examiner
l’efficacité relative du client ICA par rapport au client
RDP.

Nous avons
spécialement installé un terminal Wyse Winterm Série 3000
(sous Windows CE) et un PC doté d’un Pentium 166 MHz (sous
Win95) dans le labo " PME ". Ce dernier est
connecté à  notre labo " entreprise " via
une ligne RNIS. Dans le labo entreprise, nous avons installé
Windows NT Server 4.0 Terminal Server Edition, et MetaFrame de
Citrix sur un serveur Pentium 200 MHz. Pour éviter
l’interaction de tout autre trafic, le routeur RNIS a été
connecté au serveur au moyen d’Ethernet commuté et nous
avons exécuté les tests en fin de soirée alors que le labo
était vide.

Pour être équitable
envers toutes les parties, nous avons défini quatre
configurations de connexions entre le client et le serveur.

  1.  
  2. Une connexion
    ICA sans compression ni son

  3.  
  4. Une connexion
    ICA avec compression et toujours pas de son

  5.  
  6. Une connexion
    RDP standard

  7.  
  8. Une connexion
    RDP utilisant l’option lente

Nous avons installé
les quatre configurations à  la fois sur le terminal Winterm et
le PC dans le labo PME. J’ai également désactivé le
support du son et la mise en mémoire cache des icônes sur les
clients ICA, car les clients RDP n’ont pas d’options
comparables.

Le test de base consistait à  afficher, fermer et réafficher une image 800 x 600, 256 couleurs. Le test a été exécuté en mode plein écran et en mode écran partiel, en utilisant les quatre configurations mentionnées ci-dessus, à  la fois sur le Winterm et le PC, à  64 Kbps et 128 Kbps. Pendant chaque test, nous avons mesuré le temps que mettait chaque écran à  apparaître.
Les résultats sont exprimés en secondes et dixièmes de secondes. Comme le temps de chaque réapparition a été calculé manuellement, la marge d’erreur est approximativement de plus ou moins 0,01 secondes. Chaque test a donc été exécuté au moins trois fois pour assurer que la mesure était exacte et nous fait la moyenne des essais pour obtenir les résultats finaux. Je dois reconnaître que les résultats m’ont surpris et fasciné.

Téléchargez cette ressource

Solutions Cloud & Services Managés Simplifiés

Solutions Cloud & Services Managés Simplifiés

Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT