Capítulo 2 Camada de Aplicação

Transcrição

1 Capítulo 2 Camada de Aplicação A note on the use of these ppt slides: We re making these slides freely available to all (faculty, students, readers). They re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, July Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved 2: Camada de Aplicação 1

2 2: Camada de Aplicação 2 2

3 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 3

4 Capítulo 2: Camada de Aplicação Objetivos: Conceitual, aspectos de implementação dos protocolos de aplicação Modelos de serviço da camada de transporte Modelo Cliente x Servidor Modelo Peer-to- Peer (Peer2Peer) Aprender sobre os protocolos através de protocolos populares na camada de aplicação HTTP FTP SMTP / POP3 / IMAP DNS Programação de aplicações de rede socket API 2: Camada de Aplicação 4

5 Algumas aplicações de rede Web Sistema de Mensagem instantânea (Instant Messaging) Login remoto Compartilhamento de arquivo P2P Jogos de rede multiusuários Vídeo sob demanda Voz sobre IP (VoiP) Vídeo-conferência Computação GRID 2: Camada de Aplicação 5

6 Criando uma aplicação de rede Escreva programas que Executem em sistemas finais diferentes Comuniquem-se via rede e.x., o software de um servidor web comunica-se com o software de um browser Poucos softwares são escritos para os dispositivos no núcleo da rede Os dispositivos do núcleo não executam aplicações do usuário Aplicações nos sistemas finais permitem um rápido desenvolvimento da aplicação e a sua propagação application transport network data link physical application transport network data link physical application transport network data link physical 2: Camada de Aplicação 6

7 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 7

8 Arquiteturas de aplicação Cliente-Servidor Peer-to-peer (P2P) Híbrido de Cliente-Servidor e P2P 2: Camada de Aplicação 8

9 Arquitetura Cliente-Servidor Servidor: Sempre on Endereço IP permanente Fazendas de servidores para fins de escalabilidade Cliente: Comunica com o servidor cliente/servidor Pode ser conectado de modo intermitente Pode possuir endereço IP dinâmico Não se comunica diretamente com outro cliente 2: Camada de Aplicação 9

10 Data Centers: Google Custo Estimado de um Data Center: $600M Google tem gasto mais de $3B/ano em data centers Cada data center utilliza megawatts de potência 2: Camada de Aplicação 10

11 Arquitetura P2P Pura Não existem servidores sempre on Sistemas finais arbitrários comunicam-se diretamente Os pares são conectados de modo intermitente e podem ter o endereço IP alterado exemplo: Gnutella P2P Altamente escalável mas difícil de gerenciar 2: Camada de Aplicação 11

12 Híbrido de Cliente-Servidor e P2P Skype Aplicação P2P de voz sobre IP (VoiP) Servidor centralizado: permite encontrar o endereço de um parceiro remoto; Conexão cliente-cliente: direta (sem passar pelo servidor) Mensagem Instantânea Conversa entre dois usuários (P2P) Serviço centralizado: deteção/localização da presença do cliente Usuários registram seus endereços IP no servidor central quando eles tornam-se online Usuário contacta o servidor central para obter o endereço IP dos pares 2: Camada de Aplicação 12

13 Processos comunicantes Processo: programa em execução no host Dentro de um mesmo host, dois processos comunicam-se através do uso da comunicação entre-processos (definida pelo OS) Processos em hosts diferentes comunicamse através da troca de mensagens Processo cliente: processo que inicia a comunicação Processo servidor: processo que espera ser contactado Nota: aplicações P2P possuem processos clientes & processos servidores 2: Camada de Aplicação 13

14 Sockets Processo envia/recebe mensagens para/do seu socket O socket é análogo a uma porta o processo emissor empurra a mensagem através da porta o processo emissor confia na infra-estrutura de transporte do outro lado da porta que leva a mensagem ao socket do processo receptor. host ou servidor processo socket TCP com buffers, variáveis Controlado pelo desenvolvedor da aplicação Internet Controlado pelo OS host ou servidor processo socket TCP com buffers, variáveis API: (1) escolha do protocolo de transporte; (2) possibilidade de fixar alguns parâmetros (discussão mais à frente!) 2: Camada de Aplicação 14

15 Identificação dos processos Para receber mensagens os processos devem possuir um identificador O host possui um endereço IP de 32-bits Q: o endereço IP do host no qual o processo executa é suficiente para identificar o processo? 2: Camada de Aplicação 15

16 Identificação dos processos R: Não, já que muitos processos podem estar executando no mesmo host identificador inclui o endereço IP e o número da porta associada ao processo no host. Exemplos de portas: Servidor HTTP: 80 Servidor de 25 Para enviar mensagens HTTP ao servidor web gaia.cs.umass.edu: Endereço Ip: Número da porta: 80 2: Camada de Aplicação 16

17 Protocolo da camada de aplicação define: Tipos das mensagens trocadas, e.x., requisição (request), resposta (response) Sintaxe da mensagem: Quais campos fazem parte da mensagem, ordem e tamanho dos campos Semântica da mensagem Significado da informação nos campos Regras para quando e como os processos reagem à troca de mensagens Protocolos de domínio público: Definidos em RFCs Permite a interoperabilidade e.x., HTTP, SMTP Protocolos proprietários: e.x., Skype 2: Camada de Aplicação 17

18 Quais serviços de transporte as aplicações necessitam? Perda de dados Algumas aplicações (e.x., áudio) podem tolerar alguma perda Outras aplicações (e.x., transferência de arquivos, telnet) requerem 100% para a transferência confiável de dados Temporização Algumas aplicações (ex. Telefonia na Internet, jogos interativos) requerem baixo atraso para serem efetivas Bandwidth Algumas aplicações (e.x. multimídia) requerem uma quantidade mínima de banda para serem efetivas Outras aplicações ( aplic. elásticas) utilizam qualquer banda que eles obtêm 2: Camada de Aplicação 18

19 Requisitos de algumas aplicações relativamente ao serviço de transporte Aplicação Transf. de arquivo Documentos Web Áudio/vídeo em teleconferência Áudio/vídeo armazenado Jogos interativos Mensagem instantânea Perda de dados Sem perda Sem perda Sem perda Tolerante Tolerante Tolerante Sem perda Bandwidth elástico elástico elástico áudio: 5kbps-1Mbps vídeo:10kbps-5mbps igual ao de cima Alguns kbps a mais elástico Sensibilidade ao tempo não não não sim, 100 s msec sim, alguns secs sim, 100 s msec sim e não 2: Camada de Aplicação 19

20 Protocolos de transporte na Internet Serviço TCP: Orientado à conexão: requer o estabelecimento da conexão entre os processos cliente e servidor Transporte confiável: entre os processos emissor e receptor Controle de fluxo: o emissor não deve sobrecarregar o receptor Controle de congestionamento: regular o emissor quando a rede está sobrecarregada Não suporta: temporização, garantia de banda mínima Serviço UDP: Transferência nãoconfiável de dados entre os processos emissor e receptor Não suporta: estabelecimento de conexão, controle defluxo, controle de congestionamento, temporizações, ou garantia de banda 2: Camada de Aplicação 20

21 Aplicações Internet: protocolos de aplicação & de transporte Applicação Acesso de terminal remoto Web Transferência de arquivos Fluxo multimídia Telefonia Internet Protocolo da camada de aplicação SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietário (e.g. RealNetworks) proprietary (e.g., Vonage,Dialpad) Protocolo de transporte associado TCP TCP TCP TCP TCP or UDP tipicamente UDP 2: Camada de Aplicação 21

22 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 22

23 Web e HTTP Inicialmente algumas definições página Web consiste de objetos Objeto pode ser um arquivo HTML, imagem JPEG, applet Java, arquivo de áudio, Página Web consiste de um arquivo HTML que inclui referências a outros objetos Cada objeto é endereçável através de uma URL Exemplo URL: Nome do host Nome do caminho (path) 2: Camada de Aplicação 23

24 Descrição do HTTP HTTP: hypertext transfer protocol Protocolo de aplicação da Web Modelo cliente x servidor cliente: browser usado para requisitar, receber, apresentar objetos Web servidor: servidor Web envia objetos em resposta às requisições HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC executando Int. Explorer Mac executando Navegador Requisição HTTP Resposta HTTP Requisição HTTP Resposta HTTP Servidor executando Servidor Apache Web 2: Camada de Aplicação 24

25 Descrição HTTP (continuação) Utiliza TCP: Cliente inicia conexão TCP (cria socket) com o servidor, porta 80 Servidor aceita pedido de conexão TCP do cliente Troca de mensagens HTTP entre o browser (cliente HTTP) e o servidor Web (servidor HTTP) encerramento da conexão TCP HTTP é stateless Servidor não mantém qualquer informação sobre as requisições anteriores do cliente Protocolos que mantêm estado são complexos! Obs. O passado (estado) deve ser mantido Caso o servidor/cliente falhe, suas visões de estado podem ser inconsistentes e devem ser reconciliadas 2: Camada de Aplicação 25

26 Conexões HTTP HTTP não-persistente No máximo um objeto é enviado em uma conexão TCP. HTTP/1.0 utiliza o HTTP não-persistente HTTP Persistente Múltiplos objetos podem ser enviados em uma única conexão TCP entre o cliente e o servidor. HTTP/1.1 utiliza conexões persistentes como modo default 2: Camada de Aplicação 26

27 HTTP Não-Persistente Suponha que o usuário entre a seguinte URL (contém texto e referências p/10 Imagens jpeg) tempo 1a. cliente HTTP inicia conexãotcp com o servidor HTTP (processo) em on port cliente HTTP envia mensagem de requisição (contendo URL) no socket da conexão TCP. A mensagem indica que o cliente deseja o objeto somedepartment/home.index 1b. Servidor HTTP no host espera por conexão TCP na porta 80. aceita a conexão notificando ao client 3. Servidor HTTP recebe a mensagem de requisição, prepara a mensagem de resposta contendo o objeto requisitado e a envia no socket 2: Camada de Aplicação 27

28 HTTP não-persistente (cont.) tempo 5. Cliente HTTP recebe a mensagem de resposta contendo arquivo html e, em seguida, apresenta o arquivo html. O parsing do arquivo html encontra 10 referências a objetos.jpeg. 6. Repete os passos 1-5 para cada um dos 10 objetos jpeg 4. Servidor HTTP server fecha a conexão TCP. 2: Camada de Aplicação 28

29 HTTP não-persistente: tempo de resposta Definição de RTT: tempo de ida e volta de um pacote (cliente-servidor-cliente). Tempo de resposta: um RTT para iniciar a conexãotcp um RTT para a requisição HTTP e o retorno da resposta HTTP Tempo de transmissão do arquivo total = 2RTT + tempo de transmissão Inicia conexão TCP RTT Requisita o arquivo RTT Arquivo recebido tempo tempo Tempo de tranmissão do arquivo 2: Camada de Aplicação 29

30 HTTP persistente HTTP não-persistente: requer 2 RTTs por objeto Overhead do OS para cada conexão TCP Em geral os browsers abrem conexões TCP em paralelo para buscar os objetos HTTP persistente O servidor deixa a conexão aberta após o envio da resposta Mensagens HTTP subsequentes entre o par cliente/servidor são enviadas na conexão aberta Persistente sem pipelining: Cliente envia nova requisição somente quando a anterior foi recebida um RTT para cada objeto referenciado Persistente com pipelining: default no HTTP/1.1 Cliente envia requisições assim que ele encontra referência para um objeto Praticamente um RTT para todos os objetos referenciados 2: Camada de Aplicação 30

31 Mensagem de requisição HTTP Dois tipos de mensagens HTTP messages: request, response Mensagem de requisição HTTP: ASCII (formato legível ao ser-humano) Linha de requisição (comandos GET, POST, HEAD) cabeçalho GET /somedir/page.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr Carriage return, line feed indicam o fim da mensagem (carriage return, line feed extras) 2: Camada de Aplicação 31

32 Mensagem de requisição HTTP: formato geral 2: Camada de Aplicação 32

33 Enviando dados de formulário Método Post: Página Web inclui um formulário A entrada é encaminhada (uploaded) ao servidor no entity body Método URL: Usa o método Get A entrada é encaminhada no campo URL da linha de requisição: 2: Camada de Aplicação 33

34 Tipos de métodos HTTP/1.0 GET POST HEAD Similar ao Get. O servidor não retorna o objeto especificado (usado para debugging) HTTP/1.1 GET, POST, HEAD PUT Envia arquivo no entity body para o caminho (path) especificado no campo URL DELETE Deleta o arquivo especificado no campo URL 2: Camada de Aplicação 34

35 Mensagem de resposta HTTP Linha de status Cabeçalho dado, e.x., Arquivo HTML requisitado HTTP/ OK Connection close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun Content-Length: 6821 Content-Type: text/html data data data data data... 2: Camada de Aplicação 35

36 Códigos de status nas mensagens de resposta HTTP Aparecem na primeira linha da mensagem de resposta servidor ->cliente Alguns exemplos de códigos: 200 OK Requisição bem sucedida; objeto requisitado incluído na mensagem; 301 Objeto deslocou Objeto requisitado moveu; nova localização incluída na mensagem; 400 Requisição incorreta Mensagem de requisição não entendida pelo servidor 404 Não encontrado Documento requisitado não encontrado no servidor 505 Versão HTTP Version não suportada 2: Camada de Aplicação 36

37 Acessando um servidor HTTP via linha de comandos 1. Comando telnet para um servidor Web: telnet cis.poly.edu 80 abre conexão TCP na porta 80 (porta default do servidor Web) em cis.poly.edu. Qualquer comando é enviado para a porta 80 em cis.poly.edu 2. comando de requisição GET HTTP: GET /~ross/ HTTP/1.1 Host: cis.poly.edu Ao entrar este comando (bater duas vezes o carriage return), voce envia uma requisição GET mínima mas completa ao Servidor HTTP 3. Analise a resposta enviada pelo servidor HTTP! 2: Camada de Aplicação 37

38 Olhando o HTTP em ação-exemplos Exemplo telnet Exemplo Wireshark (ferramenta livre de monitoramento de redes) 2: Camada de Aplicação 38

39 Estado do usuário: cookies Vários sítios Web utilizam pequenos arquivos chamados cookies Quatro situações: 1) Cookie é gerado no sítio Web na primeira conexão e guardado em base de dados. 2) Cookie é inserido no cabeçalho da mensagem de resposta HTTP 3) Cookie é armazenado e gerenciado pelo browser no host do usuário 4) Cookie é enviado pelo browser ao servidor a cada nova requisição HTTP Exemplo: Susan sempre acessa a Internet através do mesmo PC Visita um sítio específico de e-comércio pela primeira vez Quando a requisição HTTP inicial chega no destino, o sítio cria: ID único Entrada na base de dados para o ID e devolve tais informações na forma de um arquivo cookie. 2: Camada de Aplicação 39

40 Cookies: mantendo o estado cliente ebay 8734 Arquivo cookie ebay 8734 amazon 1678 Uma semana após: ebay 8734 amazon 1678 requisição http resposta http Set-cookie: 1678 requisição http cookie: 1678 resposta http customizada requisição http cookie: 1678 resposta http customizada cookie servidor Servidor Amazon cria ID 1678 para o usuário cria entrada cookie accesso accesso Base de dados 2: Camada de Aplicação 40

41 Cookies (cont.) O quê os cookies oferecem: autorização cartões de compra recomendações estado da sessão do usuário Obs Cookies e privacidade: Os cookies permitem que se aprenda bastante sobre o usuário Você pode fornecer seu nome e para os sítios 2: Camada de Aplicação 41

42 Caches Web (servidor proxy) Objetivo: atender a requisição do cliente sem envolver o servidor original Usuário configura o browser: acesso Web é feito por meio de um proxy Cliente envia todos os pedidos HTTP para o Web cache Se o objeto existe no Web cache: Web cache retorna o objeto Ou o Web cache solicita objeto do servidor original e então envia o objeto ao cliente 2: Camada de Aplicação 42

43 Mais sobre o cache Web O cache atua tanto como cliente como servidor Tipicamente, o cache é instalado pelo ISP (universidade, companhia, ISP residencial) Porque o cache Web? Reduz o tempo de resposta para a requisição do cliente. Reduz o tráfego num enlace de acesso de uma instituição. A densidade de caches na Internet habilita os fracos provedores de conteúdo a efetivamente entregarem o conteúdo (mas fazendo P2P file sharing) 2: Camada de Aplicação 43

44 Exemplo de caching Suponha: Tamanho médio objeto = bits Taxa média de requisições dos browsers da instituição para os servidores de origem = 15/s Atraso típico na nuvem Internet Pública = 2 seg. Atraso típico na LAN = 10 ms Conseqüências: Utilização da LAN = x 15 / = 15% Utilização do enlace de acesso = x 15 / = 150% Atraso total = atraso da LAN + atraso de acesso + atraso da Internet = 10 ms + alguns minutos (sobrecarga) + 2 s = alguns minutos Rede institucional Internet Pública Servidores de origem Enlace de acesso 1 Mbps 10 Mbps LAN 2: Camada de Aplicação 44

45 Exemplo de caching (cont) Solução possível Aumentar a banda do acesso do enlace para, p. ex., 10 Mbps consequência Utilização da LAN = = x 15 / = 15% Utilization do enlace de acesso = = x 15 / = 15% Atraso total = atraso da LAN + atraso do acesso + atraso Internet = 10 ms + 10 ms + 2 s = 2,02 s Trata-se, em geral, de um upgrade caro! Rede institucional Internet Pública Servidores de origem Enlace de acesso 1 Mbps -> 10 Mbps 10 Mbps LAN 2: Camada de Aplicação 45

46 Exemplo de caching (cont) Solução possível: instalação de um cache Suponha que a tx. de sucesso é de 0,4 (40% dos dados pedidos já estão no cache) Consequência 40% das requisições serão satisfeitas imediatamente 60% das requisições serão atendidas pelos servidores originais (usam enlace) A utilização do enlace de acesso é reduzida para 60% implicando em atrasos negligíveis (~10 ms) Atraso médio total= atraso de LAN + atraso de acesso + atraso Internet = 0.4* 10 ms + 0.6*(10 ms s) = 1.21 s Rede institucional Internet Pública Servidores de origem Enlace de acesso 1 Mbps 10 Mbps LAN Cache institucional 2: Camada de Aplicação 46

47 GET condicional Cliente Servidor Razão: não enviar objeto se a versão que o cliente já possui está atualizada. Cliente: especifica a data da versão armazenada no pedido HTTP If-modified-since: <date> Servidor: resposta não contém objeto se a cópia é atualizada: HTTP/ Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/ Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/ OK <data> Objeto não modificado Objeto modificado 2: Camada de Aplicação 47

48 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 48

49 FTP: the file transfer protocol usuário Interface de usuário FTP Cliente FTP Sistema de Arquivo local Transf. de arquivo Servidor FTP Sistema de Arquivo remoto Transferência de arquivo para/do host remoto Modelo cliente x servidor cliente: lado que inicia a transferência (seja para/do host remoto) servidor: host remoto ftp: RFC 959 Servidor ftp: porta 21 2: Camada de Aplicação 49

50 FTP: separa fluxo de controle e fluxo de dados Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como protocolo de transporte Cliente obtém autorização pela conexão de controle Cliente procura o diretório remoto enviando comandos pela conexão de controle Quando o servidor recebe um comando para uma transferência de arquivo, ele abre uma conexão de dados TCP para o cliente Após a transferência de um arquivo, o servidor fecha a conexão Servidor abre uma segunda conexão de dados TCP para transferir outro arquivo Conexão de controle: fora da banda Servidor FTP mantém estado : diretório atual, autenticação anterior Conexão de controle TCP porta 21 Cliente FTP Conexão TCP de dados porta 20 Servidor FTP 2: Camada de Aplicação 50

51 FTP commands, responses Exemplos de comandos: Envie um texto ASCII sobre canal de controle USER username PASS password LIST retorna listagem do arquivo no diretório atual RETR filename recupera (obtém) o arquivo STOR filename armazena o arquivo no hospedeiro remoto Exemplos de códigos de retorno Código de status e frase (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: Camada de Aplicação 51

52 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 52

53 Correio eletrônico Fila de mensagens de saída Três componentes principais: Agentes do usuário Servidores de Protocolo de transferência de SMTP Agente do usuário Conhecido como leitor de e- mail Composição, edição, leitura de mensagens de E.x., Eudora, Outlook, elm, Mozilla Thunderbird O servidor armazena as mensagens enviadas e recebidas Servidor de SMTP Servidor de Agente do usuário SMTP SMTP Agente do usuário Servidor de Mailbox do usuário Agente do usuário Agente do usuário Agente do usuário Agente do usuário 2: Camada de Aplicação 53

54 Correio eletrônico: servidores de Servidores de Mailbox: contém as mensagens enviadas para o usuário Fila de mensagens: contém as mensagens de saída (a serem enviadas) Protocolo SMTP: protocolo tipo cliente-servidor entre os servidores de para troca de mensagens cliente : servidor emissor do servidor : servidor receptor do Servidor de SMTP Servidor de Agente do usuário SMTP SMTP Agente do usuário Servidor de Agente do usuário Agente do usuário Agente do usuário Agente do usuário 2: Camada de Aplicação 54

55 Correio eletrônico: SMTP [RFC 2821] Utiliza o TCP para transferência confiável das mensagens de do cliente para o servidor via porta 25 Transferência direta: servidor emissor para servidor receptor Transferência em três fases: handshaking (cumprimentos) Transferência de mensagens encerramento Interação comando/resposta comandos: texto ASCII resposta: frase e código de status As mensagens devem ser codificadas em ASCII de 7-bits 2: Camada de Aplicação 55

56 Cenário: Alice envia mensagens para Bob 1) Alice usa o agente (UA) para compor a mensagem e enviar to [email protected] 2) O agente de Alice envia a mensagem para o seu servidor; a mensagem é colocada na fila de mensagem 3) O lado cliente do SMTP abre uma conexão TCP com o servidor de do Bob 4) O cliente SMTP envia a mensagem da Alice na conexão TCP 5) O servidor de do Bob coloca a mensagem no mailbox do Bob 6) Bob evoca o seu agente para ler a mensagem 1 Agente do usuário Servidor de Servidor de 5 6 Agente do usuário 2: Camada de Aplicação 56

57 Exemplo de uma interação SMTP 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 2: Camada de Aplicação 57

58 Tente uma interação SMTP! Entre telnet servername 25 Aguarde resposta tipo: 220 reply from server Entre os comandos para envio de um sem a utilização de um cliente de (reader): HELO, MAIL FROM:, RCPT TO:, DATA, QUIT 2: Camada de Aplicação 58

59 SMTP: características SMTP utiliza conexão persistente SMTP requer as mensagens (cabeçalho & corpo) em ASCII de 7 bits: necessidade de codificação de mensagens com outras codificações que usam mais de 7 bits SMTP utiliza CRLF.CRLF para determinar o fim da mensagem Comparação com o HTTP: HTTP: pull SMTP: push Ambos interagem via comandos/resposta e códigos de status em ASCII HTTP: cada objeto é encapsulado na mensagem de resposta SMTP: múltiplos objetos enviados na mensagem 2: Camada de Aplicação 59

60 Formato da mensagem de SMTP: protocolo para troca de mensagens de RFC 822: padrão para formato da mensagem de texto: Linhas de cabeçalho, e.x., To: From: Subject: (não são os comandos SMTP!) body mensagem codificada com caracteres ASCII de 7 bits cabeçalho body Linha em branco CRLFCRLF 2: Camada de Aplicação 60

61 Formato da mensagem: extensões multimídia MIME: extensão multimedia para o , RFC 2045, 2056 Linhas adicionais no cabeçalho da mensagem declaram o conteúdo do tipo MIME Versão MIME Método usado para codificação do dado Dado multimídia tipo, subtipo, dado codificado From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data 2: Camada de Aplicação 61

62 Protocolos de acesso ao Agente do usuário SMTP SMTP Protocolo de acesso Servidor de emissor Servidor de receptor SMTP: entrega/armazenamento no servidor de recepção Protocolo de acesso ao recebimento da mensagem do servidor POP: Post Office Protocol [RFC 1939] autorização (agente <-->servidor) e download IMAP: Internet Mail Access Protocol [RFC 1730] Mais características (mais complexo) Manipulação das mensagens armazenadas no servidor HTTP: gmail, Hotmail, Yahoo! Mail, etc. Agente do usuário 2: Camada de Aplicação 62

63 Protocolo POP3 Fase de autorização Comandos do cliente: user: declara username pass: password Respostas do servidor +OK -ERR Fase de transação, cliente: list: lista número da mensagem retr: recupera mensagem pelo número dele: deleta quit S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on C: list S: S: 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 2: Camada de Aplicação 63

64 POP3 e IMAP Mais sobre o POP3 Exemplo anterior utiliza o modo download and delete. Bob não pode reler o e- mail caso ele troque de cliente Download-and-keep : cópias das mensagens em clientes diferentes POP3 é do tipo stateless IMAP Mantém as mensagens em único lugar: o servidor Permite que o usuário organize as mensagens em pastas IMAP mantém o estado do usuário entre sessões: Nomes dos folders e mapeamento entre o ID das mensagens e o nome da pasta 2: Camada de Aplicação 64

65 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 65

66 DNS: Domain Name System Pessoas: vários identificadores: RG, name, #cic, Hosts Internet, roteadores: Endereço IP (32 bits) usado para endereçamento de datagramas nome, e.x., ww.yahoo.com usado por humanos Q: como mapear nomes e endereços IP? Domain Name System: Base de dados distribuída implementada através de uma hierarquia de vários servidores de nomes Protocolo de aplicação permite que hosts e servidores de nomes comuniquem-se para resolução de nomes (tradução nome/endereço) nota: função do núcleo da Internet mas implementada como um protocolo de camada de aplicação 2: Camada de Aplicação 66

67 DNS Serviços DNS Tradução do nome do host no endereço IP Aliasing do host Canonical, sinônimos (aliases) Aliasing do servidor de Distribuição da carga Servidores Web replicados: conjunto de endereços IP para um nome canônico Por que não um DNS centralizado? Ponto único de falha Alto volume de tráfego Base de dados centralizada distante Dificuldades de manutenção Conclusão: não é escalável! 2: Camada de Aplicação 67

68 Base de dados Hierárquica e distribuída Servidores DNS Root Servidores DNS.com Servidores DNS.org Servidores DNS.edu Servidores DNS yahoo.com Servidores DNS amazon.com Servidores DNS pbs.org Servidores DNS poly.edu Servidores DNS umass.edu Cliente deseja IP para 1 a aprox: Cliente consulta um servidor root para obter o servidor DNS responsável por.com Cliente consulta servidor DNS.com para obter servidor DNS amazon.com Cliente consulta servidor DNS amazon.com para obter o endereço IP de 2: Camada de Aplicação 68

69 DNS: servidores de nome raiz (Root) Contactado pelo servidor de nome local que não é capaz de resolver o nome Servidor de nome raiz: Contata o servidor de nome autoridade (authoritative) se o mapeamento do nome não é conhecido Obém o mapeamento Retorna o mapeamento para o servidor de nome local e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, Paris, SF) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 13 servidores de nome raiz no mundo! 2: Camada de Aplicação 69

70 Servidores TLD e Servidores autoridades Servidores Top-level domain (TLD): responsáveis por com, org, net, edu, etc, e todos os domínios de países como br, uk, fr, ca, jp. Network Solutions mantém servidores TLD.com Educause mantém TLD.edu Servidores DNS autoridades: Servidores DNS das organizações são autoridades para fornecimento do mapeamento IP para o nome dos servidores da organização (e.x., Web, mail). Podem ser mantidos pelas organizações ou pelo provedor de serviço 2: Camada de Aplicação 70

71 Servidor de Nome Local Na verdade, não pertence à hierarquia do DNS cada ISP (ISP residencial, empresa, universidade) possui um. Também chamado de default name server Quando um host faz uma consulta DNS, a consulta é encaminhada ao seu servidor DNS local Atua como um proxy encaminhando a consulta na hierarquia 2: Camada de Aplicação 71

72 Exemplo de resolução de nome através do DNS root DNS server Host em cis.poly.edu deseja o endereço IP para gaia.cs.umass.edu Consulta iterativa: Servidor contactado responde com o nome do servidor a ser contactado Eu não conheço este nome mas pergunte a este servidor local DNS server dns.poly.edu requesting host cis.poly.edu TLD DNS server 6 authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu 2: Camada de Aplicação 72

73 Exemplo de resolução de nome DNS root DNS server Consulta recursiva: 2 3 Transfere o ônus da resolução de nome ao servidor contactado 7 6 TLD DNS server local DNS server dns.poly.edu requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu 2: Camada de Aplicação 73

74 DNS: caching e atualização dos registros Uma vez que qualquer servidor de nomes aprende um mapeamento, ele faz o cache deste mapeamento As entradas do cache possuem validade por um tempo (timeout) desaparecendo após expirado este tempo Parte do conteúdo dos servidores TLD em geral encontra-se no cache dos servidores locais Isso evita a necessidade de contactar os servidores de nome root a todo momento. 2: Camada de Aplicação 74

75 Registros DNS DNS: base de dados distribuída armazenando resource records (RR) Formato RR: (name, value, type, ttl) Type=A Nome é hostname Valor é endereço IP Type=NS Nome é domínio (e.x. foo.com) Valor é o hostname do servidor autoridade para este domínio Type=CNAME name é um alias para algum nome canônico (nome real) é, na realidade, servereast.backup2.ibm.com Valor corresponde ao nome canônico Type=MX value é o nome do servidor de associado ao name 2: Camada de Aplicação 75

76 DNS: protocolo, mensagens Protocolo DNS : mensagens de consulta e resposta, ambas possuem o mesmo formato Cabeçalho da mensagem identificação: 16 bits para consulta; resposta usa o mesmo identificador flags: consulta ou resposta demanda de recursão recursão disponível resposta é de autoridade do domínio 2: Camada de Aplicação 76

77 DNS: protocolo, mensagens Nome, tipo da consulta RRs na resposta a uma consulta Registros para servidores autoridades Informação adicional 2: Camada de Aplicação 77

78 Inserindo registros no DNS Exemplo: novo domínio Network Utopia Registro do nome networkuptopia.com no DNS (e.g., Network Solutions) Fornece nome e endereço IP do servidor de nomes autoridade (deve haver primário e secundário) É preciso inserir 2 registros RRs no servidor TLD: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Criar registros do Tipo A no servidor autoridade para o servidor web e do Type MX para o servidor de mail mail.networkutopia.com 2: Camada de Aplicação 78

79 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 79

80 P2P: Compartilhamento de arquivo Exemplo Alice executa uma aplicação P2P no seu notebook Intermitentemente conecta-se à Internet; obtém um novo endereço IP a cada acesso Pergunta por Hey Jude A aplicação informa outros peers que possuem uma cópia de Hey Jude. Alice escolhe um dos peers, Bob. Uma cópia do arquivo é trazida do PC do Bob para o notebook da Alice: HTTP Enquanto Alice faz o download, outros usuários realizam uploading do notebook da Alice. Os pares da Alice são, simultaneamente, um cliente e um Servidor. Todos os pares são servidores = alta escalabilidade! 2: Camada de Aplicação 80

81 P2P: diretório centralizado Projeto original do Napster 1) Quando um peer conectase, ele informa ao servidor central: Endereço IP conteúdo centralized directory server 1 1 Bob peers 2) Alice pergunta por Hey Jude 3) Alice requisita arquivo da máquina do Bob : Camada de Aplicação 81 Alice

82 P2P: problemas relacionados a um diretório centralizado Ponto único de falha Gargalo no desempenho Problemas de copyright: a ação da lei é óbvia A transferência do arquivo é descentralizada, mas a localização do conteúdo é altamente centralizada 2: Camada de Aplicação 82

83 Gnutella: inundação Completamente distribuída Não possui servidor central Protocolo de domínio público Muitos clientes Gnutella implementam o protocolo Rede overlay: grafo Arco entre os pares X e Y caso exista uma conexão TCP entre eles Todos os pares ativos e os arcos formam uma rede overlay arco: enlace virtual (não físico) Um peer conecta-se, tipicamente, com < 10 vizinhos overlay. 2: Camada de Aplicação 83

84 Gnutella: protocolo mensagem de query nas conexões TCP existentes os pares encaminham a mensagem de Query mensagem de QueryHit enviada no caminho reverso Query QueryHit Query QueryHit File transfer: HTTP Query QueryHit Query Escalabilidade: Limitada pelo esquema de inundação Query 2: Camada de Aplicação 84

85 Gnutella: associação do Peer 1. Ao associar-se, o peer Alice precisa encontrar um outro peer Gnutella na rede: utiliza a lista de candidatos a peers 2. Alice tenta, sequencialmente, conexões TCP com os candidatos peers até o set up com Bob 3. Flooding: Alice envia mensagem de Ping para Bob; Bob encaminha a mensagem para os seus vizinhos overlay. Pares ao receberem a mensagem Ping de Alice respondem com mensagem Pong 4. Alice recebe várias mensagens do tipo Pong e pode, portanto, estabelecer conexões TCP adicionais Desassociação de um Peer: veja a lista de exercícios! 2: Camada de Aplicação 85

86 Overlay Hierárquico Situa-se entre a indexação centralizada e a abordagem baseada em inundação Cada peer é um líder de grupo ou é atribuído a um líder de grupo. Conexão TCP entre o peer e o seu líder de grupo. Conexões TCP entre alguns pares de líderes de grupo. Líder de grupo pesquisa o conteúdo no seus liderados Peer comum Peer líder de grupo Relações de vizinhança na rede overlay 2: Camada de Aplicação 86

87 P2P Estudo de caso: Skype P2P (pc-to-pc, pcto-phone, phone-topc) Voice-Over-IP (VoIP) também IM Protocolo proprietário (algumas pistas obtidas via engenharia reversa) Overlay hierárquico Skype Servidor de login Clientes Skype (SC) Super nó (SN) 2: Camada de Aplicação 87

88 Skype: Realizando uma chamada Usuário inicia o Skype SC registra-se no SN Lista de SNs de bootstrap SC realiza o login (authenticate) Skype login server Call: SC contacta o SN e fornece o ID do destino SN contacta outros SNs (protocolo desconhecido, talvez por inundação) para encontrar o addr do destino; retorna o addr para o SC SC contacta diretamente o destino via TCP 2: Camada de Aplicação 88

89 Estudo de Caso P2P: BitTorrent Distribuição de arquivo P2P tracker: registra os peers participantes de um torrent torrent: grupo de peers que estão trocando pedaços de um arquivo Obtém a lista de peers Negociando partes do arquivo peer 2: Camada de Aplicação 89

90 BitTorrent (1) O arquivo é divido em pedaços (chunks) de 256KB. Peer ao associar-se a um torrent: Não possui chunks, mas irá acumulá-los com o tempo Registra-se com o tracker para obter a lista dos peers e conecta-se ao sub-conjunto dos pares ( neighbors ) Enquanto faz o download, o peer realiza o upload para outros pares. Peers podem ir e vir Uma vez que o peer possui todo o arquivo, ele pode sair (egoísta) ou ficar (altruista) 2: Camada de Aplicação 90

91 BitTorrent (2) Obtendo Chunks Em um certo instante, diferentes peers possuem diferentes subconjuntos de chunks Periodicamente, um peer (Alice) pergunta a cada vizinho pela lista dos chunks que ele possui. Alice envia uma solicitação para as partes que ela não possui Raramente ocorre de ser o primeiro! Enviando Chunks: tit-for-tat Alice envia chunks para 4 vizinhos que estão, atualmente, enviando chunks para ela na taxa mais elevada Reavalia os 4 tops a cada 10 segundos A cada 30 segundos: seleciona aleatoriamente um outro peer, para o qual começa a enviar chunks O novo peer pode fazer parte dos top 4 2: Camada de Aplicação 91

92 Comparando as arquiteturas Cliente- Servidor e P2P Questão : Quanto tempo para distribuir um arquivo inicialmente em um servidor para N outros computadores? F, tamanho do arquivo Servidor u N d N u 1 d 1 u s u 2 d2 Rede (possui abundância de banda) u s : banda de upload do servidor u i : banda de upload do peer cliente i d i : banda de download do peer cliente i 2: Camada de Aplicação 92

93 Cliente-servidor: tempo de distribuição do arquivo O servidor envia N cópias: F Server u u 2 1 d 1 u d 2 s Tempo: NF/u s Cliente i gasta F/d i de tempo para download u N d N Network (with abundant bandwidth) Tempo para distribuir F para N clientes usando o modelo cliente-servidor = d cs = max { NF/u s, F/min(d i ) } i Cresce linearmente com N 2: Camada de Aplicação 93

94 P2P: tempo de distribuição do arquivo Servidor precisa enviar uma cópia de F: tempo de F/u s F Servidor u u 2 1 d 1 u d 2 s cliente i gasta o tempo F/d i para download NF bits no total devem ser recebidos (downloaded) u N d N Rede (com abundância de banda) Maior taxa de upload possível (assumindo que todos os nós enviam pedaços do arquivo para algum peer): u s + Σ u i i=1,n d P2P = max { F/u s, F/min(d i ), NF/(u s + Σu i } i i=1,n 2: Camada de Aplicação 94

95 Comparando as arquiteturas Cliente- Servidor e P2P Tempo Mínimo de Distribuição P2P Cliente-Servidor N 2: Camada de Aplicação 95

96 Distributed Hash Table (DHT) DHT = base de dados distribuída P2P A base de dados possui tuplas (chave,valor); chave: cpf; valor: nome de alguém chave: nome de música; valor: endereço IP Peers consultam o BD com uma chave BD retorna valor(es) que casam com a chave Peers também podem inserir tuplas (chave, valor) 2: Camada de Aplicação 96

97 Identificadores na DHT Atribui um identificador inteiro para cada peer no intervalo [0,2 n -1]. Cada identificador é representado por n bits. Requer que cada chave seja um inteiro no mesmo intervalo. Para obter a chave, fazer o hash da chave original. ex, chave = h( Led Zeppelin IV ) Esta é a razão do nome distributed hash table 2: Camada de Aplicação 97

98 Como atribuir chaves aos peers? Questão central: Atribuir as tuplas (chave, valor) aos peers. Regra: atribua a chave ao peer que possui o ID mais próximo do ID. Convenção adotada: mais próximo corresponde ao sucessor imediato ao valor da chave. Ex: n=4; peers: 1,3,4,5,8,10,12,14; chave = 13, então o sucessor é o peer = 14 chave = 15, então o sucessor é o peer = 1 2: Camada de Aplicação 98

99 DHT Circular (1) Cada peer é ciente somente do sucessor e do predecessor imediatos. Exemplo de uma Rede Overlay 2: Camada de Aplicação 99

100 DHT Circular (2) O(N) mensagens na média para resolver uma consulta (query) quando existem N peers 1111 Sou eu! Quem é o responsável pela chave 1110? : Camada de Aplicação 100

101 DHT Circular com Atalhos Quem é o responsável pela chave 1110? Cada peer conhece os endereços IP do sucessor e do predecessor, assim como, alguns atalhos. Reduz o número de mensagens necessárias. Normalmente adota-se atalhos para O(log N) vizinhos, O(log N) mensagens no caso de uma query 2: Camada de Aplicação 101

102 Dinâmica dos Peers Peer 5 falha Para gerenciar a dinâmica dos peers, requere-se que cada peer conheça o endereço IP dos seus 2 sucessores. Cada peer faz um ping periodicamente para os seus dois sucessores para verificar se ambos ainda estão vivos. Peer 4 deteta; faz o 8 o seu sucessor imediato; pergunta ao peer 8 quem é o seu sucessor imediato; torna o sucessor imediato de 8 seu segundo sucessor. O que acontece se um peer 13 associa-se à rede? 2: Camada de Aplicação 102

103 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 103

104 Programação via Socket Objetivo: aprender como desenvolver aplicações cliente/servidor que se comunicam via socket API de socket Introduzida no Unix FSD4.1, 1981 Criada, utilizada e encerrada de forma explícita pela aplicação Paradigma cliente/servidor Dois tipos de serviços de transporte oferecidos pela API de socket: Datagrama não-confiável socket Trata-se de uma interface local ao host, criada pela aplicação e controlada pelo SO ( porta ) através da qual processos de aplicação podem enviar e receber mensagens de/para outro processo de aplicação Confiável e orientada ao byte 2: Camada de Aplicação 104

105 Programação de socket via TCP Socket: pode ser visto como uma porta entre o processo de aplicação e o protocolo de transporte fim-a-fim (UCP ou TCP) Serviço TCP: transferência confiável de bytes de um processo para outro Controlado pelo programador Controlado pelo SO processo socket TCP com buffers, variáveis internet processo socket TCP com buffers, variáveis Controlado pelo programador Controlado pelo SO host ou servidor host ou servidor 2: Camada de Aplicação 105

106 Programação de socket com TCP Cliente deve contactar o servidor Primeiramente, o processo servidor precisa estar executando O servidor precisa ter criado o socket (porta) que receberá o contacto do cliente Cliente contacta o servidor via: Criação de um socket TCP local ao cliente Especificação do endereço IP e do número da porta associados ao processo servidor Quando cliente cria o socket: o cliente TCP estabelece uma conexão com o servidor TCP Quando contactado pelo cliente, o servidor TCP cria um novo socket para o processo servidor comunicar-se com o cliente Permite que o servidor converse com múltiplos clientes O número da porta de origem serve para distinguir os clientes (mais no cap. 3) Ponto de vista da aplicação O TCP provê uma transferência confiável e ordenada de bytes ( pipe ) entre o cliente e o servidor 2: Camada de Aplicação 106

107 Interação cliente/servidor via socket: TCP Servidor (executando no hostid) cria socket, porta=x, para receber as requisições: welcomesocket = ServerSocket() Cliente Espera um pedido de conexão connectionsocket = welcomesocket.accept() Lê a requisição do connectionsocket Responde para connectionsocket encerra connectionsocket TCP Setup da conexão Cria socket e conecta ao hostid, porta=x clientsocket = Socket() Envia requisição via clientsocket Lê resposta de clientsocket encerra clientsocket 2: Camada de Aplicação 107

108 Stream: jargão teclado monitor um stream é uma sequência de bytes que flui para/de um processo. um stream de entrada é associado a alguma fonte de entrada para o processo, ex., teclado ou socket. Um stream de saída é associado a uma saída, ex., monitor ou socket input stream infromuser Processo cliente output stream outtoserver client infromserver client TCP socket input stream para a rede da rede 2: Camada de Aplicação 108

109 Programação de socket com TCP Exemplo de aplicação cliente-servidor: 1) Cliente lê linha da entrada (input) padrão (infromuser stream) e envia para o servidor via socket (outtoserver stream) 2) Servidor lê a linha via socket 3) Servidor converte a linha para maiúscula e envia de volta para o cliente 4) Cliente lê a linha modificada via socket (infromserver stream) e imprime 2: Camada de Aplicação 109

110 Exemplo: Cliente Java (TCP) import java.io.*; import java.net.*; class TCPClient { Cria fluxo (stream) de entrada Cria socket do cliente e conecta ao servidor Cria fluxo de saída associado ao socket public static void main(string argv[]) throws Exception { String sentence; String modifiedsentence; BufferedReader infromuser = new BufferedReader(new InputStreamReader(System.in)); Socket clientsocket = new Socket("hostname", 6789); DataOutputStream outtoserver = new DataOutputStream(clientSocket.getOutputStream()); 2: Camada de Aplicação 110

111 Exemplo: Cliente Java (TCP), cont. Cria fluxo de entrada associado ao socket Envia linha para o servidor Lê linha enviada pelo servidor BufferedReader infromserver = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = infromuser.readline(); outtoserver.writebytes(sentence + '\n'); modifiedsentence = infromserver.readline(); System.out.println("FROM SERVER: " + modifiedsentence); clientsocket.close(); } } 2: Camada de Aplicação 111

112 Exemplo: servidor Java (TCP) import java.io.*; import java.net.*; class TCPServer { Cria socket de recepção na porta 6789 Espera no socket de recepção um contacto de cliente Cria um fluxo de entrada associado ao socket public static void main(string argv[]) throws Exception { String clientsentence; String capitalizedsentence; ServerSocket welcomesocket = new ServerSocket(6789); while(true) { Socket connectionsocket = welcomesocket.accept(); BufferedReader infromclient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); 2: Camada de Aplicação 112

113 Exemplo: Servidor Java (TCP), cont. Cria fluxo de saída associado ao socket Lê linha Recebida no socket DataOutputStream outtoclient = new DataOutputStream(connectionSocket.getOutputStream()); clientsentence = infromclient.readline(); capitalizedsentence = clientsentence.touppercase() + '\n'; Escreve linha no socket } } } outtoclient.writebytes(capitalizedsentence); Final do loop do while; passa a esperar por uma nova conexão de cliente 2: Camada de Aplicação 113

114 TCP: Observações e Questões O Servidor possui dois tipos de sockets: ServerSocket e Socket Quando o cliente bate na porta do serversocket, o Servidor cria o connectionsocket e completa a conexão TCP. O IP destino e a porta não são explicitamente anexados ao segmento. Múltiplos clientes podem acessar o servidor? 114 2: Camada de Aplicação 114

115 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 Correio Eletrônico SMTP, POP3, IMAP 2.5 DNS 2.6 Aplicações P2P 2.7 Programação de Socket com TCP 2.8 Programação de Socket com UDP 2: Camada de Aplicação 115

116 Programação de Socket com UDP UDP: não existe conexão entre cliente e servidor sem handshaking A origem associa explicitamente um endereço IP de destino e uma porta de destino a cada pacote O servidor deve extrair o endereço IP e a porta de origem do pacote recebido UDP: o dado transmitido pode ser recebido fora de ordem ou perdido ponto de vista da aplicação UDP provê uma transferência de bytes não confiável ( datagramas ) entre o cliente e o servidor 2: Camada de Aplicação 116

117 Interação Cliente/Servidor via socket UDP Servidor (executando no hostid) Cliente cria socket, porta=x, para recebimento da requisição: serversocket = DatagramSocket() Lê requisição de serversocket cria socket, clientsocket = DatagramSocket() Cria datagrama de requisição contendo (endereço hostid e porta=x) e envia através de clientsocket Responde via serversocket especificando o endereço do host do cliente e o número da porta Lê a resposta de clientsocket encerra clientsocket 2: Camada de Aplicação 117

118 Exemplo: cliente Java (UDP) teclado monitor Processo Client process Saída: envia pacote (lembrar que otcp envia fluxo de bytes) input stream UDP packet infromuser sendpacket receivepacket UDP packet Entrada: recebe pacotes (lembrar que o TCP recebe fluxo de bytes) clientsocket client UDP socket UDP socket para a rede da rede 2: Camada de Aplicação 118

119 Exemplo: cliente Java (UDP) import java.io.*; import java.net.*; Cria fluxo de entrada Cria socket do cliente Traduz o nome do host para o endereço IP via DNS class UDPClient { public static void main(string args[]) throws Exception { BufferedReader infromuser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientsocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] senddata = new byte[1024]; byte[] receivedata = new byte[1024]; String sentence = infromuser.readline(); senddata = sentence.getbytes(); 2: Camada de Aplicação 119

120 Example: Java client (UDP), cont. Cria o datagrama contendo o dado, tamanho, end. IP e porta DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, 9876); Envia o datagrama para o servidor Lê o datagrama do servidor clientsocket.send(sendpacket); DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); clientsocket.receive(receivepacket); String modifiedsentence = new String(receivePacket.getData()); } System.out.println("FROM SERVER:" + modifiedsentence); clientsocket.close(); } 2: Camada de Aplicação 120

121 Exemplo: servidor Java (UDP) import java.io.*; import java.net.*; Cria o datagrama socket na porta 9876 Cria o espaço para receber o datagrama Recebe o datagrama class UDPServer { public static void main(string args[]) throws Exception { DatagramSocket serversocket = new DatagramSocket(9876); byte[] receivedata = new byte[1024]; byte[] senddata = new byte[1024]; while(true) { DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); serversocket.receive(receivepacket); 2: Camada de Aplicação 121

122 Exemplo: servidor Java (UDP), cont Obtém o end. IP # da porta da origem String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivepacket.getaddress(); int port = receivepacket.getport(); Cria datagrama para enviar ao cliente Escreve o datagrama no Socket de saída } } String capitalizedsentence = sentence.touppercase(); senddata = capitalizedsentence.getbytes(); DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, port); serversocket.send(sendpacket); } Fim do loop do while e volta a esperar um outro datagrama 2: Camada de Aplicação 122

123 Capítulo 2: resumo O estudo das aplicações de rede está completo! Arquiteturas de aplicação Cliente-servidor P2P híbrida Requisitos do serviço de aplicação: confiabilidade, banda, atraso Protocolos específicos: HTTP FTP SMTP, POP, IMAP DNS P2P: BitTorrent, Skype Programação via socket Modelo de serviço de transporte na Internet Confiável e orientado a conexão: TCP Não-confiável, datagrama: UDP 2: Camada de Aplicação 123

124 Capítulo 2: resumo Importante: conceitos sobre protocolos Troca típica de mensagem request/reply: cliente requisita informação ou serviço Servidor responde com dados e código de status Formatos das mensagens: cabeçalhos: campos que fornecem informações sobre os dados Dado: informação que é comunicada Temas importantes: Mensagens de controle vs. mensagens de dado in-band, out-of-band centralizado vs. decentralizado stateless vs. stateful Transferência confiável vs. não-confiável de mensagem complexidade na borda da rede 2: Camada de Aplicação 124