2: nível de aplicação1 silÊncio !!!!. 2: nível de aplicação2 parte 2: nível de aplicação...
TRANSCRIPT
2: Nível de Aplicação 1
SILÊNCIO !!!!
2: Nível de Aplicação 2
Parte 2: Nível de AplicaçãoObjectivos conceitos, aspectos de
implementação dos protocolos de nível de aplicação Paradigma cliente-
servidor Modelos de serviço
Aprender os protocolos, examinando protocolos de nível de aplicação populares
Outros objectivos do capítulo:
Protocolos específicos: http ftp smtp pop dns
Programação de aplicações de rede API de socket
2: Nível de Aplicação 3
Aplicações e protocolos de nível de aplicação
Aplicação: comunicação, processo distribuído Executadas nos Sistemas
Terminais da rede em espaço de utilizador (user-user-spacespace)
Troca de mensagens para implementar a aplicação
Ex: email, ftp, WebProtocolos de nível de
aplicação 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çãoTransporte
RedeLig. Lógica
Físico
AplicaçãoTransporte
RedeLig. Lógica
Físico
AplicaçãoTransporte
RedeLig. Lógica
Físico
2: Nível de Aplicação 4
Aplicações de rede: terminologia
Processo: Programa executado num nó.
Dentro do mesmo nó, dois processos em comunicação utilizam comunicação entre processos (definida pelo sistema operativo)
Processos executados em nós diferentes comunicam através do protocolo de nível de transporte
Agente de utilizador (user agent): processo de SW que faz a interface entre o utilizador “acima” e a rede “abaixo” Implementa o protocolo
de nível de aplicação Ex:
• Web: browser• E-mail: mail reader• streaming audio/video:
media player
2: Nível de Aplicação 5
O paradigma Cliente-ServidorAplicações de rede típicas têm duas partes: Cliente e o Servidor Aplicação
TransporteRede
Lig. LógicaFísico
AplicaçãoTransporte
RedeLig. Lógica
Físico
Cliente: 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 mail-
reader
request
reply
Servidor: 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 6
Protocolos de nível de aplicação (cont).
API: Interface de programação de aplicação
Define a interface entre as aplicações e o nível de transporte
socket: Internet API Dois processos
comunicam enviando dados para um socket e lendo os dados do socket.
Q: Como é que o processo identifica o outro processo com que quer comunicar ? Endereço IP do
Sistema Terminal que executa o outro processo
“Número do porto” – 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 7
Que serviços de transporte é que uma aplicação necessita ?Perda de dados Algumas aplicações toleram
algumas falhas ex: audio
Outras aplicações requerem 100% de fiabilidade na transferência de dados ex: transferência de ficheiros telnet
Timing Algumas aplicações
requerem um atraso pequeno para funcionarem adequadamente ex: Telefonia na Internet Jogos interactivos)
Largura de Banda Algumas aplicações
requerem um atraso pequeno para funcionarem adequadamente ex: aplicações multimédia
Outras aplicações utilizam a largura de banda que conseguirem obter ex: aplicações elásticas)
2: Nível de Aplicação 8
Requisitos do serviço de transporte das aplicações comuns
Aplicação
Transferência de ficheirose-mail
Documentos Webaudio/video de tempo real
audio/video armazenadoJogos interactivos
Aplicações financeiras
Perda de dados
NãoNãoToleranteTolerante
ToleranteToleranteNão
Largura de banda
elásticaelásticaelásticaaudio: 5Kb-1Mbvideo:10Kb-5MbIgual ao anterior Poucos Kb/selástica
Sensibilidade ao atraso
NãoNãoNãoSim, 100’s mseg
Sim,alguns seg.Sim, 100’s mseg Sim e Não
2: Nível de Aplicação 9
Serviços do protocolo de transporte da Internet
Serviço TCP: 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.
Serviço UDP: 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 10
Aplic. internet: aplicações e protocolos de transporte
Aplicação
e-mailAcesso remoto a Terminais
Web Transferência de ficheiros
streaming multimedia
Servidor de ficheiros remotoTelefonia Internet
Protocolo de nívelde Aplicação
smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietário(ex: RealNetworks)NSFproprietário(ex: Vocaltec)
Protocolo deTransporte
TCPTCPTCPTCPTCP or UDP
TCP or UDPTipicamente UDP
2: Nível de Aplicação 11
SILÊNCIO !!!!
2: Nível de Aplicação 12
A Web: O protocolo HTTP
http: hypertext transfer protocol
Protocolo de nível de aplicação da Web
Modelo cliente-servidor Cliente: browser que
pede, recebe e mostra objectos Web
Servidor: Servidor Web envia objectos em resposta a pedidos
http1.0: RFC 1945 http1.1: RFC 2068
PC a executar Internet Explorer
Servidor a executarNCSA Web
server
Mac a executarNetscape Navigator
http request
http re
quest
http response
http re
sponse
2: Nível de Aplicação 13
O protocolo HTTP: mais
http: Serviço de transporte TCP:
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”
O Servidor não mantém informação sobre os pedidos anteriores dos Clientes
Protocolos que mantêm o estado são complexos !
História passada (estado) tem de ser mantida
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 14
Exemplo: httpSupondo que um utilizador introduz o URL www.someSchool.edu/someDepartment/home.index
1a. Cliente http inicia a ligação TCP (processo) ao Servidor http em:
www.someSchool.edu. Porto 80 é utilizado por
omissão para o acesso ao Servidor http.
2. Cliente http envia uma mensagem para o socket da ligação TCP
request message (contendo o URL)
1b. Servidor http no Sistema Terminal www.someSchool.edu
espera a ligação TCP no porto 80, aceita pedidos de estabelecimento de
ligação notifica os Clientes.
3. Servidor http recebe mensagens de pedido constrói a response message
contendo os objectos pedidos (someDepartment/home.index)
envia a mensagem no socket.
tempo
(contem texto, Referência a 10
imagens do tipo jpeg)
2: Nível de Aplicação 15
5. Cliente http recebe mensagens de resposta
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
4. Servidor http pede o fecho da ligação TCP A ligação só é fechada quando o cliente
recebe a resposta
tempo
Exemplo: http (cont)
Ligação não persistente
2: Nível de Aplicação 16
Ligações não persistentes e ligações persistentes
Não persistentes http/1.0: Servidor
interpreta o pedido, responde e fecha a ligação TCP
2 RTTs para obter o objecto
Ligação TCP
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
Persistentes 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 17
Formato das mensagens http: request
Dois tipos de mensagens http: request, response
http request message: ASCII (Formato legível pelos Humanos)
GET /somedir/page.html HTTP/1.0 Host: www.someschool.eduConnection: closeUser-agent: Mozilla/4.0 Accept-language:fr
(extra carriage return, line feed)
request line(GET, POST,
HEAD commands)
Linhas deCabeçalho
Carriage return, line feed
Indicam o fim da mensagem
2: Nível de Aplicação 18
Formato das mensagens http: request
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language:fr
Método url Versão http
Sistema Terminal em que
os objectos residem
Não utilizar ligações
persistentes
O cliente prefere obter a versão francesa do objecto
Tipo de browser
2: Nível de Aplicação 19
http request message: formato geral
2: Nível de Aplicação 20
Formato da mensagem http: response
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 ...
Linha de estado(protocolo
Código de estadoDescrição do estado)
Linhas decabeçalho
dados, i.e., Ficheiro
html pedido
2: Nível de Aplicação 21
Formato da mensagem http: response
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 ...
Tempo em que as resposta foi criada no
servidor
Servidor que gerou a
resposta
Tempo em que o objecto foi criado, ou
modificado
Nº de Bytes do objecto que está a ser enviado
Tipo de objecto
2: Nível de Aplicação 22
Códigos de resposta http
200 OK Pedido com sucesso, objecto pedido “mais tarde” na
mensagem
301 Moved Permanently Objecto pedido foi movido, nova localização
específicada mais tarde na mensagem (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
Na primeira linha da mensagem de resposta Servidor->ClienteAlguns exemplos de códigos:
2: Nível de Aplicação 23
Executando o protocolo http (do lado do cliente)….
1. Fazer telnet para o WEB site favorito:
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
telnet www.eurecom.fr 80
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 24
User-server interaction: authentication
Authentication : control access to server content
authorization credentials: typically name, password
stateless: client must present authorization in each request authorization: header line in
each request if no authorization: header,
server refuses access, sendsWWW authenticate:
header line in response
client server
usual http request msg401: authorization req.
WWW authenticate:
usual http request msg
+ Authorization: <cred>usual http response
msg
usual http request msg
+ Authorization: <cred>usual http response
msg
time
2: Nível de Aplicação 25
SILÊNCIO !!!!
2: Nível de Aplicação 26
Cookies: mantendo o “estado”
Servidor gera um nº , servidor recorda o nº para usar mais tarde: autenticação Recordar as
preferências do utilizador, escolhas anteriores
Servidor envia a “cookie” na mensagem de resposta do clienteSet-cookie: 1678453
Cliente adiciona a “cookie” aos pedidos seguintes:cookie: 1678453
cliente servidor
http request msg usual
http response usual +
Set-cookie: #http request msg
usualcookie: #
http response msg usual
http request msg usual
cookie: #http response msg
usual
Acção específica da cookie
Acção específica da cookie
2: Nível de Aplicação 27
GET condicional: cache no lado do cliente
Objectivo: não enviar os objectos se o cliente tiver uma versão actualizada em cache
cliente: específica a data da cópia que tem em cahce no http requestIf-modified-since: <date>
servidor: a resposta não contém objectos se a cópia de cache do cliente estiver actualizada: HTTP/1.0 304 Not Modified
cliente servidor
http request msgIf-modified-since:
<date>
http responseHTTP/1.0
304 Not Modified
Objecto nãomodificado
http request msgIf-modified-since:
<date>
http responseHTTP/1.1 200 OK
<data>
Objectomodificado
2: Nível de Aplicação 28
Caches Web (proxy server)
Uitilizador activa o browser: acessos Web através da cache
Cliente envia todos os http requests para a cache 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
Objectivo: satisfazer os pedidos dos clientes sem envolver o servidor original
client
Proxyserver
client
http request
http re
quest
http response
http re
sponse
http request
http response
origin server
origin server
2: Nível de Aplicação 29
Porquê Web Caching?
Considerando que: a cache está mais próximo do cliente (i.e. na mesma rede)
Tempo de resposta menor: cache “mais perto” do cliente
Diminui o tráfego para servidores distantes Ligação de saída da
instituição/rede do ISP é o ponto de estrangulamento (bottleneck)
Servidoresde origem
Internet pública
Redeinstitucional LAN a 10 Mbp
Ligação de acesso1.5 Mbps
Cache institucional
2: Nível de Aplicação 30
ftp: o protocolo de transferência de ficheiros (file transfer protocol)
Transferência de ficheiros de/para o Sistema Terminal Modelo Cliente-Servidor
Cliente: Inicia a transferência (de/para o Sistema remoto)
Servidor: Sistema Remoto ftp: RFC 959 ftp server: port 21
file transfer ServidorFTP
Interfaceutilizador
FTP
ClienteFTP
Sistema ficheiros local
Sistema ficheiros remoto
Utilizador num Sistema Terminal
2: Nível de Aplicação 31
ftp: Controlo separado, ligações de dados
Cliente ftp contacta o servidor no porto 21, especificando o TCP como protocolo de transporte
São abertas duas ligações TCP em paralelo: controlo: transferência de
comandos, respostas entre cliente e servidor.
Controlo (ou sinalização) “out of band”
Dados: ficheiro de dados de/para o servidor
Servidor ftp mantém o estado: directório actual, autenticação anterior
ClienteFTP
ServidorFTP
Ligação de controlo TCP
porto 21
Ligação de dados TCPporto 20
2: Nível de Aplicação 32
Comandos ftp, respostas
Exemplos de comandos:
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
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 33
Correio electrónico E-Mail
Três componentes fundamentais:
Agentes utilizador Servidores de mail Protocolo de comunicação
entre servidores: simple mail transfer
protocol: smtpAgente Utilizador a.k.a. “mail reader” Compor, editar e ler
mensagne de mail e.g., Eudora, Outlook, elm,
Netscape Messenger Enviar, receber mensagens
armazenadas no servidor
user mailbox
outgoing message queue
mailserver
useragent
useragent
useragent
mailserver
useragent
mailserver
useragent
useragent
SMTP
SMTP
SMTP
2: Nível de Aplicação 34
Correio electrónico: servidores de emailServidores de Mail 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 cliente: envia email
para o servidor “server”: servidor de
recepção de email
mailserver
useragent
useragent
useragent
mailserver
useragent
useragent
mailserver
useragent
SMTP
SMTP
SMTP
2: Nível de Aplicação 35
Correio electrónico : smtp [RFC 821] 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 handshaking (greeting) Transferência de mensagens fecho
Interacção comando-resposta commandos: texto ASCII resposta: código e descrição de estado
Mensagens codificadas em 7 bits ASCII
2: Nível de Aplicação 36
Experimentem o smtp por vocês mesmos
Digitar telnet servername 25 observar 220 reply from server digitar comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT Os procedimentos anteriores permitem enviar
emails sem usar um cliente de email (reader)
2: Nível de Aplicação 37
Exemplo de interacção com smtp
Crepes.fr Hamburger.edu
Do you like ketchup ?
What about pickles ?
2: Nível de Aplicação 38
Exemplo de interacção com smtp
C: telnet hamburger.edu 2-> Estabelecimento da lig. TCPS: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
2: Nível de Aplicação 39
smtp: palavras finais
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: 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 40
Formato da mensagem de Mail
smtp: protocolo para transferir mensagens de mail
RFC 822: formato standard para mensagens de texto:
Linhas de cabeçalho, e.g., To: From: Subject:diferente dos comandos smtp
Corpo Apenas os caracteres ASCII
da mensagem
header
body
Linha em
branco
2: Nível de Aplicação 41
Formato das mensagens: extensões multimédia
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
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
Tipo de dados multimédia,sub-tipo,
declaração de parâmetros
Método usado paracodificar os dados
Versão MIME
Dados codificados
2: Nível de Aplicação 42
Tipos MIME Content-Type: type/subtype; parameters
Texto Exemplo de sub-tipos:
plain, html
Imagem Exemplo de sub-tipos:
jpeg, gif
Audio Exemplo de sub-tipos :
basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)
Video Exemplo de sub-tipos :
mpeg, quicktime
Aplicação 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 43
Tipo Multipart
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data --98766789--
Para incluir no email múltiplos objectos
Início da próxima
parte
2: Nível de Aplicação 44
Tipo Multipart - recepçãoReceived: from crepes.fr by hamburger.edu; 12 Oct 98From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data --98766789--
2: Nível de Aplicação 45
Tipo Multipart - forwardingReceived: from hamburger.edu by sushi.jp; 12 Oct 98 15:30:01 GMTReceived: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMTFrom: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data --98766789--
2: Nível de Aplicação 46
Protocolos de acesso ao Mail
SMTP: entrega/armazena mail no servidor de envio Protocolos de acesso ao mail: obter mail do servidor de recepção
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.
useragent
Servidor de envio de mail
useragent
SMTP SMTP POP3 orIMAP
Servidor de recepçãode mail
2: Nível de Aplicação 47
protocolo POP3
Fase de autorização Comandos do cliente:
user: declara username pass: password
Servidor responde +OK -ERR
Fase de transacção, cliente: list: lista nº das mensagens retr: obtém mensagens
através no nº dele: apaga quit:termina
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off
C: telnet hamburger.edu 110S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on
2: Nível de Aplicação 48
protocolo IMAPObjectivo: Utilizadores podem manipular mailboxes remotamente, como
se fossem locais Organizar folders: criar, apagar, inserir, remover ou
mover mensagens Utilizador pode obter apenas componentes específicos do mail
Só cabeçalho, só uma parte duma mensagem multipart
Quatro fases, : Estado não autenticado: estado inicial, quando a ligação se
inicia: Utilizador envia user name e password
Estado autenticado: Utilizador selecciona o folder
Estado seleccionado Utilizador envia comandos que afectam as mensagens
Estado Logout:termina
2: Nível de Aplicação 49
DNS: Domain Name System
Pessoas: muitos identificadores: SSN, name, passport #
Internet hosts, routers: 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 ?
Domain Name System: Base de dados distribuida
implementada numa hierarquia de muitos name servers
Protocolo de nível de aplicação sistemas terminais, routers, servidores de nomes comunicam para resolver nomes (tradução endereço/nome)
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 50
DNS name servers Nenhum servidor tem todos os mapeamentos de endereços IP
Servidores de nomes locais: (Local Name Server) Cada ISP, instituição têm um
servidor de nomes local (default)
Sistemas Terminais interrogam primeiro o Servidor de Nomes Local
Servidor de nomes autoritativo (authoritative name server): 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
Porque não centralizar o DNS?
Um só ponto de falha Volume de tráfego base de dados
centralizada distante Manutenção
Não é escalável !
2: Nível de Aplicação 51
DNS: Servidores de nome de raíz (Root Name Server)
Contactados pelo servidor de nomes local, quando este não resolve o end.
root name server: contactam os servidores de nomes autoritativos quando não
sabem resolver o endereço Obtém mapeamento Retornam o mapeamento ao servidor de nomes local
b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA
13 root name servers no mundo
2: Nível de Aplicação 52
Exemplo simples de DNS
Sistema terminal: surf.eurecom.fr pretende endereço IP de gaia.cs.umass.edu
1. Contacto o seu DNS server local, dns.eurecom.fr
2. dns.eurecom.fr contacta root name server, se necessário
3. root name server contacta authoritative name server, dns.umass.edu, se necessário
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
authorititive name serverdns.umass.edu
local name serverdns.eurecom.fr
1
23
4
5
6
2: Nível de Aplicação 53
Exemplo de DNS
Root name server: Pode não conhecer o
Servidor Autoritativo Pode conhecer
servidores de nomes intermédios: quem contactar para saber o servidor de nomes autoritativo
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4 5
6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
2: Nível de Aplicação 54
DNS: perguntas iterativasPerguntas
recursivas: Coloca o peso da
resolução de nomes no servidor contactado
Carga elevada ?
Perguntas iterativas:
O servidor contactado responde com o nome do servidor a contactar
“Não conheço este nome, mas pergunta a este Servidor !!“
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4
5 6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
iterated query
2: Nível de Aplicação 55
DNS: caching e records de actualização
Cada vez que um servidor de nomes aprende os mapeamentos, armazena-os na cache Entradas na cache desaparecem ao fim
dum certo tempo, porque o temporizador termina a contagem do tempo.
Mecanismos de update/notify em estudo no IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html
2: Nível de Aplicação 56
DNS recordsDNS: Records de recursos (RR) armazanedos numa Base de Dados
distribuída
Tipo=NS Nome é o domínio (e.g.
foo.com) Valor é o endereço OP
do authoritative name server desse domínio
RR formato: (name, value, type,ttl)
Tipo=A Nome do Sistema Terminal Valor é um endereço IP
Tipo=CNAME Nome é uma alias para o nome “canónico” (the real)
www.ibm.com é realmente servereast.backup2.ibm.com Valor é o nome canónico
Type=MX Valor é o nome do servidor de mail associado com o nome
2: Nível de Aplicação 57
protocolo DNS, messagensProtocolo DNS : messagens de query e reply, ambas com o mesmo
formato de mensagem
cabeçalho de msg identificação:
16 bit # para query, reply à query usa o
mesmo # flags:
query iou reply recursion desejada recursion disponível reply é autoritativa
2: Nível de Aplicação 58
Nome, tipo de campo para uma query
RRs na respostaà query
records paraauthoritative servers
Informação adicional que pode ser útil
protocolo DNS, messagens
2: Nível de Aplicação 59
Parte 2: Sumário
Requisitos do serviço de aplicação: fiabilidade, largura de
banda, atraso paradigma cliente-server Modelo de saída do
transporte na Internet Serviço orientada à
ligação, • Fiabilidade: TCP
Não fiável, datagramss: • UDP
O estudo das aplicações está completo !
Protocolos específicos: http ftp smtp, pop3 dns
2: Nível de Aplicação 60
Parte 2: Sumário
Tipicamente transferência de mensagens request/reply: Cliente pede informação
ou serviço Servidor responde com
dados, código de estado Formato das messagens:
Cabeçalho (header): campos que fornecem informação sobre os dados
dados: informação a ser comunicada
Muito importante: aprender protocolos
controlo vs. mensagens de dados 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