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 represent a lot of work on our part. In return for use, we only ask the following: q If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) 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 note our copyright of this material.
Computer Networking: A Top Down Approach Featuring the Internet, 2
nd
edition.
Jim Kurose, Keith Ross Addison-Wesley, July 2002.
Thanks and enjoy! JFK/KWR 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:
❒
❒
examinando protocolos populares
conceitos, aspectos
da camada de aplicação
de implementação dos protocolos de
❍
modelos de serviço da camada de
❍
FTP (File Transfer Protocol)
❍
SMTP (Simple Mail Transfer
Protocol) / POP3 (Post Office
transporte
❍
Protocol) / IMAP (Internet Mail Access Protocol)
paradigma clienteservidor
❍
paradigma par-par (peer-to-peer)
HTTP (HyperText Transfer Protocol)
aplicação em rede
❍
Aprender os protocolos
❍
DNS (Domain Name System protocol)
❒
Programação de aplicações de rede
❍
API dos sockets Camada
de Aplicação
2-2
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
SMTP, POP3, IMAP
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-3
Aplicações de Rede: terminologia Processo: programa
correndo numa máquina.
❒
Agente de utilizador (user agent): faz a interface
entre o utilizador acima
numa mesma máquina,
e a rede abaixo.
dois processos
comunicam usando
comunicação entre
processos (definida pelos SO).
❒
processos correndo em
❒
implementa a interface com o utilizador e o
protocolo de camada de aplicação
❍
máquinas diferentes
Web: browser
❍
E-mail: programa de
um protocolo da camada
❍
correio
comunicam através de de aplicação
áudio/vídeo: media player
Camada de Aplicação
2-4
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 user-space) de utilizador (user space
❍
troca mensagens para
implementar a aplicação
Protocolos da camada de aplicação
❍ ❍
uma parte da aplicação
define as mensagens trocadas
entre as aplicações e as acções
+,.- ( ) +/0 * 12 +3 ' , * 21 4 24564 - ( 7 8 5 + 5 *' % & ' ( )*
+ ,.- ( ) +/0 * 12 +3 ' , * 214 24 54 - ( 7 8 5 + 5 *' %& '( )*
a executar
❍
utiliza os serviços de
comunicação dos níveis inferiores (TCP, UDP).
Camada de Aplicação
2-5
O que os protocolos de aplicação definem
❒
Tipos de mensagens
Protocolos de domínio
de pedidos e respostas
❒
Sintaxe dos tipos de
definidos em RFCs
❒
permitem
trocadas, eg, mensagens
❒
mensagem: que campos
nas mensagens e como os campos são delineados
❒
Semântica dos campos, ie, significado da
público:
interoperabilidade
❒
eg, HTTP, SMTP
Protocolos proprietários:
❒
eg, KaZaA
informação nos campos
❒
Regras para quando e
como enviar e responder a mensagens
Camada de Aplicação
2-6
O paradigma Cliente-Servidor Aplicações de rede típicas têm Cliente:
❒
duas partes: Cliente e Servidor
inicia o contacto com o Servidor (fala primeiro)
❒
tipicamente, requisita serviços ao
9:.; < =9>? @ AB 9CD: @ BA E BEFE ; < G H F 9 F @D IJ D < =@ pedido
Servidor
❒
Web: Cliente implementado num browser;
e-mail: Cliente implementado num programa de correio
resposta
Servidor:
❒
9:.; < = 9>? @ AB 9CD:@ BA E BE FE ; < G H F 9 F @D IJ D< =@
fornece os serviços requisitados pelos Clientes
❒
Servidor Web envia páginas pedidas; Servidor de correio entrega emails.
Camada de Aplicação
2-7
Processos em comunicação pela rede
❒
os processos
enviam/recebem mensagens para/do seu socket
❒
socket análogo a uma porta
❍
o processo que envia empurra a mensagem para fora da porta
❍
o processo que envia assume que uma infra-estrutura de
transporte do outro lado da
porta leva a mensagem até ao socket do processo que
cliente ou servidor
cliente ou servidor
processo
controlado pelo programador da aplicação
processo socket
socket TCP com buffers, variáveis
Internet
TCP com buffers, variáveis
controlado pelo SO
recebe
❒
API (Interface de Programação de Aplicação): (1) escolha do protocolo de transporte;
Camada de Aplicação
(2) possibilidade de definir alguns parâmetros
2-8
Endereçar processos: Para um processo receber
❒
❒
mensagens, tem de ter um
tanto o endereço IP
identificador
como o número do
porto associado com o
Cada máquina tem um
❒
processo na máquina.
endereço IP único de 32 bits
❒
máquina onde o processo corre é suficiente para
identificar o processo?
Exemplos de números de portos:
Q: o endereço IP da
❒
O identificador inclui
❒
❍
servidor HTTP: 80
❍
servidor Mail: 25
Mais sobre isto depois
Resposta: Não, pode haver
❒
muitos processos a correr na mesma máquina
Camada de Aplicação
2-9
Que serviços de transporte é que uma aplicação necessita? Perda de dados
❒
Algumas aplicações toleram algumas falhas
❍
❒
Largura de Banda
❒
requerem um ritmo mínimo
ex: áudio
para funcionarem
Outras aplicações requerem
adequadamente
100% de fiabilidade na
transferência de dados
❍
ex: transferência de ficheiros
❍
Telnet
Timing
❒
Algumas aplicações
Algumas aplicações
❍
❒
ex: aplicações multimédia
Outras aplicações utilizam a largura de banda que conseguirem obter
❍
ex: aplicações elásticas
requerem um atraso
pequeno para funcionarem adequadamente
❍ ❍
ex: Telefonia na Internet Jogos interactivos
Camada de Aplicação
2-10
Requisitos do serviço de transporte para as aplicações comuns
Perda de Aplicação dados Transferência de ficheiros e-mail Documentos Web áudio/vídeo de tempo real
Não Não Tolerante Tolerante
áudio/vídeo armazenado Tolerante Jogos interactivos Tolerante Mensagens instantâneas Não
Largura de banda
Sensibilidade ao atraso
elástica elástica elástica áudio: 5K-1Mbps vídeo: 10K-5Mbps Igual ao anterior Poucos Kbps elástica
Não Não Não Sim, 100’s mseg Sim, alguns seg. Sim, 100’s mseg Sim e Não
Camada de Aplicação
2-11
Serviços do protocolo de transporte na Internet
Serviço UDP:
Serviço TCP:
❒
orientado à ligação: necessário
❒
estabelecimento de ligação
fiável entre o processo do
Servidor
receptor
emissor e o processo do
entre os processos Cliente e
❒
transporte fiável
entre o
processo emissor e o processo receptor
❒
controlo de fluxo: o emissor não sobrecarrega o receptor
❒
controlo de congestão: emissor reduz o envio quando a rede está sobrecarregada
❒
transferência de dados não
❒
não fornece estabelecimento de ligação, fiabilidade,
controlo de fluxo, controlo de congestão, garantia de atraso ou de largura de banda
Q: Porque existe?
Para que serve o UDP?
não fornece: garantia de atraso nem de largura de banda.
Camada de Aplicação
2-12
Aplicações Internet: protocolos de aplicação e transporte
Aplicação e-mail acesso remoto a terminais Web transferência de ficheiros streaming multimedia servidor de ficheiros remoto Telefonia Internet
Protocolo de nível de Aplicação
Protocolo de Transporte
SMTP [RFC 821] Telnet [RFC 854] HTTP [RFC 2068] FTP [RFC 959] proprietário (ex: RealNetworks) NFS proprietário (ex: Dialpad)
TCP TCP TCP TCP TCP ou UDP TCP ou UDP Tipicamente UDP
Camada de Aplicação
2-13
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
SMTP, POP3, IMAP
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-14
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 nome da máquina
path name Camada de Aplicação
2-15
A Web: O protocolo HTTP HTTP: HyperText
Transfer Protocol
❒
Protocolo de nível de aplicação da Web
❒
pe
PC a executar re
Internet Explorer
di do
sp o
st a
Modelo cliente-servidor
❍
Cliente: browser que
pede, recebe e mostra objectos Web
❍
Servidor: servidor Web envia objectos em
resposta a pedidos
❒
HTTP 1.0: RFC 1945
❒
HTTP 1.1: RFC 2616
p
e
d
id
re
o
sp
H
H
H
o
T
T
T
T P
T P
P T
a st
H
T
P T Servidor a executar
Servidor Web Apache
Mac a executar
Netscape Navigator
Camada de Aplicação
2-16
O protocolo HTTP (continuação) O HTTP não tem estado stateless
HTTP: usa o serviço de transporte TCP:
❒
❒
Cliente inicia a ligação TCP
❒
Clientes
à parte
Servidor aceita a ligação TCP
Protocolos que mantêm o
do Cliente
estado são complexos !
Mensagens HTTP (mensagens
❒
do protocolo de nível de
História passada (estado) tem de ser mantida
aplicação) transferidas entre o
❒
browser (Cliente HTTP) e o
Se o Servidor/Cliente
falharem, a sua visão do
Servidor Web (servidor HTTP)
❒
informação sobre os
pedidos anteriores dos
(cria um socket) para o Servidor, porto 80
❒
O Servidor não mantém
estado pode ficar
Fecho da Ligação TCP
inconsistente, e tem de ser conciliada
Camada de Aplicação
2-17
Ligações HTTP HTTP não persistente
❒
No máximo é enviado
HTTP persistente
❒
um objecto por cada
podem ser enviados
ligação TCP.
❒
Múltiplos objectos
por uma única ligação
TCP entre o cliente e o
HTTP/1.0 usa HTTP
servidor.
não persistente
❒
HTTP/1.1 usa ligações persistentes por omissão
Camada de Aplicação
2-18
HTTP não persistente Supondo que um utilizador introduz o URL
www.someSchool.edu/someDepartment/home.index 1a. Cliente HTTP inicia a ligação TCP para o Servidor HTTP (processo) em:
1b. Servidor HTTP no Sistema Terminal
www.someSchool.edu
❍
www.someSchool.edu.
❍
❍
porto 80 é utilizado por
espera a ligação TCP no porto 80,
❍
aceita pedido de estabelecimento
omissão para o acesso ao
de ligação
Servidor HTTP.
2. Cliente HTTP envia uma
mensagem para o socket da ligação TCP
❍
❍
notifica o cliente.
3. Servidor HTTP
mensagem de pedido
(contendo o URL) indica que o cliente quer o objecto
tempo
(contém texto, referência a 10 imagens do tipo jpeg)
someDepartment/home.index
❍
recebe a mensagem de pedido
❍
constrói a mensagem de resposta contendo o objecto pedido
❍
envia a mensagem para o socket.
Camada de Aplicação
2-19
HTTP não persistente (continuação) 4. Servidor HTTP pede o fecho 5. Cliente HTTP recebe a
mensagem de resposta
tempo
❍
Contendo ficheiro html,
❍
Mostra o ficheiro html.
❍
Interpreta o ficheiro html
❍
Encontra a referência a 10
❍
Fecha a ligação TCP
da ligação TCP
❍
A ligação só é fechada
quando o cliente recebe a resposta
objectos do tipo jpeg
6. Repete os passos 1 a 5 para
cada um dos 10 objectos jpeg
Camada de Aplicação
2-20
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
um RTT para o pedido HTTP e
❒
a resposta HTTP começar a chegar
tempo de transmissão do
❒
tempo para transmitir o ficheiro
RTT ficheiro recebido
tempo
tempo
ficheiro
total = 2.RTT+tempo de
Camada de Aplicação
transmissão
2-21
HTTP persistente HTTP não persistente
❒
2 RTTs por objecto
❒
O SO precisa de trabalhar
HTTP persistente sem pipelining
❒
reservando recursos para
Muitos browsers abrem
várias ligações em paralelo para ir buscar os objectos
❒
❒
o servidor mantém a ligação
❒
as mensagens HTTP
pipelining
❒
por omissão para HTTP/1.1
❒
o cliente envia pedidos assim que
❒
apenas um RTT para todos os
aberta depois de responder
seguintes do mesmo cliente vão pela mesma ligação
um RTT por cada objecto referido
HTTP persistente com
referidos
HTTP persistente
apenas quando recebeu a resposta do anterior
cada ligação TCP
❒
o cliente envia um novo pedido
encontra os objectos referidos
objectos referidos
Camada de Aplicação
2-22
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, POST, HEAD)
Linhas de
Cabeçalho
GET /somedir/page.html HTTP/1.0 Host: www.someschool.edu Connection: close User-agent: Mozilla/4.0 Accept-language:fr
Linha em branco
(carriage return,
(caracteres adicionais de carriage return, line feed)
line feed) indica o fim do cabeçalho
Camada de Aplicação
2-23
Formato das mensagens HTTP: pedido
Método
URL
Versão HTTP
Sistema Terminal em que os
objectos residem
GET /somedir/page.html HTTP/1.0 Host: www.someschool.edu Connection: close
Tipo de browser
Não utilizar ligações
User-agent: Mozilla/4.0
persistentes
Accept-language:fr O cliente prefere obter a versão francesa do objecto Camada de Aplicação
2-24
Mensagem de pedido HTTP: formato geral
Camada de Aplicação
2-25
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 do pedido (entity body)
método GET:
❒
os dados são enviados
no campo URL da linha do pedido:
www.somesite.com/animalsearch?monkeys&banana
Camada de Aplicação
2-26
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
Camada de Aplicação
2-27
Formato da mensagem HTTP: resposta linha de estado (protocolo,
código de estado,
descrição do estado)
linhas de
cabeçalho
linha em branco dados, e.g.,
HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html dados dados dados dados dados ...
ficheiro
HTML pedido
Camada de Aplicação
2-28
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
gerou a resposta
Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …...
data em que o objecto
foi criado, ou modificado
Content-Length: 6821 Content-Type: text/html
Nº de Bytes do objecto
tipo de
objecto
que está a ser enviado
dados dados dados dados dados ... Camada de Aplicação
2-29
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
Camada de Aplicação
2-30
Teste o HTTP (do lado do cliente) você mesmo
1. Fazer Telnet para o seu WEB site favorito:
telnet www.eurecom.fr 80
Abre ligação TCP para o porto 80 (porto por
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 !
Camada de Aplicação
2-31
Interacção utilizador-servidor: autenticação Autenticação : controlo de acessos ao conteúdo do servidor
❒
cliente
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
❍
linha de cabeçalho em cada pedido
❍
sem cabeçalho
+
Authorization:
Authorization:,
servidor recusa o acesso,
o
responde com o cabeçalho
WWW authenticate: ❒
servidor
pedido normal HTTP
Authorization:
resposta normal HTTP
pedido normal HTTP
+ Authorization: resposta normal HTTP
tempo
o browser memoriza a autorização, repetindo-a a cada pedido
Camada de Aplicação
2-32
Cookies: mantendo o estado Muito servidores Web
importantes usam cookies
Exemplo:
❍
Internet sempre do
Quatro componentes: 1) linha de cabeçalho cookie
na mensagem de resposta
mesmo PC
❍
na mensagem de pedido
Ela visita um servidor
de comércio electrónico
HTTP
2) linha de cabeçalho cookie
A Susana acede à
pela primeira vez
❍
HTTP
3) ficheiro de cookies
mantido na máquina do
utilizador e gerido pelo browser do utilizador
4) base de dados no servidor
Quando o primeiro
pedido HTTP chega ao
servidor, o servidor cria um identificador (ID)
único e cria uma entrada na sua base de dados para o ID
Web
Camada de Aplicação
2-33
Cookies: mantendo o estado (cont.) cliente
ebay: 8734 ficheiro de Cookies amazon: 1678 ebay: 8734
pedido HTTP normal resposta http normal +
Set-cookie: 1678 pedido HTTP normal
cookie: 1678 resposta HTTP normal
ficheiro de Cookies amazon: 1678 ebay: 8734
cria
para
Acção
específica da cookie
s aces
o
ac es s
uma semana mais tarde:
en ba trad se a n ID 1678 de a da do utilizador s
servidor
o
ficheiro de Cookies
servidor
pedido HTTP normal
cookie: 1678 resposta HTTP normal
Acção
específica da cookie
Camada de Aplicação
2-34
Cookies (continuação) O que os cookies podem oferecer:
à parte
Cookies e privacidade:
❒
os cookies permitem que os servidores aprendam
❒
autorização
❒
carrinhos de compras
❒
recomendações
❒
estado da sessão do
muito sobre você
❒
você pode dar o nome e email a um servidor
❒
utilizador (correio
motores de pesquisa usam redirecção e cookies para
electrónico via Web)
aprender ainda mais
❒
empresas de publicidade obtêm informação de vários servidores
Camada de Aplicação
2-35
GET condicional: cache no lado do cliente
❒
Objectivo: não enviar os
objectos se o cliente tiver
uma versão actualizada em cache
❒
servidor
cliente
cliente: especifica a data da cópia que tem em cache no pedido HTTP
msg pedido HTTP
If-modified-since: resposta HTTP
Objecto não
modificado
HTTP/1.0 304 Not Modified
If-modified-since: ❒
servidor: a resposta não
contém objectos se a cópia de cache do cliente estiver actualizada:
HTTP/1.0 304 Not Modified
msg pedido HTTP
If-modified-since: resposta HTTP
Objecto
modificado
HTTP/1.0 200 OK
Camada de Aplicação
2-36
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
2.6 Programação em
protocolos da camada
❍
clientes e servidores
❍
requisitos das
2.8 Construindo um
❒
servidor Web
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❒
2.7 Programação em Sockets com UDP
aplicações
❍
Sockets com TCP
2.9 Distribuição de
❒
conteúdos
SMTP, POP3, IMAP
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-37
FTP: o protocolo de transferência de ficheiros (file transfer protocol) interface
utilizador Utilizador num
FTP
Sistema Terminal
cliente
transferência
FTP
do ficheiro
servidor FTP
sistema
sistema
local
remoto
ficheiros
ficheiros
❒
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 Camada de Aplicação
2-38
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
❒
Cliente
o cliente obtém autorização
FTP
pela ligação de controlo
❒
o cliente lista os ficheiros
❒
remotos enviando comandos
Servidor FTP
o servidor abre uma segunda transferir outro ficheiro.
quando o servidor recebe um
❒
comando para uma
Ligação de controlo: fora de banda (out of band)
transferência de um ficheiro, o
❒
servidor abre uma ligação TCP
Servidor FTP mantém o
estado: directório actual,
de dados para o cliente
❒
porto 20
ligação TCP de dados para
pela ligação de controlo
❒
Ligação TCP de dados
autenticação anterior
depois de transferir um
ficheiro, o servidor fecha a
Camada de Aplicação
ligação.
2-39
Comandos FTP, respostas Exemplos de comandos:
❒
Enviados como texto
ASCII no canal de controlo
❒ PASS password ficheiros no directório corrente
devolve
(obtém) um ficheiro
❒ STOR filename
❒
Códigos de estado e
❒ 331 Username OK,
devolve a lista dos
❒ RETR filename
estado
descrição (como no HTTP)
❒ USER username
❒ LIST
Exemplo de códigos de
armazena
(põe) ficheiro no sistema remoto
❒ HELP [comando]
password required ❒ 125 data connection already open; transfer starting ❒ 425 Can’t open data connection ❒ 452 Error writing file Camada de Aplicação
2-40
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
SMTP, POP3, IMAP
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-41
Correio electrónico (E-Mail) agente
Três componentes fundamentais:
❒ ❒ ❒
agentes de utilizador
utiliz.
servidor
servidores de correio
a.k.a. programa de correio
❒
Compor, editar e ler
❒
e.g., Eudora, Outlook, elm,
❒
mensagens a enviar ou a
mensagens de correio Netscape Messenger
receber são armazenadas no servidor
servidor
SMTP
agente utiliz.
utiliz.
agente utiliz.
agente utiliz.
correio
agente
servidor correio
SMTP
Agente de Utilizador
❒
utiliz.
SMTP
Simple Mail Transfer Protocol: SMTP
agente
correio
fila de
espera de saída caixa de correio
Camada de Aplicação
2-42
Correio electrónico: servidores de correio agente
Servidores de Correio
❒
utiliz.
caixa de correio contém as
servidor
mensagens que entraram
para o utilizador (ainda não fila de espera de mensagens de correio que o utilizador quer enviar (ainda não
protocolo SMTP entre
servidores de correio para enviar as mensagens
❍
cliente: envia correio
❍
servidor: servidor de
para o servidor
recepção de correio
servidor
servidor correio
SMTP
enviadas)
❒
utiliz.
SMTP
lidas)
❒
agente
correio
SMTP
agente utiliz.
agente utiliz.
correio
agente
fila de
utiliz.
espera de saída
agente
caixa de correio
utiliz.
Camada de Aplicação
2-43
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
❒
Três fases de transferência
de recepção
❍ ❍ ❍
❒
transferência de mensagens fecho
Interacção comando-resposta
❍ ❍
❒
handshaking (apresentação)
comandos: texto ASCII
resposta: código e descrição de estado
Mensagens codificadas em ASCII de 7 bits
Camada de Aplicação
2-44
Cenário: Alice envia uma mensagem para Bruno 4) O cliente SMTP envia a
1) Alice usa um AU para compor
mensagem da Alice pela
uma mensagem para
ligação TCP
[email protected]
5) O servidor de correio do
2) O AU da Alice envia a
Bruno coloca a mensagem
mensagem para o seu
na caixa de correio do
servidor de correio; a
Bruno
mensagem é colocada em fila de espera
6) O Bruno invoca o seu
agente de utilizador para
3) O lado cliente do SMTP abre
ler a mensagem
uma ligação TCP com o
servidor de correio do Bruno
1 agente utiliz.
servidor
servidor 2
3
agente
correio
correio
4
5
6
utiliz.
Camada de Aplicação
2-45
Exemplo de interacção com SMTP
C: S: C: S: C: S: C: S: C: S: C: C: C: S: C: S:
telnet hamburger.edu 25-> Estabelecimento da lig. TCP 220 hamburger.edu HELO crepes.fr 250 Hello crepes.fr, pleased to meet you MAIL FROM: 250 [email protected]... Sender ok RCPT TO: 250 [email protected] ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Queres ketchup? Que tal pickles? . 250 Message accepted for delivery QUIT 221 hamburger.edu closing connection Camada de Aplicação
2-46
Experimentem o SMTP por vocês mesmos
❒
Digitar
❒
observar 220 resposta do servidor
❒
digitar comandos HELP, HELO, MAIL FROM, RCPT
telnet servername 25
TO, DATA, QUIT
❒
Os procedimentos anteriores permitem enviar
correio sem usar um cliente de correio (programa)
Camada de Aplicação
2-47
SMTP: palavras finais ❒
SMTP utiliza ligações persistentes
❒
SMTP requer que a
mensagem seja codificada em ASCII de 7 bits (cabeçalho e corpo)
❒
Comparação com HTTP:
❒
HTTP: puxa (pull)
❒
SMTP: empurra (push)
❒
Ambos têm interacção comando/resposta em
Servidor SMTP usa
CRLF.CRLF
ASCII, códigos de estado
para
identificar o fim da
❒
encapsula a sua própria
mensagem
❒
mensagem de resposta
Alguns caracteres não são permitidos na mensagem (e.g.,
CRLF.CRLF).
Então a
mensagem tem de ser
HTTP: cada objecto
❒
SMTP: múltiplos objectos enviados em múltiplas
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
RFC 822: formato standard para
Cabeçalho
em
mensagens de texto:
❒
branco
Linhas de cabeçalho, e.g.,
❍
To:
❍
From:
❍
Subject:
Linha
Corpo
diferente dos comandos SMTP
❒
Corpo
❍
a mensagem, apenas os caracteres ASCII
Camada de Aplicação
2-49
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 Versão MIME
Método usado para
codificar os dados
Tipo de dados multimédia, subtipo,
declaração de parâmetros Dados codificados
From: [email protected] To: [email protected] Subject: Imagem de saboroso doce. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg dados codificados em base64 ..... .................................. ...... dados codificados em base64
Camada de Aplicação
2-50
Tipos MIME
Content-Type: tipo/subtipo; parâmetros Texto (text)
❒
Exemplo de subtipos:
Vídeo (video)
❒
plain, html Imagem (image)
❒
Exemplo de subtipos:
Exemplo de subtipos:
mpeg, quicktime Aplicação (application)
❒
Outros dados que têm de
ser processados pelo leitor
jpeg, gif
antes de serem visíveis
Áudio (audio)
❒
Exemplo de subtipos :
basic
❒
Exemplo de sub-tipos :
msword, octet-stream
(codificação 8-bit
mu-law),
32kadpcm
(codificação de 32 kbps) Camada de Aplicação
2-51
Tipo Multipart
From: [email protected] To: [email protected] Subject: Imagem de saboroso doce. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Caro Bruno, junto envio imagem de um doce. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg dados codificados em base64 ..... ................................. ......dados codificados em base64 --StartOfNextPart Queres a receita?
Camada de Aplicação
2-52
Tipo Multipart - recepção
Received: from crepes.fr by hamburger.edu; 12 Oct 98 From: [email protected] To: [email protected] Subject: Imagem de saboroso doce. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Caro Bruno, junto envio imagem de um doce. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg dados codificados em base64 ..... ................................. ......dados codificados em base64 --StartOfNextPart Queres a receita?
Camada de Aplicação
2-53
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 From: [email protected] To: [email protected] Subject: Imagem de saboroso doce. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Caro Bruno, junto envio imagem de um doce. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg dados codificados em base64 ..... ................................. ......dados codificados em base64 --StartOfNextPart Queres a receita?
Camada de Aplicação
2-54
Estudo de um caso: Vírus Klez - Cabeçalho From [email protected] 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 <[email protected]>; Wed, 8 May 2002 21:57:12 +0100 (WEST) (envelope-from [email protected]) Received: from Kdccjtcr (unknown [200.163.62.20]) by smtp.brturbo.com (Postfix) with SMTP id 006D611E620 for <[email protected]>; Wed, 8 May 2002 17:50:17 -0300 (BRT) From: kit To: webmaster Destino obtido Subject: Japanese girl VS playboy numa página WEB Mime-Version: 1.0 Content-Type: multipart/alternative; Origem forjada boundary=AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3 Message-Id: <[email protected]> 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! Camada de Aplicação
2-55
Estudo de um caso: Vírus Klez - Mensagem --AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
HTML com suposto som para música de fundo
(extensão <iframe src=3Dcid:Rh5Y20734J height=3D0 width=3D0>
--AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3 Content-Type: audio/x-midi; name=kitty.pif Content-Transfer-Encoding: base64 Content-ID:
da Microsoft)
Programa executável com o vírus
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g (…) --AHdz7JR6BD7Tk7N1IvZU9l1q90A5tX90j3-Bug: ao tocar a música, corre o vírus!
Basta ver a mensagem para ficar infectado!
Camada de Aplicação
2-56
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 Camada de Aplicação
2-57
Protocolos de acesso ao Correio SMTP
SMTP
protocolo
agente
de acesso
utiliz.
servidor do emissor
do correio
❒ ❒
agente utiliz.
servidor do receptor
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
mais funcionalidades (mais complexo)
IMAP: Internet Mail Access Protocol [RFC 1730]
❍
manipulação das mensagens armazenadas nos servidores
HTTP: Hotmail , Yahoo! Mail, etc.
Camada de Aplicação
2-58
Protocolo POP3 Fase de autorização
❒
Comandos do cliente:
❍ ❍
❒
user: pass:
declara username password
Servidor responde
❍ ❍
+OK -ERR
Fase de transacção, cliente:
❒ list:
lista nº das mensagens
❒ retr:
obtém mensagens
❒ dele:
apaga
através no nº
❒ quit:
termina
C: S: C: S: C: S:
telnet hamburger.edu 110 +OK POP3 server ready user bruno +OK pass hungry +OK user successfully logged on
C: S: S: S: C: S: S: C: C: S: S: C: C: S:
list 1 498 2 912 . retr 1 <message 1 contents> . dele 1 retr 2 <message 1 contents> . dele 2 quit +OK POP3 server signing off Camada de Aplicação
2-59
POP3 (mais) e IMAP Mais sobre POP3
❒
O exemplo anterior usa o modo descarrega e apaga (download and delete).
❒
❒
de programa
❒
pastas
❒
❍
estado entre sessões
nomes de pastas e mapeamento
entre IDs de mensagem e nome de pasta
cópias de mensagens em
O POP3 não mantém
IMAP mantém estado entre sessões:
(Download-and-keep):
❒
Permite ao utilizador
organizar as mensagens em
Descarrega e mantém
clientes diferentes
Mantém todas as mensagens num único lugar: o servidor
O Bruno não pode voltar a ler o correio se mudar
❒
IMAP
❒
Utilizador pode obter apenas componentes específicos da mensagem
Camada de Aplicação
2-60
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
SMTP, POP3, IMAP
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-61
DNS: Domain Name System Pessoas: muitos
identificadores:
❍
Endereço IP (32 bit)
utilizado para endereçar datagramas
❍
❒
nome, e.g., www.ist.utl.pt usado pelos humanos
Base de dados distribuída
implementada numa hierarquia
de muitos servidores de nomes
#BI, nome, #passaporte
Internet hosts, routers:
❍
Domain Name System:
❒
Protocolo de nível de aplicação sistemas terminais, routers,
servidores de nomes comunicam para resolver nomes (tradução endereço/nome)
❍
Internet, implementada
como protocolo de nível de
Q: mapeamento entre
endereços IP e nomes ?
nota: função do núcleo da
aplicação
❍
complexidade na periferia da rede
Camada de Aplicação
2-62
Servidores de nomes DNS Servidores de nomes locais: (Local Name Server)
Porque não centralizar o DNS?
❍
❒
um só ponto de falha
❒
volume de tráfego
❒
base de dados
servidor de nomes local (default)
❍
sistemas terminais interrogam primeiro o Servidor de Nomes Local
centralizada distante
❒
cada ISP, instituição tem um
Servidor de nomes oficial
manutenção
(authoritative name server):
❍
Não escala !
para um sistema terminal:
guarda o seu nome, endereço IP
❒
Nenhum servidor tem
todos os mapeamentos de
❍
pode executar a tradução nome/endereço para esse sistema terminal Camada de
nome para endereço IP
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 d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA
k RIPE London i NORDUnet Stockholm m WIDE Tokyo
e NASA Mt View, CA f Internet Software C. Palo Alto, CA
13 servidores de nomes raiz no
b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA
mundo
Camada de Aplicação
2-64
servidor de
Exemplo simples de DNS a máquina
nomes raiz
surf.eurecom.fr
pretende o endereço IP de
2
4
gaia.cs.umass.edu
3
5
1. Contacta o seu servidor DNS local,
2.
dns.eurecom.fr dns.eurecom.fr contacta servidor de nomes raiz, se
o
servidor de nomes
servidor de nomes
dns.eurecom.fr
dns.umass.edu
local
necessário
3. o servidor de nomes raiz
1
contacta o servidor de nomes oficial,
dns.umass.edu,
necessário
oficial
6
se
máquina
gaia.cs.umass.edu
que pergunta
surf.eurecom.fr Camada de Aplicação
servidor de
Exemplo de DNS
nomes raiz
Servidor de nomes
6
2
raiz:
❒
2-65
7
3
Pode não conhecer o servidor oficial
❒
Pode conhecer servidores de nomes
servidor de nomes
contactar para descobrir
dns.eurecom.fr
intermédios: quem
o servidor de nomes
local
1
servidor de nomes intermédio
dns.umass.edu
8
oficial
4
5
servidor de nomes oficial
máquina
dns.cs.umass.edu
que pergunta
surf.eurecom.fr gaia.cs.umass.edu Camada de Aplicação
2-66
DNS: perguntas
servidor de nomes raiz
iterativas Perguntas
recursivas:
❒
3
coloca o peso da
4
resolução de nomes no servidor contactado
❒
carga elevada ?
Perguntas iterativas:
❒
o servidor contactado
7 servidor de nomes local
dns.eurecom.fr
1
contactar
❒
não conheço este
nome, mas pergunta a este servidor !!
servidor de nomes intermédio
dns.umass.edu
8
responde com o nome do servidor a
pergunta iterativa
2
5
6
servidor de nomes oficial
máquina
dns.cs.umass.edu
que pergunta
surf.eurecom.fr gaia.cs.umass.edu Camada de Aplicação
2-67
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
Camada de Aplicação
2-68
Registos DNS DNS: Registos de Recursos (Resource Records, RR) armazenados numa Base de Dados distribuída formato de um RR:
❒
Tipo=A
❍ ❍
(nome, valor, tipo, ttl) Tipo=CNAME
❒
nome do Sistema Terminal valor é um endereço IP
❍
é um sinónimo do nome
nome
canónico (o verdadeiro) www.ibm.com é realmente
❒
servereast.backup2.ibm.com
Tipo=NS
❍ ❍
nome
❍
é o domínio (e.g.
foo.com)
valor
é o endereço IP do
❒
valor
é o nome canónico
Tipo=MX
❍
servidor de nomes oficial
valor
é o nome do servidor
de correio associado com o
desse domínio
nome Camada de Aplicação
2-69
Exemplo de distribuição de carga usando DNS @tlinux:~/ > dig www.yahoo.com ;; ANSWER SECTION: www.yahoo.com. 308 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30 www.yahoo.akadns.net. 30
IN IN IN IN IN IN IN IN IN
CNAME A A A A A A A A
www.yahoo.akadns.net. 216.109.118.67 216.109.118.70 216.109.118.76 216.109.118.78 216.109.118.72 216.109.118.74 216.109.118.68 216.109.118.73
CNAME A A A A A A A A
www.yahoo.akadns.net. 216.109.118.77 216.109.118.73 216.109.118.64 216.109.118.66 216.109.118.78 216.109.118.67 216.109.118.76 216.109.118.71
Passado algum tempo:
@tlinux:~/ > dig www.yahoo.com ;; ANSWER SECTION: www.yahoo.com. 253 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8 www.yahoo.akadns.net. 8
IN IN IN IN IN IN IN IN IN
Camada de Aplicação
2-70
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
Camada de Aplicação
2-71
Camada de Aplicação
2-72
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
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
SMTP, POP3, IMAP
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-73
Programação em Sockets Objectivo: aprender a construir aplicações
cliente/servidor que comunicam através de sockets
API de Sockets
❒
introduzida no UNIX BSD4.1, 1981
❒
criado explicitamente,
utilizado, libertado pelas aplicações
❒
paradigma cliente/servidor
❒
dois tipos de serviço de
transporte através da API de sockets:
❍
não fiável, datagramas
❍
fiável, transmissão de bytes com ligação
socket uma interface (uma
porta) local à maquina, criada pela aplicação,
controlada pelo SO para a qual o processo de
aplicação pode tanto
enviar como receber
mensagens de/para outro processo de aplicaçã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
programador da
aplicação
controlado
pelo sistema operativo
processo
processo
socket
socket
TCP com buffers,
variáveis
programador da aplicação
TCP com
controlado
variáveis
operativo
buffers,
internet
controlado pelo
pelo sistema
cliente ou
cliente ou
servidor
servidor
Camada de Aplicação
2-75
Programação em Sockets com TCP O cliente tem de contactar o servidor
❒
primeiro o servidor tem de estar a correr
❒
o servidor tem de ter
❒
Quando contactado pelo cliente, o servidor TCP cria um novo socket para o processo servidor comunicar com o cliente
❍
com múltiplos clientes
criado um socket que aceita contactos de clientes
O cliente contacta o servidor da seguinte forma:
❒
criando um socket TCP local ao cliente
❒
especificando o endereço IP, número de porto do processo servidor
❒
estabelecendo ligação com o servidor TCP
permite que o servidor fale
❍
número de porto de origem utilizado para distinguir
clientes (mais no Capítulo 3) ponto de vista da aplicação O TCP oferece transferência fiável de bytes (pipe) entre cliente e servidor
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 ( )
aceita ligação
Clie nte
accept ( ) bloqueia até ter ligação de um cliente
estabelecimento de ligação
lê pedido
read ( )
socket ( )
cria socket
connect ( )
pede ligação
write ( )
envia pedido
read ( )
lê resposta
dados(pedido)
processa pedido envia resposta
write ( )
dados(resposta) Camada de Aplicação
2-77
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
protocolos da camada
❍
clientes e servidores
❍
requisitos das aplicações
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❍
❒
SMTP, POP3, IMAP
2.6 Programação em Sockets com TCP
2.7 Programação em Sockets com UDP
❒
2.8 Construindo um servidor Web
❒
2.9 Distribuição de conteúdos
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
❍
partilha de ficheiros P2P Camada de Aplicação
2-78
Programação em Sockets com UDP UDP: sem ligação entre cliente e servidor
❒
sem handshaking
❒
emissor explicitamente
coloca endereço IP e porto em cada pacote
❒
ponto de vista da aplicação UDP oferece transferência não fiável
o servidor tem de extrair
de grupos de bytes
(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
Camada de Aplicação
2-79
Interacção cliente/servidor com sockets: UDP
Se rvido r cria socket associa porto de escuta
lê pedido
socket ( ) bind ( )
Clie nte
recvfrom ( )
socket ( )
cria socket
bloqueia até receber dados de um cliente
sendto ( )
envia pedido
recvfrom ( )
lê resposta
dados(pedido) processa pedido envia resposta
sendto ( )
dados(resposta)
Camada de Aplicação
2-80
Construindo um servidor Web simplificado
❒
aceita ligação
❒
aceita pedido HTTP
❒
interpreta cabeçalhos
❒
obtém o ficheiro pedido
❒
servidor, pode pedir ficheiros com um browser (eg
Netscape), ou com
do sistema de ficheiros do servidor
❒
cria mensagem de
depois de criar o
Telnet
❒
aulas de laboratório
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-12sockets.html
Camada de Aplicação
2-82
Capítulo 2: Sumário
❒
2.1 Princípios dos
❒
de aplicação
❒
2.6 Programação em
protocolos da camada
❍
clientes e servidores
❍
requisitos das
Sockets com TCP
Sockets com UDP
servidor Web
❒
2.2 Web e HTTP
❒
2.3 FTP
❒
2.4 Correio electrónico
❒
2.8 Construindo um
❒
aplicações
❍
2.7 Programação em
2.9 Distribuição de
❒
conteúdos
SMTP, POP3, IMAP
❍
Redes de caches Web
❍
Redes de distribuição de conteúdos
2.5 DNS
partilha de ficheiros P2P
❍
Camada de Aplicação
2-83
Caches Web (servidores proxy) Objectivo: satisfazer os pedidos dos clientes sem envolver o servidor original
❒
servidor
Utilizador configura o
original
browser: acessos Web através da cache
❒
cliente envia todos os pedidos HTTP para a
pe
re cliente sp
di do
os ta
cache
❍
objecto existe na cache: cache web devolve o
p
e
caso contrário, cache
Web pede o objecto ao servidor original e
id
re
objecto
❍
d
cliente
o
sp
H
H
H
o
servidor
T
T
T
T P
T P
P T
a st
Proxy
H
T
pe
do di
o sp re
H
T
a st
P T
H
T
P T
P T
servidor original
retorna este objecto ao cliente
Camada de Aplicação
2-84
Mais sobre caches Web ❒
Cache actua tanto como cliente como servidor
❒
Cache pode fazer
verificação de actualização com o cabeçalho HTTP:
If-modified-since ❍
Problema: deve a cache
correr um risco e entregar o objecto em cache sem verificar?
❍
❒
são utilizadas heurísticas.
Tipicamente, a cache é
Porquê caches Web?
❒
Reduz o tempo de resposta para pedidos do cliente.
❒
Reduz tráfego na linha de acesso da instituição.
❒
A densidade de caches na Internet permite que os
fornecedores de conteúdos pobres, com linhas de
baixo ritmo, efectivamente forneçam conteúdos
instalada pelo ISP
(universidade, empresa, ISP residencial)
Camada de Aplicação
2-85
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
para qualquer servidor de origem e regresso ao router = 2 seg Consequências
❒
utilização na LAN = 15%
❒
utilização na linha de acesso = 100%
❒
atraso total
1.5 Mbps rede
institucional
LAN a 10 Mbps
= atraso na Internet +
atraso no acesso + atraso na LAN =
2 seg + minutos + milissegundos Camada de Aplicação
2-86
Exemplo de caches (2) 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%
❒
atraso total
atraso no acesso + atraso na LAN =
2 seg + msegs + msegs normalmente uma actualização cara
❒
Ligação de acesso
= atraso na Internet +
10 Mbps rede
institucional
LAN a 10 Mbps
Camada de Aplicação
2-87
Exemplo de caches (3) servidores
Instalar cache
❒
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
❒
reduzida para 60%, resultando em atrasos desprezáveis (digamos: 10 mseg)
❒
Ligação de acesso
a utilização da linha de acesso é
1.5 Mbps rede
institucional
LAN a 10 Mbps
atraso total = atraso na
Internet + atraso no acesso + atraso na LAN =
0.6*2 seg + 0.6*0.010 segs +
cache institucional
milissegundos < 1.3 segs
Camada de Aplicação
2-88
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
fornecedor actualiza o
na América do Sul
conteúdo, a CDN actualiza os
servidor CDN na Europa
servidores
servidor CDN na Ásia
Camada de Aplicação
Exemplo de CDN 1
2-89
pedido HTTP para www.foo.com/sports/sports.html 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 de origem
servidor CDN próximo
Empresa de CDN
❒
www.foo.com
❒
cdn.com
❒
distribui HTML
❒
distribui ficheiros gif
❒
substitui:
❒
usa o servidor de DNS
http://www.foo.com/sports/ruth.gif por
http://www.cdn.com/www.foo.com/sports/ruth.gif
oficial para encaminhar
pedidos redireccionados Camada de Aplicação
2-90
Mais sobre CDNs encaminhamento de pedidos
❒
A CDN cria um mapa,
indicando as distâncias
dos ISPs aos nós da CDN
❒
não apenas páginas Web
❒
armazenado
❒
fluxos de áudio/vídeo em tempo real
quando o pedido chega
❍
ao servidor DNS oficial:
❍
fluxos de áudio/vídeo
nós CDN criam rede de 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
Camada de Aplicação
2-91
Partilha de ficheiros P2P
❒ Exemplo
❒
A Alice corre a aplicação
Bruno.
❒
❒
liga-se à Internet
Alice: HTTP
❒
utilizadores descarregam
um endereço IP para
❒
pede por Hey Jude
❒
a aplicação mostra
outros pares que têm
uma cópia de Hey Jude.
enquanto a Alice descarrega o ficheiro, outros
temporariamente; obtém cada ligação
o ficheiro é copiado do PC do Bruno para o portátil da
cliente P2P no seu
computador portátil
Alice escolhe um dos pares,
ficheiros da Alice.
❒
o programa da Alice é
simultaneamente cliente Web e servidor Web temporário.
Todos os pares são servidores = escala muito!
Camada de Aplicação
2-92
P2P: Directório Centralizado desenho original do Napster
1) quando um par se liga,
Bruno servidor de directório
1
centralizado
pares
informa o servidor
1
central:
❍
endereço IP
❍
conteúdo
3
1 2
1
2) Alice pergunta por Hey Jude
3) Alice pede o ficheiro do Bruno
Alice
Camada de Aplicação
2-93
P2P: problemas com directório centralizado
L
único ponto de falha
a transferência de
L
estrangulamento de
ficheiros é
desempenho L
infracção de direitos de autor
descentralizada, mas a localização de conteúdos é altamente centralizada
Camada de Aplicação
2-94
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) Camada de Aplicação
2-95
Mais sobre directórios descentralizados
rede sobreposta
❒
pares são nós
❒
arcos entre pares e o
vantagens da aproximação J
directório centralizado
seu líder de grupo
❒ ❒
vizinhos virtuais
nó de arranque
❒
❍
um par que se ligue é associado a um líder de
serviço de localização distribuído pelos pares
arcos entre alguns pares de líderes de grupo
não há servidor de
❍
mais difícil de desactivar
desvantagens da aproximação L
necessários nós de arranque
L
líderes de grupo podem ser sobrecarregados
grupo ou designado como líder
Camada de Aplicação
2-96
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
Camada de Aplicação
2-97
P2P: mais sobre inundação de pedidos Prós J
pares têm
Contras L
responsabilidades similares: não há
excessivo L
líderes de grupo J
J
tráfego de pedidos
raio de alcance de pedido: pode não
altamente
encontrar o conteúdo
descentralizado
quando ele existe
nenhum par mantém informação de directório
L
nó de arranque
L
manutenção da rede sobreposta
Camada de Aplicação
2-98
Capítulo 2: Sumário O estudo das aplicações está completo !
❒
requisitos do serviço de aplicação:
❍
❒
protocolos específicos:
fiabilidade, ritmo, atraso
❒
paradigma clienteservidor
❒
modelo de serviço de transporte na Internet
❍
HTTP
❍
FTP
❍
SMTP, POP, IMAP
❍
DNS
❒
programação em sockets
❒
distribuição de conteúdos
Serviço orientado à ligação, fiável: TCP
❍
❍
❍
caches, CDNs
❍
P2P
Não fiável, datagramas: UDP Camada de Aplicação
2-99
Capítulo 2: Sumário Mais importante: aprenderam-se protocolos
❒
tipicamente transferência de
❒
mensagens de dados
mensagens pedido/resposta:
❍
Cliente pede informação ou
❍
serviço
❍
Servidor responde com dados, código de estado
❒
formato das mensagens:
❍
Cabeçalho (header): campos que fornecem informação
dados: informação a ser
em banda (in-band), fora da banda (out-of-band)
❒
Centralizado vs. distribuído
❒
Sem estado vs. com estado (stateless vs statefull)
❒
Transferência de mensagens fiável vs. não fiável
sobre os dados
❍
mensagens de controlo vs.
❒
complexidade na periferia da rede
comunicada
❒
segurança: autenticação Camada de Aplicação
2-100