El término HTTP Streaming ha sido desde sus inicios objeto de numerosas críticas (algunas constructivas y otras tantas destructivas) desde los diferentes ángulos y por los diferentes actores en las redes de distribución de contenidos nacionales e internacionales.

Y es que desde la mirada más purista, el Streaming vía HTTP no es realmente Streaming del todo (o eso solían decir), pues adolece de una condición fundamental que muchos han aprovechado para objetar y detractar ciertas ventajas que de por si este sistema tiene.

1.- La historia de “La Persistencia”
Hasta la aparición de los primeros sistemas de Distribución Adaptativa, virtualmente todos los proveedores de servicios de radios online, TV en línea y video bajo demanda consideraban que hacer Streaming “Real” solo podía ocurrir bajo protocolos que establecían una contacto 100% permanente con el usuario, ergo, si la conexión caía o había fallos en la red producto de bajas en el suministro (o quizá simplemente porque alguien más en tu casa estaba descargando un torrent) la consecuencia era siempre un mensaje de “Buffer” junto con la correspondiente espera hasta que el sistema volviera a llenar el mismo

En este sentido las conexiones unicast de Windows Media Services representan un clásico y buen ejemplo de dicha persistencia…

Luego de algunos años y la aparición de protocolos propietarios como RTMP de ADOBE este concepto fue reforzado con un intenso sentido técnico en el marketing que intentaba diferenciar ambos sistemas de distribución sobre la base de “cómo se recibía” el Stream de datos por el usuario final y las ventajas que suponía la compleja secuencia de “piratear” los contenidos de audio/video ya que ellos se visualizaban en tiempo de ejecución y no había un caché de los mismos en el PC del receptor.

Sin desmedro de lo anterior muchos proveedores de Streaming malinterpretaron este sentido y despreciaron la venta del producto “no persistente” imputando a la distribución HTTP el nombre de “falso streaming” o en el mejor de los casos “pseudo streaming” con un discurso que tenía en su fondo, más que ver con la rentabilización de las inversiones en infraestructura de servidores/licencias ya realizadas por ellos, pues claramente era una pérdida de capital el darse cuenta que un simple y económico servidor web podía realizar “la pega” de llevar MUY BUEN video a los usuarios finales, quienes no protestarían por una diferencia funcionalmente insignificante para ellos (desde su punto de vista) ya que todos estábamos acostumbrados a pausar Youtube hasta que se terminara de cargar pues suponía una deficiencia atribuible a la red y nunca a quien proveía el video.

2.- La aplicación
Todos aquellos quienes trabajamos profesionalmente en tecnología sabemos que existe una cierta reserva de los usuarios mas “geek” (y quizá tengamos que incluirnos también) cuando Microsoft hace aparición en el mercado, especialmente con un nuevo producto como fue el caso de Silverlight, el cual tenía por destino quitarle protagonismo a Flash en el marcado RIA.

Habrá quienes digan que es por el monopolio, o porque simplemente “Bill” ya tiene demasiados millones de dólares en su cuenta, pero en verdad hay que conceder a MS el crédito que corresponde en la adopción, o quizá debería llamar a esto “el perfeccionamiento y puesta en escena” de una tecnología lógica, basada en el más auténtico sentido con la que está construida la red HOY, es decir, bajo una infraestructura mucho más amigable para hacer Streaming con HTTP híbrido de lo que todos creíamos.
En este instante ya TODOS los desarrolladores de aplicaciones de Streaming están trabajando en soluciones que permiten realizar verdadera distribución dinámica HTTP, algunos lo han tomado con bastante más reticencia y se han apegado tanto como les ha sido posible a sus viejos estandartes como veremos a continuación.

3.- Y que pasa con Flash Streaming HTTP?
Cuando alguien se refiere a Flash HTTP realmente está hablando de un sistema bastante particular donde el protocolo RTMP realmente se “disfraza” de HTTP con una técnica conocida como tunelización. Esta técnica funciona tanto para contenido en vivo y “on demand” motivo por el cual puede sufrir de un leve “delay” y abultamiento en su estructura de datos, cosa no siempre aceptable, especialmente cuando entre el servidor y el cliente existen redes proxeadas ó protegidas con firewalls donde hay analizadores de paquetes.

Según lo anterior, el protocolo de Flash Streaming está diseñado para realizar su distribución bajo TCP en vez del clásico UDP de la conectividad con protocolo RTSP.

Esta debilidad fue muy bien entendida por grupos internacionales como AKAMAI o Nokeena (Ahora Ankeena/Juniper) quienes se sustentaron de manera independiente en la misma API de Flash para realizar antes que nadie sus adaptaciones de streaming HTTP “real” y generar soluciones productivas en el patio trasero del mismo ADOBE.

El motivo es bastante simple y tiene que ver con la escala…
Y es que cualquiera que haya realizado los benchmarks correspondientes (nosotros los hicimos todos) sabrá que distribuir streaming Flash bajo RTMP requiere de una cantidad de hardware y potencia de procesamiento que crece en forma directamente proporcional a la cantidad de usuarios conectados (nada inteligente) y además necesita que cada servidor tenga instalada la serie completa de licencias de software con un costo poco despreciable en su conjunto.

Esto ha puesto a la casa ADOBE en una incómoda situación donde al final del día terminará ofreciendo un producto Flash 10.1 y Flash Media Server 4 que atentará directamente contra todo su esfuerzo en el método distributivo original y generará un nuevo espacio que requerirá de un sistema de protección de contenidos DRM Flash Access, necesario para limitar la desventaja que representa la entrega literal del contenido fuente al usuario final (lo cual no es chiste para los estudios y los dueños de los derechos).

Epíologo:
Sin duda período 2010-2011 será de grandes cambios en la forma en que veamos la entrega de audio y video en la red. Empresas como ADOBE han mostrado cierta resilencia a lo que viene pero será solo cuestión de tiempo para ver la adopción de estas nuevas tecnologías.

También veremos movimientos interesantes en los ISP así como en las CDN, proveedores de Streaming y productores de contenidos, quienes asumirán una carga no menor al tener que arreglárselas para encodear una cantidad considerable de material de manera técnicamente transversal, veloz y que no deberá implicar mayores costos junto con las tecnologías de protección DRM necesarias, quienes finalmente son los verdaderos ganadores de esta pequeña batalla entre dos hermanos algo distanciados por asuntos de “protocolos de familia”.