O HTTP, o protocolo da web, é baseado no TCP (Transmission Control Protocol) e é optimizado para recuperar ficheiros. Tem comandos para obter ficheiros, verificar a data e o tamanho dos ficheiros, afixar dados da web, e obter porções de ficheiros.
O HTTP não inclui, no entanto, nenhum conceito de transferência em tempo real. Em HTTP, o cliente e o servidor comunicam por turnos; nenhuma comunicação bidireccional é permitida.
O UDP (User Datagram Protocol), e não o TCP, é o protocolo de transmissão preferido para streaming em tempo real, porque não tem problemas com perdas de pacotes. O UDP pode enviar pacotes a uma taxa constante, independentemente de congestões na rede ou da capacidade da aplicação os conseguir receber. Agora é preciso considerar as características de um protocolo de streaming media construído no UDP. Esses protocolos têm que executar uma série de tarefas:
- Instalação – Fornecer os comandos reproduzir, parar, avançar rápido, rebobinar e saltar de faixas.
- Transporte – Fornecer os meios para entrega de múltiplos streams de media, detectando, possivelmente pacotes perdidos.
- Sincronização – Fornecer os meios para sincronizar diferentes streams de media numa base de tempo partilhada em tempo real e voltar a sequenciar os pacotes fora de ordem.
- Qualidade de monitorização – Fornecer meios para informar o servidor de condições como a perda de pacotes e a qualidade de leitura do cliente.
6.1. Protocolo de transporte em tempo real
A IETF (Internet Engineering Task Force) tornou padrões um conjunto de protocolos para a entrega de vídeo. O RTP (Real-time Transport Protocol) é usado entre um servidor de media e uma aplicação que lê media. O RTP fornece a transferência de dados, por exemplo, o áudio e vídeo vêm do servidor de media como duas streams diferentes no protocolo RTP. Normalmente o RTP corre em UDP, mas também pode correr em TCP, e pode até correr sobre outros sistemas de transportes. Toma conta do sincronismo do pacote; não assegura realmente a entrega em tempo real, mas envolve diferentes frames de áudio e vídeo com informação de sincronização suficiente para que possam ser sincronizados em tempo real na recepção final. O RTP é também a maneira estandardizada para entregar media por UDP em redes multicast.
Outro protocolo na especificação RTP, o RTCP (Real-Time Control Protocol) permite, em conjunto com o RTP, fornecer um canal de controlo que é útil para monitorização de qualidade. Os servidores enviam pacotes RTCP periodicamente para que o servidor saiba a qualidade do stream que recebe. O servidor pode baixar a qualidade do stream, se necessário.
Em finais de 1996, o RTSP (Real-Time Streaming Protocol) fornecia características de instalação para entrega de vídeo. O RTSP fornece, essencialmente, os controlos de um gravador de videocassetes, a um servidor de streaming media. O protocolo é modelado, de certa forma, pelo HTTP, porque pretendia-se que fosse tão bom para a streaming media como o HTTP tinha sido para as páginas de Internet. O RTSP pode trabalhar em conjunto com o RTP; o RTSP instala a ligação e o RTP é usado para entregar os dados. Tanto a RealNetworks como a Netscape trabalharam na especificação deste protocolo. A RealNetworks mudou para o RTSP pela sua instalação de transporte, desaprovando os seus protocolos de transporte anteriores, PNM (Progressive Networks Media) e PNA (Progressive Networks Audio).
6.2. Protocolo de servidor de media
No final da década de 1990, a Microsoft criou o seu próprio conjunto de protocolos para entrega de media. Apesar de já terem usado o RTP na sua aplicação de conferência NetMeeting, a Microsoft não tinha implementado o RTSP em nenhum produto.
A Microsoft criou o MMS (Multimédia Server Protocol) que integra a maioria das características do RTP, RTCP e RTSP, mas removeram algumas características fúteis do RTP. Para alcançar a maior audiência possível, projectou o seu protocolo com várias versões diferentes, cada uma sobre um tipo de rede mais restritiva.
Recair sobre protocolos menos restritivos até que o áudio ou o vídeo comecem a funcionar é uma abordagem comum.
O protocolo MMS fornece a instalação, o transporte, a sincronização e monitorização de qualidade, e tem capacidades adicionais para transmitir informação DRM (digital rights management ) e pedir licenças do servidor.
6.3. Streaming através de Firewalls
O RTP e o RTSP são protocolos padrão de Internet de uso generalizado para o transporte de vídeo em tempo real. São normalmente executados em cima do UDP. No entanto, por muitas razões diferentes, o UDP não é sempre uma opção de transporte disponível. Uma das principais razões é que muitas firewalls de empresas são concebidas para o bloquear, no pressuposto que permiti-lo iria promover a inundação da rede com media que utiliza muita largura de banda. De um modo geral, o UDP é compreensivelmente associado a aplicações de Internet que usam intensivamente largura de banda, como a telefonia pela Internet, streaming audio, streaming video e videojogos. Compreensivelmente, as empresas que tentam prevenir pesquisas na Internet não relacionadas com o trabalho, consideram ser mais simples bloquear todo o tráfego UDP na firewall e tornar internos quaisquer serviços (como o DNS) que dependam dele.
No final da década de 1990, todos os principais fornecedores tinham sistemas que funcionavam sobre UDP e que podiam funcionar (com desempenho inferior) sobre TCP. As empresas começavam a restringir as suas redes de tal maneira que até mesmo o TCP de uso geral não era permitido; apenas o tráfego TCP no porto 80 (o porto normal para o tráfego da web). Proxy firewalls mais restritivas, muitas vezes nem permitem o uso de TCP, apenas tráfego HTTP é permitido.
Figura 6.3.1 – RTSP/RTP passa através da firewall incluído no HTTP
Seria este o fim da streaming media? Óbvio que não, mas qual era a solução? Introduzir um novo conceito em todas estas camadas: Protocol encapsulation.
O HTTP é um protocolo de pedido de resposta; o cliente pede e o servidor responde enviando o ficheiro pedido. Isto certamente não é um protocolo concebido para estar ligado durante horas, mas o HTTP tem uma característica onde a mesma ligação HTTP pode ser mantida aberta e usada. Isto foi concebido para cenários em que o utilizador recebe múltiplos ficheiros do mesmo website.
6.4. Opressão de protocolos empresariais
Em reposta a este mundo só com HTTP, criado por gestores de empresas de tecnologias de informação, os programadores conseguiram arranjar uma maneira de distribuir vídeo pela Internet nessas redes. Uma técnica de protocolos de transporte por tunneling dentro do HTTP foi desenvolvida. Com tunneling, todos os pacotes normais que seriam enviados via UDP são construídos como seriam normalmente, mas depois são enviados em ligações HTTP.
Essencialmente o servidor de media pretende enviar grandes páginas web, de modo a enganar a firewall empresarial para deixar passar o vídeo.
Parece e é bastante ineficiente. No entanto a marcha da força bruta do progresso, aumenta constantemente a largura de banda e a conectividade do mundo, a velocidade dos routers na Internet, etc… Se não houver perdas de pacotes e se a largura de banda entre o servidor e o cliente for suficiente, o vídeo funciona.