2: Application Layer 1 Redes de Computadores DCC/UFJ Capítulo 2 – Camada de Aplicação Material...

2: Application Layer 1

Redes de ComputadoresDCC/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-2009J.F Kurose and K.W. Ross, All Rights Reserved


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


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


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


Criando uma aplicação de Rede

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

transportnetworkdata linkphysical

application


application





SMTP, POP3, IMAP

2.5 DNS



Sockets com UDP


Arquiteturas das Aplicações de Redes

Cliente-Servidor Peer-to-peer (P2P) Híbrida: cliente-servidor e P2P


Arquitetura Cliente-Servidorservidor:

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


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


Arquiteturas HíbridasSkype

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


Comunicação entre processosProcessos : 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

Processo Cliente: processo que inicia a comunicação

Processo Servidor: processo que espera para ser contactado

Aplicações com arquitetura P2P possuem processo cliente e processo servidor


Sockets

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

process

TCP withbuffers,variables

socket

host orserver

process

TCP withbuffers,variables

socket

host orserver

Internet

controlledby OS

controlled byapp developer

API: (1) escolha do protocolo de transporte; (2) habilidade para definir alguns parâmetros


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


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, SMTPProtocolos

proprietários: e.g., Skype


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

Atraso Algumas apl. (e.g.,

VoIP, jogos interativos) requerem baixo atraso para serem “eficazes”

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, …


Requisições que as aplicações fazem a camada de Transporte

Application

file transfere-mail

Web documentsreal-time audio/video

stored audio/videointeractive gamesinstant messaging

Data loss

no lossno lossno lossloss-tolerant

loss-tolerantloss-tolerantno loss

Throughput

elasticelasticelasticaudio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as above few kbps upelastic

Time Sensitive

nononoyes, 100’s msec

yes, few secsyes, 100’s msecyes and no


Serviços da camada de transporteServiç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?


Aplicações na Internet: aplicação e protocolos de transporte

Aplicação

e-mailacesso a terminal remoto

Web transferência de arquivos

streaming multimedia

telefonia Internet

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

TCPTCPTCPTCPTCP or UDP

tipicamente UDP




SMTP, POP3, IMAP

2.5 DNS



Sockets com UDP


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


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

PC runningExplorer

Server running

Apache Webserver

Mac runningNavigator

HTTP request

HTTP request

HTTP response

HTTP response


HTTP (cont.)

Usa TCP: 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

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

Nota


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


HTTP Não persistenteURL 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

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

1b. Servidor HTTP em www.someSchool.edu está esperando uma conexão TCP na porta 80. “aceita” a conexão, notificando o cliente

3. Servidor HTTP recebe a mensagem de requisição, monta a mensagem de reposta contendo o objeto e envia ao socket

tempo

(contem texto, referências a 10 imagens jpeg


HTTP Não Persistente (cont.)

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

6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg

4. Servidor HTTP fecha a conexão TCP

time


HTTP Não Persistente: Tempo de RespostaDefiniçã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 TCPconnection

RTT

requestfile

RTT

filereceived

time time


HTTP Persistente

Problemas do HTTP não 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


HTTP - Mensagem de requisição

Dois tipos de mensagens : requisição, reposta Mensagem de requisição HTTP:

ASCII

GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

Linha de requisição(comandos GET, POST,

HEAD)

Linhas do cabeçalho

Enter significa fim da mensagem


Requisições HTTP : formato geral


Tipos de Métodos

HTTP/1.0 GET POST HEAD

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


HTTP – Mensagem de Reposta

HTTP/1.1 200 OK Connection closeDate: 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 ...

Linha de status(código do protocolo)

Linhas do cabeçalho

dados, e.g., Arquivo HTML requisitado


Códigos de Status -> Respostas HTTP

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

Na primeira linha da mensagem entre servidor->cliente.

Alguns exemplos de código:


Caches Web (servidores proxy)

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

Objetivo: responder a requisição do cliente sem enviá-la ao servidor

client

Proxyserver

client

HTTP request

HTTP response

HTTP request HTTP request

origin server

origin server

HTTP response HTTP response


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 1 Redes de Computadores DCC/UFJ Capítulo 2 – Camada de Aplicação Material...

Documents

Transcript of 2: Application Layer 1 Redes de Computadores DCC/UFJ Capítulo 2 – Camada de Aplicação Material...