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.
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.
-
-
Une connexion
ICA sans compression ni son
-
-
Une connexion
ICA avec compression et toujours pas de son
-
-
Une connexion
RDP standard
-
-
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
Guide de convergence du SOC et de la sécurité du cloud
Les menaces actuelles ne se cantonnent plus à une seule couche de votre environnement. Ressources cloud, systèmes d’entreprise, applications… elles se déplacent facilement par latéralisation. Pour protéger l’ensemble de votre infrastructure cloud, votre entreprise a besoin d’une approche unifiée qui place les données, la Threat Intelligence pilotée par IA et l’automatisation au service d’une protection complète. Découvrez tous les enjeux de la fusion entre CloudSec et SOC pour assurer une protection plus robuste, plus efficace de votre cloud.
