A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

2: Nível de Aplicação1 SILÊNCIO !!!!. 2: Nível de Aplicação2 Parte 2: Nível de Aplicação Objectivos r conceitos, aspectos de implementação dos protocolos.

Apresentações semelhantes


Apresentação em tema: "2: Nível de Aplicação1 SILÊNCIO !!!!. 2: Nível de Aplicação2 Parte 2: Nível de Aplicação Objectivos r conceitos, aspectos de implementação dos protocolos."— Transcrição da apresentação:

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

2 2: Nível de Aplicação2 Parte 2: Nível de Aplicação Objectivos r conceitos, aspectos de implementação dos protocolos de nível de aplicação m Paradigma cliente- servidor 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 http m ftp m smtp m pop m dns r Programação de aplicações de rede m API de socket

3 2: Nível de Aplicação3 Aplicações e protocolos de nível de aplicação Aplicação: comunicação, processo distribuído user-space m Executadas nos Sistemas Terminais da rede em espaço de utilizador (user-space) m Troca de mensagens para implementar a aplicação m Ex: , ftp, Web Protocolos de nível de aplicação m Uma parte da aplicação m Define as mensagens transferidas entre as aplicações e as acções a executar m 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 Aplicação Transporte Rede Lig. Lógica Físico

4 2: Nível de Aplicação4 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 mail reader streaming audio/video: media player

5 2: Nível de Aplicação5 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 Aplicação Transporte Rede Lig. Lógica Físico Cliente: r Inicia o contacto com o Servidor (Fala primeiro) r Tipicamente, requisita serviços ao Servidor r Ex: Web: Cliente implementado num browser; r Cliente implementado num mail- reader request reply Servidor: r Fornece os serviços requisitados pelos Clientes r Ex: Servidor Web envia páginas pedidas; Servidor de mail entrega s.

6 2: Nível de Aplicação6 Protocolos de nível de aplicação (cont). API: Interface de programação de aplicação r Define a interface entre as aplicações e o nível de transporte r socket: Internet API m 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 ? m Endereço IP do Sistema Terminal que executa o outro processo mNú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.

7 2: Nível de Aplicação7 Que serviços de transporte é que uma aplicação necessita ? Perda de dados r Algumas aplicações toleram algumas falhas m ex: audio r Outras aplicações requerem 100% de fiabilidade na transferência de dados m ex: transferência de ficheiros m telnet Timing r Algumas aplicações requerem um atraso pequeno para funcionarem adequadamente m ex: Telefonia na Internet m Jogos interactivos) Largura de Banda r Algumas aplicações requerem um atraso pequeno para funcionarem adequadamente m ex: aplicações multimédia r Outras aplicações utilizam a largura de banda que conseguirem obter m ex: aplicações elásticas)

8 2: Nível de Aplicação8 Requisitos do serviço de transporte das aplicações comuns Aplicação Transferência de ficheiros Documentos Web audio/video de tempo real audio/video armazenado Jogos interactivos Aplicações financeiras Perda de dados Não Tolerante Não Largura de banda elástica audio: 5Kb-1Mb video:10Kb-5Mb Igual ao anterior Poucos Kb/s elástica Sensibilidade ao atraso Não Sim, 100s mseg Sim,alguns seg. Sim, 100s mseg Sim e Não

9 2: Nível de Aplicação9 Serviços do protocolo de transporte da Internet Serviço TCP: r Orientado-à-ligação: estabelecimento do Cliente para o Servidor r Transporte fiável entre o processo emissor e o processo receptor r Controlo de fluxo: O emissor não sobrecarrega o receptor r Controlo de congestão: emissor reduz o envio quando a rede está sobrecarregada r Não fornece: garantia de atraso ou de largura de banda. Serviço UDP: r Transferência de dados não fiável entre o processo do emissor e o processo do receptor r 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 ?

10 2: Nível de Aplicação10 Aplic. internet: aplicações e protocolos de transporte Aplicação Acesso remoto a Terminais Web Transferência de ficheiros streaming multimedia Servidor de ficheiros remoto Telefonia Internet Protocolo de nível de Aplicação smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietário (ex: RealNetworks) NSF proprietário (ex: Vocaltec) Protocolo de Transporte TCP TCP or UDP Tipicamente UDP

11 2: Nível de Aplicação11 SILÊNCIO !!!!

12 2: Nível de Aplicação12 A Web: O protocolo HTTP http: hypertext transfer protocol r Protocolo de nível de aplicação da Web r Modelo cliente-servidor m Cliente: browser que pede, recebe e mostra objectos Web m Servidor: Servidor Web envia objectos em resposta a pedidos r http1.0: RFC 1945 r http1.1: RFC 2068 PC a executar Internet Explorer Servidor a executar NCSA Web server Mac a executar Netscape Navigator http request http response

13 2: Nível de Aplicação13 O protocolo HTTP: mais http: Serviço de transporte TCP: r Cliente inicia a ligação TCP (cria um socket) para o Servidor, porto 80 r Servidor aceita a ligação TCP do Cliente r Mensagens http (mensagens do protocolo de nível de aplicação) transferidas entre o browser (Cliente http) e o Servidor Web (servidor http) r 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

14 2: Nível de Aplicação14 Exemplo: http Supondo que um utilizador introduz o URL 1a. Cliente http inicia a ligação TCP (processo) ao Servidor http em: m 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 m request message (contendo o URL) 1b. Servidor http no Sistema Terminal m espera a ligação TCP no porto 80, m aceita pedidos de estabelecimento de ligação m notifica os Clientes. 3. Servidor http m recebe mensagens de pedido constrói a response message contendo os objectos pedidos ( someDepartment/home.index ) m envia a mensagem no socket. tempo (contem texto, Referência a 10 imagens do tipo jpeg)

15 2: Nível de Aplicação15 5. Cliente http recebe mensagens de resposta m Contendo ficheiro html, m Mostra o ficheiro html. m Interpreta o ficheiro html m Encontra a referência a 10 objectos do tipo jpeg objects m 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 m A ligação só é fechada quando o cliente recebe a resposta tempo Exemplo: http (cont) Ligação não persistente

16 2: Nível de Aplicação16 Ligações não persistentes e ligações persistentes Não persistentes r http/1.0: Servidor interpreta o pedido, responde e fecha a ligação TCP r 2 RTTs para obter o objecto m Ligação TCP m Pedido/transferência do objecto r Cada transferência é afectada pelo ritmo inicial lento do TCP (slow rate) r Muitos browsers abrem várias ligações em paralelo Persistentes r Por omissão para htp/1.1 r Na mesma ligação TCP: servidor interpreta o pedido, responde e interpreta novos pedidos,.. r Cliente envia pedidos para todos os objectos referenciados, assim que recebe o objecto de base HTML r Menos RTTs, slow start menos significativo

17 2: Nível de Aplicação17 Formato das mensagens http: request r Dois tipos de mensagens http: request, response r http request message: m ASCII (Formato legível pelos Humanos) GET /somedir/page.html HTTP/1.0 Host: Connection: close User-agent: Mozilla/4.0 Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) Linhas de Cabeçalho Carriage return, line feed Indicam o fim da mensagem

18 2: Nível de Aplicação18 Formato das mensagens http: request GET /somedir/page.html HTTP/1.0 Host: 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

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

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

21 2: Nível de Aplicação21 Formato da mensagem http: response 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... 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

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

23 2: Nível de Aplicação23 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, O que for digitado é enviado para este porto em telnet 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 !

24 2: Nível de Aplicação24 User-server interaction: authentication Authentication : control access to server content r authorization credentials: typically name, password r 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: usual http response msgusual http request msg + Authorization: usual http response msg time

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

26 2: Nível de Aplicação26 Cookies: mantendo o estado r Servidor gera um nº, servidor recorda o nº para usar mais tarde: m autenticação m Recordar as preferências do utilizador, escolhas anteriores r Servidor envia a cookie na mensagem de resposta do cliente Set-cookie: r Cliente adiciona a cookie aos pedidos seguintes: cookie: cliente servidor http request msg usual http response usual + Set-cookie: # http request msg usual cookie: # http response msg usualhttp request msg usual cookie: # http response msg usual Acção específica da cookie Acção específica da cookie

27 2: Nível de Aplicação27 GET condicional: cache no lado do cliente r Objectivo: não enviar os objectos se o cliente tiver uma versão actualizada em cache r cliente: específica a data da cópia que tem em cahce no http request If-modified-since: r servidor: a resposta não contém objectos se a cópia de cache do cliente estiver actualizada: HTTP/ Not Modified cliente servidor http request msg If-modified-since: http response HTTP/ Not Modified Objecto não modificado http request msg If-modified-since: http response HTTP/ OK Objecto modificado

28 2: Nível de Aplicação28 Caches Web (proxy server) r Uitilizador activa o browser: acessos Web através da cache r Cliente envia todos os http requests para a cache m Objecto existe na cache: cache web devolve o objecto m 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 Proxy server client http request http response http request http response origin server origin server

29 2: Nível de Aplicação29 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 Rede institucional LAN a 10 Mbp Ligação de acesso 1.5 Mbps Cache institucional

30 2: Nível de Aplicação30 ftp: o protocolo de transferência de ficheiros (file transfer protocol) r Transferência de ficheiros de/para o Sistema Terminal r Modelo Cliente-Servidor m Cliente: Inicia a transferência (de/para o Sistema remoto) m Servidor: Sistema Remoto r ftp: RFC 959 r ftp server: port 21 file transfer Servidor FTP Interface utilizador FTP Cliente FTP Sistema ficheiros local Sistema ficheiros remoto Utilizador num Sistema Terminal

31 2: Nível de Aplicação31 ftp: Controlo separado, ligações de dados r Cliente ftp contacta o servidor no porto 21, especificando o TCP como protocolo de transporte r São abertas duas ligações TCP em paralelo: m controlo: transferência de comandos, respostas entre cliente e servidor. Controlo (ou sinalização) out of band m Dados: ficheiro de dados de/para o servidor r Servidor ftp mantém o estado: directório actual, autenticação anterior Cliente FTP Servidor FTP Ligação de controlo TCP porto 21 Ligação de dados TCP porto 20

32 2: Nível de Aplicação32 Comandos ftp, respostas Exemplos de comandos: 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 Códigos de estado e descrição (como no http) r 331 Username OK, password required r 125 data connection already open; transfer starting r 425 Cant open data connection r 452 Error writing file

33 2: Nível de Aplicação33 Correio electrónico Três componentes fundamentais: r Agentes utilizador r Servidores de mail r 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 mailbox outgoing message queue mail server user agent user agent user agent mail server user agent mail server user agent user agent SMTP

34 2: Nível de Aplicação34 Correio electrónico: servidores de Servidores de Mail r mailbox contém as mensagens que entraram (ainda não lidas) para o utilizador r message queue de mensagens de mail que o utilizador quer enviar (ainda não enviadas) r smtp protocol entre servidores de para enviar as mensagens m cliente: envia para o servidor m server: servidor de recepção de mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

35 2: Nível de Aplicação35 Correio electrónico : smtp [RFC 821] r Utiliza TCP para transferir mensagens de do cliente para o servidor, de forma fiável, através do porto 25. r Transferência directa: servidor de envio para servidor de recepção r Três fases de transferência m handshaking (greeting) m Transferência de mensagens m fecho r Interacção comando-resposta m commandos: texto ASCII m resposta: código e descrição de estado r Mensagens codificadas em 7 bits ASCII

36 2: Nível de Aplicação36 Experimentem o smtp por vocês mesmos r Digitar telnet servername 25 r observar 220 reply from server r digitar comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT r Os procedimentos anteriores permitem enviar s sem usar um cliente de (reader)

37 2: Nível de Aplicação37 Exemplo de interacção com smtp Crepes.fr Hamburger.edu Do you like ketchup ? What about pickles ?

38 2: Nível de Aplicação38 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: 250 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

39 2: Nível de Aplicação39 smtp: palavras finais r smtp utiliza ligações persistentes r 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 http: pull r push r Ambos têm interacção comando/resposta em ASCII, códigos de estado r http: cada objecto encapsula a sua própria mensagem de resposta r smtp: múltiplos objectos enviados em múltiplas partes (multipart message)

40 2: Nível de Aplicação40 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 To: m From: m Subject: diferente dos comandos smtp r Corpo m Apenas os caracteres ASCII da mensagem header body Linha em branco

41 2: Nível de Aplicação41 Formato das mensagens: extensões multimédia r MIME: extensões de mail para informação multimédia, RFC 2045, 2056 r 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 Tipo de dados multimédia, sub-tipo, declaração de parâmetros Método usado para codificar os dados Versão MIME Dados codificados

42 2: Nível de Aplicação42 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 r Outros dados que têm de ser processados pelo leitor antes de serem visíveis Exemplo de sub-tipos : msword, octet-stream

43 2: Nível de Aplicação43 Tipo Multipart 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 Para incluir no múltiplos objectos Início da próxima parte

44 2: Nível de Aplicação44 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

45 2: Nível de Aplicação45 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

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

47 2: Nível de Aplicação47 protocolo POP3 Fase de autorização r Comandos do cliente: user: declara username pass: password r Servidor responde m +OK m -ERR Fase de transacção, cliente: list: lista nº das mensagens retr: obtém mensagens através no nº dele: apaga r quit:termina C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off C: telnet hamburger.edu 110 S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

48 2: Nível de Aplicação48 protocolo IMAP Objectivo: r Utilizadores podem manipular mailboxes remotamente, como se fossem locais Organizar folders: criar, apagar, inserir, remover ou mover mensagens r Utilizador pode obter apenas componentes específicos do mail m Só cabeçalho, só uma parte duma mensagem multipart Quatro fases, : Estado não autenticado: estado inicial, quando a ligação se inicia: m Utilizador envia user name e password r Estado autenticado: m Utilizador selecciona o folder r Estado seleccionado m Utilizador envia comandos que afectam as mensagens r Estado Logout:termina

49 2: Nível de Aplicação49 DNS: Domain Name System Pessoas: muitos identificadores: m SSN, name, passport # Internet hosts, routers: m IP address (32 bit) – utilizado para endereçar datagramas m nome, e.g., gaia.cs.umass.edu – usado pelos humanos Q: mapeamento entre endereços IP e nomes ? Domain Name System: r Base de dados distribuida implementada numa hierarquia de muitos name servers r Protocolo de nível de aplicação sistemas terminais, routers, servidores de nomes comunicam para resolver nomes (tradução endereço/nome) m nota: função do núcleo da Internet, implementada como protocolo de nível de aplicação m Complexidade nas fronteiras da rede

50 2: Nível de Aplicação50 DNS name servers r 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 Todos os Sistemas Terminais têm o seu nome, endereço IP armazenado num Servidor de Nome Autoritativo m Pode executar a tradução nome/endereço do nome do Sistema Terminal 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 Não é escalável !

51 2: Nível de Aplicação51 DNS: Servidores de nome de raíz (Root Name Server) r Contactados pelo servidor de nomes local, quando este não resolve o end. r 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 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

52 2: Nível de Aplicação52 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 host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu local name server dns.eurecom.fr

53 2: Nível de Aplicação53 Exemplo de DNS Root name server: r Pode não conhecer o Servidor Autoritativo r Pode conhecer servidores de nomes intermédios: quem contactar para saber o servidor de nomes autoritativo requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

54 2: Nível de Aplicação54 DNS: perguntas iterativas Perguntas recursivas: r Coloca o peso da resolução de nomes no servidor contactado r Carga elevada ? Perguntas iterativas: r O servidor contactado responde com o nome do servidor a contactar r Não conheço este nome, mas pergunta a este Servidor !! requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

55 2: Nível de Aplicação55 DNS: caching e records de actualização r 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 m RFC 2136 m

56 2: Nível de Aplicação56 DNS records DNS: Records de recursos (RR) armazanedos numa Base de Dados distribuída r 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) r Tipo=A Nome do Sistema Terminal Valor é um endereço IP r Tipo=CNAME Nome é uma alias para o nome canónico (the real) é realmente servereast.backup2.ibm.com Valor é o nome canónico r Type=MX m Valor é o nome do servidor de mail associado com o nome

57 2: Nível de Aplicação57 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 16 bit # para query, m reply à query usa o mesmo # r flags: m query iou reply m recursion desejada m recursion disponível m reply é autoritativa

58 2: Nível de Aplicação58 Nome, tipo de campo para uma query RRs na resposta à query records para authoritative servers Informação adicional que pode ser útil protocolo DNS, messagens

59 2: Nível de Aplicação59 Parte 2: Sumário r Requisitos do serviço de aplicação: m fiabilidade, largura de banda, atraso r paradigma cliente-server r Modelo de saída do transporte na Internet m Serviço orientada à ligação, Fiabilidade: TCP m Não fiável, datagramss: UDP O estudo das aplicações está completo ! r Protocolos específicos: m http m ftp m smtp, pop3 m dns

60 2: Nível de Aplicação60 Parte 2: Sumário r Tipicamente transferência de mensagens request/reply: m Cliente pede informação ou serviço m Servidor responde com dados, código de estado r Formato das messagens: m Cabeçalho (header): campos que fornecem informação sobre os dados m dados: informação a ser comunicada Muito importante: aprender protocolos r controlo vs. mensagens de dados m in-band, out-of-band r Centralizado vs. distribuído r Sem estado vs. com estado r (stateless vs statefull) r Transferência de mensagens fiável vs. não fiável r complexidade no limite da rede r segurança: autenticação


Carregar ppt "2: Nível de Aplicação1 SILÊNCIO !!!!. 2: Nível de Aplicação2 Parte 2: Nível de Aplicação Objectivos r conceitos, aspectos de implementação dos protocolos."

Apresentações semelhantes


Anúncios Google