Compresión

¿Cuál es el beneficio de la compresión de Citrix SD-WAN WANOP?

Mientras que el mecanismo básico de compresión es reducir los flujos de datos, el beneficio de esto es hacer las cosas más rápidas. Un archivo más pequeño (o una transacción más pequeña) tarda menos tiempo en transferirse. El tamaño no importa: el punto de compresión es la velocidad.

¿Cómo se mide el beneficio de compresión?

Existen dos formas de medir el beneficio de la compresión: tiempo y relación de compresión. Los dos están relacionados cuando el enlace WAN es el cuello de botella dominante. Debido a que el compresor de Citrix SD-WAN WANOP es muy rápido, comprimiendo los datos en tiempo real, un archivo que se comprime en 5:1 se transfiere en una quinta parte del tiempo. Esto es cierto hasta que se encuentra un cuello de botella secundario. Por ejemplo, si el cliente es demasiado lento para manejar una transferencia a toda velocidad, una relación de compresión 5:1 ofrece menos de una aceleración de 5:1.

¿Cómo funciona la compresión?

El motor de compresión conserva los datos previamente transferidos a través del enlace, con los datos más recientes retenidos en la memoria y una cantidad mucho mayor en el disco. Cuando una cadena que se transfirió antes se encuentra de nuevo, se reemplaza con una referencia a la copia anterior. Esta referencia se envía a través de la WAN en lugar de la cadena real, y el dispositivo en el otro extremo busca la referencia y la copia en la secuencia de salida.

¿Cuál es la relación de compresión máxima alcanzable?

La relación de compresión máxima alcanzable en un dispositivo Citrix SD-WAN WANOP es de aproximadamente 10 000:1.

¿Cuál es la relación de compresión esperada?

La relación de compresión general es el promedio de todos los intentos de comprimir las secuencias de datos en el vínculo. Algunas compresas mejor que otras, y algunas nunca se comprimen en absoluto. El dispositivo utiliza clases de servicio para evitar el envío de flujos obviamente no compresibles al compresor. El efecto de la compresión en diferentes tipos de datos varía de la siguiente manera:

Los datos comprimidos o cifrados de una sola vez (flujos que nunca se volverán a ver y que ya han sido comprimidos o cifrados, como túneles SSH cifrados y monitorización de cámaras de vídeo en tiempo real) no se comprimen, ya que sus flujos de datos nunca son los mismos dos veces.

Los datos binarios comprimidos o los datos cifrados que se ven más de una vez se comprime extremadamente bien en la segunda transferencia y posteriores, con relaciones de compresión en el rango de cientos a miles a uno en estas transferencias posteriores. En la primera transferencia, no se comprimen. La relación media de compresión de dichos datos depende de la frecuencia con la que se ven los datos más de una vez. Mientras que las transferencias individuales a veces muestran relaciones de compresión superiores a 1000:1, los promedios para los datos binarios comprimidos en el enlace promedian entre 1,5:1 y 5:1 en la mayoría de los enlaces, con promedios superiores a 10:1 en algunos enlaces, dependiendo de la naturaleza del tráfico.

Los flujos de texto y los datos binarios descomprimidos/no cifrados se comprimen incluso en la primera pasada. Las secuencias de texto se comprimen bien porque incluso los textos no relacionados tienen muchas subcadenas en común. Esto es cierto para los documentos, el código fuente, las páginas HTML, etc. La compresión de primer paso en el orden de 1,5:1 a 4:1 es común. En la segunda pasada y posteriores, comprimen casi tan bien como los datos binarios comprimidos (100:1 o más). Los datos binarios sin comprimir son variables, pero a menudo se comprime mejor que el texto. Ejemplos de datos binarios sin comprimir incluyen imágenes de CD, archivos ejecutables y formatos de imagen, audio y vídeo sin comprimir. En la segunda pasada y posteriores, comprimen los datos binarios así como los comprimidos.

Los datos de XenApp y XenDesktop se comprime especialmente bien con las transferencias de archivos, la salida de la impresora y el vídeo, siempre que las mismas secuencias de datos hayan atravesado el vínculo antes. Debido a la sobrecarga del protocolo, la compresión de pico es de aproximadamente 40:1, y es probable que la compresión promedio esté en la vecindad de 3:1. Los flujos de datos interactivos, como las actualizaciones de pantalla), dan resultados de compresión en el orden de 2:1.

¿Cuál es la diferencia entre el almacenamiento en caché y la compresión?

El almacenamiento en caché guarda objetos enteros con nombre en el dispositivo del cliente. El nombre puede ser una ruta y un nombre de archivo en el caso del almacenamiento en caché del sistema de archivos, o una URL en el caso del almacenamiento en caché web. Si transfiere un objeto idéntico con un nombre diferente, la caché no proporciona ningún beneficio. Si transfiere un objeto con el mismo nombre que un objeto almacenado en caché, pero con ligeras diferencias de contenido, la caché no proporciona ningún beneficio. Si el objeto se puede servir desde la caché, no se obtiene del servidor.

La compresión, por otro lado, no tiene concepto de nombres de objeto, y proporciona beneficios siempre que una cadena en la transferencia coincida con una que ya está en el historial de compresión. Esto significa que si descargas un archivo, cambias el 1% de su contenido y subes el nuevo archivo, es posible que consigas una compresión de 99:1 en la carga. Si descarga un archivo y lo carga a un directorio diferente en el sitio remoto, también puede lograr una alta relación de compresión. La compresión no requiere bloqueo de archivos y no sufre de estancamiento. El objeto siempre se obtiene del servidor y, por lo tanto, siempre es correcto byte por byte.

Compresión