Las redes de entrega de contenido desempeñan un papel fundamental en la difusión de vídeo y, más precisamente, en la securización de la propia transmisión. En los últimos años hemos tenido la oportunidad de trabajar mucho este punto mediante el uso de tokens junto a uno de nuestros clientes. En el post de hoy os cuento lo que hemos logrado juntos.
A diferencia de otros recursos susceptibles de ser suministrados por una CDN, los vídeos presentan una característica diferenciadora: pesan, pesan mucho. De acuerdo con nuestra monitorización de tráfico en tiempo real, más del 30% del tráfico entregado diariamente por nuestra CDN corresponde a recursos de vídeo a pesar de ser estos solo un 1% del total de peticiones o requests.
Sirva este dato simplemente para ilustrar el peso del que hablo porque influye de forma directa en el ancho de banda y en el coste que supone el tráfico saliente o egress. Dimensionar correctamente estas dos variables es imprescindible para garantizar la calidad del servicio (disponibilidad, tiempo de respuesta, baja latencia, etc.) y la experiencia de usuario.
En Transparent Edge – y con permiso de Julio César– seguimos un enfoque dívide et ímpera. Esta aproximación nos invita a dividir un problema complejo en subproblemas de naturaleza equivalente aunque más sencilla y, en consecuencia, abarcables con mayor facilidad. Así pues, realizamos la transmisión de manera escalonada y progresiva, en pequeños fragmentos más livianos que reciben el nombre de chunks.
Pasamos de tener un único recurso, un vídeo de cierta duración, a tener una multitud de pequeños recursos. Para determinar el orden en el que se reproducen estos chunks, utilizamos un índice. A estos índices los llamamos manifiestos o manifests.
En caso de un vídeo bajo demanda, su manifiesto podría ser el índice de todos los chunks que constituyen dicho vídeo, de principio a fin; por el contrario, ante una emisión en directo, este manifiesto se irá refrescando paulatinamente a medida que avanza la emisión.
En términos de políticas de caché, en el primer caso podríamos fijar tiempos relativamente altos de persistencia, por ejemplo, con un ‘max-age‘ de una semana en la cabecera ‘Cache-Control‘. Sin embargo, en el segundo, la política de caché debería ser radicalmente distinta: con una persistencia mínima, de unos pocos segundos, dependiendo de la duración de estos chunks.
Podemos imaginar un token como una especie de firma dinámica que genera la aplicación desde la que el usuario reproduce el contenido y que es verificada por el origen del cliente. Decimos que es dinámica porque se va actualizando a medida que avanza la reproducción, siendo válida tan sólo durante cierto periodo de tiempo.
Para generar un token necesitamos ciertas variables: la dirección IP del usuario, el inicio y fin del periodo de validez del token, una clave secreta, etc. Las variables concretas dependen en cada caso de las necesidades particulares de cada cliente.
En cualquier caso, estas variables se concatenan de una determinada forma (ej. [<IP address>][<valid from>][<valid until>][<secret key>]) y se les aplica una función criptográfica o hash. Esta función convertirá la cadena de entrada en una secuencia ininteligible de caracteres, como si el gato de Schrödinger hubiese podido escapar de su caja y, enfurecido (y zombi, quizá), se hubiera puesto a pegar saltos sobre el teclado del ordenador.
El hash resultante, junto con las variables públicas (la dirección IP del usuario y el inicio y fin del periodo de validez del token), nos permitirá componer el token en sí, que será remitido al origen (backend) del cliente, por ejemplo: <IP address>-<hash>-<valid from>-<valid until>.
La petición recibida por el origen recogerá este token y extraerá los distintos campos que lo conforman. Tomará las variables y, junto con la clave secreta, repetirá los mismos pasos ejecutados con anterioridad del lado del usuario y comparará los hashes resultantes. Para que el token recibido sea válido, necesariamente ambos deberán coincidir.
En este punto, nos podemos encontrar distintos escenarios:
El uso de token afecta irremediablemente a la clave de caché. Cada petición será distinta de todas las demás, aunque hagan referencia al mismo recurso o asset (chunk o manifest), desplomando el hit ratio y la eficiencia de la propia caché.
Para afrontar este problema podemos seguir dos estrategias:
La principal ventaja que aporta el enfoque elegido es, no ya sólo garantizar una adecuada eficiencia de caché, sino también liberar al origen (backend) del cliente de toda la computación que requiere validar uno tras otro los distintos tokens remitidos en las peticiones subyacentes. Además, ejecutar estos cálculos en el edge favorece la experiencia de usuario gracias a la red de nodos distribuida estratégicamente por el mundo.
En el caso que abordamos en este post hemos trabajado junto a nuestro cliente durante los últimos años, es un honor seguir caminando a su lado y adaptando nuestras funcionalidades a las necesidades particulares de cada proyecto.
Como recitaba Antonio Machado, «Caminante, son tus huellas el camino y nada más; caminante, no hay camino, se hace camino al andar».
Seguimos caminando.
Alberto Suárez López es administrador de sistemas en Transparent Edge.
Más asturiano que la sidra, Alberto estudió Ingeniería Técnica en Informática de Gestión y un Posgrado en Ingeniería Web en la Universidad de Oviedo. Desde entonces, se ha enfrentado con todos los tipos de infraestructura UNIX posibles y ha doblegado a todos gracias a sus vastos conocimientos que hacen de él un todoterreno ante cualquier problema técnico.
Compartir:
