2 Aplicacao

Capítulo 2
Camada de Aplicação
A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in powerpoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously Computer Networking:
represent a lot of work on our part. In return for use, we only ask the
A Top Down Approach
following:
q If you use these slides (e.g., in a class) in substantially unaltered form, Featuring the Internet,
2 edition.
that you mention their source (after all, we’d like people to use our book!) nd
q If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and Jim Kurose, Keith Ross
Addison-Wesley, July
note our copyright of this material.
Thanks and enjoy! JFK/KWR 2002.
All material copyright 1996-2002

J.F Kurose and K.W. Ross, All Rights Reserved
Versão em Português copyright 2003 Paulo Rogério Pereira.
Camada de Aplicação 2-1
Capítulo 2: Camada de Aplicação
Objectivos: ❒ Aprender os protocolos
examinando protocolos populares

❒ conceitos, aspectos
da camada de aplicação
de implementação dos
HTTP (HyperText Transfer
protocolos de
❍
Protocol)
aplicação em rede
❍ FTP (File Transfer Protocol)
❍ modelos de serviço
❍ SMTP (Simple Mail Transfer
da camada de Protocol) / POP3 (Post Office
transporte Protocol) / IMAP (Internet Mail
Access Protocol)
❍ paradigma cliente-
DNS (Domain Name System
servidor
❍
protocol)
❍ paradigma par-par
❒ Programação de aplicações de
(peer-to-peer)
rede
❍ API dos sockets

Capítulo 2: Sumário
❒ 2.1 Princípios dos ❒ 2.6 Programação em
protocolos da camada Sockets com TCP
de aplicação ❒ 2.7 Programação em
❍ clientes e servidores Sockets com UDP
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.9 Distribuição de
❒ 2.3 FTP
conteúdos
❒ 2.4 Correio electrónico ❍ Redes de caches Web
❍ SMTP, POP3, IMAP ❍ Redes de distribuição de
❒ 2.5 DNS conteúdos
❍ partilha de ficheiros P2P
Aplicações de Rede: terminologia
Processo: programa Agente de utilizador (user
correndo numa máquina. agent): faz a interface
❒ numa mesma máquina, entre o utilizador acima
dois processos e a rede abaixo.
comunicam usando ❒ implementa a interface
comunicação entre com o utilizador e o
processos (definida protocolo de camada de
pelos SO). aplicação
❒ processos correndo em ❍ Web: browser
máquinas diferentes ❍ E-mail: programa de
correio
comunicam através de
áudio/vídeo: media player

um protocolo da camada ❍
de aplicação
Aplicações e protocolos de camada de aplicação
Aplicação: processo distribuído
em comunicação

Ex: email, FTP, Web
!"!#$
❍ %& '( )*
❍ executada em sistemas
terminais da rede em espaço
de utilizador (user
user-space)
space
❍ troca mensagens para
implementar a aplicação
Protocolos da camada de
aplicação
+,.- ( ) +/0 *
uma parte da aplicação
+ ,.- ( ) +/0 * 12 +3 ' , * 21
4
❍ 12 +3 ' , * 214 24564
2454
define as mensagens trocadas
❍ - ( 7 8 5 + 5 *'
- ( 7 8 5 + 5 *' %& '( )*
entre as aplicações e as acções
%& '( )*
a executar
❍ utiliza os serviços de
comunicação dos níveis
inferiores (TCP, UDP).

O que os protocolos de aplicação definem
❒ Tipos de mensagens Protocolos de domínio
trocadas, eg, mensagens público:
de pedidos e respostas ❒ definidos em RFCs
❒ Sintaxe dos tipos de ❒ permitem

mensagem: que campos interoperabilidade
nas mensagens e como os
❒ eg, HTTP, SMTP
campos são delineados
Protocolos proprietários:
❒ Semântica dos campos,
❒ eg, KaZaA
ie, significado da
informação nos campos
❒ Regras para quando e
como enviar e responder
a mensagens
O paradigma Cliente-Servidor
Aplicações de rede típicas têm
duas partes: Cliente e Servidor

Cliente:
inicia o contacto com o Servidor

9:.; < =9>?@
❒ AB 9CD:@ BA
E
(fala primeiro)
BEFE
; < G H F 9 F @D
IJ D< =@
❒ tipicamente, requisita serviços ao
Servidor pedido
❒ Web: Cliente implementado num
browser;
e-mail: Cliente implementado num
programa de correio
resposta
Servidor:
9:.; < =
9>?@
AB 9CD:@ BA
E
❒ fornece os serviços requisitados BEFE
; < G H F 9 F @D
pelos Clientes IJ D< =@
❒ Servidor Web envia páginas pedidas;
Servidor de correio entrega emails.
Processos em comunicação pela rede
❒ os processos
cliente ou cliente ou
enviam/recebem mensagens servidor servidor
para/do seu socket
controlado pelo
❒ socket análogo a uma porta programador da
processo aplicação processo
❍ o processo que envia empurra
a mensagem para fora da

socket socket
porta TCP com TCP com

buffers, Internet buffers,
❍ o processo que envia assume
variáveis variáveis
que uma infra-estrutura de
transporte do outro lado da

controlado
porta leva a mensagem até ao
pelo SO
socket do processo que
recebe
❒ API (Interface de Programação de Aplicação):
(1) escolha do protocolo de transporte;

(2) possibilidade de definir alguns parâmetros
2-8
Endereçar processos:
❒ Para um processo receber ❒ O identificador inclui
mensagens, tem de ter um tanto o endereço IP
identificador como o número do
❒ Cada máquina tem um porto associado com o
endereço IP único de 32 processo na máquina.
bits ❒ Exemplos de números
❒ Q: o endereço IP da de portos:
máquina onde o processo ❍ servidor HTTP: 80
corre é suficiente para ❍ servidor Mail: 25
identificar o processo? ❒ Mais sobre isto depois
❒ Resposta: Não, pode haver
muitos processos a correr
na mesma máquina
Que serviços de transporte é que uma
aplicação necessita?
Perda de dados Largura de Banda

❒ Algumas aplicações toleram
❒ Algumas aplicações
algumas falhas
requerem um ritmo mínimo
❍ ex: áudio
para funcionarem
❒ Outras aplicações requerem
adequadamente
100% de fiabilidade na
❍ ex: aplicações multimédia
transferência de dados
❒ Outras aplicações utilizam a
❍ ex: transferência de ficheiros
largura de banda que

❍ Telnet
conseguirem obter
Timing
❍ ex: aplicações elásticas
❒ Algumas aplicações
requerem um atraso
pequeno para funcionarem
adequadamente
❍ ex: Telefonia na Internet
❍ Jogos interactivos

Requisitos do serviço de transporte para as
aplicações comuns
Perda de Largura de Sensibilidade

Aplicação dados banda ao atraso
Transferência de ficheiros Não elástica Não

e-mail Não elástica Não
Documentos Web Tolerante elástica Não
áudio/vídeo de tempo real Tolerante áudio: 5K-1Mbps Sim, 100’s mseg
vídeo: 10K-5Mbps
áudio/vídeo armazenado Tolerante Igual ao anterior Sim, alguns seg.
Jogos interactivos Tolerante Poucos Kbps Sim, 100’s mseg
Mensagens instantâneas Não elástica Sim e Não
Serviços do protocolo de transporte na
Internet
Serviço TCP: Serviço UDP:
❒ orientado à ligação: necessário ❒ transferência de dados não
estabelecimento de ligação fiável entre o processo do
entre os processos Cliente e emissor e o processo do
Servidor receptor
❒ transporte fiável entre o ❒ não fornece estabelecimento
processo emissor e o processo de ligação, fiabilidade,
receptor controlo de fluxo, controlo de
congestão, garantia de atraso

❒ controlo de fluxo: o emissor não
ou de largura de banda
sobrecarrega o receptor
❒ controlo de congestão: emissor

Q: Porque existe?
reduz o envio quando a rede
Para que serve o UDP?
está sobrecarregada
❒ não fornece: garantia de atraso
nem de largura de banda.

Aplicações Internet: protocolos de aplicação e
transporte
Protocolo de nível Protocolo de

Aplicação de Aplicação Transporte
e-mail SMTP [RFC 821] TCP

acesso remoto a terminais Telnet [RFC 854] TCP
Web HTTP [RFC 2068] TCP
transferência de ficheiros FTP [RFC 959] TCP
streaming multimedia proprietário TCP ou UDP
(ex: RealNetworks)
servidor de ficheiros remoto NFS TCP ou UDP
Telefonia Internet proprietário Tipicamente UDP
(ex: Dialpad)
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos

Web e HTTP
Primeiro alguma terminologia
❒ Uma Página Web consiste de objectos
❒ Objectos podem ser ficheiros HTML, imagens JPEG,
applets Java, ficheiros áudio,
❒ Uma página Web consiste de um ficheiro base HTML
que inclui vários objectos referidos
❒ Cada objecto pode ser endereçado por um URL
(Uniform Resource Location)
❒ Exemplo de URL:
www.someschool.edu/someDept/pic.gif
path name
nome da máquina
A Web: O protocolo HTTP
HTTP: HyperText
Transfer Protocol pe
di
do
H
T
❒ Protocolo de nível de PC a executar re T
P
sp
o st
aplicação da Web Internet Explorer a
H
T
T
P
❒ Modelo cliente-servidor
❍ Cliente: browser que

P
T
T
pede, recebe e mostra o
H
P
id T
T
d
e H
objectos Web p a
st Servidor a
o
sp
❍ Servidor: servidor Web re
executar
Servidor Web
envia objectos em
Apache
resposta a pedidos
Mac a executar
❒ HTTP 1.0: RFC 1945 Netscape Navigator
❒ HTTP 1.1: RFC 2616

O protocolo HTTP (continuação)
O HTTP não tem estado
HTTP: usa o serviço de stateless
transporte TCP: ❒ O Servidor não mantém
informação sobre os
❒ Cliente inicia a ligação TCP
pedidos anteriores dos
(cria um socket) para o
Clientes
Servidor, porto 80
à parte
❒ Servidor aceita a ligação TCP Protocolos que mantêm o
do Cliente
estado são complexos !
❒ Mensagens HTTP (mensagens ❒ História passada (estado)

do protocolo de nível de tem de ser mantida
aplicação) transferidas entre o
❒ Se o Servidor/Cliente
browser (Cliente HTTP) e o
falharem, a sua visão do
Servidor Web (servidor HTTP)
estado pode ficar
❒ Fecho da Ligação TCP
inconsistente, e tem de ser
conciliada
Ligações HTTP
HTTP não persistente HTTP persistente
❒ No máximo é enviado ❒ Múltiplos objectos
um objecto por cada podem ser enviados
ligação TCP. por uma única ligação
❒ HTTP/1.0 usa HTTP TCP entre o cliente e o
não persistente servidor.
❒ HTTP/1.1 usa ligações
persistentes por
omissão

HTTP não persistente
(contém texto,
Supondo que um utilizador introduz o URL
referência a
www.someSchool.edu/someDepartment/home.index 10 imagens
do tipo jpeg)
1a. Cliente HTTP inicia a ligação
TCP para o Servidor HTTP 1b. Servidor HTTP no Sistema
(processo) em: Terminal www.someSchool.edu

❍ www.someSchool.edu. ❍ espera a ligação TCP no porto 80,
porto 80 é utilizado por

aceita pedido de estabelecimento
❍ ❍
omissão para o acesso ao
de ligação
Servidor HTTP.
❍ notifica o cliente.
2. Cliente HTTP envia uma
mensagem para o socket 3. Servidor HTTP

da ligação TCP
❍ recebe a mensagem de pedido
mensagem de pedido
constrói a mensagem de resposta
❍ ❍
(contendo o URL) indica que
contendo o objecto pedido
o cliente quer o objecto
❍ envia a mensagem para o socket.
someDepartment/home.index
tempo
HTTP não persistente (continuação)
4. Servidor HTTP pede o fecho
da ligação TCP
5. Cliente HTTP recebe a ❍ A ligação só é fechada
mensagem de resposta quando o cliente recebe a
❍ Contendo ficheiro html, resposta
❍ Mostra o ficheiro html.
❍ Interpreta o ficheiro html
tempo ❍ Encontra a referência a 10
objectos do tipo jpeg
❍ Fecha a ligação TCP
6. Repete os passos 1 a 5 para
cada um dos 10 objectos jpeg

Modelo do Tempo de Resposta
Definição de RRT (Round-Trip
Time): tempo que o sinal
(um bit) demora a ir do
cliente para o servidor e
voltar (2.Tpropagação).
iniciar a
ligação TCP
Tempo de Resposta: RTT
um RTT para estabelecer a

pedir
❒ ficheiro
ligação TCP tempo para
RTT
transmitir
❒ um RTT para o pedido HTTP e o ficheiro
a resposta HTTP começar a
ficheiro
recebido
chegar
tempo de transmissão do
❒ tempo tempo
ficheiro
total = 2.RTT+tempo de
transmissão
HTTP persistente
HTTP não persistente HTTP persistente sem
pipelining
❒ 2 RTTs por objecto
o cliente envia um novo pedido

O SO precisa de trabalhar
❒ ❒
apenas quando recebeu a resposta
reservando recursos para
do anterior
cada ligação TCP
um RTT por cada objecto referido

Muitos browsers abrem
❒ ❒
várias ligações em paralelo
HTTP persistente com
para ir buscar os objectos
pipelining
referidos
❒ por omissão para HTTP/1.1

HTTP persistente
❒ o cliente envia pedidos assim que
❒ o servidor mantém a ligação
encontra os objectos referidos
aberta depois de responder
❒ apenas um RTT para todos os

❒ as mensagens HTTP
objectos referidos
seguintes do mesmo cliente
vão pela mesma ligação

Formato das mensagens: Pedido HTTP
❒ dois tipos de mensagens HTTP: pedido, resposta
❒ mensagem de pedido HTTP:
❍ ASCII (formato legível por humanos)
linha do pedido
(comandos GET, GET /somedir/page.html HTTP/1.0

POST, HEAD) Host: www.someschool.edu
Connection: close
Linhas de
User-agent: Mozilla/4.0
Cabeçalho
Accept-language:fr
Linha em branco
(carriage return, (caracteres adicionais de carriage return, line feed)

line feed) indica o
fim do cabeçalho
Formato das mensagens HTTP: pedido
Método URL Versão HTTP
Sistema Terminal
em que os GET /somedir/page.html HTTP/1.0

objectos residem
Host: www.someschool.edu
Tipo de browser
Connection: close
Não utilizar
ligações User-agent: Mozilla/4.0

persistentes
Accept-language:fr
O cliente prefere obter a versão francesa do objecto

Mensagem de pedido HTTP: formato geral
Enviando dados de um formulário
método POST:
❒ é frequente as páginas
Web incluírem entrada
de dados em formulários
❒ os dados são envidados
para o servidor no corpo método GET:
do pedido (entity body) ❒ os dados são enviados
no campo URL da linha
do pedido:
www.somesite.com/animalsearch?monkeys&banana

Tipos de métodos
HTTP/1.0 HTTP/1.1
❒ GET ❒ GET, POST, HEAD
❒ POST ❒ PUT
❒ HEAD ❍ envia ficheiro no corpo
do pedido para o
❍ pede ao servidor para
caminho especificado no
não incluir o objecto na
campo URL
resposta
❒ DELETE
❍ apaga o ficheiro
especificado no campo
URL
Formato da mensagem HTTP: resposta
linha de estado
(protocolo,
código de estado, HTTP/1.0 200 OK

descrição do estado) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
linhas de
Content-Length: 6821
cabeçalho
Content-Type: text/html
linha em branco
dados dados dados dados dados ...
dados, e.g.,
ficheiro
HTML pedido

Formato da mensagem HTTP: resposta
tempo em que a resposta
foi criada no servidor

HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT

servidor que
Server: Apache/1.3.0 (Unix)
gerou a resposta
Last-Modified: Mon, 22 Jun 1998 …...

data em que o objecto
Content-Length: 6821
foi criado, ou modificado
tipo de
objecto
Content-Type: text/html
Nº de Bytes do objecto
que está a ser enviado
dados dados dados dados dados ...

Códigos de estado HTTP
Na primeira linha da mensagem de resposta Servidor->Cliente
Alguns exemplos de códigos:
200 OK
❍ pedido teve sucesso, objecto pedido mais tarde nesta
mensagem
301 Moved Permanently

❍ objecto pedido foi movido, nova localização especificada
mais tarde nesta mensagem (cabeçalho Location:)
400 Bad Request

❍ mensagem de pedido não foi entendida pelo servidor
404 Not Found

❍ objecto pedido não foi encontrado no servidor
505 HTTP Version Not Supported

Teste o HTTP (do lado do cliente) você mesmo
1. Fazer Telnet para o seu WEB site favorito:
Abre ligação TCP para o porto 80 (porto por

telnet www.eurecom.fr 80
omissão do servidor HTTP) em www.eurecom.fr
O que for digitado é enviado para este porto
em www.eurecom.fr
2. Digitar um pedido HTTP GET:
Ao digitar isto (introduzindo

GET /~ross/index.html HTTP/1.0
RETURN 2x), é enviado um pedido
GET mínimo, mas completo, para o
servidor HTTP
3. Analise as respostas enviadas pelo servidor HTTP !
Interacção utilizador-servidor: autenticação
Autenticação : controlo de acessos

cliente servidor
ao conteúdo do servidor
pedido normal HTTP

❒ credenciais de autorização:
tipicamente nome, senha 401 Authorization Req.
(password) WWW authenticate:

❒ sem estado: o cliente tem de
apresentar a autorização em cada

pedido normal HTTP
pedido + Authorization: <cred>

❍ linha de cabeçalho Authorization:
resposta normal HTTP
em cada pedido
❍ sem cabeçalho Authorization:, o

pedido normal HTTP
servidor recusa o acesso,
responde com o cabeçalho

+ Authorization: <cred>
tempo
WWW authenticate: resposta normal HTTP
❒ o browser memoriza a autorização,
repetindo-a a cada pedido

Cookies: mantendo o estado
Muito servidores Web Exemplo:
importantes usam cookies ❍ A Susana acede à
Internet sempre do
Quatro componentes:
mesmo PC
1) linha de cabeçalho cookie
❍ Ela visita um servidor
na mensagem de resposta
de comércio electrónico
HTTP
pela primeira vez
2) linha de cabeçalho cookie
❍ Quando o primeiro
na mensagem de pedido
pedido HTTP chega ao
HTTP
servidor, o servidor cria
3) ficheiro de cookies
um identificador (ID)
mantido na máquina do
único e cria uma entrada
utilizador e gerido pelo
na sua base de dados
browser do utilizador
para o ID
4) base de dados no servidor
Web Camada de Aplicação 2-33
Cookies: mantendo o estado (cont.)
cliente servidor
pedido HTTP normal en

servidor
ficheiro de
Cookies ba trad
se a n
resposta http normal + cria ID 1678 de a
da
para utilizador
ebay: 8734 Set-cookie: 1678 do
s
ficheiro de
Cookies pedido HTTP normal
amazon: 1678 Acção

cookie: 1678 s o
ebay: 8734 específica aces
resposta HTTP normal
da cookie
o
uma semana mais tarde:

s
es
ac
pedido HTTP normal

Acção
ficheiro de
Cookies cookie: 1678
amazon: 1678 específica
resposta HTTP normal

da cookie
ebay: 8734

Cookies (continuação)
à parte
O que os cookies podem Cookies e privacidade:
oferecer: ❒ os cookies permitem que
❒ autorização os servidores aprendam
muito sobre você

❒ carrinhos de compras
❒ você pode dar o nome e e-

❒ recomendações
mail a um servidor
❒ estado da sessão do
❒ motores de pesquisa usam
utilizador (correio
redirecção e cookies para
electrónico via Web)
aprender ainda mais
❒ empresas de publicidade
obtêm informação de
vários servidores
GET condicional: cache no lado do cliente
cliente servidor
❒ Objectivo: não enviar os
objectos se o cliente tiver

msg pedido HTTP
uma versão actualizada em If-modified-since:
Objecto
cache <data>
não
❒ cliente: especifica a data da
modificado
resposta HTTP
cópia que tem em cache no
HTTP/1.0
pedido HTTP
304 Not Modified
If-modified-since: <data>
❒ servidor: a resposta não
msg pedido HTTP
contém objectos se a cópia de
If-modified-since:
cache do cliente estiver <data> Objecto
actualizada: modificado
HTTP/1.0 304 Not Modified resposta HTTP
HTTP/1.0 200 OK
<dados>
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos
FTP: o protocolo de transferência de
ficheiros (file transfer protocol)
interface transferência
cliente servidor
utilizador do ficheiro
FTP FTP
FTP
Utilizador num
sistema sistema
Sistema Terminal
ficheiros ficheiros
local remoto
❒ transferência de ficheiros de/para o sistema remoto
❒ modelo cliente-servidor
❍ cliente: inicia a transferência (de/para o sistema
remoto)
❍ servidor: sistema remoto
❒ FTP: RFC 959
❒ servidor FTP: porto 21

FTP: ligações de controlo e dados separadas
Ligação TCP de controlo

❒ o cliente FTP contacta o
porto 21
servidor no porto 21,
especificando o TCP como
protocolo de transporte Ligação TCP de dados

Cliente Servidor
porto 20
❒ o cliente obtém autorização
FTP FTP
pela ligação de controlo
o cliente lista os ficheiros

o servidor abre uma segunda
❒ ❒
remotos enviando comandos
ligação TCP de dados para
pela ligação de controlo
transferir outro ficheiro.
quando o servidor recebe um

Ligação de controlo: fora de
❒ ❒
comando para uma
banda (out of band)
transferência de um ficheiro, o
❒ Servidor FTP mantém o
servidor abre uma ligação TCP
estado: directório actual,
de dados para o cliente
autenticação anterior
❒ depois de transferir um
ficheiro, o servidor fecha a

ligação.
2-39
Comandos FTP, respostas
Exemplos de comandos: Exemplo de códigos de
❒ Enviados como texto estado

ASCII no canal de controlo
❒ Códigos de estado e
❒ USER username descrição (como no HTTP)
❒ PASS password ❒ 331 Username OK,

❒ LIST devolve a lista dos
password required
ficheiros no directório ❒ 125 data connection
corrente already open;
transfer starting
❒ RETR filename devolve
❒ 425 Can’t open data
(obtém) um ficheiro
connection
❒ STOR filename armazena
❒ 452 Error writing
(põe) ficheiro no sistema
file
remoto
❒ HELP [comando]
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos
Correio electrónico (E-Mail)
agente
Três componentes utiliz.
fundamentais:
servidor
agente
❒ agentes de utilizador correio
utiliz.
servidores de correio
SMTP
❒
servidor
❒ Simple Mail Transfer
correio agente
Protocol: SMTP
SMTP
utiliz.
Agente de Utilizador
SMTP
❒ a.k.a. programa de correio servidor
agente
utiliz.
❒ Compor, editar e ler correio
mensagens de correio
agente
fila de
❒ e.g., Eudora, Outlook, elm,
utiliz.
espera de saída
Netscape Messenger
agente
❒ mensagens a enviar ou a utiliz. caixa de correio
receber são armazenadas no
servidor Camada de Aplicação 2-42

Correio electrónico: servidores de correio
agente
Servidores de Correio utiliz.
❒ caixa de correio contém as

servidor
agente
mensagens que entraram correio
utiliz.
para o utilizador (ainda não
lidas) SMTP
servidor
❒ fila de espera de mensagens correio agente
de correio que o utilizador

SMTP
utiliz.
quer enviar (ainda não
enviadas)
SMTP
agente
❒ protocolo SMTP entre servidor
utiliz.
servidores de correio para correio
enviar as mensagens
agente
❍ cliente: envia correio fila de
utiliz.
espera de saída
para o servidor
agente
❍ servidor: servidor de utiliz. caixa de correio
recepção de correio
Correio electrónico : SMTP [RFC 2821]
❒ Utiliza TCP para transferir mensagens de correio do
cliente para o servidor, de forma fiável, através do porto
25.
❒ Transferência directa: servidor de envio para servidor
de recepção
❒ Três fases de transferência
❍ handshaking (apresentação)
❍ transferência de mensagens
❍ fecho
❒ Interacção comando-resposta
❍ comandos: texto ASCII
❍ resposta: código e descrição de estado
❒ Mensagens codificadas em ASCII de 7 bits

Cenário: Alice envia uma mensagem para Bruno
1) Alice usa um AU para compor 4) O cliente SMTP envia a
uma mensagem para mensagem da Alice pela
bruno@someschool.edu ligação TCP
2) O AU da Alice envia a 5) O servidor de correio do
mensagem para o seu Bruno coloca a mensagem
servidor de correio; a na caixa de correio do
mensagem é colocada em fila Bruno
de espera 6) O Bruno invoca o seu
3) O lado cliente do SMTP abre agente de utilizador para
uma ligação TCP com o ler a mensagem
servidor de correio do Bruno
1
servidor
servidor
agente
correio
agente correio
utiliz.
utiliz. 2
3 6
4
5
Exemplo de interacção com SMTP
C: telnet hamburger.edu 25-> Estabelecimento da lig. TCP

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bruno@hamburger.edu>
S: 250 bruno@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Queres ketchup?
C: Que tal pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Experimentem o SMTP por vocês mesmos
❒ Digitar telnet servername 25

❒ observar 220 resposta do servidor
❒ digitar comandos HELP, HELO, MAIL FROM, RCPT
TO, DATA, QUIT
❒ Os procedimentos anteriores permitem enviar
correio sem usar um cliente de correio (programa)
SMTP: palavras finais
❒ SMTP utiliza ligações Comparação com HTTP:

persistentes
❒ HTTP: puxa (pull)
❒ SMTP requer que a
❒ SMTP: empurra (push)
mensagem seja codificada
em ASCII de 7 bits
❒ Ambos têm interacção
(cabeçalho e corpo)
comando/resposta em
❒ Servidor SMTP usa ASCII, códigos de estado
CRLF.CRLF para
identificar o fim da ❒ HTTP: cada objecto
mensagem encapsula a sua própria
mensagem de resposta
❒ Alguns caracteres não são
permitidos na mensagem ❒ SMTP: múltiplos objectos
(e.g., CRLF.CRLF). Então a enviados em múltiplas
mensagem tem de ser partes (multipart message)
codificada (ex: base-64 ou
quoted printable) Camada de Aplicação 2-48

Formato da mensagem de Correio
SMTP: protocolo para transferir
mensagens de correio Cabeçalho

Linha
RFC 822: formato standard para
em
mensagens de texto:
branco
❒ Linhas de cabeçalho, e.g.,
To:
Corpo
❍
❍ From:
❍ Subject:
diferente dos comandos SMTP
❒ Corpo
❍ a mensagem, apenas os
caracteres ASCII
Formato das mensagens: extensões multimédia
❒ MIME (Multipurpose Internet Mail Extensions): extensões de
correio para informação multimédia, RFC 2045, 2056
❒ Linhas adicionais no cabeçalho da mensagem declaram o tipo de
conteúdo MIME
From: alice@crepes.fr
Versão MIME
To: bruno@hamburger.edu
Subject: Imagem de saboroso doce.
Método usado para
MIME-Version: 1.0
codificar os dados Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Tipo de dados multimédia,
subtipo,
dados codificados em base64 .....
declaração de parâmetros ..................................
...... dados codificados em base64
Dados codificados

Tipos MIME
Content-Type: tipo/subtipo; parâmetros
Texto (text) Vídeo (video)
❒ Exemplo de subtipos: ❒ Exemplo de subtipos:
plain, html mpeg, quicktime
Imagem (image) Aplicação (application)
Exemplo de subtipos:
Outros dados que têm de
❒ ❒
ser processados pelo leitor
jpeg, gif
antes de serem visíveis
Áudio (audio) ❒ Exemplo de sub-tipos :
msword, octet-stream
❒ Exemplo de subtipos :
basic (codificação 8-bit
mu-law), 32kadpcm
(codificação de 32 kbps)
Tipo Multipart
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Caro Bruno, junto envio imagem de um doce.
--StartOfNextPart
Content-Transfer-Encoding: base64
.................................
......dados codificados em base64
--StartOfNextPart
Queres a receita?

Tipo Multipart - recepção
Received: from crepes.fr by hamburger.edu; 12 Oct 98

MIME-Version: 1.0
--StartOfNextPart
--StartOfNextPart
.................................
--StartOfNextPart
Queres a receita?
Tipo Multipart - encaminhamento
Received: from hamburger.edu by sushi.jp; 12 Oct 98 15:30:01 GMT

Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMT
MIME-Version: 1.0
--StartOfNextPart
--StartOfNextPart
.................................
--StartOfNextPart
Queres a receita?

Estudo de um caso: Vírus Klez - Cabeçalho
From biomedic@brturbo.com.br Wed May 8 21:58:05 2002

Received: from smtp.brturbo.com ([200.199.201.47])
by inesc.inesc.pt (8.9.3/8.9.3) with ESMTP id VAA96840
for <webmaster@mariel.inesc.pt>; Wed, 8 May 2002 21:57:12 +0100 (WEST)
(envelope-from biomedic@brturbo.com.br)
Received: from Kdccjtcr (unknown [200.163.62.20])
by smtp.brturbo.com (Postfix) with SMTP id 006D611E620
for <webmaster@mariel.inesc.pt>; Wed, 8 May 2002 17:50:17 -0300 (BRT)
From: kit <kit@microcontrolador.com>
To: webmaster Destino obtido
numa página WEB

Subject: Japanese girl VS playboy
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary=AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3 Origem forjada
Message-Id: <20020508205018.006D611E620@smtp.brturbo.com>
Date: Wed, 8 May 2002 17:50:18 -0300 (BRT)
Assunto supostamente apelativo
Utilizador infectado
Verme (Worm) - vírus que se propaga por correio
electrónico
Fazer vírus é punível com prisão!

Estudo de um caso: Vírus Klez - Mensagem
--AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3
Content-Type: text/html; HTML com suposto som para
música de fundo
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY> (extensão da Microsoft)

<iframe src=3Dcid:Rh5Y20734J height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>
--AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3
Programa executável com o vírus
Content-Type: audio/x-midi;
name=kitty.pif
Content-ID: <Rh5Y20734J>
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
(…)
--AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3--
Bug: ao tocar a música,
corre o vírus!
Basta ver a mensagem
para ficar infectado!

Estudo de um caso: Vírus Klez
Moral da História
❒ Programadores:
❍ verificar cuidadosamente toda a informação que chega da rede
se os dados fazem sentido, bytes a mais ou a menos
❒ Administradores:
❍ instalar antivírus, actualizar as definições de vírus c/frequência
❍ aplicar periodicamente patches de segurança
❍ monitorizar explosões de tráfego na rede
❒ Utilizadores
❍ não pôr o endereço de correio electrónico directamente em
páginas web (usar imagem, Javascript)
❍ desconfiar de anexos no correio com programas executáveis,
com dupla extensão, ou com nomes que parecem ligações web:
Ex: Veja as fotos fantásticas em: www.myparty.yahoo.com
Protocolos de acesso ao Correio
SMTP SMTP
protocolo
agente
agente
utiliz. de acesso utiliz.
servidor do servidor do
emissor receptor
do correio do correio
❒ SMTP: entrega/armazena correio no servidor do receptor
❒ Protocolos de acesso ao correio: obter correio do servidor do
receptor
❍ POP: Post Office Protocol [RFC 1939]
Autorização (agente <--> servidor) e download
❍ IMAP: Internet Mail Access Protocol [RFC 1730]
mais funcionalidades (mais complexo)
manipulação das mensagens armazenadas nos servidores
❍ HTTP: Hotmail , Yahoo! Mail, etc.

Protocolo POP3
C: telnet hamburger.edu 110
S: +OK POP3 server ready
C: user bruno
Fase de autorização
S: +OK
C: pass hungry
❒ Comandos do cliente:
S: +OK user successfully logged on
❍ user: declara username
password
❍ pass: C: list
S: 1 498
❒ Servidor responde
S: 2 912
❍ +OK S: .
❍ -ERR C: retr 1
Fase de transacção, cliente:
S: <message 1 contents>
S: .
❒ list: lista nº das mensagens
C: dele 1
❒ retr: obtém mensagens C: retr 2
através no nº S: <message 1 contents>
❒ dele: apaga S: .
termina
❒ quit:
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3 (mais) e IMAP
Mais sobre POP3 IMAP
❒ O exemplo anterior usa ❒ Mantém todas as mensagens
o modo descarrega e num único lugar: o servidor
apaga (download and

❒ Permite ao utilizador
delete).
organizar as mensagens em
❒ O Bruno não pode voltar pastas
a ler o correio se mudar

❒ IMAP mantém estado entre
de programa
sessões:
❒ Descarrega e mantém ❍ nomes de pastas e mapeamento
(Download-and-keep): entre IDs de mensagem e nome
de pasta
cópias de mensagens em
clientes diferentes ❒ Utilizador pode obter apenas
componentes específicos da
❒ O POP3 não mantém
mensagem
estado entre sessões Camada de Aplicação 2-60
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos
DNS: Domain Name System
Domain Name System:
Pessoas: muitos ❒ Base de dados distribuída
identificadores: implementada numa hierarquia
de muitos servidores de nomes

❍ #BI, nome, #passaporte
Protocolo de nível de aplicação

Internet hosts, routers:
❒
sistemas terminais, routers,
❍ Endereço IP (32 bit) servidores de nomes comunicam
utilizado para endereçar para resolver nomes (tradução
datagramas endereço/nome)
❍ nome, e.g., www.ist.utl.pt ❍ nota: função do núcleo da
usado pelos humanos Internet, implementada
como protocolo de nível de

Q: mapeamento entre
aplicação
endereços IP e nomes ?
❍ complexidade na periferia da
rede

Servidores de nomes DNS
Servidores de nomes locais:
Porque não centralizar o (Local Name Server)
DNS? ❍ cada ISP, instituição tem um
servidor de nomes local

❒ um só ponto de falha
(default)
❒ volume de tráfego
❍ sistemas terminais interrogam
❒ base de dados primeiro o Servidor de Nomes
Local
centralizada distante
❒ manutenção Servidor de nomes oficial
(authoritative name server):
❍ para um sistema terminal:

Não escala !
guarda o seu nome, endereço
IP
❒ Nenhum servidor tem ❍ pode executar a tradução
todos os mapeamentos de nome/endereço para esse
sistema terminal
nome para endereço IP Camada de Aplicação 2-63
DNS: Servidores de nomes raiz
(Root Name Server)

❒ contactados por servidores de nomes locais que não sabem resolver
nomes
❒ servidor de nomes raiz:
❍ contacta o servidor de nomes oficial quando não sabe o
mapeamento do nome
❍ obtém mapeamento
❍ retorna o mapeamento ao servidor de nomes local

a NSI Herndon, VA
c PSInet Herndon, VA k RIPE London
d U Maryland College Park, MD i NORDUnet Stockholm
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
13 servidores de
nomes raiz no
mundo
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA

servidor de
Exemplo simples de DNS nomes raiz
a máquina surf.eurecom.fr
pretende o endereço IP de 2 4
gaia.cs.umass.edu 5 3
1. Contacta o seu servidor DNS
local,
dns.eurecom.fr
2. dns.eurecom.fr contacta o
servidor de nomes raiz, se servidor de nomes servidor de nomes
local oficial
necessário
dns.eurecom.fr dns.umass.edu
3. o servidor de nomes raiz 1 6
contacta o servidor de nomes
oficial, dns.umass.edu, se
necessário
máquina
gaia.cs.umass.edu
que pergunta
surf.eurecom.fr
servidor de
Exemplo de DNS nomes raiz
Servidor de nomes 6
2
raiz: 7 3
❒ Pode não conhecer o
servidor oficial
❒ Pode conhecer
servidores de nomes servidor de nomes servidor de nomes intermédio
local
intermédios: quem
dns.umass.edu
contactar para descobrir
dns.eurecom.fr 4 5
1 8
o servidor de nomes
oficial
servidor de nomes oficial
dns.cs.umass.edu
máquina
que pergunta
surf.eurecom.fr
gaia.cs.umass.edu

DNS: perguntas servidor de
nomes raiz
iterativas
Perguntas pergunta iterativa

2
recursivas: 3
❒ coloca o peso da 4
resolução de nomes no
servidor contactado
7
❒ carga elevada ? servidor de nomes servidor de nomes intermédio
local dns.umass.edu
Perguntas iterativas: dns.eurecom.fr 5 6
1 8
❒ o servidor contactado
responde com o nome

servidor de nomes oficial
do servidor a dns.cs.umass.edu
contactar máquina
que pergunta
❒ não conheço este
surf.eurecom.fr
nome, mas pergunta a
gaia.cs.umass.edu
este servidor !!
DNS: caches e actualização de registos
❒ Cada vez que um (qualquer) servidor de nomes
aprende os mapeamentos, armazena-os na cache
❍ Entradas na cache desaparecem ao fim dum certo
tempo, porque se esgota o tempo de vida (ttl).
❒ Mecanismos de actualização/notificação em estudo
no IETF
❍ RFC 2136
❍ http://www.ietf.org/html.charters/dnsext-charter.html

Registos DNS
DNS: Registos de Recursos (Resource Records, RR)
armazenados numa Base de Dados distribuída
formato de um RR: (nome, valor, tipo, ttl)
❒ Tipo=A ❒ Tipo=CNAME
❍ nome do Sistema Terminal ❍ nome é um sinónimo do nome
❍ valor é um endereço IP canónico (o verdadeiro)
www.ibm.com é realmente
servereast.backup2.ibm.com
❒ Tipo=NS ❍ valor é o nome canónico
❍ nome é o domínio (e.g.
foo.com) ❒ Tipo=MX
❍ valor é o endereço IP do ❍ valor é o nome do servidor

servidor de nomes oficial de correio associado com o
desse domínio
nome
Exemplo de distribuição de carga usando DNS
@tlinux:~/ > dig www.yahoo.com

;; ANSWER SECTION:
www.yahoo.com. 308 IN CNAME www.yahoo.akadns.net.
www.yahoo.akadns.net. 30 IN A 216.109.118.67
Passado algum tempo:

@tlinux:~/ > dig www.yahoo.com
;; ANSWER SECTION:
www.yahoo.com. 253 IN CNAME www.yahoo.akadns.net.
Protocolo DNS, mensagens
Protocolo DNS : mensagens de pedido e resposta,
ambas com o mesmo formato de mensagem
cabeçalho de msg
❒ identificação:
❍ # de 16 bit para pedido
❍ resposta ao pedido usa o
mesmo #
❒ flags:
❍ pedido ou resposta
❍ recursividade desejada
❍ recursividade disponível
❍ resposta é oficial
Protocolo DNS, mensagens
Nome, tipo de campo
para um pedido
RRs em resposta
ao pedido
registos para
servidores oficiais
informação adicional
que pode ser útil

requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos
Programação em Sockets
Objectivo: aprender a construir aplicações
cliente/servidor que comunicam através de sockets
API de Sockets socket
❒ introduzida no UNIX
uma interface (uma
BSD4.1, 1981
porta) local à maquina,
❒ criado explicitamente, criada pela aplicação,
utilizado, libertado pelas controlada pelo SO para a
aplicações qual o processo de
❒ paradigma cliente/servidor aplicação pode tanto
enviar como receber

❒ dois tipos de serviço de
mensagens de/para outro
transporte através da API
processo de aplicação
de sockets:
❍ não fiável, datagramas
❍ fiável, transmissão de
bytes com ligação Camada de Aplicação 2-74

Programação em Sockets usando TCP
Socket: uma porta entre o processo de aplicação e o
protocolo de transporte extremo a extremo (UDP
ou TCP)
Serviço TCP: transferência fiável de bytes de um
processo para outro
controlado pelo
controlado pelo
processo programador da
programador da processo
aplicação
aplicação socket
socket
TCP com controlado
controlado TCP com
buffers, pelo sistema
pelo sistema buffers,
internet operativo
variáveis
operativo variáveis
cliente ou
cliente ou
servidor
servidor
Programação em Sockets com TCP
O cliente tem de contactar o ❒ Quando contactado pelo cliente, o
servidor servidor TCP cria um novo socket
❒ primeiro o servidor tem de para o processo servidor
estar a correr comunicar com o cliente
❒ o servidor tem de ter ❍ permite que o servidor fale
criado um socket que aceita com múltiplos clientes
contactos de clientes ❍ número de porto de origem
utilizado para distinguir

O cliente contacta o servidor
clientes (mais no Capítulo 3)
da seguinte forma:
❒ criando um socket TCP local

ponto de vista da aplicação
ao cliente
O TCP oferece transferência
❒ especificando o endereço
fiável de bytes (pipe)
IP, número de porto do
entre cliente e servidor
processo servidor
❒ estabelecendo ligação com
o servidor TCP Camada de Aplicação 2-76

Interacção cliente/servidor com sockets: TCP
Se rvido r
cria socket socket ( )
associa porto
bind ( )
de escuta
inicia escuta listen ( )

Clie nte
aceita ligação accept ( )
socket ( ) cria socket
bloqueia até ter ligação
de um cliente
estabelecimento de ligação
connect ( ) pede ligação
write ( ) envia pedido

lê pedido read ( )
dados(pedido)
processa pedido
dados(resposta)
envia resposta write ( )
read ( ) lê resposta
requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos

Programação em Sockets com UDP
UDP: sem ligação entre
cliente e servidor
❒ sem handshaking
❒ emissor explicitamente ponto de vista da aplicação
coloca endereço IP e porto

UDP oferece transferência
em cada pacote
não fiável de grupos de bytes
❒ o servidor tem de extrair
(datagramas) entre o cliente
do pacote recebido o
e o servidor
endereço IP, porto do
emissor
UDP: dados transmitidos
podem ser recebidos fora
de ordem, ou perdidos
Interacção cliente/servidor com sockets: UDP
Se rvido r
cria socket socket ( )
associa porto
bind ( )
de escuta
Clie nte
lê pedido recvfrom ( ) socket ( ) cria socket
bloqueia até receber sendto ( ) envia pedido

dados de um cliente
dados(pedido)
processa pedido
envia resposta sendto ( ) dados(resposta)

recvfrom ( ) lê resposta

Construindo um servidor Web simplificado
❒ aceita ligação ❒ depois de criar o
servidor, pode pedir

❒ aceita pedido HTTP
ficheiros com um
❒ interpreta cabeçalhos
browser (eg
❒ obtém o ficheiro pedido
Netscape), ou com
do sistema de ficheiros
Telnet
do servidor
❒ aulas de laboratório
❒ cria mensagem de
resposta HTTP:
❍ linhas de cabeçalho +
ficheiro
❒ envia a resposta para o
cliente (pode ser aos
bocados...) Camada de Aplicação 2-81
Programação em Sockets: referências
Mini-curso de linguagem C (áudio/slides):
❒ Unix Network Programming (J. Kurose),
http://manic.cs.umass.edu/~amldemo/courseware/intro .html
Mini-curso de Java:
❒ All About Sockets (Mini-curso da Sun),
http://java.sun.com/docs/books/tutorial/networking/
sockets/
❒ Socket Programming in Java: a tutorial,
http://www.javaworld.com/javaworld/jw-12-1996/ jw-12-
sockets.html

requisitos das
2.8 Construindo um
❍
❒
aplicações
servidor Web
❒ 2.2 Web e HTTP
❒ 2.3 FTP
conteúdos
Caches Web (servidores proxy)
Objectivo: satisfazer os pedidos dos clientes sem
envolver o servidor original
servidor
❒ Utilizador configura o original
browser: acessos Web

servidor
pe
através da cache di T
P
do Proxy H
T
H
re T do P
cliente envia todos os cliente sp T
P di T
pe T
❒ os H
ta a
st
pedidos HTTP para a H
T sp
o
T
P re
cache T
P
T
H
o P
objecto existe na cache: id T
❍ d T
e H
p a
cache web devolve o st
o
sp
objecto re
❍ caso contrário, cache

cliente
Web pede o objecto ao servidor
servidor original e original
retorna este objecto ao
cliente
Mais sobre caches Web
❒ Cache actua tanto como Porquê caches Web?

cliente como servidor
❒ Reduz o tempo de resposta
❒ Cache pode fazer para pedidos do cliente.
verificação de actualização
❒ Reduz tráfego na linha de
com o cabeçalho HTTP:
acesso da instituição.
If-modified-since
❒ A densidade de caches na
❍ Problema: deve a cache
Internet permite que os
correr um risco e entregar
fornecedores de conteúdos
o objecto em cache sem
pobres, com linhas de
verificar?
baixo ritmo, efectivamente

❍ são utilizadas heurísticas.
forneçam conteúdos
❒ Tipicamente, a cache é
instalada pelo ISP
(universidade, empresa,
ISP residencial)
Exemplo de caches (1)
servidores
Condições
de origem
❒ tamanho médio de objecto =
Internet
100 000 bits
pública
❒ taxa média de pedidos dos
browsers da instituição para os
servidores de origem = 15/seg
Ligação de acesso
❒ atraso do router institucional
1.5 Mbps
para qualquer servidor de origem
rede
e regresso ao router = 2 seg
institucional
LAN a 10 Mbps
Consequências
❒ utilização na LAN = 15%
❒ utilização na linha de acesso = 100%
❒ atraso total = atraso na Internet +
atraso no acesso + atraso na LAN
= 2 seg + minutos + milissegundos

servidores
Solução Possível
de origem
❒ aumentar a linha de acesso para,
Internet
digamos, 10 Mbps
pública
Consequências
❒ utilização na LAN = 15%
❒ utilização na linha de acesso = 15%

Ligação de acesso
❒ atraso total = atraso na Internet +
10 Mbps
atraso no acesso + atraso na LAN
rede
= 2 seg + msegs + msegs
institucional
LAN a 10 Mbps
❒ normalmente uma actualização cara
Instalar cache servidores
de origem
❒ supondo taxa de acerto de 0.4
Consequências Internet
pública
❒ 40% dos pedidos são satisfeitos
quase imediatamente
❒ 60% dos pedidos satisfeitos
pelo servidor de origem

Ligação de acesso
❒ a utilização da linha de acesso é 1.5 Mbps
reduzida para 60%, resultando

rede
em atrasos desprezáveis
institucional
LAN a 10 Mbps
(digamos: 10 mseg)
❒ atraso total = atraso na
Internet + atraso no acesso +
atraso na LAN
cache institucional
= 0.6*2 seg + 0.6*0.010 segs +
milissegundos < 1.3 segs

Redes de Distribuição de Conteúdos
(Content Distribution Network, CDN)

servidor de origem
na América do Norte
❒ Os clientes das CDNs são os
fornecedores de conteúdos.
Replicação de Conteúdos
❒ A empresa de CDN instala

nó de distribuição da CDN
centenas de servidores CDN
pela Internet
❍ em ISPs próximos dos
utilizadores
❒ A CDN replica os conteúdos
dos seus clientes em
servidores CDN. Quando o servidor CDN

servidor CDN
fornecedor actualiza o na América
servidor CDN na Ásia
do Sul
conteúdo, a CDN actualiza os na Europa
servidores
Exemplo de CDN pedido HTTP para

www.foo.com/sports/sports.html
1 servidor de origem
2 DNS query for www.cdn.com

servidor DNS
oficial da CDNs
3
pedido HTTP para

www.cdn.com/www.foo.com/sports/ruth.gif
servidor
servidor de origem CDN próximo

Empresa de CDN
❒ www.foo.com ❒ cdn.com
❒ distribui HTML ❒ distribui ficheiros gif
substitui:
usa o servidor de DNS
❒ ❒
oficial para encaminhar
http://www.foo.com/sports/ruth.gif
por
pedidos redireccionados
http://www.cdn.com/www.foo.com/sports/ruth.gif

Mais sobre CDNs
encaminhamento de não apenas páginas Web
pedidos
❒ fluxos de áudio/vídeo
❒ A CDN cria um mapa, armazenado
indicando as distâncias
❒ fluxos de áudio/vídeo
dos ISPs aos nós da CDN
em tempo real
❒ quando o pedido chega ❍ nós CDN criam rede de
ao servidor DNS oficial: nível aplicação
sobreposta
❍ servidor determina qual o
ISP de onde provém o
pedido
❍ usa o mapa para
determinar o melhor
servidor da CDN
Partilha de ficheiros P2P
❒ Alice escolhe um dos pares,
Bruno.
Exemplo
❒ o ficheiro é copiado do PC do
❒ A Alice corre a aplicação
Bruno para o portátil da
cliente P2P no seu
Alice: HTTP
computador portátil
❒ enquanto a Alice descarrega
❒ liga-se à Internet
o ficheiro, outros
temporariamente; obtém
utilizadores descarregam
um endereço IP para
ficheiros da Alice.
cada ligação
❒ o programa da Alice é
❒ pede por Hey Jude
simultaneamente cliente Web
a aplicação mostra
e servidor Web temporário.
❒
outros pares que têm
Todos os pares são servidores =
uma cópia de Hey Jude.
escala muito!
P2P: Directório Centralizado
Bruno
desenho original do
servidor de
Napster directório
centralizado 1
1) quando um par se liga, pares
informa o servidor 1
central:
3
1
❍ endereço IP
2
❍ conteúdo 1
2) Alice pergunta por Hey
Jude
3) Alice pede o ficheiro do
Bruno
Alice
P2P: problemas com directório centralizado
L único ponto de falha a transferência de
L estrangulamento de ficheiros é
desempenho descentralizada, mas a
localização de conteúdos
L infracção de direitos
é altamente centralizada
de autor

P2P: directório descentralizado
❒ cada par é um líder de
grupo, ou associado a
um líder de grupo.
❒ o líder de grupo
conhece o conteúdo de
todos os seus filhos.
❒ par pergunta ao líder
de grupo; o líder de
grupo pode perguntar
a outros líderes de
par normal
grupo.
par líder de grupo
relações de vizinhança
na rede sobreposta (rede lógica)
Mais sobre directórios descentralizados
rede sobreposta vantagens da aproximação
❒ pares são nós J não há servidor de
❒ arcos entre pares e o directório centralizado
seu líder de grupo ❍ serviço de localização
distribuído pelos pares

❒ arcos entre alguns pares
❍ mais difícil de desactivar
de líderes de grupo
desvantagens da aproximação
❒ vizinhos virtuais
L necessários nós de arranque
nó de arranque
L líderes de grupo podem ser
❒ um par que se ligue é
sobrecarregados
associado a um líder de
grupo ou designado como
líder
P2P: inundação de pedidos
❒ Gnutella ❒ envia pedido aos vizinhos
❒ sem hierarquia ❒ vizinhos encaminham pedido
❒ usa nó de arranque para ❒ se um tem o objecto, envia
conhecer outros uma mensagem de volta para
❒ mensagem de associação o par que perguntou
pedido
join
associação
P2P: mais sobre inundação de pedidos
Prós Contras
J pares têm L tráfego de pedidos
responsabilidades excessivo
similares: não há L raio de alcance de

líderes de grupo pedido: pode não
J altamente encontrar o conteúdo
descentralizado quando ele existe
J nenhum par mantém L nó de arranque
informação de L manutenção da rede

directório sobreposta

O estudo das aplicações está completo !
❒ requisitos do serviço
❒ protocolos específicos:
de aplicação:
❍ HTTP
❍ fiabilidade, ritmo,
❍ FTP
atraso
❍ SMTP, POP, IMAP
❒ paradigma cliente-
❍ DNS
servidor
❒ programação em sockets
❒ modelo de serviço de
❒ distribuição de conteúdos
transporte na Internet
❍ caches, CDNs
❍ Serviço orientado à
❍ P2P
ligação, fiável: TCP
❍ Não fiável, datagramas:
UDP
Mais importante: aprenderam-se protocolos
❒ tipicamente transferência de ❒ mensagens de controlo vs.
mensagens pedido/resposta: mensagens de dados
❍ Cliente pede informação ou ❍ em banda (in-band), fora
serviço da banda (out-of-band)
❍ Servidor responde com

❒ Centralizado vs. distribuído
dados, código de estado
❒ Sem estado vs. com estado
❒ formato das mensagens:
(stateless vs statefull)
❍ Cabeçalho (header): campos
❒ Transferência de mensagens
que fornecem informação
fiável vs. não fiável
sobre os dados
❍ dados: informação a ser

❒ complexidade na periferia da
comunicada rede
❒ segurança: autenticação

2 Aplicacao

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2 Aplicacao

Transféré par

Droits d'auteur :

Formats disponibles

Capítulo 2

A note on the use of these ppt slides:

Thanks and enjoy! JFK/KWR 2002.

All material copyright 1996-2002

Capítulo 2: Camada de Aplicação

Objectivos: ❒ Aprender os protocolos

examinando protocolos populares

transporte Protocol) / IMAP (Internet Mail

❍ API dos sockets

❒ 2.1 Princípios dos ❒ 2.6 Programação em

protocolos da camada Sockets com TCP

de aplicação ❒ 2.7 Programação em

❍ clientes e servidores Sockets com UDP

❒ 2.4 Correio electrónico ❍ Redes de caches Web

❍ SMTP, POP3, IMAP ❍ Redes de distribuição de

❒ 2.5 DNS conteúdos

❍ partilha de ficheiros P2P

Camada de Aplicação 2-3

Aplicações de Rede: terminologia

Processo: programa Agente de utilizador (user

correndo numa máquina. agent): faz a interface

❒ numa mesma máquina, entre o utilizador acima

dois processos e a rede abaixo.

comunicam usando ❒ implementa a interface

comunicação entre com o utilizador e o

processos (definida protocolo de camada de

pelos SO). aplicação

❒ processos correndo em ❍ Web: browser

máquinas diferentes ❍ E-mail: programa de

áudio/vídeo: media player

Aplicação: processo distribuído

terminais da rede em espaço

❍ troca mensagens para

comunicação dos níveis

inferiores (TCP, UDP).

O que os protocolos de aplicação definem

❒ Tipos de mensagens Protocolos de domínio

trocadas, eg, mensagens público:

de pedidos e respostas ❒ definidos em RFCs

❒ Sintaxe dos tipos de ❒ permitem

informação nos campos

❒ Regras para quando e

como enviar e responder

Aplicações de rede típicas têm

duas partes: Cliente e Servidor

inicia o contacto com o Servidor

❒ Web: Cliente implementado num

e-mail: Cliente implementado num

❒ Servidor Web envia páginas pedidas;

Servidor de correio entrega emails.

Camada de Aplicação 2-7

Processos em comunicação pela rede

a mensagem para fora da

porta TCP com TCP com

transporte do outro lado da

❒ API (Interface de Programação de Aplicação):

(1) escolha do protocolo de transporte;

❒ Para um processo receber ❒ O identificador inclui

mensagens, tem de ter um tanto o endereço IP

identificador como o número do

❒ Cada máquina tem um porto associado com o

endereço IP único de 32 processo na máquina.

bits ❒ Exemplos de números

transporte Protocol) / IMAP (Internet Mail

❒ numa mesma máquina, entre o utilizador acima

dois processos e a rede abaixo.

HTTP: usa o serviço de stateless