[No] utilices una CDN

Casi todos los artículos o herramientas para optimizar la velocidad del sitio tienen una cláusula modesta "use una CDN". En general, CDN es una red de distribución de contenidos o red de distribución de contenidos. En Method Lab a menudo encontramos preguntas de clientes sobre este tema; algunos de ellos habilitan su propia CDN. El propósito de este artículo es comprender qué puede proporcionar una CDN en términos de velocidad de carga del sitio, qué problemas pueden surgir y en qué casos está justificado el uso de una CDN.

Los retrasos marcados con un círculo en la imagen se deben al uso de una CDN.

Un poco de historia

Como muchas tecnologías, las CDN surgieron por necesidad. Con el desarrollo de los canales de Internet entre los usuarios de Internet, aparecieron los servicios de vídeo en línea. Naturalmente, el contenido de vídeo requiere mucho más ancho de banda en comparación con el contenido normal de un sitio web (imágenes, texto y código CSS o JS).

Al intentar transmitir una transmisión de video en paralelo a muchos clientes desde un servidor, lo más probable es que el canal de Internet del servidor se convierta en el cuello de botella. Como regla general, unos pocos miles de subprocesos son suficientes para obstruir un canal de servidor típico. Por supuesto, puede haber otras limitaciones de recursos, pero no son importantes en este momento. También es importante que ampliar el canal del servidor sea demasiado caro (y a veces imposible) y además poco práctico. La carga del canal durante las retransmisiones será cíclica.

CDN resuelve perfectamente el problema de limitar el canal de un servidor individual. Los clientes no se conectan directamente al servidor, sino a nodos de la red CDN. En una situación ideal, el servidor envía una secuencia al nodo CDN y luego la red utiliza sus propios recursos para entregar esta secuencia a muchos usuarios. Desde un punto de vista económico, pagamos sólo por los recursos realmente consumidos (puede ser ancho de banda o tráfico) y obtenemos una excelente escalabilidad de nuestro servicio. Usar una CDN para entregar contenido pesado está completamente justificado y es lógico. Aunque vale la pena señalar que los actores más importantes en este espacio (por ejemplo, Netflix) están creando sus propias CDN en lugar de utilizar grandes CDN comerciales (Akamai, Cloudflare, Fastly, etc.)

A medida que la web ha evolucionado, las propias aplicaciones web se han vuelto más complejas y complejas. El problema de la velocidad de carga pasó a primer plano. Los entusiastas de la velocidad de los sitios web identificaron rápidamente varios problemas importantes que provocaban que los sitios web se cargaran lentamente. Uno de ellos fueron los retrasos en la red (RTT - tiempo de ida y vuelta o tiempo de ping). Los retrasos afectan muchos procesos en la carga de un sitio web: establecer una conexión TCP, iniciar una sesión TLS, cargar cada recurso individual (imagen, archivo JS, documento HTML, etc.)

El problema se vio agravado por el hecho de que cuando se utiliza el protocolo HTTP/1.1 (antes de la aparición de SPDY, QUIC y HTTP/2 esta era la única opción), los navegadores no abren más de 6 conexiones TCP a un host. Todo esto provocó tiempos de inactividad en la conexión y un uso ineficiente del ancho de banda del canal. El problema se resolvió parcialmente mediante la fragmentación del dominio: la creación de hosts adicionales para superar el límite en la cantidad de conexiones.

Aquí es donde aparece la segunda capacidad de CDN: reducir la latencia (RTT) debido a la gran cantidad de puntos y la proximidad de los nodos al usuario. La distancia juega aquí un papel decisivo: la velocidad de la luz es limitada (unos 200 km/s en fibra óptica). Esto significa que cada 000 km de recorrido añade 1000 ms de retraso o 5 ms al RTT. Este es el tiempo mínimo requerido para la transmisión, ya que también existen retrasos en los equipos intermedios. Dado que una CDN generalmente sabe cómo almacenar en caché objetos en sus servidores, podemos beneficiarnos al cargar dichos objetos a través de una CDN. Condiciones necesarias para esto: la presencia del objeto en el caché, la proximidad del punto CDN al usuario en comparación con el servidor de aplicaciones web (servidor de origen). Es importante comprender que la proximidad geográfica de un nodo CDN no garantiza una latencia baja. El enrutamiento entre el cliente y la CDN se puede construir de tal manera que el cliente se conecte a un host en otro país y posiblemente en otro continente. Aquí es donde entra en juego la relación entre los operadores de telecomunicaciones y el servicio CDN (peering, conexiones, participación en IX, etc.) y la política de enrutamiento del tráfico de la propia CDN. Por ejemplo, Cloudflare, cuando utiliza dos planes iniciales (gratuito y económico), no garantiza la entrega de contenido desde el host más cercano: el host será seleccionado para lograr el costo mínimo.

Muchas empresas líderes de Internet atraen el interés del público (desarrolladores web y propietarios de servicios) sobre el tema de la velocidad de carga y el rendimiento del sitio web. Entre estas empresas se encuentran Yahoo (herramienta Yslow), AOL (WebPageTest) y Google (servicio Page Speed ​​​​Insights), que están desarrollando sus propias recomendaciones para acelerar sitios (principalmente se relacionan con la optimización del cliente). Más tarde, aparecen nuevas herramientas de prueba de velocidad de sitios web, que también brindan consejos para aumentar la velocidad del sitio web. Cada uno de estos servicios o complementos tiene una recomendación constante: "Utilice una CDN". La reducción de la latencia de la red suele citarse como explicación del efecto de la CDN. Desafortunadamente, no todo el mundo está preparado para comprender exactamente cómo se logra el efecto de aceleración de CDN y cómo se puede medir, por lo que la recomendación se toma por fe y se utiliza como postulado. De hecho, no todas las CDN son iguales.

Usando una CDN hoy

Para evaluar la utilidad del uso de CDN, es necesario clasificarlas. Lo que se puede encontrar ahora en la práctica (los ejemplos entre paréntesis, por supuesto, no son exhaustivos):

1. CDN gratuito para distribuir bibliotecas JS (MaxCDN, Google, Yandex).
2. CDN de servicios para optimización del cliente (por ejemplo, Google Fonts para fuentes, Cloudinary, Cloudimage para imágenes).
3. CDN para optimización estática y de recursos en CMS (disponible en Bitrix, WordPress y otros).
4. CDN de uso general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para aceleración de sitios web (Cloudflare, Imperva, Airi).

La diferencia clave entre estos tipos es la cantidad de tráfico que pasa por la CDN. Los tipos 1 a 3 son la entrega de solo una parte del contenido: desde una solicitud hasta varias docenas (generalmente imágenes). Los tipos 4 y 5 son proxy completo del tráfico a través de una CDN.

En la práctica, esto significa la cantidad de conexiones que se utilizan para cargar el sitio. Con HTTP/2, utilizamos una única conexión TCP con el host para procesar cualquier cantidad de solicitudes. Si dividimos los recursos en el host principal (origen) y CDN, entonces es necesario distribuir las solicitudes entre varios dominios y crear varias conexiones TCP. El peor de los casos es: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Esta fórmula no tiene en cuenta los retrasos en las redes móviles para la activación del canal de radio del dispositivo (si no estaba activo) ni los retrasos en la torre de telefonía móvil.

Así es como se ve en la cascada de carga del sitio (las latencias para conectarse a la CDN están resaltadas en RTT 150 ms):

Si la CDN cubre todo el tráfico del sitio (excepto los servicios de terceros), entonces podemos usar una única conexión TCP, ahorrando demoras al conectarnos a hosts adicionales. Por supuesto, esto se aplica a las conexiones HTTP/2.

Otras diferencias están determinadas por la funcionalidad de una CDN en particular: para el primer tipo simplemente aloja un archivo estático, para el quinto cambia varios tipos de contenido del sitio con el fin de optimizarlo.

Capacidades de CDN para la aceleración de sitios web

Describamos la gama completa de capacidades CDN para acelerar sitios, independientemente de la funcionalidad de los tipos individuales de CDN, y luego veamos qué se implementa en cada uno de ellos.

1. Compresión de recursos de texto.

La característica más básica y comprensible, pero a menudo mal implementada. Todas las CDN declaran la presencia de compresión como característica de aceleración. Pero si miras con más detalle, las deficiencias quedan claras:

• se pueden utilizar grados bajos para compresión dinámica: 5-6 (por ejemplo, para gzip el máximo es 9);
• la compresión estática (archivos en caché) no utiliza funciones adicionales (por ejemplo, zopfi o brotli con grado 11)
• no hay soporte para una compresión brotli eficiente (ahorrando alrededor del 20% en comparación con gzip).

Si usa una CDN, vale la pena verificar estos pocos puntos: tome el archivo que vino de la CDN, registre su tamaño comprimido y comprímalo manualmente para compararlo (puede usar algún servicio en línea con soporte de brotli, por ejemplo). vsszhat.rf).

2. Configuración de encabezados de almacenamiento en caché del cliente

También una función de aceleración simple: agregue encabezados para el almacenamiento en caché del contenido por parte del cliente (navegador). El encabezado más actual es control de caché, el desactualizado caduca. Además, se puede utilizar Etag. Lo principal es que la antigüedad máxima del control de caché sea lo suficientemente grande (desde un mes o más). Si está listo para almacenar en caché el recurso lo más posible, puede agregar la opción inmutable.

Las CDN pueden reducir el valor de edad máxima, lo que obliga al usuario a recargar contenido estático con más frecuencia. No está claro con qué está relacionado esto: el deseo de aumentar el tráfico en la red o aumentar la compatibilidad con sitios que no saben cómo restablecer el caché. Por ejemplo, el tiempo de caché de encabezado predeterminado de Cloudflare es 1 hora, que es muy bajo para datos estáticos inmutables.

3. Optimización de imágenes

Dado que la CDN asume las funciones de almacenamiento en caché y entrega de imágenes, sería lógico optimizarlas en el lado de la CDN y entregarlas a los usuarios de esta forma. Hagamos una reserva de inmediato: esta función solo está disponible para los tipos CDN 2, 3 y 5.

Puede optimizar las imágenes de varias formas: utilizando formatos de compresión avanzados (como WebP), codificadores más eficientes (MozJPEG) o simplemente limpiando metadatos innecesarios.

En general, existen dos tipos de optimizaciones: con pérdida de calidad y sin pérdida de calidad. Las CDN suelen esforzarse por utilizar una optimización sin pérdidas para evitar posibles quejas de los clientes sobre cambios en la calidad de la imagen. En tales condiciones, la ganancia será mínima. En realidad, a menudo el nivel de calidad JPEG es mucho más alto de lo necesario y puedes volver a comprimirlo de forma segura con un nivel de calidad más bajo sin comprometer la experiencia del usuario. Por otro lado, es difícil determinar el nivel de calidad y la configuración de forma universal para todas las aplicaciones web posibles, por lo que las CDN utilizan configuraciones más conservadoras en comparación con las que se pueden aplicar teniendo en cuenta el contexto (propósito de las imágenes, tipo de aplicación web). , etc.)

4. Optimización de la conexión TLS

La mayor parte del tráfico actual viaja a través de conexiones TLS, lo que significa que dedicamos más tiempo a la negociación TLS. Recientemente, se han desarrollado nuevas tecnologías para acelerar este proceso. Por ejemplo, esto es criptografía EC, TLS 1.3, caché y tickets de sesión, aceleración de cifrado de hardware (AES-NI), etc. La configuración correcta de TLS puede reducir el tiempo de conexión a 0-1 RTT (sin contar DNS y TCP).

Con el software moderno, no es difícil implementar estas prácticas por su cuenta.

No todas las CDN implementan las mejores prácticas de TLS; puede comprobarlo midiendo el tiempo de conexión de TLS (por ejemplo, en Webpagetest). Ideal para una nueva conexión - 1RTT, 2RTT - nivel medio, 3RTT y más - malo.

También cabe señalar que incluso cuando usamos TLS a nivel de CDN, el servidor con nuestra aplicación web también debe procesar TLS, pero desde el lado de CDN, porque el tráfico entre el servidor y la CDN pasa por la red pública. En el peor de los casos, obtendremos retrasos dobles en la conexión TLS (el primero al host CDN, el segundo entre este y nuestro servidor).

Para algunas aplicaciones, vale la pena prestar atención a los problemas de seguridad: el tráfico generalmente se descifra en los nodos CDN, y esta es una oportunidad potencial para la interceptación del tráfico. La opción de trabajar sin notificación de tráfico se suele ofrecer en los planes de tarifas superiores por un cargo adicional.

5. Reducir los retrasos en la conexión

El principal beneficio de CDN del que todo el mundo habla: baja latencia (menos distancia) entre el host de CDN y el usuario. Se logra mediante la creación de una arquitectura de red distribuida geográficamente, en la que los hosts están ubicados en puntos de concentración de usuarios (ciudades, puntos de intercambio de tráfico, etc.)

En la práctica, las prioridades de diferentes redes pueden estar en regiones específicas. Por ejemplo, las CDN rusas tendrán más puntos de presencia en Rusia. Los americanos desarrollarán en primer lugar la red en EE.UU. Por ejemplo, uno de los CDN más grandes, Cloudflare, tiene solo 2 puntos en Rusia: Moscú y San Petersburgo. Es decir, podremos ahorrar un máximo de unos 10 ms de latencia respecto a la colocación directa en Moscú.

La mayoría de las CDN occidentales no tienen ningún punto en Rusia. Al conectarse a ellos, sólo podrá aumentar los retrasos para su audiencia rusa.

6. Optimización de contenidos (minificación, cambios estructurales)

El punto más complejo y tecnológicamente avanzado. Cambiar el contenido durante la entrega puede ser muy arriesgado. Incluso si tomamos la minificación: reducir el código fuente (debido a espacios adicionales, estructuras sin importancia, etc.) puede afectar su rendimiento. Si hablamos de cambios más serios (mover el código JS al final del HTML, fusionar archivos, etc.), el riesgo de alterar la funcionalidad del sitio es aún mayor.

Por lo tanto, sólo algunas CDN tipo 5 hacen esto. Por supuesto, no será posible automatizar todos los cambios necesarios para acelerar las cosas: se requieren análisis y optimización manuales. Por ejemplo, eliminar código duplicado o no utilizado es una tarea manual.

Como regla general, todas estas optimizaciones están controladas por la configuración y las más peligrosas están desactivadas de forma predeterminada.

Soporte para capacidades de aceleración por tipo de CDN

Entonces, echemos un vistazo a las posibles oportunidades de aceleración que brindan los diferentes tipos de CDN.

Por conveniencia, repetimos la clasificación.

1. CDN gratuito para distribuir bibliotecas JS (MaxCDN, Google, Yandex).
2. CDN de servicios para optimización del cliente (por ejemplo, Google Fonts para fuentes, Cloudinary, Cloudimage para imágenes).
3. CDN para optimización estática y de recursos en CMS (disponible en Bitrix, WordPress y otros).
4. CDN de uso general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para aceleración de sitios web (Cloudflare, Imperva, Airi).

Ahora comparemos las características y tipos de CDN.

Oportunidad
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compresión de texto
+ -
–
+ -
+ -
+

encabezados de caché
+
+
+
+
+

fotos
–
+ -
+ -
–
+

TLS
–
–
–
+ -
+

Retrasos
–
–
–
+
+

Contenido
–
–
–
–
+

En esta tabla, “+” se utiliza para indicar soporte total, “–” significa que no hay soporte y “+–” es soporte parcial. Por supuesto, en la realidad puede haber desviaciones de esta tabla (por ejemplo, algunas CDN de uso general implementarán funciones para optimizar imágenes), pero para una idea general es útil.

resultados

Con suerte, después de leer este artículo tendrá una idea más clara sobre la recomendación de “usar una CDN” para acelerar sus sitios.

Como en cualquier negocio, no se pueden creer las promesas de marketing de ningún servicio. El efecto debe medirse y probarse en condiciones reales. Si ya está utilizando una CDN, verifique su efectividad utilizando los criterios descritos en el artículo.

Es posible que el uso de una CDN en este momento esté ralentizando el tiempo de carga de su sitio.

Como recomendación general, podemos centrarnos en lo siguiente: estudia tu audiencia, determina su alcance geográfico. Si su audiencia principal se concentra en un radio de 1 a 2 mil kilómetros, no necesita una CDN para su objetivo principal: reducir la latencia. En su lugar, puede colocar su servidor más cerca de sus usuarios y configurarlo adecuadamente, obteniendo la mayoría de las optimizaciones descritas en el artículo (gratuitas y permanentes).

En caso de que su audiencia esté realmente distribuida geográficamente (radio de más de 3000 kilómetros), utilizar una CDN de calidad será realmente útil. Sin embargo, debe comprender de antemano qué es exactamente lo que puede acelerar su CDN (consulte la tabla de capacidades y su descripción). Sin embargo, la aceleración de sitios web sigue siendo una tarea compleja que no se puede resolver conectando una CDN. Además de las optimizaciones anteriores, detrás de la CDN quedan los medios de aceleración más efectivos: optimización de la parte del servidor, cambios avanzados en la parte del cliente (eliminación de código no utilizado, optimización del proceso de renderizado, trabajo con contenido, fuentes, adaptabilidad, etc. )

Fuente: habr.com