Tráfico en conexiones ICA
Uno de los principales problemas y datos reflejados en la mayoría de tests que se documentan, siempre están realizados en entornos de prueba, con lo que los resultados a nivel de como mejorar el protocolo ICA a nivel de WAN (que es lo que indicas como líneas grandes) puede trascender mucho de la realidad. Otro de los problemas principales se aplica a la tecnología instalada o implementada para ello.En estos puntos podrían surguir dos cuestiones, una que sería la optimización del protocolo ICA para mejorar el rendimiento y otra la limitación del tráfico no ICA para mejorar y «proteger» el tráfico ICA.
La perspectiva general y los resultados se establecen normalmente y en modo general a appliance que permiten gestionar lo que se denomina QoS, Calidad de Servicio.
La aceleración ICA, se establece normalmente en WAN cuando está debe de centrarse a nivel de control de flujo y procesos de compresión.
El protegerse de conexiones TCP que influyan en el tráfico ICA, pueden ser deribadas por consumo excesivo del ancho de banda, tanto a nivel de WAN y LAN.
El protegerse o el utilizar elementos para asegurar el ancho de banda puede repercutir considerablemente en la mejora del rendimiento en muchos casos superando el 50%, pero en muchos casos y dependiendo de la infraestructura puede provocar el caso contrario, un tráfico TCP lento y con perdida de paquetes, debido a la congestión de tráfico existente en dicha WAN o LAN.
El tamaño de un paquete o Window Size, es de 64KB de datos, por cada 64KB que pasa a través de un cable de red es necesario en la mayor parte de los casos el reconocerlo antes de que pase el siguiente paquete de datos, muchos de los procesos de mejoras de comunicaciones WAN pueden mejorar estos procesos mediante técnicas de eliminación de paquetes TCP lentos, incrementando el tamaño de la Windows Size.
ICA como protocolo es altamente interactivo, aúnque es considerablemente menor el consumo de ancho de banda con respecto al existente con RDP, este require constantemente por pequeño que sea una comunicación de tipo cliente / Servidor.
Muchas veces se han encontrado conexiones lentas, o períodos de sesiones execivas, detectadas en otros usuarios externos (por ejemplo) que han conectado a la granja. Todo ello generando un consumo de ancho de banda determinado, el consumo del ancho de banda es lo que genera en gran parte que una conexión vaya o sea más lenta o rápida que otras, este ancho de banda puede verse mermado considerablemente cuando se establecen además procesos de impresión altos, o ficheros de impresión excesivos, lo que generan una «caida» de la red, generando conexiones lentas o problemas de rendimiento, existen opciones como el uso de Streaming Media que permiten solucionar problemas del tipo de descargas de archivos, limitando y controlando en parte cierto tipo de acciones no controladas.
El protocolo ICA permite además que se consuma únicamente aquello que varia en la pantalla, y tránsmite únicamente aquello que cambia.
En cualquier plataforma Citrix, es necesario tener encuenta la prioridad del tráifo ICA sobre otros protocolos y mirar de «limpiar» todo aquello que no sea necesario en el tráfico WAN existente.
El consumo de ancho de banda del protocolo ICA puede variar de 4/8KB a 20KB como máximo de consumo de ancho de banda por conexión existente, RDP tiene un consumo fijo de 26KB de ancho de banda por conexión establecida.
El proceso de logon de cualquier conexión es siempre de 26KB peró únicamente en el proceso de validación, por lo que es sumamente importante en el proceso de diseño de nuestra plataforma Citrix.
ICA (Independent Computing Architecture) es el protocolo utilizado por Citrix basado en servidores.
Este protocolo está optimizado y transmite únicamente los movimientos de ratón, teclado basándose en eventos. ICA establece la comunicación con el servidor Citrix mediante la utilización de un cliente y un dispositivo gráfico independiente GDI que realiza la interpretación de las llamadas y actualización de elementos necesarios. Este protocolo es más eficiente debido al uso de un buffer de pantalla.
ICA es un protocolo de presentación, porqué opera independiente del protocolo de transmisión utilizado. ICA puede ser utilizado con TCP (Transmition Control Protocol), IPX (Internetwork Packet Exchange, SPX (Sequenced Packet Exchange), NetBIOS, y conexiones asíncronas, permitiendo trabajar con redes Ethernet, Tokenring, FDDI, Whireless, Internet, Intranet y dial-up, entre otras.
ICA como protocolo dispone de una serie de elementos muy interesantes como los que se detallan a continuación (y comentadas anteriormente en el foro ICA del portal):
– Arquitectura inteligente
– Protocolo de presentación
– Independencia del protocolo de transporte como TCP,IPX,NETBEUI…
– Encriptación
– Compresión
– cache de bitmaps
– bajo requerimiento de ancho de banda
– soporte Full color
A nivel de arquitectura del protocolo ICA, este está compuesto por los siguientes elementos,
– Preambulo
– Command Data
– Trailer
Dentro de Preambulo, tenemos a nivel de paquete TCP:
– Frame head
– Reliable
– Encription
– Compression
– Command
A nivel de Command Data -> Data
Y a nvel de Trailer -> Frame Trailer
Frame Head, es opcional pero forma parte de la cabecera del protocolo, este es el encargado en parte de controlar el stream oriendo a comunicaciones y tiene relación con Reliable.
Reliable, es opcional pero forma parte de la cabecera del protocolo, es el encargado de la detección de errores y el detection recovery garantizando de esta forma el delivery.
Encription, es opcional pero forma parte de la cabecera del protocolo, este permite la encriptación de ICA a nivel de paquete.
Compression: tiene la misma funcionalidad que Encription, pero permitiendo compresión del paquete, para manejar el proceso de compresión de datos.
Command: es de carácter obligado, es el inicio del paquete ICA.
Command Data: es opcional y contiene los datos que son enviados en el paquete, este depende en su totalidad de command, y su longitud puede ser variable, contiene además los canales virtuales del paquete.
Frame Trail: es opcional al protol trailer, es el encargado de notificar de la finalización del paquete y esta orientado a comunicaciones.
Dicho esto a nivel de conocimientos general, indicaremos que cualquier conexión a nivel de LAN o WAN, que genere por ejemplo procesos de replicación de drivers de impresoras, gráficos de mayor calidad, procesos de impresión largos o que necesite de decodificación como por ejemplo PCL6, producirá lentitud en la plataforma.
Los puntos que debemos de controlar en toda plataforma quedarían limitados a:
– Impresión Tráfico
* Podría estar descargado de los servidores Citrix, tráspasándolo a Print Servers.
– Aplicaciones o tráfico TCP/IP no controlable (dowloads, ftps..etc)
* Controlado a nivel de appliances de QoS.
* Bloquear navegación
* Gestión de protocolos
* Análisis mediante sniffers y analizadores de protocolo.
– Proceso de impresión.
* Utilizar drivers certificados.
* Utilizar UPD siempre que sea posible.
* Desviar la impresión al puesto de trabajo.
* Conexiones WAN utilizar en medida de lo posible Session Printer Policy.
– Ancho de banda
* Calcularlo en función de la cantida de usuarios concurrentes a conectarse.
* Publicar aplicación y no escritorio
– Servidores
* Servidores instalados correctamente
* RAM suficiente
* RAID 1 (mejor rendimiento, ya que al servir aplicaciones, únicamente necesitamos
velocidad en la lectura, no hay escritura).
– Otros…
El cumulo de todos los elementos permitirá el poder disponer de un mejor acceso a cualquier plataforma, así como una mejor gestión de ella, el tráfico de red no lo es todo, si los servidores no son los adecuados por mucho ancho de banda que se disponga el acceso será igualmente lento.
Espero que ello aya aclarado algo más los distintos conceptos, y no haberme dejado nada de todas formas espero vuestras consideraciones.
Más información y soporte en http://www.ctxdom.com/citrix
Comentarios recientes