Hispanopedia Wiki
Articulo de referencia

interconexión de redes de entrega de contenido

La interconexión de redes de distribución de contenido (CDNI) es un conjunto de interfaces y mecanismos necesarios para interconectar dos redes de distribución de contenido (CDN...

Hispanopedia WikiContenido en espanolLectura gratuita

La interconexión de redes de distribución de contenido (CDNI) es un conjunto de interfaces y mecanismos necesarios para interconectar dos redes de distribución de contenido (CDN) independientes, lo que permite que una distribuya contenido en nombre de la otra. Las CDN interconectadas ofrecen numerosas ventajas, como la ampliación de la cobertura , la reducción de costes de infraestructura y una mayor disponibilidad, entre otras, para los proveedores de servicios de contenido (CSP), las CDN y los usuarios finales. Entre sus múltiples aplicaciones, permite la interconexión de pequeñas CDN y proporciona servicios a los CSP que les permiten competir con las CDN de los CSP globales.

Razón fundamental

Gracias a las numerosas ventajas de las CDN, como la reducción de costes de entrega, la mejora de la calidad de la experiencia (QoE) y el aumento de la robustez en la entrega, estas se han popularizado para la distribución a gran escala de contenido almacenable en caché. Por este motivo, los proveedores de CDN están ampliando su infraestructura y muchos proveedores de servicios de Internet (ISP) y de red (NSP) han implementado o están implementando sus propias CDN para su propio uso o en régimen de arrendamiento, tras un acuerdo comercial y técnico con un proveedor de CDN. Estas CDN independientes, con sistemas y protocolos bien definidos de enrutamiento, entrega, adquisición y contabilidad de solicitudes, pueden enfrentarse tarde o temprano a limitaciones de espacio, recursos o capacidad. La CDNI tiene como objetivo aprovechar las CDN independientes para proporcionar una entrega integral de contenido desde los CSP hasta los usuarios finales, independientemente de su ubicación o red de conexión.

Ejemplo de operación

Consideremos la interconexión de dos CDN como se muestra en la siguiente figura. El ISP-A implementa una CDN ascendente (uCDN) autorizada y ha establecido un acuerdo técnico y comercial con el CSP. Dado que la CDN-A está autorizada para prestar servicios en nombre del CSP, un usuario en la red del ISP-B solicita contenido a la CDN-A (1). La uCDN puede atender la solicitud directamente o redirigirla a una CDN descendente (dCDN) si, por ejemplo, esta se encuentra más cerca del equipo de usuario (UE). Si la solicitud se redirige, las CDN interconectadas deben proporcionar el contenido solicitado a la dCDN. Si el contenido no está disponible en la uCDN, se puede obtener primero del CSP (2) y luego enviarlo a un intermediario en la dCDN (3). El UE, tras la redirección, solicitará el contenido a la dCDN (4) y, finalmente, el intermediario lo distribuirá.

Un ejemplo de entrega de contenido de extremo a extremo mediante CDNI.
Un ejemplo de entrega de contenido de extremo a extremo mediante CDNI.

En este ejemplo, las cuatro partes se benefician de la interconexión: los usuarios finales disfrutan de una mejor calidad de servicio (QoS); el proveedor de servicios de comunicación (CSP) se beneficia al tener que realizar un único acuerdo comercial y técnico con la uCDN; la uCDN se beneficia al no tener que desplegar una CDN tan extensa; y la dCDN recibe una compensación por la entrega. Los procedimientos y algoritmos para seleccionar la dCDN adecuada, elegir un servidor sustituto y adquirir el contenido que se enviará a dicho servidor pueden variar, pero la dCDN sirve el contenido en nombre de la uCDN.

Casos de uso

A continuación se muestra una lista incompleta de casos de uso para los que se presentó CDNI. [ 1 ] Los casos de uso parecen converger entre los enfoques de estandarización (véase la sección Estado de la estandarización ).

Extensión de la huella

Footprint se define como una región para la cual una CDN puede entregar contenido. Con una CDNI implementada, los proveedores de CDN no globales pueden ofrecer a los CSP una huella geográfica extendida sin

  • comprometiendo la calidad de la entrega;
  • costos de tránsito adicionales, si el contenido se va a servir desde servidores sustitutos geográficamente o topológicamente remotos; y
  • El despliegue y la operación de sistemas sustitutos no se justifican en la región correspondiente, por ejemplo, debido a los altos costos de inversión y al bajo volumen de entregas.

Una interconexión puede resultar atractiva para un gran proveedor de CDN que posea numerosas redes de distribución de contenido (CDN) en diversas ubicaciones y que desee hacerlas interoperables.

La extensión de la cobertura de CDN también resulta beneficiosa en los casos en que los proveedores de CDN distribuyen gran cantidad de contenido popular a las redes de pocos proveedores de servicios de Internet (ISP). En tal caso, la interconexión de dichas CDN ofrecería una mejor calidad de servicio (QoS) y experiencia de usuario (QoE) a los usuarios finales, reduciría y permitiría controlar el tráfico entrante en la red del ISP, disminuiría la capacidad de hardware y la cobertura de uCDN, y permitiría al ISP obtener ingresos.

Además, las redes interconectadas pueden permitir a los usuarios finales nómadas acceder a contenido con una calidad de experiencia consistente en una variedad de dispositivos y/o regiones geográficas.

Descargar

Una CDN puede ser muy útil para gestionar la sobrecarga, ya que permite distribuir los picos de tráfico inesperados, como una afluencia repentina que supere los picos para los que se dimensionó una CDN, entre la uCDN y la dCDN. Si las CDN comparten sus recursos, pueden beneficiarse de un ahorro en el dimensionamiento. Para que este mecanismo funcione correctamente, la uCDN requiere información en tiempo real de la dCDN sobre la cantidad de tráfico que puede descargar. En cambio, para eventos planificados, como el mantenimiento o la distribución de eventos especiales, una reserva de recursos estática puede ser suficiente.

Además, una CDNI proporciona resiliencia ante fallos en la entrega y adquisición de contenido. Su implementación, en casos donde los servidores sustitutos y de origen de los CSP no estén disponibles, permite redirigir las solicitudes de entrega a otra CDN. De igual modo, con una CDNI implementada, si falla una fuente de adquisición predeterminada, se pueden utilizar otras fuentes dentro de la interconexión, por ejemplo, una uCDN alternativa. Esto, a su vez, proporciona equilibrio de carga entre las fuentes de adquisición de contenido.

Capacidad

Una CDN puede servir para ampliar la gama de dispositivos y tecnologías de red compatibles si una CDN no puede ofrecerlos o si su proveedor no está dispuesto a proporcionarlos. Por ejemplo, un proveedor de CDN podría querer ampliar su cartera de servicios a la transmisión HTTP adaptativa y/o IPv6, mientras que actualmente solo ofrece transmisión HTTP y/o IPv4. Esta ampliación se puede lograr mediante la interconexión con una CDN que pueda proporcionar los protocolos solicitados. De manera similar, una interconexión puede permitir que un proveedor de CDN de línea fija extienda sus servicios a dispositivos móviles.

Cuando un proveedor de CDN gestiona muchas redes con diferentes tecnologías, tiene una estrategia de múltiples proveedores o implementa redes separadas para muchos CSP, una interconexión puede facilitar el establecimiento de la interoperabilidad entre tecnologías y proveedores mediante la simplificación o automatización de algunas operaciones entre CDN.

Otro caso de uso sería una mejora de la calidad de servicio (QoS) y la experiencia del usuario (QoE) para un proveedor de CDN si existiera una opción de interconexión con una red de servidores sustitutos más cercanos a los usuarios finales.

Interfaces en CDNI

El Grupo de Trabajo de Ingeniería de Internet (IETF) (véase la sección Estado de estandarización ) [ 1 ] [ 2 ] define cinco interfaces necesarias para interconectar un par de CDN desde una perspectiva técnica, como se muestra en la Figura 2. Estas interfaces son interfaces del plano de control que operan en la capa de aplicación y cuyo objetivo es reutilizar o aprovechar protocolos existentes, como HTTP, en lugar de definir uno nuevo. Este modelo de CDNI no define las interfaces ni los mecanismos de adquisición, entrega y solicitud de contenido, ya que actualmente las CDN ya utilizan protocolos estandarizados para ello; por ejemplo, HTTP, FTP, rsync, etc., se utilizan para la adquisición de contenido. La interconexión permite conectar varias CDN en diversas topologías, como línea, malla o topología de inicio. Es importante destacar que, para implementar una CDNI, se deben establecer acuerdos comerciales adicionales entre el CSP y la uCDN, y entre la uCDN y la dCDN. En el momento de redactar este documento, el funcionamiento detallado de las interfaces y la estructura de los objetos intercambiados se encuentran en proceso de estandarización. [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] Las interfaces definidas se describen brevemente a continuación.

Un modelo CDNI según la definición del IETF.
Un modelo CDNI según la definición del IETF.

Interfaz de control (IC)

La interfaz de control (CI) está diseñada para iniciar una interconexión entre dos CDN y configurar las demás interfaces CDNI. Por ejemplo, la interfaz de control puede utilizarse para proporcionar la dirección del servidor de registro y así configurar la interfaz de registro, o para establecer asociaciones de seguridad para otras interfaces. También permite que una uCDN preposicione, revalide o elimine metadatos y contenido en una dCDN.

Interfaz de redirección de enrutamiento de solicitudes (RI)

Redirige y selecciona una CDN de entrega para una solicitud de usuario determinada. Esta interfaz proporciona un mecanismo de detección y prevención de bucles para las solicitudes atendidas.

Interfaz publicitaria de huella digital y capacidades (FCI)

Permite el intercambio asíncrono de información de enrutamiento sobre capacidades y huella para admitir la selección de dCDN para solicitudes de usuario posteriores. La unión de las interfaces RI y FCI denota la interfaz de solicitud.

Interfaz de metadatos (IM)

Permite que una dCDN proporcione metadatos de contenido desde una uCDN. Estos metadatos pueden incluir información sobre la autorización requerida, el bloqueo geográfico, los periodos de disponibilidad y las listas blancas y negras de delegación. Esta información puede, por ejemplo, limitar la distribución a un país determinado o restringir el acceso al contenido para adultos solo durante la noche. Los metadatos recopilados se utilizan posteriormente para la redirección de CDNI y las respuestas a las solicitudes de contenido de los usuarios.

Interfaz de registro (LI)

Permite intercambiar detalles sobre la distribución y entrega de contenido mediante interconexión. El intercambio en tiempo real se puede utilizar para la monitorización del tráfico, mientras que el intercambio fuera de línea se puede utilizar para la facturación al usuario final o la facturación entre redes de distribución de contenido (CDN) interconectadas.

Criterios de selección de CDN descendentes

Para la selección de una dCDN, se utiliza principalmente la información sobre su huella y capacidades. La huella se puede especificar mediante subredes IP, números de sistemas autónomos (AS) o combinaciones de país, estado y código. [ 9 ] Las capacidades describen las características, servicios y estados que una CDN puede o no puede cumplir e incluyen capacidades de red y administrativas, información sobre cachés y recursos. La información de red puede revelar detalles sobre QoS o el ancho de banda de transmisión admitido. Las capacidades administrativas pueden informar sobre los límites y políticas establecidos. Los datos sobre las cachés pueden informar sobre la carga y los recursos disponibles. La información de recursos puede especificar las tecnologías de entrega y los tipos de contenido admitidos, como la capacidad de transmitir video a un tipo de dispositivo en particular.

Conociendo la información sobre la huella digital y las capacidades, la uCDN puede proceder a la selección inicial de una dCDN, primero en función de la huella digital y luego de las capacidades. Sin embargo, estos procedimientos pueden dar lugar a decisiones subóptimas o incorrectas; por ejemplo, si la dCDN se selecciona en función de la huella digital, no puede proporcionar la tecnología de entrega solicitada. Por lo tanto, un procedimiento más adecuado consiste en incluir la información sobre la huella digital entre los requisitos de capacidades.

Se consideran varios protocolos para el intercambio de información, ya sea sobre la huella digital, como BGP, sobre las capacidades, como HTTP, o sobre ambas, como Application Layer Traffic Optimization (ALTO). [ 10 ]

Redirección de la solicitud de contenido en la CDN

Para la redirección de solicitudes de usuario, en las CDN se utilizan, entre otros, dos mecanismos: principalmente la redirección HTTP y la redirección DNS.

El método HTTP utiliza la respuesta de redirección HTTP, por ejemplo, 302, que contiene una nueva URL a visitar. Además de la opción de cambiar el nombre del servidor en la nueva URL, esta puede incluir el nombre del servidor original, lo que permite la comunicación en banda. Asimismo, el mecanismo de redirección puede utilizar la información de la dirección IP del cliente, el tipo de contenido solicitado o el agente de usuario para seleccionar el servidor sustituto. Lamentablemente, el cambio del dominio de una URL impedirá que los navegadores web envíen cookies.

La redirección DNS es completamente transparente para el usuario final en comparación con el método HTTP. En la redirección DNS simple, el servidor DNS autoritativo para el nombre devuelve una dirección IP basada en las características del cliente. La dirección IP devuelta depende, entre otros factores, de la ubicación del usuario final o de la carga del servidor sustituto. Existe otro método de redirección DNS en el que el servidor autoritativo devuelve una respuesta CNAME. Esto obliga al par a reiniciar la búsqueda del nombre utilizando un nuevo nombre. Para mantener la vigencia de la redirección en caso de que las respuestas DNS estén en caché, se establece un valor adecuado para el parámetro de tiempo de vida (TTL). Una desventaja de este método es que las cachés DNS ocultan la dirección IP del usuario final.

Ambos métodos de redirección, basados ​​en HTTP y DNS, pueden implementarse en la CDNI, ya sea de forma iterativa o recursiva. La redirección recursiva es más transparente para el usuario final, ya que solo implica la redirección de un UE, pero tiene otras dependencias con respecto a la interconexión. Una única redirección de UE puede ser preferible si el número de CDN interconectadas supera las dos.

Funcionamiento ejemplar de las interfaces CDNI en la entrega de contenido.

El diagrama de secuencia que se muestra en la figura siguiente proporciona algunos detalles sobre CDNI y la operación iterativa de redirección DNS. En el ejemplo que se muestra, un UE descarga contenido de la dirección cdn.csp.com/foo , que es entregado principalmente por la CDN-A en nombre de un CSP con la dirección csp.com .

Un ejemplo de redirección DNS iterativa de una solicitud de contenido en CDNI.
Un ejemplo de redirección DNS iterativa de una solicitud de contenido en CDNI.
  1. Antes de redirigir cualquier solicitud, el CDN-B (dCDN) anuncia información sobre la infraestructura y las capacidades compatibles.
  2. El equipo de usuario realiza una consulta DNS para encontrar el servidor cdn.csp.com en el dominio del proveedor de servicios en la nube (CSP) desde el cual va a descargar el contenido.
  3. Un enrutador de solicitudes en la CDN-A (uCDN) que presta servicio al dominio cdn.csp.com procesa la solicitud y reconoce, basándose en la dirección IP de origen de la misma, que el usuario final podría recibir un mejor servicio a través de la dCDN. Por lo tanto, realiza una consulta en la dCDN para determinar si está dispuesta y capacitada para atender dicha solicitud.
  4. Si la dCDN puede gestionar la solicitud, el enrutador de solicitudes en la uCDN devuelve una respuesta DNS CNAME. Esta respuesta contiene un nuevo dominio, por ejemplo, b.cdn.csp.com , que indica la dCDN y el dominio original, así como un registro NS que asigna este nuevo dominio a un enrutador de solicitudes en la dCDN.
  5. El UE realiza una consulta DNS utilizando el nuevo dominio ( b.cdn.csp.com ). Un enrutador de solicitudes en dCDN responde a esta solicitud con la dirección IP de un nodo de entrega adecuado.
  6. El equipo de usuario (UE) solicita el contenido /foo al nodo de entrega en la dCDN. En este punto, el nodo de entrega recibe la dirección IP real del UE y la información sobre el contenido solicitado. Si las redirecciones en los pasos anteriores fueron incorrectas, el nodo de entrega podría realizar una redirección HTTP.
  7. Si los metadatos del contenido /foo no están disponibles en dCDN, se utiliza la interfaz de metadatos para solicitarlos a uCDN.
  8. Si se va a atender la solicitud, es decir, si se cumplen las restricciones de metadatos y se produce un fallo de caché, el nodo de entrega en la dCDN debe iniciar el proceso de adquisición. El nodo de entrega realiza una búsqueda DNS de la dirección de dominio interno op-b-acq.op-a.net . La uCDN reconoce que la solicitud proviene de una dCDN, en lugar de un UE, y devuelve la dirección IP de un nodo de entrega en la uCDN.
  9. El contenido /foo se entrega al nodo de entrega en dCDN desde el nodo de entrega en uCDN.
  10. El contenido /foo se entrega al UE desde el nodo de entrega en dCDN.
  11. Después de un tiempo, la uCDN puede indicarle a la dCDN que elimine el contenido /foo para asegurarse de que no se vuelva a entregar.
  12. Una vez entregado el contenido, se proporciona un registro de las acciones de entrega a la uCDN.

Transmisión adaptativa HTTP

Si se aborda en las especificaciones de CDNI, se implementa particularmente la compatibilidad con la transmisión adaptativa HTTP (HAS) [ 11 ] . Los objetos grandes se dividen en una secuencia de fragmentos pequeños e independientes, por ejemplo, videos, que se perciben como si no existiera relación entre ellos. Como resultado, la adquisición de contenido y la eliminación de fragmentos se realizan de forma individual para cada fragmento. Para reducir la carga de CDNI, las especificaciones permiten el uso de Localizadores Uniformes de Recursos (URL) relativos o modifican las URL absolutas en el archivo de manifiesto de un recurso distribuido mediante HAS.

Seguridad

La seguridad de la CDNI es opcional y su soporte se introduce como una funcionalidad de la CDN. La seguridad de la CDNI implica la protección de la confidencialidad del contenido, la comunicación entre pares autenticados y la autenticación del origen de los datos . La autenticación del origen de los datos es de suma importancia si se cuestiona la confianza en el enlace entre CDN. La seguridad se refuerza mediante el uso de versiones seguras de los protocolos implementados en la CDNI, por ejemplo, HTTPS. Generalmente, si una CDNI se establece mediante protocolos seguros, estos también se utilizan para la adquisición y distribución de contenido.

Otros problemas relacionados con la seguridad podrían ser los diversos requisitos de privacidad del usuario final en relación con los registros intercambiados entre diferentes países o la autenticidad de los registros para la facturación de entregas a través de CDN. Las consecuencias de una brecha de seguridad dependen de la interfaz y su función; por ejemplo, una interfaz de control corrupta podría corromper otras interfaces, mientras que una interfaz de registro corrupta podría permitir un fraude en la facturación.

estado de estandarización

Varias organizaciones y proyectos, como IETF, el Instituto Europeo de Normas de Telecomunicaciones (ETSI), la Alianza para Soluciones de la Industria de las Telecomunicaciones (ATIS) y Open Content Aware Networks (OCEAN), han estado trabajando o están trabajando en la estandarización de las interfaces y los métodos CDNI. Existen algunas discrepancias y diferencias entre las especificaciones de las interfaces definidas, así como en la terminología.

Las especificaciones ETSI [ 12 ] [ 13 ] describen tres interfaces CDNI. La primera, el control de interconexión, parece corresponder a la unión de las interfaces de control y registro de ETSI. La siguiente, el control de solicitud y contenido, parece corresponder a su vez a la unión de las interfaces de enrutamiento de solicitudes y metadatos de ETSI. La tercera es la interfaz de distribución de contenido.

El marco OCEAN especifica exhaustivamente las interfaces y los procesos abiertos de la CDNI propuesta. [ 14 ] [ 15 ] Los documentos definen interfaces adicionales de negocio, adquisición y metadatos internos. Además, la interfaz de metadatos definida por ETSI se divide en dos interfaces más especializadas que, en conjunto, dan como resultado el modelo de referencia con nueve interfaces.

Los estándares y los informes técnicos de ATIS, de pago, definen la especificación de casos de uso y los requisitos de alto nivel para una CDNI. Según los resúmenes disponibles gratuitamente, estas especificaciones cubren, entre otros aspectos, la interconexión de dos proveedores de CDN [ 16 ] como base para usar la multidifusión como medio para distribuir contenido entre dos proveedores de CDN [ 17 ] y para unir varios proveedores de CDN para formar una federación de CDN. [ 18 ]

Véase también

Lecturas adicionales

  • S. Puopolo, M. Latouche, F. Le Faucheur y J. Defour. Federaciones de redes de distribución de contenido (CDN): Cómo los proveedores de servicios pueden ganar la batalla por los consumidores ávidos de contenido, 2011.
  • A. Pathan y R. Buyya. Taxonomía y estudio de las redes de distribución de contenido. Informe técnico, GRIDS-TR-2007-4, Laboratorio de Computación en Red y Sistemas Distribuidos, Universidad de Melbourne, Australia, febrero de 2007.

Referencias

  1. 1 2 G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma y G. Watson. Casos de uso para la interconexión de redes de entrega de contenido. RFC 6770 (Informativo), noviembre de 2012.
  2. 1 2 L. Peterson y B. Davie. Marco para la interconexión de CDN. draft-ietf-cdni-framework-06 (Borrador activo de Internet), octubre de 2013.
  3. ↑ B. Niven-Jenkins, F. Le Faucheur y N. Bitar. Declaración del problema de la interconexión de redes de distribución de contenido (CDNI). RFC 6707 (Informativo), septiembre de 2012.
  4. ↑ F. Le Faucher, G. Bertrand, I. Oprescu y R. Peterkofsky. Interfaz de registro CDNI. draft-ietf-cdni-logging-08 (borrador activo de Internet), octubre de 2013.
  5. ↑ K. Leung y Y. Lee. Requisitos de interconexión de redes de distribución de contenido (CDNI). draft-ietf-cdni-requirements-11 (Borrador activo de Internet), octubre de 2013.
  6. ↑ R. Murray y B. Niven-Jenkins. Interfaz de control CDNI / Disparadores. draft-ietf-cdni-control-triggers-01 (Borrador activo de Internet), octubre de 2013.
  7. ↑ B. Niven-Jenkins, R. Murray, G. Watson, M. Caulfield, K. Leung y K. Ma. Metadatos de interconexión de CDN. draft-ietf-cdni-metadata-03 (Borrador activo de Internet), octubre de 2013.
  8. ↑ Danhua. Wang, B. Niven-Jenkins, Xiaoyan. He, Chen. Ge y Wei. Ni. Interfaz de redirección de enrutamiento de solicitudes para interconexión de CDN. draft-ietf-cdni-redirection-01 (Borrador activo de Internet), octubre de 2013.
  9. ↑ J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg y K. Ma. Enrutamiento de solicitudes CDNI: semántica de huella y capacidades. draft-ietf-cdni-footprint-capabilities-semantics-01 (borrador activo de Internet), octubre de 2013.
  10. ↑ E. Stephan y S. Ellouze. Sesión ALTO para la interconexión de CDN. draft-stephan-cdni-alto-session-ext-04 (Borrador activo de Internet), octubre de 2013.
  11. ↑ R. van Brandenburg, O. van Deventer, F. Le Faucheur y K. Leung. Modelos para la interconexión de redes de distribución de contenido (CDNI) con capacidad de transmisión adaptativa HTTP. RFC 6983 (Informativo), julio de 2013.
  12. ↑ Distribución de contenido multimedia (MCD); interconexión de CDN, casos de uso y requisitos. Informe técnico, ETSI, 2012. TS 102 990.
  13. ↑ Arquitectura de interconexión de CDN. Informe técnico, ETSI, 2013. TS 182 032.
  14. ↑ D3.1 Arquitectura funcional de OCEAN y especificación de interfaz abierta. Informe técnico, OCEAN, 2012.
  15. ↑ Entregable D2.2 Requisitos finales para redes abiertas con reconocimiento de contenido. Informe técnico, OCEAN, 2013.
  16. ↑ Especificación del caso de uso de interconexión CDN y requisitos de alto nivel. Informe técnico, ATIS, 2011. ATIS-0200003.
  17. ↑ Casos de uso y requisitos de interconexión de CDN para la distribución de contenido basada en multidifusión. Informe técnico, ATIS, 2012. ATIS-0200004.
  18. ↑ Casos de uso y requisitos de interconexión de CDN en un entorno de federación multipartita. Informe técnico, ATIS, 2012. ATIS-0200010.
  • Interconexión de redes de distribución de contenido (cdni)
  • OpenCDN | Federación de CDN | EdgeCast
  • SwiftServe: tecnología de almacenamiento en caché transparente y red de distribución de contenido (CDN).
  • Federación Multi-CDN | Cedexis - Datos en tiempo real para decisiones en tiempo real. Archivado el 22/09/2017 en Wayback Machine.
  • Blog sobre estrategias de CDN, noticias sobre CDN, noticias del sector de CDN, estrategias de redes de distribución de contenido. Archivado el 28/10/2013 en Wayback Machine.
  • ¿Qué es Multi-CDN y cómo funciona?