This paper was presented at SET 2008 Conference, and discuss technologies available to delivery content over the Internet

1. Arquiteturas de Distribuição de Vídeos na Internet
Marcello de Lima Azambuja Rafael Silva Pereira
Globo.com Globo.com
Rio de Janeiro, RJ Brasil Rio de Janeiro, RJ Brasil
azambuja@corp.globo.com rafael.pereira@corp.globo.com
ABSTRACT Keywords
Apesar de parecer algo simples, a escolha correta de uma ar- Arquitetura, Distribui¸˜o de V´
ca ıdeo, Internet TV, V´
ıdeo na
quitetura de distribui¸˜o de v´
ca ıdeos ´ t˜o fundamental para
e a Internet
um servi¸o na internet, quanto a defini¸˜o dos parˆmetros
c ca a
de codifica¸˜o de um determinado algoritmo de compress˜o,
ca a
isto porque ela tamb´m pode impactar de forma decisiva na
e
1. INTRODUÇÃO
qualidade da experiˆncia do usu´rio. A distribui¸˜o de v´
e a ca ıdeo A distribui¸˜o de v´
ca ıdeos na internet n˜o ´ um processo
a e
em uma rede ’Best Effort’, a varia¸˜o estat´
ca ıstica de retardo, novo, por´m vem se popularizando bastante nos ultimos
e ´
assim como outras adversidades do meio, criam desafios para anos, principalmente devido ao aumento da disponibilidade
que o usu´rio tenha uma experiˆncia cont´
a e ınua – demora para de banda dos usu´rios. Sites dedicados ` distribui¸˜o de
a a ca
carregar, travamentos constantes, etc. Desta forma, para v´
ıdeos, como o YouTube, que hoje ´ o terceiro portal mais
e
projetar uma arquitetura de distribui¸˜o de v´
ca ıdeos devemos acessado no mundo, ajudam a impulsionar o mercado de
levar uma s´rie de fatores em considera¸˜o, como a largura
e ca v´
ıdeo na internet, e criam oportunidades para que novos
de banda m´dia necess´ria para a distribui¸˜o dos v´
e a ca ıdeos, servi¸os sejam desenvolvidos, visando atender a crescente
c
a disponibilidade de banda dos usu´rios, a audiˆncia esper-
a e demanda dos usu´rios.
a
ada, etc. Baseado nessas caracter´ ısticas, ´ poss´ escolher
e ıvel Entretanto, criar um servi¸o de distribui¸˜o de v´
c ca ıdeos que
uma distribui¸˜o via streaming, download progressivo, Peer-
ca seja robusto o suficiente para atender toda a demanda, e
2-Peer, entre outras. que seja est´vel e escal´vel, n˜o ´ uma tarefa simples. Exis-
a a a e
Assim, nosso objetivo ´ analisar quais fatores mais influen-
e tem hoje diversas tecnologias e arquiteturas de distribui¸˜o, ca
ciam na escolha de uma arquitetura de distribui¸˜o de v´
ca ıdeos que permitem uma s´rie de diferentes abordagens, de modo
e
para internet, e, baseado numa combina¸˜o de fatores, qual ´
ca e que uma escolha inadequada pode comprometer seriamente
a melhor escolha. Iremos analisar arquiteturas de streaming a qualidade do servi¸o, se houver uma m´
c ınima mudan¸a dec
(Windows Media Services e Flash Media Server), de down- cen´rio, como o aumento inesperado da demanda, por ex-
a
load progressivo e redes P2P, verificando as particularidades emplo.
de cada uma, e avaliando como estruturar um ambiente para Assim, devemos analisar cuidadosamente quais s˜o as car-
a
uma distribui¸˜o mais eficiente, ou seja, com mais usu´rios
ca a acter´ısticas relacionadas ao processo de distribui¸˜o, ou seja,
ca
por servidor. qual ´ a audiˆncia esperada, qual ´ o perfil de acesso dos
e e e
usu´rios, quais as caracter´
a ısticas do meio f´
ısico utilizado
para o acesso, quais s˜o os requisitos de qualidade do servi¸o,
a c
etc. S´ assim, teremos informa¸˜es suficientes para definir
o co
Categories and Subject Descriptors qual ´ a estrutura e tecnologia que mais se adequa `s neces-
e a
C.2 [Computer Systems Organization]: Computer Com- sidades do neg´cio.
o
munication Networks; H.4.3 [Information Systems]: In- A seguir, iremos ver quais s˜o as tecnologias existentes,
a
formation Systems Applications quais s˜o suas caracter´
a ısticas, e como podemos utiliz´-las
a
para distribuir v´ ıdeos na internet.
General Terms 2. STREAMING
Design, Performance Nesse artigo utilizamos o termo ’Streaming’ nos referindo
a streaming de v´ ıdeo. Isto ´, tecnologia para envio de infor-
e
ma¸˜es multi-m´
co ıdia na Internet atrav´s de pacotes IP. Em
e
geral com um protocolo de controle de sess˜o (ex.: RTP)
a
controlando a transmiss˜o dos dados e de forma que ap´s a
a o
reprodu¸˜o os dados n˜o sejam armazenados na m´quina do
ca a a
cliente.
2.1 Windows Media Services
Um dos principais servidores de streaming do mercado ´
e
o Windows Media Services, solu¸˜o da Microsoft que ainda
ca

2. ´ a mais usada para transmiss˜o ao vivo. Descreveremos a
e a stream ´ reproduzido pelo Windows Media Player na taxa
e
seguir algumas caracter´ısticas importantes na solu¸˜o Win-
ca especificada pelo formato do stream, mas o cliente passa a
dows Media que o tornam interessantes para distribui¸˜o de
ca ter um buffer bem maior antes da reprodu¸˜o. Isso permite
ca
m´ıdia ao vivo na Internet. que o cliente seja mais robusto a varia¸˜es na condi¸˜o da
co ca
Como principais pontos podemos citar: rede de transmiss˜o sem um impacto percept´
a ıvel na qual-
idade da reprodu¸˜o do conte´do, principalmente no on-
ca u
• Intelligent Streaming demand.
O Fast Start usa um conceito parecido ao Fast Cache, de
• Fast Streaming (Fast Cache, Fast Start, etc.) transmitir os dados numa taxa maior que a especificada no
• Server-side Playlist formato do stream para que o in´ da reprodu¸˜o seja acel-
ıcio ca
erada. A id´ia ´ reduzir ao m´ximo o intervalo entre o tempo
e e a
2.1.1 Intelligent Streaming em que o bot˜o de play ´ pressionado e o efetivo in´
a e ıcio da
reprodu¸˜o. Isso tamb´m acelera o processo de fast-forward
ca e
Intelligent streaming ´ um conjunto de funcionalidades do
e
ou rewind na reprodu¸˜o do v´
ca ıdeo sem um atraso adicional
Microsoft Windows Media Services que detecta automatica-
ou re-buffering. Um ponto de aten¸˜o ´ para o caso de v´rios
ca e a
mente as condi¸˜es de rede e ajusta as propriedades de um
co
clientes simultaneamente requisitarem a reprodu¸˜o de umca
fluxo de stream para maximizar a qualidade da experiˆncia e
v´
ıdeo, caso comum em transmiss˜es ao vivo de grande escala
o
do usu´rio. Com a varia¸˜o estat´
a ca ıstica de retardo sendo uma
quando o link passa a ser disponibilizado numa p´gina com
a
caracter´ ıstica comum na maioria das conex˜es da Internet,
o
acesso elevado (ex.: p´gina inicial da globo.com). Nesse caso
a
al´m do fato do mercado de banda larga oferecer uma ampla
e
o aumento da utiliza¸˜o de banda ser´ enorme sendo acon-
ca a
variedade de largura de banda, o Intelligent streaming passa
selh´vel limitar a utiliza¸˜o de banda que o Fast Start pode
a ca
a ser uma caracter´ ıstica de grande relevˆncia. Por exemplo,
a
utilizar pela administra¸˜o do Windows Media Services.
ca
um usu´rio com um laptop pode conectar-se a um prove-
a
O Fast Recovery faz uso de um algoritmo de forward er-
dor de conte´do com uma conex˜o de 600kbps ADSL em
u a
ror correction (FEC) em um publishing point do Windows
casa, uma conex˜o de 10Mbps no trabalho ou um modem
a
Media Services para recupera¸˜o em caso de recebimento de
ca
de 56kbps enquanto viaja a neg´cios. o
pacotes danificados ou perdidos.
No sistema Windows Media, o servidor Windows Media
O Fast Reconnect permite a re-conex˜o autom´tica no
a a
e o cliente (normalmente o Windows Media Player) se co-
caso de uma falha tempor´ria de rede. No caso de uma
a
municam a fim de identificar a largura de banda dispon´ ıvel
reprodu¸˜o de v´
ca ıdeo on-demand a reprodu¸˜o ´ iniciada do
ca e
realizando um s´rie de medi¸˜es e ajustes de forma a max-
e co
ponto de onde parou automaticamente.
imizar a qualidade do stream para que n˜o haja esvazia-
a
O Advanced Fast Start estende a funcionalidade do Fast
mento do buffer (interrompendo a reprodu¸˜o da m´ ca ıdia).
Start permitindo que o Windows Media Player inicie a re-
No caso de conex˜es mais lentas (dial-up) o usu´rio tem
o a
produ¸˜o mesmo antes do buffer estar completamente cheio,
ca
uma degrada¸˜o de qualidade em prol da reprodu¸˜o con-
ca ca
apenas com um valor m´ ınimo presente. O objetivo nova-
t´
ınua, em contra partida, numa conex˜o com maior largura
a
mente ´ minimizar o intervalo entre a intera¸˜o do usu´rio
e ca a
de banda a qualidade pode ser oferecida com a maior uti-
e a reprodu¸˜o do v´
ca ıdeo.
liza¸˜o de recursos de rede.
ca
Para que o Intelligent Streaming seja usado, ´ preciso no
e
entanto, que os servidores de codifica¸˜o (Windows Media
ca
2.1.3 Server-side Playlist
Encoder) estejam configurados para gerar mais de um perfil As Server-side Playlists s˜o listas de reprodu¸˜o config-
a ca
de codifica¸˜o (profiles de encoding). Esse tipo de stream ´
ca e uradas no lado do servidor de maneira transparente para
chamado de Multiple Bit Rate (MBR). Para cada novo perfil o cliente Windows Media Player. Elas podem ser usadas
acrescentado uma nova carga de processamento equivalente para dois objetivos b´sicos: controle de falhas (fail-over) e
a
ser´ aplicada no servidor.
a inser¸˜o de propaganda (Ad Insertion).
ca
Um problema no algoritmo usado para detec¸˜o da largura
ca Uma playlist contendo duas referˆncias para Windows Me-
e
de banda dispon´ ´ sempre considerar o Maximum Trans-
ıvel e dia Encoders, com o mesmo sinal, pode ser usada para o caso
mission Unit como 1500 bytes (Ethernet). O que n˜o ´ cor- a e de uma falha em um deles. Dessa forma automaticamente os
reto para o caso de conex˜es ADSL que fazem uso de PPPoE,
o servidores iriam conectar no segundo servidor sem nenhuma
que adicionam um overhead reduzindo o MTU para 1492 interven¸˜o humana.
ca
bytes, gerando uma fragmenta¸˜o dos pacotes que possivel-
ca Essas playlists podem ser usadas tamb´m para a inser¸˜o
e ca
mente contabiliza erroneamente a largura de banda dispon´ ıvel. de propaganda antes, entre ou depois da reprodu¸˜o de m´
ca ı-
Um parˆmetro pode ser utilizado no Windows Media En-
a dias. A gera¸˜o da playlist pode inclusive ser feita por um
ca
coder para amenizar esse problema. programa externo com uma l´gica de neg´cios mais elabo-
o o
rada para controlar a inser¸˜o de propaganda.
ca
2.1.2 Fast Streaming
A tecnologia Fast Streaming refere-se a um grupo de fun- 2.2 Flash Media Server
cionalidades inclu´
ıdas no Windows Media Services para mel- Uma solu¸˜o de distribui¸˜o de conte´do em Flash V´
ca ca u ıdeo,
horar a qualidade da experiˆncia do usu´rio: Fast Cache,
e a On Demand e Ao Vivo, deve levar em considera¸˜o uma s´rie
ca e
Fast Start, Fast Recovery, Fast Reconnect e Advanced Fast de caracter´ısticas que devem ser atendidas visando garan-
Start. tir ao usu´rio uma experiˆncia satisfat´ria e de qualidade.
a e o
O Fast Cache possibilita o envio dos dados a uma taxa Basicamente, devemos nos preocupar em montar uma infra-
maior do que a especificada no formato do stream. Por ex- estrutura tolerante a falhas, escal´vel e que se adapte da
a
emplo, um servidor Windows Media poderia enviar para o melhor forma poss´ ıvel `s solu¸˜es j´ utilizadas em outros
a co a
cliente um stream de 128kbps a uma taxa de 700kbps. O sistemas que por ventura tenham que ser integrados ` nova
a

3. Figure 2: Splitting de Sinal no FMS
tante redundante do ponto de vista dos Edge Servers, que, se
estiverem diretamente ligados em um balanceador de carga,
podem ser facilmente retirados de servi¸o caso apresentem
c
algum problema, de modo que os clientes ser˜o atendidosa
Figure 1: Escalabilidade com Flash Media Server pelos outros servidores dispon´ ıveis.
Entretanto, para a camada de Origin Servers temos uma
situa¸˜o cr´
ca ıtica. Por ser o CORE de toda infra-estrutura,
solu¸˜o. Al´m disso, esta estrutura deve ser facilmente geren-
ca e uma vez que todas as aplica¸˜es est˜o mapeadas nele, sua
co a
ci´vel, ou seja, devemos ter um ponto centralizado de ad-
a indisponibilidade causaria a queda de toda a estrutura de
ministra¸˜o, onde seja poss´ alterar configura¸˜es de toda
ca ıvel co distribui¸˜o. A indisponibilidade de um Origin Server sig-
ca
estrutura, al´m de possuir informa¸˜es de todos os pontos.
e co nifica a queda imediata e interrup¸˜o de streaming para
ca
O Flash Media Server ´ o servidor de streaming da Adobe
e todos os clientes, sem exce¸˜o, mesmo que tenhamos um
ca
que procura endere¸ar todas essas necessidades, permitindo
c balanceador entre o Origin e os Edges e um servidor em
a cria¸˜o de uma arquitetura facilmente escal´vel e geren-
ca a Origin como backup. Existem alternativas para contornar
ci´vel.
a este tipo de problema, que seria implementar no player uma
O Flash Media Server oferece uma solu¸˜o bastante in-
ca funcionalidade para reconex˜o autom´tica caso o streaming
a a
teressante no que diz respeito a escalabilidade e distribui¸˜o ca seja interrompido por queda na conex˜o. Esta ´ uma solu¸˜o
a e ca
de carga, o que recebe o nome de Arquitetura Origin/Edge que minimizaria o problema de queda do Origin Server, e,
Servers. Esta arquitetura introduz o conceito de execu¸˜o ca dadas todas as demais caracter´ ısticas positivas, est´ con-
a
remota de aplica¸˜es, de modo que a aplica¸˜o est´ ”hospedada”
co ca a tinua sendo uma solu¸˜o bastante robusta.
ca
em um servidor, mas pode ser executada em outro. Basica- A redundˆncia dos encoders tamb´m ´ parte fundamen-
a e e
mente, a id´ia consiste em criar um ”cluster” de m´quinas
e a tal para a confiabilidade de transmiss˜es ao vivo. Basi-
o
de front-end respons´veis por atender e executar as requi-
a camente, deveremos ter 2 encoders para cada transmiss˜o a
si¸˜es dos usu´rio, e centralizar toda a administra¸˜o das
co a ca ao vivo, sendo um Master e outro Backup. Diferentemente
aplica¸˜es em um unico servidor. Desta forma, aliamos a
co ´ da arquitetura de Windows Media, os encoders publicam o
centraliza¸˜o da administra¸˜o com alta uma capacidade de
ca ca streaming codificado no servidor, e n˜o o servidor vai at´ o
a e
processamento de requisi¸˜es, de modo que a medida que au-
co encoder. Desta forma, fica inviabilizada a utiliza¸˜o de bal-
ca
menta a necessidade de atendimento de requisi¸˜es, podemos
co aceadores para realiza¸˜o de failover. Assim, o chaveamento
ca
aumentar a quantidade de Edge Servers. dos sinais em caso de falha fica sob responsabilidade de um
Uma caracter´ ıstica bastante importante dos Edge Servers script no Origin Server.
´ o caching de conte´do On Demand, em mem´ria e em
e u o Para que ocorra o chaveamento entre os sinais, ambos en-
disco, que reduz a carga sobre o Origin Server. Basicamente, coders devem publicar seus streams no Origin Server durante
quando um cliente solicita ao Edge Server o streaming de um toda a transmiss˜o. O encoder Master dever´ publicar seu
a a
determinado conte´do, ele procura se existe alguma vers˜o
u a stream com um nome e o Backup com outro, sendo que os
v´lida deste conte´do em seu cache. Caso exista, ele ini-
a u clientes (Edge Servers) dever˜o se conectar em um terceiro
a
cia a distribui¸˜o do conte´do. Caso n˜o exista, ele ir´ ao
ca u a a stream. Neste caso, o script que roda no servidor ir´ mapeara
Origin Server busc´-lo. Outra caracter´
a ıstica excepcional da a entrada do master para a sa´ em que os Edge Servers es-
ıda
arquitetura de Origin/Edge Servers ´ a realiza¸˜o de split-
e ca t˜o conectados. Em caso de falha, a conex˜o entre o encoder
a a
ting de conte´do ao vivo realizado pelo Origin Server. Basi-
u Master e o Origin Server ser´ perdida, gerando um evento
a
camente, o Origin Server recebe o sinal codificado em FLV de Disconnect no Origin Server. Ao identificar este evento
do conte´do ao vivo e distribui para os Edge Servers onde
u o Origin Server automaticamente remapeia a entrada apon-
existem clientes conectados solicitando streaming deste con- tando para o backup. Esta arquitetura ´ bastante robusta e
e
te´do. A caracter´
u ıstica fundamental disto ´ que, supondo
e tolerante a falhas, de modo que, caso seja necess´rio chavear
a
que temos um v´ ıdeo sendo codificado e publicado no Origin para o back-up, nenhum cliente ´ desconectado. Al´m disso,
e e
Server com taxa de 1Mbps, teremos uma taxa de transmis- caso seja necess´rio reiniciar um encoder, sem chavear, ainda
a
s˜o deste v´
a ıdeo para os Edge Server de 1Mbps, independente assim os clientes n˜o ser˜o derrubados.
a a
da quantidade de clientes no Edge Server. (Figure 2) Do ponto de vista do usu´rio, o Flash Media Server possui
a
Um outro ponto importante quando estamos projetando algumas desvantagens quando comparado com a distribui¸˜o ca
uma arquitetura de distribui¸˜o de v´ca ıdeos trata-se de elimi- via Windows Media Services, j´ que ele n˜o implementa o
a a
nar um poss´ ponto unico de falha. No caso da arquitetura
ıvel ´ Intelligent Streaming nem o Fast Cache/Fast Start. Apesar
Origin/Edge do Flash Media Server, temos uma solu¸˜o bas- ca de n˜o ter estas funcionalidades build-in, ´ poss´
a e ıvel imple-

4. mentar solu¸˜es semelhantes atrav´s do desenvolvimento de
co e dor Apache rodando em um sistema operacional Linux, n˜o a
aplica¸˜es client e server side, capazes de realizar detec¸˜o
co ca ´ necess´rio nenhum investimento em licenciamento de soft-
e a
de banda e gerenciamento dinˆmico de buffer.
a ware, sendo que todo o custo de uma estrutura b´sica fica
a
restrito ao hardware.
3. DOWNLOAD PROGRESSIVO Baseado neste cen´rio, seria bastante desej´vel que este
a a
componente b´sico fosse capaz de servir a maior quantidade
a
Uma das alternativas ` utiliza¸˜o do streaming como ar-
a ca
poss´ de usu´rios, uma vez que, desta forma, reduzir´
ıvel a ıamos
quitetura de distribui¸˜o ´ conhecida como Download Pro-
ca e
a quantidade de hardware necess´rio, reduzindo ainda mais
a
gressivo, onde os arquivos de ´udio e v´ a ıdeo s˜o distribu´
a ı-
os custos da montagem da estrutura de distribui¸˜o. Para
ca
dos atrav´s de downloads para os usu´rios. Na verdade, o
e a
aumentar a performance de um sistema, devemos primeira-
pr´prio nome j´ define bem o funcionamento deste processo:
o a
mente analisar seus componentes e como eles se relacionam,
Download, referente ao processo de c´pia de um arquivo via
o
para ent˜o identificarmos os pontos cr´
a ıticos que devem ser
HTTP para um computador ` partir de um servidor web;
a
otimizados.
Progressivo, referente ` possibilidade de iniciar a reprodu¸˜o
a ca
No caso de distribui¸˜o de v´
ca ıdeos via Progressive Down-
do conte´do antes que a c´pia completa seja finalizada. As-
u o
load temos algumas caracter´ ısticas b´sicas que devem ser
a
sim, a unica diferen¸a entre o Download Progressivo e um
´ c
consideradas para otimiza¸˜o:
ca
download de um arquivo qualquer na internet via HTTP,
consiste na possibilidade de iniciar a decodifica¸˜o antes que
ca • As conex˜es com o WebServer s˜o persistentes, ou seja,
o a
todo conte´do esteja dispon´
u ıvel. Esta, ali´s, ´ uma car-
a e o usu´rio fica conectado ao servidor por uma quanti-
a
acter´ıstica bastante importante, que limita a utiliza¸˜o do ca dade razo´vel de tempo, at´ que o conte´do seja com-
a e u
Download Progressivo por determinados formatos de m´ ıdia, pletamente copiado
que dependem de informa¸˜es contidas no trailer do arquivo
co
para realizar a decodifica¸˜o, como arquivos MOV/MP4.
ca • Dependendo da quantidade de v´ ıdeos diferentes pode-
Nestes casos, ´ necess´rio alterar o encapsulamento do con-
e a mos ter diversos conte´dos diferentes sendo acessados
u
te´do, transferindo todas as informa¸˜es necess´rias para o
u co a simultaneamente
header, de modo que a decodifica¸˜o possa ser iniciada as-
ca
sim que os primeiros frames de v´ ıdeo sejam recebidos. Por • Os arquivos de m´ ıdia n˜o est˜o necessaiamente nos
a a
este motivo, o Download Progressivo ´ popular apenas para
e discos do servidor. Eles podem estar em um reposit´rio
o
distribui¸˜o de Flash V´
ca ıdeos e MOV/MP4. central sendo acessados pelo servidor Web atrav´s de
e
O Download Progressivo, ao contr´rio do Streaming, per-
a NFS/CIFS
mite que o conte´do seja reproduzido continuamente mesmo
u
• A quantidade de acessos ao servi¸o pode aumentar rap-
c
em ambientes onde a disponibilidade de banda ´ inferior ao e
idamente, variando de acordo com o conte´do disponi-
u
bitrate total do arquivo. Na verdade, ´ poss´ e ıvel calcular
bilizado
a largura de banda efetiva durante o download e, baseado
neste valor, iniciar a reprodu¸˜o apenas quando o tempo
ca Com estas caracter´
ısticas j´ podemos identificar alguns gar-
a
restante de download for inferior ao tempo total de execu¸˜o ca galos principais:
do conte´do. Desta forma, at´ usu´rios com baixa taxa de
u e a
transferˆncia podem ter uma experiˆncia satisfat´ria no con-
e e o • Tr´fego de rede: muitos usu´rios conectados realizando
a a
sumo de m´ ıdia na internet. Uma outra caracter´ ıstica inter- download ir˜o rapidamente ocupar a banda dispon´
a ıvel.
essante ´ que ap´s copiado, ´ poss´ realizar um seek para
e o e ıvel Al´m disso, existe a ocupa¸˜o de banda pela c´pia dos
e ca o
qualquer posi¸˜o do arquivo sem que seja necess´rio realizar
ca a arquivos do reposit´rio central para o servidor
o
um buffer de conte´do para reprodu¸˜o, isto ´, ap´s a c´pia,
u ca e o o
todo o conte´do est´ dispon´ independente das condi¸˜es
u a ıvel co • IO (Reposit´rio Central e Disco Local): muitos usu´rios
o a
da rede. Com isso, ´ poss´ controlar por quanto tempo o
e ıvel realizando download significa muito IO de leitura, que
conte´do ´ v´lido na m´quina do usu´rio, permitindo inclu-
u e a a a ´ maior a medida que temos mais usu´rios acessando
e a
sive uma redu¸˜o no tr´fego de rede e uma maior disponibil-
ca a arquivos diferentes.
idade, o que pode ser uma vantagem bastante significativa
• Mem´ria: quanto mais usu´rios, mais mem´ria o Apache
o a o
para o usu´rio quando ele paga por byte trafegado na rede.
a
ir´ precisar para atendˆ-los, e quanto mais arquivos,
a e
Al´m disso, por ser fundamentalmente uma transferˆn-
e e
mais mem´ria o kernel ir´ utilizar para cache
o a
cia de dados via HTTP, a arquitetura de distribui¸˜o via ca
Download Progressivo pode ser extremamente simples, com • CPU: quanto mais usu´rios mais processamento para
a
um baixo custo de implanta¸˜o e manuten¸˜o, al´m de ser
ca ca e organizar e servir as requisi¸˜es
co
facilmente escal´vel, se for implementada de forma correta.
a
O componente b´sico de uma estrutura de distribui¸˜o em
a ca A seguir iremos analisar todas as configura¸˜es que pode-
co
Download Progressivo ´ um Servidor Web, como o Apache,
e mos fazer no sistema com o objetivo de maximizar a capaci-
que recebe e processa requisi¸˜es HTTP. Al´m do Apache,
co e dade de distribui¸˜o por servidor.
ca
existem diversas alternativas, como IIS da Microsoft e o
LightHTTPd, por´m, por ser completamente Open-Source
e 3.1 Otimização no Servidor Web - Apache
e gratuito, al´m de possuir uma comunidade de desenvolvi-
e O primeiro ponto, e mais simples, consiste em alterar as
mento e suporte bastante ativa, o uso de Apaches ´ forte- e configura¸˜es do Apache, escolher a vers˜o correta (2.X), e
co a
mente recomendado. Nesta mesma linha de utilizarmos uma compilar uma vers˜o do Web Server que tenha apenas aquilo
a
arquitetura simples e de baixo custo, podemos utilizar um que ´ relevante para a distribui¸˜o de arquivos, ou seja, de-
e ca
sistema operacional Linux, que ´ bastante comum e utilizado
e vemos evitar incluir na configura¸˜o de compila¸˜o m´dulos
ca ca o
para distribui¸˜o de conte´do na web. Assim, com um servi-
ca u que n˜o ser˜o utilizados, como mod ssl, por exemplo.
a a

5. Uma vez compilado cabe a n´s decidir qual arquitetura in-
o com os testes realizados que mostraram que com muitas
terna de funcionamento possui uma performance maior: se ´ e threads em baixo de um unico processo o overhead sobre
´
a multi-process (Apache Prefork) ou a multi-process/multi- ele era muito alto, e o consumo de recursos com uma quan-
thread (Apache Worker). tidade intermedi´ria de clientes era maior.
a
Basicamente, no prefork, para cada conex˜o ser´ criado
a a Al´m de configurar o MPM, o Apache permite diversas
e
um processo espec´ ıfico para atendˆ-la, de modo que a quan-
e outras configura¸˜es capazes de aumentar o desempenho
co
tidade de processos httpd ser´ sempre maior ou igual a quan-
a do mesmo, como a possibilidade de desabilitar Hostname
tidade de clientes. Nesta arquitetura, temos uma quantidade Lookups e DNS resolving, e outras que podem ser encon-
inicial que processos que s˜o pr´-criados para atender as
a e tradas na documenta¸˜o do Apache.
ca
conex˜es, sendo que a medida que os clientes se conectam,
o Entretanto, quando falamos de arquiteturas de distribui¸˜o
ca
eles s˜o atendidos por estes processos. No prefork, temos
a de v´ıdeo que recebem grandes volumes de acesso, devemos
basicamente dois problemas em termos de performance: nos preocupar um pouco mais em como otimizar o processo
de distribui¸˜o. Uma das maneiras mais eficientes de au-
ca
• Mem´ria: cada processo criado ocupa uma por¸˜o da
o ca mentar a capacidade de uma infra-estrutura de Download
mem´ria, de modo que a mem´ria dispon´ para cache
o o ıvel Progressivo consiste em realizar um processo de cache in-
do kernel ´ cada vez menor, ao ponto que toda ela
e tensivo.
´ preenchida pelos processos httpd, momento onde o
e
servidor come¸a a fazer swap em disco.
c
3.2 Aumentando o Desempenho com Estraté-
• Load: a cria¸˜o de novos processos (fork) gera um over-
ca gias de Cache
head no sistema, de modo que quanto maior a taxa de Ter uma estrat´gia de cache de conte´do ´ fundamental
e u e
conex˜o, maior ser´ o overhead no fork para atender
a a quando falamos de alta performance com um grande vol-
as novas conex˜es.
o ume de acessos. Quando temos um volume muito grande,
A outra op¸˜o de MPM, o worker, trabalha com o conceito
ca temos tamb´m diversos requests ao mesmo conte´do. Pro-
e u
multi-thread, onde as requisi¸˜es s˜o atendidas por threads
co a cessar todo o request para cada cliente consistiria em repe-
e n˜o por processos. Assim, ter´
a ıamos apenas um ou poucos tir as mesmas opera¸˜es diversas vezes, sem aproveitar para
co
processos com m´ltiplas threads em cada um deles, aten-
u um request os dados processados por outro. Assim, fica
dendo cada uma das conex˜es. Com o worker, minimizamos
o claro que podemos otimizar este processamento, simples-
a utiliza¸˜o de mem´ria, j´ que as threads compartilham
ca o a mente aproveitando aquilo que serve para mais de uma req-
a mesma ´rea de mem´ria do processo pai, e reduzimos
a o uisi¸˜o.
ca
o overhead na cria¸˜o de processos. Na verdade, no caso
ca Em situa¸˜es onde temos uma arquitetura onde o Apache
co
do worker, definimos a quantidade de threads por processo funciona como uma esp´cie de ”proxy” entre o usu´rio e um
e a
de modo que s´ realizamos um fork quando este limite ´
o e reposit´rio central de v´
o ıdeos, essa necessidade ´ ainda mais
e
atingido. latente, uma vez que n˜o faz sentido obter um mesmo ar-
a
A escolha entre prefork ou worker deve ser realizada caso quivo diversas vezes neste reposit´rio para servir para os
o
a caso, ou seja, dependendo da situa¸˜o de uso e da config-
ca clientes a cada request semelhante. Uma vez copiado do
ura¸˜o de hardware uma escolha poder´ ser melhor que a
ca a storage para o Apache, para servir uma requisi¸˜o, o arquivo
ca
outra. No caso espec´ ıfico de servidores para utiliza¸˜o em
ca pode ser mantido no servidor Web para as requisi¸˜es pos-
co
distribui¸˜o de v´
ca ıdeos em Progressive Download, a escolha teriores realizadas ao mesmo v´ ıdeo. Com essa abordagem,
do MPM Worker ´ recomendada, com o objetivo de reduzir
e reduzimos a carga no storage e o tr´fego de rede e de oper-
a
a ocupa¸˜o de mem´ria pelo servidor Web, deixando-a livre
ca o a¸˜es de c´pia.
co o
para que o kernel possa utiliz´-la para cache de conte´do,
a u Para realizar o cache de conte´do existem diversas alter-
u
reduzindo o IO no disco e consequentemente o tempo de re- nativas, como o Squid e o mod cache. O mod cache, por
sposta da requisi¸˜o. Uma configura¸˜o interessante seria
ca ca estar integrado ao Apache e por ser bastante conhecido e uti-
neste caso seria for¸ar a cria¸˜o de todos os processos filho
c ca lizado, al´m de apresentar uma ´tima performance, ´ uma
e o e
(childs) e suas threads no momento que o servidor Web for excelente op¸˜o para cache em arquiteturas de distribui¸˜o
ca ca
iniciado, reduzindo assim o overhead de controle de threads, em Download Progressivo.
por exemplo: O mod cache permite duas abordagens principais de cache:
disco ou mem´ria. O mod disk cache ´ o m´dulo respon-
o e o
ThreadLimit 100 s´vel pelo cache em disco, e funciona da seguinte forma: ao
a
ServerLimit 12 receber um request, o mod disk cache verifica se o conte´do u
StartServers 12 solicitado j´ est´ no cache em disco. Se estiver, o m´dulo
a a o
MaxClients 1200 valida se o conte´do n˜o est´ expirado e serve o mesmo a
u a a
MinSpareThreads 1200 partir do cache, sem que a requisi¸˜o seja passada aos demais
ca
MaxSpareThreads 1200 m´dulos do Apache. Caso, n˜o esteja cacheado, o request
o a
ThreadsPerChild 100 passa pelo path normal de atendimento ao request, sendo
MaxRequestsPerChild 0 que, ao finalizar o processamento, o mod cache escreve a re-
sposta no cache antes de servir a mesma. Assim, ele cria
Na configura¸˜o acima teremos inicialmente a cria¸˜o dos
ca ca dois arquivos em disco: o .data, com o conte´do do request,
u
12 processos com 100 threads que ficar˜o esperando novas
a e o .header com os headers da resposta. O nome dos ar-
conex˜es, sendo que assim evitamos a necessidade de forks
o quivos criados ´ criado a partir de um hash, para evitar que
e
adicionais e um overhead para o controle da quantidade de o conte´do seja sobre-escrito.
u
threads dispon´ıveis. Al´m disso, definimos um m´ximo de
e a O mod mem cache, ´ o m´dulo respons´vel pelo cache em
e o a
100 threads pro processo. Este valor foi definido de acordo mem´ria, e funciona de forma semelhante ao mod disk cache,
o

6. por´m armazenando o conte´do em mem´ria.
e u o
A escolha de um dos m´dulos para utiliza¸˜o em um servi-
o ca Desde o aparecimento do Napster no come¸o de 1999,
c
dor de Download Progressivo tamb´m depende da configu-
e as redes peer-to-peer (P2P) tˆm experimentado um cresci-
e
ra¸˜o do hardware. Entretanto, em servidores que rodam
ca mento consider´vel. Em 2003 as aplica¸˜es P2P passaram
a co
em Linux, o uso do mod disk cache ´ recomendada, uma
e a ser as mais populares na Internet, e, no final de 2004,
vez que o gerenciamento do cache em mem´ria feito pelo
o os protocolos P2P representavam 60% do tr´fego total da
a
kernel ´ bastante eficiente. Assim, poder´
e ıamos ter a seguinte Internet. [7] Esse r´pido sucesso foi sustentado por redes
a
configura¸˜o:
ca de transferˆncia de arquivos quem permitiam usu´rios tro-
e a
carem arquivos de m´ ıdia. A expectativa ´ que esse cresci-
e
<IfModule mod_cache.c> mento continue com o desenvolvimento de novas aplica¸˜es co
<IfModule mod_disk_cache.c> P2P.
CacheRoot /mnt/flashcache Uma outra op¸˜o muito interessante, especificamente para
ca
CacheEnable disk / transmiss˜es ao vivo, ´ o IP Multicast. O conceito ´ bastante
o e e
CacheDirLevels 2 antigo, introduzido por S. Deering em sua tese de doutorado
CacheDirLength 1 [5] em 1988. Sendo que o primeiro teste em larga escala s´ o
CacheMaxFileSize 209715200 #200GB ocorreu no encontro da IETF em 1992 [6]. Essa arquitetura e
CacheMinFileSize 1 alguns de seus desafios ser˜o rapidamente relatados a seguir.
a
CacheDefaultExpire 86400
CacheMaxExpire 86400 4.1 Peer to Peer
</IfModule>
</IfModule> Em uma transmiss˜o P2P, um fluxo de m´
a ıdia ´ enviado
e
para uma audiˆncia consider´vel utilizando a capacidade de
e a
Com uma configura¸˜o adequada de cache ´ poss´
ca e ıvel au- uplink em cada n´ para repassar os dados. An´logo `s re-
o a a
mentar a capacidade de um servidor de Download Progres- des de transferˆncia de arquivos, a propaga¸˜o de dados ´
e ca e
sivo em at´ 40%, sendo que, juntamente com a escolha cor-
e feita por um protocolo distribu´ que permite que os n´s
ıdo o
reta de configura¸oes do servidor Web, este ganho pode atin-
c˜ se auto-organizem em ´rvores de distribui¸˜o. A diferen¸a
a ca c
gir at´ 70%.
e fundamental nesse caso ´ que isso deve acontecer em tempo
e
real para que os usu´rios conectados tenham uma experiˆn-
a e
3.3 As desvantagens do Download Progressivo cia pr´xima com a de assistir TV. Comparado com redes de
o
Apesar de ser uma solu¸˜o bastante simples e com baixo
ca distribui¸˜o de conte´do (content delivery networks, CDN),
ca u
custo de implementa¸˜o, o Download Progressivo possui al-
ca essa proposta ´ bastante interessante pelo fato de n˜o pre-
e a
gumas desvantagens quando comparado com outras tecnolo- cisar de uma infra-estrutura dedicada e ser auto-escal´vel a a
gias. O fato de copiar totalmente o conte´do conte´do para-
u u medida que os recursos da rede aumentam com o n´mero de u
para a m´quina do usu´rio, exatamente como acontece com
a a usu´rios.
a
um download de um arquivo qualquer, torna esta solu¸˜o ca Para que seja amplamente adotado, sistemas de stream-
relativamente insegura, dado que existem diversas formas ing P2P devem atingir uma qualidade de v´ ıdeo alta e con-
extremamente simples de se obter, copiar e distribuir ilegal- stante, assim como uma baixa latˆncia para o in´
e ıcio da re-
mente o conte´do. Existem algumas t´cnicas que dificultam
u e produ¸˜o. Alguns fatores dificultam bastante essa tarefa. A
ca
o acesso ` este conte´do copiado, n˜o ´ poss´ garantir que
a u a e ıvel largura de banda dispon´ em cada n´ ´ normalmente insu-
ıvel oe
ele n˜o ser´ utilizado indevidamente.
a a ficiente para manter a qualidade alta do v´ ıdeo. Al´m disso,
e
Outra limita¸˜o do Download Progressivo est´ na sua in-
ca a os n´s podem decidir desconectar a qualquer momento, in-
o
capacidade de transmitir conte´do ao vivo. Na verdade,
u terrompendo o caminho de distribui¸˜o. Verificamos ent˜o
ca a
existem algumas t´cnicas que permitem que isto aconte¸a,
e c que essa rede ´ altamente dinˆmica e n˜o confi´vel. Essas
e a a a
por´m, elas est˜o longe de serem eficientes. Para utilizar
e a caracter´ısticas espec´ıficas demonstram o tamanho do desafio
o Download Progressivo para uma transmiss˜o ao vivo ´
a e associado a implementa¸˜o dessas redes.
ca
necess´rio identificar no sinal de video codificado que est´
a a Apesar de todos os desafios existem diversas solu¸˜es com-
co
sendo gerado a posi¸˜o o ultimo key-frame, para que a cada
ca ´ erciais dispon´ıveis no mercado como a Octoshape [3] e Pando
nova conex˜o seja atendida a partir deste ponto. Com isso,
a [4]. Entretanto todos eles re-caem no mesmo problema do
´ necess´rio incluir um header semelhante ao header de um
e a cliente ter que instalar um software propriet´rio exclusivo
a
arquivo previamente codificado, al´m de definir um content-
e (em geral em forma de plug-in) para servir o conte´do. u
length fict´ ıcio na resposta do servidor web. Com isso, o Recentemente a Adobe anunciou que a vers˜o 10 do seu
a
cliente processa o conte´do pensando que o mesmo ´ um
u e Flash Player possibilitar´ a distribui¸˜o de conte´do usando
a ca u
arquivo comum, apesar de n˜o ter um final definido.
a P2P [1]. Em agosto de 2008, data da elabora¸˜o desse ar-
ca
Assim, utilizar uma arquitetura de Download Progressivo tigo, o Flash Player 10 ainda era apenas um beta, mas com
pode ser extremamente interessante tanto em cen´rios coma sua alta penetra¸˜o no mercado [2] passa a ser um grande
ca
pequenos volumes de produ¸˜o e audiˆncia, quanto em ambi-
ca e promissor no mercado P2P.
entes com grandes volumes de acesso, sendo bastante flex´ ıvel
com rela¸˜o ` varia¸˜es na disponibilidade de rede, uma
ca a co 4.2 Multicast
vez que elas n˜o prejudicam tanto a experiˆncia do usu´rio.
a e a Os trabalhos de S. Deering [5] levaram a cria¸˜o de um
ca
Al´m disso, a simplicidade e o baixo custo de implanta¸˜o e
e ca ”multicast backbone” na Internet, conhecido como MBone,
manuten¸˜o tornam esta alternativa bastante atraente para
ca que consiste em ilhas de multicast conectadas por liga¸˜es
co
distribui¸˜o de m´
ca ıdias na internet. ponto-a-ponto chamadas t´neis IP. Cada t´nel IP conectava
u u
dois roteadores de multicast atrav´s de um enlace l´gico, que
e o
4. OUTRAS ARQUITETURAS podia ultrapassar v´rios roteadores unicast IP. Mensagens
a

7. IP multicast eram encaminhadas encapsuladas em IP uni-
cast de roteador e roteador multicast. Como o MBone e a
Internet tem topologias diferentes, os roteadores multicast
executam um protocolo de roteamento separado.
Para fins acadˆmicos e pesquisa o MBone cumpria muito
e
bem o seu papel. Entretanto, para que as transmiss˜es com-
o
erciais tenham as vantagens da conex˜o multicast toda a
a
rede, desde a gera¸˜o de conte´do at´ o usu´rio final pre-
ca u e a
cisam suportar esse protocolo. Para que isso ocorra precisa
haver um interesse em comum das empresas geradoras de
conte´do, provedores de trˆnsito e provedores de conex˜o
u a a
ao usu´rio final.
a
Devido ao modelo comercial implantado, onde em geral as
operadoras cobram por tr´fego gerado, dificilmente o custo
a
de montar tal opera¸˜o justifica o interesse. Por isso os
ca
autores at´ hoje n˜o conhecem grandes casos de transmiss˜es
e a o
comerciais usando multicast.
5. CONCLUSÃO
Como podemos ver, existem diversas solu¸˜es e alternati-
co
vas que abordam o desafio de distribuir v´ ıdeos na internet
de maneiras diferentes, de modo que cada uma delas possui
um conjunto de caracter´ ısticas que podem ser bastante im-
portantes em cen´rios espec´
a ıficos. Na verdade, a chave para
escolha da melhor arquitetura consiste na avalia¸˜o correta
ca
de todos os pontos envolvidos no processo de distribui¸˜o,
ca
considerando assim os pr´s e contras de cada solu¸˜o, para
o ca
cada necessidade. Existem situa¸˜es onde o streaming ser´ a
co a
melhor escolha, por realizar uma distribui¸˜o em tempo-real
ca
e por contribuir para a seguran¸a do conte´do, por´m, em
c u e
outra situa¸˜o o download progressivo poder´ ser mais ade-
ca a
quado, por permitir uma experiˆncia cont´
e ınua independente
das varia¸˜es na disponibilidade de banda.
co
Al´m de se preocupar com a tecnologia a ser adotada, ´ de
e e
fundamental importˆncia projetar uma arquitetura escal´vel
a a
e facilmente gerenci´vel, que permita uma r´pida adapta¸˜o
a a ca
de acordo com a varia¸˜o da demanda, ao mesmo tempo que
ca
devemos sempre nos preocupar em otimizar ao m´ximo osa
recursos utilizados. Desta forma, teremos uma arquitetura
flex´ıvel e capaz de atender as necessidades de um neg´cioo
em constante evolu¸˜o.
ca
6. BIBLIOGRAFIA
[1] Peer to peer (p2p) in flash player 10 beta.
[2] Adobe flash player version penetration, 2008.
[3] Octoshape official website, 2008.
[4] Pando official website, 2008.
[5] S. Deering. Multicast Routing in a Datagram
Internetwork. PhD thesis, Stanford University, 1991.
[6] S. Casner; S. Deering. First internet audiocast. In ACM
Computer Communication Review, pages 92–97, 1992.
[7] Richard MacManus. Trend watch: P2p traffic much
bigger than web traffic, 2006.