Explicación detallada del proceso de solicitud de CDN

Introducción a CDN

CDN es familiar para todos, aquí hay una breve introducción.

CDN principalmente permite a los usuarios obtener recursos de los nodos CDN que están muy cerca de los usuarios cuando acceden a los recursos, en lugar de ir a la máquina que realmente proporciona los servicios. Entonces CDN puede

1. Permita que los usuarios obtengan el contenido que necesitan más rápido
2. Reducir el tráfico de la red troncal
3. Reducir la presión del servidor

CDN ha pasado por tres etapas

La primera fase En 1995, Tim, el inventor de Internet, creó la primera empresa de servicios CDN Akamai

La segunda etapa 1999 ~ 2001, el clímax del desarrollo de Internet, CDN se desarrolló rápidamente

En la tercera etapa, Internet colapsó en 2001, las empresas de CDN quebraron y la empresa de Tim también quebró. A partir de 2002, las actualizaciones de banda ancha, los juegos y el desarrollo de video han llevado al desarrollo de CDN

Aunque CDN ha experimentado más de 20 años de desarrollo, aún no ha formado una especificación estándar y la implementación específica de cada empresa es diferente.Este artículo solo explica un tipo y espera brindarle una comprensión más profunda de CDN.

Proceso de solicitud de CDN

El proceso de solicitud de CDN es aproximadamente como se muestra en la figura a continuación, y lo presentaré brevemente a continuación. El cuadro sólido de la izquierda es la fase de búsqueda de DNS y el cuadro punteado de la derecha es el alcance de la CDN. https://www.processon.com/view/link/5ed5175e0791291d5dba30ea

Fase de búsqueda de DNS

El usuario solicita un enlace en el navegador, como event.mi.com, el navegador necesita encontrar la dirección IP correspondiente al nombre de dominio.

1. Primero verifique si hay un registro en el cliente DNS de su máquina, si no hay ningún registro

2. Obtener del servidor DNS local, si el servidor DNS local no tiene registro

3. Busque desde el servidor de nombres de dominio raíz (13 servidores de nombres de dominio raíz en todo el mundo), el nombre de dominio raíz devuelve la dirección del servidor de nombres de dominio com

4. El servidor DNS local busca desde el servidor de nombres de dominio com, y el servidor de nombres de dominio com devuelve la dirección autorizada del servidor de nombres de dominio de event.mi.com

• Servidor DNS de nombre de dominio autorizado: contiene toda la información del nombre de dominio

5. Después de encontrar el servidor de nombres de dominio autorizado, encontrará que el nombre de dominio tiene un CNAME, este CNAME generalmente apunta al sistema de equilibrio de carga global de la CDN

• Registro DNS A

  • El formato del registro A es "nombre de dominio-ip", y el registro es la dirección IP del servidor correspondiente al nombre de dominio.

• DNS CNAME

  CNAME es el alias del nombre de dominio, generalmente tiene dos funciones

  1) Varios nombres de dominio apuntan a la misma IP de servicio.Cuando la IP de servicio cambia, solo es necesario cambiar un registro A. Por ejemplo, el registro A del nombre de dominio www.abc.com es 1.1.1.1, y el alias del nombre de dominio mail.abc.com y study.abc.com se puede establecer en www.abc.com, de modo que cuando el servicio cambie la dirección IP, solo Es necesario cambiar el registro A de www.abc.com, no es necesario cambiar otros nombres de dominio, lo que reduce los costos de mantenimiento.

  2) El papel de CNAME en CDN también es muy importante. Para colgar un nombre de dominio en la CDN, debe configurar el CNAME del nombre de dominio en el nombre de dominio proporcionado por el proveedor de CDN, de modo que el proveedor de CDN pueda transferir tráfico a la CDN a través de DNS. Además, después de que el CNAME del nombre de dominio se establece en el nombre de dominio de la CDN, el registro A del nombre de dominio no puede existir. Generalmente , puede ver la resolución de DNS a través de los comandos nslookup y dig . Como se muestra en la figura siguiente, puede ver que el CNAME del nombre de dominio event.mi.com es un nombre de dominio de Baishan Cloud. Además, puede ver que el nombre de dominio de Baishan Cloud también tiene un CNAME correspondiente, principalmente para el balanceo de carga, que se explicará más adelante.
  

  3) La resolución de DNS descrita en este módulo utiliza una búsqueda iterativa. DNS también proporciona un método de búsqueda recursiva. Si está interesado, puede ver la diferencia entre los dos

Etapa CDN

A través del proceso de resolución de DNS descrito anteriormente, el operador de CDN les transfirió con éxito la solicitud

1. Hay muchas formas de implementar el sistema de equilibrio de carga global de CDN. Aquí hay una solución más común, el sistema de equilibrio de carga global basado en DNS.

• Primero, el sistema es DNS, que puede resolver nombres de dominio

• En segundo lugar, el sistema tiene una función de equilibrio de carga. En general, existen dos tipos de estrategias de equilibrio de carga para CDN, equilibrio de carga estático (seleccione diferentes servidores según la ubicación geográfica del usuario, operadores de red, etc.) y equilibrio de carga dinámico (seleccione servidores basados ​​en datos dinámicos como tráfico, rendimiento y carga del servidor). Debido a que el equilibrio de carga dinámico consume más recursos, los sistemas de equilibrio de carga global generalmente usan estrategias de equilibrio de carga estática, y los sistemas de equilibrio de carga regionales generalmente usan estrategias de equilibrio de carga dinámico.

• Por último, el sistema de equilibrio de carga global, basado en la estrategia de equilibrio de carga estática, selecciona la IP del sistema de equilibrio de carga regional apropiado para el solicitante.

• PD: En general, el sistema de equilibrio de carga global tendrá un sistema de respaldo y la configuración del sistema de respaldo es exactamente la misma que la del sistema actual. Cuando se descubre que la CDN está siendo atacada por DDos, el sistema de respaldo se activará, la ip del sistema de respaldo se agregará al DNS y el tiempo de caché de la configuración de la ip será mayor. Esta solución puede reducir los ataques de DDos.

• PD: El balanceo de carga tiene cuatro niveles de balanceo de carga y siete niveles de balanceo de carga. Los llamados cuatro y siete niveles corresponden a las siete capas de OSI. La cuarta capa solo puede realizar balanceo de carga basado en IP, etc., y la séptima capa puede obtener la información solicitada, como Las cookies, etc. hacen balanceo de carga, nuestro nginx de uso común puede hacer balanceo de carga de cuatro niveles y balanceo de carga de siete niveles.

2. El cliente solicita el sistema de equilibrio de carga regional CDN, que determinará el servidor de caché CDN que proporciona el servicio. Los sistemas regionales de equilibrio de carga generalmente usan estrategias dinámicas. Por esta razón, se necesita un servidor separado para recopilar información diversa de los servidores de caché CDN en la región (como la capacidad de la sesión, el tiempo de ida y vuelta, el tráfico, la ubicación de la caché, etc.)

• Aquí hay una breve introducción a cómo seleccionar un servidor de caché CDN según la ubicación de la caché. El principio de implementación de este método es muy simple: la URL solicitada se hace coincidir con un servidor de caché CDN a través de un algoritmo determinado, y cuando la URL se solicite nuevamente en el futuro, seguirá llegando al servidor de caché. La ventaja de este método es que ahorra espacio: una solicitud se almacena en un solo servidor y no hay redundancia. La desventaja es que si es una URL activa, la presión del servidor será demasiado alta y, si hay un problema con el servidor, todas las solicitudes pueden devolverse a la fuente.

3. Si el servidor de caché CDN proporcionado por el sistema de equilibrio de carga regional no está en caché o el caché no es válido, se realizará una solicitud al servidor de caché CDN de nivel superior. Los protocolos más utilizados son ICP / HTCP / CARP, etc. Por supuesto, el conocimiento básico de la Web se utiliza para juzgar la invalidación de la caché, como Pragma, Expires, Cache-Control, Last-Modified, Etag, etc.

4. Si el servidor de caché de CDN superior aún no está almacenado en caché o ha expirado, solicitará el archivo en la máquina de origen y lo almacenará en caché después de que la solicitud sea exitosa

Algunos problemas en el uso de CDN

CDN es muy útil contra una alta concurrencia, puede consultar este artículo "Técnicas comunes de almacenamiento en caché"

Sin embargo, al usar CDN, también puede encontrar algunos problemas, aquí le contaré algunos problemas que he encontrado.

La obtención de archivos lleva demasiado tiempo

Recientemente encontré un problema. Me tomó 120 segundos obtener una imagen de 50 KB a través de CDN.

La razón de esto es que hay un problema con la configuración de balanceo de carga del fabricante de la CDN. Bajo la configuración incorrecta, para obtener la imagen, necesita viajar la mitad de la tierra. Más tarde, después de permitir que el fabricante de CDN modifique la configuración, solo toma 0.2s.

Obtener archivo incorrecto

El producto debe tener un sitio del producto, y el sitio del producto hará referencia al archivo js. Cada vez que cambia el sitio del producto, el nombre js no cambiará, pero la etiqueta js cambiará, como base.js? V01 a base.js? V02. El archivo js está configurado para que nunca caduque. Si cambia el número de versión, se devolverá a la fuente, que es la premisa.

Si el sitio del producto no coincide con la versión js, el sitio del producto producirá algunos errores, como que la página no se puede abrir o algunas funciones no se pueden utilizar. Hay dos situaciones en las que el sitio del producto y js no coinciden

1. El sitio del producto es la nueva versión, js es la versión anterior

Esta situación generalmente se debe al hecho de que js no se lanzó por primera vez a la máquina back-to-source cuando se lanzó, sino que se lanzó por primera vez un nuevo sitio de producto, de modo que cuando el sitio del nuevo producto solicite nuevos js, solicitará la máquina back-to-source y regresará La máquina de origen sigue siendo la versión anterior, por lo que el antiguo js se trata como el nuevo caché de js. Después de que esto suceda, generalmente se genera una nueva versión de js y la operación de liberación se realiza nuevamente.

2. El sitio del producto es la versión anterior, js es la nueva versión

Hay muchas razones para esta situación y, a menudo, es difícil lidiar con ella. Un requisito previo para que esto suceda es que el nuevo js se haya lanzado a la máquina de origen y el sitio del producto anterior aún no se haya publicado

• Cuando solo hay un proveedor de servicios CDN, si los usuarios están todos en el extranjero y visitan el sitio del producto en China en este momento, de acuerdo con la estrategia global de equilibrio de carga, esta solicitud es la primera solicitud en el país y no hay caché en la CDN. El js obtenido es Es un nuevo js, ​​pero la probabilidad de que esto ocurra es relativamente pequeña y el impacto no es grande.
• Cuando hay varios proveedores de servicios CDN, la probabilidad de que esto suceda es extremadamente alta. Debido a que los diferentes proveedores de servicios tienen diferentes áreas de servicio, y la operación y el mantenimiento también pueden implementar el tráfico de diferentes proveedores de servicios, es probable que la solicitud js no esté en la CDN, lo que da como resultado una situación de regreso al origen. En este caso, la caché de CDN generalmente se elimina para forzar un acuerdo de versión, pero aún puede afectar a los usuarios
• Otra situación es que si los archivos solo se almacenan en caché en un servidor de caché CDN, si el servidor falla, también se producirá el retorno al origen. Sin embargo, esta situación es poco común, porque la probabilidad de daño del servidor no es alta y hay un servidor de caché en la capa superior del servidor CDN, por lo que la probabilidad es pequeña.

Solicitar masivo

Después de que esto suceda, el servidor suele estar abrumado. La razón de esto es que la mayoría de los proveedores de servicios de CDN juzgan el acierto de CDN en función de la URL completa. Si la URL se promociona a través de anuncios de Google, se agregará un sufijo diferente más adelante y no se alcanzará. Para evitar que esto suceda, puede dejar que la operación y el mantenimiento ayuden a realizar una configuración especial, y solo los cambios especificados en los parámetros de consulta volverán a la fuente (es posible que la operación y el mantenimiento no quieran realizar esta operación porque no conduce a un mantenimiento posterior), o mejorar el rendimiento de su propio servicio.

​

Al final

Si te gusta mi artículo, puedes seguir mi cuenta pública (Programador Mala Tang)

Explicación detallada del proceso de solicitud de CDN

Reflexiones sobre el desarrollo profesional de los programadores

La historia del servicio de blogs siendo aplastado

Técnicas comunes de almacenamiento en caché

Cómo conectarse de manera eficiente con pagos de terceros

Versión concisa del marco de gin

Pensando en la revisión del código

datos

1. https://cloud.tencent.com/developer/article/1349559
2. https://www.cnblogs.com/liyuanhong/articles/7353974.html
3. https://www.jianshu.com/p/4d8df62d55e3
4. https://blog.csdn.net/jiajiren11/article/details/80071312?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2. 2.ninguno
5. Introducción a la función y el uso de DNS en CDN
6. https://mp.weixin.