PTC Aula A camada de aplicação. (Kurose, p ) 10/03/2017

Alguns apps de rede e-mail web mensagens de texto login remoto compartilhamento de arquivos P2P jogos em rede multiusuários streaming de vídeo armazenado (YouTube, Hulu, Netflix) voz-sobre-ip (e.g., Skype) videoconferência em tempo real redes sociais busca Introdução 2-2

Criando um app de rede escrever programas que: rodam em (diferentes) sistemas finais comunicam-se sobre a rede e.g., programa servidor web rodando em servidor comunica-se com navegador em host do usuário e.g., sistema de compartilhamento de arquivos P2P programa em cada um dos hosts que participam da comunidade não é necessário escrever programa para dispositivos do núcleo da rede dispositivos do núcleo da rede não rodam aplicativos de usuário aplicativos em usuários finais permite rápido desenvolvimento e propagação de apps application aplicação transporte network rede data enlace link physical física application aplicação transporte network rede data enlace link physical física application aplicação transporte network rede data enlace link physical física Introdução 2-3

Arquiteturas de aplicativos possíveis estruturas de aplicativos: cliente-servidor peer-to-peer (P2P) Introdução 2-4

Arquitetura cliente-servidor servidor: em host sempre ligado endereço IP permanente data centers pensando em escala (servidor virtual) cliente/servidor clientes: comunicam-se com servidor podem se conectar de forma intermitente podem ter endereços IP dinâmicos não se comunicam diretamente entre si Web, FTP, Telnet, e-mail,... Introdução 2-5

Arquitetura P2P não há servidor sempre ligado sistemas finais arbitrários (peers) comunicam-se diretamente peers requerem serviço de outros peers provêm serviço para outros peers em retorno autoescalável novos peers trazem novos serviços, assim como novas demandas de serviço peers conectam-se de forma intermitente e mudam endereço IP gerenciamento complexo BitTorrent, Skype,... peer-peer Introdução 2-6

Arquitetura P2P Arquitetura crescente Problemas: ISPs residenciais são assimétricos Segurança Motivação: por que eu vou ceder largura de banda, armazenamento, etc.? Estruturas híbridas. WhatsApp é P2P ou cliente servidor??? peer-peer Introdução 2-7

Sockets processo envia/recebe mensagens de/para uma interface de software (API - Application Programming Interface) chamada socket socket análogo a porta processo transmissor empurra mensagem pela porta processo transmissor confia na infraestrutura de transporte do outro lado da porta para entregar mensagem ao socket no processo receptor aplicação processo transporte rede enlace física socket Internet aplicação processo transporte rede enlace física controlado pelo desenvolvedor do aplicativo controlado pelo sist. operacional Introdução 2-8

Endereçamento de processos para receber mensagens, processo precisa ter identificador dispositivo host tem endereço IP de 32 bits único Q: Endereço IP do host em que o processo roda é suficiente para identificar o processo? A: Não! Muitos processos podem estar rodando no mesmo host! identificador inclui tanto endereço IP (32 bits) quanto número da porta associado com processo no host. exemplos de números de porta: servidor HTTP: 80 servidor de e-mail: 25 Internet Assigned Numbers Authority (IANA) http://www.iana.org para enviar mensagem HTTP para servidor web www.usp.br: endereço IP: 200.144.183.244 número de porta: 80 mais em breve Introdução 2-9

Quais serviços de transporte um app precisa? integridade dos dados alguns apps (e.g., transferência de arquivos, comércio na web) requerem transferência de dados 100% confiável (reliable data transfer) outros apps (e.g., áudio) podem tolerar alguma perda timing alguns apps (e.g., telefonia Internet, jogos iterativos) requerem baixa latência para serem efetivos vazão alguns apps (e.g., multimídia) requerem mínima vazão (bits/segundo) para serem efetivos outros apps ( apps elásticos ) fazem uso de qualquer vazão disponível segurança encriptação, integridade de dados, Introdução 2-10

Requisitos do serviço de transporte: apps comuns aplicativo transferência de arquivos e-mail páginas Web áudio/vídeo em tempo real áudio/vídeo armazenado jogos interativos mensagem de teto perda de dados sem perdas sem perdas sem perdas tolerante tolerante tolerante sem perdas vazão elástico elástico elástico áudio: 5kbps-1Mbps vídeo:10kbps-5mbps mesmo acima alguns kbps ou mais elástico timing não não não sim, 100 s ms não sim, alguns s sim, 100 s ms sim e não Introdução 2-11

Serviços dos protocolos de transporte Internet serviços TCP: transporte confiável entre processos transmissor e receptor dados recebidos sem erro e na ordem enviada controle de fluxo: transmissor não soterra receptor controle de congestionamento: regula transmissor quando rede está sobrecarregada orientado a conexão: requer setup entre processos cliente e servidor não provê: timing, garantia de mínima vazão, segurança serviços UDP : transferência de dados não confiável entre processos transmissor e receptor não provê: integridade, controle de fluxo, controle de congestionamento, timing, garantia de vazão, segurança, ou setup de conexão Q: Para que serve o UDP?? Introdução 2-12

Apps internet : protocolos de aplicativos e transport aplicativo e-mail aceso a terminal remoto Web transferência de arquivos streaming de multimídia telefonia Internet protocolo da camada de aplicação SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP (e.g., YouTube), RTP [RFC 1889] SIP, RTP, proprietários (e.g., Skype) protocolo da camada de transporte TCP TCP TCP TCP TCP ou UDP TCP ou UDP Introdução 2-13

Tornando o TCP seguro TCP e UDP sem encriptação senhas não criptografadas enviados pelo socket atravessam a Internet não criptografadas SSL (Secure Sockets Layer) provê conexão TCP criptografada integridade dos dados autenticação end-point SSL é um aplicativo da camada de aplicação Aplicativos usam bibliotecas SSL, que falam com o TCP socket API SSL Aplicativos passam dados para socket SSL que por sua vez passa para socket TCP Usado para web, e-mail, etc... Introdução 2-14

Web e HTTP usa TCP: cliente inicia conexão TCP (cria socket) para o servidor, porta 80 servidor aceita conexão TCP do cliente mensagens HTTP (mensagens do protocolo da camada de aplicação) trocadas entre navegador (cliente HTTP) e servidor Web (servidor HTTP) conexão TCP fechada HTTP é sem memória servidor não mantém informação sobre pedidos anteriores do cliente nota protocolos que mantêm memória são complexos! história passada (estado) precisa ser mantido se cliente/servidor cai, suas visões do estado podem ser inconsistentes, precisam ser reconciliadas Camada de Aplicação 2-15

Mensagem pedido HTTP 2 tipos de mensagens HTTP: pedido (request), resposta Mensagem pedido HTTP: ASCII (formato que permite leitura por humanos) linha de requisição (comandos GET, POST, HEAD) linhas de cabeçalho (opcionais) http://en.wikipedia.org/wiki/list_of_http_header_fields carriage return, line feed no início de linha indica fim de linhas de cabeçalho caractere carriage return caractere line-feed GET /~marcio/index.htm HTTP/1.1\r\n Host: www.lcs.poli.usp.br\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n Accept-Language: pt-br,en-us;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 close para conexão não persistente Camada de Aplicação 2-16

Mensagem pedido HTTP: formato geral método sp URL sp versão cr lf nome do campo de cabeçalho sp valor ~~ ~ ~ cr lf linha de requisição linhas cabeçalho nome do campo de cabeçalho sp valor cr lf cr lf corpo da entidade ~ ~ ~ corpo Camada de Aplicação 2-17

Mensagem resposta HTTP linha de estado (código e frase de estado do protocolo) linhas de cabeçalho dados, e.g., arquivo HTML requisitado HTTP/1.1 200 OK\r\n Date: Tue, 25 Feb 2014 18:24:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 18 Feb 2014 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... Camada de Aplicação 2-18

Códigos de estado da resposta HTTP Código de estado aparece na 1a linha da mensagem resposta servidor-cliente Alguns códigos exemplos: 200 OK atendido com sucesso, objeto pedido mais para frente na msg 301 Moved Permanently objeto pedido foi movido, nova localização especificada mais a frente nessa msg (Location:) 400 Bad Request mensagem pedido não entendida pelo servidor 404 Not Found documento pedido não encontrado nesse servidor 505 HTTP Version Not Supported Camada de Aplicação 2-19

DNS: Domain Name System (RFC 1034 e 1035) pessoas: vários identificadores: CPF, nome, num. do passporte Cada um mais relevante em cada situação hosts e roteadores Internet: Endereço IP (32 bit 4 bytes) usado para endereçar datagramas Hostname - nome, e.g., www.yahoo.com usado por humanos Q: como mapear entre endereço IP e nome, e vice versa? Domain Name System (1983): banco de dados distribuído implementado de forma hierárquica em muitos name servers (ou servidores DNS) protocolo da camada de aplicação: hosts e name servers comunicam-se para decifrar nomes (tradução endereço IP/nome) nota: função de núcleo da Internet, implementada como protocolo da camada de aplicação complexidade na borda da rede Application Layer 2-20

DNS: serviços, estrutura serviços DNS tradução nome do host para endereço IP apelidos para host nomes canônicos, apelidos apelidos para servidores de mail distribuição de carga servidores Web replicados: muitos endereços IP correspondem a um só nome Usa UDP porta 53 Software Berkley Internet Name Domain (BIND) por que não centralizar DNS? Ponto único de falha Volume de tráfego Banco de dados centralizado distante Manutenção Segurança R: não é escalável! Utilizado por outros protocolos da camada de aplicação: HTTP, SMTP, FTP, Pode ser fonte importante de delay Application Layer 2-21

DNS: banco de dados hierárquico e distribuído Servidores DNS Raiz servidores DNS com servidores DNS br servidores DNS edu servidores DNS yahoo.com servidores DNS amazon.com servidores DNS edu.br servidores DNS poly.edu cliente quer IP para www.amazon.com; 1 a abordagem: servidores DNS umass.edu cliente pede a servidor DNS raiz encontrar servidor DNS com cliente pede a servidor DNS top level domain (TLD).com obter servidor amazon.com cliente pede a servidor DNS autoritário de amazon.com obter endereço IP para www.amazon.com Application Layer 2-22

DNS: name servers raízes Contactado, retorna endereços IP de servidores TLD para o domínio desejado (.com,.br,.edu, etc.) 13 name servers raízes ao redor do mundo (247 servidores) Verisign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Netnod, RIPE NCC, ICANN, WIDE 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) e. NASA Mt View, CA f. Internet Software C. Palo Alto, CA (and 48 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) http://www.root-servers.org/ g. US DoD Columbus, OH (5 other sites) Application Layer 2-23

TLD e servidores autoritários servidores top-level domain (TLD): responsáveis por com, org, net, edu, aero, jobs, museums, e todos domínios de nível mais alto de países, e.g.: br, uk, fr, ca, jp VeriSign Global Registry Services mantêm servidores para TLD.com (http://www.networksolutions.com/) Educause para TLD.edu (http://www.educause.edu/) CGI.br para TLD.br (http://www.cgi.br/) Lista completa em http://www.iana.org/domains/root/db servidores DNS autoritários: servidor(es) DNS da própria organização, fornecendo mapeamentos autoritários entre nomes de host e IP para os hosts da organização nomeados podem ser mantidos por organização ou provedor de serviços Application Layer 2-24

Name server DNS local não está estritamente na hierarquia cada ISP (ISP residencial, empresa, universidade) tem um também chamado de default name server IP fornecido pela rede quando host faz consulta DNS, consulta é enviada para seu servidor DNS local tem cache local de traduções nome-endereço recentes (mas algumas podem estar desatualizadas!) age como proxy, repassando consulta para hierarquia Application Layer 2-25

Exemplo de resolução de nome DNS servidor DNS raiz host em lcs.poli.usp.br quer endereço IP para www.unicamp.br 2 3 4 5 servidor DNS TLD consulta iterativa: servidor contatado responde com nome do servidor a contatar Eu não conheço esse nome, mas pergunte a esse servidor Note que são necessárias 8 mensagens DNS para resolver! servidor DNS local dns.lcs.poli.usp.br 1 8 host na rede lcs.poli.usp.br 7 6 servidor DNS autoritário dns.unicamp.br www.unicamp.br Application Layer 2-26

DNS: caching, atualizando registros uma vez que (qualquer) servidor DNS aprende mapeamento, ele o guarda registros do cache são apagados (timeout) depois de algum tempo (TTL - time-to-live muitas vezes, 2 dias) servidores TLD tipicamente guardados em name servers locais assim name servers raízes são raramente visitados registros guardados podem estar desatualizadas (tradução nomepara-endereço com melhor esforço!) se nome do host muda de endereço IP, ele pode não ser conhecido na Internet toda até que todos os TTLs expirem mecanismos de atualização/notificação propostos como padrão IETF RFC 2136 Testar nslookup! Application Layer 2-27

Atacando DNS Se DNS não funcionar Internet (web, email, etc.) para!! ataques DDoS Bombardear servidores raízes com tráfego Tentado em 21/10/2002 Filtragem do tráfego Servidores DNS locais guardam IPs dos servidores TLD, permitindo pular servidores raízes Bombardear servidores TLD Potencialmente mais perigoso Ataques de redirecionamento Man-in-the-middle Consultas interceptadas envenenar DNS Enviar respostas falsas a servidores DNS, que as armazenam Explorar DNS para DDoS Enviar consultas com endereço do emissor falso: IP alvo Requer amplificação Até hoje robusto a ataques. Não conseguiu se impedir DNS de funcionar. Camada de Aplicação 2-28