[Non] use un CDN

Case todos os artigos ou ferramentas para optimizar a velocidade do sitio teñen unha modesta cláusula "usar un CDN". En xeral, CDN é unha rede de entrega de contido ou rede de entrega de contido. En Method Lab adoitamos atopar preguntas dos clientes sobre este tema; algúns deles activan o seu propio CDN. O obxectivo deste artigo é comprender o que pode proporcionar unha CDN en canto á velocidade de carga do sitio, que problemas poden xurdir e en que casos se xustifica o uso dunha CDN.

Os atrasos rodeados na imaxe son causados ​​polo uso dunha CDN.

Un pouco de historia

Como moitas tecnoloxías, as CDN xurdiron por necesidade. Co desenvolvemento das canles de Internet entre os usuarios de Internet, apareceron servizos de vídeo en liña. Por suposto, o contido de vídeo require ordes de magnitude máis ancho de banda en comparación co contido normal do sitio web (imaxes, texto e código CSS ou JS).

Cando se tenta transmitir un fluxo de vídeo en paralelo a moitos clientes desde un servidor, a canle de Internet do servidor probablemente se converta no pescozo de botella. Como regra xeral, uns poucos miles de fíos son suficientes para obstruír unha canle típica do servidor. Por suposto, pode haber outras limitacións de recursos, pero non son importantes neste momento. Tamén é importante que ampliar a canle do servidor sexa demasiado caro (e ás veces imposible), e tamén pouco práctico. A carga na canle durante as emisións será cíclica.

O problema de limitar a canle dun servidor individual está perfectamente solucionado por CDN. Os clientes non se conectan directamente ao servidor, senón aos nodos da rede CDN. Nunha situación ideal, o servidor envía un fluxo ao nodo CDN e, a continuación, a rede utiliza os seus propios recursos para entregar este fluxo a moitos usuarios. Desde o punto de vista económico, pagamos só polos recursos realmente consumidos (pode ser ancho de banda ou tráfico) e conseguimos unha excelente escalabilidade do noso servizo. Usar un CDN para entregar contido pesado está completamente xustificado e lóxico. Aínda que convén ter en conta que os maiores xogadores deste espazo (por exemplo, Netflix) están a construír os seus propios CDN en lugar de usar grandes CDN comerciais (Akamai, Cloudflare, Fastly, etc.)

A medida que a web foi evolucionando, as propias aplicacións web fixéronse máis complexas e complexas. O problema da velocidade de carga saíu á palestra. Os entusiastas da velocidade dos sitios web identificaron rapidamente varios problemas importantes que fixeron que os sitios web se cargasen lentamente. Un deles foron os atrasos da rede (RTT - tempo de ida e volta ou tempo de ping). Os atrasos afectan a moitos procesos na carga do sitio web: establecer unha conexión TCP, iniciar unha sesión TLS, cargar cada recurso individual (imaxe, ficheiro JS, documento HTML, etc.)

O problema agravouse polo feito de que ao usar o protocolo HTTP/1.1 (antes da aparición de SPDY, QUIC e HTTP/2 esta era a única opción), os navegadores non abren máis de 6 conexións TCP a un servidor. Todo isto provocou un tempo de inactividade da conexión e un uso ineficiente do ancho de banda da canle. O problema resolveuse parcialmente coa fragmentación do dominio: a creación de hosts adicionais para superar o límite no número de conexións.

Aquí é onde aparece a segunda capacidade de CDN: reducir a latencia (RTT) debido á gran cantidade de puntos e á proximidade dos nodos ao usuario. A distancia xoga aquí un papel decisivo: a velocidade da luz é limitada (uns 200 km/s en fibra óptica). Isto significa que cada 000 km de viaxe engade 1000 ms de atraso ou 5 ms a RTT. Este é o tempo mínimo necesario para a transmisión, xa que tamén hai atrasos nos equipos intermedios. Dado que un CDN adoita saber como almacenar en caché obxectos nos seus servidores, podemos beneficiarnos de cargar tales obxectos a través dunha CDN. Condicións necesarias para iso: a presenza do obxecto na caché, a proximidade do punto CDN ao usuario en comparación co servidor de aplicacións web (servidor de orixe). É importante entender que a proximidade xeográfica dun nodo CDN non garante unha baixa latencia. O enrutamento entre o cliente e a CDN pódese construír de forma que o cliente se conecte a un host doutro país, e posiblemente noutro continente. É aquí onde entran en xogo a relación entre os operadores de telecomunicacións e o servizo CDN (peering, conexións, participación en IX, etc.) e a política de encamiñamento do tráfico da propia CDN. Por exemplo, Cloudflare, ao usar dous plans iniciais (gratuíto e barato), non garante a entrega de contido do host máis próximo: seleccionarase o host para acadar o custo mínimo.

Moitas empresas líderes de Internet atraen o interese público (desenvolvedores web e propietarios de servizos) polo tema da velocidade de carga e o rendemento do sitio web. Entre estas empresas atópanse Yahoo (ferramenta Yslow), AOL (WebPageTest) e Google (servizo Page Speed ​​​​Insights), que están a desenvolver as súas propias recomendacións para acelerar os sitios (principalmente están relacionadas coa optimización do cliente). Máis tarde, aparecen novas ferramentas de proba de velocidade do sitio web, que tamén ofrecen consellos para aumentar a velocidade do sitio web. Cada un destes servizos ou complementos ten unha recomendación consistente: "Usar un CDN". A redución da latencia da rede adoita citarse como explicación do efecto da CDN. Desafortunadamente, non todos están preparados para comprender exactamente como se consegue o efecto acelerador da CDN e como se pode medir, polo que a recomendación tómase a fe e úsase como postulado. De feito, non todos os CDN son iguais.

Usando un CDN hoxe

Para avaliar a utilidade do uso de CDN, é necesario clasificalos. O que se pode atopar agora na práctica (os exemplos entre corchetes non son, por suposto, exhaustivos):

1. CDN gratuíto para distribuír bibliotecas JS (MaxCDN, Google. Yandex).
2. CDN de servizos para a optimización do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imaxes).
3. CDN para optimización estática e de recursos en CMS (dispoñible en Bitrix, WordPress e outros).
4. CDN de propósito xeral (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para aceleración de sitios web (Cloudflare, Imperva, Airi).

A diferenza fundamental entre estes tipos é a cantidade de tráfico que pasa pola CDN. Os tipos 1-3 son a entrega de só parte do contido: desde unha solicitude ata varias ducias (xeralmente imaxes). Os tipos 4 e 5 son un proxy completo do tráfico a través dunha CDN.

Na práctica, isto significa o número de conexións que se utilizan para cargar o sitio. Con HTTP/2, usamos unha única conexión TCP co host para procesar calquera número de solicitudes. Se dividimos os recursos en host principal (orixe) e CDN, entón é necesario distribuír as solicitudes en varios dominios e crear varias conexións TCP. O peor dos casos é: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Esta fórmula non ten en conta os atrasos nas redes móbiles para a activación da canle de radio do dispositivo (se non estivese activa) e os atrasos na torre móbil.

Este é o que parece na fervenza de carga do sitio (as latencias para conectarse ao CDN destacan en RTT 150 ms):

Se o CDN cobre todo o tráfico do sitio (agás os servizos de terceiros), entón podemos usar unha única conexión TCP, aforrando atrasos na conexión a hosts adicionais. Por suposto, isto aplícase ás conexións HTTP/2.

Outras diferenzas están determinadas pola funcionalidade dun CDN en particular: para o primeiro tipo só está a aloxar un ficheiro estático, para o quinto está cambiando varios tipos de contido do sitio coa finalidade da optimización.

Capacidades CDN para acelerar sitios web

Imos describir a gama completa de capacidades de CDN para acelerar sitios, sen ter en conta a funcionalidade dos tipos individuais de CDN, e despois vexamos o que se implementa en cada un deles.

1. Compresión de recursos de texto

A característica máis básica e comprensible, aínda que moitas veces mal implementada. Todos os CDN declaran a presenza de compresión como a súa característica de aceleración. Pero se miras con máis detalle, as deficiencias quedan claras:

• pódense usar graos baixos para a compresión dinámica - 5-6 (por exemplo, para gzip o máximo é 9);
• A compresión estática (arquivos na caché) non usa funcións adicionais (por exemplo, zopfi ou brotli con grao 11)
• non hai soporte para a compresión brotli eficiente (aforrando un 20% en comparación co gzip).

Se usas un CDN, paga a pena revisar estes poucos puntos: colle o ficheiro que veu do CDN, rexistra o seu tamaño comprimido e comprime manualmente para comparalo (podes usar algún servizo en liña con soporte para brotli, por exemplo). vsszhat.rf).

2. Establecer cabeceiras de caché do cliente

Tamén unha función sinxela de aceleración: engade cabeceiras para o almacenamento en caché de contido por parte do cliente (navegador). A cabeceira máis actual é o control da caché, a desactualizada é caduca. Ademais, pódese usar Etag. O principal é que a idade máxima do control da caché é o suficientemente grande (a partir dun mes ou máis). Se estás preparado para almacenar o recurso o máis duro posible, podes engadir a opción inmutable.

As CDN poden reducir o valor de idade máxima, o que obriga ao usuario a recargar contido estático con máis frecuencia. Non está claro a que está conectado isto: o desexo de aumentar o tráfico na rede ou aumentar a compatibilidade con sitios que non saben como restablecer a caché. Por exemplo, o tempo predeterminado da caché da cabeceira de Cloudflare é de 1 hora, o que é moi baixo para os datos estáticos inmutables.

3. Optimización da imaxe

Dado que a CDN asume as funcións de almacenamento en caché e servizo de imaxes, sería lóxico optimizalas no lado da CDN e servilas aos usuarios neste formulario. Fagamos unha reserva de inmediato de que esta función só está dispoñible para os tipos CDN 2, 3 e 5.

Podes optimizar as imaxes de varias maneiras: usando formatos de compresión avanzados (como WebP), codificadores máis eficientes (MozJPEG) ou simplemente limpando metadatos innecesarios.

En xeral, hai dous tipos de optimizacións deste tipo: con perda de calidade e sen perda de calidade. As CDN adoitan esforzarse en utilizar a optimización sen perdas para evitar posibles queixas dos clientes sobre cambios na calidade da imaxe. En tales condicións, a ganancia será mínima. En realidade, moitas veces o nivel de calidade JPEG é moito máis alto do necesario e pode recomprimir con seguridade cun nivel de calidade inferior sen comprometer a experiencia do usuario. Por outra banda, é difícil determinar o nivel de calidade e a configuración de forma universal para todas as posibles aplicacións web, polo que as CDN usan configuracións máis conservadoras en comparación coas que se poden aplicar tendo en conta o contexto (finalidade das imaxes, tipo de aplicación web). , etc.)

4. Optimización da conexión TLS

A maior parte do tráfico hoxe viaxa a través de conexións TLS, o que significa que dedicamos tempo extra á negociación TLS. Recentemente, desenvolvéronse novas tecnoloxías para acelerar este proceso. Por exemplo, esta é a criptografía EC, TLS 1.3, caché de sesión e tickets, aceleración de cifrado de hardware (AES-NI), etc. A configuración correcta de TLS pode reducir o tempo de conexión a 0-1 RTT (sen contar DNS e TCP ).

Co software moderno, non é difícil implementar tales prácticas por conta propia.

Non todos os CDN implementan as mellores prácticas de TLS; podes comprobalo medindo o tempo de conexión TLS (por exemplo, en Webpagetest). Ideal para unha nova conexión - 1RTT, 2RTT - nivel medio, 3RTT e máis - malo.

Tamén hai que ter en conta que mesmo cando se utiliza TLS a nivel CDN, o servidor coa nosa aplicación web tamén debe procesar TLS, pero dende o lado CDN, porque o tráfico entre o servidor e a CDN pasa pola rede pública. No peor dos casos, obteremos atrasos de conexión TLS dobres (o primeiro ao host CDN, o segundo entre este e o noso servidor).

Para algunhas aplicacións, paga a pena prestar atención aos problemas de seguridade: o tráfico adoita descifrarse nos nodos CDN, e esta é unha oportunidade potencial para a interceptación do tráfico. A opción de traballar sen divulgación de tráfico adoita ofrecerse nos plans de tarifas superiores por unha taxa adicional.

5. Reducir os atrasos de conexión

O principal beneficio do CDN do que todos falan: baixa latencia (menos distancia) entre o servidor CDN e o usuario. Conséguese mediante a creación dunha arquitectura de rede distribuída xeograficamente, na que os hosts estean situados en puntos de concentración de usuarios (cidades, puntos de intercambio de tráfico, etc.)

Na práctica, as prioridades para diferentes redes poden estar en rexións específicas. Por exemplo, as CDN rusas terán máis puntos de presenza en Rusia. Os americanos desenvolverán en primeiro lugar a rede en EE.UU. Por exemplo, un dos maiores CDN Cloudflare ten só 2 puntos en Rusia - Moscova e San Petersburgo. É dicir, podemos aforrar un máximo duns 10 ms de latencia en comparación coa colocación directa en Moscova.

A maioría das CDN occidentais non teñen puntos en Rusia. Ao conectar con eles, só podes aumentar os atrasos para a túa audiencia rusa.

6. Optimización de contidos (minificación, cambios estruturais)

O punto máis complexo e tecnoloxicamente avanzado. Cambiar o contido durante a entrega pode ser moi arriscado. Aínda que tomemos minificación: a redución do código fonte (debido a espazos extra, estruturas sen importancia, etc.) pode afectar o seu rendemento. Se falamos de cambios máis serios -mover o código JS ao final do HTML, fusionar ficheiros, etc.- o risco de perturbar a funcionalidade do sitio é aínda maior.

Polo tanto, só algúns CDN tipo 5 fan isto. Por suposto, non será posible automatizar todos os cambios necesarios para acelerar as cousas: é necesario realizar unha análise e optimización manual. Por exemplo, eliminar o código non utilizado ou duplicado é unha tarefa manual.

Como regra xeral, todas estas optimizacións están controladas pola configuración e as máis perigosas están desactivadas por defecto.

Soporte para capacidades de aceleración por tipo de CDN

Entón, vexamos que oportunidades potenciais de aceleración ofrecen os diferentes tipos de CDN.

Por comodidade, repetimos a clasificación.

1. CDN gratuíto para distribuír bibliotecas JS (MaxCDN, Google. Yandex).
2. CDN de servizos para a optimización do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imaxes).
3. CDN para optimización estática e de recursos en CMS (dispoñible en Bitrix, WordPress e outros).
4. CDN de propósito xeral (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para aceleración de sitios web (Cloudflare, Imperva, Airi).

Agora imos comparar as características e os tipos de CDN.

Oportunidade
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

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

Cabeceiras da caché
+
+
+
+
+

Imaxes
-
+–
+–
-
+

TLS
-
-
-
+–
+

Atrasos
-
-
-
+
+

Contido
-
-
-
-
+

Nesta táboa, "+" úsase para indicar soporte total, "-" non é soporte e "+-" é soporte parcial. Por suposto, pode haber desviacións desta táboa na realidade (por exemplo, algúns CDN de propósito xeral implementarán funcións para optimizar imaxes), pero para unha idea xeral é útil.

Resultados de

Con sorte, despois de ler este artigo terás unha imaxe máis clara sobre a recomendación de "utilizar un CDN" para acelerar os teus sitios.

Como en calquera empresa, non podes crer as promesas de mercadotecnia de ningún servizo. O efecto debe ser medido e probado en condicións reais. Se xa está a usar un CDN, comprobe a súa efectividade utilizando os criterios descritos no artigo.

É posible que usar un CDN neste momento estea retardando o tempo de carga do teu sitio.

Como recomendación xeral, podemos centrarnos no seguinte: estudar o seu público, determinar o seu alcance xeográfico. Se a túa audiencia principal está concentrada nun radio de 1-2 mil quilómetros, non necesitas un CDN para o seu propósito principal: reducir a latencia. Pola contra, podes colocar o teu servidor máis preto dos teus usuarios e configuralo correctamente, obtendo a maioría das optimizacións descritas no artigo (gratuítas e permanentes).

No caso de que a túa audiencia estea realmente distribuída xeograficamente (radio de máis de 3000 quilómetros), utilizar un CDN de calidade será realmente útil. Non obstante, cómpre comprender de antemán o que pode acelerar exactamente a súa CDN (consulte a táboa de capacidades e a súa descrición). Non obstante, a aceleración do sitio web segue sendo unha tarefa complexa que non se pode resolver conectando un CDN. Ademais das optimizacións anteriores, os medios de aceleración máis eficaces quedan detrás do CDN: optimización da parte servidor, cambios avanzados na parte cliente (eliminación de código non utilizado, optimización do proceso de renderizado, traballo con contidos, fontes, adaptabilidade, etc.). )

Fonte: www.habr.com