Protocolos de Multimídia

Prévia do material em texto

Redes de Computadores 
Protocolos de transmissão de multimídia com e sem tempo real:
QUIC, RTP e RTSP
Prof.: Diego Silva Caldeira Rocha
Introdução
• As redes multimídia representam a integração de tecnologias de 
comunicação que permitem a transmissão e o processamento de 
conteúdos multimídia, como áudio, vídeo, imagens e texto, por meio 
de redes de computadores.
Introdução
Multimídia em Tempo Real - Essa categoria envolve aplicações onde o 
tempo é crítico: os dados precisam ser entregues e processados quase 
instantaneamente para manter a qualidade e a usabilidade. Exemplos 
incluem:
• Chamadas de vídeo e áudio (VoIP): Como no Zoom ou WhatsApp.
• Transmissões ao vivo: Eventos esportivos ou shows em plataformas como 
YouTube Live ou Twitch.
• Jogos online multiplayer: Onde ações em tempo real, como em Fortnite ou 
League of Legends.
Introdução
Multimídia Sem Tempo Real - o tempo não é um fator crítico; os dados 
podem ser entregues com atrasos toleráveis, priorizando a integridade 
e a qualidade final em vez da velocidade Isso permite buffering
(armazenamento temporário) e retransmissões para corrigir erros. 
Exemplos incluem:
• Streaming de vídeo sob demanda: Como Netflix ou YouTube (vídeos 
gravados), onde o usuário pode pausar e o sistema pré-carrega o 
conteúdo.
• Download de arquivos multimídia: Músicas no Spotify ou imagens em 
sites, onde a transmissão pode ser interrompida e retomada.
Real-Time Protocol (RTP) - Protocolo de 
tempo real
• O RTP comumente roda sobre UDP.
Real-Time Protocol (RTP)
• Exemplo RTP:
• considere o envio de voz codificada em PCM de 64 kbps sobre RTP.
• aplicação coleta os dados codificados em pedaços, ex., a cada 20 
mseg = 160 bytes num pedaço.
• o pedaço de áudio junto com o cabeçalho RTP formam um pacote 
RTP, que é encapsulado num segmento UDP
Cabeçalho RTP
• Os quatro principais campos de cabeçalho do pacote RTP são:
• Tipos de carga útil de códigos suportados pelo RTP(7 bits): Ex: 0 PCM 
- 64 kbps, 26 - Motion JPEG, 31 - H.261 e 33 - vídeo MPEG2.
• número de sequência (16 bits): incrementa para cada pacote RTP 
enviado e pode ser usado para detectar perda de pacote e restaurar 
sequência de pacote.
Cabeçalho RTP
• Os quatro principais campos de cabeçalho do pacote RTP são:
• Marca de tempo (32 bits): instante de amostragem do primeiro byte 
neste pacote de dados RTP.
• Identificador de sincronização da fonte (32 bits): identifica origem da 
corrente de RTP . Cada corrente na sessão RTP deverá ter SSRC 
distinto.
Protocolo de Controle de Tempo Real
(Real-Time Control Protocol - RTCP)
• trabalha em conjunto com o RTP.
• cada participante numa sessão RTP periodicamente transmite
• pacotes de controle RTCP para todos os demais participantes.
• cada pacote RTCP contém relatos do transmissor e/ou receptor
• relatam estatísticas úteis para as aplicações : no. Pacotes enviados, 
no. pacotes perdidos, intervalo entre chegadas (jitter), etc.
• a realimentação de informação pode ser usada para controlar o 
desempenho o transmissor pode modificar as suas transmissões com 
base na realimentação
Real-Time Control Protocol - RTCP
Real-Time Control Protocol - RTCP
Pacotes RTCP:
• Pacotes de relato do receptor:
• fração dos pacotes perdidos, último número de sequência, jitter médio entre 
chegadas
• Pacotes de relato do transmissor:
• SSRC do fluxo RTP, tempo atual, número de pacotes enviados e número de 
bytes enviados.
• Pacotes de descrição da origem:
• endereço de e-mail do transmissor, nome do transmissor, o SSRC do fluxo RTP 
associado.
• os pacotes provêm um mapeamento entre o SSRC e o nome do usuário/host.
Real-Time Control Protocol - RTCP
• Sincronização de Fluxos:
• o RTCP pode ser usado para sincronizar diferentes fluxos de mídia dentro de 
uma sessão RTP.
• considere uma aplicação de videoconferência para a qual cada transmissor 
gera um fluxo RTP para vídeo e outro para áudio.
• as marcas de tempo nestes pacotes RTP estão vinculados aos relógios de 
amostragem de vídeo e de áudio não estão vinculadas ao relógio de tempo 
real.
• cada relatório RTCP do transmissor contém, para o pacote gerado mais 
recentemente no fluxo RTP associado, a marca de tempo do pacote RTP e o 
tempo de relógio físico em que o pacote foi criado.
• os receptores pode usar esta associação para sincronizar a reprodução de 
áudio e de vídeo.
RTSP – RealTime Streaming Protocol
• RFC 2326
• protocolo cliente-servidor da camada de aplicação.
• usuário pode controlar a reprodução: retorno, avanço rápido, pausa, 
retomada, reposicionamento, etc.
RTSP – RealTime Streaming Protocol
• O que ele não faz:
• não define como o áudio/vídeo é encapsulado para ser transmitido pela rede
• não restringe como a mídia tipo fluxo contínuo é transportada; pode ser 
transportada sobre UDP ou TCP
• não especifica como o media player utiliza buffers para áudio/vídeo 
RTSP – RealTime Streaming Protocol
• O FTP usa um canal de controle “fora de banda”:
• um arquivo é transferido sobre uma conexão TCP.
• a informação de controle (mudanças de diretório, remoção de arquivo, 
renomeação de arquivo, etc.) é enviada numa conexão TCP à parte
• os canais “fora de banda” e “dentro da banda” utilizam diferentes números de 
portas 
• Mensagens RTSP também são enviadas fora de banda:
• as mensagens de controle RTSP usam números de porta diferentes do fluxo 
contínuo da mídia, e são, portanto, enviadas fora de banda (Porta 554)
• o fluxo de mídia é considerado “dentro da banda”. 
RTSP – Estudo de caso
• Exemplo RTSP:
• Cenário:
• meta arquivo enviado para o browser web
• browser inicia o media player
• media player estabelece uma conexão de controle RTSP e uma conexão de 
dados para o servidor de mídia contínua
RTSP – Estudo de caso
Exemplo de Meta-arquivo:
Twister 
 
 
 
 
 
 
 
 
 
RTSP – Estudo de caso
RTSP – Exemplo de troca de mensagem
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 
Transport: rtp/udp; compression; port = 3056; mode = PLAY 
S: RTSP/1.0 200 1 OK 
Session 4231 
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 
Session: 4231 
Range: npt = 0
S: RTSP/1.0 200 2 OK 
Session 4231
RTSP – Exemplo de troca de mensagem
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 
Session: 4231 
Range: npt = 37 
S: RTSP/1.0 200 3 OK 
Session 4231 
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 
Session: 4231 
S: 200 4 OK
QUIC: Quick UDP Internet Connections –
Conexões Rápidas de Internet UDP
• O protocolo QUIC (Quick UDP Internet Connections) foi inicialmente
proposto pela Google com o objetivo de melhorar a experiência do
usuário na navegação web, reduzindo latências e corrigindo
limitações dos protocolos tradicionais, como TCP + TLS.
• Ao utilizar o UDP como camada base, o QUIC permite a integração
direta de mecanismos essenciais — criptografia, multiplexação de
fluxos e controle de congestionamento — dentro de um único
protocolo de transporte.
• Em junho de 2022 é apresentada a especificação oficial do protocolo
no RFC 9114 ficando completa a separação do protocolo de
transporte QUIC e a camada HTTP.
QUIC: Arquitetura
• Diferentemente do TCP, que é implementado no kernel do sistema
operacional, o QUIC é implementado no espaço do usuário,
facilitando atualizações e permitindo rápida evolução do protocolo.
QUIC: Quick UDP Internet Connections
• Redução de RTT (Round Trip Time) no estabelecimento da 
conexãoTCP + TLS tradicional exige 2 RTTs para estabelecer uma 
conexão segura.
• QUIC integra TLS 1.3 ao próprio protocolo, exigindo apenas 1 RTT 
para a primeira conexão.• Em cenários em que cliente e servidor já trocaram chaves 
anteriormente, é possível conexão 0-RTT, permitindo envio imediato 
de dados.
QUIC: Estabelecimento de conexão
QUIC: Estabelecimento de conexão
QUIC: Estabelecimento de conexão
Benefício multimídia:
• Início instantâneo de streaming
• Reconexões rápidas após perda de sinal
• Ideal para mobile e redes instáveis
QUIC e o Problema do HOL (Head-Of-Line 
Blocking)
• O HOL ocorre no TCP porque todos os pacotes precisam chegar em 
ordem, bloqueando fluxos independentes caso um pacote seja 
perdido.
• QUIC, com sua multiplexação de fluxos sobre UDP, permite que: A 
perda de um pacote em um fluxo não bloqueie os demais.
• Diferentes streams sejam entregues independentemente. Isso corrige 
a limitação observada no HTTP/2, que mesmo com múltiplas streams, 
ainda dependia do TCP.
QUIC: fluxos: paralelismo, sem bloqueio de
cabeça de fila (HOL)
QUIC: sem bloqueio de cabeça de fila (HOL)
Somente o fluxo afetado atrasa.
Isso significa:
• Vídeo continua fluindo mesmo que um pacote de outro objeto seja 
perdido
• Navegação mais fluida
• Maior resiliência em redes instáveis (Wi-Fi, 4G/5G) 
QUIC: multiplexação por Fluxos: Adequado 
para objetos multimídia
• QUIC possui múltiplos fluxos independentes dentro de uma mesma 
conexão.
• Cada fluxo entrega dados de forma confiável, ordenada e 
independente
• Impacto para multimídia
Em uma página ou aplicativo multimídia existem vários objetos:
Vídeo, Trilhas de áudio, Legendas e Sinalização/controle.
QUIC: multiplexação por Fluxos: Adequado 
para objetos multimídia
• Em aplicações multimídia, atrasos por pacotes bloqueados são 
extremamente prejudiciais.
QUIC: Controle de congestionamento 
otimizado
• QUIC usa TCP NewReno como base, porém roda no espaço do usuário 
e é atualizável sem mexer no kernel do SO.
• Impacto para multimídia: 
• Adaptabilidade mais rápida às variações da rede
• Melhor uso de 4G/5G, onde congestionamento muda rapidamente
• Streaming mais estável mesmo com flutuações de sinal
• Vídeo adaptativo (ABR) funciona melhor porque QUIC reage rápido
Real-Time Protocol (RTP) - Protocolo de 
Tempo Real
• O RTP especifica uma estrutura de pacote que transportam dados de 
áudio e de vídeo
• RFC 3550
• pacote RTP provê
• identificação do tipo da carga
• numeração da sequência de pacotes
• marca de tempo
Referências
Kurose, J. F., & Ross, K. W. (2021). Redes de Computadores e a Internet: Uma Abordagem
Top-Down. Pearson.
Langley, Adam et al. QUIC Transport Protocol: Design and Internet-Scale Deployment. In:
ACM SPECIAL INTEREST GROUP ON DATA COMMUNICATION - SIGCOMM'17, 2017, Los Angeles, CA,
USA. Anais... Los Angeles, CA, USA: ACM, 2017. p. 21-25.