Aplicações em Redes e Qos - Aula 2

Prévia do material em texto

DESCRIÇÃO
O Vídeo de Fluxo Contínuo Armazenado, os protocolos utilizados, as Redes de Distribuição de
Conteúdo e os estudos de caso sobre a operação da Netflix e do YouTube.
PROPÓSITO
Compreender as características do vídeo de fluxo contínuo armazenado e o funcionamento dos
protocolos utilizados para seu controle, bem como entender a operação desse tipo de serviço.
Analisar como o emprego de redes de distribuição de conteúdo, conhecidas pela sigla CDN,
contribui para a melhoria da experiência do usuário, e como funcionam provedores de
conteúdo de vídeo armazenado.
OBJETIVOS
MÓDULO 1
Analisar as características e o funcionamento do Vídeo de Fluxo Contínuo Armazenado
MÓDULO 2
Analisar o funcionamento das Redes de Distribuição de Conteúdo
MÓDULO 3
Descrever casos reais de empresas que utilizam Fluxo Contínuo de Vídeo Armazenado
INTRODUÇÃO
Ao longo dos anos, o tráfego de dados da internet evoluiu de mensagens enviadas como texto
para os mais diversos tipos de conteúdo. Nos últimos anos, o streaming de vídeo se tornou o
principal tipo de tráfego, atingindo mais de 80% de tudo que transita pela internet.
Para atender a essa demanda, foi necessário desenvolver várias técnicas, utilizando protocolos
como UDP, HTTP e TCP, para dar suporte às necessidades específicas desse tipo de
conteúdo.
Além disso, percebeu-se a necessidade do desenvolvimento das Redes de Distribuição de
Conteúdo com o objetivo de melhorar a experiencia do usuário.
São esses aspectos que estudaremos ao longo deste conteúdo, analisando estudos de caso
dos principais provedores de streaming de vídeo: Netflix e YouTube.
MÓDULO 1
 Analisar as características e o funcionamento do Vídeo de Fluxo Contínuo
Armazenado.
VÍDEO DE FLUXO CONTÍNUO
ARMAZENADO
Quando pensamos em vídeo na internet, a primeira ideia que temos é baixar o vídeo para
nosso dispositivo e assistir.
Esse esquema funciona por meio de uma requisição que fazemos ao servidor que armazena o
vídeo para iniciarmos o download. Após o arquivo ser baixado, podemos iniciar a reprodução
utilizando um programa de mídia.
Imagem: FOROUZAN, 2008, p 909.
 Download de Mídia.
Esse método, apesar de ser simples e funcionar, tem algumas desvantagens:
A reprodução somente pode começar após o término do download do arquivo.
O arquivo ocupa lugar no disco do hospedeiro, mesmo que o usuário deseje apenas reproduzi-
lo uma vez.
Pelos inconvenientes citados, foram desenvolvidos métodos que permitem assistir ao Vídeo
por Demanda (VOD); dessa forma, o vídeo pode ser assistido do início ao fim, sem interrupção,
bem como pausado ou reposicionado em uma cena futura ou passada.
A ideia então é utilizar um fluxo contínuo de vídeo a partir de um servidor de armazenamento.
Um método para fazer isso seria o exibido na figura a seguir, em que o media player acessa
diretamente o servidor web para fazer o download do arquivo. O servidor web armazena dois
arquivos: um com o áudio/vídeo real e um metafile que armazena informações específicas
sobre o arquivo de áudio/vídeo.
METAFILE
Arquivo de texto muito pequeno com as informações e alguns segundos iniciais do vídeo
que ficam em um buffer para lidar com eventuais atrasos no fluxo.
Imagem: FOROUZAN, 2008, p 910.
 Servidor web com metafile.
1
O cliente HTTP acessa o servidor web enviando uma mensagem GET.
As informações do metafile vêm junto com a resposta.
javascript:void(0)
2
3
O metafile é repassado para o media player.
O media player usa a URL contida no metafile para acessar o arquivo de áudio/vídeo.
4
5
5
O servidor web responde.
Note que, nesse caso, o media player pode iniciar a reprodução assim que começar a receber
o vídeo do servidor, o que diminui a espera do usuário, já que ele precisa baixar apenas o
metafile.
Esse método, entretanto, não está imune a problemas. O Browser e o Media Player usam o
HTTP que foi projetado para ser executado sobre o TCP, que devido a seu esquema de
retransmissão e controle de congestionamento é menos adequado à transmissão de mídia que
o UDP.
A partir dessa constatação, temos duas formas de lidar com o fluxo contínuo a partir de
protocolos diferentes:
UDP de fluxo contínuo.
HTTP de fluxo contínuo.
HTTP de fluxo contínuo adaptativo.
BUFFER DE VÍDEO ARMAZENADO
Seja utilizando UDP ou HTTP, para que o sistema funcione corretamente é necessário que
exista um buffer de aplicação no cliente para lidar com a variação do atraso (jitter) fim a fim e
com as eventuais flutuações da largura de banda entre o cliente e o servidor.
JITTER
Jitter é uma variação estatística do atraso na entrega de dados em uma rede, ou seja,
pode ser definida como a medida de variação do atraso entre os pacotes sucessivos de
dados.
javascript:void(0)
Foto: Shutterstock.com
 Congelamento da imagem.
Como vimos, inicialmente, o browser do cliente baixa o metafile, passa a informação para o
player de mídia que entra diretamente em contato com o servidor e inicia o fluxo de vídeo.
Esses passos geram um retardo desprezível para o início da reprodução do vídeo; porém, se
ao receber os primeiros dados o player de mídia começasse imediatamente a reprodução,
qualquer flutuação na banda ou atraso geraria congelamento da imagem ou sua pixelização.
Observe a figura a seguir que ilustra o atraso de reprodução.
Imagem: KUROSE, 2014, P 438.
 Atraso de Reprodução.
Em t0, o servidor transmite o primeiro bloco, e cada bloco contém os quadros a serem
reproduzidos e que foram codificados a uma taxa de bits fixa. A partir daí, a cada intervalo de
tempo fixo (Δ), ele transmite os outros blocos, t0 + Δ para o segundo, t0 + 2Δ para o terceiro e
assim sucessivamente.
Para que o cliente possa assistir ao vídeo sem congelamento ou pixelização, ele deve ser
exibido no mesmo ritmo de sua transmissão, respeitando a temporização do vídeo original.
Se o player iniciasse a reprodução logo após receber o primeiro bloco em t3 e ocorresse um
atraso na transmissão, como a do segundo bloco na linha do meio da figura, o segundo bloco
não teria chegado em t3 + Δ, de forma que a reprodução seria prejudicada.
Para evitar esse problema, os players possuem um buffer onde armazenam uma quantidade
de segundos de vídeo antes de iniciar a reprodução. Esse “colchão” de vídeo permite
amortecer eventuais flutuações do fluxo, fazendo com que o usuário não perceba que elas
ocorreram.
No exemplo acima, se o player inicialmente armazenasse em seu buffer os blocos de 1 a 6, e
somente depois iniciasse a reprodução, para o usuário, o problema do atraso seria contornado
de forma eficiente.
UDP DE FLUXO CONTÍNUO
Conforme vimos, um dos protocolos que podem ser utilizados para a transmissão de vídeo
armazenado é o UDP.
No UDP de fluxo contínuo, a transmissão do vídeo a partir do servidor ocorre a uma taxa igual
ao consumo de vídeo pelo cliente, de forma constante.
 EXEMPLO
Se a taxa de consumo for 2Mbit/s e cada pacote UDP transportar 2.000 bits de vídeo, o
servidor deverá enviar 1000 datagramas a cada segundo, ou seja, a cada 1ms um datagrama
UPD é enviado contendo 2000 bits de vídeo.
Nesse esquema, um player de mídia que utilize UDP terá um pequeno buffer no cliente para
armazenar aproximadamente 1 segundo de vídeo. O funcionamento básico é o seguinte:
Imagem: FOROUZAN, 2008, P 910.
 UDP fluxo contínuo.
Os passos ilustrados na figura são os seguintes:
1
O cliente HTTP acessa o servidor web enviando uma mensagem GET.
As informações do metafile vêm junto com a resposta.
2
3
O metafile é repassado para o media player.
O media player usa a URL contida no arquivo de metafile para acessar o servidor de mídia e
baixar o arquivo utilizando UDP na camada de transporte.
4
5
O servidor de mídia encapsulará os trechos de vídeo dentro de pacotes de transporte
projetados especialmente para transportar áudio e vídeo, usando o Real-Time Transport
Protocol (RTP) e os passará para o UDP para responder a solicitação.
REAL-TIME TRANSPORT PROTOCOL (RTP)
O RTP é um protocolo deredes utilizado em aplicações de tempo real como, por
exemplo, entrega de dados áudio ponto a ponto, como Voz sobre IP. Ele funciona como
uma subcamada na camada de transporte e define como deve ser feita a fragmentação
do fluxo de dados de áudio, adicionando a cada fragmento informação de sequência e de
tempo de entrega.
O esquema explicado tem como desvantagem não permitir que o usuário controle o vídeo,
pausando sua execução ou pulando para uma cena anterior ou posterior. Para acrescentar
esse tipo de facilidade, o RTP/UDP deve ser associado ao RTSP que acrescentará uma
conexão de controle ao esquema. Observe na figura a seguir o funcionamento do UDP com o
RTSP.
javascript:void(0)
javascript:void(0)
RTSP
O Real Time Streaming Protocol (RTSP) é um protocolo de aplicação, que trabalha na
porta 554, que controla a transferência de áudio ou vídeo sob demanda. Ele possui
diretivas para iniciar a reprodução, pausar a reprodução, avançar ou retroceder no vídeo
ou áudio.
Imagem: FOROUZAN, 2008, P 910.
 UDP e RTSP.
Os passos ilustrados na figura são os seguintes:
1
O cliente HTTP acessa o servidor web enviando uma mensagem GET.
As informações do metafile vêm junto com a resposta do servidor.
2
3
O metafile é repassado para o media player.
O media player envia uma mensagem de SETUP para estabelecer uma conexão com o
servidor de mídia.
4
5
O servidor de mídia responde estabelecendo a conexão.
O media player envia uma mensagem PLAY para iniciar a reprodução (download).
6
7
O servidor de mídia encapsulará os trechos de vídeo dentro de pacotes usando o protocolo
RTP, que os passará para o UDP para ser enviado.
A conexão é encerrada enviando-se a mensagem TEARDOWN.
8
9
O servidor de mídia responde fechando a conexão.
O UDP de fluxo contínuo possui três grandes desvantagens:
CONGELAMENTO E PIXELIZAÇÃO
Como a largura de banda entre o servidor e o cliente pode variar de forma imprevisível, a taxa
transmissão constante do UDP pode fazer com que a reprodução seja interrompida
(congelamento ou pixelização da imagem).
CUSTO E COMPLEXIDADE
Para permitir pausar, reiniciar ou correr a mídia para frente ou para trás, o UDP exige o uso de
um servidor de controle de mídia que utilize o RTSP, o que aumenta a complexidade e custo do
sistema.
BLOQUEIOS
Muitos firewalls são configurados para bloquear o tráfego UDP.
HTTP DE FLUXO CONTÍNUO
No HTTP de fluxo contínuo, o vídeo é armazenado em um servidor web como um arquivo
comum possuindo uma URL própria. Quando o usuário deseja assistir ao vídeo, ele realiza os
javascript:void(0)
javascript:void(0)
javascript:void(0)
seguintes passos:
1
Estabelece uma conexão TCP/IP com o servidor.
Realiza o comando HTTP GET na URL do vídeo.
2
3
O servidor envia o vídeo utilizando uma mensagem HTTP encapsulada em TCP.
No cliente, o vídeo é armazenado em um buffer até atingir um limite predeterminado.
4
5
Quando o buffer atinge esse limite, a aplicação cliente começa a exibir o vídeo consumindo
quadros do buffer.
O cliente continua recebendo quadros e os coloca no buffer.
6
7
Ao término da transmissão do vídeo, a conexão TCP é fechada.
A figura a seguir ilustra esse processo.
Imagem: Sidney Venturi.
 HTTP e TCP.
É importante notar que, nesse cenário, o servidor vai tentar transmitir o vídeo o mais rápido que
puder, respeitando o controle de fluxo e de congestionamento do TCP.
Pode parecer, a princípio, que o uso do TCP na camada de transporte é inadequado; nesse
caso, devido à variação na taxa de transmissão pelo controle de congestionamento e atraso
pela retransmissão de pacote perdidos. Entretanto, com o uso de um buffer adequado e a
utilização de pré-busca de vídeo, esses problemas podem ser minimizados, tornando a
técnica muito efetiva.
javascript:void(0)
PRÉ-BUSCA DE VÍDEO
Quando utilizamos TCP na camada de transporte, podemos, além do buffer, utilizar a pré-
busca que corresponde a baixar o vídeo em uma taxa maior do que a taxa de consumo
dos quadros do buffer; dessa forma, haverá um acúmulo maior de conteúdo no buffer,
gerando um “colchão maior“ para lidar com atrasos.
Esse comportamento é típico do TCP de fluxo contínuo, uma vez que o mecanismo que
impede o congestionamento tentará usar toda a largura de banda disponível entre o
cliente e o servidor.
Uma vantagem do uso do HTTP sobre TCP é que o esquema permite ao vídeo atravessar
firewalls e NATs mais facilmente (os quais são, em geral, configurados para bloquear a maior
parte do tráfego UDP, mas permitir o tráfego HTTP).
 DICA
De um modo geral, essa técnica se tornou um padrão, sendo utilizada em diversos provedores
de conteúdo, incluindo Netflix e YouTube.
O HTTP de fluxo contínuo permite o reposicionamento e o término antecipado do vídeo; para
isso, ele faz uso do cabeçalho do intervalo de bytes HTTP na mensagem HTTP GET,
especificando a faixa de bytes que o cliente deseja naquele momento. Em resumo:
CABEÇALHO DO INTERVALO DE BYTES
HTTP
Esse cabeçalho corresponde à requisição HTTP Range, que indica a parte do documento
que o servidor deve retornar. Várias partes podem ser requisitadas com um cabeçalho
javascript:void(0)
Range de uma vez, e o servidor pode mandar de volta esses intervalos em um
documento de múltiplas partes. Se o servidor manda de volta os intervalos, ele usa o 206
Partial Content para resposta.
Imagem:Shutterstock.com
REPOSICIONAMENTO
Quando o cliente deseja saltar para outro ponto do vídeo, basta fazer uma nova solicitação
com a posição desejada. O servidor, ao receber a nova mensagem GET, “esquece” a posição
que estava transmitindo e passa a transmitir a partir do novo ponto que foi especificado.
Imagem:Shutterstock.com
TÉRMINO ANTECIPADO DO VÍDEO
Quando o cliente deseja encerrar a transmissão, basta solicitar o fechamento da conexão TCP.
Vamos analisar agora como funcionam os buffers do TCP e de aplicação no HTTP de fluxo
contínuo, ilustrado na figura a seguir.
Imagem: KUROSE, 2014, p. 441.
 Vídeo de Fluxo Contínuo com HTTP/TCP.
Perceba que a parte do arquivo disponível no servidor que está em branco representa a porção
do vídeo que já foi transmitida, e, a parte azul, a porção que falta ser enviada.
Para a transmissão dos bytes restantes, estes são colocados no buffer de envio do TCP e
depois enviados pela internet. Como o buffer de envio está cheio, o servidor fica,
momentaneamente, impedido de transmitir.
No lado cliente, o player de mídia transfere os bytes do buffer de recepção do TCP para o
buffer da aplicação. Em paralelo, vai consumindo os quadros que estão em seu buffer,
descompactando-os e os exibindo na tela para o usuário.
ANÁLISE DO VÍDEO DE FLUXO CONTÍNUO
Vamos analisar agora o atraso inicial de reprodução e o congelamento devido ao esgotamento
do buffer da aplicação.
Observe a figura a seguir, em que B representa o tamanho do buffer do player de mídia, em
bits, e Q indica a quantidade de bits que precisam estar no buffer antes de iniciar a reprodução
do vídeo (corresponde ao “colchão”).
Imagem: KUROSE, 2014, p. 441.
 Análise de Buffer do Cliente.
Se o vídeo é exibido a 30 quadros por segundo, e cada quadro possui 100 mil bits, a taxa de
esgotamento (r) será de 3Mbit/s.
Para criar o “colchão” Q correspondente a 3 segundos de vídeo, se o servidor envia os dados a
2Mbit/s, que é a taxa de preenchimento x, o tempo de atraso antes do início da reprodução
será de 4,5 segundos, já que temos que ter transferidos 9Mbits para o buffer do player.
Agora, note que como x < r à razão de 1Mbit/s, ou seja, a cada segundo de vídeo é consumido
1MBit a mais do que a recomposição do buffer, após 9 segundos o “colchão” teria sido
consumido e o vídeo congelaria.
Isso mostra que, apesar de o "colchão" amortecer as flutuações da taxa de transmissão do
TCP, se a sua taxa média for menor do que a taxa de exibição do vídeo, depois de algum
tempo ele congelará. Nesse cenário, a reprodução ficará alternando entre exibição e
congelamento.
Vamos agora considerar a situaçãooposta: Se a taxa de preenchimento for de 4Mbit/s, o
“colchão” seria criado em pouco mais de 2 segundos e o vídeo começaria a reprodução.
Considere agora que o buffer todo possuísse espaço para 6 segundos; como a cada segundo é
acrescido de 1 Mbits, diferença entre x e r, em 9 segundos o buffer ficaria totalmente cheio, o
que faria o servidor pausar o envio do vídeo, até ter espaço disponível novamente no buffer.
Nesse cenário, a reprodução será contínua, já que o vídeo chega a uma taxa maior do que é
consumido, e o usuário não toma conhecimento do enchimento do buffer.
HTTP DE FLUXO CONTÍNUO ADAPTATIVO E
DASH
O HTTP de fluxo contínuo possui uma grande deficiência: Todos os clientes recebem o vídeo
com a mesma codificação, independentemente da largura de banda que possuem, o que pode
ocasionar o esgotamento do buffer da aplicação se a taxa de preenchimento for menor do que
a taxa de reprodução do vídeo.
Uma pergunta surgiu então para os projetistas de sistemas de vídeo armazenado:
 PERGUNTA
Poderíamos adequar a taxa de reprodução à taxa de preenchimento disponível para o usuário?
Em resposta a esse desafio foi criado o Fluxo Contínuo Adaptativo Dinamicamente sobre HTTP
(DASH). O DASH funciona da seguinte forma:
O vídeo é codificado em várias versões, cada uma com uma taxa de exibição de bits diferente,
variando a sua qualidade, cada um com sua própria URL.

Quando o cliente solicita o vídeo ao servidor, ele recebe um metafile em que são descritas
todas as versões disponíveis, sua taxa de bits, qualidade e URL.

O cliente solicita alguns segundos de vídeo da versão compatível com a sua largura de banda
naquele instante utilizando uma requisição GET.

Enquanto baixa o vídeo, o cliente monitora sua largura de banda de recepção.

À medida que a largura de banda aumenta ou diminui, o cliente utiliza um algoritmo que
determinará a taxa a ser utilizada na próxima requisição GET.

O cliente faz novas requisições pedindo mais alguns segundos da versão adequada a sua
situação atual.
O DASH possui algumas vantagens em relação ao HTTP normal:
Permite aos clientes com diferentes taxas de acesso à internet fluir em um vídeo por diferentes
taxas codificadas.
Clientes com conexões lentas podem receber uma versão com baixa taxa de bits (e baixa
qualidade), e clientes com conexões por fibra ótica podem receber versões de alta qualidade.
Permite a um cliente se adaptar à largura de banda disponível, caso a largura de banda fim a
fim altere durante a sessão, o que é bastante comum.
Em resumo, podemos observar que, se o cliente possui muito vídeo em seu buffer, e se a
largura de banda de recepção que foi medida for alta, ele escolherá um trecho de uma versão
com taxa alta associada. E, claro, se o cliente possui pouco vídeo em seu buffer, e a sua
largura de banda de recepção for baixa, escolherá um trecho de uma versão de taxa baixa.
O PAPEL DOS BUFFERS NA TRANSMISSÃO
MULTIMIDIA
No vídeo a seguir, você entenderá o papel dos buffers nas aplicações multimídia e na
eliminação dos efeitos causados pelo jitter.
VERIFICANDO O APRENDIZADO
1. NO PROCESSO DE UTILIZAÇÃO DO UDP DE FLUXO CONTÍNUO PARA
REALIZAR O STREAMING DE VÍDEO, PODEMOS AFIRMAR QUE:
I. O PROTOCOLO HTTP NÃO É UTILIZADO
II. O INÍCIO DA CONEXÃO É REALIZADO UTILIZANDO O RTSP
III. O PACOTE DE VÍDEO É ENCAPSULADO NO RTP
ESTÁ CORRETO O QUE SE AFIRMA EM:
A) II apenas
B) I e II apenas
C) I e III apenas
D) II e III apenas
E) I, II e III
2. NO PROCESSO DE UTILIZAÇÃO DO HTTP DE FLUXO CONTÍNUO PARA
REALIZAR O STREAMING DE VÍDEO, PODEMOS AFIRMAR QUE:
I. O PACOTE DE VÍDEO É ENCAPSULADO NO TCP.
II. O PROTOCOLO TCP É UTILIZADO PARA ESTABELECER UMA
CONEXÃO ENTRE O CLIENTE (PLAYER DE MÍDIA) E O SERVIDOR.
III. A REPRODUÇÃO COMEÇA IMEDIATAMENTE APÓS O RECEBIMENTO
DO PRIMEIRO PACOTE DO VÍDEO.
ESTÁ CORRETO O QUE SE AFIRMA EM:
A) I apenas
B) I e II apenas
C) I e III apenas
D) II e III apenas
E) I, II e III
GABARITO
1. No processo de utilização do UDP de Fluxo Contínuo para realizar o streaming de
vídeo, podemos afirmar que:
I. O protocolo HTTP não é utilizado
II. O início da conexão é realizado utilizando o RTSP
III. O pacote de vídeo é encapsulado no RTP
Está correto o que se afirma em:
A alternativa "D " está correta.
A primeira afirmativa é falsa porque para utilizar o UDP de fluxo contínuo o browser do cliente
deve inicialmente mandar uma requisição HTTP GET para o servidor web, que lhe responderá
com o metafile com as informações para que a aplicação possa acessar o servidor de vídeo. As
outras duas opções são verdadeiras.
2. No processo de utilização do HTTP de Fluxo Contínuo para realizar o streaming de
vídeo, podemos afirmar que:
I. O pacote de vídeo é encapsulado no TCP.
II. O protocolo TCP é utilizado para estabelecer uma conexão entre o cliente (player de
mídia) e o servidor.
III. A reprodução começa imediatamente após o recebimento do primeiro pacote do
vídeo.
Está correto o que se afirma em:
A alternativa "A " está correta.
A primeira afirmativa está correta. A segunda afirmativa está incorreta, pois o TCP cria a
conexão entre o browser do cliente e o servidor, sendo o browser que recebe os pacotes de
vídeo e os coloca em um buffer do qual o player de mídia os lerá.
A terceira afirmativa está incorreta porque a reprodução somente começa após o buffer ter
recebido uma quantidade predeterminada de pacotes de vídeo, visando atenuar o efeito do
jitter.
MÓDULO 2
 Analisar o funcionamento das Redes de Distribuição de Conteúdo.
TRÁFEGO NA INTERNET
Ao olharmos a história da internet, podemos notar que, em seu início, ela era utilizada
basicamente para comunicação e troca de arquivos. O uso do e-mail, chat de texto e entrega
de arquivos por FTP dominavam o cenário. Com o aparecimento da WWW, ocorreu um boom
na busca de informações, ocupando a maior parte da largura de banda da rede. 
No início dos anos 2000, o compartilhamento de arquivos P2P (música, vídeo etc.) passou a
dominar e, no final, o streaming de vídeo, oferecido por sites como YouTube e Netflix,
despontou como o maior gerador de tráfego na internet, gerando mais de 80% do tráfego total.
Imagem: Shutterstock.com
 Tráfego de mídias.
 COMENTÁRIO
Você pode achar essa estatística estranha, afinal você se comunica por voz e texto usando
algum programa de mensagens e faz isso mais vezes do que assiste a vídeos, mas, lembre-se,
a largura necessária para transmitir vídeo é duas ordens de grandeza maior do que a
necessária para transmitir voz ou mensagens.
Um problema que surgiu a partir dessa situação é que sites muito populares demandaram uma
infraestrutura muito grande para poderem funcionar. Nenhum servidor isolado é poderoso o
suficiente para lidar com a demanda de sites como YouTube ou Netflix.
Além da enorme largura de banda necessária para atender aos clientes, o poder de
processamento para lidar com as requisições simultâneas é enorme. Os projetistas de redes
buscaram então soluções para esses problemas.
A primeira parte da solução foi prover no núcleo da internet uma largura de banda elevada e,
na borda da rede, uma conectividade de banda larga mais rápida.
Essa solução resolveu parte do problema, mas continuavam existindo atrasos fim a fim e
gargalos no processamento das requisições. Então, novas arquiteturas para distribuição de
conteúdo foram desenvolvidas, passando pela criação de grandes parques de servidores
(datacenters), uso de proxies e a criação de Redes de Distribuição de Conteúdo.
PARQUES DE SERVIDORES
Para melhorar a capacidade de processamento do lado servidor, visando agilizar a resposta às
requisições HTTP, uma das soluções foi o emprego de um Parque de Servidores.
Um parque de servidores, normalmente montado em datacenters, nada mais é do que um
conjunto de máquinas vistas como um único site lógico pelo cliente, mas na realidade temos
vários sites diferentes trabalhando em paralelo.
A ideia básica é que qualquer um dos servidores do parque deve ter condiçõesde responder à
requisição de qualquer cliente e para qualquer conteúdo, sendo, portanto, necessário que
todos os servidores do parque possam acessar uma cópia integral do conteúdo que será
disponibilizado.
Como pode ser visto na figura a seguir, para que cada servidor possa acessar o conteúdo,
todos estão ligados a um Banco de Dados back-end (linhas tracejadas na figura) que armazena
o conteúdo.
Imagem: TANENBAUM, 2011, p. 464
 Parque de Servidores.
Outro problema recorrente nessa solução é como distribuir as requisições entre os servidores.
Conheça algumas das possíveis soluções para este problema:
BALANCEAMENTO DE CARGA
O front-end recebe as requisições que chegam da internet e as distribui entre os servidores,
buscando fazer o balanceamento de carga entre eles.
Para isso, o front-end, que normalmente é um switch ou roteador IP, lê os cabeçalhos das
camadas de redes, transporte e aplicação, violando a ideia do encapsulamento, e decide para
qual servidor a encaminhará.
Esse mapeamento entre as requisições e os servidores é denominado Política de
Balanceamento de Carga e pode utilizar vários critérios, dos mais simples aos mais
complexos.
Um exemplo de critério simples seria estabelecer uma fila de servidores e fazer a distribuição
sucessivamente para o que estiver em primeiro lugar. Obviamente, o servidor que recebe a
requisição passa para o final da fila.
Este método exige que o front-end lembre-se do mapeamento que realizou para cada
requisição, de modo que os pacotes seguintes que fazem parte da mesma solicitação sejam
enviados ao mesmo servidor.
ENCAMINHAMENTO POR BROADCAST
Uma outra forma mais simples de resolver a questão é o front-end encaminhar por broadcast
todas as requisições a todos os servidores e deixar que estes decidam quais irão atender.
Para que essa solução funcione, os servidores devem responder apenas a uma pequena parte
das requisições; por exemplo, poderiam examinar o endereço IP de origem e responder ao
solicitante somente se os quatro últimos bits do endereço IP de origem combinarem com seus
seletores configurados. Outros pacotes seriam descartados.
USO DE DNS
Uma outra forma de distribuir as requisições entre os servidores é utilizando o serviço de
nomes DNS. Quando o cliente deseja fazer uma requisição, ele solicita, via DNS, o IP do
servidor. A resposta do DNS não é um endereço IP, mas uma lista móvel de endereços de
servidores que atendem àquele site. Como normalmente o cliente faz a requisição ao primeiro
IP da lista, cada um deles enviará a requisição para um servidor distinto.
Note que o uso do DNS está no centro do funcionamento das Redes de Distribuição de
Conteúdo, como veremos logo mais.
javascript:void(0)
DOMAIN NAME SYSTEM
Lista móvel é aquela que apresenta uma ordenação diferente dos IP dos servidores a
cada retorno de consulta para o cliente.
PROXIES WEB
Você sabe para que servem os proxies web? Afinal, qual é a diferença entre os proxies e os
parques de servidores?
Parque de Servidores
Visa melhorar o acesso ao conteúdo pelo lado do servidor.

Proxy
Visa aprimorar a experiência pelo lado cliente.
A ideia aqui é que se um conteúdo foi solicitado no passado, ao se manter uma cópia em um
servidor próximo ao usuário final, se ele for novamente solicitado, não haverá necessidade de
baixá-lo novamente pela internet, permitindo seu compartilhamento com vários usuários.
Claro que esse esquema suscita novos problemas como, por exemplo, saber se o conteúdo
ainda é valido, ou seja, se não sofreu modificação.
Para isso, o Servidor Proxy, ilustrado na figura a seguir, analisa vários dados das páginas em
cache, determinando se deve mantê-las e entregá-las ao solicitante ou não, devendo então
requisitá-las novamente na internet.
Imagem: TANENBAUM, 2011, p. 466.
 Proxy.
Normalmente, a organização, uma empresa ou um ISP, utiliza o Proxy para os seus usuários,
reduzindo a necessidade de largura de banda e diminuindo a latência para o início do acesso,
já que, normalmente, o Proxy está na rede interna, o que torna o acesso ao seu conteúdo mais
rápido e menos sujeito a erros.
Nesse cenário, cada navegador é configurado para fazer solicitações das páginas ao proxy, e
não ao servidor real da página. Se existir uma cópia da página, e ela for válida, ele a retornará
imediatamente. Se não, ele buscará a página na internet, acrescentará ao seu cache para uso
futuro e a retornará ao cliente que a solicitou.
REDES DE DISTRIBUIÇÃO DE CONTEÚDO
CDNS (CONTENT DELIVERY NETWORKS)
Apesar da grande melhoria que o Parque de Servidores gerou para disponibilização de
conteúdo, a solução não atende plenamente a provedores de acesso massivo como o YouTube
ou a Netflix.
Isso decorre do fato de que, ao utilizar um único parque de servidores (datacenter) para
armazenar seus vídeos e os distribuir, surgem três grandes problemas:
DISTÂNCIA
DESPERDÍCIO
DISPONIBILIDADE
DISTÂNCIA
Se a distância for muito grande entre o cliente e o parque de servidores, os pacotes que vão
do servidor para o cliente atravessarão muitos enlaces de comunicação e passarão por muitos
ISPs. Se um dos enlaces fornecer uma taxa de transferência menor do que a de consumo do
vídeo, a taxa de transferência fim a fim será também abaixo da de consumo, resultando para o
usuário em atrasos incômodos por congelamento.
DISTÂNCIA FOR MUITO GRANDE
Distância muito grande em termos de redes significa que entre o cliente e o servidor há
muitos enlaces de redes, possivelmente passando por diversos sistemas autônomos,
cada um com sua própria arquitetura e velocidade de transmissão.
DESPERDÍCIO
Um vídeo popular será possivelmente enviado muitas vezes pelos mesmos enlaces de
comunicação. Isso não apenas é um desperdício de largura de banda de rede, mas a própria
empresa de streaming pagará ao seu ISP por enviar os mesmos bytes pela internet muitas e
muitas vezes.
DISPONIBILIDADE
Um único datacenter representa um único ponto de falha — se o datacenter ou seu enlace para
a internet cair, ele não será capaz de distribuir nenhum vídeo de fluxo de dados.
Por isso, foi desenvolvido um novo conceito: Redes de distribuição de conteúdo CDNs.
javascript:void(0)
As CDNs, ilustradas na figura a seguir, invertem a ideia do Proxy, pois, em vez de deixar uma
cópia do conteúdo em um cache ligado ao cliente, elas a colocam no lado servidor, em um nó
de rede que esteja próximo ao cliente, minimizando o tráfego pela internet e os eventuais
atrasos decorrentes.
Imagem: TANENBAUM, 2011, p. 467.
 Árvore de distribuição CDN.
O servidor de origem da CDN envia cópias do conteúdo para outros nós (servidores) da rede
(linhas tracejadas), e os clientes vão buscar o conteúdo nos servidores mais próximos de sua
localização (linhas sólidas).
Na figura Árvore de distribuição CDN, podemos ver que os clientes de Sidney requisitam o
conteúdo ao servidor do nó de Sidney, sendo que o equivalente ocorre com os outros nós, e
nenhum deles faz requisição direta ao nó de origem.
Como se pode notar, a estrutura de uma CDN corresponde a uma árvore, trazendo as
seguintes vantagens:
A expansão da distribuição é muito fácil, já que, quando ocorre o aumento da quantidade de
requisições, basta acrescentar mais nós ou mais níveis na árvore, o que permite eliminar algum
eventual gargalo na rede.
O servidor de origem nunca fica sobrecarregado, já que se comunica apenas com os nós da
própria CDN, sem nunca atender às requisições dos clientes finais.
O tempo de resposta para os clientes é muito baixo, pois a busca das páginas ocorre em um
servidor próximo e não em um distante. Isso porque o estabelecimento da conexão TCP é mais
rápido, devido ao menor tempo de comunicação.
A partida lenta do TCP sobe mais rapidamente devido ao tempo de ida e volta mais curto, e o
caminho de rede mais curto terá menos chance de passar por regiões de congestionamento na
internet.
A carga total sobre a rede também é mantida no mínimo, devido ao bom posicionamento dos
nós das CDNs, acarretandoque o tráfego para determinada página deverá passar por cada
parte da rede apenas uma vez.
Uma CDN pode pertencer ao próprio provedor de conteúdo, como a do Google, que faz a
distribuição dos vídeos do YouTube, denominada CDN privada; ou ser uma CDN de terceiros,
que faz a distribuição de provedores de conteúdo que não pertencem à empresa, como é o
caso das CDNs da Akamai e da Limelight.
AKAMAI E DA LIMELIGHT
A Akamai e a Limelight são líderes em serviços CDN (Rede de Entrega de Conteúdo)
para entrega de mídia e software.
Para a instalação de seus clusters de servidores, as CDN podem utilizar duas filosofias
diferentes:
CLUSTERS DE SERVIDORES
Cluster é a denominação que se dá a um sistema onde dois ou mais computadores
atuam como se fossem uma única máquina dividindo as atividades a serem realizadas.
Cada máquina no cluster é denominada nodo.
ENTER DEEP
BRING HOME
javascript:void(0)
javascript:void(0)
ENTER DEEP
Utilizada pela Akamai, tem como ideia entrar profundamente nas redes de acesso dos ISP,
implantando cluster CDN na rede dos provedores pelo mundo todo. O objetivo é ficar próximo
do cliente final, minimizando o atraso percebido pelo cliente e diminuindo a quantidade de
enlaces e roteadores entre o nó da CDN e o usuário.
BRING HOME
Adotada pela Limelight, a ideia aqui é trazer os ISPs para dentro da rede da CDN, construindo
enormes clusters, mas em quantidades bem menores do que na Enter Deep, em lugares-chave
e conectando-os em uma rede privada de alta velocidade.
Quando uma empresa, que não possui uma CDN privada, deseja disponibilizar seu conteúdo
aos clientes, ela entra em contato com a Akamai, por exemplo, e firma um contrato para que
ela realize a entrega.
Com o contrato assinado e ativo, o proprietário entrega o conteúdo à CDN, que é enviado aos
nós da CDN. Além disso, o proprietário reescreve quaisquer páginas web que se vinculam ao
conteúdo para que o conteúdo não seja mais vinculado ao seu site, mas sim à URL da CDN.
Observe a figura a seguir. Na parte (a), podemos notar que a referência aos vídeos MPG era
para o próprio site de Fluffy Vídeo; já na parte (b) a referência é para uma URL na empresa de
CDN.
Imagem: TANENBAUM, 2011, p. 469.
 Página web original (a) e reescrita para vincular a CDN (b).
OPERAÇÃO DA CDN
Para acessar a CDN, o cliente deve enviar sua requisição para um de seus nós. Mas como
fazemos para que ela haja dessa forma? Uma primeira ideia seria utilizar os servidores Proxy
para realizar essa tarefa.
Se na figura Árvore de distribuição CDN os clientes de Sidney forem configurados para
utilizar o nó de Sidney da CDN, como um Proxy web, a distribuição funcionaria corretamente.
Porém, essa estratégia não é boa na prática devido a dois fatores:
Os clientes normalmente são de diferentes organizações, cada uma utilizando o seu próprio
servidor proxy.
Um cliente pode precisar acessar várias CDNs diferentes, mas cada um deles somente pode
estar associado a um proxy.
Para poder lidar de forma eficiente com essa situação, a Akamai iniciou, em 1998, o uso do
DNS, mais especificamente o Redirecionamento de DNS para indicar a qual nó CDN a
requisição deve ser direcionada.
A ideia é que, quando o cliente deseja acessar um vídeo, por exemplo, o browser utilize o DNS
para definir o IP do servidor de nome que responde pela URL desejada e, depois, o acessa
para descobrir o IP para o qual deve ser encaminhada a requisição.
 PERGUNTA
Até aí tudo funciona como sempre foi, mas o que muda no redirecionamento?
O servidor de nome é executado pela CDN, e, em vez de retornar sempre o mesmo IP para
cada solicitação, ele pesquisará o IP do cliente que fez a solicitação e retornará respostas
diferentes dependendo da localização do usuário. Na realidade, ele retornará o IP que esteja
na menor distância, do ponto de vista da rede, do solicitante.
Vejamos um exemplo de funcionamento do método de redirecionamento de DNS extraído de
KUROSE (2014). Suponha que um provedor de conteúdo, NetCinema, utiliza outra companhia
de CDN, KingCDN, para distribuir seus vídeos para seus consumidores.
Nas páginas de internet do NetCinema, cada vídeo está associado a uma URL que inclui a
palavra “vídeo” e um identificador único para o vídeo em si, por exemplo
http://video.netcinema.com/6Y7B23V.
O funcionamento ocorre então em seis passos, ilustrados na figura a seguir:
Imagem: KUROSE, 2014, p. 446.
 Redirecionamento de DNS.
1
O usuário visita a página da internet no NetCinema.
Quando o usuário clica no link de um vídeo, seu browser envia uma consulta de DNS para
video.netcinema.com.
2
3
O Servidor de DNS local (LDNS) do usuário retransmite a consulta de DNS a um servidor DNS
autoritativo pelo NetCinema, que, ao encontrar a palavra vídeo na URL, em vez de retornar o
IP do servidor, retorna um nome de domínio da KingCDN, por exemplo, a1105. kingcdn.com.
A partir de então, todo o tratamento do DNS será realizado pela CDN de KingCDN. Quando o
LDNS envia a consulta solicitando o vídeo, ele é redirecionado para um dos nós da CDN; isso
é feito retornando o IP do servidor que esteja mais próximo do cliente.
4
5
O LDNS encaminha o endereço IP do nó de conteúdo/serviço da CDN para o hospedeiro do
usuário.
Obtido o IP do servidor, o cliente estabelece uma conexão TCP e envia uma requisição HTTP
para obter o vídeo. Se o servidor utilizar DASH, ele inicialmente envia um metafile com uma
lista de URLs, uma para cada versão do vídeo, e o cliente irá dinamicamente selecionar
trechos das diferentes versões.
6
ESTRATÉGIAS DE SELEÇÃO DE CLUSTER
Uma questão complexa que se origina do redirecionamento de DNS é como encontrar o nó da
CDN mais próximo; para isso, dois fatores devem ser levados em consideração:
DISTÂNCIA DA REDE
O cliente deverá ter um caminho de rede curto e de alta capacidade para o nó da CDN,
permitindo downloads rápidos.
CARGA DA REDE EM TRANSPORTE PELO NÓ DA CDN
Se os nós da CDN estiverem sobrecarregados, eles entregarão respostas lentamente, assim
como o servidor web sobrecarregado que buscamos evitar em primeiro lugar.
Com esses dois fatores em mente, vamos ver algumas estratégias que podem ser utilizadas na
determinação do cluster.
PROXIMIDADE GEOGRÁFICA
Uma solução simples seria associar o cliente ao cluster geograficamente mais próximo; para
isso, a CDN, utilizando bases de dados de geolocalização, ao receber a consulta DNS, faz o
levantamento da geolocalização do endereço IP do LDNS do solicitante e retorna o IP do
cluster mais próximo geograficamente, ou seja, o que está a uma menor distância em
quilômetros do usuário requisitante.
Apesar de funcionar relativamente bem, para alguns usuários essa solução pode ter um
desempenho ruim, uma vez que a distância geográfica pode não corresponder à menor
distância de rede.
Outro elemento a se considerar aqui é que muitos clientes usam LDNS remotos como, por
exemplo, o do Google (8.8.8.8), o que pode tornar a localização do LDNS distante
geograficamente do solicitante.
Um último aspecto é que essa abordagem ignora totalmente a carga da rede e do cluster
solicitado.
AVALIAR A CARGA DA REDE
Para fazer essa análise, a CDN inicialmente encaminha a solicitação a um de seus servidores
utilizando, por exemplo, a proximidade geográfica.
A seguir, ela passa a monitorar o tráfego mais recente entre o cliente e o servidor visando a
determinar suas características. Para isso, ela pode estimar o atraso examinando o intervalo
entre a troca de mensagens SYN/ACK do servidor para o cliente e o ACK do cliente para o
servidor durante o estabelecimento da conexão TCP.
Essa solução possui como desvantagem a necessidade de exigir o redirecionamento dos
clientes para outros servidores, nem sempre os melhores, para analisar o atraso para esses
novos nós.
ANALISAR O TRÁFEGO DNS
Em vez de analisar o atraso da conexão TCP, essa abordagem visa a verificar o atraso nas
consultas DNS emitida pelo LDNS do cliente para um servidor DNS da CDN.
As consultas do LDNSpodem ser direcionadas para servidores de autorização da CDN em
várias localizações de cluster diferentes, produzindo um tráfego de DNS que pode então ser
medido entre o LDNS e tais localizações. Nesse método, os servidores de DNS continuam a
retornar o cluster ideal para o cliente, de modo que a entrega de vídeos e outros objetos da
internet não seja afetada.
IP DE QUALQUER MEMBRO DO GRUPO
A ideia por detrás do IP de qualquer membro do Grupo é colocar os roteadores de borda da
internet na rota dos pacotes do cliente para o cluster “mais próximo”, utilizando o protocolo de
roteamento BGP (Border Gateway Protocol).
Para isso, o provedor de CDN age da seguinte forma, como exemplificado na figura a seguir:
Imagem: KUROSE, 2014, p. 449.
 Utilizando Anycast IP para determinar o cluster.
Durante o estágio de configuração, é feita a associação do mesmo endereço IP, utilizando
o endereço anycast, por exemplo, a cada um dos seus clusters, e utiliza o BGP para
informar esse endereço IP de cada uma das diferentes localizações de clusters;
Como um roteador BGP, ao receber vários anúncios de rotas para o mesmo IP, os trata
como caminhos diferentes para a mesma localização física (apesar de no caso
corresponderem a clusters diferentes), ele selecionará a rota de menor custo de acordo
com as políticas estabelecidas pela CDN;
Após a configuração inicial, a CDN pode distribuir o conteúdo pelos clusters.
Nessa abordagem, quando o LDNS faz uma consulta, o DNS da CDN retorna o endereço para
qualquer membro do grupo, independentemente da localização física do cliente. A seguir,
quando o cliente manda a requisição HTTP para o IP retornado, ele é roteado para o cluster
“mais próximo”, conforme determinado pelas tabelas de repasse pré-configuradas pelo BGP.
Essa abordagem faz com que a requisição seja encaminhada ao cluster mais próximo do
cliente, e não ao mais próximo de seu LDNS, mas tampouco leva em consideração as
variações de carga da rede.
FATORES ADICIONAIS DE SELEÇÃO
Além das considerações de rede, como atraso, carga e largura de banda, outros fatores
adicionais são importantes:
CARGA DOS CLUSTERS
Se um clusters estiver sobrecarregado, os clientes não devem ser redirecionados para ele.
CUSTO DE DISTRIBUIÇÃO
Cada ISP possui um custo específico de distribuição; isso deve ser levado em conta pela CDN
que pode direcionar o tráfego para o ISP, que, por contrato, fornece-lhe uma opção de menor
custo.
javascript:void(0)
javascript:void(0)
REDES DE DISTRIBUIÇÃO DE CONTEÚDO
No vídeo a seguir, você entenderá o conceito de redes de distribuição de conteúdo e sua
importância no serviço de multimídia de vídeo armazenado.
VERIFICANDO O APRENDIZADO
1. NO PROCESSO DE SELEÇÃO DE CLUSTER DE UMA CDN, VÁRIOS
ASPECTOS SÃO OBSERVADOS. A RESPEITO DESSE FATO, PODEMOS
AFIRMAR QUE:
I - A PROXIMIDADE GEOGRÁFICA ENTRE O CLIENTE E SERVIDOR É UM
FATOR DETERMINANTE, POIS SEMPRE CORRESPONDE À MENOR
DISTÂNCIA DE REDE
II - NEM SEMPRE O CLUSTER COM A MENOR DISTÂNCIA DE REDE DO
CLIENTE É SELECIONADO, POIS TAMBÉM É LEVADA EM
CONSIDERAÇÃO A CARGA DA REDE E DO CLUSTER PROPRIAMENTE
DITO.
III - DURANTE A FASE DE CONSULTA DO DNS PELO CLIENTE, O
TRÁFEGO PODE SER ANALISADO PARA DETERMINAR QUAL SERVIDOR
DEVE ATENDER À SOLICITAÇÃO.
ESTÁ CORRETO O QUE SE AFIRMA EM:
A) I apenas
B) II apenas
C) III apenas
D) I e II apenas
E) II e III apenas
2. AS CDNS POSSUEM UMA ESTRUTURA EM ÁRVORE EM QUE TEMOS
NA RAIZ UM SERVIDOR DE ORIGEM E NAS FOLHAS OS CLUSTERS QUE
RECEBEM A REPLICAÇÃO DO CONTEÚDO E ATENDEM DIRETAMENTE
AOS USUÁRIOS.
A RESPEITO DAS VANTAGENS DESSA ESTRUTURA EM ÁRVORE, TEMOS
QUE:
I - A EXPANSÃO DA DISTRIBUIÇÃO É MUITO FÁCIL, JÁ QUE, QUANDO
OCORRE O AUMENTO DE REQUISIÇÕES, BASTA ACRESCENTAR MAIS
NÓS NA ÁRVORE
II - A PARTIDA LENTA DO TCP SOBE MAIS RAPIDAMENTE DEVIDO AO
TEMPO DE IDA E VOLTA MAIS CURTO
III - A CARGA TOTAL SOBRE A REDE TAMBÉM É MANTIDA NO MÍNIMO
DEVIDO AO BOM POSICIONAMENTO DOS NÓS DAS CDNS
IV - O TEMPO DE RESPOSTA PARA OS CLIENTES É MUITO BOM, POIS A
BUSCA DAS PÁGINAS OCORRE EM UM SERVIDOR PRÓXIMO E NÃO EM
UM DISTANTE.
ESTÁ CORRETO O QUE SE AFIRMA EM:
A) I, II e III apenas
B) II, III e IV apenas
C) I, II e IV apenas
D) I, III e IV apenas
E) I, II, III e IV
GABARITO
1. No processo de seleção de cluster de uma CDN, vários aspectos são observados. A
respeito desse fato, podemos afirmar que:
I - A proximidade Geográfica entre o cliente e servidor é um fator determinante, pois
sempre corresponde à menor distância de rede
II - Nem sempre o cluster com a menor distância de rede do cliente é selecionado, pois
também é levada em consideração a carga da rede e do cluster propriamente dito.
III - Durante a fase de consulta do DNS pelo cliente, o tráfego pode ser analisado para
determinar qual servidor deve atender à solicitação.
Está correto o que se afirma em:
A alternativa "E " está correta.
Analisando as afirmativas, temos que:
I – Errada, pois a distância de rede não tem obrigatoriamente relação com a distância
geográfica.
II – A alternativa está correta e corresponde aos aspectos análise de carga e análise de rede do
processo de seleção.
III – A alternativa está correta e corresponde à análise de tráfego DNS do processo de seleção.
2. As CDNs possuem uma estrutura em árvore em que temos na raiz um servidor de
origem e nas folhas os clusters que recebem a replicação do conteúdo e atendem
diretamente aos usuários.
A respeito das vantagens dessa estrutura em árvore, temos que:
I - A expansão da distribuição é muito fácil, já que, quando ocorre o aumento de
requisições, basta acrescentar mais nós na árvore
II - A partida lenta do TCP sobe mais rapidamente devido ao tempo de ida e volta mais
curto
III - A carga total sobre a rede também é mantida no mínimo devido ao bom
posicionamento dos nós das CDNs
IV - O tempo de resposta para os clientes é muito bom, pois a busca das páginas ocorre
em um servidor próximo e não em um distante.
Está correto o que se afirma em:
A alternativa "E " está correta.
Todas as afirmativas correspondem a vantagens conhecidas do uso de uma estrutura em
árvore para a CDN, como facilidade de expansão e tempo de resposta baixo para os clientes,
bem como permite a partida lenta do TCP subir mais rapidamente e distribuir a carga da rede
em vários locais, mantendo um bom desempenho do serviço.
MÓDULO 3
 Descrever casos reais de empresas que utilizam Fluxo Contínuo de Vídeo
Armazenado.
NETFLIX
Primeiramente, vamos conhecer um pouco sobre a história da empresa e as mudanças em seu
modelo de negócio:
Foto: James Duncan Davidson / Wikimedia Commons / CC BY 2.0 à esquerda; Foto: Gage
Skidmore/ Wikimedia Commons / CC BY-SA 3.0 à direita.
A Netflix foi fundada em 1997 por Reed Hastings (à esquerda) e Marc Randolph (à direita)
como uma videolocadora tendo, em 1998, passado a ofertar um serviço de venda e aluguel de
DVDs com envio pelos correios a partir de pedidos feitos em seu site.
Imagem:Shutterstock.com
Em 1999, a Netflix lança o serviço de assinatura que permite o aluguel de DVDs ilimitados sem
data de devolução, multa por atraso ou limite mensal.
Imagem:Shutterstock.com
Seguindo a evolução tecnológica, em 2007 é introduzido o streaming de vídeo, permitindo aos
assinantes acessarem filmes e séries de forma imediata pela internet, dando início ao seu atual
modelo de negócios, permitindo o acesso a milhares de títulos 24 horas por dia por meio de
computadores, videogames, tablets, smartphones e smartTVs.
Imagem:Shutterstock.com
Além de distribuir conteúdo de terceiros, desde 2013 a Netflix se tornou uma produtora de
conteúdo, e ganhou o Oscar de melhor filme estrangeiro com Roma, além de vários outros
prêmios da indústria de entretenimento.
A Netflix atualmente está presente em mais de 190 países, em 21 idiomas com mais de 200
milhões de assinantes, sendo considerada a maior empresa de entretenimento, em valor de
mercado, do mundo.
Quando começou o seu serviço de streaming, a Netflix mantinha uma infraestruturade
datacenter própria para atender suas necessidades de processamento. Em agosto de 2008,
entretanto, o banco de dados da empresa foi corrompido, o que causou a paralisação de suas
atividades por três dias.
Diante dessa situação, e devido ao grande crescimento na base de assinantes, associado à
necessidade de processamento, a empresa resolveu migrar para a nuvem da Amazon Web
Services (AWS).
A migração foi um processo longo, concluído apenas em 2015. Durante o processo, a empresa
fez uma reengenharia em seus sistemas, visando adequá-los à nova filosofia de uso da nuvem
e mantendo apenas uma pequena parte do processamento em seu datacenter.
A figura a seguir mostra a arquitetura do sistema da Netflix.
Imagem: KUROSE, 2014, p. 449.
 Arquitetura do Serviço da Netflix.
Na figura, podemos observar que existem quatro componentes principais:
OS SERVIDORES DE REGISTRO E PAGAMENTO
A NUVEM DA AWS
A REDE DE ENTREGA DE CONTEÚDO
OS CLIENTES
OS SERVIDORES DE REGISTRO E PAGAMENTO
Mantidos em sua infraestrutura interna, permitem o registro de novas contas e capturam
informações de pagamento por cartão de crédito.
A NUVEM DA AWS
Responsável por atender as necessidades de processamento e armazenamento escaláveis, a
lógica de negócios, bancos de dados distribuídos e processamento / análise de big data,
recomendações, transcodificação e centenas de outras funções.
A REDE DE ENTREGA DE CONTEÚDO
Responsável pela entrega dos vídeos. Nos anos iniciais de funcionamento do streaming eram
utilizadas CDN de terceiros, no caso as da Akamai, Limelight e Level-3. Em 2012, a Netflix
lançou o programa Open Connect visando criar um CDN privado que atendesse às suas
necessidades. Esse programa foi um sucesso, e atualmente a Open Connect entrega todo o
conteúdo da Netflix.
OS CLIENTES
Computadores, smartphones e demais meios de acesso a conteúdo da plataforma.
A NUVEM DA AMAZON (AWS)
Todo o sistema da Netflix na AWS é implementado com o uso de máquinas virtuais que
fornecem as seguintes funcionalidades:
OBTENÇÃO DE CONTEÚDO
PROCESSAMENTO DE CONTEÚDO
DESCARREGAMENTO DE VERSÕES PARA A CDN
OBTENÇÃO DE CONTEÚDO
Quando a Netflix recebe as versões principais do filme ou séries dos estúdios, faz a
armazenagem em host da AWS.
PROCESSAMENTO DE CONTEÚDO
Para entregar da forma mais eficiente e adaptável à largura de banda do cliente, a Netflix,
utilizando os recursos de processamento da nuvem, cria diversas versões do vídeo, adaptadas
aos variados players de mídia (celular, TV, computador etc.). Além da criação de uma versão
para cada formato, também são geradas versões com diferentes taxas de vídeo para permitir o
uso do HTTP de vídeo de fluxo contínuo com DASH.
DESCARREGAMENTO DE VERSÕES PARA A CDN
Uma vez que todas as versões de um filme foram criadas, os hospedeiros na nuvem da
Amazon descarregam as versões para a CDN Open Connect.
ENTREGA DE CONTEÚDO
Para a entrega de filmes a seus consumidores, a Netflix faz uso extensivo da CDN. Quando o
cliente navega pela biblioteca de vídeos da Netflix, as páginas são fornecidas pelos servidores
da AWS.
Quando o usuário envia a requisição HTTP solicitando um vídeo, ele recebe da AWS o metafile
com a descrição das versões disponíveis do vídeo e suas URLs, utilizadas pelo DASH. Além
disso, o cliente também recebe uma lista ordenada dos clusters da CDN, em que o conteúdo
está disponível.
Foto: Shutterstock.com
 Consumidor escolhendo filme em catálogo.
 DICA
A ordenação da lista dos clusters da CDN é estabelecida pela Netflix e pode mudar de uma
sessão de fluxo para outra em função da carga da rede ou do cluster.
Após ser selecionado o cluster, normalmente o primeiro da lista, é estabelecida uma sessão
TCP entre o cliente e o servidor, que interagem usando DASH, inclusive com a utilização de
informações nos cabeçalhos das mensagens de requisição HTTP para requisitar trechos das
diferentes versões do filme.
Por padrão, a Netflix usa trechos de cerca de 4s. Enquanto os trechos vão sendo baixados, o
cliente mede a vazão recebida e executa um algoritmo para determinação da taxa, a fim de
definir a qualidade do próximo trecho que será requisitado.
OPEN CONNECT
A Open Connect é a CDN privada da Netflix, sendo responsável por 100% do tráfego de
visualização, que corresponde a mais de 125 milhões de horas por dia (dados de 2016),
significando dezenas de terabits por segundo em horários de pico.
O desenvolvimento da Open Connect, visando substituir as CDNs de terceiros utilizadas até
então, começou em 2012 devido a dois motivos:
O crescimento da Netflix como empresa de streaming fez com que ela passasse a responder
por uma parte significativa do tráfego dos ISPs, tornando importante uma aproximação visando
melhorar a qualidade de serviço.
A criação de uma solução de entrega personalizada permitiu projetar um gerenciamento de
cache nos nós da CDN mais eficiente do que a solução padrão empregada na CDN de
terceiros.
A Open Connect é composta de vários nós (na verdade, milhares), em que são colocados os
Open Connect Appliances (OCAs), dispositivos especialmente desenvolvidos para armazenar
os arquivos de vídeo codificados e entregá-los aos clientes via HTTP/HTTPS.
Os OCAs possuem uma capacidade de armazenamento de aproximadamente 288TB, com
uma taxa de transferência de até 90Gbps, e formam uma rede global implantada de duas
maneiras:
Imagem: Heloise Godinho
Em um dos datacenters da Netflix (existem cerca de 60 no mundo), denominados pontos de
troca (referidos como IXs OU IXPs) nos mercados mais importantes. Estes OCAs são então
interligados ao ISP por meio de peering.
Imagem: Heloise Godinho
Incorporados ao datacenter de um ISP. Essa solução é adotada quando o ISP possui um
grande volume de tráfego da Netflix e mostra interesse em ter uma OCA. Nesse caso, o
equipamento é oferecido gratuitamente, enquanto o ISP fornece o espaço, a energia e a
conectividade.
 VOCÊ SABIA
Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo
em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o
relacionamento seja mutuamente benéfico.
Um dos tipos de peering é o SFI (Settlement-Free Interconnect) quando nenhuma das partes
paga a outra pela troca de tráfego.
A Open Connect possui atualmente cerca de mil pontos ao redor do mundo, tanto em
metrópoles como Paris ou Londres quanto em pontos remotos como a Groelândia, e até
mesmo em cidades da Amazônia, como Manaus e Macapá.
Essa distribuição geográfica faz com que a maioria dos assinantes receba seu conteúdo de um
servidor que está dentro ou diretamente conectado ao seu provedor de acesso.
FUNCIONAMENTO DA OPEN CONNECT
Como explicado, todo o processamento realizado antes de o usuário solicitar o vídeo é
processado na AWS. Após o usuário clicar em assistir, tudo acontece na Open Connect.
Os arquivos de vídeo que compõem o catálogo da Netflix são massivos, então é de
fundamental importância definir o melhor local para os armazenar dentro da CDN.
A Netflix possui sofisticados algoritmos de popularidade que permitem determinar que o arquivo
esteja no provedor correto, na hora necessária. Esses avançados algoritmos compartilham
algumas abordagens, e, por vezes, entradas em comum, com os sistemas de recomendação
de conteúdo líderes do mercado.
Esse pré-posicionamento do conteúdo permite que seja minimizado o uso do núcleo da
internet.
Por exemplo, considere a Austrália. Todo conteúdo que se deseja acessar na internet e que
não esteja hospedado localmente é acessado por meio de cabos submarinos.
Então, ao invés de utilizar esse caro meio de transmissão para levar o conteúdo a um cliente, e
transmitir novamente quando outro cliente solicitar o mesmo filme, é realizada a cópia, uma
única vez, do centro de transcodificação norte-americano para o centro de armazenamento na
Austrália, como ilustrado na figura a seguir. Essa cópia é realizada fora dos horários de pico
visando a diminuir o custo ea competição com outros tipos de tráfego.
Após a cópia ser realizada, ela é replicada para dezenas de servidores existentes por todo o
país, dentro da rede dos ISP na Austrália.
Imagem: Heloise Godinho
 Funcionamento do pré-posicionamento.
Em resumo, o funcionamento do sistema da Netflix pode ser explicado da seguinte forma:
1
As OCAs relatam periodicamente a saúde, as rotas que aprenderam e o conteúdo (arquivo)
disponível para os serviços de controle de cache na AWS.
Um usuário em um dispositivo cliente solicita a reprodução de um título (programa de TV ou
filme) do Aplicativo Netflix na AWS.
2
3
Os serviços de aplicativo de reprodução na AWS verificam a autorização do usuário e, em
seguida, determinam quais arquivos específicos são necessários para lidar com a
reprodução/solicitação, tomando as características individuais do cliente e as condições atuais
da rede.
O serviço de direção na AWS usa as informações armazenadas pelo controle de cache para
escolher OCAs a partir dos quais os arquivos solicitados devem ser servidos, gera URLs para
esses OCAs, e passa os URLs para o aplicativo de reprodução.
4
5
O aplicativo de reprodução solicita conteúdo ao OCA apropriado.
O OCA começa a servir os arquivos solicitados.
6
Esse processo está ilustrado na figura a seguir.
Imagem: Heloise Godinho
 Funcionamento da Open Connect
YOUTUBE
O YouTube é o maior site de compartilhamento de vídeo da internet e um dos sites mais
visitados do mundo. Fundado por Chad Hurley, Steven Chen e Jawed Karim, todos
funcionários à época do PayPal, entrou no ar às 21h13 de 14 de fevereiro de 2005. O primeiro
vídeo foi carregado em 23 de abril do mesmo ano, uma produção feita por um dos
cofundadores denominada Me at the zoo.
Imagem: photobyphotoboy / Shutterstock.com
 Usuário escolhendo vídeo
 COMENTÁRIO
Esse vídeo, feito por Jawed Karim, realizado no Zoológico de San Diego, tem 18 segundos de
duração, com comentários a respeito das trombas dos elefantes:
"Tudo bem, então aqui estamos na frente dos elefantes, e o legal desses caras é que eles têm
trombas muito, muito, muito grandes, e isso é legal e é tudo o que há para dizer."
O vídeo foi postado com o nome de usuário "jawed".
Em seu primeiro ano de funcionamento, o YouTube atingiu 2 milhões de visualizações por dia,
com 200 mil usuários registrados. Esse desempenho chamou a atenção do Google, que o
adquiriu por US$1,65 bilhão em outubro de 2016, unificando-o com o seu próprio serviço, o
Google Filmes, tendo mantido a equipe original e o site sendo operado praticamente de forma
independente até os dias atuais.
O YouTube atualmente está disponível em mais de 100 países e tem suporte a 80 idiomas,
possuindo mais de 2 bilhões de usuários mensais (números do final de 2020).
Segundo uma estimativa da Cisco, o consumo de vídeo, no qual o YouTube é líder, deverá
ocupar 82% do tráfego da internet em 2021.
Atualmente, o YouTube possui bilhões de vídeos, cujo consumo atinge mais de um bilhão de
horas de conteúdo diariamente, sendo que a cada minuto cerca de 500 horas de novos
conteúdos são adicionados.
Cerca de 70% do conteúdo é consumido via celulares, o que confirma a tendência de
crescimento desse tipo de acesso a conteúdo da internet, de um modo geral, sendo previsto
que em 2022 ele atingirá mais de 77 exabytes por mês. Devido à enorme demanda por seus
conteúdos, o YouTube faz uso da tecnologia de CDN para entrega; mais especificamente, da
CDN privada do Google.
INFRAESTRUTURA DE REDES DO GOOGLE
Para dar suporte a seus diversos serviço, o Google implementou uma rede privada de
infraestrutura de CDN dividida em três camadas de clusters de servidores:
MEGA DATACENTERS
CLUSTERS BRING HOME
CLUSTERS ENTER DEEP
MEGA DATACENTERS
Oito “mega datacenters”, sendo seis localizados nos Estados Unidos e dois na Europa, cada
um com cerca de 100 mil servidores responsáveis por servir conteúdo dinâmico (e muitas
vezes personalizado), incluindo resultados de busca e mensagens de correio por meio do
Gmail.
CLUSTERS BRING HOME
30 clusters bring home com até 500 servidores distribuídos ao redor do mundo e próximos a
múltiplos pontos de presença de ISP camada 1, que se responsabilizam pela distribuição de
conteúdo estático, incluindo vídeos do YouTube.
CLUSTERS ENTER DEEP
Várias centenas de clusters enter deep localizados dentro dos ISPs, de acesso composto, cada
um com dezenas de servidores em um único gabinete. Os servidores enter deep realizam a
divisão de TCP e servem conteúdo estático, incluindo as partes estáticas das páginas de
resultados de busca.
DIVISÃO DE TCP
Divisão de TCP é uma técnica para diminuir o RTT a partir da instalação de servidores de
front end perto dos usuários, que mantém a conexão TCP e estabelece outra conexão
TCP persistente entre o servidor e o datacenter, com uma janela de congestionamento
TCP muito grande.
Toda essa estrutura está disposta em uma rede privada, fazendo parte de um grande Sistema
Autônomo, sem passar pela internet pública.
Quando um usuário envia uma requisição de vídeo, ela é, inicialmente, direcionada para um
servidor enter deep, que prove as partes da página web ao redor do vídeo, enquanto o vídeo é
entregue por um dos servidores bring home e os anúncios chegam dos datacenters.
ENTREGA DE VÍDEO DO YOUTUBE
A escolha do cluster para entrega do vídeo é feita da seguinte forma:
Para fazer a entrega de seus vídeos, o Google utiliza o Redirecionamento de DNS, enviando a
requisição do usuário para um cluster específico.

javascript:void(0)
De um modo geral, é selecionado o cluster para o qual o RTT entre ele e o cliente seja menor;
porém, a fim de balancear a carga através dos clusters, algumas vezes o cliente é direcionado
a um cluster mais distante.

Se o cluster que recebe a requisição não possui o vídeo solicitado, ele retorna mensagem de
redirecionamento para o cliente, indicando um novo cluster para o qual a requisição deve ser
enviada.
O YouTube utiliza HTTP de fluxo contínuo e pode disponibilizar uma pequena quantidade de
versões diferentes do mesmo vídeo, com taxa de bits distintas e com diferentes níveis de
qualidade. Entretanto, não utiliza DASH, e requer que o cliente faça a seleção manual da
versão desejada. O YouTube faz uso também da requisição HTTP de intervalo de bytes, de
modo a limitar o fluxo de dados transmitidos após uma quantidade do vídeo ter sido obtida pela
pré-busca.
NETFLIX E YOUTUBE
No vídeo a seguir, você verá mais detalhes sobre a estrutura e os recursos que são utilizados
pelo Netflix e YouTube.
VERIFICANDO O APRENDIZADO
1. A INFRAESTRUTURA COMPUTACIONAL DA NETFLIX POSSUI TRÊS
GRANDES COMPONENTES:
• DATACENTER INTERNO
• AWS
• OPEN CONNECT
CADA UM DELES REALIZA OPERAÇÕES ESPECÍFICAS. O DATACENTER
INTERNO TEM, ENTRE SUAS OPERAÇÕES:
A) Realizar o redirecionamento de DNS
B) Criar as diversas versões de um vídeo
C) Entregar o conteúdo para o usuário
D) Registrar novas contas de usuário
E) Armazenar o conteúdo original recebido dos estúdios
2. A INFRAESTRUTURA DE REDES DO GOOGLE, QUE ATENDE AO
YOUTUBE, BEM COMO A OUTROS SERVIÇOS OFERTADOS AO PÚBLICO,
É COMPOSTA DE VÁRIOS COMPONENTES, CADA UM REALIZANDO
DIVERSAS TAREFAS. O COMPONENTE RESPONSÁVEL PELA DIVISÃO
TCP DENOMINA-SE:
A) Datacenter
B) OCAs
C) Cluster Enter Deep
D) Cluster de distribuição
E) Clusters bring home
GABARITO
1. A infraestrutura computacional da Netflix possui três grandes componentes:
• Datacenter interno
• AWS
• Open Connect
Cada um deles realiza operações específicas. O datacenter interno tem, entre suas
operações:
A alternativa "D " está correta.
Analisando as alternativas, temos que:
a - O redirecionamento é realizado pela AWS
b – A criação das diversas versões é realizada pela AWS
c – A entrega do conteúdo é realizada pela Open Connect
d – O registro de novas contas ocorre no servidor de registro e pagamento que fica no
datacenter interno
e- O conteúdo original enviado pelos estúdios é armazenado na AWS
2.A infraestrutura de redes do Google, que atende ao YouTube, bem como a outros
serviços ofertados ao público, é composta de vários componentes, cada um realizando
diversas tarefas. O componente responsável pela divisão TCP denomina-se:
A alternativa "C " está correta.
A divisão do TCP é realizada criando-se uma conexão persistente entre o cluster enter deep
localizado no ISP e o datacenter, visando a reduzir o RTT total.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Ao longo deste conteúdo, pudemos estudar o que é e como funciona o Vídeo de Fluxo
Contínuo Armazenado. Começamos vendo as características desse tipo de fluxo e o uso dos
Protocolos UDP e HTTP.
Em seguida, estudamos as Redes de Distribuição de Conteúdo (CDN), como elas se
originaram, sua estrutura e funcionamento, incluindo como elas selecionam o cluster mais
adequado para atender à requisição de um usuário.
Finalmente, vimos dois casos reais de empresas que trabalham como provedores de conteúdo
de vídeo, o YouTube e a Netflix.
Nesses estudos de caso, vimos que ambas utilizam CDN privadas – a do Google, no caso do
YouTube, e o Open Connect, no caso da Netflix; pudemos então verificar a estrutura interna de
cada uma e como elas operam.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
COMER, D.E. Interligação Redes com TCP/IP. Elsevier, 6. ed., 2015.
FOROUZAN, B. Comunicação de dados e redes de computadores. 4. ed. São Paulo:
McGraw-Hill, 2008.
KUROSE, J.; ROSS, K. Redes de computadores e a Internet: uma abordagem top-down.
Pearson Education, 6. ed., 2014.
TANENBAUM, A. Redes de Computadores. 5.ed., Rio de Janeiro: Campus, 2011.
EXPLORE+
Faça uma pesquisa na internet a respeito dos protocolos RTP e RSTP, buscando informações
sobre suas aplicações e como funcionam.
Para entender o funcionamento e distribuição das OCAs, acesse o documento Open Connect
Netflix, disponível no site Open Connect Netflix.
CONTEUDISTA
Sidney Nicolau Venturi Filho
 CURRÍCULO LATTES
javascript:void(0);