2. Camada de aplicação

2. Camada de aplicação Redes de Computadores

Objetivos Discutir os aspetos conceptuais e de implementação dos protocolos da camada de aplicação Aprender conceitos fundamentais dos protocolos de aplicação através da análise dos mais populares Web: HTTP Transferência de ficheiros: FTP Correio eletrónico: SMTP, POP3, IMAP Tradução de endereços: DNS Aplicações P2P

Bibliografia [Kurose&Ross], Capítulo 2 NOTA Os acetatos que se seguem não substituem a bibliografia aqui referida, e deverão por isso ser vistos apenas como um complemento para o estudo da matéria.

Plano do módulo Aplicações de rede: princípios Web e HTTP FTP Correio eletrónico: POP3, IMAP e SMTP DNS Aplicações P2P

Exemplo de aplicações de rede

Criação de uma aplicação de rede Escrever um programa que Corra em diferentes computadores Comunique pela rede e.g., um browser comunica com um web server Não é necessário escrever software para dos dispositivos das rede Os dispositivos da rede não correm aplicações do utilizador As aplicações correm apenas nos equipamentos terminais Isso foi crucial para o enorme crescimento da Internet Dois tipos de arquitetura Cliente-servidor Peer-to-peer (P2P) application transport network data link physical application transport network data link physical application transport network data link physical

cliente/servidor Arquitetura cliente-servidor Servidor Terminal sempre ligado (always-on) Endereço IP permanente Normalmente estão localizados em grandes data centers por questões de escalabilidade Clientes Comunicam com o servidor Não estão sempre ligados Os seus endereços IP podem ser dinâmicos Não comunicam diretamente entre si

Arquitetura P2P Não há um servidor sempre ligado Os terminais (peers) comunicam diretamente entre si Os peers requisitam serviços de outros peers, e em troca fornecem serviço a outros peers Sistema auto-escalável peers que entram aumentam número de pedidos......mas como também servem pedidos aumentam a capacidade global de serviço do sistema Os peers estão ligados de forma intermitente e o seu IP pode ir variando Tornando a gestão complexa P2P

Comunicação entre processos Processo: programa em execução num computador No mesmo computador, dois processos comunicam usando a comunicação entre processos disponibilizada pelo sistema operativo Processos em computadores diferentes comunicam através da troca de mensagens Arquitetura cliente-servidor Processo cliente é o que inicia a comunicação Processo servidor é o que espera por ser contactado Arquitetura P2P Os peers incluem um processo cliente e um processo servidor

Sockets Os processos enviam/recebem mensagens para/de um socket O socket é como uma porta Os processos enviam mensagens pela porta e esperam que a infraestrutura de transporte que entregue a mensagem na outra porta/socket do processo destino application process socket application process controlled by app developer transport network link physical Internet transport network link physical controlled by OS

Como se ligam os processos? Para receberem mensagens os processos têm de ter um identificador Os computadores têm um endereço IP que é único (na sua rede) Será que o endereço IP do computador é suficiente para identificar um processo que corre nesse computador? Não porque vários processos podem correr no mesmo computador O identificador inclui o endereço IP e o número de porto associado com o processo Exemplos: Servidor HTTP: 80 Servidor de correio: 25 Para ligar ao moodle: Endereço IP: 194.117.42.110 Número de porto: 80

Protocolos de nível de aplicação Definem: Os tipos de mensagens trocadas e.g., pedido, resposta Sintaxe da mensagem Que campos compõem a mensagem e como são organizados Semântica da mensagem O significado de cada campo da mensagem Regras sobre quando enviar que mensagem Protocolos abertos Definidos em RFCs Permitem interoperabilidade e.g., HTTP, SMTP Protocolos proprietários Definidos por empresas e.g., Skype, Dropbox

refletir.com Indique a única afirmação falsa. A: Ao desenvolver aplicações distribuídas não é necessário escrever software para dos dispositivos das rede B: Os protocolos definem a sintaxe das mensagens, isto é, os campos que compõem a mensagem e como são organizados. C: Os protocolos definem também a semântica da mensagem, que lida com o significado de cada campo da mensagem D: O porto do protocolo HTTP é o 180 E: Só há uma resposta falsa.

Noções básicas Uma página web consiste num conjunto de objetos Ficheiros HTML, imagens (JPEG, PNG, etc.), applets, ficheiros de audio e vídeo, etc. Uma página web consiste num ficheiro HTML-base que inclui várias referências para outros objetos Cada objeto é identificado por um URL: http://moodle.ciencias.ulisboa.pt/course/view.php?id=2213 Protocolo Nome do host Caminho (path name)

HTTP: visão geral Protocolo do nível de aplicação Segue modelo cliente/servidor cliente: browser que faz pedidos, recebe respostas e apresenta objetos web na interface gráfica servidor: o servidor envia respostas (objetos) aos pedidos recebidos Utiliza TCP como protocolo de transporte: Cliente cria socket TCP para comunicar Pede ao S.O. para ligar o seu socket ao servidor, no porto 80 O servidor aceita o pedido de ligação TCP do cliente As mensagens codificadas de acordo com o protocolo HTTP são trocadas entre o cliente e o servidor através dos respetivos sockets A ligação TCP é fechada PC a correr Google Chrome Telemóvel a correr browser Safari Servidor a executar Apache Web server

HTTP: protocolo stateless O HTTP é um protocolo stateless (sem estado) porque o servidor não guarda nenhuma informação sobre pedidos anteriores do cliente Vantagem Um protocolo stateless é mais simples Manter um histórico dos pedidos de cada cliente (o tal estado) é complicado Por exemplo, se o servidor falhar podemos ficar num estado inconsistente e provocar problemas Sendo stateless se o servidor falhar não perde nenhuma informação Desvantagem O servidor não pode utilizar informação de pedidos passados do cliente (porque não guarda o estado) Se o servidor mantivesse estado sobre os pedidos dos clientes podia oferecer serviços personalizados Mas de facto isso já acontece hoje em dia em muitos sites! Como é que é resolvido o problema quando é necessário manter estado, sendo o protocolo stateless? Com os cookies, de que falaremos em breve

Ligações HTTP Ligações não persistentes Cada ligação serve para transmitir um objeto e depois é fechada A transferência de um novo objeto requer o estabelecimento de uma nova ligação Ligações persistentes É possível pedir vários objetos utilizando sempre a mesma ligação

HTTP não persistente Suponha que o utilizador insere o URL: www.universidade.pt/departamento/home.index que contém texto e referências para 10 imagens jpeg 1a. Cliente HTTP inicia ligação TCP ao servidor (processo) HTTP em www.universidade.pt, porto 80 2. Cliente HTTP envia mensagem com pedido HTTP (contendo o URL) através do seu socket. A mensagem indica que o cliente quer obter o objeto Departamento/home.html 5. O cliente HTTP recebe a mensagem de resposta contendo o ficheiro HTML e apresenta o HTML no écrã. Deteta que existem 10 referências a objetos jpeg. 1b.Servidor HTTP em www.universidade.pt espera por pedidos de ligação TCP no porto 80. Aceita pedido e notifica cliente. 3. O servidor HTTP recebe a mensagem com o pedido, prepara uma mensagem de resposta contendo o objeto pedido e envia a mensagem através do seu socket 4. O servidor HTTP fecha a ligação TCP 6. Os passos 1-5 são repetidos para cada um dos 10 objetos jpeg

HTTP não persistente: tempo de resposta RTT (Round-Trip Time) tempo que demora a enviar um pacote e a receber a resposta. Tempo de resposta: Um RTT para iniciar a ligação TCP Um RTT para o pedido HTTP e recepção do primeiro pacote de resposta Tempo de transmissão dos restantes pacotes do ficheiro (se não couberem num único pacote) Início ligação TCP RTT Pedido ficheiro RTT Ficheiro recebido time time Tempo de transmissão do ficheiro total = 2RTT + tempo de transmissão

HTTP persistente Problemas do HTTP não persistente: Demora 2 RTTs por objeto Estabelecimento de ligação + pedido do objeto Leva a sobrecarga de pedidos ao Sistema operativo 1 pedido ao SO por cada ligação HTTP persistente O servidor mantém a ligação aberta depois de enviar uma resposta As mensagens HTTP seguintes são enviadas através dessa mesma ligação já aberta O cliente pode enviar um novo pedido assim que encontra uma referência a um objeto numa página HTML Sem necessidade de estabelecer nova ligação TCP Assim, só custa um RTT de estabelecimento de ligação para todos os objetos Em vez de ser 1 RTT por objeto

Pedido HTTP método sp url sp versão cr lf nome cabeçalho valor cr lf Linha do pedido ~ ~ Cabeçalhos nome cabeçalho cr lf valor cr lf Espaço em branco (carriage return, line feed) indica fim dos cabeçalhos corpo da mensagem ~ ~ Corpo Linha do pedido Cabeçalhos Espaço em branco GET /index.html HTTP/1.1\r\n Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n \r\n

HTTP 1.0 GET Tipos de método dados de entrada estão incluídos no campo URL Exemplo: www.somesite.com/animalsearch?monkeys&banana POST HEAD dados de entrada estão incluídos no corpo da mensagem Pede ao servidor que envie apenas o cabeçalho HTTP 1.1 GET, POST, HEAD PUT Faz upload do ficheiro que está no corpo para o caminho (path) especificado no campo URL DELETE Apaga ficheiro no URL especificado

Resposta HTTP versão sp código sp frase cr lf nome cabeçalho valor cr lf Linha do pedido ~ ~ Cabeçalhos nome cabeçalho cr lf valor cr lf Espaço em branco (carriage return, line feed) indica fim dos cabeçalhos corpo da mensagem ~ ~ Corpo Linha do pedido Cabeçalhos Espaço em branco Corpo HTTP/1.1 200 OK\r\n Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=iso-8859-1\r\n \r\n data data data data data...

Códigos de resposta: categorias 1xx: informação 100 Continue (continuar a enviar o pedido) 2xx: sucesso 200 OK (pedido bem sucedido, recurso no corpo) 3xx: redirecionamento 301 Moved Permanently (recurso movido para outro URL) 302 Found (recurso movido temporariamente para outro URL) 304 Not Modified (documento não modificado) 4xx: erro no cliente 400 Bad Request (servidor não percebeu pedido, erro sintaxe) 401 Unauthorized (este pedido necessita de autenticação) 404 Not Found (recurso não existe no servidor) 5xx: erro no servidor 503 Service Unavailable (servidor não consegue responder ao pedido por estar sobrecarregado ou em manutenção)

Exemplo (demo na TP) $ telnet gaia.cs.umass.edu 80 Trying 128.119.245.12... Connected to gaia.cs.umass.edu. Escape character is '^]'. GET /wireshark-labs/intro-wiresharkfile1.html HTTP/1.1 HOST: gaia.cs.umass.edu Espaço em branco! HTTP/1.1 200 OK Date: Mon, 28 Sep 2015 12:39:06 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 mod_perl/2.0.9dev Perl/v5.16.3 Last-Modified: Mon, 28 Sep 2015 05:59:01 GMT ETag: "51-520c864e32cfe" Accept-Ranges: bytes Content-Length: 81 Content-Type: text/html; charset=utf-8 Espaço em branco! <html> Congratulations! You've downloaded the first Wireshark lab file! </html> Connection closed by foreign host. Início da sessão (estabelecimento de ligação TCP) Pedido HTTP enviado pelo cliente Cabeçalhos HTTP da resposta do servidor Web Corpo da resposta do servidor Web Fim da sessão

Como manter estado com o protocolo HTTP? Voltemos à pergunta que colocámos há uns slides atrás: Como é que se consegue manter estado, sendo o protocolo HTTP stateless? Através de cookies São usadas 4 componentes 1. Um cabeçalho cookie na mensagem HTTP de resposta 2. Um cabeçalho cookie no próximo pedido HTTP 3. Um ficheiro de cookies mantido no PC do utilizador, gerido pelo browser 4. Uma base de dados no site web Exemplo típico Acedes a um site web a partir do teu PC Vais pela primeira vez a um site novo de comércio eletrónico Quando chega o teu pedido HTTP inicial o site cria: Um ID único Um entrada na sua base de dados com esse ID

Cookies: manter estado cliente ebay 8734 Ficheiro cookies ebay 8734 amazon 1678 Pedido HTTP normal Resposta HTTP set-cookie: 1678 Pedido HTTP cookie: 1678 Resposta HTTP Ação específica para cookie servidor (amazon) Servidor da Amazon cria o ID 1678 para o utilizador Cria entrada Acesso à BD Base de dados 1 semana depois ebay 8734 amazon 1678 Pedido HTTP cookie: 1678 Resposta HTTP Ação específica para cookie Acesso à BD

Cookies: uso e controvérsia Para que são usados os cookies? autorização lista de compras e.g., loja da Amazon Recomendações Baseados na vossa navegação anterior (que coisas compraram, que artigos leram, etc.) pode recomendar-vos o que fazer a seguir estado de sessão de utilizador Web e-mail, FB login, etc. Controvérsia: privacidade Os cookies permitem que o site saiba muito sobre vocês, e sobre os vossos comportamentos na web O vosso nome, o vosso endereço de e-mail, e outras informações...

discutir.com As cookies são convenientes (evitam a necessidade de estar constantemente a responder às mesmas perguntas quando visitas um site), permitem serviços personalizados (recomendar um produto que vocês não conheciam) mas trazem problemas de privacidade (muitos dos vossos movimentos pela web podem ser gravados) e de segurança (falhas no sistema podem permitir que acedem a informação que consideram sensível) Qual a tua opinião relativamente aos cookies? A = São muito úteis, têm muitos mais vantagens do que inconvenientes. VIVAM OS COOKIES! B = Vejo vantagens e inconvenientes. Estou indecisa/o. C = São indesejáveis, não quero que ninguém grave o que faço, independentemente de poder ter vantagens. FIM DOS COOKIES!

Web cache (servidor proxy) Objetivo: satisfazer pedidos dos clientes sem envolver o servidor origem Utilizador configura o browser para aceder à Web via cache O browser envia todos os pedidos HTTP para a cache Se está em cache, a cache retorna o objeto Caso contrário a cache pede o objeto ao servidor origem, e depois encaminha-o para o cliente Reduz tempo de resposta e quantidade de tráfego para o servidor Servidor proxy cliente Servidor origem cliente Servidor origem

Objetivo: não enviar objeto se a cache tem uma versão atualizada Remove atraso de transmissão Reduz utilização da ligação Especifica-se a data do que está em cache no pedido HTTP If-modified-since: <data> A resposta do servidor não traz objeto se a cópia em cache estiver atualizada HTTP/1.0 304 Not Modified GET condicional cliente HTTP request msg If-modified-since: <data> HTTP response HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <data> HTTP response HTTP/1.0 200 OK <data> servidor Objeto não modificado antes de <data> Objeto modificado depois de <data>

FTP: file transfer protocol Transferir ficheiro de/para terminais remotos Modelo cliente/servidor cliente: inicia transferência servidor: terminal remoto ftp: RFC 959 Servidor ftp: porto 21 user at host FTP user interface FTP client local file system file transfer FTP server remote file system

FTP: canais de controlo e dados separadas Cliente FTP contacta servidor FTP no porto 21, usando TCP O cliente é autorizado através dessa ligação de controlo O cliente pesquisa a diretoria remota e envia comandos através desse canal de controlo Quando o servidor recebe um comando de transferência de ficheiro, abre segunda ligação TCP (de dados) para o cliente Depois de transferir o ficheiro o servidor fecha essa ligação de dados Servidor abre outra ligação de dados TCP para transferir outro ficheiro Princípios importantes A ligação de controlo diz-se que é out of band O servidor FTP mantém estado : a diretoria atual, autenticação anterior, etc. Ligação TCP de controlo, porto 21 Cliente FTP Ligação TCP de dados, porto 20 Servidor FTP

Comandos e respostas Exemplo de comandos (enviados em ASCII através do canal de controlo) USER username PASS password LIST retornar lista de ficheiros da diretoria corrente RETR filename descarregar ficheiro STOR filename armazenar ficheiro Exemplo de códigos de retorno (código e frase, tal como no HTTP) 331 Username OK, necessária password 125 Canal de dados aberto; início de transferência 425 Não consigo abrir canal de dados 452 Erro a escrever o ficheiro

Correio eletrónico Três componentes principais: Agentes do utilizador (user agents) Servidores de correio (mail servers) SMTP: simple mail transfer protocol Agente do utilizador (user agent) O vosso cliente de correio eletrónico e.g., Outlook, Thunderbird, iphone mail client Serve para ler e escrever mensagens de correio As mensagens enviadas e recebidas ficam armazenadas no servidor (pelo menos temporariamente) mail server SMTP mail server user agent user agent SMTP SMTP user agent outgoing message queue mail server user mailbox user agent user agent user agent

Correio eletrónico: servidores de correio Os servidores de correio armazenam as mensagens destinadas ao utilizador As mensagens que estão para ser enviadas ficam guardadas numa fila O protocolo SMTP é usado entre servidores de e-mail para enviar as mensagens de correio eletrónico cliente SMTP: servidor de correio emissor servidor STMP: servidor de correio destino mail server SMTP mail server user agent user agent SMTP SMTP user agent mail server user agent user agent user agent

Correio eletrónico: SMTP [RFC 2821] Usa TCP para transferir de forma fiável as mensagens de correio do cliente para o servidor, no porto 25 A tranferência é direta do servidor emissor para o servidor destino Não passa por intermediários independentemente da distância emissor-destino Há 3 fases na transferência Handshaking ( aperto de mão ) Transferência de mensagens Fecho Interação do tipo comando/resposta tal como o HTTP e o FTP comandos: texto ASCII resposta: código (status code) e frase As mensagens devem ser enviadas em ASCII de 7- bits

Cenário: Alice envia mensagem ao Bob 1) A Alice usa o seu agente para escrever mensagem para bob@universidade.pt 2) O agente envia a mensagem para o seu servidor de correio e a mensagem é colocada numa fila 3)O cliente SMTP abre ligação TCP com o servidor de correio do Bob 4) O cliente SMTP envia a mensagem da Alice através dessa ligação TCP 5) O servidor de correio do Bob coloca a mensagem na caixa de correio do Bob 6) O Bob usa o seu agente para ler a mensagem 1 user agent mail server 2 3 4 mail server 6 user agent Servidor de e-mail da Alice 5 Servidor de e-mail do Bob

demo $ dig servidor.pt mx ( ) ;; ANSWER SECTION: servidor.pt. 7200 IN MX 100 correio1.servidor.pt. servidor.pt. 7200 IN MX 100 correio2.servidor.pt. servidor.pt. 7200 IN MX 100 correio3.servidor.pt. servidor.pt. 7200 IN MX 100 correio4.servidor.pt. ( ) $ telnet correio.servidor.pt 25 Trying 194.117.3.101... Connected to correio.servidor.pt. Escape character is '^]'. 220 correio.servidor.pt ESMTP HELO correio.servidor.pt 250 correio.servidor.pt MAIL from: <qualquer_endereco@gmail.com> 250 2.1.0 Ok RCPT to: <bob@universidade.pt> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Ola. Abraco, Bob. Final da mensagem 250 2.0.0 Ok: queued as 3nS2JS6y1lz12fH QUIT 221 2.0.0 Bye Connection closed by foreign host. Pedido ao DNS para saber qual o endereço dos servidores de correio. Estabelecimento de ligação TCP com o servidor Aperto de mão Definição do emissor e destinatário Envio de dados Correio para a fila Fecho da ligação

SMTP: comparação com HTTP Alguns detalhes importantes O SMTP usa ligações persistentes Se houver muitas mensagens para enviar para o mesmo destino podem todas ser enviadas usando a mesma ligação TCP O SMTP exige que a mensagem (cabeçalho e corpo) seja enviada em ASCII, 7-bit O servidor SMTP usa CRLF.CRLF para determinar o final da mensagem Comparação com HTTP HTTP: protocolo do tipo pull (o cliente puxa o objeto que está no servidor web quando a quer) SMTP: protocolo do tipo push (o servidor de correio cliente empurra a mensagem para o servidor de correio destino) Ambos usam comandos e respostas ASCII para interagirem, e status codes HTTP: cada objeto é encapsulado numa mensagem de resposta SMTP: vários objetos são enviados através de uma única mensagem

Formato de uma mensagem de correio O SMTP é o protocolo que permite o envio de mensagens de correio eletrónico O RFC 5322 é o standard que define o formato das mensagens: Por exemplo, os cabeçalhos To: From: Subject: NOTA: isto é diferente dos comandos SMTP! MAIL FROM RCPT TO Corpo: a mensagem Apenas caracteres ASCII cabeçalho corpo Linha em branco

Protocolos de acesso ao correio user agent SMTP SMTP Protocolos de acesso ao correio (e.g., POP, IMAP) user agent Servidor de email do emissor Servidor de email do destinatário SMTP: envio para servidor destino Mas é necessário outro protocolo de acesso ao correio para ir buscar o correio ao servidor Não pode ser o SMTP por ser protocolo push ( empurra ) E o Bob ir buscar o seu correio ao servidor é operação pull ( puxa ) Protocolos de acesso ao correio POP: Post Office Protocol [RFC 1939]: autorização, descarregar e-mail IMAP: Internet Mail Access Protocol [RFC 1730]: mais funcionalidades, incluindo a manipulação de mensagens armazenadas no servidor HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Protocolo POP3 Fase de autorização Comandos do cliente user: username pass: password Respostas do servidor +OK -ERR Fase de transação list: lista as mensagens retr: descarrega mensagem (por número) dele: apaga mensagem Quit: fechar Neste exemplo usa-se o modo POP3 descarrega e apaga Assim, o Bob não consegue voltar a ler as mensagens se mudar de cliente de e-mail O modo POP3 descarrega e mantém permite cópias das mensagens em diferentes clientes O POP3 é stateless (não guarda estado) entre sessões S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on 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

IMAP Mantem todas as mensagens apenas num sítio: no servidor Permite que o utilizador organize as mensagens por pastas no próprio servidor Para tal, tem de manter estado do utilizador entre sessões Os nomes das diretorias e o mapeamento entre os IDs das mensagens e o nome da diretoria onde elas estão localizadas

DNS: domain name system As pessoas têm muitos identificadores Nome, número de cartão de cidadão, número de contribuinte Os computadores ligados na Internet, assim como os routers, também Os nomes (e.g., www.yahoo.com) são fáceis de usar por humanos Os endereços IP (32 bits) são mais fáceis de ser processados por máquinas, por isso são usados para endereçamento de pacotes Questão: como mapear entre um endereço IP e um nome (e vice-versa)? Resposta: Domain Name System Uma base de dados (BD) distribuída implementada como uma hierarquia de servidores de nomes Protocolo de nível de aplicação Os terminais e os servidores de nomes comunicam para traduzir nomes em endereços (e vice-versa) A este serviço chama-se resolução de nomes Os servidores DNS são tipicamente máquinas UNIX que correm o software BIND O protocolo corre tipicamente sobre UDP e usa o porto 53 Nota interessante: esta é uma função fundamental da arquitetura da Internet, mas é implementada como um protocolo de nível aplicacional! A complexidade é deixada na edge (borda) da rede

DNS: serviços e estrutura Serviços Traduções (resolução) de endereços de nomes de máquinas (hostnames) para endereços IP (e vice-versa) Múltiplos nomes (host aliasing) Nomes próprios ( canónicos ) e alternativos (alias) Nomes de servidor de correio Distribuição de carga e.g., quando temos servidores Web replicados podemos ter múltiplos endereços IP a corresponder a um único nome Estrutura: porque não centralizar o DNS? Tornava-se um SPOF Ponto único de falha (single point of failure) Todo o tráfego concentrado nesse ponto central Uma base de dados centralizada fica distante da maior parte dos clientes Em 2 palavras: Não escala!

DNS: BD distribuída e hierárquica Root DNS Servers com DNS servers org DNS servers edu DNS servers Servidores raiz Servidores TLD yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers poly.edu umass.edu DNS servers DNS servers Servidores autorizados Cliente: qual o IP de www.amazon.com? O cliente pergunta ao servidor DNS de raíz (root server) qual o servidor DNS que deve ser contactado O servidor responde com o servidor TLD que trata do domínio.com. O cliente pergunta a este servidor TLD qual o servidor que trata de amazon.com O servidor responde com o servidor autorizado de amazon.com e o cliente pergunta-lhe qual o endereço IP para aceder a www.amazon.com

DNS: servidores de raíz (root servers) São contactados pelo servidor de nomes local quando este não sabe como resolver um nome Há 13 root servers no mundo Replicados para tolerar faltas e assim aumentar fiabilidade do serviço Alguns usam a técnica anycast Envia pedido para servidor mais próximo e. NASA Mt View, CA f. Internet Software C. Palo Alto, CA (and 48 other sites) c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) k. RIPE London (17 other sites) i. Netnod, Stockholm (37 other sites) m. WIDE Tokyo (5 other sites) a. Verisign, Los Angeles CA (5 other sites) b. USC-ISI Marina del Rey, CA l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites)

DNS: servidores de raíz (root servers) http://www.root-servers.org/

Servidores TLD e servidores autorizados Servidores top-level domain (TLD) Responsáveis pelos domínios com, org, net, edu, e todos os domínios top level de países e.g.: pt, uk, fr, ca, jp Domínio pt é atualmente gerido pela dns.pt Servidor DNS autorizados (authoritative): Servidores DNS de organizações que são considerados a autoridade no que respeita à associação de nomes a endereços de servidores nessa organização e.g., servidor Web, servidor de e-mail Podem ser geridos pela própria organização ou por um fornecedor de serviços

Servidor de DNS local Não pertence, estritamente, à hierarquia Cada ISP (ISP residencial, empresa, universidade) tem um servidor de nomes local Também designado por default name server Quando uma máquina faz um query ao DNS (um pedido de resolução de endereço), esse query é enviado ao servidor de nomes local Funciona como um intermediário que reencaminha os queries para a hierarquia de servidores Tem uma cache local com os pares nome/endereço mais recentes

Resolução de nomes iterativa Exemplo (típico nas aulas TP) A máquina lab1312-01.alunos.di.fc.ul.pt quer saber o endereço IP de gaia.cs.umass.edu Query iterativo: O servidor contactado responde com o nome do servidor a contactar Não conheço este nome, mas sei quem conhece: pergunta a este servidor. Servidor DNS local dns.fc.ul.pt 1 Terminal que faz pedido lab1312-01.alunos.di.fc.ul.pt 2 8 Servidor DNS root 3 4 5 7 Servidor DNS TLD 6 Servidor DNS autorizado dns.cs.umass.edu gaia.cs.umass.edu

Resolução de nomes recursiva Exemplo (típico nas aulas TP) A máquina lab1312-01.alunos.di.fc.ul.pt quer saber o endereço IP de gaia.cs.umass.edu Query recursivo: A responsabilidade da resolução de nomes passa para o servidor de nomes contactado Servidor DNS local dns.fc.ul.pt Terminal que faz pedido lab1312-01.alunos.di.fc.ul.pt 1 2 8 Servidor DNS root 7 6 5 3 4 Servidor DNS TLD Servidor DNS autorizado dns.cs.umass.edu gaia.cs.umass.edu

refletir.com Na vossa opinião, o método recursivo é a melhor técnica de resolução de nomes? TRUE = SIM FALSE = NÃO

DNS: cache e atualização de registos Sempre que um servidor de nome aprende uma nova tradução, armazena-a localmente numa cache Para melhorar o desempenho do sistema, isto é, o tempo de resposta aos pedidos As entradas na cache são removidas após um determinado período de tempo (Time To Live, TTL) já que os mapeamentos não são permanentes A informação sobre os servidores TLD está tipicamente na cache nos servidores de nomes locais Por essa razão os servidor de raiz são raramente visitados Isso ajuda o sistema a escalar E torna-o mais robusto As entradas na cache podem estar desatualizadas Se um terminal mudar de endereço IP pode demorar algum tempo até toda a Internet ficar a saber Tem de se esperar que todos os TTLs expirem A tradução de endereços é um serviço best effort, não há garantias!

Registos DNS O DNS é uma BD distribuída que armazena resource records (RR) Formato de um RR : (nome, valor, tipo, TTL) tipo=a nome é o nome do computador valor é o seu endereço IP Este é o serviço mais usado: resolução nome->ip tipo=ns nome é um domínio (e.g., ulisboa.pt) valor é o hostname do servidor de nomes autorizado neste domínio tipo=cname nome é um alias (nome alternativo) para o nome oficial ( canónico ) e.g., www.ibm.com é, na realidade www.ibm.com.cs186.net valor é o nome oficial tipo=mx valor é o nome do servidor de e-mail associado a nome

DNS: formato das mensagens As mensagens de pedido (query) e de resposta têm o mesmo formato Cabeçalho da mensagem Identificação Número de 16 bits para identificar o query; a resposta usa o mesmo número 2 bytes 2 bytes identification # questions # authority RRs flags # answer RRs # additional RRs questions (variable # of questions) Flags Query ou resposta? Recursão desejada Recursão disponível etc. Número de ocorrências de cada um dos campos que se seguem answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs)

DNS: formato das mensagens As mensagens de pedido (query) e de resposta têm o mesmo formato 2 bytes 2 bytes identification flags # questions # authority RRs # answer RRs # additional RRs Campos com o nome e tipo de um query RRs de reposta a um query Registos de outros servidores autorizados Informação adicional questions (variable # of questions) answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs)

Como inserir registos no DNS? Imaginem que criam uma nova start up, a Network Utopia, e querem colocar o vosso site online Têm de registar o nome networkuptopia.pt num DNS registrar (e.g., a FCCN) Têm de fornecer os nomes e endereço IP de um servidor de nomes autorizado ao registrar e.g., dns1.networkutopia.pt -> 212.212.212.1 O registrar insere dois RRs no servidor TLD do domínio.pt (networkutopia.pt, dns1.networkutopia.pt, NS) (dns1.networkutopia.pt, 212.212.212.1, A) E ainda têm de criar no vosso servidor autorizado Um registo tipo A para www.networkutopia.pt Um registo tipo MX para mail.networkutopia.pt

Ataques ao DNS Ataques DDoS (Distributed DoS) Bombardear os servidores raiz com tráfego Não há muitos casos, mas já aconteceu Filtragem de tráfego pelos root servers protege Além disso, os servidores DNS locais colocam em cache os IPs dos servidores TLD, permitindo não incomodar muito os servidores de root Bombardear os servidores TLD com tráfego Ataques de redireccionamento Man-in-middle: interceptar os queries e enviar respostas falsas aos clientes DNS poisoning: enviar respostas falsas para o servidor de DNS, que as coloca em cache Pode ser usado para redirecionar todo o tráfego para o atacante! Usar o DNS para executar ataque DDoS contra um alvo O alvo pode ser o vosso computador! Atacante envia pedidos usando um endereço IP de emissor falso (técnica de IP spoofing): o IP do alvo a atacar Depois as respostas do DNS vão bombardear o alvo Requer amplificação Tem de haver muitos pedidos destes para despoletar o envio de MUITAS respostas falsas para o alvo

Arquitetura P2P Não depende de nenhum servidor que esteja sempre ligado ( alwayson ) Os terminais ligados à Internet (peers) comunicam diretamente entre si Estes peers não estão sempre ligados Vão entrando e saindo da rede P2P Podem mudar de endereço IP Exemplos: Distribuição de ficheiros (BitTorrent) Streaming de vídeo VoIP (Skype)

Cliente-servidor vs P2P Questão: quanto tempo demora distribuir um ficheiro de tamanho F de um servidor para N clientes/peers? ficheiro, tamanho F u s : capacidade de upload do servidor servidor u s u 1 d 1 u 2 d 2 d i : capacidade de download do peer i u N Rede d i u i d N u i : capacidade de upload do peer i

Tempo de distribuição: cliente-servidor Tempo de transmissão do servidor: deve enviar, sequencialmente, N cópias do ficheiro Tempo para enviar uma cópia: F/u s Tempo para enviar N cópias: NF/u s Cliente: deve receber uma cópia do ficheiro d min = taxa de transferência do cliente mais lento Tempo de transferência do ficheiro desse cliente mais lento: F/d min F u s rede d i u i Aumenta linearmente com N Tempo para distribuir F para N clients usando arquitetura cliente-servidor T c-s > max{nf/u s,f/d min }

Tempo de distribuição: P2P Transmissão pelo servidor: deve enviar pelo menos uma cópia Tempo para enviar uma cópia: F/u s Cliente: tem de descarregar pelo menos uma cópia Para o cliente mais lento: F/d min Clientes: no total têm de descarregar NF bits A taxa de upload total (que limita a taxa de download): u s + Σu i F u s rede Aumenta linearmente com N mas isto também, porque cada peer traz consigo capacidade extra d i u i Tempo para distribuir F para N clientes usando arquitetura P2P T P2P > max{f/u s,,f/d min,,nf/(u s + Σu i )}

Cliente-servidor vs P2P: exemplo Taxa upload dos clientes = u, F/u = 1 hour, u s = 10u, d min u s Minimum Distribution Time 3.5 3 2.5 2 1.5 1 0.5 0 P2P Client-Server 0 5 10 15 20 25 30 35 N Arquitetura auto-escalável

refletir.com Qual o tempo mínimo demora a distribuição de um ficheiro de 1Mbit por 10 clientes, usando uma arquitetura cliente-servidor, assumindo que o servidor tem capacidade de upload de 1Mbps e os clientes têm capacidade de download entre 10Mbps e 10kbps? A = 0.01s; B = 0.1s; C = 1s; D = 10s; E = 100s

Distribuição de ficheiros P2P: BitTorrent Ficheiros divididos em pedaços (chunks) de 256Kb Os peers que participam num torrent enviam e recebem chunks tracker: guarda info sobre peers que participam num torrent torrent: grupo de peers que trocam chunks de um ficheiro A Alice chega obtém lista de peers do tracker e começa a trocar chunks com os outros peers

Distribuição de ficheiros P2P: BitTorrent Quando um peer entra num torrent: Não tem chunks (óbvio) Regista-se com o tracker para obter a lista de peers e liga-se a um subconjunto de peers ( vizinhos ) Ao mesmo tempo que descarrega chunks, o peer também vai enviando os chunks que tem para outros peers Tudo isto é dinâmico Os peers podem trocar de peers vizinhos Os peers podem sair e entrar no torrent Quando um peer consegue descarregar o ficheiro todo (todos os chunks) pode ir embora ( egoísta ) ou manterse no torrent ( altruísta )

Distribuição de ficheiros P2P: BitTorrent Pedidos de chunks: A cada momento, diferentes peers têm diferentes subconjuntos de chunks Periodicamente, a Alice pergunta aos seus peers uma lista dos chunks que eles têm A Alice vai depois pedindo os chunks que não tem dos seus peers, optando por escolher primeiro os mais raros Envio de chunks: tit-for-tat A Alice envia chunks apenas aos 4 peers que lhe enviam chunks com as taxas de transferência mais elevadas Os peers mais fixes Os outros não recebem chunks da Alice são colocados na lista negra (são chocked ) A escolha deste top 4 é reavaliada a cada 10 segundos A cada 30 segundos é escolhido um outro peer, aleatoriamente, para lhe começar a enviar chunks Retiramos este peer aleatório da lista negra (ele é unchocked ) para ver se ele se porta bem (isto é, se ele envia chunks a uma taxa de transferência elevada) Se se portar bem e passar a ser um dos fixes, passa para o top 4

Mecanismo de incentivo tit-for-tat (1) A Alice retira o Bob da lista negra (2) A Alice passa a ser um dos 4 peers fornecedores do Bob; o Bob faz o mesmo (3) O Bob passa a ser um dos 4 peers fornecedores da Alice Quanto melhores peers encontrares, mais depressa obténs o ficheiro! Tit-for-tat: Mecanismo de incentivo fundamental para o sucesso deste serviço

Sumário deste módulo Estudo sobre a camada de aplicação Aplicações de rede: princípios Web e HTTP FTP Correio eletrónico: POP3, IMAP e SMTP DNS Aplicações P2P Importante: aprendemos um conjunto de princípios genéricos sobre protocolos Troca de mensagens típica: pedido/resposta Formato das mensagens: cabeçalhos (informação acerca dos dados) + dados Há mensagens de controlo e mensagens de dados As de controlo podem ser enviadas in-band (mesmo canal dos dados) ou out-of-band (noutro canal, e.g. num outro porto) Há arquiteturas centralizadas e descentralizadas Há protocolos que não mantêm estado (stateless) enquanto outros mantêm (stateful) A complexidade é deixada na edge (borda) da rede