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

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

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: email, 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

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

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; e-mail: Cliente implementado num mail-reader 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

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

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

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 e-mail Documentos Web audio/video de tempo real audio/video armazenado Jogos interactivos Aplicações financeiras 2: Nível de Aplicação

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

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 e-mail Acesso remoto a Terminais Web Transferência de ficheiros streaming multimedia Servidor de ficheiros remoto Telefonia Internet 2: Nível de Aplicação

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

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

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

Exemplo: http Supondo que um utilizador introduz o URL www.someSchool.edu/someDepartment/home.index (contem texto, Referência a 10 imagens do tipo jpeg) 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. 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. 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

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

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

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: www.someschool.edu 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

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: www.someschool.edu 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

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

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

Formato da mensagem http: response Tempo em que as resposta foi criada no servidor 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 ... 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

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

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

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

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

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: 1678453 Cliente adiciona a “cookie” aos pedidos seguintes: cookie: 1678453 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

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/1.0 304 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/1.1 200 OK <data> 2: Nível de Aplicação

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

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

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

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

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

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

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 email para enviar as mensagens cliente: envia email para o servidor “server”: servidor de recepção de email 2: Nível de Aplicação

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

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

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

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: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... 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

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 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

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

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: alice@crepes.fr To: bob@hamburger.edu 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

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

Para incluir no email múltiplos objectos Tipo Multipart Para incluir no email múltiplos objectos From: alice@crepes.fr To: bob@hamburger.edu 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. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- Início da próxima parte 2: Nível de Aplicação

Tipo Multipart - recepção Received: from crepes.fr by hamburger.edu; 12 Oct 98 From: alice@crepes.fr To: bob@hamburger.edu 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. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- 2: Nível de Aplicação

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: alice@crepes.fr To: bob@hamburger.edu 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. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- 2: Nível de Aplicação

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

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

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

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

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

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

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

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

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

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

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) www.ibm.com é 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

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

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

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

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