Con el equipo A10, podemos hacer un "Connection Reuse" para descargar a los servidores finales de gestionar las sesiones TCP. Esto hace que los servidores puedan tener una respuesta más rápida.
Con esta característica, las sesiones de los clientes terminan en el A10. Pero el A10 es el que mantiene las sesiones con los servidores y les envías las peticiones de persistencia de los clientes.
Para usar "Connection Reuse", tenemos que habilitar SLB Source NAT en nuestro equipo A10 y HTTP Keep-Alive en los servidores.
Otra opción para descargar de procesamiento al servidor es usar SSL Off-Load del que ya hablamos en el capítulo anterior
 |
| SSL Off-Load |
Comprensión HTTP/HTTPS
Al usar la comprensión conseguimos que se use menos ancho de banda y proveemos al cliente de una descarga de los objetos más rápida.
Si la comprensión está habilitada en los servidores, esta la ejecuta el A10 descargando así de esta tarea a los servidores. Los obejtos comprimidos se mandan entonces desde el A10. Por defecto, suele ser "texto" como html, css o js y, "aplicaciones" como doc, xls, ppt o pdf.
Cacheo de la RAM
El equipo A10 mete en su caché los objetos estáticos y dinámicos y, los sirve a los clientes desde él mismo descargando al servidor de la tarea.
El A10 cachea los siguientes códigos a menos que el servidor explícitamente lo deniegue:
- 200 OK
- 203 Non-Authorative response
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 410 Gone
Hay una serie de limitaciones cuando hacemos caché de la RAM:
- No soporta rango de peticiones HTTP. Las manda directamente al servidor
- No cachea las respuestas de servidor que lleven en la cabecera "Vary" excepto "Vary:Enconding"
- No cachea las respuestas de servidor que lleven en la cabecera "Warning"
- No cachea las respuestas de servidor si la petición tenía en la cabecera "Authorization", incluso si el servidor especifica "Cache:control public"
- No cachea las respuestas de servidor parciales/incompletas
Cacheo dinámico
Es necesario entender el comportamiento de la aplicación para aplicar un cacheo correcto. ¿Qué tiene que ser chacheado? ¿Durante cuánto tiempo el contenido es válido? ¿Qué detalle nos avisa cuando hay un cambio de respuesta?
Los parámetros de las peticiones de clientes que podemos usar pueden ser:
- La URL tiene un patrón concreto
- Tiene específicas "query"
- Tiene específicas "cookies"
- Tiene específicas "cabecera de HTTP"
Configuramos reglas para determinar qué es cacheable y qué no. Las políticas que configuramos se pueden usar para sobreescribir/aumentar el comportamiento estándar de HTTP.
Las políticas se especifican de la siguiente manera:
- policy
Las políticas son evaluadas en el orden que han sido configuradas.
La acción que se aplica es la primera que coincida con la política aplicada.
Un ejemplo de cacheo dinámico si tenemos una aplicación web con las siguientes URLs:
http://x.y.com/list - lista todos los elementos de la base de datos
http://x.y.com/add?a=p1&b=p2 - añade elementos a la base de datos
http://x.y.com/del?c=p3 - elimina elementos de la base de datos
http://x.y.com/private?user=u1 - información privada para el usuario
Como la URI de "list" es usada con mucha frecuencia, tiene sentido que sea cacheada.
 |
| Tiene 300 segundos de cacheo |
Cuando no deberíamos usar cache dinámica:
- Cuando la respuesta configura cookies específicas en la sesió, como por ejemplo la respuesta a una página de inicio de sesión (login page)
- Respuestas que contienen datos específicos previo a una acción en la sesión, como por ejemplo la confirmación de un número para una transacción que acaba de ser ejecutada.
- Respuestas que contienen datos que serán refrescados en base a una futura acción, como por ejemplo los datos de un broker que se refrescarán cuando haga una transacción.
- Diferentes versiones de respuesta que no pueden ser distinguidas por la URL, los paránetro de query o las cookies de las peticiones, como por ejemplo en respuestas que contengan configuraciones personalizadas, como el nombre de usuario.
No hay comentarios:
Publicar un comentario