Princípios de Aplicações de Rede

Prévia do material em texto

Camada de Aplicação
● Aplicações são a grande razão para existir uma rede de 
computadores
– Qual a necessidade de projetar uma rede sem nenhuma 
aplicação?
– Aplicações vem evoluindo a mais de 40 anos
● Que aplicações?
– Aplicações clássicas de texto
– Transferência de arquivo
– Correio eletrônico
– World Wide Web
– Aplicações de áudio e vídeo 
– etc 
 
Princípios de aplicações de rede
● Nosso desafio é desenvolver aplicações que rodem em 
sistemas finais diferentes e se comuniquem entre si pela 
rede
– Heterogeneidade
● Além de levar em consideração os problemas: atraso, 
filas, perdas
● O desenvolvimento na camada de aplicação limite-se a 
sistemas finais
– O núcleo da rede executa apenas os níveis mais 
baixos
 
Arquiteturas de aplicação de rede
● Antes de codificar, é necessário elaborar um plano geral 
para a arquitetura da sua aplicação
● A arquitetura da aplicação é projetado pelo 
desenvolvedor e determina como a aplicação é 
organizada nos vários sistemas finais
● As duas mais utilizadas são:
– Cliente-servidor
– P2P
● Qual a diferença de uma arquitetura de rede e uma 
arquitetura de aplicação?
 
Princípios de aplicações de rede
● Em uma arquitetura cliente-servidor há um hospedeiro 
sempre em funcionamento, denominado servidor, que 
atende a requisições de muitos outros hospedeiros, 
denominados clientes
● Clientes não se comunicam entre si
● Servidor possui um endereço IP fixo
● Serviços como FTP, Web, e-mail utilizam a arquitetura 
cliente/servidor
● Datacenter é um conjunto de servidores que trabalham 
em conjunto para possibilitar as requisições dos muitos 
clientes
– Ex: Google, Facebook, Amazon
 
Princípios de aplicações de rede
● Em uma arquitetura P2P, a comunicação é direta entre 
pares de hospedeiros conectados alternadamente, 
denominados pares
● Pares não são de propriedade dos provedores de 
serviço, mas sim pelos sistemas finais de usuários
– Ex: BitTorrent (distribuição de arquivos), Emule 
(compartilhamento de arquivos), Telefonia pela 
internet
● Existem também muitas aplicações com arquiteturas 
hibridas (cliente-servidor e P2P)
 
Princípios de aplicações de rede
● Quais as vantagens de se usar uma arquitetura P2P?
– Autoescalabilidade (vários nós trabalhando e 
distribuindo carga de trabalho)
– Bom custo-beneficio, não requerem infraestrutura de 
servidor e larguras de banda de servidor
● E as desvantagens?
– Nem sempre a aplicação requerida executa em uma 
arquitetura que não seja cliente-servidor
– É necessário confiança nos nós
– Complexidade elevada (reparo, sincronização, etc)
– Segurança 
 
Princípios de aplicações de rede
 
Comunicação entre processos
● A comunicação nas redes de computadores é feita pelos 
processos
● Processos que rodam em um mesmo sistema final, se 
comunicam através da comunicação interprocessos 
(sistemas operacionais) 
● E entre sistemas finais diferentes, necessitamos de uma 
rede
 
A interface entre o processo e a 
rede de computadores
● A maioria das aplicações consiste em pares de 
processos comunicantes
– Qualquer mensagem enviada de um par ao outro 
necessita passar pela rede subjacente
● Um processo envia mensagens para a rede e recebe 
mensagens dela através de uma interface de software 
denominada socket
– Analogia ao socket: porta de uma casa – para mandar 
um pacote ele precisa passar pela porta. E no destino, 
precisa passar novamente pela porta
 
A interface entre o processo e a 
rede de computadores
Um socket é denominado a interface entre a camada de aplicação e a de transporte
É também a API (interface de programação) da aplicação
 
Serviços de transporte disponíveis 
para aplicações
● Toda comunicação via socket, possui um par de sockets: 
remetente e destinatário
● Mas qual protocolo da camada de transporte utilizar?
– Analogia: trem vs avião – em uma viagem o trem pode 
pode trazer facilidades de acesso, e o avião um menor 
tempo de viagem
● Então quais os serviços que um protocolo da camada de 
transporte pode oferecer às aplicações que o chamem?
– Classificação de maneira geral:
● Transferência confiável de dados
● Vazão
● Temporização
● Segurança
 
Transferência confiável de dados
● Como já vimos, os pacotes podem se perder na rede
● Alguns serviços não toleram a perda de pacotes
– Correio eletrônico, aplicações financeiras, etc
● Assim, para essas aplicações, algo deve ser feito para 
garantir a entrega do remente ao destinatário
– Mecanismos serão estudados mais a diante
● Outras aplicações podem não necessitar de uma 
transferência confiável de dados
– Áudio/video em tempo real 
 
Vazão
● Já sabemos o que é a vazão (throughput): bits/tempo
● A vazão pode sofrer oscilação, dependendo do estado 
que se encontra a rede
● Aplicações que possuam necessidade de vazão são 
conhecidas como aplicações sensíveis a largura de 
banda
● Aplicações elásticas podem fazer uso de qualquer 
quantidade mínima ou máxima que esteja disponível
– Correio eletrônico, transferência de arquivos
– Importante para sobreviver em uma Internet com 
muito congestionamento
● “Quanto mais vazão melhor!”
 
Temporização
● Um protocolo da camada de transporte pode também 
oferecer garantias de temporização
– Ex: cada bit que o remetente insere no socket chega 
ao socket destinatário em menos de 100 
milissegundos depois 
● Serviço eficiente para aplicações de tempo real
● Atrasos longos fazem com que a aplicação pareça 
menos realista (jogo multiusuário)
– Latência 
 
Segurança
● Um protocolo de transporte pode oferecer uma aplicação 
com um ou mais serviços de segurança
● Ex: Nos hospedeiros remetente/destinatário, um 
protocolo de transporte pode codificar todos os dados 
transmitidos (criptografia)
● Outros serviços, como integridade dos dados, 
autenticação do ponto terminal
 
Serviços de transporte providos 
pela Internet
● A Internet disponibiliza dois protocolos de transporte para 
aplicações: TCP e UDP
● Quando você cria uma aplicação, uma das primeiras 
decisões é qual protocolo de transporte utilizar
● Requisitos de algumas aplicações de rede:
 
Serviços do TCP
● TCP inclui um serviço orientado para conexão e um 
serviço confiável de transferência de dados
– Serviço orientado a conexão: o TCP faz com que o 
cliente e o servidor troquem informações de controle de 
camada de transporte antes que as mensagens de 
camada de aplicação comecem a fluir. Assim cliente e 
servidor se apresentam e se preparam para a 
enxurrada de pacotes que virá.
– Serviço confiável de transporte: os processos 
comunicantes podem confiar no TCP para a entrega de 
todos os dados enviados sem erro e na ordem correta.
● O TCP inclui também um mecanismo de controle de 
congestionamento (mecanismos que limita a capacidade 
de transmissão de um processo) 
 
Serviços do UDP
● O UDP é um protocolo de transporte simplificado leve, 
com um modelo de serviço minimalista
● É um serviço não orientado a conexão
● Provê serviço não confiável de transferência de dados
● Não inclui mecanismo de controle de congestionamento
● Utilizamos quando precisamos de velocidade e temos 
tolerância na aplicação desenvolvida 
 
Aplicações TCP e UDP
● Aplicações populares da Internet, seus protocolos de 
camada de aplicação e seus protocolos de transporte 
subjacentes
 
Endereçamento de processos
● Como um processo indica qual processo ele quer para 
se comunicar usando esses serviços?
– Um hospedeiro pode estar executando vários 
processos
– Eles se acham através do IP
– Mas é através de um número de porta do destino 
que consegue saber qual é o processo
– Ex: servidor web - porta 80, correio eletrônico – porta 
25
● Quando um desenvolvedor cria uma nova aplicação de 
rede, ela deve receber um novo número de porta 
 
Endereçamento de processos
● E quem é responsável pela padronização das portas?
– IANA - http://www.iana.org 
– Não apenas portas:
● “The InternetAssigned Numbers Authority (IANA) is 
responsible for the global coordination of the DNS 
Root, IP addressing, and other Internet protocol 
resources”
 
Protocolos de camada de aplicação
● Um protocolo de camada de aplicação define como 
processos de uma aplicação, que funcionam em 
sistemas finais diferentes, passam mensagens entre si
● Em particular, um protocolo de camada de aplicação 
define:
– Os tipos de mensagens trocadas;
– A sintaxe dos vários tipos de mensagens, tais como os 
campos da mensagem e como os campos são 
delineados;
– A semântica dos campos, isto é, o significado da 
informação nos campos;
– Regras para determinar quando e como um processo 
envia mensagens e responde a mensagens. 
 
A Web e o HTTP
● A Web é a aplicação da Internet que chamou a atenção 
do público em geral
– Ela transformou drasticamente a maneira como 
pessoas interagem dentro e fora de seus ambientes 
de trabalho
● Parte do seu sucesso se deve ao seu funcionamento: 
sob demanda (diferente da TV ou Rádio atuais)
● HTTP é o protocolo utilizado na Web 
 
A descrição geral do HTTP
● O HTTP – Protocolo de Transferência e Hipertexto 
(Hypertext Transfer Protocol) – protocolo da camada de 
aplicação da Web
● É implementado em dois programas: um programa 
cliente e outro servidor
– Os dois programas conversam através da troca de 
mensagens HTTP
– HTTP define a estrutura dessas mensagens e o modo 
como o cliente e o servidor as trocam
 
A descrição geral do HTTP
● Terminologia:
– Uma página Web é constituída de objetos. 
– Um objeto é simplesmente um arquivo (um arquivo 
HTML, uma imagem JPEG)
– Páginas Web, sem sua maioria, são constituídas de 
um arquivo-base HTML, e diversos objetos 
referenciados
– Uma URL contém dois componentes: o nome do 
hospedeiro do servidor que abriga o objeto e o nome 
do caminho do objeto
ex: 
http://www.someSchool.edu/someDepartment/pictur
e.gif 
 
A descrição geral do HTTP
● Terminologia:
– Browser implementam HTTP (cliente ou servidor)
● O HTTP define como clientes Web requisitam páginas 
Web aos servidores e como eles as transferem a clientes
 
A descrição geral do HTTP
● O HTTP utiliza o TCP como seu protocolo de transporte 
subjacente
● O cliente envia mensagens de requisição HTTP para sua 
interface socket e recebe mensagens de resposta HTTP 
de sua interface socket
● O servidor HTTP recebe mensagens de requisição de 
sua interface socket e envia mensagens de resposta 
para sua interface socket
● HTTP é um protocolo sem estado, ou seja, quando um 
servidor recebe uma solicitação ele não mantém o 
estado (cache). Caso recebe imediatamente depois a 
mesma solicitação, ele envia novamente tudo de novo
 
Conexões persistentes e não 
persistentes
● HTTP não persistente: a conexão TCP é desfeita no final 
da entrega de cada objeto. A conexão não PERSISTE para 
outros objetos. O browser pode abrir várias conexões TCP 
simultâneas (paralelismo). Pode sobrecarregar o Servidor 
e tem maior tempo de resposta (requisição de conexão a 
cada objeto solicitado)
● HTTP Persistente: Múltiplos objetos podem ser enviados 
sobre uma mesma conexão TCP (com paralelismo ou sem 
paralelismo). Sem paralelismo, o Servidor fica ocioso entre 
o final do envio do objeto e a recepção da requisição de 
envio do próximo objeto (desperdício de recurso) e maior 
tempo de reposta para montar a página WEB. 
● O HTTP utiliza conexões persistentes por padrão (mas 
pode ser configurado para não persistente) 
 
O HTTP com conexões não 
persistentes
● Vamos percorrer as etapas de transferência de uma página 
Web de um servidor para um cliente para o caso de 
conexões não persistentes
● Supondo que a página consista em um arquivo-base HTML 
e em dez imagens JPEG (tudo residindo no mesmo 
servidor)
● Supondo que a URL seja, http://www.someSchool.edu/ 
someDepartment/home.index 
● Eis o que acontece:
1. O processo cliente HTTP inicia uma conexão TCP para 
o servidor www.someSchool.edu na porta número 80, que 
é o número de porta default para o HTTP. Associados à 
conexão TCP, haverá um socket no cliente e um socket 
no servidor 
http://www.someSchool.edu/
http://www.someSchool.edu/
 
O HTTP com conexões não 
persistentes
● Eis o que acontece:
2. O cliente HTTP envia uma mensagem de 
requisição HTTP ao servidor através de seu socket. 
Essa mensagem inclui o nome de caminho 
/someDepartment/home.index
3. O processo servidor HTTP recebe a mensagem de 
requisição através de seu socket, extrai o objeto 
/someDepartment/home.index de seu 
armazenamento (RAM ou disco) encapsula o objeto 
em uma mensagem de resposta HTTP e a envia ao 
cliente através de seu socket 
 
O HTTP com conexões não 
persistentes
● Eis o que acontece:
4. O processo servidor HTTP ordena ao TCP que 
encerre a conexão TCP. (Mas na realidade, o TCP só 
encerrará a conexão quando tiver certeza de que o 
cliente recebeu a mensagem de resposta intacta.)
5. O cliente HTTP recebe a mensagem de resposta e 
a conexão TCP é encerrada. A mensagem indica que 
o objeto encapsulado é um arquivo HTML. O cliente 
extrai o arquivo da mensagem de resposta, analisa o 
arquivo HTML e encontra referências aos dez objetos 
JPEG. 
 
O HTTP com conexões não 
persistentes
● Eis o que acontece:
6. As primeiras quatro etapas são repetidas para cada 
um dos objetos JPEG referenciados
● À medida que recebe a página Web, o browser a 
apresenta ao usuário
● Dois browsers diferentes podem interpretar uma página 
Web de modos ligeiramente diferentes
– O HTTP não tem nada a ver com o modo como uma 
página Web é interpretada por um cliente 
 
O HTTP com conexões não 
persistentes
● Podemos estimar o tempo entre a requisição e o 
recebimento de um arquivo-base HTML por um cliente
– Para tal, definimos o tempo de viagem de ida e volta 
(round-trip time – RTT) (tempo que um pacote viaja do 
cliente ao servidor e de volta ao cliente)
– O RTT inclui atrasos de propagação de pacotes, de 
fila de pacotes e de processamento de pacotes
● A próxima figura explica esse tempo
 
O HTTP com conexões não 
persistentes
 
O HTTP com conexões não 
persistentes
● A requisição de um pacote para iniciar a transmissão 
com o servidor causa um RTT (estabelecimento de 
conexão TCP)
● A requisição para transferência de um arquivo do 
servidor, gasta mais um RTT
● Assim, aproximadamente, o tempo total de resposta são 
dois RTTs mais o tempo de transmissão do arquivo 
HTML no servidor
 
O HTTP com conexões persistentes
● Conexões não persistentes têm algumas desvantagens
– Uma nova conexão deve ser estabelecida e mantida 
para cada objeto solicitado
– Para cada uma dessas conexões devem ser alocados 
buffers TCP e conservadas variáveis TCP tanto no 
cliente quanto no servidor
– Isso pode sobrecarregar seriamente o servidor Web
– Além disso, cada objeto sofre dois RTTs
 
O HTTP com conexões persistentes
● Em conexões persistentes, o servidor deixa a conexão 
aberta após enviar resposta
● Requisições e respostas subsequentes entre os mesmos 
cliente e servidor podem ser enviadas por meio da mesma 
conexão
● Uma página Web inteira (como no exemplo anterior) pode 
ser enviada mediante uma única conexão TCP persistente
● Conexão é fechada quando ela não é usada durante um 
certo tempo (configurável)
– Como você faria para configurar esse tempo?
● Por default do HTTP, usa conexões persistentes com 
paralelismo
 
Cadeia de Threads
● Cada requisição ao servidor é atendida por uma thread
● A criação/finalização de threads traz alguns problemas: 
overhead
– Servidor Web: recebe muitas conexões por segundo
● Criar e terminar inúmeras threads é um trabalho muito 
grande
● Trabalha-se com um número ilimitado de threads: 
término dos recursos
● Solução: utilizar cadeia de threads em espera
– Na inicialização do processo, cria-se um número adequado 
de threads
– As threads permanecem aguardando para entrar em 
funcionamentoCadeia de Threads
– Quando o servidor recebe uma solicitação, desperta 
uma thread da cadeia (se houver disponível, senão 
espera) e repassa trabalho
– Quando thread completa serviço, volta à cadeia de 
espera
● Vantagens: mais rápido que criar thread, limita recursos
● Número de threads: relacionado aos recursos 
disponíveis
 
Formato da mensagem HTTP
● As especificações do HTTP [RFC 2616] definem o 
formato das mensagens HTTP
● Existem dois tipos de mensagens HTTP:
– Requisição
– Resposta
 
Mensagem de requisição HTTP
● Constituído de linha de requisição (primeira linha) e 
linhas de cabeçalho (linhas seguintes)
● Linha de requisição tem três campos: campo do método, 
o do URL e o da versão do HTTP
 
Mensagem de requisição HTTP
● A linha Host especifica o hospedeiro onde o objeto reside
– Importante principalmente para fornecer informação 
aos armazenadores intermediários da Web
● Na linha Connection: close o browser está dizendo ao 
servidor que não quer usar conexões persistentes, quer 
que o servidor feche a conexão após o envio do objeto
● A linha User-agent: especifica o agente de usuário, ou 
seja, tipo de browser que está fazendo a requisição
● Accept-language é um dos muitos cabeçalhos de 
negociação de conteúdo disponíveis no HTTP
 
Mensagem de resposta HTTP
● Tipicamente, uma mensagem de resposta possui uma 
linha de estado, linhas de cabeçalho (seis neste 
exemplo) e em seguida o corpo da entidade (onde 
contém o objeto da mensagem) 
 
Mensagem de resposta HTTP
● Linha de estado tem três campos: campo da versão do protocolo, 
um código de estado e uma mensagem de estado 
correspondente
– O servidor usado é o HTTP/1.1 e está tudo 200 OK (encontrou 
o objeto solicitado) (outra exemplo de estado e mensagem: 
400 Bad Request, quando não pode ser atendido)
● Connection: Close informa que fechará a conexão após enviar a 
mensagem
● Date: indica hora e data em que a resposta HTTP foi criada e 
enviada pelo servidor
● Server: mostra que a mensagem foi gerada por um servidor Web 
Apache análogo ao User-agent:
● Last Modified: indica hora e data em que o objeto foi criado ou 
sofreu a última modificação 
 
Mensagem de resposta HTTP
● Content-Length: indica o número de bytes do objeto que 
está sendo enviado
● Content-Type: mostra o tipo do objeto, no caso um texto 
HTML
● Todas essas informações são fundamentais para fazer 
cache na rede
● Além disso, percebem como iniciamos um ataque?
– Colhendo informações (estudaremos mais para frente 
a parte de segurança)
 
Caches Web
● Um cache Web – também denominado servidor proxy 
– é uma entidade da rede que atende requisições HTTP 
em nome de um servidor Web de origem
● O cache Web tem seu próprio disco de armazenamento 
e mantém, dentro dele, cópias de objetos recentemente 
requisitados
● Como mostrado na próxima figura, o browser de um 
usuário pode ser configurado de modo que todas as 
suas requisições HTTP sejam dirigidas primeiramente ao 
cache Web
 
Caches Web
 
Caches Web
● Exemplo: suponha que um browser esteja requisitando o 
objeto http://www.someschool.edu/campus.gif
● Eis o que acontece:
1. O browser estabelece uma conexão TCP com o 
cache Web e envia a ele uma requisição HTTP para 
um objeto
2. O cache Web verifica se tem uma cópia do objeto 
armazenada localmente. Se tiver, envia o objeto ao 
browser do cliente, dentro de uma mensagem de 
resposta HTTP 
http://www.someschool.edu/campus.gif
 
Caches Web
3. Se não tiver o objeto, o cache Web abre uma 
conexão TCP com o servidor de origem, isto é, com 
www.someschool.edu. Então, envia uma requisição 
HTTP do objeto para a conexão TCP. Após receber 
essa requisição, o servidor de origem envia o objeto 
ao cache Web, dentro de uma resposta HTTP
4. Quando recebe o objeto, o cache Web guarda uma 
cópia em seu armazenamento local e envia outra, 
dentro de uma mensagem de resposta, ao browser do 
cliente (pela conexão TCP existente entre o browser 
do cliente e o cache Web) 
● Caso a informação não esteja no cache, overhead 
adicional! Vale a pena?
http://www.someschool.edu/
 
Caches Web
● Por exemplo: uma universidade poderia instalar um 
cache na rede de seu campus e configurar todos os 
browsers apontando para esse cache
● Cache Web é utilizado amplamente na Internet por duas 
razões:
– Pode reduzir substancialmente o tempo de resposta 
para a requisição de um cliente (objeto está “mais 
perto”)
– Podem reduzir substancialmente o tráfego no enlace 
de acesso de uma instituição qualquer à Internet 
(caso o objeto estiver no cache, não precisa ir até o 
servidor)
 
Caches Web
● E se o objeto ficar desatualizado no cache?
– Existe um mecanismo para resolver esse problema: 
GET condicional
● Verifica se os objetos estão atualizados
– Através das datas de últimas atualizações (presentes 
nas mensagens HTTP)
 
Transferência de arquivo: FTP
● Em uma sessão FTP típica, o usuário, em um 
hospedeiro local, quer transferir arquivos para um 
hospedeiro remoto
– Para isso é necessário uma identificação e senha
– Somente após autorizado, a transferência é feita
 
Transferência de arquivo: FTP
● A interação do usuário é través de um agente de usuário 
FTP
– Primeiro, fornece o nome do hospedeiro remoto (para 
que seja estabelecida uma conexão TCP – 
cliente/servidor)
– Então o usuário fornece identificação e senha, 
enviado pela conexão TCP
– Caso seja autorizado pelo servidor, usuário copia os 
arquivos solicitados (vice-versa)
 
Transferência de arquivo: FTP
● O protocolo FTP utiliza duas conexões TCP paralelas para 
transferir um arquivo: conexão de controle e conexão de 
dados
● Conexão de controle envia informações de controle entre 
os dois hospedeiros (identificação, senha, comandos para 
trocar diretórios remotos, etc)
– É permanente, ou seja, uma sessão fica aberta durante 
todo o processo
● Conexão de dados é usada para efetivamente enviar o 
arquivo
– Não é permanente, ou seja, transfere um arquivo a cada 
conexão 
 
 
Transferência de arquivo: FTP
● Durante uma sessão, o FTP deve manter informações de 
estado sobre o usuário
– Por ter de manter uma sessão de controle, possui um 
limite menor no número de sessões possíveis
● Acesso:
ftp://[username]:[password]@[servidor]
ou
ftp://[username]:[password]@[servidor]:[porta]
 
FTP passivo e ativo
● FTP ativo: cliente abre uma conexão de controle na 
porta 21 para o servidor, e sempre que o cliente pede 
dados ao servidor, o servidor abre uma sessão de TCP 
na porta 20
– FTP ativo é o utilizado por
 padrão
 
FTP passivo e ativo
● FTP passivo: Este modo de operação é mais seguro 
porque todas as conexões estão sendo iniciadas do 
cliente, assim há menor chance de comprometer a 
conexão. A razão de ser chamado de passivo é que o 
servidor executa um " passive open".
– No FTP passivo, o cliente abre uma conexão de 
controle na porta 21 para o servidor, e então faz 
pedidos de modo passivo pelo uso do " comando de 
PASV "
– O servidor concorda com este modo, e então 
seleciona um número de porta randomicamente 
(>1023), provendo este número de porta para o 
cliente fazer transferência de dados
 
FTP passivo e ativo
– O cliente recebe esta informação e abre um canal de 
dados para a porta do servidor-designado
 
FTP passivo e ativo
● FTP ativo e passivo podem ser configurados
– Mas são passiveis de falhas devido a Firewalls
– Alguns Firewalls podem bloquear certas portas
● Link:http://pop-rs.rnp.br/~berthold/etcom/redes2-
2000/trabalhos/FTP_EltonMarques.htm
 
Correio eletrônico na Internet
● Foi uma das aplicações mais populares desde quando a 
Internet surgiu
● E-mail é um meio de comunicação assíncrono – pessoas 
enviam e recebem mensagens quando for conveniente
● Agente: permite que um usuário leia, responda, 
retransmite, salve e componha uma mensagem. 
Normalmente utilizada uma Interface Gráfica de Usuário 
(GUI). Ex: GMAIL, Thunderbird● Servidor de correio: formam o núcleo da infraestrutura do 
e-mail. Cada destinatário tem uma caixa postal localizada 
em um dos servidores
● SMTP: principal protocolo de camada de aplicação 
utilizado 
 
Correio eletrônico na Internet
 
 
SMTP
● Simple Mail Transfer Protocol - Transfere mensagens de 
servidores de correio remetentes para servidores de 
correio destinatários (definido no RFC 5321)
● Utiliza TCP
● Operação básica:
1. Alice chama seu agente de usuário para e-mail, 
fornece o endereço de Bob (ex, 
bob@someschool.edu), compõe uma mensagem e 
instrui o agente de usuário a enviar a mensagem
2. O agente de usuário de Alice envia a mensagem 
para seu servidor de correio, onde ela é colocada em 
uma fila de mensagens 
mailto:bob@someschool.edu
 
SMTP
● Operação básica:
3. O lado cliente do SMTP, que funciona no servidor 
de correio de Alice, vê a mensagem na fila e abre uma 
conexão TCP para um servidor SMTP, que funciona 
no servidor de correio de Bob
4. Após alguns procedimentos iniciais de 
apresentação, o cliente SMTP envia a mensagem de 
Alice para dentro da conexão TCP
5. No servidor de correio de Bob, o lado servidor do 
SMTP recebe a mensagem e a coloca na caixa postal 
dele
6. Bob chama seu agente de usuário para ler a 
mensagem quando for mais conveniente para ele
 
SMTP
● SMTP normalmente não usa servidores intermediários
– Comunicação direta entre servidores dos clientes
 
SMTP
● O cliente SMTP faz com que o TCP estabeleça conexão 
na porta 25 com o servidor SMTP
● Uma vez estabelecida, servidor e cliente trocam 
procedimentos de apresentação
 
Protocolos de acesso ao correio
● Atualmente utilizamos a arquitetura cliente-servidor
● Assim, mensagens ficam armazenadas em um servidor, 
para posteriormente serem solicitadas
● Mas o SMTP não oferece operação de recuperação de 
mensagens (apenas “empurra”) 
– Para tal, utilizamos protocolos com recuperação de 
informação: POP3, IMAP ou o HTTP
– Assim podemos acessar nosso servidor de e-mails e 
recuperar as mensagens
 
Leitura
● http://pop2imap.com/index.php
● Artigo: Performance Evaluation of Mail Systems (Está no 
Moodle)
http://pop2imap.com/index.php
 
DNS: o serviço de diretório da Internet
● Com qual nome podemos identificar um hospedeiro?
– Para seres humanos, é mais fácil aqueles mais 
semelhantes a linguagem natural, como cnn.com ou 
ufgd.edu.br (human readable)
– Para computadores, muito oneroso a linguagem 
natural, mais fácil processar números, como 
121.7.106.83 (IP)
● Hospedeiros são identificados de ambas as formas
● Para conciliar as duas preferências, utilizamos o DNS
 
Serviços fornecidos pelo DNS
● O DNS – Domain Name Service – é um serviço de 
diretório que traduz nomes de hospedeiros para 
endereços IP
● O DNS é:
1. um banco de dados distribuído implementado em 
uma hierarquia de servidores de nome (servidores 
DNS)
2. um protocolo de camada de aplicação que permite 
que hospedeiros consultem o banco de dados 
distribuído 
● Servidores de nome são frequentemente máquinas UNIX 
executando o software BIND (Berkeley Internet Name 
Domain)
 
Serviços fornecidos pelo DNS
● O protocolo DNS utiliza UDP e usa a porta 53
● DNS é utilizado por qualquer protocolo que precise 
traduzir nomes de hospedeiros para endereços IP – tais 
como HTTP, SMTP e FTP
● Exemplo de funcionamento: usuário requisita 
www.someschool.edu/index.html em seu browser 
(solicitação HTTP). Para que a máquina do usuário 
possa enviar uma mensagem de requisição HTTP ao 
servidor Web www.someschool.edu, precisa 
primeiramente obter o endereço IP do servidor:
1. A própria máquina do usuário executa o lado cliente 
da aplicação DNS
http://www.someschool.edu/index.html
http://www.someschool.edu/
 
Serviços fornecidos pelo DNS
2. O browser extrai o nome do hospedeiro, 
www.someschool.edu, do URL e passa o nome para o 
lado cliente da aplicação DNS
3. O cliente DNS envia uma consulta contendo o 
nome do hospedeiro para um servidor DNS
4. O cliente DNS finalmente recebe uma resposta, 
que inclui o endereço IP correspondente ao nome de 
hospedeiro
5. Tão logo o browser receba o endereço do DNS, 
pode abrir uma conexão TCP com o processo 
servidor HTTP localizado naquele endereço IP
http://www.someschool.edu/
 
Serviços fornecidos pelo DNS
● Essa busca pelo DNS pode gerar mais um atraso 
substancial na rede (acrescentar na fórmula)
● Como melhorar esse atraso?
– Cache! Muitas vezes o endereço IP procurado está no 
cache de um servidor DNS 'próximo'
– Ajuda a reduzir o tráfego DNS da rede, e o atraso 
médio do DNS
● Além da tradução de nomes de hospedeiros, o DNS 
provê alguns outros serviços importantes:
– Apelidos de hospedeiro, apelidos de servidor de 
correio e distribuição de carga
 
Serviços fornecidos pelo DNS
● Apelidos de hospedeiro : um hospedeiro com nome 
complicado pode ter um ou mais apelidos. Por exemplo, 
relay1.west-coast.enterprise.com pode ter um apelido 
como enterprise.com 
– O primeiro nome é denominado nome canônico
– Apelidos são mais fáceis de lembrar do que os nomes 
canônicos
– O DNS pode ser chamado por uma aplicação para 
obter o nome canônico correspondente a um apelido 
fornecido, bem como obter o endereço IP do 
hospedeiro
 
Serviços fornecidos pelo DNS
● Apelidos de servidor de correio : endereços de e-mails 
também devem ser fáceis de lembrar
– O DNS pode ser chamado por uma aplicação de 
correio para obter o nome canônico a partir de um 
apelido fornecido
– Servidores Web e de e-mail podem ter o mesmo 
nome (apelidos), graças ao registro MX
http://en.wikipedia.org/wiki/MX_record
 
Serviços fornecidos pelo DNS
● Distribuição de carga : O DNS também é utilizado para 
realizar distribuição de carga entre servidores replicados
– Sites movimentados como cnn.com são replicados 
em vários servidores, sendo que cada servidor roda 
em um sistema final diferente e tem endereço IP 
diferente
– DNS faz rodízio entre os servidores replicados de 
acordo com as solicitações que vão chegando 
 
Visão geral do modo de funcionamento 
do DNS
● Porque não utilizamos um servidor DNS central, 
contendo todos os mapeamentos?
– Um único ponto de falha
– Volume de tráfego
– Banco de dados centralizado distante
– Manutenção (atualizado frequentemente para 
atender todos os hospedeiros) 
● Em resumo, um único servidor DNS centralizado não é 
escalável
– Portanto ele precisa ser distribuído
 
Visão geral do modo de funcionamento 
do DNS
● O DNS usa um grande número de servidores, 
organizados de maneira hierárquica e distribuídos por 
todo o mundo
● Nenhum servidor de nomes isolado tem todos os 
mapeamentos para todos hospedeiros da Internet
● Há três classes de servidores de nomes: servidores de 
nomes raiz, servidores DNS de domínio de alto nível 
(Top-Level Domain – TLD) e servidores DNS com 
autoridade
 
Visão geral do modo de funcionamento 
do DNS
● Servidores de nomes raiz : Na Internet há 13 
servidores de nome raiz (denominados de A a M) e a 
maior parte deles está localizada na América do Norte. 
Embora tenhamos nos referido a cada um dos 13 
servidores de nomes raiz como se fossem um servidor 
único, na realidade, cada um é um conglomerado de 
servidores replicados, para fins de segurança e 
confiabilidade
– http://www.root-servers.org/presentations/rootops-gac-
rio.pdf 
 
Visão geral do modo de funcionamento 
do DNS
 
Visão geral do modo de funcionamento 
do DNS
● Servidores de nomes de Domínio de Alto Nível : 
Esses servidores são responsáveis por domínios de alto 
nível como .com, .org, .net e de países .br, .fr
● Servidores de nomes com autoridade : toda 
organização que tiver hospedeiros que possam ser 
acessados publicamente na Internet deve fornecer 
registros DNS também acessíveis publicamente que 
mapeiem os nomes desses hospedeiros para endereços 
IP. Um servidor DNS com autoridade de uma 
organização abriga esses registros.Pode ser 
implementado pela própria organização, ou armazenar 
em um servidor DNS com autoridade de algum provedor 
de serviço (fica a critério da organização)
 
Visão geral do modo de funcionamento 
do DNS
● Servidor de nome local : O servidor de nome local não 
pertence a hierarquia de servidores DNS mas é central 
para o seu funcionamento. Cada ISP (Provedor de 
Internet) como universidades e grandes empresas possui 
um ou mais servidores DNS locais, quando um 
hospedeiro se conecta a um ISP este fornece um ou 
mais IPs de servidores DNS locais normalmente por 
DHCP.
 
Visão geral do modo de funcionamento 
do DNS
● Cada requisição, obtêm
IPs de outros servidores
até encontrar o IP do
destino 
 
Cache DNS
● Melhora o desempenho quanto ao atraso e reduz o 
número de mensagens DNS pela Internet
● O Servidor de nomes local, 
pode fazer cache de toda 
consulta realizada, em 
sua memória local
● Além disso, cada servidor
pode fazer cache do 
servidor superior
 
Leitura
● Mensagens DNS: livro páginas 103-104
link: http://technet.Microsoft.Com/pt-br/library/dd 
197470%28v= ws.10%29.aspx
● Artigo: A precise and Efficient Evaluation of the Proximity 
between Web Clients and their Local DNS Servers (está 
no Moodle)
● Vulnerabilidades do DNS: livro página 105
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	Slide 74
	Slide 75
	Slide 76
	Slide 77
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84