ResumosTesteV2

Prévia do material em texto

Resumos ESR
Eduardo Silva
January 2022
Conteúdo
1 Camada de Aplicação 3
1.1 Prinćıpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Criação de uma aplicação de rede . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Arquitetura Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Arquitetura P2P: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Serviço de transporte necessário numa aplicação . . . . . . . . . . . . . . . . . . . 4
1.1.7 Protocolos de transporte: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Aplicações P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Distribuição de ficheiros: Cliente-Servidor vs P2P . . . . . . . . . . . . . . . . . . 5
1.3 Streaming de v́ıdeo e Redes de Distribuição de Conteúdo (CDNs) . . . . . . . . . . . . . 6
1.3.1 Multimedia: Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Cenário simples: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 DASH : Dynamic, Adaptive Streaming over HTTP . . . . . . . . . . . . . . . . . 7
1.3.4 CDN - Content Distribuition Networks . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Multimedia Networking 8
2.1 Aplicações de Multimedia Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Streaming de v́ıdeo armazenado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Voice Over IP - VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Caracteŕısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Perda de pacotes, atrasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Atraso de playout fixo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.4 Atraso de playout adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.5 Recuperação após uma perda de pacote . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.6 Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.7 P2P VoIP : Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.8 Peers como retransmissores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Protocolos para a aplicações conversacionais: RTP , SIP . . . . . . . . . . . . . . . . . . 14
2.4.1 Real-Time Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Real-Time Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.3 RTCP: Stream synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4 RTCP: Bandwidth Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.5 Serviços SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.6 SIP Registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1
3 Internet Transport Protocols 18
3.1 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4 Pacotes SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.5 4-way handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.6 Multistreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.7 Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Multicast 23
4.1 Multicast Group Membership Discovery Protocols . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Alternativas de design: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Opt-In (PIM SM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Opt-Out (PIM DM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Source-based Trees Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Shared Tree Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
1 Camada de Aplicação
1.1 Prinćıpios
Alguns exemplos de aplicações:
• E-mail;
• Web;
• Mensagens de texto;
• Partilha de ficheiros P2P;
• Jogos multi utilizadores em rede;
• etc...
1.1.1 Criação de uma aplicação de rede
Escrever programas que:
• Corram em (diferentes) sistemas finais;
• Comuniquem através da rede;
• ex: Servidor Web que comunica com um browser.
Não há necessidade de escrever software para dispositivos com núcleo de rede (network-core) uma vez
que estes não executam aplicações do utilizador e aplicações em sistemas finais (end systems) permitem
um rápido desenvolvimento e propagação.
1.1.2 Arquitetura Cliente-Servidor
Servidor:
• Está sempre ligado;
• Possui um endereço IP permanente;
• Utiliza centros de dados (data centers) para escalabilidade.
Cliente:
• Comunica com o servidor;
• Pode estar conectado de forma intermitente;
• Pode ter um IP dinâmico;
• Não comunica diretamente com outros clientes.
3
1.1.3 Arquitetura P2P:
• O servidor não está sempre ligado;
• Existem sistemas finais arbitrários que comunicam de forma direta;
• Peers pedem serviço a outros peers, e da mesma forma prestam serviço a outros peers.
Esta caracteŕıstica torna posśıvel uma autoescalabilidade, uma vez que novos peers trazem consigo
uma melhor capacidade de serviço, assim como uma maior procura.
• Os peers estão conectados de forma intermitente, e o seu IP altera.
1.1.4 Processos
Processo: Programa que corre num host.
• No mesmo host, 2 processos comunicam através de IPC - inter-process communication, definido pelo
SO.
• Processos em hosts diferentes comunicam através da troca de mensagens.
Clientes, Servidores:
• Processo de Cliente: Processo que inicia a comunicação.
• Processo de Servidor: Processo que espera que seja contactado.
Uma aplicação com uma arquitetura P2P utiliza os dois tipos de processos, cliente e servidor.
1.1.5 Sockets
Um processo envia e recebe mensagens através do seu socket e cada processo tem um identificador.
Cada host possui um IP único de 32 bits. Mas este IP não é suficiente para identiificar o processo,
uma vez que podem correr vários processos no mesmo host. Dáı que o identificador tenha, para além do
IP do host, o número da porta associada ao processo.
Exemplo:
• Endereço IP: 128.119.245.12
• Porta: 80
1.1.6 Serviço de transporte necessário numa aplicação
•Integridade de Dados:
Há aplicações que precisam de uma fiabilidade de 100% na transferência de dados. Outras, (por
exemplo aúdio), toleram alguma perda.
•Timing:
Jogos interativos, ou chamadas pela internet necessitam de um atraso curto, de forma a serem
“eficaz”.
•Throughput ou Rendimento:
Multimedia, por exemplo, precisa de um ńıvel mı́nimo de throughput de forma a ser “eficaz”. Por
outro lado, existem aplicações (“elastic apps”), que faz uso de qualquer throughput que consigam.
•Segurança:
Encriptação, etc...
4
1.1.7 Protocolos de transporte:
TCP:
• Transporte fiável entre o processo de envio e de receção;
• Controlo de fluxo: o remetente não sobrecarregará o destinatário;
• Controlo de congestão: Regula o remetente em função da sobrecarga na rede.
• Não garante timing, um throughput mı́nimo nem segurança;
• Orientado à conexão.
UDP:• Transporte não fiável entre o envio e a receção do processo;
1.2 Aplicações P2P
1.2.1 Distribuição de ficheiros: Cliente-Servidor vs P2P
Cliente-Servidor:
Transmissão do servidor: Envia de forma sequencial N cópias do ficheiro.
• Tempo para enviar uma cópia: F
us
• Tempo para enviar N cópias: N ×
F
us
Cliente: Cada cliente precisa de fazer download do ficheiro.
• dmin é a taxa de download mı́nimo do cliente.
• Tempo mı́nimo de download: F
dmin
P2P:
Transmissão do servidor: Tem de fazer upload de pelo menos uma cópia do ficheiro.
• Tempo para enviar uma cópia: F
us
Cliente: Cada cliente precisa de fazer download do ficheiro.
• dmin é a taxa de download mı́nimo do cliente.
• Tempo mı́nimo de download: F
dmin
Clientes: Em conjunto têm de fazer download de N × F bits.
• Taxa de upload máximo: us +P ui. (well, esse P devia ser o śımbolo normal de somatório lmao)
5
Como é posśıvel ver, a arquitetura P2P, para um número de maior de N, torna-se bastante mais
rápida, comprovando também a autoescalabilidade.
1.3 Streaming de v́ıdeo e Redes de Distribuição de Conteúdo (CDNs)
1.3.1 Multimedia: Video
•Video é uma sequência de imagens apresentadas a uma taxa constante, p.e 24 imagens/segundo;
•Imagem digital: array de pixeis, onde cada pixel é representado por bits.
•Usar redundância dentro e entre imagens, de forma a diminuir o número de bits usados na sua
codificação.
Espacial: (dentro da imagem). Em vez de mandar N valores da mesma cor (por exemplo roxo),
enviar os seguintes valores: cor (roxo) e o número de vezes que se repete (N).
Temporal: (de uma imagem para outra). Em vez de mandar o frame completo i+1, enviar
apenas as diferenças desse frame para o frame i.
CBR: (constant bit rate). Taxa de codificação de v́ıdeo fixa.
VBR: (variable bit rate). A taxa de codificação altera consoante a alteração na codificação
temporal e espacial.
1.3.2 Cenário simples:
Principais desafios:
• A largura de banda do servidor varia ao longo do tempo, com as alterações da rede ao ńıvel do
congestionamento:
• Perda de pacotes, o atraso devido ao congestionamento atrasará a reprodução ou resultará num
v́ıdeo com má qualidade.
6
1.3.3 DASH : Dynamic, Adaptive Streaming over HTTP
Servidor:
• Divide o ficheiro em várias partes (chunks);
• Cada chunk está codificado com vários rates;
• manifest file: fornece URLs para diferentes chunks.
Cliente:
• Mede periodicamente a largura de banda do servidor para o cliente;
• Consulta o manifest file, e solicita um chunk de cada vez;
• Escolhe. a taxa máxima de codificação sustentável, a partir da largura de banda atual;
• Pode escolher taxas diferentes de codificação, em diferentes pontos no tempo (dependendo da
largura de banda dispońıvel no momento).
A “inteligência” está na parte do Cliente, uma vez que é este que:
• Determina quando fazer um pedido de um chunk (de modo a que não ocorra buffer starvation
ou overflow);
• Qual a taxa de codificação a pedir (maior qualidade quando a largura de banda é maior);
• Onde pedir o chunk. Pode pedir a um servidor que lhe esteja perto, ou que a sua largura de
banda seja maior.
1.3.4 CDN - Content Distribuition Networks
Problema: Como transmitir conteúdo (selecionado de milhões de v́ıdeos) a centenas de milhares
de utilizadores em simultâneo?
Opção 1: Um servidor único, “mega-server”
• Ponto único de falha;
• Ponto de congestionamento da rede;
• Longo caminho para clientes que estejam distantes do servidor;
• Várias cópias dos v́ıdeos enviadas pelo link de sáıda.
Conclusão: Esta solução não é escalável.
Opção 2: Armazenar várias cópias dos v́ıdeos em vários CDN, distribúıdos geograficamente.
• enter deep: posicionar os servidores CDN “profundamente”, em muitos acessos de rede:
– Mais próximo dos utilizadores;
– Tentativa de single hop.
• bring home: número menor (10) de clusters maiores em POPs próximos (mas não dentro) de
redes de acesso.
7
2 Multimedia Networking
2.1 Aplicações de Multimedia Networking
Existem 3 tipos de aplicações:
Streaming armazenado áudio, v́ıdeo:
• Streaming: pode começar a correr antes de fazer download do ficheiro inteiro;
• Armazenado (em servidor): Pode transmitir mais rápido do que o processamento de áudio ou
v́ıdeo. Implica um armazenamento num buffer no cliente.
• Ex: YouTube, Netflix, etc.
Voice/video over IP:
• Natureza interativa da conversa entre humanos. Existe um limite para a tolerância de atraso.
• Ex: Skype, Zoom, Viber, etc.
Streaming de áudio ou v́ıdeo ao vivo:
• Ex: evento desportivo ao vivo.
2.2 Streaming de v́ıdeo armazenado
Restrição na transmissão cont́ınua: Assim que o cliente comece a transmissão, a reprodução deve
corresponder ao tempo original. Mas, os atrasos na redes são variáveis (jitter), por isso é necessário
buffer no lado do cliente, para igualar os requisitos da reprodução.
Outros desafios:
•Interactividade do Cliente (pausa, avanço, retrocesso, etc);
•Os pacotes de v́ıdeo podem ser perdidos ou retransmitidos.
O buffer no lado do cliente, e o atraso na trasmissão compensam o atraso que possa ocorrer
na rede.
8
1. Preenchimento inicial do buffer, até que comece a reprodução;
2. A reprodução começa;
3. O ńıvel do buffer varia ao longo do tempo, uma vez que a taxa a que este enche varia, e a taxa
de reprodução é constante.
2.3 Voice Over IP - VoIP
Requisito de atraso final de VoIP: Necessário para manter o aspeto “conversacional”.
• Maiores atrasos são percet́ıveis, prejudicando a interatividade.
– 300 mseg: mau.
• Inclúı o ńıvel aplicacional (packetização, playout), atrasos de rede.
Inicialização da sessão: Como é que o callee anuncia o IP, endereço, número de porta, algoritmos
de codificação?
Serviços de valor agregado: Encaminhamento de chamadas, redirecionamento, gravação, etc.
2.3.1 Caracteŕısticas
• Áudio do altifalante: alternação entre peŕıodos de conversas, com peŕıodos de silêncio;
– 64 kbps durante os peŕıodos de conversa;
– só se geram pacotes durante os peŕıodos de conversa;
– pedaços de 20 msec a 8kbytes/sec: 160 bytes de dados.
• A cada pacote é adicionado o cabeçalho da camada de aplicação;
• Chunk + header são encapsulados em UDP (ou num segmento TCP);
• A aplicação envia o segmento para o socket a cada 20 ms, durante os peŕıodos de conversa.
2.3.2 Perda de pacotes, atrasos
• Recall, por padrão: IP forcene um serviço de melhor esforço (best-effort);
• Perda de rede: O datagrama IP perdido devido ao congestionamento da rede;
• Perda de atraso: O datagrama IP chega tarde demais para a reprodução no recetor;
– Atrasos: processamento, queueing na rede, atrasos do sistema final (end-system) (emissor
ou recetor);
– Um pacote atraso é um pacote perdido;
– Atraso máximo tolerável t́ıpico: 300ms.
• Tolerância a perdas: Dependendo da codificação da voz e da ocultação de perda, perdas numa
taxa de 1% a 10% podem ser toleradas.
2.3.3 Atraso de playout fixo
O recetor tenta reproduzir cada bloco exatamente q ms após a sua geração, ou seja, o chuck tem
um time stamp t, que irá ser reproduzido em t+q.
Neste caso, se o chunk chega depois do peŕıodo t+q ao destinatário, significa que chegaram tarde
para o playout, logo é perdido.
9
• Tradeoff na escolha de q:
– Se o q for grande, menos packets serão perdidos;
– Mas se o q for pequeno, há uma melhor experiência interativa.
2.3.4 Atraso de playout adaptativo
Objetivo: Baixo atraso de playout, e baixa taxa de perda tardia.
• Abordagem:
– Estimar o atraso da rede, ajustar o atraso de playout no ińıcio de cada ińıcio de conversa;
– Peŕıodos de silêncio comprimidos e alongados;
– Chunks ainda tocados a cada 20 ms durante o peŕıodo de fala.
• Estimar de forma adaptativa o atraso do pacote (EWMA - Exponentially Weighted Moving
Range, Média Móvel Exponencialmente Ponderada. Estimativa TCP RTT):
• Também é útil para estimar o desviomédio de atraso, vi:
• Estimativas vi e di calculadas para cada pacotes recebido, mas usado apenas no ińıcio do peŕıodo
de conversa.
• Para o primeiro pacote no peŕıodo de conversa, o tempo de playout é:
• Os pacotes restantes no peŕıodo de conversa são reproduzidos periodicamente.
10
Questão: Como é que o recetor determina se o pacote é o primeiro num peŕıodo de conversa?
• Se não houver perda, o recetor olha para os timestamps sucessivos:
– Se a diferença de timestamps sucessivos for maior que 20 ms, o peŕıodo de fala começa.
• Com a possibilidade de perda, o recetor olha tanto para os timestamps como para os números
de sequência:
– Se a diferença de timestamps sucessivos for maior que 20 ms, e os números de sequência
não tiverem intervalos então o peŕıodo de fala começa.
2.3.5 Recuperação após uma perda de pacote
• Cada ACK/NAK demora aprox. um RTT;
• Alternativa: Forward Error Correction (FEC):
– Enviar bits suficientes para permitir a recuperação sem retransmissão.
Simple FEC:
• Para cada grupo de N chunks, criar um chunk redundante por Ou Exclusivo dos N chunks
originais;
• Enviar N+1 chunks, aumentando a largura de banda pelo factor 1
N ;
• Pode reconstruir os N chunks originais se, no máximo se perdeu 1 chunk dos N+1 enviados com
atraso de playout.
Outro esquema FEC:
• “Piggyback lower quality stream”
• Enviar fluxo de áudio de resolução inferior como informação redundante;
• por exemplo, fluxo nominal PCM a 64 kbps e fluxo redundante GSM a 13 kbps;
• Perda não consecutiva: o recetor pode ocultar a perda;
• Generalização: Também pode anexar (n-1)st e (n-2)nd bloco de low-bit rate.
11
Intercalação para ocultar a perda:
• Blocos de áudio divididos em unidades menores, por exemplo 4 unidades de 5 ms por bloco de
áudio de 20 ms;
• Cada pacote fica com pequenas unidades de diferentes blocos;
• Se o pacote for perdido, ainda terá a maior parte de cada pedaço original;
• Sem sobrecarga de redundância, mas aumenta o atraso de playout.
2.3.6 Skype
• Protocolo de camada aplicacional proprietário (inferido através de engenharia reversa);
– Mensagens encriptadas;
• Componentes P2P:
– Clientes: (SCs) Os peers conectam-se diretamente entre si para chamadas VoIP;
– Super nós (SN): São peers com funções especiais;
– Rede Overlay: entre SNs para localizar SCs;
– Servidor de login.
12
2.3.7 P2P VoIP : Skype
Operação de um cliente Skype:
1. Entra na rede Skype, contactando o SN (endereço IP em cache) através de TCP;
2. Faz login (username e pw) no servidor centralizado de login do Skype;
3. Obtém o endereço IP para o recetor de SN, rede SN overlay;
• Ou a lista de amigos desse cliente.
4. Inicia a chamada diretamente para o recetor.
2.3.8 Peers como retransmissores
• Problema: A Alice e o Bob estão por trás de NATs.
– NAT impede que o peer externo inicie uma conexão com o peer interno.
– O peer interno pode iniciar uma conexão com o peer externo.
• Solução de retransmissão: Tanto a Alice como o Bob mantêm uma conexão aberta com os
seus SNs.
– A Alice sinaliza ao seu SN para se contectar com o Bob;
– O SN da Alice conecta-se ao SN do Bob;
– O SN do Bob conecta-se ao Bob através de uma conexão aberta que o Bob iniciou, inicial-
mente, com o seu SN.
13
2.4 Protocolos para a aplicações conversacionais: RTP , SIP
2.4.1 Real-Time Protocol (RTP)
RTP especifica a estrutura de pacotes que transportam dados de áudio e v́ıdeo.
O pacote RTP fornece:
• Identificação do tipo de payload;
• Numeração de sequência de pacotes;
• Timestamp.
RTP é executado em sistemas finais (endsystems) e os seus pacotes são encapsulados em UDP.
Interoperabilidade: Se duas aplicações VoIP utilizam RTP, podem trabalhar juntos.
• RTP não fornece nenhum mecanismo para garantir a entrega oportuna de dados ou outras
garantias de QoS (quality of service);
• O encapsulamento RTP apenas é visto em sistemas finais (ou seja, não em routers intermédios)
• Routers fornecem o serviço de best-effort, sem fazer nenhum esforço especial para garantir que
os pacotes RTP cheguem ao destino em tempo hábil.
2.4.2 Real-Time Control Protocol (RTCP)
Trabalha em conjunto com RTP;
• Cada participante na sessão RTP envia periodicamente pacotes de controlo RTCP para todos
os outros participantes;
• Cada pacote RTCP. contém relatórios de emissor e/ou recetor;
– Estat́ısticas de úteis para a aplicação: #Pacotes enviados, #Pacotes perdidos e Instabili-
dade entre chegadas;
• Feedback é usado para controlar o desempenho:
– O remetente pode modificar as suas transmissões com base no feedback do relatório.
•Cada sessão RTP normalmente possui um único endereço multicast. Todos os pacotes RTP/RTCP
que pertençam a essa sessão usam um endereço multicast.
•Pacotes RTP/RTCP são diferenciados entre si através de um número de porta distinto;
•De forma a limitar o tráfego, cada participante reduz o tráfego RTCP conforme o número de
participantes na conferência aumenta.
14
2.4.3 RTCP: Stream synchronization
RTCP consegue sincronizar diferentes streams de media numa sessão RTP.
Por exemplo, numa v́ıdeo conferência, cada remetente gera um fluxo RTP para v́ıdeo, e outro
para áudio. Existe também um timestamp no pacote RTP associado ao v́ıdeo, e um sampling clock
no aúdio.
Cada relatório RTCP de remetente possúı (para o mais recente pacote gerado pela stream RTP)
o seguinte:
• Um timestamp do pacote RTP;
• Um Wall-Clock que indica a o tempo de criação do pacote.
Os recetores utilizam associação para sincronizar a reprodução de v́ıdeo e áudio.
2.4.4 RTCP: Bandwidth Scaling
RTCP tenta limitar o tráfego a 5% da largura de banda da sessão.
Exemplo: Um remetente a enviar tráfego a 2 Mbps.
• RTCP tenta limitar o tráfego RTCP a 100 Kbps;
• RTCP dá 75% do tráfego a recetores, e os 25% restantes para o remetente;
– Os 75 kbps são igualmente partilhados entre os recetores, ou seja, cada recetor vai receber
tráfego a 75
#R kbps.
• O remetente envia tráfego a 25 kbps.
• O participante determina o peŕıodo de transmissão do pacote RTCP, calculando o tamanho
médio do pacote (em toda a sessão) e dividindo pela taxa alocada.
2.4.5 Serviços SIP
O SIP (protocolo de Ińıcio de Sessão) fornece mecanismos para a configuração de chamada da
seguinte forma:
• Para que o chamador avise o recetor que deseja estabelecer uma chamada;
• Para que o chamador e o recetor concordem com o tipo de codificação de media;
• Para terminar a chamada.
Para determinar o IP atual do recetor, há um mapeamento do identificador mnemónico para o
endereço IP atual.
Relativamente à gestão de chamadas, é posśıvel:
• Adicionar novos fluxos de media durante a chamada;
• Alterar a codificação durante a chamada;
• Convidar outros participantes;
• Transferir ou reter chamadas.
15
• A mensagem de convite SIP da Alice indica o seu número da porta, o endereço IP e a codificação
que ela prefere receber;
• A mensagem (com sinal 200) do Bob indica o seu número de porta, o seu endereço IP e a sua
codificação preferida;
• As mensagem SIP podem ser enviados por TCP ou UDP. Neste exemplo foi usado RTP/UDP;
• O número de porta SIP default é 5060.
Negociação de codificação:
•Supondo que o Bob não tinha a codificação que a Alice lhe enviou, este responde com o sinal
606-Not Acceptable Reply, listando todos os seus codificadores. A Alice pode então enviar uma nova
mensagem INVITE, com um codificador diferente.
Rejeitar uma chamada:
•O Bob pode rejeitar com as seguintes respostas: ”Busy”, ”Gone”, ”Payment Required”ou ”For-
bidden”.
Media pode ser enviado pelo protocolo RTP ou outro qualquer.
2.4.6 SIP Registrar
Uma função do servidor SIP: Registar
•Quando o Bob inicia o cliente SIP, o cliente envia uma mensagem SIP REGISTER para o
servidor de registro de Bob.
Este servidor (de registro de Bob) mantém registado o seu IP atual. Sempre que Bob muda para
num novo dispositivo SIP, o novodispositivo envia uma nova mensagem de registo, com o novo IP. Para
além disso, se o Bob se mantiver no mesmo dispositivo por um peŕıodo de tempo longo, o dispositivo
envia mensagens de atualização de registo, a indicar que o endereço de IP mais recente ainda é válido.
Importante notar que o servidor de registo é análogo a um servidor DNS: o servidor DNS converte
hostnames fixos em endereços de IP fixos e o servidor de registo SIP traduz identificadores humanos
fixos (por exemplo bob@domain.com) em endereços IP dinâmicos.
16
Passos SIP:
•Jim@umass.edu − > 217.123.56.89;
•keith@upenn.edu − > 197.87.54.21.
1. Jim envia uma mensagem INVITE para o proxy SIP umass;
2. O proxy faz uma pesquisa DNS no SIP register upenn.edu (não mostrado no diagrama) e então
encaminha a mensagem para o servidor register;
3. Como keith@upenn.edu não está registado no SIP register upenn, este envia uma resposta de
redirecionamento, indicando que deve tentar keith@nyu.edu;
4. O proxy umass envia uma mensagem INVITE ao SIP register nyu;
5. O register nyu conhece o IP keith@upenn e encaminha a mensagem INVITE para o host
197.87.54.21, que está a executar o cliente Keith;
6, 7, 8. Uma resposta SIP é enviada de volta, por meio de registers / proxies ao cliente SIP em 217.123.56.89;
9. A media é enviada diretamente entre os dois clientes.
Outro exemplo:
17
3 Internet Transport Protocols
3.1 SCTP
3.1.1 Motivação
•Fiabilidade, mas sem ordenação:
TCP proporciona tanto uma transferência de dados fiável como uma ordem estrita de transmissão
de dados. Algumas aplicações precisam da fiabilidade mas sem manutenção de sequência, enquanto
que outras ficariam satisfeitas com a ordenação parcial dos dados. Em ambos os casos, o bloqueio
head-of-line causado pelo TCP causa atrasos desnecessários.
•Fiabilidade, mas sem orientação para fluxo (stream-oriented):
A natureza stream-oriented do TCP é muitas vezes um inconveniente. Aplicações devem adicionar
a sua própria record para delimitar as suas mensagens, e devem fazer uso expĺıcito do recurso push
para garantir que uma mensagem completa seja transferida num tempo razoável.
•Mais escalabilidade e redundância (multihoming):
O alcance limitado de sockets TCP complica a tarefa de fornecer capacidade de transferência de
dados altamente dispońıvel utilizando hosts multi-homed.
•Mais robustez (para ataques):
TCP é relativamente vulnerável a ataques de denial-of-service (DOS), tais como SYN flood attacks.
3.1.2 Introdução
Tal como o TCP, o SCTP (Stream Control Transmission Protocol) fornece transferências fiáveis,
full-duplex e unicast. Por outro lado, ao contrário do TCP e do UDP, oferece novas opções de entrega
que são particularmente desejáveis para a sinalização telefónica e para aplicações de multi media.
O SCTP mantém retransmissões fiáveis do tipo TCP, controlo de congestão, orientação à conexão
e ainda:
• Framing: Preserva os limites das mensagens;
• 4-way handshake: reduz a vulnerabilidade a ataques Dos;
• Multi streaming: Até 64k de fluxos ordenados independentes;
• Multihoming: em vez de um único endereço IP por endpoint, possui um conjunto de endereços
IP. Utiliza multihoming para redundância, e não para equilibrio de carga!
18
A combinação de uma porta SCTP e um endereço IP define um ”Endereço de Transporte SCTP”.
•Um endpoint SCTP é um fim lógico do transporte do protocolo SCTP: uma parte que comunica;
•Pode ter mais do que um endereço IP, mas sempre associado a uma única porta.
Exemplo: endpoint = [10.1.4.2, 10.1.5.3 : 80]
•A comunicação entre 2 endpoints, é chamada associação.
3.1.3 Framing
Uma mensagem de uma aplicação é mantida como um ou mais pedaços (chunks) de dados;
O objetivo é aumentar o desempenho, através da remoção do bloqueio nos dados recebidos, quer
por atraso ou por perda.
Ao permitir a entrega não ordenada de pacotes, elimina o atraso HoL (head-of-line blocking).
As aplicações poderão querer unidades de dados (chunks), uma vez que ver dados como um fluxo
de bytes é ineficiente.
Neste caso, se o pacote 2 se perder, os outros pacotes podem na mesma ser tratados, pois SCTP
preserva o enquadramente do nivel aplicacional. Cada envio e cada leitura é um chunk.
19
3.1.4 Pacotes SCTP
• Cabeçalho comum:
– Portas de origem e destino, utilizadas juntamente com os endereços IPs. Outras informações
sobre o estado para identificação uma association (conexão);
– Tag de verificação, aleatória e negociada no ińıcio;
– Checksum: CRC32 sobre o pacote inteiro.
• Seguido por um mais chunks:
– Chunks são blocos de construção concatenados, que contêm informação de controlo ou de
dados;
– Um cabeçalho do bloco identifica o comprimento, tipo e outras flags especiais;
– Blocos de controlo transferem as informações necessárias para as funcionalidades de
associação e os blocos de dados carregam os dados da camada aplicacional;
– a RFC atual especifica: 14 blocos de controlo diferentes para a associação, o estabeleci-
mento, a terminação (?), ACK, recuperação de falhas de destino, ECN e comunicação de
erros.
3.1.5 4-way handshake
Maior segurança em relação a ataques DoS (Denial of service).
Como não existe nenhum ACK em resposta ao SYN-ACK, a ligação permanece semi-aberta, o que
impossibilita outros clientes (genúınos) de abrirem ligações.
Solução:
20
• O Host A envia um chunk INIT para o Host B. O Host B retorna o INIT-ACK que contém a
cookie com informação de estado que apenas o Host B pode verificar. 32 bits de flags aleatórias
de verificação; Sem alocação de memória;
• O Host A responde com um chumnk de COOKIE-ECHO. Pode conter os primeiros dados de A;
• O Host B verifica a validade da cookie e a ligação é estabelecida, respondendo com um COOKIE-
ACK.
3.1.6 Multistreaming
SCTP permite várias streams totalmente independentes por associação.
• Separação lógica de dados dentro de uma associação;
• Concebido para evitar o bloqueio Head-of-Line (HoL);
• Pode ser usada para entregar vários objetos da mesma associação, por exemplo:
– Objetos dentro de uma página web, fluxos de multimédia (áudio, v́ıdeo, texto), ficheiros
num FTP mget
21
3.1.7 Multihoming
SCTP é capaz de lidar com cenários com múltiplos endereços IP (origem e destino), p.e interfaces
wired ou wireless, múltiplos ISPs, etc...
Existe uma associação SCTP posśıvel: ({A1, A2}, {B1, B2})
• Destino “primário” selecionável;
• Novos dados são enviados apenas para o destino principal;
• O estado do caminho e a acessibilidade são monitorizas (através de heartbeats.
Objetivo: robustez, isto é:
• Mudar automaticamente os endereços de host IP em caso de falha;
• Elimina o tempo de reconvergência de routing.
SCTP monitoriza a acessibilidade de cada destino através de acks de:
• Chunks de dados;
• Chunks heartbeat.
Utiliza multihoming para redundância, e não para equiĺıbrio de carga!
22
4 Multicast
Objetivo: Enviar uma única cópia dos dados para um grupo de destinatários (identificados por
um endereço multicast).
Os routers devem encaminhar os pacotes e, quando necessário, duplicar os pacotes de dados.
Elementos de rede interessados num determinado grupo multicast:
• Aplicativos/hosts usam protocolos de descoberta de membros de grupo multicast (GMDP) (por
exemplo, IGMP para IPv4) para informar a rede sobre a disposição de receber dados (através
do envio de uma mensagem para um router multicast),
• Routers multicast comunicam entre si através de Multiple Routing Protocols:
– Protocolos de routing precisam de construir uma árvore de distribuição multicast;
– O tráfego atinge todos os destinatários que se juntaram a esse grupo;
– O número de cópias idênticas é minimizado.
4.1 Multicast Group Membership Discovery Protocols
Protocolos de Descoberta de Membros de Grupo Multicast são utilizados pelas aplicações/hosts
para informar os routers na LAN do endereçodo grupo multicast para aderir a:
• Internet Group Management Protocol (IGMP), IPv4;
• Multicast Listener Discovery, IPv6.
Operação básica do IGMP:
• O host deseja juntar-se a um novo grupo multicast: envia uma mensagem de relatório IGMP
não solicitada para esse grupo;
• Um router local capta a mensagem enviada e utiliza um protocolo de encaminhamento multicast
para se juntar ao grupo;
• Periodicamente, um router de consulta emite mensagens IGMP Query para verificar quais os
grupos cujos hosts locais estão subscritos.
• Os hosts respondem às mensagens Query: enviam um relatório IGMP que indica a sua filiação
em grupo (os grupos a que pertence);
• Se o router não receber uma mensagem Report para um determinado grupo durante um peŕıodo
de tempo, assume que não existem mais membros desse grupo na LAN, e retira-se do grupo
multicast.
Para evitar várias respostas simultâneas, cada host inicia um temporizador random para cada
grupo de que é membro. Quando o temporizador chega ao fim, envia um relatório IGMP. Se entretanto
uma mensagem for recebida para o mesmo grupo, cancela.
23
4.2 Alternativas de design:
Hosts que se juntam a um grupo multicast podem:
• Receber dados enviados para o grupo de qualquer fonte (especificar apenas o grupo multicast) -
Any Source Multicast (ASM);
• Receber apenas dados de uma fonte espećıfica (Grupo multicast e fonte) - Source-Specific
Multicast (SSM).
•Multicast Routing Protocols: um router conhece os grupos dos hosts que lhe estão liga-
dos diretamente Ð→ Troca informações com outros routers Ð→ Junta-se ou deixa árvores de grupo
multicast.
Árvores de distribuição multicast para vários destinatários:
• opt-in protocols: Os routers indicam os grupos de interesse, ou seja, aqueles que querem
receber;
• Opt-out protocols: Assume-se que os routers querem receber informação. Depois disso, os
routers eliminam-se da árvore (prune themselves).
Dois tipos de árvores:
• Source-Based Tree: Árvores separada de cada fonte, enviando dados para um grupo. Está
enraizada no router adjacente à fonte (source);
• Shared Tree: Árvore única para todas as fontes, que envia dados para o grupo. Enraizada
nalgum ponto selecionado (Rendezvous Point)- Precisa de um mecanismo para transportar
dados para as fontes.
4.3 Opt-In (PIM SM)
Os routers anunciam interesse e podem usar tanto source-based como shared trees.
24
4.4 Opt-Out (PIM DM)
Só utiliza source-based trees.
Os dados são enviados para todos os hosts na rede e são enviadas mensagens prune dos hosts que
não queiram receber aquele fluxo de dados.
25
4.5 Source-based Trees Protocols
Constrói uma árvore separada para cada fonte que envia dados:
• Cada árvore é enraizada num router adjacente à fonte;
• Routers que desejam entrar no grupo devem especificar a fonte e o grupo dos dados multicast
que gostariam de receber → Enviar uma mensagem (S,G) para o próximo router upstream.
• Vantagens:
– Os caminhos de dados multicast são eficientes.
• Desvantagens:
– Problemas de escalabilidade quando há um grande número de fontes;
– Source Specific Multicast (SSM) requer o uso de árvores source-based.
26
4.6 Shared Tree Protocols
Uma única árvore é usada por todas as fontes do grupo multicast.
Se um router pretende entrar no grupo, não precisa de especificar a fonte → envia uma mensagem
(*,G) para o próximo upstream router, com o grupo ao qual pretende entrar.
•Mecanismo para a entrega de tráfego da fonte:
Árvores de partilha unidirecionais: Cada pacote de dados é encapsulado por um router de
fonte, enviado para a ráız da árvore (por unicast) e desencapsulado (PIM-SM).
• Vantagens:
– Para um número grande de fontes, shared trees são melhores do que source-based trees.
• Desvantagens:
– Caminhos de dados ineficientes;
– Requer um mecanismo de seleção para a raiz da árvore (RP).
27
	Camada de Aplicação
	Princípios
	Criação de uma aplicação de rede
	Arquitetura Cliente-Servidor
	Arquitetura P2P:
	Processos
	Sockets
	Serviço de transporte necessário numa aplicação
	Protocolos de transporte:
	Aplicações P2P
	Distribuição de ficheiros: Cliente-Servidor vs P2P
	Streaming de vídeo e Redes de Distribuição de Conteúdo (CDNs)
	Multimedia: Video
	Cenário simples:
	DASH : Dynamic, Adaptive Streaming over HTTP
	CDN - Content Distribuition Networks
	Multimedia Networking
	Aplicações de Multimedia Networking
	Streaming de vídeo armazenado
	Voice Over IP - VoIP
	Características
	Perda de pacotes, atrasos
	Atraso de playout fixo
	Atraso de playout adaptativo
	Recuperação após uma perda de pacote
	Skype
	P2P VoIP : Skype
	Peers como retransmissores
	Protocolos para a aplicações conversacionais: RTP , SIP
	Real-Time Protocol (RTP)
	Real-Time Control Protocol (RTCP)
	RTCP: Stream synchronization
	RTCP: Bandwidth Scaling
	Serviços SIP
	SIP Registrar
	Internet Transport Protocols
	SCTP
	Motivação
	Introdução
	Framing
	Pacotes SCTP
	4-way handshake
	Multistreaming
	Multihoming
	Multicast
	Multicast Group Membership Discovery Protocols
	Alternativas de design:
	Opt-In (PIM SM)
	Opt-Out (PIM DM)
	Source-based Trees Protocols
	Shared Tree Protocols