[No] utilitzeu un CDN

Gairebé tots els articles o eines per optimitzar la velocitat del lloc tenen una clàusula modesta "utilitza un CDN". En general, CDN és una xarxa de lliurament de contingut o xarxa de lliurament de contingut. A Method Lab sovint ens trobem amb preguntes dels clients sobre aquest tema; alguns d'ells activen el seu propi CDN. L'objectiu d'aquest article és entendre què pot proporcionar un CDN en termes de velocitat de càrrega del lloc, quins problemes poden sorgir i en quins casos es justifica l'ús d'un CDN.

Els retards encerclats a la imatge són causats per l'ús d'un CDN.

Una mica d'història

Com moltes tecnologies, els CDN van sorgir per necessitat. Amb el desenvolupament dels canals d'Internet entre els usuaris d'Internet, van aparèixer els serveis de vídeo en línia. Naturalment, el contingut de vídeo requereix ordres de magnitud més amplada de banda en comparació amb el contingut habitual del lloc web (imatges, text i codi CSS o JS).

Quan intenteu emetre un flux de vídeo en paral·lel a molts clients des d'un servidor, el canal d'Internet del servidor probablement es convertirà en el coll d'ampolla. Com a regla general, uns quants milers de fils són suficients per obstruir un canal de servidor típic. Per descomptat, hi pot haver altres limitacions de recursos, però ara mateix no són importants. També és important que ampliar el canal del servidor sigui massa car (i de vegades impossible) i també poc pràctic. La càrrega al canal durant les emissions serà cíclica.

El problema de limitar el canal d'un servidor individual està perfectament resolt per CDN. Els clients no es connecten directament al servidor, sinó als nodes de la xarxa CDN. En una situació ideal, el servidor envia un flux al node CDN i, a continuació, la xarxa utilitza els seus propis recursos per lliurar aquest flux a molts usuaris. Des del punt de vista econòmic, paguem només pels recursos realment consumits (pot ser ample de banda o trànsit) i obtenim una excel·lent escalabilitat del nostre servei. L'ús d'un CDN per oferir contingut pesat està completament justificat i lògic. Tot i que val la pena assenyalar que els jugadors més importants d'aquest espai (per exemple, Netflix) estan construint els seus propis CDN en lloc d'utilitzar grans CDN comercials (Akamai, Cloudflare, Fastly, etc.)

A mesura que la web ha evolucionat, les aplicacions web en si s'han tornat més complexes i complexes. El problema de la velocitat de càrrega va sortir al primer pla. Els entusiastes de la velocitat dels llocs web van identificar ràpidament diversos problemes importants que feien que els llocs web es carreguessin lentament. Un d'ells va ser els retards de la xarxa (RTT - temps d'anada i tornada o temps de ping). Els retards afecten molts processos en la càrrega del lloc web: establir una connexió TCP, iniciar una sessió TLS, carregar cada recurs individual (imatge, fitxer JS, document HTML, etc.)

El problema es va agreujar pel fet que quan s'utilitzava el protocol HTTP/1.1 (abans de l'arribada de SPDY, QUIC i HTTP/2 aquesta era l'única opció), els navegadors no obrien més de 6 connexions TCP a un host. Tot això va provocar un temps d'inactivitat de la connexió i un ús ineficient de l'ample de banda del canal. El problema es va resoldre parcialment mitjançant la fragmentació del domini: la creació d'amfitrions addicionals per superar el límit del nombre de connexions.

Aquí és on apareix la segona capacitat de CDN: reduir la latència (RTT) a causa del gran nombre de punts i la proximitat dels nodes a l'usuari. La distància juga aquí un paper decisiu: la velocitat de la llum és limitada (uns 200 km/s en fibra òptica). Això vol dir que cada 000 km de recorregut afegeix 1000 ms de retard o 5 ms a RTT. Aquest és el temps mínim necessari per a la transmissió, ja que també hi ha retards en els equips intermedis. Com que un CDN normalment sap com emmagatzemar objectes a la memòria cau als seus servidors, podem beneficiar-nos de carregar aquests objectes a través d'un CDN. Condicions necessàries per a això: la presència de l'objecte a la memòria cau, la proximitat del punt CDN a l'usuari en comparació amb el servidor d'aplicacions web (servidor d'origen). És important entendre que la proximitat geogràfica d'un node CDN no garanteix una latència baixa. L'encaminament entre el client i el CDN es pot construir de manera que el client es connecti a un host d'un altre país, i possiblement a un altre continent. És aquí on entra en joc la relació entre els operadors de telecomunicacions i el servei CDN (peering, connexions, participació en IX, etc.) i la política d'encaminament del trànsit de la mateixa CDN. Per exemple, Cloudflare, quan s'utilitza dos plans inicials (gratuïts i barats), no garanteix el lliurament de contingut de l'amfitrió més proper: l'amfitrió serà seleccionat per aconseguir el cost mínim.

Moltes empreses líders d'Internet atrauen l'interès públic (desenvolupadors web i propietaris de serveis) pel tema de la velocitat de càrrega i el rendiment del lloc web. Entre aquestes empreses hi ha Yahoo (eina Yslow), AOL (WebPageTest) i Google (servei Page Speed ​​​​Insights), que estan desenvolupant les seves pròpies recomanacions per accelerar els llocs (principalment es refereixen a l'optimització de clients). Més tard, apareixen noves eines de prova de velocitat del lloc web, que també ofereixen consells per augmentar la velocitat del lloc web. Cadascun d'aquests serveis o connectors té una recomanació coherent: "Feu servir un CDN". La reducció de la latència de la xarxa se sol citar com a explicació de l'efecte de CDN. Malauradament, no tothom està preparat per entendre exactament com s'aconsegueix l'efecte d'acceleració del CDN i com es pot mesurar, de manera que la recomanació es pren per fe i s'utilitza com a postulat. De fet, no tots els CDN es creen iguals.

Utilitzant CDN avui

Per avaluar la utilitat d'utilitzar CDN, cal classificar-los. Què es pot trobar ara a la pràctica (els exemples entre parèntesis, per descomptat, no són exhaustius):

1. CDN gratuït per distribuir biblioteques JS (MaxCDN, Google. Yandex).
2. CDN de serveis per a l'optimització del client (per exemple, Google Fonts per a fonts, Cloudinary, Cloudimage per a imatges).
3. CDN per a l'optimització estàtica i de recursos en CMS (disponible a Bitrix, WordPress i altres).
4. CDN de propòsit general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN per a l'acceleració de llocs web (Cloudflare, Imperva, Airi).

La diferència clau entre aquests tipus és la quantitat del trànsit que passa pel CDN. Els tipus 1-3 són el lliurament de només una part del contingut: des d'una sol·licitud fins a diverses dotzenes (normalment imatges). Els tipus 4 i 5 són el proxy complet del trànsit mitjançant un CDN.

A la pràctica, això significa el nombre de connexions que s'utilitzen per carregar el lloc. Amb HTTP/2, fem servir una única connexió TCP a l'amfitrió per processar qualsevol nombre de sol·licituds. Si dividim els recursos en l'amfitrió principal (origen) i el CDN, llavors és necessari distribuir les sol·licituds entre diversos dominis i crear diverses connexions TCP. El pitjor dels casos és: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Aquesta fórmula no té en compte els retards a les xarxes mòbils per a l'activació del canal de ràdio del dispositiu (si no estava actiu) i els retards a la torre mòbil.

A continuació es mostra com es veu a la cascada de càrrega del lloc (les latències per connectar-se al CDN es destaquen a RTT 150 ms):

Si el CDN cobreix tot el trànsit del lloc (excepte els serveis de tercers), podem utilitzar una única connexió TCP, estalviant retards en connectar-nos a amfitrions addicionals. Per descomptat, això s'aplica a les connexions HTTP/2.

Més diferències estan determinades per la funcionalitat d'un CDN en particular: per al primer tipus només allotja un fitxer estàtic, per al cinquè està canviant diversos tipus de contingut del lloc amb finalitats d'optimització.

Capacitats CDN per a l'acceleració de llocs web

Descriurem la gamma completa de capacitats de CDN per accelerar llocs, sense tenir en compte la funcionalitat dels tipus individuals de CDN, i després veurem què s'implementa en cadascun d'ells.

1. Compressió de recursos de text

La característica més bàsica i comprensible, però sovint mal implementada. Tots els CDN declaren la presència de compressió com a característica d'acceleració. Però si ens fixem amb més detall, les deficiències queden clares:

• es poden utilitzar graus baixos per a la compressió dinàmica: 5-6 (per exemple, per a gzip, el màxim és 9);
• La compressió estàtica (fitxers a la memòria cau) no utilitza funcions addicionals (per exemple, zopfi o brotli amb grau 11)
• no hi ha suport per a una compressió eficient de brotli (estalvi d'un 20% en comparació amb gzip).

Si utilitzeu un CDN, val la pena comprovar aquests pocs punts: agafeu el fitxer que prové del CDN, registreu-ne la mida comprimida i comprimiu-lo manualment per comparar-lo (podeu utilitzar algun servei en línia amb suport brotli, per exemple). vsszhat.rf).

2. Configuració de les capçaleres de la memòria cau del client

També una característica senzilla d'acceleració: afegiu capçaleres per a l'emmagatzematge en memòria cau del contingut del client (navegador). La capçalera més actual és el control de memòria cau, la obsoleta caduca. A més, es pot utilitzar Etag. El més important és que l'edat màxima del control de memòria cau és prou gran (a partir d'un mes o més). Si esteu preparats per emmagatzemar el recurs a la memòria cau tan dur com sigui possible, podeu afegir l'opció immutable.

Els CDN poden reduir el valor màxim d'edat, obligant l'usuari a tornar a carregar contingut estàtic amb més freqüència. No està clar amb què està connectat això: el desig d'augmentar el trànsit a la xarxa o augmentar la compatibilitat amb llocs que no saben com restablir la memòria cau. Per exemple, el temps per defecte de la memòria cau de la capçalera de Cloudflare és d'1 hora, que és molt baix per a dades estàtiques immutables.

3. Optimització de la imatge

Atès que el CDN assumeix les funcions d'emmagatzematge en memòria cau i de servei d'imatges, seria lògic optimitzar-les al costat del CDN i servir-les als usuaris d'aquesta forma. Reservem de seguida que aquesta funció només està disponible per als tipus CDN 2, 3 i 5.

Podeu optimitzar les imatges de diverses maneres: utilitzant formats de compressió avançats (com ara WebP), codificadors més eficients (MozJPEG) o simplement netejant metadades innecessàries.

En general, hi ha dos tipus d'optimitzacions d'aquest tipus: amb pèrdua de qualitat i sense pèrdua de qualitat. Els CDN solen s'esforcen per utilitzar l'optimització sense pèrdues per evitar possibles queixes dels clients sobre canvis en la qualitat de la imatge. En aquestes condicions, el guany serà mínim. En realitat, sovint el nivell de qualitat JPEG és molt més alt del necessari i podeu tornar a comprimir amb seguretat amb un nivell de qualitat inferior sense comprometre l'experiència de l'usuari. D'altra banda, és difícil determinar el nivell de qualitat i la configuració de manera universal per a totes les aplicacions web possibles, de manera que les CDN utilitzen configuracions més conservadores en comparació amb les que es poden aplicar tenint en compte el context (propòsit de les imatges, tipus d'aplicació web). , etc.)

4. Optimització de la connexió TLS

La majoria del trànsit d'avui viatja per connexions TLS, el que significa que dediquem més temps a la negociació TLS. Recentment, s'han desenvolupat noves tecnologies per accelerar aquest procés. Per exemple, això és la criptografia EC, TLS 1.3, memòria cau de sessió i tiquets, acceleració de xifratge de maquinari (AES-NI), etc. La configuració correcta de TLS pot reduir el temps de connexió a 0-1 RTT (sense comptar DNS i TCP).

Amb el programari modern, no és difícil implementar aquestes pràctiques pel vostre compte.

No tots els CDN implementen les millors pràctiques de TLS; podeu comprovar-ho mesurant el temps de connexió TLS (per exemple, a Webpagetest). Ideal per a una nova connexió - 1RTT, 2RTT - nivell mitjà, 3RTT i més - dolent.

També cal tenir en compte que fins i tot quan s'utilitza TLS a nivell CDN, el servidor amb la nostra aplicació web també ha de processar TLS, però des del costat CDN, perquè el trànsit entre el servidor i el CDN passa per la xarxa pública. En el pitjor dels casos, obtindrem el doble de retards de connexió TLS (el primer a l'amfitrió CDN, el segon entre aquest i el nostre servidor).

Per a algunes aplicacions, val la pena parar atenció als problemes de seguretat: el trànsit normalment es desxifra als nodes CDN, i aquesta és una oportunitat potencial per a la intercepció del trànsit. L'opció de treballar sense divulgació de trànsit s'ofereix normalment als plans de tarifes superiors per una tarifa addicional.

5. Reduir els retards de connexió

El principal avantatge del CDN del qual tothom parla: baixa latència (menys distància) entre l'amfitrió CDN i l'usuari. S'aconsegueix creant una arquitectura de xarxa distribuïda geogràficament, en la qual els hosts es troben en punts de concentració d'usuaris (ciutats, punts d'intercanvi de trànsit, etc.)

A la pràctica, les prioritats per a diferents xarxes poden estar en regions específiques. Per exemple, els CDN russos tindran més punts de presència a Rússia. Els americans desenvoluparan en primer lloc la xarxa als EUA. Per exemple, un dels CDN Cloudflare més grans només té 2 punts a Rússia: Moscou i Sant Petersburg. És a dir, podem estalviar un màxim d'uns 10 ms de latència en comparació amb la col·locació directa a Moscou.

La majoria de CDN occidentals no tenen punts a Rússia. En connectar-s'hi, només podeu augmentar els retards per al vostre públic rus.

6. Optimització de continguts (minificació, canvis estructurals)

El punt més complex i tecnològicament avançat. Canviar el contingut durant el lliurament pot ser molt arriscat. Fins i tot si prenem la minificació: reduir el codi font (a causa d'espais addicionals, estructures sense importància, etc.) pot afectar el seu rendiment. Si parlem de canvis més greus -motar el codi JS al final de l'HTML, fusionar fitxers, etc.- el risc d'interrompre la funcionalitat del lloc és encara més gran.

Per tant, només alguns CDN de tipus 5 ho fan. Per descomptat, no serà possible automatitzar tots els canvis necessaris per accelerar les coses; calen anàlisis i optimitzacions manuals. Per exemple, eliminar el codi no utilitzat o duplicat és una tasca manual.

Per regla general, totes aquestes optimitzacions estan controlades per la configuració i les més perilloses estan desactivades per defecte.

Suport per a les capacitats d'acceleració per tipus de CDN

Per tant, fem una ullada a quines oportunitats potencials d'acceleració ofereixen els diferents tipus de CDN.

Per comoditat, repetim la classificació.

1. CDN gratuït per distribuir biblioteques JS (MaxCDN, Google. Yandex).
2. CDN de serveis per a l'optimització del client (per exemple, Google Fonts per a fonts, Cloudinary, Cloudimage per a imatges).
3. CDN per a l'optimització estàtica i de recursos en CMS (disponible a Bitrix, WordPress i altres).
4. CDN de propòsit general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN per a l'acceleració de llocs web (Cloudflare, Imperva, Airi).

Ara comparem les característiques i els tipus de CDN.

Oportunitat
Tipus 1
Tipus 2
Tipus 3
Tipus 4
Tipus 5

Compressió de text
+–
-
+–
+–
+

Capçaleres de la memòria cau
+
+
+
+
+

Imatges
-
+–
+–
-
+

TLS
-
-
-
+–
+

Retards
-
-
-
+
+

Contingut
-
-
-
-
+

En aquesta taula, "+" s'utilitza per indicar suport total, "-" no és cap suport i "+-" és suport parcial. Per descomptat, pot haver-hi desviacions d'aquesta taula en realitat (per exemple, alguns CDN de propòsit general implementaran funcions per optimitzar imatges), però per a una idea general és útil.

Resultats de

Amb sort, després de llegir aquest article tindreu una idea més clara sobre la recomanació d'"utilitzar un CDN" per accelerar els vostres llocs.

Com en qualsevol negoci, no us podeu creure les promeses de màrqueting de cap servei. L'efecte s'ha de mesurar i provar en condicions reals. Si ja esteu utilitzant un CDN, comproveu-ne l'eficàcia mitjançant els criteris descrits a l'article.

És possible que l'ús d'un CDN ara mateix alenti el temps de càrrega del vostre lloc.

Com a recomanació general, podem centrar-nos en el següent: estudiar el vostre públic, determinar el seu abast geogràfic. Si el vostre públic principal es concentra en un radi d'1 a 2 mil quilòmetres, no necessiteu un CDN per al seu propòsit principal: reduir la latència. En canvi, podeu col·locar el vostre servidor més a prop dels vostres usuaris i configurar-lo correctament, obtenint la majoria de les optimitzacions descrites a l'article (gratuïtes i permanents).

En cas que el vostre públic estigui realment distribuït geogràficament (radi de més de 3000 quilòmetres), utilitzar un CDN de qualitat serà realment útil. Tanmateix, heu d'entendre per endavant què pot accelerar exactament el vostre CDN (vegeu la taula de capacitats i la seva descripció). Tanmateix, l'acceleració del lloc web segueix sent una tasca complexa que no es pot resoldre connectant un CDN. A més de les optimitzacions anteriors, darrere del CDN es mantenen els mitjans d'acceleració més efectius: optimització de la part del servidor, canvis avançats a la part del client (eliminació de codi no utilitzat, optimització del procés de renderització, treball amb contingut, tipus de lletra, adaptabilitat, etc.). )

Font: www.habr.com