Aula 6. Disciplina: IF66B Redes de Computadores 2018/1 Universidade Tecnológica Federal do Paraná Câmpus Curitiba. Aula 6. Prof. Daniel F.

(1)

Aula 6 Prof. Daniel F. Pigatto Camada de Aplica¸cão Arq. das Aplica¸cões Processos em Comunica¸cão Protocolos da Camada de Aplica¸cão HTTP FTP Correio Eletrônico: SMTP, POP, IMAP DNS P2P Atividades Práticas

Aula 6

Camadas de Sessão, Apresenta¸cão e Aplica¸cão

Prof. Daniel F. Pigatto

Disciplina: IF66B – Redes de Computadores – 2018/1 Universidade Tecnológica Federal do Paraná — Câmpus Curitiba

(2)

Roteiro

1 Camada de Aplica¸c˜ao

2 Arq. das Aplica¸c˜oes

3 Processos em Comunica¸c˜ao

4 Protocolos da Camada de Aplica¸c˜ao

HTTP FTP

Correio Eletrˆonico: SMTP, POP, IMAP DNS

P2P

(3)

Modelo OSI

Camada de Sess˜ao

Cuida dos processos que controlam a transferˆencia dos dados, cuidando dos erros e administrando registros das transmiss˜oes.

• Servi¸cos:

• Controle de di´alogo (quem deve transmitir em cada momento);

• Gerenciamento de tokens (impede opera¸c˜oes cr´ıticas de serem executadas ao mesmo tempo);

• Sincroniza¸c˜ao (permite que uma transmiss˜ao continue do ponto onde parou).

Aplicação Apresentação Sessão Transporte Rede Enlace de dados Física OSI 1 2 3 4 5 6 7

(4)

Modelo OSI

Camada de Apresenta¸c˜ao

Serve como o tradutor de dados para a rede: está ligada à semântica e à sintaxe das informa¸cões transmitidas.

• Gerencia estruturas de dados abstratas:

• Para que dois computadores possam se comunicar, as estruturas de dados a serem trocados podem ser definidas de maneira abstrata, com uma codifica¸cão padrão que será usada durante a conexão.

• E respons´´ avel pela compress˜ao e criptografia dos dados.

(5)

Modelo OSI

Camada de Aplica¸c˜ao

Engloba protocolos que realizam a comunica¸c˜ao fim-a-fim entre aplica¸c˜oes/processos de diferentes computadores.

• Contém muitos protocolos comumente necessários pelos usuários;

• Frequentemente nos referimos `as camadas de Sess˜ao,

Apresenta¸cão e Aplica¸cão simplesmente como Camada de Aplica¸cão:

• As fun¸c˜oes dessas trˆes

camadas s˜ao implementadas de modo bem integrado.

(6)

Aula 6 Prof. Daniel F. Pigatto Camada de Aplica¸cão Arq. das Aplica¸cões Processos em Comunica¸cão Protocolos da Camada de Aplica¸cão HTTP FTP Correio Eletrônico: SMTP, POP, IMAP DNS P2P Atividades Práticas Camada de Aplica¸cão /

Algumas aplica¸c˜

oes de rede

• E-mail;

• Web;

• Mensagens instantˆaneas;

• Login remoto;

• Compartilhamento de arquivos P2P;

• Jogos de rede multi-usu´arios;

• V´ıdeo-clipes;

• Voz sobre IP;

• Videoconferˆencia em tempo real;

• Computa¸c˜ao paralela em larga escala;

(7)

Criando uma aplica¸c˜

ao de rede

• Programas que executam em diferentes sistemas finais e comunicam-se através da rede. Ex.: servidor Web se comunica com o navegador; • Programas não relacionados ao núcleo da rede: • Dispositivos do núcleo da rede não executam aplica¸cões de usuários;

• Aplica¸cões nos sistemas finais permitem rápido desenvolvimento e dissemina¸cão.

(8)

Arquiteturas das aplica¸c˜

oes

• Cliente-servidor;

• Peer-to-peer (P2P);

(9)

Camada de Aplica¸c˜ao / Arquitetura das aplica¸c˜oes /

Arquitetura cliente-servidor

• Servidor: • Sempre ligado; • Endere¸co IP permanente; • Escalabilidade. • Cliente: • Comunica-se com o servidor; • Pode estar conectado intermitentemente;

• Pode ter endere¸cos IP dinˆamicos;

• N˜ao se comunica diretamente com outros clientes.

(10)

Camada de Aplica¸c˜ao / Arquiteturas das aplica¸c˜oes /

Arquitetura P2P pura

• Não há servidor sempre ligado; • Sistemas finais arbitrários se comunicam diretamente;

• Pares est˜ao conectados intermitentemente e mudam endere¸cos IP;

• Exemplo: Gnutella;

• Altamente escal´avel;

• Por´em, dif´ıcil de gerenciar.

(11)

Camada de Aplica¸c˜ao / Arquiteturas das aplica¸c˜oes /

Arquitetura h´ıbrida de cliente-servidor e P2P

• Napster:

• Transferˆencia de arquivos P2P;

• Busca de arquivos centralizada:

• Pares registram conte´udo no servidor central;

• Pares consultam o mesmo servidor central para localizar conte´udo.

• Instant messaging :

• Conversa entre usu´arios P2P;

• Localiza¸cão e deteçcão de presen¸ca centralizadas:

• Usu´arios registram o seu endere¸co IP junto ao servidor central quando ficam online;

• Usu´arios consultam o servidor central para encontrar endere¸cos IP dos contatos.

(12)

Processos em comunica¸c˜

ao

• Processo: programa que executa num hospedeiro

• Processos no mesmo hospedeiro se comunicam usando comunica¸c˜ao entre processos definida pelo sistema operacional (SO);

• Processos em hospedeiros distintos se comunicam trocando mensagens atrav´es da rede.

Processos

• Processo cliente: processo que inicia a comunica¸c˜ao;

• Processo servidor: processo que espera para ser contatado.

• Nota: aplica¸c˜oes com arquiteturas P2P possuem processos clientes e processos servidores.

(13)

Sockets

• Os processos enviam/recebem mensagens para/dos seus sockets;

• Um socket ´e an´alogo a uma porta:

• Processo transmissor envia a mensagem atrav´es da porta;

• O processo transmissor assume a existˆencia da

infraestrutura de transporte no outro lado da porta que faz com que a mensagem chegue ao socket do processo receptor.

(14)

Sockets

(15)

Endere¸cando os processos

• Para que um processo receba mensagens, ele deve possuir um identificador;

• Cada host possui um endere¸co IP ´unico de 32 bits;

• Pergunta: o endere¸co IP do host no qual o processo est´a sendo executado ´e suficiente para identificar o processo?

• Resposta: n˜ao, muitos processos podem estar executando no mesmo host;

• O identificador inclui tanto o endere¸co IP quanto os n´umeros das portas associadas com o processo no host.;

• Exemplo de n´umeros de portas:

• Servidor HTTP: 80;

(16)

Protocolos da camada de aplica¸c˜

ao

• Definem tipos de mensagens trocadas;

• Definem sintaxe dos tipos das mensagens: campos presentes nas mensagens e como s˜ao identificados;

• Definem semˆantica dos campos: significado da informa¸c˜ao nos campos;

• Definem regras para quando os processos enviam e respondem `as mensagens.

Protocolos da camada de aplica¸c˜ao • Protocolos de dom´ınio p´ublico:

• Definidos em RFCs;

• Permitem interopera¸c˜ao;

• Ex.: HTTP e SMTP.

• Protocolos propriet´arios:

(17)

Que servi¸co de transporte uma aplica¸c˜

ao precisa?

• Perda de dados:

• Algumas aplica¸c˜oes (Ex.: ´audio) podem tolerar algumas perdas;

• Outras (Ex.: transferência de arquivos, Telnet) requerem transferência 100% confiável.

• Temporiza¸c˜ao:

• Algumas aplica¸c˜oes (Ex.: jogos interativos) requerem baixo atraso para serem “vi´aveis”.

• Largura de banda:

• Algumas aplica¸c˜oes (Ex.: multim´ıdia) requerem quantia m´ınima de banda para serem “vi´aveis”;

• Outras aplica¸cões (“aplica¸cões elásticas”) conseguem usar qualquer quantia de banda dispon´ıvel.

(18)

Requisitos do servi¸co de transporte de apls comuns

Aplica¸cão Perdas Banda Sensibilidade temporal Transferência de arquivos Sem perdas Elástica Não

Correio Sem perdas Elástica Não Documentos WWW Sem perdas Elástica Não ´

Audio/v´ıdeo de tempo real Tolerante Audio: 5 kbps - 1 mbps´

V´ıdeo: 10 kbps - 5 mbps Sim, 100 ms ´

Audio/v´ıdeo gravado Tolerante Como o anterior Sim, alguns segundos Jogos interativos Tolerante >alguns kbps Sim, 100 ms Aplica¸cões financeiras Sem perdas Elástica Sim e não

(19)

Aplica¸c˜

oes Internet e seus protocolos

Aplica¸cão Protocolo de aplica¸cão Protocolo de transporte usado Correio eletrônico SMTP [RFC 2821] TCP

Acesso terminal remoto Telnet [RFC 854] TCP

WWW HTTP [RFC 2616] TCP

Transferˆencia de arquivos FTP [RFC 959] TCP Streaming multim´ıdia Propriet´ario (Ex.: RealNetworks) TCP ou UDP

(20)

Protocolo HTTP

• P´aginas Web consistem de objetos;

• Objeto pode ser um arquivo HTML, uma imagem JPEG, um applet Java, um arquivo de ´audio;

• P´aginas Web consistem de um arquivo HTML base que inclui v´arios objetos referenciados;

• Cada objeto ´e endere¸c´avel por uma URL;

• Exemplo de URL:

• www.someschool.edu/someDept/pic.gif

(21)

Protocolo HTTP

• HTTP – Hypertext Transfer Protocol

• Protocolo da camada de aplica¸c˜ao da Web;

• Modelo cliente/servidor.

• Cliente: browser que pede, recebe, “visualiza” objetos Web;

• Servidor: servidor Web envia objetos em resposta a pedidos.

• HTTP 1.0: RFC 1945;

(22)

Protocolo HTTP

(23)

Protocolo HTTP

• Usa servi¸co de transporte TCP:

• Cliente inicia conex˜ao TCP (cria socket) ao servidor, porta 80;

• Servidor aceita conex˜ao TCP do cliente;

• Mensagens HTTP (mensagens do protocolo da camada de aplica¸c˜ao) trocadas entre browser (cliente HTTP) e servidor Web (servidor HTTP);

• Encerra conex˜ao TCP.

• HTTP ´e “sem estado”:

• Servidor não mantém informa¸cão sobre pedidos anteriores do cliente.

Protocolos que mantêm “estado” são complexos! • História passada (estado) tem que ser guardada;

• Caso caia servidor/cliente, suas vis˜oes do “estado” podem ser inconsistentes, devem ser reconciliadas.

(24)

FTP: o protocolo de transferˆ

encia de arquivos

• Transferir arquivo de/para hospedeiro remoto;

• Modelo cliente/servidor:

• Cliente: lado que inicia transferˆencia (pode ser de ou para o sistema remoto);

• Servidor: hospedeiro remoto.

• FTP: RFC 959;

(25)

FTP: o protocolo de transferˆ

encia de arquivos

• Cliente FTP contata servidor FTP na porta 21, especificando o TCP como protocolo de transporte;

• O cliente obtém autoriza¸cão através da conexão de controle;

• O cliente consulta o diretório remoto enviando comandos através da conexão de controle;

• Quando o servidor recebe um comando para a

transferˆencia de um arquivo, ele abre uma conex˜ao de dados TCP para o cliente;

• Após a transmissão de um arquivo o servidor fecha a conexão.

(26)

FTP: o protocolo de transferˆ

encia de arquivos

• Servidor FTP mantém o “estado”: diretório atual, autentica¸cão anterior.

(27)

Correio Eletrˆ

onico

• Trˆes grandes componentes:

1 Agentes de usu´ario (UA); 2 Servidores de correio;

3 Simple Mail Transfer Protocol (SMTP).

• 1 – Agente de Usu´ario:

• Tamb´em conhecido como “leitor de correio”;

• Compor, editar, ler mensagens de correio;

• Ex.: Outlook, Thunderbird;

• Mensagens de sa´ıda e entrada s˜ao armazenadas no servidor.

(28)

Correio Eletrˆ

onico

• 2 – Servidores de correio:

• Caixa de correio contém mensagens de chegada (ainda não lidas) p/ usuário;

• Fila de mensagens cont´em mensagens de sa´ıda (a serem enviadas).

• 3 – Protocolo SMTP entre servidores de correio para transferir mensagens de correio:

• Cliente: servidor de correio que envia;

(29)

Correio Eletrˆ

onico

• SMTP

• Usa TCP para a transferˆencia confi´avel de mensagens do correio do cliente ao servidor, porta 25;

• Transferˆencia direta: servidor remetente ao servidor receptor;

• Trˆes fases da transferˆencia:

• Handshaking ;

• Transferˆencia das mensagens;

• Encerramento.

• Intera¸c˜ao comando/resposta:

• Comandos: texto ASCII;

(30)

Protocolos de acesso ao correio

• SMTP: faz entrega/armazenamento no servidor do receptor;

• Protocolo de acesso ao correio: recupera do servidor:

• POP: Post Office Protocol [RFC 1939]

• Autoriza¸c˜ao (agente – servidor) e transferˆencia.

• IMAP: Internet Mail Access Protocol [RFC 1730]

• Mais comandos (mais complexo);

• Manuseio de mensagens armazenadas no servidor.

• HTTP: Hypertext Transfer Protocol

(31)

DNS (Domain Name System)

• Pessoas possuem muitos identificadores:

• CPF, nome, RG.

• Hospedeiros, roteadores:

• Endere¸co IP (32 bits) – usado p/ endere¸car pacotes;

• _{“nome”, ex.: www.cs.vu.nl/~ast/ – usado por pessoas.}

(32)

DNS (Domain Name System)

• Domain Name System:

• Base de dados distribu´ıda implementada na hierarquia de muitos servidores de nomes;

• Protocolo de camada de aplica¸c˜ao permite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolver nomes (tradu¸c˜ao endere¸co/nome);

• Fun¸c˜ao imprescind´ıvel da Internet implementada como protocolo de camada de aplica¸c˜ao (complexidade na borda da rede);

• Roda sobre UDP e usa a porta 53;

(33)

DNS (Domain Name System)

• Servidor de nomes DNS:

• Por que n˜ao centralizar o DNS?

• Ponto ´unico de falha;

• Volume de tr´afego;

• Base de dados centralizada e distante;

• Manuten¸c˜ao da base de dados;

• Não é escalável;

• Nenhum servidor mant´em todos os mapeamentos nome-para-endere¸co IP.

(34)

DNS (Domain Name System)

• Servidor de nomes DNS:

• Servidor de nomes local:

• Cada provedor, empresa tem servidor de nomes local (default);

• Pedido DNS de hospedeiro vai primeiro ao servidor de nomes local;

• Quando n˜ao consegue resolver o nome, procura um servidor raiz.

• Servidor raiz:

• Procura servidor oficial se mapeamento for desconhecido;

• Obt´em tradu¸c˜ao;

(35)

DNS (Domain Name System)

• Exemplo de DNS: usuario.utfpr.edu.br requer o endere¸co IP de www.cs.columbia.edu 1 Contata servidor DNS local, dns.utfpr.edu.br; 2 dns.utfpr.edu.br contata servidor raiz, se necess´ario; 3 Servidor raiz contata

servidor oficial, cs.columbia.edu, se necess´ario.

(36)

Compartilhamento de arquivos P2P

Vamos analisar um exemplo:

1 Alice executa a aplica¸cão cliente P2P em seu computador; 2 Conecta-se à Internet, obtém um novo endere¸co IP para

cada conex˜ao;

3 Procura por uma m´usica;

4 A aplica¸c˜ao exibe outros pares que possuem uma c´opia da

m´usica;

5 Alice escolhe um dos pares, Bob;

6 O arquivo ´e copiado do PC de Bob para o PC de Alice por

HTTP;

7 Enquanto Alice faz o download, outros usu´arios copiam o

arquivo a partir do PC de Alice;

8 O par de Alice pode ser classificado tanto como um cliente

Web, quanto como um servidor Web transiente;

(37)

Camada de Aplica¸c˜ao / Compartilhamento de arquivos P2P /

Diret´

orio centralizado: Napster

• Projeto original “Napster”:

1 Quando um par se conecta, ele informa ao servidor central o seu endere¸co IP e conte´udo;

2 Alice procura pela m´usica; 3 Alice requisita o arquivo de Bob.

(38)

Diret´

orio centralizado: Napster

• Problemas do “Napster”:

• Ponto ´unico de falhas;

• Gargalo de desempenho;

• Infra¸c˜ao de copyright.

• Transferência de arquivo é descentralizada, mas a localiza¸cão de conteúdo é altamente centralizada.

(39)

Diret´

orio distribu´ıdo: Gnutella

• Totalmente distribu´ıdo;

• Sem servidor central;

• Protocolo de dom´ınio p´ublico;

(40)

Diret´

orio distribu´ıdo: Gnutella

• Mensagem de consulta ´e enviada pelas conex˜oes TCP existentes;

• Os pares encaminham a mensagem de consulta;

(41)

Explorando heterogeneidade: KaZaA

• Cada par ´e um l´ıder de grupo ou est´a atribu´ıdo a um l´ıder de grupo:

• Conex˜ao TCP entre o par e seu l´ıder de grupo;

• Conex˜oes TCP entre alguns pares de l´ıderes de grupo.

• O l´ıder de grupo acompanha o conte´udo em todos os seus “disc´ıpulos”.

(42)

Explorando heterogeneidade: KaZaA

• Cada arquivo possui um hash e um descritor;

• O cliente envia a consulta de palavra-chave para o seu l´ıder de grupo;

• O l´ıder de grupo responde com os encontros:

• Para cada encontro: metadata, hash, endere¸co IP.

• Se o l´ıder de grupo encaminha a consulta para outros l´ıderes de grupo, eles respondem com os encontros;

• O cliente ent˜ao seleciona os arquivos para download:

• Requisi¸cões HTTP usando hash como identificador são enviadas aos pares que contêm o arquivo desejado.

(43)