7
1 Redes de Comunicação - Camada de Aplicação - Prof. Juliano F. Kazienko Juliano F. Kazienko [email protected] 2 Agenda Arquiteturas de aplicação Comunicação entre processos Protocolos da camada de aplicação – P2P – HTTP – SMTP – DNS Juliano F. Kazienko [email protected] 3 Arquiteturas de Aplicação • Cliente-Servidor Peer-to-Peer (P2P) Arquiteturas híbridas • Métricas – Tolerância a falhas – Escalabilidade, etc. Cliente Servidor Realiza consulta Resultado Servidor Web com acesso a Banco de Dados Juliano F. Kazienko [email protected] 4 Cliente-Servidor Servidor sempre ligado com IP conhecido – Escalabilidade Ex.: aplicação Web P2P Não há servidor sempre ligado Pares com conexão intermitente IPs variáveis por conexão O par pode ser cliente e servidor Participantes compartilham recursos de hardware próprios como memória, poder de processamento, capacidade de armazena mento, banda de rede, etc. Segurança e incentivos (usuários participativos) Ex.: Telefonia por Internet, Compartilhamento de arquivos na Internet (Gnutella) Arquiteturas de Aplicação Juliano F. Kazienko [email protected] 5 Arquiteturas de Aplicação Arquiteturas híbridas – P2P – Cliente-servidor "Uma arquitetura de rede distribuída deve ser classificada como P2P 'híbrida' se em primeiro lugar for P2P conforme a primeira definição e em segundo lugar tiver a necessidade de uma entidade central para prover parte dos serviços da rede." "Uma arquitetura de rede distribuída pode ser classificada como P2P 'pura', se em primeiro lugar for P2P conforme a definição anterior e em segundo lugar se qualquer entidade terminal da rede puder ser individualmente removida sem que a rede sofra qualquer perda em termos de 'serviço'." "Uma rede cliente-servidor possui uma arquitetura distribuída com um sistema de alta performace , o servidor, e vários clientes , de menor performace . O servidor é uma unidade central de registro e também o único provedor de serviço e conteúdo. Um cliente somente faz requisições de conteúdo ou execução de serviços ao servidor, sem compartilhar nenhum de seus próprios recursos." [Schollmeier, 2001] [Schollmeier, 2001] [Schollmeier, 2001] Juliano F. Kazienko [email protected] 6 Comunicação entre Processos Programas são processos (SO) que se comunicam Processo Cliente Inicia a comunicação. Ex: navegador Processo Servidor Espera ser contatado para iniciar a sessão • Sockets Identificação de uma comunicação entre processos (conexão TCP)

redes

Embed Size (px)

Citation preview

1

Redes de Comunicação- Camada de Aplicação -

Prof. Juliano F. Kazienko

Juliano F. [email protected] 2

Agenda

• Arquiteturas de aplicação• Comunicação entre processos• Protocolos da camada de aplicação

– P2P– HTTP– SMTP– DNS

Juliano F. [email protected] 3

Arquiteturas de Aplicação• Cliente-Servidor• Peer-to-Peer (P2P)• Arquiteturas híbridas• Métricas

– Tolerância a falhas– Escalabilidade, etc.

Cliente

Servidor

Realiza consulta

Resultado

Servidor Web com acesso a Banco de

Dados

Juliano F. [email protected] 4

• Cliente-Servidor– Servidor sempre ligado com IP conhecido– Escalabilidade– Ex.: aplicação Web

• P2P– Não há servidor sempre ligado– Pares com conexão intermitente– IPs variáveis por conexão– O par pode ser cliente e servidor– Participantes compartilham recursos de hardware próprios como

memória, poder de processamento, capacidade de armazena mento, banda de rede, etc.

– Segurança e incentivos (usuários participativos)– Ex.: Telefonia por Internet, Compartilhamento de arquivos na

Internet (Gnutella)

Arquiteturas de Aplicação

Juliano F. [email protected] 5

Arquiteturas de Aplicação

• Arquiteturas híbridas– P2P– Cliente-servidor

"Uma arquitetura de rede distribuída deve ser

classificada como P2P 'híbrida' se em primeirolugar for P2P conforme a primeira definição e

em segundo lugar tiver a necessidade de umaentidade central para prover parte dos serviços

da rede."

"Uma arquitetura de rede distribuída pode

ser classificada como P2P 'pura', se emprimeiro lugar for P2P conforme a definição anterior e em segundo lugar se

qualquer entidade terminal da rede puderser individualmente removida sem que a

rede sofra qualquer perda em termos de 'serviço'."

"Uma rede cliente-servidor possui uma

arquitetura distribuída com um sistemade alta performace , o servidor, e vários

clientes , de menor performace . O servidor é uma unidade central de registro e também o único provedor de

serviço e conteúdo. Um cliente somentefaz requisições de conteúdo ou

execução de serviços ao servidor, semcompartilhar nenhum de seus próprios

recursos."

[Schollmeier, 2001]

[Schollmeier, 2001]

[Schollmeier, 2001]

Juliano F. [email protected] 6

Comunicação entre Processos

• Programas são processos (SO) que se comunicam

• Processo Cliente– Inicia a comunicação. Ex: navegador

• Processo Servidor– Espera ser contatado para iniciar a sessão

• Sockets• Identificação de uma comunicação entre

processos (conexão TCP)

2

Juliano F. [email protected] 7

Comunicação entre Processos

Adaptado de [Kurose and Ross, 2010]

processo

TCP com

buffers,

variáveis

socket

Host:

Processo

Cliente

processo

TCP com

buffers,

variáveis

socket

Host:

Processo

Servidor

Internet

controlado

pelo SO

controlado pelo

desenvolvedor da

aplicação

Juliano F. [email protected] 8

SYN Flooding

SYN

SYN-ACK

ACK

SYN

SYN-ACK

SYN

Atacante Servidor

Servidor

Usuário

Usuário

Usuário

Servidor

Servidor

Usuário?

?

ServidorX

(a) Conexão Cliente-Servidor Nomal (b) Conexão com SYN Flooding

Juliano F. [email protected] 9

Programando com Sockets

• Um fluxo (stream) é uma sequência de caracteres que fluem de/ou para um processo.– Um fluxo de entrada é conectado a alguma

fonte de entrada para o processo, por exemplo, teclado ou socket.

– Um fluxo de saída é conectado a uma fonte de saída, por exemplo, um monitor ou um socket

• Programação de aplicações com o TCPJuliano F. Kazienko

[email protected] 10

Cliente Java (TCP)import java.io.*; import java.net.*;

class ClienteTCP {

public static void main(String argv[]) throws Exception {

String frase; String fraseModificada;

BufferedReader doUsuario = new BufferedReader(new InputStreamReader(System.in));

Socket socketCliente = new Socket(”localhost", 6789);

DataOutputStream paraServidor = new DataOutputStream(socketCliente.getOutputStream());

Criafluxo de entrada

do tecladoCria

socket de cliente, conexão ao servidor

Criafluxo de saída

ligado ao socket

Juliano F. [email protected] 11

Cliente Java (TCP)

BufferedReader doServidor = new BufferedReader(newInputStreamReader(socketCliente.getInputStream()));

frase = doUsuario.readLine();

paraServidor.writeBytes(frase + '\n');

fraseModificada = doServidor.readLine();

System.out.println(”Do Servidor: " + fraseModificada);

socketCliente.close();

} }

Criafluxo de entradaligado ao socket

Envia linhaao servidor

Lê linhado servidor

Método bloqueante: fica parado esperando

msg do servidor

Juliano F. [email protected] 12

Servidor Java (TCP)import java.io.*; import java.net.*;

class ServidorTCP {

public static void main(String argv[ ]) throws Exception {

String fraseCliente; Stringf fraseMaiusculas;

ServerSocket socketRecepcao = new ServerSocket(6789);

while(true) {

Socket socketConexao = socketRecepcao.accept();

BufferedReader doCliente = new BufferedReader(newInputStreamReader(socketConexao.getInputStream()));

Cria socketpara recepçãona porta 6789

Aguarda, no socketpara recepção, o

contato do cliente

Cria fluxo deentrada, ligado

ao socket

Método bloqueante: fica parado esperando

msg do cliente

3

Juliano F. [email protected] 13

Servidor Java (TCP)

DataOutputStream paraCliente = new DataOutputStream(socketConexao.getOutputStream());

fraseCliente= doCliente.readLine();

fraseMaiusculas= fraseCliente.toUpperCase() + '\n';

paraCliente.writeBytes(fraseMaiusculas); }

} }

Lê linhado socket

Cria fluxode saída, ligado

ao socket

Escreve linhaao socket

Final do laço while,volta ao início e aguardaconexão de outro cliente

Juliano F. [email protected] 14

Protocolos

• Definem tipos de msgs trocadas. Ex.: req./resp.• Campos das msgs e suas sintaxes• Protocolos de domínio público

– HTTP [RFC 1945] [RFC 2616]– DNS [RFC 1034]– SMTP [RFC 5321], etc.

• Protocolos proprietários– KazaA– Skype

Juliano F. [email protected] 15

Protocolo

Oi

Oi

Horas?

15:30

TCP connectionreq.

TCP connectionreply.

<arquivo>

t

Alice

Bob

Get http://www.google.com

Cliente

Servidor

t t t

Juliano F. [email protected] 16

Serviço/Aplicação/Protocolo

Serviços

correio eletrônicoacesso terminal remoto

WWW transferência de arquivosMultimídia em tempo real

telefonia Internet

Protocolo da camada de aplic.

SMTP [RFC 5321]telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]HTTP (ex.: Youtube)RTPproprietário(ex: Skype)

Protocolo de transporte usado

TCPTCPTCPTCPTCP ou UDP

tipicamente UDP

Adaptado de [Kurose and Ross, 2010]

Juliano F. [email protected] 17

HTTP• Protocolo de Transferência de Hipertexto• Define a estrutura das msgs trocadas entre

cliente e servidor• Cliente universal: navegador Web• Página Web é formada por objetos

– Arquivo HTML– Imagens. Ex.: JPEG, GIF.

• URL– Cada objeto é endereçável por um URL– http://www.unipampa.edu.br/alegrete/logo.gif

nome do hospedeiro nome do caminhoJuliano F. Kazienko

[email protected] 18

HTTP: Interação Cliente/Serv.• Modelo cliente/servidor

– Cliente: Browser que pede, recebe, “visualiza”objetos Web através

– Servidor: servidor Web envia objetos em resposta a pedidos

• O HTTP é um protocolo sem estado– não mantém informação

sobre clientes e suas requisições. Por isso édenominado assim

WindowsInternet Explorer

Máquina Servidora

executandoApache

Linux executaFirefox

pedido http

pedido http

resposta http

resposta http

Adaptado de [Kurose and Ross, 2010]

4

Juliano F. [email protected] 19

Conexões HTTP• HTTP não persistente

– No máximo um objeto é enviado numa conexão TCP

– HTTP 1.0 usa o HTTP não persistente

• HTTP persistente– Múltiplos objetos podem ser enviados sobre

uma única conexão TCP entre cliente e servidor

– HTTP 1.1 usa conexões persistentes por padrão

– Uso de CookiesJuliano F. Kazienko

[email protected] 20

Formato de Mensagem HTTP• Dois tipos de mensagem HTTP:

– Pedido

– Resposta

• mensagem de pedido HTTP (ASCII)

GET /somedir/page.html HTTP/1.0

Host: www.someschool.edu

User-agent: Mozilla/4.0

Connection: close

Accept-language:fr

linha do pedido(comandos GET,

POST, HEAD)

linhas docabeçalho

Juliano F. [email protected] 21

Mensagem de pedido HTTP: formato geral

Fica vazio com o método GET, mas povoado com o método POST. Ex: Preenchimento de formulário ou campos em um site de busca.

Juliano F. [email protected] 22

Tipos de métodos

• GET, PUT, POST, etc.• PUT realiza o upload de arquivo contido

no corpo da mensagem para o caminho especificado no campo URL

• POST passa dados preenchidos na página para o servidor

• DELETE Exclui arquivo especificado no campo URL

Juliano F. [email protected] 23

Cookies

• Arquivos pequenos gravados no cliente• Contém informações sobre as sessões do

navegador• Uso de cookies (RFC 2965)

– Manutenção da persistência da sessões HTTP– Viabiliza sessão de usuário sobre HTTP sem estado – Restrição de acesso– Identificação do usuário / conteúdo– Ex.: Comércio eletrônico, Internet Banking, Redes

sociais, etc.

Juliano F. [email protected] 24

Mantendo o Estado da Conexão com Cookies

• Tecnologia com quatro componentes– Linha de cabeçalho de cookie na msg. de

resposta HTTP– Linha de cabeçalho de cookie na msg. de

pedido HTTP– Arquivo de cookie mantido no sistema final do

usuário e gerenciado pelo navegador do usuário

– BD de apoio no site WEB

5

Juliano F. [email protected] 25

Estado da Conexão: Cookiescliente servidor

msg usual pedido http

resposta usual http +Set-cookie: 1678

msg usual pedido httpcookie: 1678

resposta usual http

msg usual pedido httpcookie: 1678

resposta usual http

ação específicado cookie

açãoespecíficado cookie

servidorcria a ID 1678 para o usuário

entrada no BD

de apoio

acesso

acesso

arquivo deCookies

amazon: 1678ebay: 8734

arquivo deCookies

ebay: 8734

arquivo deCookies

amazon: 1678ebay: 8734

uma semana depois:

t tAdaptado de [Kurose and Ross, 2010]

Juliano F. [email protected] 26

Caches Web

• Cache Web ou Servidor Proxy

• Atende requisições HTTP em nome de um servidor Web de origem

• Motivação– Redução do tempo de resposta (desempenho)– Redução do tráfego em uma instituição

• Instalado por ISPs, universidades, etc.

Juliano F. [email protected] 27

Proxy: Funcionamento

Navegadores apontam para o servidor proxy

É cliente e servidor

Juliano F. [email protected] 28

Cache InstitucionalServidoresde origem

Internet

rede dainstituição

LAN 10 Mbps

enlace de acesso 1,5 Mbps

cacheinstitucional

[Kurose and Ross, 2010]

Juliano F. [email protected] 29

Correio Eletrônico

• Componentes– Agentes de usuário– Servidores de correio

• Caixa de correio (chegada)• Fila de mensagens (saída)

– Simple Mail Transfer Potocol - SMTP [RFC 5321]

• SMTP– Transfere mensagens– Servidor de correio remetente– Servidor de correio destinatário

• POP3 e IMAP

Juliano F. [email protected] 30

SMTP

• Porta 25• Utiliza TCP para a transferência confiável

de msgs. do correio do cliente ao servidor• Transferência direta

– Servidor remetente ao servidor receptor

• Fases da transferência– Handshaking (cumprimento)– Transferência das mensagens– Encerramento

6

Juliano F. [email protected] 31

Protocolos de Acesso ao Correio

• SMTP – entrega/armazenamento no servidor do receptor

• Protocolos de acesso ao correio– POP– IMAP– HTTP

servidor de correio do remetente

SMTP SMTP POP3 ouIMAP

servidor de correiodo receptor

agente de

usuário

agente de

usuárioAlice Bob

Juliano F. [email protected] 32

Protocolos de Acesso

• POP (porta 110)– Post Office Protocol [RFC 1939]– Mensagens são baixadas no cliente– E se Bob mudar de cliente?

• IMAP (porta 143)– Internet Mail Access Protocol [RFC 1730]– Mensagens são armazenadas no servidor

• Suporta operação on-line e off-line

• Cliente pode armazenar cópias locais temporárias

– Permite organização das msgs em pastas• HTTP (Hotmail, Yahoo, Google, etc.)

Bob não poderáreler as

mensagens

Juliano F. [email protected] 33

Domain Name System (DNS)

• Sistema de Nomes de Domínio– BD distribuído e hierárquico (Servs. DNS)– Protocolo p/ consulta ao BD distribuído

• Traduz – Nomes -> endereços IP– Endereços IP -> Nomes (DNS Reverso)

• Ex.: Uso indevido de domínio para envio de spams

• Usado por HTTP, SMTP, FTP• Mais atraso...

Entidade registradora

Juliano F. [email protected] 34

Serviços Providos

• Tradução de nomes• Apelidos

– moita.unipampa.edu.br

– www.unipampa.edu.br, www.unipampa.edu.br

• Distribuição de carga– Servidores Web replicados– Conjunto de IPs associados a um mesmo nome

canônico– Balanceamento de carga– Tolerância a falhas– Ex.: DNS Round Robin (rodízio)

nome canônico

Juliano F. [email protected] 35

Abordagem Centralizada

• Problemas–Ponto único de falha–Volume de tráfego

–BD centralizado distante–Manutenção

Não é usada pelo DNS

Juliano F. [email protected] 36

Abordagem Distribuída

• Nenhum servidor de nomes tem todos mapeamentos para todos os hospedeiros da Internet

• Tipos de servidores DNS– SN Raiz: 13 servidores– SN de Alto Nível (TLD): .com .org .edu .gov e .uk .br– SN com autoridade: empresas que possuem

hospedeiros acessados publicamente. Ex: amazon.com– SN Local: ISPs, universidade, depto. acadêmico,

residencial (pode estar na mesma LAN)

7

Juliano F. [email protected] 37

Interação entre Servidores

• O host cis.poly.edu quer obter o IP de gaia.cs.umass.edu

• As 8 msgs de consulta podem ser reduzidas

• Cache DNS

[Kurose and Ross, 2010]

Juliano F. [email protected] 38

Mensagens DNS• Consulta e Resposta• SNs armazenam Registros de Recursos

(RR)• Sintaxe (Name, Value, Type, TTL)• Ex.: O servidor TLD edu não sabe como

obter um endereço IP– Passo 5– (umass.edu, dns.umass.edu, NS)– (dns.umass.edu, 128.119.40.111, A)

Domínio

Nome do servidor de nomes com autoridade que sabe

obter o IP p/ o domínio

Nome de Hospedeiro

Endereço IP para o Nome de Hospedeiro