SILÊNCIO !!!! 2: Nível de Aplicação.

Apresentação em tema: "SILÊNCIO !!!! 2: Nível de Aplicação."— Transcrição da apresentação:

1 SILÊNCIO !!!! 2: Nível de Aplicação

2 Parte 2: Nível de Aplicação
Objectivos 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-space) Troca de mensagens para implementar a aplicação Ex: , ftp, Web Protocolos 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ção Transporte Rede Lig. 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 mail reader streaming audio/video: media player 2: Nível de Aplicação

5 O paradigma Cliente-Servidor
Aplicações de rede típicas têm duas partes: Cliente e o Servidor Aplicação Transporte Rede Lig. Lógica Físico reply request Cliente: Inicia o contacto com o Servidor (“Fala primeiro”) Tipicamente, requisita serviços ao Servidor Ex: Web: Cliente implementado num browser; Cliente implementado num mail-reader Servidor: Fornece os serviços requisitados pelos Clientes Ex: Servidor Web envia páginas pedidas; Servidor de mail entrega s. 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 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) Timing Algumas aplicações requerem um atraso pequeno para funcionarem adequadamente ex: Telefonia na Internet Jogos interactivos) 2: Nível de Aplicação

8 Requisitos do serviço de transporte das aplicações comuns
Perda de dados Não Tolerante Largura de banda elástica audio: 5Kb-1Mb video:10Kb-5Mb Igual ao anterior Poucos Kb/s Sensibilidade ao atraso Não Sim, 100’s mseg Sim,alguns seg. Sim, 100’s mseg Sim e Não Aplicação Transferência de ficheiros Documentos Web audio/video de tempo real audio/video armazenado Jogos interactivos Aplicações financeiras 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
Protocolo de nível de Aplicação smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietário (ex: RealNetworks) NSF (ex: Vocaltec) Protocolo de Transporte TCP TCP or UDP Tipicamente UDP Aplicação Acesso remoto a Terminais Web Transferência de ficheiros streaming multimedia Servidor de ficheiros remoto Telefonia Internet 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 http request PC a executar Internet Explorer http response http request http response Servidor a executar NCSA Web server Mac a executar Netscape Navigator 2: Nível de Aplicação

13 O protocolo HTTP: mais http não tem estado “stateless”
O Servidor não mantém informação sobre os pedidos anteriores dos Clientes 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 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: http Supondo que um utilizador introduz o URL (contem texto, Referência a 10 imagens do tipo jpeg) 1a. Cliente http inicia a ligação TCP (processo) ao Servidor http em: Porto 80 é utilizado por omissão para o acesso ao Servidor http. 1b. Servidor http no Sistema Terminal espera a ligação TCP no porto 80, aceita pedidos de estabelecimento de ligação notifica os Clientes. 2. Cliente http envia uma mensagem para o socket da ligação TCP request message (contendo o URL) 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 2: Nível de Aplicação

15 Exemplo: http (cont) tempo Ligação não persistente
4. Servidor http pede o fecho da ligação TCP A ligação só é fechada quando o cliente recebe a resposta 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 tempo 6. Repete os passos 1 a 5 para cada um dos 10 objectos jpeg Ligação não persistente 2: Nível de Aplicação

16 Ligações não persistentes e ligações 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) request line (GET, POST, HEAD commands) GET /somedir/page.html HTTP/1.0 Host: Connection: close User-agent: Mozilla/4.0 Accept-language:fr (extra carriage return, line feed) Linhas de Cabeçalho Carriage return, line feed Indicam o fim da mensagem 2: Nível de Aplicação

18 Formato das mensagens http: request
Método url Versão http Sistema Terminal em que os objectos residem GET /somedir/page.html HTTP/1.0 Host: Connection: close User-agent: Mozilla/4.0 Accept-language:fr Tipo de browser Não utilizar ligações persistentes O cliente prefere obter a versão francesa do objecto 2: Nível de Aplicação

19 http request message: formato geral
2: Nível de Aplicação

20 Formato da mensagem http: response
Linha de estado (protocolo Código de estado Descrição do estado) HTTP/ OK Date: Thu, 06 Aug :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 ... Linhas de cabeçalho dados, i.e., Ficheiro html pedido 2: Nível de Aplicação

21 Formato da mensagem http: response
Tempo em que as resposta foi criada no servidor HTTP/ OK Date: Thu, 06 Aug :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 ... Servidor que gerou a resposta Tempo em que o objecto foi criado, ou modificado Tipo de objecto Nº de Bytes do objecto que está a ser enviado 2: Nível de Aplicação

22 Códigos de resposta http
Na primeira linha da mensagem de resposta Servidor->Cliente Alguns exemplos de códigos: 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 2: Nível de Aplicação

23 Executando o protocolo http (do lado do cliente)….
1. Fazer telnet para o WEB site favorito: telnet 80 Abre a ligação TCP para o porto 80 (Porto por omissão do servidor http) e, O que for digitado é enviado para este porto em 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, sends WWW authenticate: header line in response client server usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization: <cred> usual http response msg usual http request msg + Authorization: <cred> time usual http response msg 2: Nível de Aplicação

25 SILÊNCIO !!!! 2: Nível de Aplicação

26 Cookies: mantendo o “estado”
cliente servidor 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 cliente Set-cookie: Cliente adiciona a “cookie” aos pedidos seguintes: cookie: http request msg usual http response usual + Set-cookie: # http request msg usual cookie: # Acção específica da cookie http response msg usual http request msg usual cookie: # Acção específica da cookie http response msg usual 2: Nível de Aplicação

27 GET condicional: cache no lado do cliente
servidor 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 request If-modified-since: <date> servidor: a resposta não contém objectos se a cópia de cache do cliente estiver actualizada: HTTP/ Not Modified http request msg If-modified-since: <date> Objecto não modificado http response HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> Objecto modificado http response HTTP/ OK <data> 2: Nível de Aplicação

28 Caches Web (proxy server)
Objectivo: satisfazer os pedidos dos clientes sem envolver o servidor original origin 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 Proxy server http request http request client http response http response http request http response client origin server 2: Nível de Aplicação

29 Porquê Web Caching? Servidores de origem 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) Internet pública Ligação de acesso 1.5 Mbps Rede institucional LAN a 10 Mbp Cache institucional 2: Nível de Aplicação

30 ftp: o protocolo de transferência de ficheiros (file transfer protocol)
Servidor FTP InterfaceutilizadorFTP Cliente Sistema ficheiros local Sistema ficheiros remoto Utilizador num Sistema Terminal 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 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 Cliente FTP Servidor Ligação de controlo TCP porto 21 Ligação de dados TCP porto 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
user mailbox outgoing message queue mail server user agent Três componentes fundamentais: Agentes utilizador Servidores de mail Protocolo de comunicação entre servidores: simple mail transfer protocol: smtp Agente 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 SMTP 2: Nível de Aplicação

34 Correio electrónico: servidores de email
server user agent SMTP Servidores 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 para enviar as mensagens cliente: envia para o servidor “server”: servidor de recepção de 2: Nível de Aplicação

35 Correio electrónico : smtp [RFC 821]
Utiliza TCP para transferir mensagens de 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 s sem usar um cliente de (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. TCP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 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 Comparação com http:
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 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 Linha em branco body 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: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data Versão MIME Método usado para codificar os dados Tipo de dados multimédia, sub-tipo, declaração de parâmetros 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 Para incluir no email múltiplos objectos
Tipo Multipart Para incluir no múltiplos objectos From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data Início da próxima parte 2: Nível de Aplicação

44 Tipo Multipart - recepção
Received: from crepes.fr by hamburger.edu; 12 Oct 98 From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data 2: Nível de Aplicação

45 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: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data 2: Nível de Aplicação

46 Protocolos de acesso ao Mail
SMTP SMTP POP3 or IMAP user agent user agent Servidor de envio de mail Servidor de recepção de 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. 2: Nível de Aplicação

47 protocolo POP3 Fase de autorização C: list
C: telnet hamburger.edu 110 S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on 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> C: dele 1 C: retr 2 C: dele 2 C: quit S: +OK POP3 server signing off 2: Nível de Aplicação

48 protocolo IMAP Objectivo: Quatro fases, :
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
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 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 ? 2: Nível de Aplicação

50 DNS name servers Porque não centralizar o DNS? Um só ponto de falha
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, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo 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 13 root name servers no mundo 2: Nível de Aplicação

52 authorititive name server
Exemplo simples de DNS root name server 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 2 4 3 5 local name server dns.eurecom.fr authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu 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 2 6 7 3 local name server dns.eurecom.fr intermediate name server dns.umass.edu 4 5 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 2: Nível de Aplicação

54 DNS: perguntas iterativas
root name server Perguntas 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 !!“ iterated query 2 3 4 7 local name server dns.eurecom.fr intermediate name server dns.umass.edu 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 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 2: Nível de Aplicação

56 RR formato: (name, value, type,ttl)
DNS records DNS: Records de recursos (RR) armazanedos numa Base de Dados distribuída 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) é realmente servereast.backup2.ibm.com Valor é o nome canónico Tipo=NS Nome é o domínio (e.g. foo.com) Valor é o endereço OP do authoritative name server desse domínio Type=MX Valor é o nome do servidor de mail associado com o nome 2: Nível de Aplicação

57 protocolo DNS, messagens
Protocolo 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 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

59 Parte 2: Sumário O estudo das aplicações está completo !
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 Protocolos específicos: http ftp smtp, pop3 dns 2: Nível de Aplicação

60 Parte 2: Sumário Muito importante: aprender protocolos
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 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 2: Nível de Aplicação