Redes II - P2

1 DNS: Domain Name System

Protocolo que funciona sobre UDP na Porta 53, cuja função consiste em fornecer a
resolução de nomes. Ou seja, ele mapeia nomes em endereços IP (serviço de tradução).
Vale ressaltar que possui uma base de dados distribuída (nameservers).
A importância da resolução de nomes se dá do fato que utilizar nomes de endereços IP
é pouco prático e sujeito a erros, com IPv6 fica impossível pelo tamanho.
Antes de iniciar o tópico, vale ressaltar que nenhum servidor mantém os mapeamentos
nome-IP.

1.1 Breve histórico

Antes, utilizava-se o arquivo etc/[Link], que mapeava manualmente os endereços
IP e ficava localizado no sistema de arquivos local. Este foi o precursor do DNS, que
acabou sendo mais usado por sua escalabilidade (base distribuída e não concentrada em
única tabela como etc/[Link]), ademais a informação se dissemina facilmente para quem
precisa dela (permite modificação de informação de forma facilitada). Outra informação
é que o DNS pode ter cache distribuída, para armazenar respostas e evitar consultas
repetidas, melhorando o desempenho e a eficiência do sistema.

1.2 Servidores DNS

Nenhum servidor mantém todos os mapeamentos, tendo uma hierarquia entre eles.

1.2.1 Servidor de nomes local

Também chamado de servidor recursivo ou de cache local.
Existe na infraestrutura de redes de cada provedor de internet, empresa ou instituição.
Ele atua como o primeiro ponto de contato para resolver nomes de domínio em endereços
IP quando um dispositivo na rede faz uma requisição DNS.
Se a informação não estiver no cache, o servidor recursivo inicia um processo de
resolução recursiva. Ele consulta outros servidores de DNS na hierarquia — começando
pelos servidores raiz, depois os servidores de domínio de nível superior (como .com, .org),
até chegar ao servidor autoritativo que tem a resposta final. A resposta é então devolvida
ao servidor recursivo local, que armazena essa informação para futuras consultas e a
transmite ao dispositivo que fez a requisição inicial.
Muitas vezes, um servidor de nomes local atende redes grandes, com centenas ou
milhares de dispositivos. A capacidade de cache é especialmente importante nesses casos,
pois reduz o número de consultas externas e melhora a velocidade de resposta para os
usuários.
Ao utilizar um servidor recursivo local, uma organização reduz a latência de consultas
DNS e minimiza o tráfego de dados que precisa ser enviado para fora da rede. Isso melhora
o desempenho e a experiência do usuário.

1
 Figura 1: Hierarquia e consulta DNS.

1.2.2 Servidor autoritativo

É o que contém a base de dados oficial do domínio. Em outras palavras, ele é
responsável por armazenar e fornecer as respostas finais para consultas DNS sobre um
conjunto específico de domínios. Diferente de um servidor recursivo (ou DNS Cache), que
busca as respostas DNS e armazena em cache, o servidor autoritativo fornece respostas
oficiais e diretas para os registros DNS que ele mantém.
Um servidor autoritativo mantém registros de DNS de uma zona, ou seja, uma parte
específica da hierarquia DNS. Isso inclui informações sobre o domínio principal e seus
subdomínios.
Sua resposta é sempre direta.

1.2.3 Hierarquia
Root:
O DNS sempre tem um domínio raiz (root domain), que é o topo da hierarquia. Eles
são servidos por root servers. Esse domínio raiz, representado por um simples “.” (ponto),
é essencial para o funcionamento do sistema DNS, pois serve como ponto inicial para todas
as consultas de resolução de nomes.
Existem 13 conjuntos de servidores raiz no mundo, nomeados de “A” a “M”. Embora
existam apenas 13 identificadores, eles representam centenas de servidores distribuídos
globalmente por meio de um sistema de anycast, que permite que cada identificador seja
associado a múltiplos servidores físicos em diferentes localidades (espelhos).
Cada um desses 13 possuem IP fixos.
Ademais, não armazenam todos os nomes de domínio da internet. Em vez disso, eles
mantêm apenas informações sobre os domínios de nível superior (Top-Level Domains, ou
TLDs), como domínios genéricos (gTLDs), como .com e .org, e domínios de código de país
(ccTLDs), como .br para o Brasil ou .jp para o Japão. Essas informações se dão por meio
de apontadores.
Os espelhos reduzem a latência e proporcionam redundância.
TLD:

2
 Logo abaixo de root, podendo ser genérico ou geográfico. Pode ser os dois também,
ao mesmo tempo.
O AS112 é um AS (Autonomous System) distribuído e de propósito especial, dedicado
a processar consultas de DNS... e....?
R: Atua como uma "lixeira"para consultas de DNS mal configuradas, respondendo
com respostas negativas e evitando que elas atrapalhem o tráfego legítimo da internet. O
AS112 é um Autonomous System (AS) distribuído e de propósito especial, dedicado a
processar consultas de DNS para endereços IP privados e reservados, evitando que essas
consultas, que deveriam ser resolvidas localmente, sobrecarreguem a infraestrutura de
DNS global e os servidores raiz da internet.

1.2.4 Governança
ICANN (Internet Corporation for Assigned Names and Numbers)
É uma entidade internacional e sem fins lucrativos responsável por coordenar aspectos
técnicos e administrativos da internet.
Algumas funções incluem:

• Distribuição de numeração IP.

• Designação de identificações de protocolos.

• Controle a delegação dos sistemas de nomes de domínios de primeiro nível (gTLDs e

ccTLDs).

Anteriormente estas atividades eram originalmente prestadas mediante contrato com o

governo dos EUA, pela Internet Assigned Numbers Authority (IANA) e outras entidades.
A ICANN hoje cumpre a função da IANA.
Registry
O Registry é uma entidade central na administração de domínios de topo (TLDs) no
sistema de DNS, designada pela ICANN para armazenar, administrar e operar os registros
de um determinado TLD, seja ele genérico (gTLD) ou específico de país (ccTLD).

3
 Um Registry também é chamado de NIC (Network Information Center) e como já dito
ele armazena endereços IP de nomes de domínio de segundo nível que administra.
Quando ele recebe uma consulta de resolução de nome, ele responde com um apontador
para o IP do servidor autoritativo do domínio.
Portanto, fazer um registro de um domínio consiste em ter um domínio publicado nos
sistemas de um Registry.
Vale ressaltar que cada TLD ou GLD tem apenas um Registry. Ademais, o Registry
opera a raiz do seu TLD, ou seja, ele opera a base principal do seu TLD apontando para
os servidores autoritativos, mantendo informações de servidores de DNS. Isso inclui a
responsabilidade por listar e manter todos os domínios registrados sob esse TLD.
Explicando melhor, a "raiz"do TLD (como .com, .br ou .org) é o ponto inicial do TLD
na hierarquia do Sistema de Nomes de Domínio (DNS). Ela contém a lista centralizada
de todos os nomes de domínio registrados sob aquele TLD e é gerida pelo Registry. Isso
significa que ele é a autoridade final sobre quais domínios estão registrados e ativos dentro
de seu TLD, além de garantir que esses registros sejam corretos e atualizados.
O Registry mantém uma lista de servidores DNS autoritativos específicos que respondem
pelas consultas para o TLD que ele gerencia. No caso do .br, por exemplo, o Registry
do Brasil (o [Link]) tem servidores DNS autoritativos que sabem onde encontrar cada
domínio registrado sob .br. O Registry configura e monitora esses servidores, garantindo
que eles estejam sempre prontos para direcionar consultas corretamente.
O Registry armazena informações relacionadas especificamente aos servidores DNS
para cada domínio registrado no TLD. Isso inclui quais servidores DNS estão autorizados
a responder pelas consultas de cada domínio. Ele não armazena informações sobre o site
em si (como conteúdo ou IP final), mas sim uma lista de quais servidores DNS devem ser
consultados para encontrar esses domínios. Isso mantém o sistema leve e seguro.
Juntamente com o Registrar, o Registry controla a alocação de nomes dentro do seu
TLD.
Registrar e operar um TLD não é apenas caro, mas também exige um compromisso
contínuo de gerenciamento e infraestrutura.
Registrar
Também chamado de agente de registro, é a entidade credenciada por um Registry
responsável por proceder registro de nomes de domínios requerido por pessoa ou entidade.
Assim, um TLD pode ter vários Registrars. Então, um Registrar diz para o Registry
que um domínio está sob sua responsabilidade, mantendo as informações do proprietário
em um banco de dados, informando apenas as informações de ponteiro para os servidores
daquele DNS (apontadores IP).
Um name broker é uma pessoa ou empresa que atua como intermediária na compra e
venda de domínios, facilitando transações para aqueles que desejam adquirir ou vender
domínios específicos. Eles são especializados em encontrar domínios de valor, negociar
preços e ajudar seus clientes a garantir o nome de domínio que desejam. Alguns Registrars
também são name brokers.
Em MUITOS países o Registry também atua como Registrar.
Registrants
É a entidade ou pessoa que registra um domínio no Registrar e informa dados técnicos
(servidor DNS), administrativos (contatos, endereços, pessoas) e de cobrança.

4
1.3 Funcionamento do DNS
Um dos softwares mais populares para implementar o DNS é o BIND. É padrão em
sistemas Linux/Unix e faz a tradução de nomes para endereços IP.
BIND é um sistema de arquitetura cliente-servidor. A parte "cliente"é chamada de
resolver, enquanto a parte "servidor"é conhecida como named (name daemon). O BIND
permite que os clientes façam consultas DNS para traduzir nomes de domínio em endereços
IP e também serve como servidor, respondendo a essas consultas para outros dispositivos
na rede.

1.3.1 Domínio/Domain Name

Um domínio é uma hierarquia de nomes usada para identificar um conjunto de recursos
na internet. Ele representa um endereço exclusivo que facilita o acesso a sites, serviços de
e-mail e outros recursos. Um domínio é estruturado em níveis, geralmente separados por
pontos (.), onde cada nível é uma parte da hierarquia.
Seu conceito é parecido com o de Zona, mas são diferentes de forma sutil.

1.3.2 Zona
É um conjunto de informações contido em um BD que descreve o domínio. As
configurações da Zona estão associadas à definições de um domínio.

1.3.3 FQDN: Fully Qualified Domain Name

É o nome completo de um dispositivo, começa com o nome de host específico e termina
com o TLD.
Pode, inclusive, ter subdomínios no meio, ou seja, zone delegation.
Zone Delegation, ou delegação de zona, é o processo de transferir a responsabilidade
pela administração de uma subzona (ou subdomínio) para outro servidor DNS. Isso permite
dividir o gerenciamento de registros DNS entre diferentes administradores ou servidores,
criando uma hierarquia de autoridades para diferentes partes de um domínio.
Quando uma zona é delegada, o administrador da zona principal (ou pai) cria registros
DNS especiais, chamados de registros NS (Name Server), que apontam para os servidores
DNS autoritativos que vão gerenciar a subzona (ou subdomínio). Esses servidores autori-
tativos da subzona, então, são responsáveis por manter os registros DNS específicos para
aquela subzona.
Esses níveis hierárquicos não tem relação com endereços IP (os octetos).

1.4 Bind e servidores

1.4.1 Servidor primário ou master
É a fonte principal de todas as informações de um domínio específico a partir de arquivos
de zona mantidos pelo adm. É o que deve manter todas as informações atualizadas sobre
o domínio.
Ele responde qualquer consulta com autoridade. Assim, existe apenas um primário por
domínio.

5
 Figura 2: Transferência entre primário e secundário

1.4.2 Servidor secundário ou slave

Transferem/copiam um conjunto completo de informação do primário, mantendo
redundância. Ou seja, não possuem arquivos de zona próprio (zone transfers). São os
backup-servers.
Um servidor DNS secundário mantém uma cópia completa de todas as informações
sobre um domínio, permitindo que ele também responda a consultas com autoridade, assim
como o servidor primário. Por isso, tanto o servidor primário quanto o secundário são
autoritativos para o domínio e compartilham a responsabilidade de responder a consultas
DNS. Ambos são configurados na zona pai do domínio, que, por sua vez, define a delegação
e aponta para os servidores autoritativos do domínio filho. No caso dos TLDs, eles
direcionam para os servidores autoritativos do próximo nível, garantindo que o fluxo de
consultas DNS percorra a hierarquia de forma eficiente e confiável.
Como ambos possuem autoridade de domínio, para quem está fora do domínio, não há
diferença entre secundário e primário.
O recomendado é ter sempre mais de um secundário por domínio (de 3 a 8 dependendo
da criticidade, tamanho e geoabrangência do domínio), pois essa é a função do secundário,
garantir redundância em caso de falhas ou sobrecarga no primário.
Os RFCs recomendam que, para cada domínio, exista pelo menos um servidor secundário
fora da rede física onde reside o servidor primário do domínio ou zona, devido à necessidade
de proteção de desastres.

1.5 Configuração de DNS

Os Zone Transfers são como os secundários transmitem informações para os primários,
podendo ser de 3 tipos: full, incremental ou DNS Notify.

1.5.1 Registro SOA

A configuração de uma zona é feito por RR (Resource Records), são entradas em
arquivo de texto. O SOA é um deles, (Start Of Authority), fica no início do arquivo de

6
zona e define suas propriedades gerais.
$ORIGIN [Link].
@ 1D IN SOA [Link]. [Link]. (

20230823 ; Serial (No. srie): em data invertida - indica alterao

10800 ; Refresh (3 horas em segundos): verificar se primario alterou
3600 ; Retry: tempo para sec tentar de novo se nao tiver resp
432000 ; Expire: tempo para sec parar se nao tiver contato com prim
86400 ; TTL Minimum: TTL de cache para todos registros
)
Quando é iniciado, o secundário não contém nenhum arquivo de zona, então faz uma
requisição SOA. Para isso acontecer, o IP do primário precisa estar no secundário.
Assim, o secundário recebe o RR SOA e como ele não tem nenhuma informação, ele
solicita full zone transfer (AXFR). Assim, de posse os dados, ele apenas fará transferência
com primário após seu refresh.

1.5.2 Full zone transfer

A periodicidade com que o secundário faz requisição com o primário está no refresh
time do SOA, assim, quando alcança esse tempo o secundário verifica se tem alteração no
serial. Se há alteração no Serial Number, transfere a zona inteira, pela requisição TCP
“AXFR request ”. Bem, e se não tem resposta tenta novamente com base no retry. Se
atingir expiry time sem contato, o secundário deve parar de responder pela zona.
Full Zone Transfer (AXFR) é pouco eficiente para transferência de zonas muito grandes.
Por esse motivo, normalmente AXFR só é usada na 1a. transferência do primário para o
secundário, quando o secundário está iniciando.

1.5.3 Incremental zone transfer

Solicita o registro SOA e verifica se houve alteração serial com relação à última consulta
e se alterou faz ICFR request. O primário mantém histórico de alteração e só envia o que
modificou, melhorando a performance.

1.5.4 DNS Notify

Neste caso o Primário notifica o Secundário que houve alteração, via mensagem de
notify. Então, o secundário faz um SOA para confirmar alteração no Serial. Assim, ele faz
requisição AXFR ou IXFR.

1.5.5 DDNS
O DDNS (Dynamic DNS) é um tipo de DNS que permite atualizar dinamicamente o
mapeamento de um nome de domínio para o endereço IP do dispositivo, sem necessidade de
intervenções manuais constantes. Isso é particularmente útil para endereços IP dinâmicos,
como aqueles frequentemente atribuídos por ISPs residenciais, permitindo que serviços
hospedados localmente (como sites ou câmeras de segurança) permaneçam acessíveis por
um domínio fixo, mesmo que o IP do dispositivo mude.
Os dispositivos configurados com DDNS enviam solicitações para o servidor DNS
toda vez que o IP muda, e o servidor atualiza os registros do nome de domínio para

7
refletir o novo IP. DNS Dynamic Update é especificado pela RFC-2136, que define como
clientes podem modificar registros em um servidor DNS com atualizações dinâmicas. Essas
atualizações são autorizadas, protegidas por autenticação, e executadas automaticamente.

1.5.6 Configuração do recursivo

Arquivos default de um servidor recursivo são:

• /etc/[Link]

• /etc/[Link]

• /etc/bind/[Link]

options{

recursion yes;
allow-recursion{network_allowed;};

};
acl network_allowed{
[Link]/16;
200.145.201/24;
[Link];
};
zone "." {

type hint;
file "/etc/bind/[Link]";

};

• options { ...}:

– recursion yes;
Permite a recursão para consultas DNS, ou seja, o servidor pode resolver
consultas para outras zonas, não apenas para as que ele é autoritativo.
– allow-recursion { network_allowed; };
Especifica uma lista de redes permitidas a fazer consultas recursivas. Neste
caso, a ACL (lista de controle de acesso) chamada network_allowed define as
redes que têm permissão.

• acl network_allowed { ...}:

– Define uma ACL (Access Control List) chamada network_allowed, que especi-
fica quais redes podem usar a recursão DNS.
∗ [Link]/16;
Permite a rede com prefixo [Link]/16.

8
 ∗ [Link]/24;
Permite a rede com prefixo [Link]/24.
∗ [Link];
Permite o próprio servidor (localhost).
• zone "."{ ...}:
– Define a zona raiz ".", que é a base para a resolução de nomes na Internet.
– type hint;
Define o tipo de zona como hint. Isso indica que o servidor utilizará esta zona
para buscar informações de referência para a resolução de nomes de outras
zonas.
– file "/etc/bind/[Link]";
Especifica o arquivo [Link], onde estão armazenados os servidores raiz co-
nhecidos. Ele serve como ponto de partida para a resolução de consultas
recursivas.

Tem ainda os Forward Name Servers (a.k.a Proxy) que são servidores DNS para os
quais um servidor DNS local encaminha consultas que ele não consegue resolver sozinho.
Eles atuam como intermediários, resolvendo nomes de domínio que não estão presentes na
zona local ou cache do servidor.
acl goodclients {

200.145.200/24;
localhost;

};
options {

recursion yes;
allow-query { goodclients; };
};
forwarders {

[Link];
[Link];

};

forward only;

};

Define uma ACL chamada goodclients, que especifica os clientes permitidos para
realizar consultas DNS.
O comando forward only; indica que o servidor DNS usará exclusivamente os encami-
nhadores especificados ([Link] e [Link]) para resolver consultas para as quais ele não é
autoritativo. Se os encaminhadores não conseguirem resolver a consulta, o servidor DNS
não tentará outras fontes.

9
1.5.7 Configuração do primário
A configuração se dá através de arquivos locais, com erros podendo causar danos sérios
ao DNS, além disso, os arquivos de configuração devem operar entre si.
Vale ressaltar que um mesmo servidor pode atuar como primário e secundário, mas em
zonas diferentes.

• ../[Link] (ou [Link], [Link]):

– Arquivo principal de configuração do servidor DNS.

– Contém diretivas globais, como permissões de acesso, zonas e encaminhadores.
– Define parâmetros de funcionamento e segurança do servidor DNS.

• ../[Link] (ou [Link]):

– Arquivo que contém a lista de servidores raiz conhecidos.

– Utilizado pelo servidor DNS para localizar os servidores autoritativos para a
resolução de domínios desconhecidos.
– Serve como ponto de partida para a resolução de consultas DNS recursivas.

• ../[Link] (ou [Link]):

– Arquivo que configura a resolução para o endereço de loopback (localhost),

normalmente [Link].
– Define que consultas para [Link] retornem o nome localhost.
– É importante para o funcionamento correto de aplicações que requerem acesso
ao próprio servidor.

• ../{[Link]}.db (ou [Link]):

– Arquivo de zona que armazena os registros DNS para um domínio específico.

– Contém registros como A, MX, NS e outros, que mapeiam nomes para endereços
IP e serviços.
– Utilizado para responder consultas autoritativas sobre o domínio configurado.

• ../{[Link]}.db (ou [Link] – DNS reverso):

– Arquivo de configuração para DNS reverso, que mapeia endereços IP para

nomes de domínio.
– Necessário para resolução de nomes reversa (PTR records), onde o servidor
converte IPs em nomes de domínio.
– Essencial para a identificação de dispositivos e aplicações que requerem verifica-
ção de nomes por IP.

1.5.8 Configuração do secundário

Servidores secundários não possuem arquivos de zona próprios, pois são copiados do
primário, o que deixa a configuração mais simples.

10
Configuração de /etc/bind/[Link]
/* /etc/bind/[Link] */
options {
directory "/etc/bind";
allow-transfer { [Link]; [Link]; 192.168.0/24; };
/* Endereos permitidos para transferir meus registros de DNS */
/* Servidores secundrios autorizados a copiar os mapas do primrio */

/* Domnios onde atuo como servidor primrio (auth) (mapas master) */

zone "[Link]" {
type master;
file "/etc/bind/[Link]";
/* Arquivo onde est o mapa primrio */
};

/* Domnios para os quais sou servidor secundrio (mapas slave) */

zone "[Link]" {
type slave;
file "/etc/bind/[Link]";
/* Arquivo onde vai armazenar o mapa secundrio */
masters { [Link]; };
/* IP do primrio onde vai buscar o mapa master de [Link] */
};
};

1.6 Arquivo de Zona

Tem sempre um formato básico, com RR definindo informações, cada um associado a
um tipo de informação.

[RRname] [TTL] IN RRtype Data

Elementos Principais dos Registros de Recursos (RR)

• RRname:

– Nome do objeto que o RR referencia. Pode ser um nome de host individual,

domínio inteiro, ou outros objetos.

• TTL (Time to Live):

– Define o tempo que a informação do registro deve ser mantida em cache em

outros hosts e recursivos.
– Medido em segundos, mas aceita "h", "m"e "d"(horas, minutos, dias).
– Se não especificado, usa o valor TTL global do SOA.

• IN:

11
 – Define o registro como um RR de Internet ("IN"), o único tipo amplamente
utilizado.

• RRtype:

– Identifica o tipo do RR, como SOA, MX, A, etc.

• Data:

– Contém o dado específico para o qual o RRtype aponta.

Exemplo de Configuração Básica de um Arquivo de

Zona
# { aqui ainda virá o SOA no header } #
[RRname] [ttl] IN RRtype Data

www 3600 IN A [Link]

ftp IN A [Link]
mail IN MX 10 [Link].

Principais Tipos de Registros de Recursos (RR) no

DNS

Indicador do Tipo Nome do RR Descrição

do Registro
SOA Start of Autho- Marca o início dos dados de uma zona e define
rity parâmetros que afetam toda a zona.
NS Name Server Aponta um servidor de nomes para o domínio.
A Address Resolução direta: mapeia um nome de host
para um endereço IP.
PTR Pointer Resolução reversa: mapeia um endereço IP
para um nome de host.
MX Mail Exchange Aponta para o servidor de email de um domí-
nio específico.
CNAME Canonical Name Define um alias (sinônimo ou nome canônico)
para um nome de host.
TXT Texto Usado para definições como registros SPF
(Sender Policy Framework) para controle anti-
spam, entre outros.

Tabela 1: Principais tipos de registros de recursos (RR) no DNS

12
Observação
Existem outros tipos de RRs especializados para funções específicas, como:
• DNSSEC (segurança para DNS)
• DANE (Autenticação de Nome de Domínio para TLS)
• EMAIL (registros específicos para segurança de emails), entre outros.
Se não for inserido um FQDN no RRname, o sistema, internamente no processamento,
faz um append do nome do domínio. Se colocar o FQDN, o RRname precisa terminar
com “ . ” caso contrário o sistema faz o append internamente e o RRname ficaria errado
como [Link].

1.6.1 Reverse query (Consulta ao DNS reverso)

Em vez de fornecer um nome e solicitar um endereço IP, o cliente DNS fornece o
endereço IP e solicita o FQDN correspondente. A zona que contêm o mapeamento de
endereço IP-to-FQDN é conhecida como “zona reversa”. Também chamado “registro PTR”
(pointer).

Explicação da Configuração Reversa

Abaixo está o exemplo de um arquivo de zona reversa para a rede IP 192.168.0.x,
que utiliza o domínio [Link] para configuração de DNS reverso. O DNS reverso
permite que um endereço IP seja resolvido para um nome de host. O arquivo segue a
estrutura de configuração, conforme especificado:

[Link]. 1D IN SOA [Link]. [Link]. (

2020080901 ; Serial (o serial)
10800 ; Refresh (3 horas em segundos)
3600 ; Retry (1 hora em segundos)
432000 ; Expire (5 dias em segundos)
86400 ; Minimum TTL (24 hrs em seg.)
)

• [Link]: Indica a zona de DNS reverso para o bloco de IP

192.168.0.x.
• SOA (Start of Authority): Marca o início dos dados da zona e define parâmetros
que afetam toda a zona. Inclui informações como:
– Serial: 2020080901 - usado para versionamento do arquivo.
– Refresh: 10800 segundos (3 horas) - intervalo de atualização.
– Retry: 3600 segundos (1 hora) - tempo para novas tentativas de atualização,
caso o servidor esteja inacessível.
– Expire: 432000 segundos (5 dias) - após esse período, o servidor secundário
não considera mais válida a zona, se não puder ser atualizada.
– Minimum TTL: 86400 segundos (24 horas) - tempo padrão para cache das
informações.

13
Registros de Recursos (RR) para Resolução Reversa
Os registros abaixo definem os mapeamentos PTR para resolver endereços IP para
nomes de host:

IN NS [Link].
; continua...

; Exemplo de registros PTR para reverso

1 IN PTR [Link].
10 IN PTR [Link].
23 IN PTR [Link].
25 IN PTR [Link].

• NS: Define o servidor de nomes ([Link]) para esta zona de resolução

reversa.

• Registros PTR:

– 1 IN PTR [Link]: Associa o IP [Link] ao hostname [Link].

– 10 IN PTR [Link]: Associa o IP [Link] ao hostname
[Link].
– 23 IN PTR [Link]: Associa o IP [Link] ao hostname [Link]
– 25 IN PTR [Link]: Associa o IP [Link] ao hostname [Link].c

1.6.2 Exercícios
1) Identifique e explique o que anunciam os dois exemplos abaixo colocados num
arquivo de zona primário de [Link]:

Exemplo 1:
[Link]. TXT "v=spf1 a:[Link] \textasciitilde all"

O tipo TXT indica que é um registro que contém políticas SPF, usadas para indicar
como deve ocorrer o envio de emails (indica quais servidores são autorizados a enviar
emails em nome do domínio. Neste exemplo, [Link] é quem pode enviar para
[Link], se não for ele, usa a política softfail de ~all, que envia o email, mas o marca
como suspeito ou spam. O trecho v=spf1 a:[Link] ~all indica a política SPF
(que é 1, por v=spf1 ), o endereço que pode enviar (a:[Link]) e o tratamento
final se outro enviar.

2) Identifique e explique o que anunciam os dois exemplos abaixo colocados num

arquivo de zona primário de [Link]:

Exemplo 2:
[Link]. TXT "v=spf1 mx ip4:[Link] ip4:[Link]
include:[Link] -all"

14
 Aqui já é um pouco diferente. Semelhante ao anterior, busca-se inserir uma política
SPF do tipo 1 para [Link], autorizando pelo mx, o Mail Exchanger que permite
os IP’s listados a enviar emails para [Link], com o include indicando que todos os
autorizados por [Link] também estão autorizados a enviar ao [Link]. O
-all indica que em caso de envio por servidor não listado, a mensagem é recusada (mais
rigoroso).

3) Entenda e explique a diferença entre os resultados “softfail”, “fail”,

“pass” e “neutral” e sua relação com o anúncio “\textasciitilde all” e “-alI”

Fail: O servidor que enviou o e-mail não está autorizado a enviar e-mails em nome do
domínio. Quando ocorre: Se o e-mail vem de um servidor que não está listado nas regras
SPF e a política termina com -all. Nesse caso, o servidor de recebimento deve rejeitar a
mensagem.
Softfail: O servidor que enviou o e-mail não está autorizado, mas a política permite
certa flexibilidade. O servidor de recebimento pode aceitar a mensagem, mas pode marcá-la
como suspeita. Quando ocorre: Se o e-mail vem de um servidor não listado, mas a política
termina com ~all. O servidor pode optar por aceitar o e-mail, mas é aconselhável tratá-lo
como potencialmente indesejado.
Pass: O servidor que enviou o e-mail está autorizado a enviar e-mails em nome
do domínio, conforme definido na política SPF. Quando ocorre: Se o e-mail vem de
um endereço IP que está explicitamente listado nas regras SPF (por exemplo, em um
mecanismo a, mx, ip4, etc.).
Neutral: Não há informações suficientes para determinar se o e-mail deve ser conside-
rado legítimo ou não. Quando ocorre: Isso pode acontecer se não houver uma regra SPF
que se aplique ao e-mail ou se a política utilizar ?all, o que significa que o domínio não
tem uma opinião sobre a autenticidade do e-mail.

4) Entenda quais outros usos existem para os anúncios de TXT e CNAME no DNS.

Dica: como exemplo, veja como é feita a validação de Google Adsense e

Google Analitycs, ou o anúncio de uma chave DKIM usada para mitigação a SPAM.

Exemplo:
default._domainkey 3600 IN TXT "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDnX/oPYI/f+QKP3ZoVQwIe0Fn6205tr1xFWA
tOil+yXbEiAdF2SMOZvydPIY6VdL2wE7qFK4TUXFo5lEa7mX8zPk1Q53AjB/7OH2Ie1+EfkFWz03
wFbZvuUd6xDAi9k17UQ5bYzYMSpIu6kqh/VM/W0JIziOaKurSf7dA81myywwIDAQAB\;"

Configuração de segurança, validação de propriedade de domínio e integração com

serviços externos.
DKIM (DomainKeys Identified Mail): usado para autenticar e-mails, adicionando uma
assinatura digital às mensagens. O registro TXT contém a chave pública que os servidores
de recebimento podem usar para verificar a assinatura.
DMARC (Domain-based Message Authentication, Reporting Conformance): usa
registros TXT para informar como tratar e-mails que falham nas verificações de SPF ou
DKIM, além de permitir relatórios sobre a conformidade.
O CNAME (Canonical Name) permite que você aponte um domínio para outro. Isso
é útil para redirecionar subdomínios para serviços externos, como plataformas de blogs

15
ou lojas online. Alguns provedores de SSL exigem que você adicione um CNAME para
validar a propriedade do domínio antes de emitir um certificado.

5) Para que serve e como funciona um Stealth Name Server

(a.k.a. Hidden Master)? Como funciona um Split Horizon DNS Server?

Um Stealth Name Server é um servidor DNS que não é anunciado publicamente como
um servidor mestre (master) para um domínio específico. Ele gerencia zonas DNS, mas não
aparece nas respostas de consultas DNS públicas. O Stealth Name Server é configurado
como um servidor mestre para uma zona, mas seus registros NS (Name Server) não incluem
esse servidor.
Um Split Horizon DNS é uma configuração de servidor DNS que fornece diferentes
respostas a consultas DNS dependendo da origem da consulta. Isso é utilizado para separar
ambientes internos e externos.

6) Como funciona DNS Geotag.

DNS Geotag, ou Geolocation DNS, é uma técnica utilizada para direcionar usuários
para o servidor mais próximo ou apropriado com base na localização geográfica de suas
consultas DNS. Localização vista pelo IP.

2 Correio Eletrônico
Apesar do aumento das redes sociais, o Correio Eletrônico ainda é uma das aplicações
mais difundidas da Internet por conta de sua versatilidade, rapidez, multiplataforma, poder
usar off-line, etc.

2.1 Revisão - componentes

• MUA (Mail User Agent): software de atendimento direto ao usuário, que permite
ele enviar, escrever, ver sua caixa de mensagens, etc.

• MTA (Mail Transfer Agent): responsável pelo envio, roteamento e entrega de

e-mails na internet. O servidor de envio, que é um MTA, recebe a mensagem e
analisa o endereço do destinatário. Se o destinatário estiver em um domínio diferente
(por exemplo, alguém enviando de @[Link] para @[Link]), o MTA deve
encaminhar a mensagem para o MTA do domínio do destinatário. Esse processo
pode envolver múltiplos MTAs e roteamentos.

• MDA (Mail Delivery Agent): é o componente responsável pela entrega final das
mensagens na caixa de entrada do destinatário. Enquanto o MTA (Mail Transfer
Agent) cuida de transferir os e-mails entre servidores, o MDA é responsável por
pegar as mensagens do servidor e colocá-las no local adequado para que o usuário
final possa acessá-las.

• MAA (Mail Access Agent): é o componente que permite ao usuário final acessar
e visualizar as mensagens armazenadas no servidor de e-mail. Ele atua como uma
interface entre o servidor de e-mail e o cliente de e-mail do usuário, utilizando
protocolos de acesso para disponibilizar as mensagens.

16
 Sobre os protocolos do email, temos:

• SMTP (Simple Mail Transfer Protocol): protocolo para troca de e-mails que
define como as mensagens chegam de um servidor ao outro, até atingir seu dispositivo
final. Ele usa a porta 25 para envio de emails sem criptografia e 587 para mensagens
criptografadas.

• IMAP (Internet Message Access Protocol): protocolo de recebimento e ge-

renciamento do acesso de e-mails recebidos. IMAP permite acessar e gerenciar as
mensagens diretamente no servidor, mantendo-as sincronizadas em vários dispositi-
vos, o seu dispositivo, você tem apenas a cópia delas. Baixar um conteúdo é feito
sob demanda.

• POP3 (Post Office Protocol 3): após o recebimento de mensagens, é responsável

por baixar essas mensagens no dispositivo, apagando-as do servidor. Isso significa
que cada dispositivo onde o POP3 é configurado tem uma cópia independente dos
e-mails, sem sincronização com outros dispositivos.

Mais informações relevantes:

• Spam: e-mails não solicitados, geralmente enviados em massa, que visam promover
produtos, serviços ou espalhar mensagens maliciosas (como phishing ou golpes).

• Relays abertos: é um servidor de e-mail configurado de forma que permite a

qualquer pessoa enviar e-mails através dele, mesmo sem autenticação. Em condições
normais, um servidor de e-mail deve restringir o envio de mensagens apenas aos
usuários autenticados ou aos endereços de IP autorizados.

2.2 Anatomia de um e-mail

Um formato padrão de uma mensagem de e-mail vai incluir: cabeçalho, envelope e
body. Cabe ressaltar que o cabeçalho é diferente de mensagens SMTP. Este formato é
definido pelo RFC 822, e no cabeçalho temos quem enviou, assunto e para quem é (obtido
do envelope) e entre esse pedaço e o body temos uma linha em branco. O body constitui-se
de mensagem composta por caracteres ASCII terminada por um ponto.
O envelope é usado pelo protocolo SMTP para entregar a mensagem no servidor de
destino.
Os principais campos de cabeçalho são:

• To: endereço de e-mail do principal receptor.

• Cc: endereço de e-mail de receptores secundários.

• Bcc: permite enviar uma cópia de uma mensagem para destinatários adicionais sem
que os demais destinatários saibam.

• From: quem enviou a mensagem.

• Sender: endereço de origem da mensagem.

• Received: registra cada servidor pelo qual o e-mail passou durante seu trajeto.

17
 Figura 3: Tipos e subtipos de dados MIME.

• Return-path: rota até o receptor.

• Date: data de envio.

• Reply-to: endereço pelo qual a resposta retornará.

• Message-Id: identificador daquela mensagem.

• In-Reply-to: id da mensagem a qual essa resposta se originou.

• References: outros identificadores relevantes.

• Keywords: palavras chaves da mensagem.

• Subject: tema.

2.3 MIME (Multipurpose Internet Mail Extension)

Permite o envio de outros tipos de informações além de ASCII, como linguagens com
acentos, outros alfabetos, linguagens criptográficas, outras mídias, etc. O MIME acrescenta
codificação para outros tipos de informação além de textos puros. Usa RFC 2045 e 2046.
No cabeçalho, existem informações que definem o MIME. As informações são: versão,
método para codificar os dados, tipo de mídia/informação e dados codificados. Ainda tem
o delimitador MIME, que separa os diferentes tipos de conteúdo.
Tipos e subtipos enviados estão na Figura 3.

18
2.4 Pishing e Spam
O núcleo de sistemas de e-mail não foi criado com quaisquer protocolos de segurança.
Assim, é muito fácil falsificar um e-mail, que aparentemente vem de fontes legítimas. Ou
seja, no e-mail falso o endereço exibido para o destinatário é diferente do endereço real.
Isso é e-mail spoofing, que é uma técnica utilizada para falsificar o remetente de um e-mail,
fazendo com que a mensagem pareça ter sido enviada de um endereço legítimo quando, na
verdade, veio de uma origem diferente e potencialmente maliciosa.
Como o destinatário não sabe quem é o verdadeiro remetente do e-mail, essa técnica
é comumente utilizada em ataques de phishing e spam. Phishing é um tipo de ataque
cibernético em que criminosos tentam enganar pessoas para obter informações sensíveis,
como senhas, números de cartão de crédito, dados bancários e outras informações pessoais.
Para que o e-mail funcione corretamente e as mensagens sejam entregues aos destina-
tários, sem irem parar na caixa de spam, ou serem rejeitadas, é preciso configurar:

• Registro MX;

• Registro SPF;

• Chave DKIM;

• Registro DMARK.

2.4.1 Registro MX (Mail Exchanger)

É indispensável para receber e-mails corretamente, sendo registro no DNS que informa
a todos na Internet onde uma mensagem de e-mail para um domínio deve ser entregue. O
objetivo é informar onde o servidor de e-mail está localizado.
Seu funcionamento é: A quer enviar um e-mail para E, assim, faz uma busca DNS
para o servidor E, A localiza o Registro MX do domínio do destinatário e encaminha a
mensagem ao servidor. O servidor do destinatário entrega para o usuário E, que recebe a
mensagem.

2.4.2 Registro SPF (Sender Policy Framework)

Visa combater o envio não autorizado de menssagens em nome de um domínio. Anuncia,
no DNS de um domínio, quais são os IPs ou servidores autorizados a fazer envios de e-mail
em nome dele. Uma vez configurado corretamente, faz sempre a autentificação de quem

19
envia o e-mail. O servidor do destinatário verifica se o servidor remetente é autorizado a
enviar e-mails em nome do domínio.
Utiliza um registro de DNS RR do tipo texto (TXT).

2.4.3 Chave DKIM (DomainKeys Identified Mail)

Framework de autentificação de e-mail, adiciona assinatura digital à mensagem, assim
garantindo que a fonte é confiável e que a mensagem não foi alterada.
Usa criptografia assimétrica. Ademais, a chave assina o header e o body e a chave
pública é disponibilizada pelo DNS do domínio (Registro TXT).
A chave pública é usado pelos servidores do destinatário para validar os e-mails como
vindos de onde dizem vir, e para garantir que não foram alterados.
NÃO é para criptografar o e-mail. É para autenticar o servidor e a mensagem. Para
criptografar o envio usa o TSL e a mensagem o PGP ou S-MIME.
DKIM Domainkey é a chave pública de autenticação que fica disponível no servidor de
DNS do domínio. Ao contrário do SPF, que só verifica o envelope (quem está enviando), o
framework DKIM verifica o cabeçalho da mensagem e o conteúdo.
No servidor remetente, o corpo e o cabeçalho do e-mail que está saindo são transformados
num único hash. A chave privada assina esse hash e hash é enviado no header do e-mail.
Servidor de DESTINO identifica que o e-mail que chegou possui uma assinatura DKIM.
Para validá-la, o servidor de DESTINO recupera a chave pública do registro TXT/DKIM
do domínio do REMETENTE, para verificar a assinatura do hash do header que chegou
com a mensagem original. Servidor de DESTINO gera o seu próprio hash do cabeçalho, e
do corpo do e-mail recebido. Se o hash de assinatura verificada combinar com aquele que
foirecém-criado, isso significa que o e-mail é genuíno e não foi adulterado.
._domainkey é uma palavra reservada, para ser usada como subdomínio dentro do
domínio principal. Se o FQDN é s1._domainkey.[Link], então s1 é chamado de
“seletor” da chave DKIM. Pode ser configurado qualquer nome de seletor de sua preferência,
sendo um valor alfanumérico e pode conter hifens onde o hífen não pode ser o primeiro
caractere.
No sistema de correio eletrônico deve-se solicitar que o sistema mostre a mensagem
inteira original, com todos os headers. Localize no header a seção de assinatura DKIM
(“DKIM-Signature”) e procure a tag “s=”. O valor desta tag é o seletor.

2.4.4 Registro DMARC (Domain-based Message Authentication, Reporting

& Conformance)
É um conjunto de regras que permitem que os emissores e destinatários saibam o que
fazer com relação ao tratamento de e-mails fraudulentos ou com problema. Remetentes

20
publicam uma política que desejam que os destinatários sigam, destinatários enviam rela-
tórios aos remetentes sobre a quantidade de e-mails falsos ou fraudulentos que detectaram
e rejeitaram.
Políticas DMARC são anunciadas no servidor de DNS do domínio. É recomendável,
porém não obrigatório, anunciar a política DMARC.
Deve-se editar a zona de DNS e criar um registro TXT apontando da seguinte forma:
_dmarc.[Link] IN TXT ......[política]...
A "política” deve ser criado de acordo com as preferências em regras definidas para as
políticas do domínio.

2.5 Exercícios
Exercício 1) DANE
– DNS-Based Authentication of Named Entities
• Maneira de autenticar chaves de entidades TLS clientes e servidores, sem a necess
certificadora, armazenando-as no sistema de DNS.
• Utiliza recursos do DNSSEC.
– RFC-6698

DANE (DNS-Based Authentication of Named Entities) é um protocolo que permite

autenticar chaves de entidades TLS (clientes e servidores) sem a necessidade de autoridades
certificadoras (CAs) tradicionais. Em vez disso, as chaves públicas são armazenadas
diretamente no DNS (Domain Name System), utilizando os recursos de segurança fornecidos
pelo DNSSEC (DNS Security Extensions). O DNSSEC adiciona assinaturas criptográficas
às informações do DNS, garantindo a integridade e a autenticidade dos registros DNS, o que
permite que o DANE ofereça uma camada adicional de segurança ao associar diretamente
certificados TLS com os registros DNS autenticados.

Exercício 2) Entenda e explique o que é o “DMARC ARC” e como

ele funciona.
– Authenticated Received Chain (ARC) system for DMARC.

Entenda os novos headers:

– ARC-Authentication-Results (AAR)
– ARC-Seal (AS)
– ARC-Message-Signature (AMS)
• O ARC substitui om DMARC?
• Quem está usando DMARC ARC?

O DMARC ARC (Authenticated Received Chain) é um sistema que complementa o

DMARC (Domain-based Message Authentication, Reporting Conformance), projetado
para resolver problemas de autenticação de emails quando eles são encaminhados por
servidores intermediários. Com o DMARC ARC, é possível validar e manter os registros
de autenticação de emails durante a passagem por várias entidades, ajudando a evitar
falhas de autenticação que poderiam fazer com que emails legítimos fossem marcados como
spam ou rejeitados. Isso é especialmente útil em serviços de encaminhamento, como listas
de discussão e reenvios automáticos.
ARC-Authentication-Results (AAR): Este cabeçalho armazena os resultados de auten-
ticação (como SPF e DKIM) obtidos pelo primeiro servidor que processou o email. Cada

21
servidor que processa o email acrescenta o seu próprio AAR, criando uma cadeia confiável
de resultados de autenticação.
ARC-Seal (AS): Este cabeçalho garante a integridade da cadeia ARC, assinando
digitalmente todos os cabeçalhos ARC anteriores. Ele permite que o próximo servidor de
email valide que os cabeçalhos não foram adulterados, mesmo que o email passe por vários
intermediários.
ARC-Message-Signature (AMS): Este cabeçalho contém uma assinatura do conteúdo
do email e de outros cabeçalhos relevantes, como o From, de forma semelhante ao DKIM.
O AMS verifica que o conteúdo original da mensagem permanece intacto durante o
encaminhamento.
ARC não substitui o DMARC; ele o complementa. O DMARC ainda fornece a
política de autenticação e as instruções de tratamento para mensagens que não passam
nas verificações de autenticação. O ARC apenas permite que os emails encaminhados
mantenham o histórico de autenticação, ajudando a evitar que falhem em verificações de
DMARC, mesmo ao passar por servidores intermediários.
Empresas de grande porte e provedores de email, como Google e Microsoft, implementam
o ARC para melhorar a entrega de emails encaminhados e evitar falsos positivos no
tratamento de spam.

3 Multimídia
Os principais requisitos a serem atendidos quando exploramos recursos multimídia são:

• Atraso;

• Taxa de transmissão;

• Perda de pacotes.

A ideia é aproveitar ao máximo o serviço de melhor esforço do IPv4.

A grande questão é que em serviços multimídia temos sensibilidade ao atraso e certa
tolerância a perdas, o que o faz ser a antítese da transmissão de dados binários.
Sobre as mídias a serem transmitidas, existem 3 tipos básicos:

• Mídia armazenada (On-demand): vídeo e áudio contínuos e armazenados. São comuns

em serviços de Streaming, em que os clientes solicitam os arquivos, armazenados em
um servidor, para poderem assistir. Tem vários comandos de operação como pausar,
avançar, retornar, etc. Aqui, um atraso de 1 a 10 segundos é tolerável.

• Fluxo Contínuo (tempo real): unidirecional ao vivo (Broadcast - um para muitos).

O atraso de 10 segundos para iniciar é aceitável e tem menos comandos que a mídia
armazenada.

• Tempo real interativo (áudio e videoconferência): o fluxo é bidirecional e em tempo

real, com atrasos de áudio aceitável entre 150 e 400 ms e de vídeo menor que 150 ms.

Porém, garantir isso é uma tarefa desafiadora, pois a arquitetura do IPv4 não garante
nada, nem banda nem atraso/variação de atraso. Assim, surge um conceito importante,
o Jitter, que é a variação do atraso de pacotes, dentro de um mesmo fluxo de pacotes.

22
Ademais, vale ressaltar que o desempenho deteriora se os enlaces estão congestionados ou
muito distantes.
A ideia da multimídia é aproveitar ao máximo o serviço de melhor esforço do IPv4,
tentando bufferizar o conteúdo do cliente para atenuar o Jitter, além de usar UDP ao
invés de TCP. Pode-se colocar marcação de tempo em pacotes, para que o receptor saiba
quando reproduzir(não seria problema se chegasse fora de ordem), adaptar compressão de
dados para a banda disponível e transmitir pacotes redundantes.

3.1 Codificação e compressão de áudio/vídeo

Áudio e vídeo exigem muito mais recursos comparado com a transmissão de textos e
imagens estáticas, então obviamente não se envia tais dados sem compressão.

3.1.1 Codificação e CODECs

Módulos que codificam e comprimem arquivos de áudio e vídeo. Cada tipo de mídia
tem um tipo de CODEC associado, e todos resultam em algum tipo de perda (em geral
humanamente imperceptível).
Para áudio, a compressão é baseada na frequência de amostragem (afeta qualidade) e
no número de canais.

3.1.2 Codificação PCM (Pulse Code Modulation)

Transforma áudio analógico em digital por meio de 3 etapas.
Amostragem
A primeira etapa da Modulação por Código de Pulso (PCM) é a amostragem, na qual
um sinal analógico é capturado a uma taxa fixa para ser convertido em um formato digital.
Isso envolve a coleta de amostras periódicas da amplitude do sinal em intervalos regulares.
Por exemplo, para transmissões de voz, uma taxa de 8.000 amostras por segundo (8 kHz)
é suficiente para captar o conteúdo essencial, pois é compatível com o limite de frequência
das vozes humanas. Cada amostra possui um valor de amplitude específico, resultando
em um número real que representa a altura do sinal naquele momento, conhecido como
Pulsos PAM (Modulação por Amplitude de Pulso).
Se quisermos qualidade melhor, aumentamos a frequência de amostragem.
O Teorema da Amostragem de Nyquist-Shannon estabelece que, para converter um
sinal analógico em digital sem perda de informação, a taxa de amostragem deve ser, no
mínimo, o dobro da frequência mais alta presente no sinal analógico. Essa frequência
mínima de amostragem é chamada de frequência de Nyquist. A taxa de amostragem define
quantas vezes por segundo um sinal é medido, e é expressa em hertz (Hz). Na prática,
diferentes aplicações usam taxas de amostragem adequadas à sua faixa de frequência.
Quantização
Cada uma das amostras é “arredondada” para um valor qualquer, entre um número
finito de valores.
Esse processo de arredondamento, conhecido como quantização, permite representar a
amplitude do sinal com valores discretos. Em sistemas de PCM, esses níveis de quantização
geralmente são definidos como potências de 2, pois facilita a representação binária dos
dados. Por exemplo, ao usar 256 níveis de quantização (ou 8 bits), cada amostra pode ser
representada com um valor entre 0 e 255.
Representação

23
 Cada um dos valores de quantização é representado por um número fixo de bits.
Exemplo: se houver 256 valores de quantização, então cada amostra pode ser representado
por 1 byte (8 bits).
Assim, o PCM possui tamanho muito grande e portanto necessita de compressão,
existindo várias técnicas.

3.1.3 Compressões
A compressão de áudio no formato MP3 utiliza a técnica de "perceptual noise sha-
ping"para reduzir o tamanho dos arquivos de áudio com mínima perda de qualidade
percebida. O princípio fundamental é identificar e remover informações sonoras que são
irrelevantes ou redundantes, como frequências acima de 20 kHz, que o ouvido humano
não percebe, mas que estão presentes na codificação PCM. Ao comprimir o áudio para
taxas de 128 ou 96 Kbps, o MP3 mantém uma qualidade próxima à de CD, eliminando
componentes inaudíveis e repetitivos do som, o que reduz o tamanho dos arquivos em uma
proporção de até 12:1. Essa compressão torna o MP3 ideal para armazenar e transmitir
música em alta qualidade com baixo consumo de dados.
Já para vídeos, o MPEG são o mais usados, sendo MPEG1 de qualidade média, MPEG2
para vídeos DVD de alta qualidade e MPEG4 orientada a objetos.

3.1.4 Transdutor
Um transdutor (ou player) é um software projetado para reproduzir áudio digital com
qualidade e precisão. Entre suas funções principais estão a remoção de jitter (variações
temporais indesejadas que afetam a qualidade do som), a descompressão de formatos de
áudio como MP3, a correção de erros de dados durante a reprodução e a apresentação de
uma interface gráfica de usuário (GUI) para facilitar o controle da reprodução. Muitos
players suportam plug-ins, que permitem embutir o player em navegadores ou aplicativos,
ou usá-los de forma independente, ampliando suas funcionalidades e integração com outros
sistemas.

3.1.5 Vídeo on-demand (streaming) em servidores Web

Na abordagem ingênua para o armazenamento de mídia em servidores web, o browser
solicita um arquivo através de um HTTP request e o servidor responde enviando o
arquivo, com o cabeçalho “content-type” indicando a codificação. O browser então ativa
o transdutor de mídia para reproduzir o arquivo. Porém, essa abordagem apresenta
problemas, especialmente em streaming, pois o transdutor interage com o servidor via
browser, que funciona como intermediário. Isso causa latências e limitações no controle da
mídia, agravadas pelo uso do HTTP e TCP, que são menos eficientes para transmissão
contínua de mídia.
Na abordagem intermediária, o browser solicita um meta-arquivo que descreve o
conteúdo, e o transdutor estabelece uma conexão direta com o servidor de mídia via
HTTP para buscar o conteúdo. Contudo, o uso do HTTP continua limitando o suporte a
comandos de controle de apresentação, como pausar e avançar.
A melhor solução é uma arquitetura onde o transdutor se conecta diretamente ao
servidor de streaming, sem o browser como intermediário. Isso permite o uso de protocolos
alternativos, como UDP, que é mais adequado para streaming, pois evita as sobrecargas

24
de controle e correção de erros do TCP, resultando em uma transmissão mais fluida e
eficiente.

3.2 RTSP (Real Time Streaming Protocol)

O Real Time Streaming Protocol (RTSP) é um protocolo de controle de mídia que
permite o gerenciamento de fluxos de áudio e vídeo armazenados, com comandos como
avançar, voltar, pausar e continuar a reprodução. Ele é um protocolo de aplicação na
arquitetura cliente-servidor, projetado especificamente para dar ao usuário controle sobre a
mídia, mas não é um protocolo de streaming em si. Em vez disso, o RTSP apenas define as
interações de controle; ele não especifica o transporte do fluxo de mídia, o encapsulamento,
ou como o receptor deve armazenar o conteúdo.
O RTSP utiliza uma comunicação “fora-da-banda”, o que significa que as mensagens
de controle (como os comandos de pausa ou avanço) usam portas diferentes das portas
de dados da mídia. O fluxo de dados (a mídia em si) é transmitido “dentro-da-banda”
através de outro protocolo de transporte, como RTP (Real-Time Protocol), que é mais
apropriado para a entrega contínua dos dados de mídia. Dessa forma, o RTSP controla a
mídia sem se envolver diretamente no envio dos dados, oferecendo uma solução eficiente
para o controle de mídia armazenada.
Lembrando que este protocolo surge porque o HTTP não foi projetado para lidar com
mídia armazenada.
O processo é simples: O Cliente obtém a descrição do conteúdo multimídia (metadados
- pode consistir em vários fluxos de dados), depois o browser chama o player com base nesse
conteúdo obtido, transdutor envia o comando RTSP SETUP e servidor envia a resposta
RTSP SETUP, transdutor envia o comando RTSP PLAY; servidor envia a resposta RTSP
PLAY, então servidor descarrega o conteúdo de mídia. Caso for pausar, transdutor envia
RTSP PAUSE e servidor confirma mandando também de volta, idem para TEARDOWN.
Cada sessão de RTSP possui um ID, que é enviado pelo servidor quando ele recebe o
SETUP. Esse ID é repetido pelo cliente até o fim da sessão. Ademais, cada mensagem
RTSP é enviado por uma conexão TCP separada para transporte.

3.3 Aplicações interativas em tempo-real

Chamadas de telefones, dispositivo a dispositivo (Softfone VoIP-2-VoIP), VoIP para
ligação com telefone convencional (PSTN), entre outros, são esse tipo de serviço.
Mas como usamos o melhor esforço, temos problemas de atrasos, perdas e jitter. Tudo
descrito é sob viés da telefonia.
Para não desperdiçar banda, os pacotes são apenas enviados em momentos de voz
detectada. A aplicação funciona juntando momentos de atividade e gerando porção de
dados a cada 20 mseg.
Além dos dados, um cabeçalho é acrescentado ao bloco e juntamente com os dados
encapsulados a um pacote UDP. Alguns pacotes podem ser perdidos ou atrasados, então o
receptor decide o que fazer para reproduzir os blocos (ordem tomada) e determinar o que
fazer em caso de falta.

3.3.1 Tratamentos para o funcionamento do best-effort

O UDP está encapsulado em um datagrama IP, que pode ser descartado por um
roteador, o uso do TCP podeira impedir essas perdas, mas atrasaria muito a tecnologia.

25
O maior problema do TCP é que as retransmissões atrasam e o slidind window limita a
taxa de transmissão. Assim, usamos pacotes redundantes.
Outro problema na transmissão e streaming é o atraso fim a fim, cuja a causa é o
acúmulo de todos os atrasos (comrpomete a iteratividade).
Ainda tem problemas de jitter, e para resolver, enumeramos os pacotes, uso de marcas
de tempo e trasos na transmissão para conciliar o tempo.
TimeStamp - marcas de tempo: em cada bloco, colocamos a marca t, que indica o
tempo em que o bloco foi gerado. Ele reproduz o pacote um tempo p ms após ser gerado,
sendo a escolha desse valor p muito importante. Assim, se um bloco chega até o momento
t + p ele é reproduzido. Porém, se chegar após esse tempo ele é descartado. Números
de sequência não são necessários, mas deve ter umm meio para trabalhar com pacotes
perdidos.
Atraso de reprodução fixo: aqui o transmissor gera pacotes em intervalos de 20
ms durante períodos de intervalos de atividades. Para evitar interrupções ao longo da
transmissão, tem um atraso fixo inicial planejado p. Assim, as reproduções começam
apenas em p. Esse valor p é muito importante e deve ser escolhido com cautela, pois é por
meio dele que com variação nos tempos de chegada consegue-se uma reprodução contínua.
Mesmo que a reprodução com atraso p cause falhas, tem ainda um atraso p’ que auxilia
nesses casos, se ambos derem errado, o atraso será sentido.
2. Atraso de reprodução (adaptativo): o receptor estima dinamicamente o atraso
de rede após cada pacote recebido, ajustando a reprodução no início de cada intervalo de
atividade para garantir uma reprodução contínua. Cada pacote i tem um atraso de rede
di, calculado pela diferença entre o instante de recebimento ri e a marca de tempo de envio
ti. Esse atraso é atualizado dinamicamente usando uma média móvel ponderada com um
fator u (ex: u=0,01), para suavizar a estimativa do atraso médio di. Durante intervalos de
silêncio, a duração é ajustada com base nessa média de atrasos para compensar variações
na rede. Também é calculada uma variância média vi do atraso, que mede a dispersão dos
tempos de chegada, ajudando a identificar grandes flutuações. No início de cada intervalo
de atividade, o primeiro pacote é reproduzido em pi=ti+di+Kvi, onde K é um ajuste que
aumenta a segurança contra variações abruptas. O atraso de reprodução qi é então piti,
sendo aplicado para calcular o instante de reprodução pj dos pacotes subsequentes no
mesmo intervalo, de modo que cada pacote j seja reproduzido após qi unidades de tempo
de sua chegada tj. Assim, a reprodução se adapta constantemente aos atrasos, ajustando
intervalos e evitando interrupções na transmissão.
Números de sequência: o número de sequência serve para marcar a ordem de
reprodução dos pacotes, quando há um tempo de silêncio não conseguimos saber se houve
uma interrupção de atividade, ou se houve perda de pacotes. Assim, fazemos marcas de
tempo sucessivas. Se a diferença de marcas de tempo sucessivas forem maiores do que 20
ms então é período de silêncio.
O timestamp está marcado no header do pacote e ele incrementa o valor fixo de 20 em
20 ms.

3.3.2 Recuperação de perdas

Para considerarmos uma perda, ou o pacote nunca chega ou chega depois do período
programado para reprodução. Assim tem algumas técnicas de recuperação.
Uma delas é enviar, junto com o fluxo original, um fluxo de carona de menor qualidade.
Esse fluxo se chama fluxo redundante. O transmissor então gera um novo pacote a partir
do bloco n do fluxo nominal, anexando a ele um bloco n-1 redundante.

26
 Neste caso, sempre que ocorrer perda não consecutiva, ela pode ser mascarada. Apenas
dois pacotes precisam ser recebidos antes do início da reprodução.
Além da redundância, tem também a intercalação. Neste processo, cada bloco é
quebrado em blocos menores, estes são então enviados intercalados e são remontados no
destino. A ideia é que se um pacote for perdido ao enviar (ele estará intercalado), ainda
resta um pouco de cada pedaço original.
Ainda tem a correção de envio (FEC - Forward Error Correction), que adiciona
redundância para o receptor recuperar os dados sem necessitar de retransmissão. Em
um esquema simples, para cada conjunto de n blocos de dados originais, é criado um
bloco redundante usando uma operação XOR entre os blocos originais. Assim, o sistema
envia n+1 blocos (os n dados e o bloco redundante), o que aumenta a largura de banda
utilizada em um fator de 1/n. Caso ocorra a perda de até um bloco entre os n+1 enviados,
o receptor pode reconstruir o bloco perdido usando o XOR dos blocos recebidos e do
bloco redundante, sem precisar de retransmissão. Esse método é semelhante ao uso de
bits de paridade, mas com uma capacidade de correção mais robusta, já que permite a
recuperação de blocos inteiros.

3.4 Real Time Protocol - RTP

RFC 3550, que cuida do transporte de áudio e vídeo, seguindo o modelo cliente-
servidor.O RTP possui como principais características possuir identificação dos tipos de
carga para o CODEC, possuir marcação de sequência e de tempo, além de estar encapsulado
com UDP. Outra característica marcante e que faz com que ele seja amplamente utilizado
é que ele possui interoperabilidade, ou seja, as aplicações que usam RTP funcionam juntas
mesmo que sejam de desenvolvedores diferentes.
O RTP é um protocolo da camada de aplicação, que juntamente com UDP amplia suas
funcionalidades para transporte de mídia.

Figura 4: Encapsulamento RTP

Assim, o cabeçalho RTP mais o bloco de áudio forma o pacote RTP encapsulado dentro
de um pacote UDP. Ainda vale ressaltar que no cabeçalho RTP tem um campo que indica
o tipo de CODEC de cada pacote, que permite mudança em voo do tipo de CODEC.
Antes de continuar sobre o RTP, vamos falar sobre QoS, ou Quality of Service. QoS são
o conjunto de tecnologias e práticas para gerenciar e priorizar o tráfego de dados em redes,
garantindo que certos tipos de dados tenham uma transmissão mais eficiente e com menos

27
latência. Assegura que aplicações críticas, como de voz ou de vídeo, tenham tratamento
adequado para uma melhor performance, pois são sensíveis ao atraso e a perdas.
Os principais componentes são:

1. Classificação dos tipos de dados;

2. Prioritização do tráfego: atribui prioridades diferentes àqueles sensíveis ao atraso;

3. Controle de banda;

4. Gerenciamento de bandas.

Os benefícios do QoS é que reduz atraso e latência em serviços sensíveis (jitter reduzido),
otimiza o uso da largura de banda, prioriza tipos de serviços e melhora estabilidade e
desempenho em redes congestionadas ou com uso intenso.
Para obter Qualidade de Serviço (QoS) em uma rede, é necessário que a infraestrutura
ofereça um mecanismo especial que permita à aplicação reservar recursos específicos,
geralmente na rede local. Uma das soluções é o uso do protocolo RSVP (Resource
reSerVation Protocol), definido na RFC-2205. O RSVP é um protocolo de configuração
que estabelece estados de reserva de fluxo específicos em roteadores e hosts, integrando-se
à arquitetura de "serviços integrados"(IntServ) da Internet para oferecer QoS. Projetado
para ser robusto, eficiente, flexível e extensível, o RSVP suporta tanto fluxos de dados
multicast quanto unicast. Com frequência, o RSVP é utilizado em conjunto com MPLS
para garantir a entrega eficiente e confiável dos dados na rede.
O MPLS (Multiprotocol Label Switching) é uma tecnologia de encaminhamento de
pacotes baseada em rótulos (labels) que insere um rótulo nos pacotes ao entrarem no
backbone da rede, através dos roteadores de borda, permitindo que o encaminhamento
subsequente dentro do backbone seja feito com base nesse rótulo. É considerada uma tec-
nologia de "camada 2.5", pois opera na camada de enlace, mas utiliza também informações
da camada 3 para decidir o caminho dos pacotes. Um exemplo de funcionamento do MPLS
é o seguinte: quando um usuário em São Paulo envia um pacote para um servidor em
Nova York, o pacote é recebido por um roteador de borda em São Paulo, que adiciona um
rótulo ao pacote indicando que deve ser encaminhado ao roteador de borda em Nova York.
O pacote é então transmitido através do backbone, passando por diversos roteadores de
transporte que leem o rótulo e o encaminham para o próximo roteador de acordo com as
instruções do rótulo. Ao chegar ao roteador de borda em Nova York, o rótulo é removido
e o pacote é encaminhado ao servidor.

3.4.1 Fluxos RTP

O RTP (Real-time Transport Protocol) é um protocolo que permite a transmissão de
dados em tempo real, como áudio e vídeo, criando fluxos independentes para diferentes
fontes de mídia. Com RTP, cada tipo de mídia (como áudio e vídeo) é transmitido em
seu próprio fluxo de pacotes, o que facilita a sincronização e o controle desses dados. Por
exemplo, em uma videoconferência, é comum que existam duas fontes principais: uma
para o vídeo e outra para o áudio. Isso permite que haja a priorização correta para cada
fluxo.

28
3.4.2 Header RTP
• Número de sequência (16 bits): a cada RTP enviado é incrementado em 1, usado
para identificar perdas, momentos de silêncio e recuperar pacotes.

• TimeStamp (32 bits): serve para identificar em qual momento o pacote deve ser
reproduzido, identifica o instante de amostragem do primeiro byte, removendo o
jitter e obtendo sincronismo de reprodução. Incrementa em um a cada amostragem
e é indicado pela amostragem do transmissor. Note que o relógio de marca de tempo
continua a aumentar numa taxa constante, mesmo quando a fonte está inativa.

• Identificador de sincronisto fonte (SSRC - 32 bits): cada fluxo RTP tem uma seção
SSRC única, assim ela identifica a fonte.

• Versão (2 bits).

• Padding (1 bit): Sinaliza a adição de octetos de enchimento adicionais ao conteúdo da

carga (payload) sem fazer parte da mesma. O último octeto do preenchimento contém
a informação de quantos octetos foram inseridos. Este preenchimento adicional é
normalmente utilizado para uso de algoritmos de criptografia de tamanho de blocos
fixos ou para transmissão de pequenos conteúdos.

• X (Extensão - 1 bit): Este campo indica se há um cabeçalho de extensão extra entre

os dados e o cabeçalho básico do pacote RTP. Se o valor deste campo for 0, não há
cabeçalho de extensão extra.

• CC (Contador CSRC - 4 bits): número do id. Identificar as fontes de contribuição

para um fluxo RTP. Um fluxo RTP pode ter várias fontes de contribuição, como
uma câmera de vídeo, um microfone ou um computador. Os identificadores CSRC
permitem que o receptor do fluxo RTP identifique as fontes de contribuição para o
fluxo. O CSRC é um campo opcional no cabeçalho do pacote RTP.

• M (marcador - 1 bit): sinalizador é usado para indicar que os dados atuais têm
alguma relevância especial para a aplicação. Por exemplo, este sinalizador pode ser
usado para indicar que os dados atuais são um pacote de controle ou que os dados
atuais são um pacote de dados de um tipo específico.

3.4.3 SRTP (Secure Real-time Transport Protocol)

Protocolo que oferece segurança adicional para o RTP (Real-time Transport Protocol),
que é amplamente utilizado em comunicações em tempo real, como chamadas de voz e vídeo
sobre IP. O SRTP acrescenta funcionalidades de criptografia, autenticação e verificação
de integridade aos pacotes RTP, assegurando que os dados transmitidos sejam protegidos
contra escutas e modificações não autorizadas. Com SRTP, os dados de áudio e vídeo
são criptografados para garantir a privacidade, e um código de autenticação é usado para
verificar a integridade dos pacotes e garantir que não foram alterados durante o tráfego na
rede. Esse protocolo é comumente utilizado em aplicativos de VoIP, videoconferências e
streaming, onde a proteção de dados é fundamental para a segurança das comunicações.

29
3.4.4 Nem tudo usa RTP
O RTP é ideal para streaming que usam tempo real e iteratividade, em casos armaze-
nados e sob demanda, a confiabilidade e qualidade de transmissão. Ou seja, a latência
mais baixa possível deixa de ser prioridade. Assim, poucos provedores de streaming usam
RTP hoje em dia.
O que usa é: plataformas de transmissão ao vivo, sistemas de vigilância e segurança,
soluções de telemedicina, etc.
Em grandes provedores, usa-se HTTP para streaming, que tem a mesma base do HTTP,
mas com alguns tratamentos especiais.
O HTTP foi escolhido porque ele possui algumas qualidades que auxiliariam na entrega
do pacote, como CDNs (Content Delivery Networks), que são caches intermediários que
armazenam cópias dos arquivos e aceleram a entrega. CDNs já são otimizados para
distribuir conteúdo HTTP em larga escala, com baixa latência, geolocalização e alta
eficiência. Além disso, ele tem compatibilidade com firewalls e coorporações, o RTP pode
ser bloqueado.
Os headers do HTTP também permitem adicionar o tipo do conteúdo e informações
adicionais, ele é aberto e extensível (permite a criação de novos recursos e funcionalidades)
e garante segurança com HTTPS.
O HTTP usa tecnologia de streaming adaptativo.

• DASH (Dynamic Adaptive Streaming over HTTP): é um padrão aberto desenvolvido

pela MPEG (Moving Picture Experts Group) que otimiza o streaming de vídeo,
sendo amplamente utilizado por grandes plataformas, como Netflix e YouTube. Esse
padrão divide o conteúdo em pequenos segmentos, ajustando a qualidade do vídeo
transmitido com base na largura de banda disponível, o que permite uma reprodução
mais fluida e adaptativa. Um componente essencial do DASH é o “arquivo de
manifesto”, chamado Media Presentation Description (.mpd), que lista os segmentos
de vídeo em diferentes qualidades. Com esse arquivo, o player pode escolher em
tempo real o segmento mais adequado à conexão do usuário, proporcionando uma
experiência de streaming contínua e de alta qualidade.

• HLS (HTTP Live Streaming): é um protocolo de streaming desenvolvido pela Apple,

amplamente utilizado em dispositivos iOS, Apple TV e Mac, mas que também
possui suporte em outras plataformas populares, como Amazon Prime, Twitch e
Paramount+. O HLS funciona dividindo o vídeo em pequenos segmentos de arquivo
(.ts ou .m4s) e usa um arquivo de índice (.m3u8) que lista as variações de qualidade
disponíveis, permitindo que o player escolha a melhor opção de reprodução com
base na conexão do usuário. Devido à sua flexibilidade e compatibilidade, muitas
plataformas de streaming em larga escala utilizam o HLS em conjunto com o DASH
para garantir uma experiência de streaming adaptável e contínua em diferentes
dispositivos e condições de rede.

Perguntas e Respostas sobre WebRTC

1. O que é WebRTC (Web Real-Time Communication)?
WebRTC é uma tecnologia que permite que navegadores web estabeleçam conexões
ponto a ponto para comunicação em tempo real, como chamadas de vídeo, áudio e

30
compartilhamento de tela, diretamente no navegador e sem a necessidade de plugins ou
softwares adicionais.

2. Como funciona o WebRTC?

O WebRTC utiliza uma combinação de protocolos e APIs que permitem a transmissão
de áudio, vídeo e dados diretamente entre navegadores, superando a necessidade de um
servidor intermediário. O processo envolve o estabelecimento de conexões seguras ponto a
ponto (P2P), resolução de rede, negociação de codec e fluxo contínuo de dados.

3. O WebRTC utiliza uma série de protocolos e tecnologias para

estabelecer e manter conexões em tempo real. Quais são eles?
Para garantir a comunicação em tempo real, o WebRTC utiliza os seguintes protocolos
e tecnologias:

• ICE (Interactive Connectivity Establishment): para detectar a melhor rota

para estabelecer a conexão P2P.

• STUN (Session Traversal Utilities for NAT): para descoberta de endereço IP

público e mapeamento de rede.

• TURN (Traversal Using Relays around NAT): para redirecionar dados caso
uma conexão direta P2P não seja possível.

• DTLS (Datagram Transport Layer Security): para assegurar a criptografia

dos dados durante a transmissão.

• SCTP (Stream Control Transmission Protocol) e RTP (Real-Time Trans-

port Protocol): para transmissão de dados e mídia em tempo real.

4. Quais são as principais aplicações do WebRTC?

As principais aplicações do WebRTC incluem videoconferências, chamadas VoIP, jogos
online, compartilhamento de arquivos P2P, e serviços de atendimento ao cliente com
suporte de vídeo e áudio em tempo real.

5. Quais os componentes principais do WebRTC?

Os componentes principais do WebRTC são:

• MediaStream: para capturar e gerenciar fluxos de mídia de áudio e vídeo.

• RTCPeerConnection: para gerenciar a conexão P2P, incluindo a troca de dados e

controle de fluxo.

• RTCDataChannel: para permitir a troca de dados arbitrários entre os pares.

31
6. Quais os desafios e limitações do WebRTC?
Alguns desafios e limitações do WebRTC incluem:

• Escalabilidade em transmissões de larga escala.

• Exigências de largura de banda e latência baixa para melhor qualidade de serviço.

• Configuração complexa para superar firewalls e NATs.

• Suporte limitado a qualidade de serviço (QoS).

7. O protocolo WebRTC utiliza, ou pode utilizar, protocolo RTP?

Se sim, onde o RTP é usado?
Sim, o WebRTC utiliza o protocolo RTP para transportar mídia (áudio e vídeo) em
tempo real entre os navegadores, garantindo sincronização e transmissão contínua dos
dados multimídia.

8. Quais outras tecnologias são relacionadas ao WebRTC e RTP?

Outras tecnologias relacionadas incluem SRTP (Secure Real-time Transport
Protocol) para a criptografia de dados RTP e RTCP (Real-Time Control Protocol)
para monitoramento da qualidade de serviço e sincronização de mídia.

9. O WebRTC utiliza HLS? Qual o motivo para usar ou não usar?

Não, o WebRTC não utiliza HLS. O HLS é um protocolo de streaming baseado em
HTTP projetado para transmissões de conteúdo de vídeo sob demanda com maior latência,
enquanto o WebRTC é ideal para comunicação em tempo real, pois prioriza a latência
baixa e conexões P2P diretas.

10. O WebRTC utiliza DASH? Qual o motivo para usar ou não

usar?
Não, o WebRTC não utiliza DASH, que é mais adequado para streaming de vídeo sob
demanda ou ao vivo em larga escala com alta latência tolerável. O WebRTC, por outro
lado, é projetado para interações com latência muito baixa.

11. Quando escolher WebRTC, e quando escolher DASH, e quando

escolher HLS?
• WebRTC é ideal para comunicação em tempo real, como videoconferência e com-
partilhamento de tela, onde a baixa latência é fundamental.

• DASH e HLS são mais apropriados para streaming de vídeo ao vivo ou sob demanda
em larga escala, como em serviços de entretenimento, onde a latência pode ser maior.

32
12. O WebRTC é adequado para streaming em larga escala?
Não, o WebRTC não é ideal para streaming em larga escala, pois a sua arquitetura
P2P não é escalável como as arquiteturas baseadas em CDN usadas pelo HLS e DASH.
Para transmissões com muitos espectadores, os métodos tradicionais como HLS ou DASH
são mais apropriados.

3.5 RTCP - Real-Time Control Protocol

O Real-Time Control Protocol (RTCP) é um protocolo complementar ao RTP, essencial
para o controle de desempenho e diagnóstico em aplicações de tempo real, como streaming
de vídeo. Ele opera em conjunto com o RTP, fornecendo feedback sobre a qualidade da
comunicação por meio de pacotes de controle periódicos, que contêm relatórios detalhados
sobre o número de pacotes enviados, pacotes perdidos, variação de atraso, entre outras
métricas. Esses pacotes de relatório são transmitidos tanto pelo receptor quanto pelo
transmissor, permitindo ajustes na comunicação para otimizar a qualidade. Além disso, o
RTCP inclui pacotes de descrição da fonte, que fornecem informações como o endereço de
e-mail e o nome do gerador do fluxo, permitindo mapear o SSRC com o nome do usuário
ou host. Para não sobrecarregar a rede, o RTCP limita seu tráfego a 5% da largura de
banda da sessão, com 75% dessa taxa reservada para os receptores e o restante para o
transmissor. Esse controle de tráfego é fundamental para garantir a estabilidade e eficiência
das transmissões em tempo real.
Os grandes provedores de streaming de vídeo, como Netflix, Amazon Prime Video,
Disney+ e YouTube, não utilizam o RTCP (Real-Time Control Protocol) diretamente. O
RTCP é utilizado principalmente em comunicação em tempo real, como videoconferências,
e não é ideal para o streaming de vídeo sob demanda, que envolve o envio de conteúdo
para um grande número de usuários de forma eficiente e sem latência significativa.
Em vez do RTCP, esses serviços de streaming utilizam tecnologias como o DASH
(Dynamic Adaptive Streaming over HTTP) e o HLS (HTTP Live Streaming). Ambos
são protocolos adaptativos que dividem o conteúdo em segmentos pequenos e ajustam
a qualidade do vídeo em tempo real, de acordo com a largura de banda disponível e as
condições da rede. Essas tecnologias permitem uma transmissão contínua e eficiente, com
a capacidade de ajustar a qualidade do vídeo para evitar buffering e melhorar a experiência
do usuário, especialmente em redes móveis com variação na velocidade de conexão.

4 Wifi
Redes wireless podem ser de 4 tipos:

1. Salto único com inffraestrutura (Acess Point - AP): comunicação direta entre hosts
e estaçãao-base.

2. Salto único sem infraestrutura (ad hoc): Hosts conectados uns com os outros, contudo
somente se comunicam com os vizinhos no alcance.

3. Múltiplos saltos com infraestrutura (mesh): Hosts podem se comunicar com demais
hosts, a fim de que a mensagem alcance a estação base.

33
 4. Múltiplos saltos sem infraestrutura (móvel): Hosts se comunicam uns com os outros
e podem rotear informações para os demais fora do alcance do emissor, não há
estação-base.

No wireless, o sinal enfraquece de acordo com a distância da fonte (atenuação de

recurso), travessia de materiais (absorção) e reflexão em obstáculos. Pode ter interferência,
pois ondas muito parecidas podem interagir. Ademais, há a propagação de multicaminhos,
em que as ondas atingem o destino por caminhos diferentes e chegam em tempos diferentes.
Ou seja, redes wireless possuem maior propensão a interferências e erros de transmissão,
que precisarão ser tratados por detecção de erros mais avançadas do que cabeadas e
também possuem ACK e retransmissão.
A modulação do sinal é muito importante nesses casos e é a maneira como o sinal se
varia para transmitir as informações.
Ondas portadoras são outro conceitos importantes, se referindo a um sinal eletro-
magnético que serve como veículo para transportar informações. Mas por que elas são
usadas?
Elas são usadas pois:

• Elas são eficientes, suas altas frequências permitem que ela perca menos sinal no
caminho.
• Modulação: se modificarmos alguma característica dessa onda, podemos codificar a
informação que desejamos transmitir.
• Podemos transmitir diferentes dados ao mesmo tempo por conta das múltiplas
transmissões simultâneas, que utilizam frequências portadoras distintas.

As principais características de ondas portadoras são sua amplitude (intensidade

máxima da onda), frequência (número de ciclos completos que a onda realiza por segundo)
e a fase que é a posição inicial da onda em relação a um ponto de referência. Elas definem
o tipo de modulação.

4.1 Como um dispositivo é capaz de obter os dados?

O sinal wireless em um dispositivo é composto por sinal degradado (atenuação, multivias,
interferência) enviado pelo emissor e ruído do ambiente (outras frequâncias competindo
com sinal).
A Relação Sinal-Ruído (SNR) é uma medida adimensional expressa em decibéis (dB)
que compara a potência do sinal desejado com a potência do ruído indesejado, indicando
a qualidade de transmissão. Quanto maior o SNR, melhor a qualidade do sinal, pois ele se
sobressai ao ruído.
Lembrando que a potência do sinal é sua amplitude ao quadrado.
Psinal
 
SNR = 10 · log10
Pruído

4.2 Terminal Oculto

Ocorre quando dois hosts conseguem transmitir para a estação base, mas não um para
o outro. Isso pode ocorrer pela obstrução física ou pela distância dos hosts que desvanece
o sinal.

34
4.3 Arquitetura da rede
A arquitetura das redes LANs IEEE 802.11 (Wi-Fi) suporta duas configurações princi-
pais conhecidas como Conjunto Básico de Serviço (*Basic Service Set* - BSS): o modo
infraestrutura e o modo ad-hoc. No modo infraestrutura, os dispositivos se conectam a
um ponto de acesso (Access Point - AP) ou roteador, que organiza a comunicação. Já no
modo ad-hoc, os dispositivos se comunicam diretamente, sem a necessidade de um AP.
Antes de transmitir dados em uma rede infraestrutura, os dispositivos devem se associar
ao AP, que tem configurado um *Service Set Identifier* (SSID) e um canal de operação em
frequências de 2 GHz, 5 GHz ou 6 GHz. As redes Wi-Fi utilizam diferentes padrões, cada
um operando em diferentes frequências e larguras de canal: o padrão IEEE 802.11b/g,
que usa a frequência de 2.4 GHz com canais espaçados a cada 5 MHz, e os padrões IEEE
802.11n/ac/ax, que operam em frequências de 2.4, 5 e 6 GHz, com larguras de canal
variando entre 20 e 40 MHz. No Brasil, a banda de 2.4 GHz ainda é amplamente utilizada,
com canais numerados de 1 a 11, onde apenas os canais 1, 6 e 11 são independentes e não
apresentam sobreposição, permitindo uma melhor qualidade de transmissão.

4.4 Como achar um AP?

Em ambientes com várias redes Wi-Fi, como condomínios, prédios e aeroportos, conhe-
cidos como "Wi-Fi Jungles,"um dispositivo pode detectar sinais de múltiplos pontos de
acesso (APs). No entanto, a seleção automática do AP não é definida pelo padrão 802.11
e geralmente depende do fabricante do dispositivo, que tipicamente prioriza a intensidade
do sinal.
Para se conectar a uma rede Wi-Fi, o dispositivo segue várias etapas de comunicação
com o ponto de acesso (AP). Primeiramente, o dispositivo envia uma *Probe Request* para
procurar pontos de acesso próximos, solicitando informações sobre as redes disponíveis.
Cada AP que recebe essa solicitação responde com uma *Probe Response*, contendo
dados sobre a rede, como o identificador da rede (SSID) e suas capacidades, permitindo
que o dispositivo saiba quais redes estão ao seu alcance. Com base nessas respostas, o
dispositivo escolhe um AP ao qual deseja se conectar.
Em seguida, o dispositivo envia uma *Authentication Request* ao AP para iniciar o
processo de autenticação. O AP responde com uma *Authentication Response*, indicando
se a autenticação foi bem-sucedida. Se a autenticação for aprovada, o dispositivo está
pronto para a próxima etapa, que é a associação à rede.
Após a autenticação, o dispositivo envia um *Association Request* ao AP para solicitar
a associação à rede. O AP responde com um *Association Response*, confirmando que o
dispositivo pode se conectar à rede e comunicando o canal e as configurações da rede.
Finalmente, o dispositivo faz uma solicitação ao *Dynamic Host Configuration Protocol*
(DHCP) para obter automaticamente um endereço IP, as configurações de rota e servidores
DNS. O DHCP atribui um endereço IP válido ao dispositivo, permitindo que ele acesse
os recursos da rede local (LAN) e a internet. O uso do DHCP simplifica o processo de
configuração da rede, evitando a necessidade de configurar manualmente o endereço IP e
outras informações de rede.
A autenticação pode ser simples, por exemplo, usando usuário e senha, ou mais
complexa, com certificados digitais e autenticação centralizada via servidores RADIUS,
LDAP ou Active Directory (AD). Com a associação ao AP estabelecida, o dispositivo está
pronto para enviar e receber dados na rede, usando protocolos de acesso múltiplo para
gerenciar o compartilhamento do meio sem fio.

35
4.5 Lightweight Directory Access Protocol (LDAP)
O **Lightweight Directory Access Protocol (LDAP)** é um protocolo de comunicação
utilizado para acessar e gerenciar informações em um diretório, que é uma estrutura
hierárquica especializada em armazenar dados sobre recursos e usuários em uma rede,
como nomes, endereços de e-mail, senhas, grupos e permissões de acesso. Organizando os
dados em uma árvore hierárquica, o LDAP facilita a busca e a gestão das informações,
sendo projetado para consultas rápidas e acessos frequentes a dados que não mudam com
frequência, tornando-o eficiente em termos de uso de rede e recursos do servidor. Funcio-
nando sobre o protocolo TCP/IP, o LDAP é amplamente utilizado para gerenciamento de
autenticação de usuários e controle de acesso, sendo comum em ambientes corporativos,
servidores de e-mail e outros sistemas. Ele permite que clientes LDAP façam solicita-
ções para acessar ou modificar dados no diretório, com o servidor LDAP processando e
retornando as informações ou alterando-as conforme necessário. Além disso, o LDAP é
utilizado em diversas aplicações, como autenticação centralizada em redes corporativas e
gerenciamento de diretórios de e-mail. Sua escalabilidade, eficiência e compatibilidade com
diversos sistemas tornam-no uma ferramenta essencial para a gestão de dados em redes.

4.6 RADIUS (Remote Authentication Dial-In User Service)

O **RADIUS (Remote Authentication Dial-In User Service)** é um protocolo de rede
utilizado para gerenciar autenticação, autorização e contabilidade (AAA - Authentication,
Authorization, and Accounting) de usuários que se conectam a redes, especialmente
em ambientes que exigem acesso remoto, como VPNs, redes Wi-Fi e sistemas de rede
corporativos. O RADIUS verifica as credenciais do usuário, como nome de usuário e senha,
para garantir que o usuário tenha permissão para acessar a rede, além de verificar quais
recursos e serviços o usuário pode acessar após a autenticação. Ele também rastreia o uso
da rede, registrando detalhes sobre quando o usuário se conecta, a duração da sessão e o
consumo de dados. O RADIUS funciona com um cliente (como um ponto de acesso ou
roteador) que envia uma solicitação de autenticação para um servidor RADIUS, que valida
as credenciais e responde com uma autorização de acesso. A centralização do processo
de autenticação e a criptografia das credenciais tornam o RADIUS uma solução segura e
escalável, frequentemente utilizado em redes Wi-Fi corporativas, VPNs e provedores de
serviços de Internet (ISPs).

4.7 Carrier Sense Multiple Access with Collision Avoidance -

CSMA/CA.
O protocolo de acesso ao meio utilizado em redes Wi-Fi é o CSMA/CA (Carrier
Sense Multiple Access with Collision Avoidance), que é uma variação do protocolo CSMA
utilizado em Ethernet. A principal diferença entre ambos é que o CSMA/CA não realiza
a detecção de colisão (CD - Collision Detection), mas sim prevenção de colisão (CA -
Collision Avoidance). Em um cenário de comunicação sem fio, devido à natureza do meio,
não é possível utilizar a detecção de colisão da mesma maneira que no Ethernet, onde o
dispositivo pode transmitir e, ao mesmo tempo, ouvir o canal para detectar uma colisão.
No Wi-Fi, o problema é que a intensidade do sinal transmitido é muito maior próximo à
antena do emissor, o que dificulta a detecção de sinais externos. Para a detecção de colisões,
seria necessário ter receptores capazes de escutar múltiplos canais ao mesmo tempo, o que
tornaria o hardware muito caro e tecnologicamente complexo. Além disso, o ambiente

36
sem fio é afetado por diversas interferências, como ruídos e perdas de sinal, que podem
impactar a qualidade da transmissão. Por essa razão, o CSMA/CA adota um mecanismo
de confirmação (ACK - acknowledgment) na camada de enlace, em que o receptor confirma
o recebimento do frame enviado, ao invés de depender da detecção de colisões. Outra
limitação do protocolo CSMA/CA é o fenômeno conhecido como problema do terminal
oculto, onde um dispositivo pode não estar no alcance de todos os outros dispositivos da
rede, e, portanto, não ser capaz de detectar colisões que ocorrem fora do seu alcance. Além
disso, o enfraquecimento do sinal de recepção pode reduzir a capacidade do dispositivo
de detectar colisões, especialmente em longas distâncias. Outro fator que contribui para
a dificuldade de detecção de colisões é o fato de que a transmissão de dados é contínua:
uma vez que um dispositivo começa a enviar um frame, ele só para de transmitir quando
termina a comunicação, o que aumenta a chance de colisões, principalmente quando o
frame é longo. As colisões, por sua vez, degradam o desempenho da comunicação, e é aí
que o protocolo CSMA/CA entra em ação, tentando evitar colisões antes que elas ocorram
por meio de diferentes mecanismos de prevenção.

4.7.1 Transmissor
O dispositivo ouve o meio durante o DIFS (Distributed Inter Frame Space), se nenhuma
transmissão for detectada ele envia seus dados. Caso ele perceba uma transmissão no
canal durante o DIFS, ele calcula um tempo aleatório de recuo pelo backoff exponencial e
connta o tempo regressivamente até o canal estar ocioso. Quando o contador chegar a 0 e
o canal estiver livre ele transmmite o frame e aguarda o ACK, caso receba o ACK, então
retorna ao início. Se não receber espera tempo de recuo maior.
Quando uma estação deseja enviar um quadro de dados, ela escuta o canal para garantir
que ele está livre. Se o canal estiver ocupado, a estação deve esperar até que o canal se
torne livre e, em seguida, esperar o tempo DIFS para garantir que outras estações que
também estão esperando para transmitir tenham tempo de fazê-lo.

4.7.2 Receptor
O receptor recebe o frame e realiza o CRC, após isso, aguarda o SIFS (Short Inter
Frame Spacing), então devolve o ACK. Caso o ACK não for recebido, ele receberá o frame
de novo do transmissor, mas isso só ocorrre uma quantidade máxima de vezes, depois
apenas haverá descarte.
Intervalo de tempo mais curto usado para transmissões de controle (como ACK e
RTS/CTS), permitindo que essas mensagens de controle sejam transmitidas com alta
prioridade.
Pode-se adicionar RTS do transmissor e CTS do receptor, que alerta os nós ao alcance
para não transmitirem. Reduz colisão, mas aumenta overhead.

4.7.3 RTS e CTS

O protocolo CSMA/CA, utilizado em redes Wi-Fi, busca evitar colisões ao regular
o acesso ao meio de transmissão. Quando dois dispositivos percebem que o canal está
ocioso, eles não transmitem imediatamente, pois isso pode levar a uma colisão. Se ambos
começarem a transmitir simultaneamente, os frames serão enviados integralmente e o tempo
e a banda seriam desperdiçados. Isso ocorre porque, ao contrário do CSMA/CD, não é viável
detectar colisões em redes sem fio, devido à dificuldade de "colisão de detecção"(CD) em

37
ambientes com múltiplas fontes de interferência e problemas de recepção. Para minimizar
a chance de colisões, utiliza-se uma técnica de contagem regressiva aleatória antes de
transmitir. No entanto, em cenários onde os dispositivos estão ocultos uns aos outros (ou
seja, um dispositivo não consegue detectar a transmissão do outro), o problema é agravado,
levando à possibilidade de colisões entre terminais ocultos. Para resolver esse problema,
implementa-se o mecanismo Request-to-Send (RTS) e Clear-to-Send (CTS). O dispositivo
que deseja transmitir envia um quadro RTS ao ponto de acesso (AP), informando-o sobre
a intenção de transmitir e o tempo estimado para a transmissão. O AP, por sua vez,
responde com um quadro CTS, liberando o dispositivo para transmitir e notificando os
demais dispositivos da rede para não transmitirem durante esse período. Esse mecanismo
ajuda a mitigar o problema de terminais ocultos e melhora o desempenho da rede, embora
possa causar alguns atrasos devido à reserva de acesso ao meio.
Frames RTS e CTS são pequenos. Mas ainda podem causar atrasos.

4.8 Padrão IEEE 802.11

Ele define várias letras para indicar padrões, segurança e handoff (Negociação automá-
tica de troca de um AP para outro).
A camada física das redes sem fio é responsável por vários aspectos fundamentais,
incluindo a geração e remoção de parâmetros para sincronização, a recepção e transmissão
de bits, e a definição dos padrões de codificação de sinais. Ela especifica as técnicas
de modulação utilizadas para transmitir sinais de rádio através de uma ampla faixa de
frequências, permitindo que múltiplos dispositivos compartilhem o mesmo espectro sem
interferir uns com os outros. Entre as técnicas de modulação mais conhecidas estão o
CCK (Complementary Code Keying), o FHSS (Frequency Hopping Spread Spectrum), o
DSSS (Direct Sequence Spread Spectrum), o OFDM (Orthogonal Frequency Division Mul-
tiplexing) e o OFDMA (Orthogonal Frequency Division Multiple Access). Essas técnicas,
que foram adotadas em diferentes versões do padrão IEEE 802.11, são projetadas para
melhorar a eficiência da comunicação sem fio, aumentar a capacidade do sistema, reduzir
interferências eletromagnéticas e proporcionar maior segurança contra interceptações. Elas
são essenciais em redes Wi-Fi modernas, com o OFDM sendo amplamente utilizado em
padrões como 802.11a, g, n, ac, e ax, enquanto o FHSS e o DSSS foram mais comuns nas
primeiras gerações, com o FHSS ainda presente no Bluetooth.
O Wi-Fi 5 (802.11ac) é uma atualização do 802.11n, operando na faixa de 5 GHz, com
taxas de transmissão entre 500 Mbps e 1 Gbps em condições ideais. Ele utiliza tecnologias
como OFDM e MIMO (Multiple-Input Multiple-Output) para melhorar a eficiência de
dados e cobertura, permitindo a transmissão simultânea por vários caminhos de sinal.
O Wi-Fi 6 (802.11ax), sucessor do Wi-Fi 5, melhora a eficiência e a capacidade da rede
(agregação de portadora), com técnicas como OFDMA e MU-MIMO, permitindo taxas de
até 9,6 Gbps, operando em 2.4 GHz e 5 GHz, além de 6 GHz no Wi-Fi 6E. Já o Wi-Fi
7 (802.11be), com lançamento esperado para 2025, promete velocidades de até 46 Gbps,
utilizando a banda tripla (2.4 GHz, 5 GHz, 6 GHz) e canais de 320 MHz, representando
um aumento significativo em relação às gerações anteriores. Ele visa reduzir latência e
suportar um maior número de dispositivos simultâneos, embora o custo de implementação
ainda seja alto.
O MIMO (Multiple Input, Multiple Output) é uma tecnologia que utiliza múltiplas
antenas tanto no transmissor quanto no receptor para melhorar a qualidade e a eficiência
da transmissão de dados. Ao combinar as antenas, o MIMO permite que os dados

38
viajem por diversos caminhos de sinal simultaneamente, o que ajuda a reduzir erros,
otimizar a velocidade de transmissão e aumentar a capacidade do sistema de rádio. Além
disso, o MIMO contribui para o aumento da taxa de dados, ampliação da cobertura e
maior eficiência energética. Esta tecnologia está presente em todos os padrões Wi-Fi
desde o 802.11n, e o Wi-Fi 802.11ac pode suportar até 8 antenas em cada dispositivo,
potencializando ainda mais a performance da rede.
O Wi-Fi 7 introduz a tecnologia MLO (Multi-Link Operation), que permite aos
dispositivos conectarem-se simultaneamente a múltiplas bandas de frequência, como
2,4 GHz, 5 GHz e 6 GHz. Ao contrário das versões anteriores, onde os dispositivos
normalmente escolhiam apenas uma banda para transmitir dados, o MLO no Wi-Fi 7
possibilita a agregação dessas bandas, resultando em velocidades mais rápidas. Além
disso, ao utilizar as três bandas ao mesmo tempo, o Wi-Fi 7 oferece maior confiabilidade e
latência ultrabaixa e precisa, permitindo uma experiência de rede mais estável, mesmo
em ambientes congestionados. Isso também permite compartilhar dados redundantes ou
exclusivos de maneira eficiente, melhorando o desempenho geral da conexão sem fio.

4.9 Encerramento
• FHSS (Frequency Hopping Spread Spectrum):

– Originalmente para torpedos.

– O transmissor "pula"entre frequências de forma aleatória e rápida.
– O receptor sincroniza com o transmissor para recuperar o sinal original.

• DSSS (Direct Sequence Spread Spectrum):

– O sinal é modulado com um código de espalhamento pseudoaleatório.

– O receptor utiliza o mesmo código para demodular e recuperar o sinal.

• OFDM (Orthogonal Frequency Division Multiplexing):

– O sinal é dividido em sinais menores, cada um modulado em uma frequência

diferente.
– Os sinais são transmitidos simultaneamente em frequências diferentes.
– O receptor utiliza a modulação original para recuperar o sinal.

• CCK (Complementary Code Keying):

– O sinal é modulado com um "código complementar"pseudoaleatório.

– O receptor usa o mesmo código para demodular e recuperar o sinal.

• Rádios Cognitivos:

– Baseado no conceito de rádio definido por software (SDR).

– Permite o compartilhamento dinâmico do espectro e uso adaptativo das frequên-
cias.

• Faixa ISM (Industrial, Scientific and Medical):

39
 – Faixa de frequências livre para uso em aplicações industriais, científicas e
médicas.
– Dispositivos devem seguir limites de potência para evitar interferências.
– As faixas comuns incluem 902-928 MHz, 2.4-2.4835 GHz e 5.725-5.875 GHz.

5 Última matéria da prova - parte de segurança que

faltou
5.1 X.509
Um certificado X.509 é um padrão internacional que define o formato de certificados
digitais, amplamente usado em protocolos de segurança de rede, como TLS/SSL, e em
sistemas de autenticação. Ele é parte da infraestrutura de chaves públicas (PKI), que
permite a autenticação de identidades e o estabelecimento de comunicações seguras na
internet.
subsection*1. Qual a estrutura de um certificado X.509? Um certificado X.509 possui
uma estrutura padronizada que inclui os seguintes campos principais:

• Versão: define a versão do padrão X.509 usada pelo certificado.

• Número de série: identifica unicamente o certificado dentro da autoridade certifi-

cadora.

• Algoritmo de assinatura: especifica o algoritmo usado para assinar o certificado.

• Emissor: identifica a autoridade certificadora (CA) que emitiu o certificado.

• Validade: define o período de tempo durante o qual o certificado é válido.

• Sujeito: identifica a entidade à qual o certificado pertence (ex., um site ou indivíduo).

• Chave pública do sujeito: contém a chave pública do sujeito, que é usada para
criptografia e verificação de assinaturas digitais.

• Assinatura: é a assinatura digital da CA, validando a integridade do certificado.

• Extensões (opcionais): adiciona informações adicionais, como Uso da Chave e

Política de Certificado.

2. Como um certificado X.509 pode ser usado para assinar E-

mails?
Um certificado X.509 pode ser usado para assinar e-mails por meio do protocolo
S/MIME (Secure/Multipurpose Internet Mail Extensions). O processo funciona da seguinte
forma:

• O remetente gera uma assinatura digital usando sua chave privada associada ao
certificado X.509.

40
 • O certificado X.509 do remetente é anexado ao e-mail, permitindo ao destinatário
verificar a assinatura.

• O destinatário usa a chave pública contida no certificado X.509 do remetente para

validar a assinatura, garantindo que o e-mail veio do remetente e não foi alterado.

3. Como o processo de revogação de um certificado X.509 funciona,

e quais são os métodos usados para notificar os clientes de um
certificado comprometido?
O processo de revogação de um certificado X.509 envolve a invalidação do certificado
antes de sua data de expiração. Isso pode acontecer quando o certificado é comprometido,
ou a entidade associada ao certificado não está mais autorizada. Existem dois métodos
principais para notificar os clientes de um certificado revogado:

• Lista de Certificados Revogados (CRL - Certificate Revocation List): uma

lista publicada periodicamente pela CA que contém todos os certificados revogados.
Clientes podem consultar a CRL para verificar se um certificado foi revogado.

• Protocolo de Status de Certificado Online (OCSP - Online Certificate

Status Protocol): permite que o cliente consulte diretamente a CA sobre o status
de um certificado específico, fornecendo uma resposta em tempo real sobre a validade
do certificado.

5.2 TSL
protocolo TLS (Transport Layer Security), sucessor do SSL (Secure Sockets Layer), é
amplamente utilizado para proteger comunicações pela internet, não apenas para navegação
em sites, mas também para e-mails, mensagens e aplicações IoT, oferecendo segurança para
aplicações baseadas no protocolo TCP. Ele fornece autenticação do servidor, criptografia
dos dados e autenticação opcional do cliente, protegendo a troca de informações entre
cliente e servidor de forma segura.
Os principais serviços de segurança fornecidos por SSL/TLS incluem a autenticação do
servidor, garantindo que o cliente se conecte ao servidor correto; a criptografia dos dados
transmitidos, protegendo contra interceptações; e a autenticação opcional do cliente, que
permite que os servidores confirmem a identidade dos usuários, se necessário. Embora
o termo "SSL"ainda seja comumente usado para se referir a essas conexões seguras, o
protocolo SSL original é considerado obsoleto e inseguro, tendo sido substituído pelo TLS,
que passou a incorporar diversas melhorias de segurança e eficiência para proteger as
comunicações na internet.
O TLS funciona sobre a camada de transporte TCP, criando uma conexão segura por
meio de um processo chamado handshake. Esse processo é iniciado quando o cliente envia
um "Client Hello", informando a versão de TLS, os algoritmos de criptografia suportados
(chamados de cipher suites) e um número aleatório (nonce). O servidor responde com um
"Server Hello", confirmando a versão de TLS e o algoritmo de criptografia selecionado,
enviando seu certificado digital e um segundo nonce. O certificado do servidor é validado
pelo cliente usando a PKI (infraestrutura de chaves públicas), que garante que o servidor
é quem afirma ser.

41
 Após validar o certificado, o cliente gera um número aleatório chamado "Premaster
Secret", criptografa-o com a chave pública do servidor e o envia de volta. O servidor
decriptografa o Premaster Secret com sua chave privada, e agora ambos, cliente e servidor,
possuem os elementos necessários para derivar uma chave de sessão simétrica a partir
de uma função chamada PRF (Pseudo-Random Function), que utiliza os dois nonces e
o Premaster Secret. Essa chave de sessão é usada para criptografar e proteger todos os
dados trocados na conexão.
O processo de handshake é finalizado com o envio de uma mensagem "Change Cipher
Spec", que sinaliza que as mensagens subsequentes serão criptografadas usando a nova
chave de sessão. O cliente e o servidor confirmam o sucesso do handshake com uma
mensagem "Finished", criptografada com a chave de sessão. Após essa confirmação, os
dados são transmitidos de forma segura usando criptografia simétrica, geralmente AES,
garantindo confidencialidade e integridade na comunicação.
Esse processo garante uma comunicação autêntica e segura, protegendo dados de
interceptações e adulterações e estabelecendo um canal seguro entre cliente e servidor.
No protocolo TLS, a criação da Chave de Sessão é um processo criptográfico importante,
realizado com o auxílio de uma função chamada PRF (Pseudo-Random Function), que
transforma valores iniciais em uma série de chaves para proteger a comunicação. Esse
processo começa com o Premaster Secret, um valor gerado pelo cliente e criptografado
usando a chave pública do servidor. Esse valor é então decriptado pelo servidor durante
o processo de handshake, garantindo que ambos os lados possuam o mesmo valor inicial
para a geração das chaves.
Para reforçar a segurança e garantir que as chaves de sessão sejam únicas, o TLS
utiliza valores aleatórios chamados nonces, que são números gerados pelo cliente e servidor,
respectivamente denominados Client Random e Server Random. Esses números são
trocados no início do processo de handshake, durante as mensagens de Client Hello e
Server Hello. Eles atuam como um "sal"(salt), que aumenta a aleatoriedade das chaves
derivadas e evita que duas sessões possam gerar as mesmas chaves mesmo que o Premaster
Secret seja igual.
A função PRF, no contexto do TLS 1.2, combina o Premaster Secret e os nonces para
gerar a Master Secret, um valor intermediário essencial para a derivação de chaves. A
PRF usa HMAC, geralmente com os algoritmos SHA-256 ou SHA-1, para criar um valor
pseudo-aleatório robusto. A fórmula aplicada para gerar a Master Secret é: Master Secret
= PRF(Premaster Secret, "mastersecret", Client Random + Server Random). A Master
Secret, com um tamanho de 48 bytes, fornece uma base segura para o próximo passo, a
criação das chaves necessárias para a comunicação.
A partir da Master Secret, o protocolo usa novamente a PRF para criar um bloco de
chave chamado Key Block. Esse Key Block é criado a partir da Master Secret e é longo o
suficiente para gerar todas as chaves menores usadas na sessão. Ele é gerado pela fórmula
Key Block = PRF(Master Secret, "keyexpansion", Client Random + Server Random). Em
seguida, o Key Block é dividido em três chaves específicas: a Chave de Criptografia, a
Chave de Autenticação (ou MAC Key), e o IV (Initialization Vector). Cada uma dessas
chaves possui uma função específica na sessão TLS, como criptografar e decriptar dados
ou verificar a integridade dos dados transmitidos.
Por fim, como cliente e servidor compartilham o Premaster Secret e os nonces, ambos
podem executar o processo de PRF e gerar as mesmas chaves. Essas chaves derivadas são
então utilizadas ao longo da sessão TLS para manter a segurança da comunicação. Isso
inclui a criptografia dos dados, garantindo que eles permaneçam privados, e a verificação

42
de integridade, para assegurar que não foram alterados.

43