SILÊNCIO !!!!
2: Nível de Aplicação
1
Parte 2: Nível de Aplicação
Objectivos
r conceitos, aspectos de
implementação dos
protocolos de nível de
aplicação
m Paradigma clienteservidor
m Modelos de serviço
r Aprender os protocolos,
examinando protocolos de
nível de aplicação
populares
Outros objectivos do
capítulo:
r Protocolos específicos:
m
m
m
m
m
r
http
ftp
smtp
pop
dns
Programação de
aplicações de rede
m
API de socket
2: Nível de Aplicação
2
Aplicações e protocolos de nível de aplicação
Aplicação: comunicação, processo
distribuído
m
m
m
Executadas nos Sistemas
Terminais da rede em espaço
de utilizador (user-space)
Troca de mensagens para
implementar a aplicação
Ex: email, ftp, Web
Aplicação
Transporte
Rede
Lig. Lógica
Físico
Protocolos de nível de aplicação
m
m
m
Uma “parte” da aplicação
Define as mensagens
transferidas entre as
aplicações e as acções a
executar
Utiliza os serviços de
comunicação dos níveis
inferiores (TCP ou UDP).
Aplicação
Transporte
Rede
Lig. Lógica
Físico
Aplicação
Transporte
Rede
Lig. Lógica
Físico
2: Nível de Aplicação
3
Aplicações de rede: terminologia
Processo: Programa
executado num nó.
r Dentro do mesmo nó,
dois processos em
comunicação utilizam
comunicação entre
processos (definida pelo
sistema operativo)
r Processos executados
em nós diferentes
comunicam através do
protocolo de nível de
transporte
r
Agente de utilizador (user
agent): processo de SW que
faz a interface entre o
utilizador “acima” e a rede
“abaixo”
m Implementa o protocolo
de nível de aplicação
m Ex:
• Web: browser
• E-mail: mail reader
• streaming audio/video:
media player
2: Nível de Aplicação
4
O paradigma Cliente-Servidor
Aplicações de rede típicas têm
duas partes: Cliente e o
Servidor
Cliente:
r
r
r
r
Inicia o contacto com o Servidor
(“Fala primeiro”)
Tipicamente, requisita serviços ao
Servidor
Ex: Web: Cliente implementado num
browser;
e-mail: Cliente implementado num mailreader
Servidor:
r
r
Aplicação
Transporte
Rede
Lig. Lógica
Físico
request
reply
Aplicação
Transporte
Rede
Lig. Lógica
Físico
Fornece os serviços requisitados
pelos Clientes
Ex: Servidor Web envia páginas
pedidas; Servidor de mail entrega
emails.
2: Nível de Aplicação
5
Protocolos de nível de aplicação (cont).
API: Interface de
Q: Como é que o processo
programação de
identifica o outro
aplicação
processo com que quer
comunicar ?
r Define a interface entre
m Endereço IP do Sistema
as aplicações e o nível
Terminal que executa o
de transporte
outro processo
r socket: Internet API
m “Número do porto” –
m
Dois processos comunicam
enviando dados para um
socket e lendo os dados
do socket.
Permite que o Sistema
Terminal receptor
identifique o processo
para o qual se destinam
os dados
… Muito mais mais tarde (???) final deste capítulo/SO.
2: Nível de Aplicação
6
Que serviços de transporte é que uma
aplicação necessita ?
Perda de dados
r Algumas aplicações toleram
algumas falhas
m
r
ex: audio
Outras aplicações requerem
100% de fiabilidade na
transferência de dados
m
m
ex: transferência de ficheiros
telnet
Largura de Banda
r Algumas aplicações
requerem um atraso
pequeno para funcionarem
adequadamente
m
r
ex: aplicações multimédia
Outras aplicações utilizam a
largura de banda que
conseguirem obter
Timing
m ex: aplicações elásticas)
r Algumas aplicações
requerem um atraso
pequeno para funcionarem
adequadamente
m
m
ex: Telefonia na Internet
Jogos interactivos)
2: Nível de Aplicação
7
Requisitos do serviço de transporte das aplicações comuns
Perda de
Aplicação dados
Transferência de ficheiros
e-mail
Documentos Web
audio/video de tempo real
Não
Não
Tolerante
Tolerante
audio/video armazenado Tolerante
Jogos interactivos Tolerante
Aplicações financeiras Não
Largura de
banda
Sensibilidade
ao atraso
elástica
elástica
elástica
audio: 5Kb-1Mb
video:10Kb-5Mb
Igual ao anterior
Poucos Kb/s
elástica
Não
Não
Não
Sim, 100’s mseg
Sim,alguns seg.
Sim, 100’s mseg
Sim e Não
2: Nível de Aplicação
8
Serviços do protocolo de transporte da
Internet
Serviço TCP:
Serviço UDP:
r
r
r
r
r
r
Orientado-à-ligação:
estabelecimento do Cliente
para o Servidor
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
Não fornece: garantia de
atraso ou de largura de
banda.
r
Transferência de dados
não fiável entre o
processo do emissor e o
processo do receptor
Não fornece
estabelecimento de
ligação, fiabilidade,
controlo de fluxo,
controlo de congestão,
garantia de atraso ou de
largura de banda
Q: O que importa? Para que
serve o UDP ?
2: Nível de Aplicação
9
Aplic. internet: aplicações e protocolos de 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)
NSF
proprietário
(ex: Vocaltec)
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
Tipicamente UDP
2: Nível de Aplicação
10
SILÊNCIO !!!!
2: Nível de Aplicação
11
A Web: O protocolo HTTP
http: hypertext transfer
protocol
r
r
r
r
Protocolo de nível de
aplicação da Web
Modelo cliente-servidor
m Cliente: browser que
pede, recebe e mostra
objectos Web
m Servidor: Servidor Web
envia objectos em
resposta a pedidos
http1.0: RFC 1945
http1.1: RFC 2068
PC a executar
Internet Explorer
Servidor a executar
NCSA Web
server
Mac a executar
Netscape Navigator
2: Nível de Aplicação
12
O protocolo HTTP: mais
http: Serviço de
transporte TCP:
r
r
r
r
Cliente inicia a ligação TCP
(cria um socket) para o
Servidor, porto 80
Servidor aceita a ligação
TCP do Cliente
Mensagens http (mensagens
do protocolo de nível de
aplicação) transferidas
entre o browser (Cliente
http) e o Servidor Web
(servidor http)
Fecho da Ligação TCP
http não tem estado
“stateless”
r
O Servidor não
mantém informação
sobre os pedidos
anteriores dos
Clientes
Protocolos que mantêm o
estado são complexos !
r História passada (estado)
tem de ser mantida
r Se o Servidor/Cliente
falharem a sua visão do
estado pode ficar
inconsistente, e tem de ser
conciliada
2: Nível de Aplicação
13
Exemplo: http
Supondo que um utilizador introduz o URL
(contem texto,
www.someSchool.edu/someDepartment/home.index Referência a 10
imagens do tipo jpeg)
1a. Cliente http inicia a ligação
TCP (processo) ao Servidor
1b. Servidor http no Sistema
http em:
Terminal www.someSchool.edu
m
m
www.someSchool.edu.
Porto 80 é utilizado por
omissão para o acesso ao
Servidor http.
m
m
m
2. Cliente http envia uma
mensagem para o socket da
ligação TCP
m
tempo
request message (contendo o
URL)
espera a ligação TCP no porto 80,
aceita pedidos de
estabelecimento de ligação
notifica os Clientes.
3. Servidor http
m
m
m
recebe mensagens de pedido
constrói a response message
contendo os objectos pedidos
(someDepartment/home.index)
envia a mensagem no socket.
2: Nível de Aplicação
14
Exemplo: http (cont)
4. Servidor http pede o fecho
5. Cliente http recebe mensagens
de resposta
m
m
tempo
m
m
m
Contendo ficheiro html,
Mostra o ficheiro html.
Interpreta o ficheiro html
Encontra a referência a 10
objectos do tipo jpeg objects
Fecha a ligação TCP
6. Repete os passos 1 a 5 para
cada um dos 10 objectos
jpeg
da ligação TCP
m
A ligação só é fechada
quando o cliente recebe a
resposta
Ligação não
persistente
2: Nível de Aplicação
15
Ligações não persistentes e ligações
persistentes
Não persistentes
r
r
r
r
http/1.0: Servidor
interpreta o pedido,
responde e fecha a ligação
TCP
Persistentes
r
r
2 RTTs para obter o objecto
m
Ligação TCP
m
Pedido/transferência do
objecto
Cada transferência é
afectada pelo ritmo inicial
lento do TCP (slow rate)
Muitos browsers abrem
várias ligações em paralelo
r
r
Por omissão para htp/1.1
Na mesma ligação TCP:
servidor interpreta o
pedido, responde e
interpreta novos pedidos,..
Cliente envia pedidos para
todos os objectos
referenciados, assim que
recebe o objecto de base
HTML
Menos RTTs, slow start
menos significativo
2: Nível de Aplicação
16
Formato das mensagens http: request
Dois tipos de mensagens http: request, response
r http request message:
r
m
ASCII (Formato legível pelos Humanos)
request line
(GET, POST,
HEAD commands)
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
Carriage return,
(extra carriage return, line feed)
line feed
Indicam o fim da mensagem
2: Nível de Aplicação
17
Formato das mensagens http: request
Método
Sistema Terminal
em que os
objectos residem
url
Versão http
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
Não utilizar
ligações
persistentes
Connection: close
Tipo de browser
User-agent: Mozilla/4.0
Accept-language:fr
O cliente prefere obter a versão francesa do
objecto
2: Nível de Aplicação
18
http request message: formato geral
2: Nível de Aplicação
19
Formato da mensagem http: response
Linha de estado
(protocolo
Código de estado
Descrição do estado)
Linhas de
cabeçalho
dados, i.e.,
Ficheiro
html pedido
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
data data data data data ...
2: Nível de Aplicação
20
Formato da mensagem http: response
Tempo em que as
resposta foi criada no
servidor
Servidor que
gerou a resposta
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 …...
Tempo em que o objecto
foi criado, ou modificado
Content-Length: 6821
Content-Type: text/html
Nº de Bytes do objecto
que está a ser enviado
Tipo de
objecto
data data data data data ...
2: Nível de Aplicação
21
Códigos de resposta http
Na primeira linha da mensagem de resposta Servidor->Cliente
Alguns exemplos de códigos:
200 OK
m
Pedido com sucesso, objecto pedido “mais tarde” na
mensagem
301 Moved Permanently
m
Objecto pedido foi movido, nova localização específicada
mais tarde na mensagem (Location:)
400 Bad Request
m
Mensagem de pedido não foi entendida pelo servidor
404 Not Found
m
Objecto pedido não foi encontrado no servidor
505 HTTP Version Not Supported
2: Nível de Aplicação
22
Executando o protocolo http (do lado do
cliente)….
1. Fazer telnet para o WEB site favorito:
telnet www.eurecom.fr 80 Abre a ligação TCP para o porto 80
(Porto por omissão do servidor http) e,
www.eurecom.fr.
O que for digitado é enviado para este porto em
www.eurecom.fr
2. Digitar um pedido http, (GET):
GET /~ross/index.html HTTP/1.0
Ao digitar isto (introduzindo CR 2X), é
enviado um pedido mínimo, mas
completo, para o servidor http
3. Analise as respostas enviadas pelo servidor http !
2: Nível de Aplicação
23
User-server interaction: authentication
Authentication : control access
server
client
to server content
usual http request msg
r authorization credentials:
typically name, password
401: authorization req.
WWW authenticate:
r stateless: client must present
authorization in each request
m authorization: header line in
usual http request msg
+ Authorization: <cred>
each request
m if no authorization: header,
usual http response msg
server refuses access,
sends
WWW authenticate:
header line in response
usual http request msg
+ Authorization: <cred>
usual http response msg
time
2: Nível de Aplicação
24
SILÊNCIO !!!!
2: Nível de Aplicação
25
Cookies: mantendo o “estado”
r
r
cliente
servidor
Servidor gera um nº ,
servidor recorda o nº
http request msg usual
para usar mais tarde:
http response usual +
m autenticação
Set-cookie: #
m Recordar as
preferências do
utilizador, escolhas
http request msg usual
Acção
anteriores
cookie: #
específica
Servidor envia a “cookie”
http response msg usual
da cookie
na mensagem de resposta
do cliente
Set-cookie: 1678453
r
Cliente adiciona a
“cookie” aos pedidos
seguintes:
http request msg usual
cookie: #
http response msg usual
Acção
específica
da cookie
cookie: 1678453
2: Nível de Aplicação
26
GET condicional: cache no lado do cliente
r
r
Objectivo: não enviar os cliente
objectos se o cliente tiver
http request msg
uma versão actualizada em
If-modified-since:
<date>
cache
cliente: específica a data da
http response
cópia que tem em cahce no
HTTP/1.0
http request
304 Not Modified
servidor
Objecto não
modificado
If-modified-since: <date>
r
servidor: a resposta não
contém objectos se a cópia de
cache do cliente estiver
actualizada:
HTTP/1.0 304 Not Modified
http request msg
If-modified-since:
<date>
http response
Objecto
modificado
HTTP/1.1 200 OK
<data>
2: Nível de Aplicação
27
Caches Web (proxy server)
Objectivo: satisfazer os pedidos dos clientes sem
envolver o servidor original
r
r
Uitilizador activa o
browser: acessos Web
através da cache
Cliente envia todos os
http requests para a
cache
m
m
Objecto existe na
cache: cache web
devolve o objecto
Caso contrário, cache
Web pede o objecto ao
servidor original e
retorna este objecto ao
cliente
origin
server
client
client
Proxy
server
origin
server
2: Nível de Aplicação
28
Porquê Web Caching?
Considerando que: a
cache está mais
próximo do cliente (i.e.
na mesma rede)
r Tempo de resposta
menor: cache “mais
perto” do cliente
r Diminui o tráfego para
servidores distantes
m
Ligação de saída da
instituição/rede do ISP
é o ponto de
estrangulamento
(bottleneck)
Servidores
de origem
Internet
pública
Ligação de acesso
1.5 Mbps
Rede
institucional
LAN a 10 Mbp
Cache institucional
2: Nível de Aplicação
29
ftp: o protocolo de transferência de
ficheiros (file transfer protocol)
Utilizador num
Sistema Terminal
r
r
r
r
Interface Cliente
utilizador FTP
FTP
Sistema
ficheiros
local
file transfer
Servidor
FTP
Sistema
ficheiros
remoto
Transferência de ficheiros de/para o Sistema Terminal
Modelo Cliente-Servidor
m Cliente: Inicia a transferência (de/para o Sistema
remoto)
m Servidor: Sistema Remoto
ftp: RFC 959
ftp server: port 21
2: Nível de Aplicação
30
ftp: Controlo separado, ligações de dados
r
r
r
Cliente ftp contacta o
servidor no porto 21,
especificando o TCP como
protocolo de transporte
São abertas duas ligações
TCP em paralelo:
m controlo: transferência de
Cliente
comandos, respostas
FTP
entre cliente e servidor.
Controlo (ou sinalização)
“out of band”
m Dados: ficheiro de dados
de/para o servidor
Servidor ftp mantém o
estado: directório actual,
autenticação anterior
Ligação de controlo TCP
porto 21
Ligação de dados TCP
Servidor
porto 20
FTP
2: Nível de Aplicação
31
Comandos ftp, respostas
Exemplos de comandos:
r
r
r
r
r
r
Enviados como texto
ASCII no canal de controlo
USER username
PASS password
LIST devolve a lista dos
ficheiros no directório
corrente
RETR filename devolve
(get) um ficheiro
STOR filename armazena
(put) ficheiro no Sistema
Remoto
Exemplo de códigos de
estado
r
r
r
r
r
Códigos de estado e
descrição (como no http)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
2: Nível de Aplicação
32
Correio electrónico E-Mail
outgoing
message queue
user mailbox
Três componentes
fundamentais:
r
r
r
Agentes utilizador
Servidores de mail
Protocolo de comunicação
entre servidores:
m
simple mail transfer
protocol: smtp
Agente Utilizador
r a.k.a. “mail reader”
r Compor, editar e ler
mensagne de mail
r e.g., Eudora, Outlook, elm,
Netscape Messenger
r Enviar, receber mensagens
armazenadas no servidor
user
agent
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
2: Nível de Aplicação
33
Correio electrónico: servidores de email
Servidores de Mail
r
r
r
mailbox contém as
mensagens que entraram
(ainda não lidas) para o
utilizador
message queue de
mensagens de mail que o
utilizador quer enviar (ainda
não enviadas)
smtp protocol entre
servidores de email para
enviar as mensagens
m cliente: envia email para
o servidor
m “server”: servidor de
recepção de email
user
agent
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
2: Nível de Aplicação
34
Correio electrónico : smtp [RFC 821]
r
r
r
r
r
Utiliza TCP para transferir mensagens de email 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
m handshaking (greeting)
m Transferência de mensagens
m fecho
Interacção comando-resposta
m commandos: texto ASCII
m resposta: código e descrição de estado
Mensagens codificadas em 7 bits ASCII
2: Nível de Aplicação
35
Experimentem o smtp por vocês mesmos
r
Digitar telnet servername 25
observar 220 reply from server
r digitar comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT
r Os procedimentos anteriores permitem enviar
emails sem usar um cliente de email (reader)
r
2: Nível de Aplicação
36
Exemplo de interacção com smtp
Crepes.fr
Hamburger.edu
Do you like ketchup ?
What about pickles ?
2: Nível de Aplicação
37
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 2-> Estabelecimento da lig. TCP
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
2: Nível de Aplicação
38
smtp: palavras finais
r
r
r
r
smtp utiliza ligações
persistentes
smtp requer que a
mensagem seja codificada
em 7 bits ASCII
(cabeçalho e corpo)
Alguns caracteres não são
permitidos na mensagem
(e.g., CRLF.CRLF). Então a
mensagem tem de ser
codificadas (ex: base-64 ou
quoted printable)
Servidor smtp usa
CRLF.CRLF para
identificar o fim da
mensagem
Comparação com http:
r
r
r
r
r
http: pull
email: push
Ambos têm interacção
comando/resposta em
ASCII, códigos de estado
http: cada objecto
encapsula a sua própria
mensagem de resposta
smtp: múltiplos objectos
enviados em múltiplas
partes (multipart message)
2: Nível de Aplicação
39
Formato da mensagem de Mail
smtp: protocolo para transferir
mensagens de mail
RFC 822: formato standard para
mensagens de texto:
r Linhas de cabeçalho, e.g.,
m
m
m
To:
From:
Subject:
header
Linha
em
branco
body
diferente dos comandos smtp
r
Corpo
m
Apenas os caracteres ASCII
da mensagem
2: Nível de Aplicação
40
Formato das mensagens: extensões multimédia
r
r
MIME: extensões de mail 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,
sub-tipo,
declaração de parâmetros
Dados codificados
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
2: Nível de Aplicação
41
Tipos MIME
Content-Type: type/subtype; parameters
Texto
Video
r
r
Exemplo de sub-tipos:
plain, html
Imagem
r
Exemplo de sub-tipos:
jpeg, gif
Aplicação
r
Audio
r
Exemplo de sub-tipos :
basic (8-bit mu-law
encoded), 32kadpcm (32
kbps coding)
Exemplo de sub-tipos :
mpeg, quicktime
r
Outros dados que têm de
ser processados pelo leitor
antes de serem “visíveis”
Exemplo de sub-tipos :
msword, octet-stream
2: Nível de Aplicação
42
Tipo Multipart
Para incluir no email
múltiplos objectos
From: [email protected]
To: [email protected]
Início da
Subject: Picture of yummy crepe.
próxima parte
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789-2: Nível de Aplicação
43
Tipo Multipart - recepção
Received: from crepes.fr by hamburger.edu; 12 Oct 98
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789-2: Nível de Aplicação
44
Tipo Multipart - forwarding
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: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
2: Nível de Aplicação
45
Protocolos de acesso ao Mail
user
agent
SMTP
SMTP
POP3 or
IMAP
user
agent
Servidor de envio Servidor de recepção
de mail
de mail
r
r
SMTP: entrega/armazena mail no servidor de envio
Protocolos de acesso ao mail: obter mail do servidor de recepção
m POP: Post Office Protocol [RFC 1939]
• Autorização (agente <-->servidor) e download
m IMAP: Internet Mail Access Protocol [RFC 1730]
• Mais funcionalidades (mais complexo)
• Manipulação das mensagens armazenadas nos servidores
m HTTP: Hotmail , Yahoo! Mail, etc.
2: Nível de Aplicação
46
protocolo POP3
Fase de autorização
r
r
Comandos do cliente:
m user: declara username
m pass: password
Servidor responde
m +OK
m -ERR
Fase de transacção, cliente:
r
r
r
r
list: lista nº das mensagens
retr: obtém mensagens
através no nº
dele: apaga
quit:termina
C:
S:
C:
S:
C:
S:
telnet hamburger.edu 110
+OK POP3 server ready
user bob
+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
2: Nível de Aplicação
47
protocolo IMAP
Objectivo:
r
Utilizadores podem manipular mailboxes remotamente, como se
fossem locais
m
r
Organizar folders: criar, apagar, inserir, remover
ou mover mensagens
Utilizador pode obter apenas componentes específicos do mail
m
Só cabeçalho, só uma parte duma mensagem multipart
Quatro fases, :
r
Estado não autenticado: estado inicial, quando a ligação se
inicia:
m
r
Estado autenticado:
m
r
Utilizador selecciona o folder
Estado seleccionado
m
r
Utilizador envia user name e password
Utilizador envia comandos que afectam as mensagens
Estado Logout:termina
2: Nível de Aplicação
48
DNS: Domain Name System
Pessoas: muitos
identificadores:
m
m
r
Base de dados distribuida
r
Protocolo de nível de aplicação
SSN, name, passport #
Internet hosts, routers:
m
Domain Name System:
IP address (32 bit) –
utilizado para endereçar
datagramas
“nome”, e.g.,
gaia.cs.umass.edu – usado
pelos humanos
Q: mapeamento entre
endereços IP e nomes ?
implementada numa hierarquia
de muitos name servers
sistemas terminais, routers,
servidores de nomes
comunicam para resolver
nomes (tradução
endereço/nome)
m
m
nota: função do núcleo da
Internet, implementada
como protocolo de nível de
aplicação
Complexidade nas
fronteiras da rede
2: Nível de Aplicação
49
DNS name servers r
Porque não centralizar o
DNS?
r Um só ponto de falha
r Volume de tráfego
r base de dados
centralizada distante
r Manutenção
Nenhum servidor tem todos os
mapeamentos de endereços IP
Servidores de nomes locais:
(Local Name Server)
m
Cada ISP, instituição têm um
servidor de nomes local
(default)
m
Sistemas Terminais
interrogam primeiro o
Servidor de Nomes Local
Servidor de nomes autoritativo
(authoritative name server):
m
Não é escalável !
m
Todos os Sistemas Terminais
têm o seu nome, endereço IP
armazenado num Servidor de
Nome Autoritativo
Pode executar a tradução
nome/endereço do nome do
Sistema Terminal
2: Nível de Aplicação
50
DNS: Servidores de nome de raíz
(Root Name Server)
r
r
Contactados pelo servidor de nomes local, quando este não resolve o end.
root name server:
m contactam os servidores de nomes autoritativos quando não sabem
resolver o endereço
m Obtém mapeamento
m Retornam 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
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
13 root name
servers no mundo
2: Nível de Aplicação
51
Exemplo simples de DNSroot name server
Sistema terminal:
surf.eurecom.fr pretende
endereço IP de
gaia.cs.umass.edu
2
4
5
1. Contacto o seu DNS server
local, dns.eurecom.fr
local name server
2. dns.eurecom.fr contacta
dns.eurecom.fr
root name server, se
1
6
necessário
3. root name server contacta
authoritative name server,
dns.umass.edu, se
requesting host
necessário
surf.eurecom.fr
3
authorititive name server
dns.umass.edu
gaia.cs.umass.edu
2: Nível de Aplicação
52
Exemplo de DNS
root name server
Root name server:
r
r
Pode não conhecer o
Servidor Autoritativo
Pode conhecer
servidores de nomes
intermédios: quem
contactar para saber
o servidor de nomes
autoritativo
6
2
7
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Nível de Aplicação
53
DNS: perguntas
iterativas
root name server
Perguntas
recursivas:
r
r
Coloca o peso da
resolução de nomes no
servidor contactado
Carga elevada ?
Perguntas iterativas:
r
r
O servidor
contactado responde
com o nome do
servidor a contactar
“Não conheço este
nome, mas pergunta a
este Servidor !!“
iterated query
2
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Nível de Aplicação
54
DNS: caching e records de actualização
Cada vez que um servidor de nomes aprende os
mapeamentos, armazena-os na cache
m Entradas na cache desaparecem ao fim dum
certo tempo, porque o temporizador termina a
contagem do tempo.
r Mecanismos de update/notify em estudo no
IETF
r
m
RFC 2136
m
http://www.ietf.org/html.charters/dnsind-charter.html
2: Nível de Aplicação
55
DNS records
DNS: Records de recursos (RR) armazanedos numa Base de
Dados distribuída
RR formato:
Tipo=A
r
m
m
r
(name, value, type,ttl)
r
Nome do Sistema
Terminal
Valor é um endereço IP
Tipo=NS
m
m
Nome é o domínio (e.g.
foo.com)
r
Valor é o endereço OP
do authoritative name
server desse domínio
Tipo=CNAME
m
Nome é uma alias para o
nome “canónico” (the real)
www.ibm.com é realmente
servereast.backup2.ibm.com
m
Valor é o nome canónico
Type=MX
m
Valor é o nome do
servidor de mail
associado com o nome
2: Nível de Aplicação
56
protocolo DNS, messagens
Protocolo DNS : messagens de query e reply, ambas com o
mesmo formato de mensagem
cabeçalho de msg
r
identificação:
m
m
r
16 bit # para query,
reply à query usa o
mesmo #
flags:
m query iou reply
m recursion desejada
m recursion disponível
m reply é autoritativa
2: Nível de Aplicação
57
protocolo DNS, messagens
Nome, tipo de campo
para uma query
RRs na resposta
à query
records para
authoritative servers
Informação adicional
que pode ser útil
2: Nível de Aplicação
58
Parte 2: Sumário
O estudo das aplicações está completo !
r
Requisitos do serviço de
aplicação:
m
r
r
fiabilidade, largura de
banda, atraso
paradigma cliente-server
Modelo de saída do
transporte na Internet
m
r
Protocolos específicos:
m
m
m
m
http
ftp
smtp, pop3
dns
Serviço orientada à
ligação,
• Fiabilidade: TCP
m
Não fiável, datagramss:
• UDP
2: Nível de Aplicação
59
Parte 2: Sumário
Muito importante: aprender protocolos
r
Tipicamente transferência
de mensagens
request/reply:
m
m
r
Cliente pede informação ou
serviço
Servidor responde com
dados, código de estado
Formato das messagens:
m
m
Cabeçalho (header):
campos que fornecem
informação sobre os dados
dados: informação a ser
comunicada
r
r
r
r
r
r
r
controlo vs. mensagens de
dados
m in-band, 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
“complexidade no limite da
rede”
segurança: autenticação
2: Nível de Aplicação
60