Capítulo 2 – Camada de Aplicação Redes de Computadores DCC/UFJ Capítulo 2 – Camada de Aplicação Material fortemente baseado nos slides do livro: Computer Networking: A Top-Down Approach Featuring the Internet. Os slides foram disponibilizados pelos autores James F. Kurose e Keith W. Ross All material copyright 1996-2009 J.F Kurose and K.W. Ross, All Rights Reserved 2: Application Layer

Capítulo 2: Camada de Aplicação 2.1 Princípios das aplicações de rede 2.2 Web e HTTP 2.3 FTP 2.4 Email SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Sockets com TCP 2.8 Programação de Sockets com UDP 2: Application Layer

Capítulo 2: Camada de Aplicação Objetivos: Aspectos conceituais e de implementação de protocolos de aplicações em redes Modelos de serviços da camada de transporte Paradigma cliente-servidor Paradigma peer-to-peer aprender um pouco sobre protocolos, examinando protocolos populares da camada de aplicação HTTP FTP SMTP / POP3 / IMAP DNS Programação de aplicações em redes socket API 2: Application Layer

Algumas Aplicações de Rede e-mail web Mensagem instantânea Login remoto Compartilhamento de arquivos P2P Jogos Vídeo armazenado Voz sobre IP Video conferência em tempo real Computação em grade 2: Application Layer

Criando uma aplicação de Rede application transport network data link physical escrever programas que Rodam em (diferentes) sistemas finais Comunicação através da rede e.g., software do servidor web que se comunica com o browser Não existe necessidade de escrever software para os dispositivos no núcleo da rede Dispositivos do núcleo da rede não executam aplicações de ‘usuários’ application transport network data link physical application transport network data link physical 2: Application Layer

Capítulo 2: Camada de Aplicação 2.1 Princípios das aplicações de rede 2.2 Web e HTTP 2.3 FTP 2.4 Email SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Sockets com TCP 2.8 Programação de Sockets com UDP 2: Application Layer 6

Arquiteturas das Aplicações de Redes Cliente-Servidor Peer-to-peer (P2P) Híbrida: cliente-servidor e P2P 2: Application Layer

Arquitetura Cliente-Servidor Sempre um sistema final em funcionamento Endereco IP permanente Conjunto de servidores -> server farms clientes: Comunicam com o servidor Podem ter endereço IP dinâmico Não existe comunicação direta entre clientes cliente/servidor 2: Application Layer

Arquitetura P2P Pura Não existe um servidor sempre em funcionamento Sistemas finais podem se comunicar diretamente uns com os outros Peers se conectam e desconectam e podem mudar os endereços IP Altamente escalável, mas de difícil gerenciamento peer-peer 2: Application Layer

Arquiteturas Híbridas Skype Aplicação P2P de voz sobre IP Servidor central: encontrar o endereço IP Conexão cliente-cliente: direta (sem passar pelo servidor) Mensagem Instantânea Conversa entre dois usuários usa paradigma P2P Serviço centralizado: detecção da presença localização de um cliente Usuário registra seu IP no servidor central quando fica online Usuário contacta um servidor central para encontrar o IP de seus buddies 2: Application Layer

Comunicação entre processos Processo Cliente: processo que inicia a comunicação Processo Servidor: processo que espera para ser contactado Processos : programas em execução em um sistema final. Em um mesmo host dois processos se comunicam usando comunicação entre processos (definida pelo SO). Processos em diferentes sistemas finais, se comunicam através de trocas de mensagens Aplicações com arquitetura P2P possuem processo cliente e processo servidor 2: Application Layer

Sockets Processo envia/recebe mensagens para/de seu socket TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Processo envia/recebe mensagens para/de seu socket Socket análogo a uma porta Processo envia mensagens pela porta Processo que envia msgs se apoia na infraestrutura de transporte que remete a mensagem ao socket ligado ao processo remoto controlled by app developer Internet controlled by OS API: (1) escolha do protocolo de transporte; (2) habilidade para definir alguns parâmetros 2: Application Layer

Endereçando Processos Para receber mensagens, processo tem que ter um identificador O dispositivo do sistema final possui um endereço IP de 32 bits Q: o endereço IP de um sistema final é suficiente para identificar também um processo? identificador inclui o endereço IP e o número da porta associada ao processo rodando no sistema final Exemplo de portas: Servidor HTTP : 80 Servidor Mail: 25 Para enviar mensagens HTTP para o servidor gaia.cs.umass.edu : Endereço IP : 128.119.245.12 Porta: 80 2: Application Layer

Protocolos da Camada de Aplicação definem Tipos de mensagens trocadas e.g., requisições, respostas Sintaxe da Mensagem: Quais são os campos das mensagens e como os campos são delimitados Semântica da Mensagem Significado das informações nos campos Regras para quando e como os processos enviam e respondem mensagens Protocolos de domínio público: Definidos em RFCs Permitem interoperabilidade e.g., HTTP, SMTP Protocolos proprietários: e.g., Skype 2: Application Layer

De que serviços uma aplicação necessita? Perda de pacotes Algumas apl. (e.g., audio) podem tolerar alguma perda Outras apl. (e.g., ftp, telnet) requerem 100% de transferência confiável dos dados Vazão Algumas apl. (e.g., multimedia) requerem quantidade mínima de vazão para serem “eficazes” Outras apl. (“apl. elásticas”) utilizam a vazão que conseguem Segurança Integridade dos dados, … Atraso Algumas apl. (e.g., VoIP, jogos interativos) requerem baixo atraso para serem “eficazes” 2: Application Layer

Requisições que as aplicações fazem a camada de Transporte Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss loss-tolerant Throughput elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up Time Sensitive no yes, 100’s msec yes, few secs yes and no 2: Application Layer

Serviços da camada de transporte Serviços TCP: Orientado a conexão : servidor e clientes devem se conectar Transporte confiável entre os procesos que estão enviando e recebendo mensagens Controle de fluxo: origem nunca vai sobrecarregar o destino Controle de congestionamento: diminui a taxa de envio da origem, quando a rede está congestionada Não provê: atraso e vazão mínimos, segurança Serviços UDP: Transferência não confiável entre os processos de origem e destino Não provê conexão inicial, confiabilidade, controle de fluxo, vazão e atraso mínimos ou segurança Q: Para que existe UDP? 2: Application Layer

Aplicações na Internet: aplicação e protocolos de transporte Protocolo da camada de Aplicação SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP (eg Youtube), RTP [RFC 1889] SIP, RTP, proprietário (e.g., Skype) Protocolo de Transporte TCP TCP or UDP tipicamente UDP Aplicação e-mail acesso a terminal remoto Web transferência de arquivos streaming multimedia telefonia Internet 2: Application Layer

Capítulo 2: Camada de Aplicação 2.1 Princípios das aplicações de rede 2.2 Web e HTTP 2.3 FTP 2.4 Email SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Sockets com TCP 2.8 Programação de Sockets com UDP 2: Application Layer 19

Web e HTTP Alguns termos conhecidos Página Web consiste em um grupo de objetos Objeto pode ser um arquivo HTML, imagem JPEG, applet Java, arquivo de audio,… Páginas Web consistem de um arquivo HTML base com um conjunto de referências a objetos Cada objeto é endereçável a partir de uma URL Exemplo URL: www.someschool.edu/someDept/pic.gif Nome do host Caminho do objeto 2: Application Layer

HTTP HTTP: hypertext transfer protocol Protocolo da camada de aplicação para Web Modelo cliente/servidor Cliente: browser que requisita, recebe e disponibiliza objetos Web Servidor : Servidor Web envia objetos em reposta a requisições HTTP request PC running Explorer HTTP response HTTP request Server running Apache Web server HTTP response Mac running Navigator 2: Application Layer

HTTP (cont.) HTTP é sem estado Usa TCP: Nota Cliente inicializa uma conexão TCP com o servidor, através da porta 80 Servidor aceita a conexão TCP Mensagens HTTP messages (application-layer protocol messages) são trocadas entre o browser (cliente HTTP) e o servidor Web Web (servidor HTTP) Conexão TCP é fechada HTTP é sem estado Servidor não mantém informações sobre requisições passadas dos clientes Nota Protocolos que guardam estados são complexos! Passado deve ser mantido Se o servidor ou cliente caem, o estados podem ficar inconsistentes, e devem ser refeitos 2: Application Layer

Conexões HTTP Não persistente No máximo um objeto é enviado a cada conexão TCP Persistente Vários objetos podem ser enviados em uma única conexão entre o cliente e o servidor 2: Application Layer

referências a 10 imagens jpeg HTTP Não persistente (contem texto, referências a 10 imagens jpeg URL www.someSchool.edu/someDepartment/home.index 1a. Cliente HTTP inicializa uma conexão TCP com o servidor HTTP (processo) em www.someSchool.edu na porta 80 1b. Servidor HTTP em www.someSchool.edu está esperando uma conexão TCP na porta 80. “aceita” a conexão, notificando o cliente 2. Cliente HTTP envia uma mensagem de requisição HTTP (com a URL) no socket TCP. Messagem indica que o cliente quer acessar o objeto someDepartment/home.index 3. Servidor HTTP recebe a mensagem de requisição, monta a mensagem de reposta contendo o objeto e envia ao socket tempo 2: Application Layer

HTTP Não Persistente (cont.) 4. Servidor HTTP fecha a conexão TCP 5. Cliente HTTP recebe a mensagem de resposta vinda do servidor, contendo o arquivo e apresenta o htm. Durante a passagem no arquivo html, o cliente encontra 10 referências a objetos jpge time 6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg 2: Application Layer

HTTP Não Persistente: Tempo de Resposta Definição de RTT: tempo para que um pacote pequento ´viaje´ do cliente para o servidor e volte ao cliente Tempo de reposta: Um RTT para iniciar a conexão TCP Um RTT para que a primeira requisição seja respondida Tempo de transmissão de um objeto total = 2RTT+tempo de transmissão time to transmit file initiate TCP connection RTT request received time 2: Application Layer

HTTP Persistente Problemas do HTTP não persistente: HTTP Persistente Requer 2 RTTs por objeto Sobrecarga do SO para cada conexão TCP browsers oferecem conexões TCP em paralelo para busca de objetos referenciados HTTP Persistente Servidor deixa a conexão aberta após envio de resposta Todas as mensagens trocadas pelo servidor e o cliente usam a mesma conexão TCP aberta no começo Cliente faz uma requisiçaõ assim que encontra um objeto referenciado Um pouco mais de um RTT para todos os objetos referenciados 2: Application Layer

HTTP - Mensagem de requisição Dois tipos de mensagens : requisição, reposta Mensagem de requisição HTTP: ASCII Linha de requisição (comandos GET, POST, HEAD) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr Linhas do cabeçalho Enter significa fim da mensagem 2: Application Layer

Requisições HTTP : formato geral 2: Application Layer

Tipos de Métodos HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT asks server to leave requested object out of response HTTP/1.1 GET, POST, HEAD PUT Realiza o upload de um arquivo para a URL especificada no campo URL DELETE Apaga um arquivo especificado no campo URL 2: Application Layer

HTTP – Mensagem de Reposta Linha de status (código do protocolo) HTTP/1.1 200 OK Connection close 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 do cabeçalho dados, e.g., Arquivo HTML requisitado 2: Application Layer

Códigos de Status -> Respostas HTTP Na primeira linha da mensagem entre servidor->cliente. Alguns exemplos de código: 200 OK Requisição foi feita com sucesso, o objeto está na parte de dados da mensagem 301 Moved Permanently Objeto foi removido do endereço passado, novo endereço é especificado no final da mensagem 400 Bad Request Servidor não entendeu a mensagem de requisição 404 Not Found Documento requisitado não foi encontrado no servidor 505 HTTP Version Not Supported 2: Application Layer

Caches Web (servidores proxy) Objetivo: responder a requisição do cliente sem enviá-la ao servidor No browser: página Web é acessada via cache browser envia todas as requisições a cache Objeto em cache: cache retorna o objeto requisitado] Cache também pode fazer requisições para o servidor original origin server HTTP response Proxy server HTTP request client HTTP request HTTP response client origin server 2: Application Layer

Mais sobre Cache Web Cache age como cliente e servidor Tipicamente a cache é instalada por um provedor de Internet (universidade, companhias, ISPs residênciais) Por quê usar cache? Reduz o tempo de reposta a um cliente Reduz o tráfego nos enlaces de acesso de uma instituição 2: Application Layer