Infraestrutura de Comunicação (Camada de Aplicação)

Prévia do material em texto

Estudo InfraCom - Módulo 2: Camada de Aplicação 
 
2.1. Princípios das aplicações de rede 
 
Email, web, instant messaging (im), login remoto, compartilhamento de arquivos (p2p), 
jogos multi-usuários em rede, streaming, telefonia, videoconferência (e.g meets), 
computação paralela massiva, etc. 
 
Criando aplicações de rede 
 
● Programas que 
 
- executam em diferentes end systems; 
- Se comuniquem através das redes; 
- ex: software do servidor web se comunica via software do browser. 
 
● Poucos softwares para dispositivos dentro do núcleo da rede 
 
- Os dispositivos do núcleo não executam códigos de aplicação do usuário; 
- Aplicações nos end systems permitem desenvolvimento e disseminação 
rápidos. 
Arquiteturas 
 
Cliente => Servidor 
 
Servidor: 
 
● Host sempre online; 
● Endereço de IP permanente; 
● Múltiplos servidores; 
 
Clientes: 
 
● Comunicação com o servidor; 
● Nem sempre estão online; 
● IPs podem ser dinâmicos; 
● Não se comunicam diretamente entre si. 
 
P2P pura 
 
● Não existe servidor sempre online; 
● End systems arbitrários com comunicação direta entre si; 
● Peers conectados intermitentemente e mudam de IP; 
● Altamente escalável mas difícil de gerenciar. 
 
Híbrido: Cliente-Servidor e P2P 
 
Skype: 
 
● Telefonia via internet; 
● Obtém o endereço remoto (servidores centralizados); 
● Conexão direta entre clientes sem mediação dos servidores. 
 
Instant Messaging (IM): 
 
● Chatting P2P; 
● presença/localização centralizada: quando online, IP é registrado no servidor, e o 
usuário contacta o servidor central para encontrar IP dos coleguinhas; 
● Exemplo: whatsapp. Mensagem instantânea é cliente-servidor e, por suposição, 
ligação é híbrido p2p. 
 
Comunicação entre processos 
 
Processo é um programa que é executado em um host. Nele, dois processos se comunicam 
via API de comunicação de processos (definida pelo SO). Processos em hosts diferentes 
tem comunicação via mensagens. O processo cliente inicia comunicação, enquanto o 
servidor aguarda comunicação 
Sockets 
 
● Processo envia/recebe mensagens para/de sockets; 
● Socket é a interface entre o processo da aplicação e o protocolo de camada de 
transporte; 
● Podemos pensar em sockets como uma porta. Processo emissor manda pra fora da 
porta, dependendo da infra de transporte, que levará a mensagem para o socket do 
processo receptor; 
 
 
 
Endereçamento de processos 
 
 Os processos precisam de identificadores. Então, apenas com o endereço de IP do 
host, talvez não seja possível identificar o processo, pois podem ter vários processos em 
execução nesse IP. Precisamos tanto do endereço de IP quanto do número da porta 
associado ao processo no host; 
 
Exemplos de portas: 
 
● http: 80; 
● Email: 25; 
● Enviar mensagem http para servidor web cin.ufpe.br: IP 172.21.0.3, porta 80. 
 
Protocolos da camada de aplicação definem… 
 
● Tipos de mensagem trocadas, e.g request, response; 
● Sintaxe da mensagem: como a mensagem é apresentada, desde composição à 
campos delineados; 
● Semântica da mensagem; 
● Quando e como processos enviam e respondem; 
● Protocolos públicos: documentados em RFCs (request for comment), 
interoperabilidade, e.g http, smtp; 
● Protocolos proprietários: e.g kazaa. 
Que tipo de serviço de transporte uma aplicação precisa? 
 
● Em se tratando de perda de dados, algumas aplicações toleram perdas, e outros 
exigem 100% de confiança no transporte de dados; 
● Já falando de prazo de entrega, algumas aplicações exigem baixo atraso; 
● E sobre banda passante, algumas aplicações exigem uma quantidade mínima de 
banda passante para ser executada (e.g youtube), enquanto outras usam qualquer 
banda que conseguirem (elástica). 
 
Serviços de transporte 
 
● TCP: 
- Orientado à conexão (requer cliente => servidor); 
- Transporte confiável; 
- Controle de fluxo e congestionamento (não gera filas, emissor só manda o 
que receptor pode receber, limita o emissor se a rede estiver 
congestionada); 
- Não provê prazo de entrega, mínima banda passante. 
● UDP: 
- Transferência não confiável porém segura (seguro != confiável); 
- Não provê conexão, confiabilidade, controle de fluxo e congestionamento, 
entrega de prazo nem garantia de banda passante; 
 
 
 
 
 
2.2. Web e HTTP 
 
Breve introdução 
 
● Página web contém objetos, que podem ser arquivos html jpeg, applets, java, 
áudios, vídeos, etc; 
● Página web é feita de um html base que inclui diversos objetos referenciados, que 
são endereçados por url’s no formato host/caminho. 
HTTP (hypertext transfer protocol) 
 
● Protocolo da camada de aplicação da web; 
● Cliente => servidor: browser (cliente) requisita, recebe e mostra objetos web, 
servidor envia objetos e responde requisições; 
● HTTP 1.0: RFC 1945, HTTP 1.1: RFC 2068; 
 
 
● Usa TCP: 
- Cliente => Servidor (via socket, porta 80); 
- Servidor aceita; 
- Mensagens HTTP trocadas entre browser e servidor; 
- Conexão encerrada. 
 
● HTTP é stateless e não guarda log de requisições passadas; 
● Existem alguns que guardam logs, mas são complexos. Caso dê algum erro, a visão 
de estado pode diferir entre cliente e servidor. 
 
Conexões HTTP 
 
● HTTP não persistente 
 
- Um objeto por vez via uma única conexão TCP; 
- Usado pelo HTTP 1.0: RFC 1945. 
- 1a) Cliente inicia conexão TCP ao servidor (e.g someschool.edu); 
1b) O servidor aguarda conexão na porta 80, aceita e notifica; 
2) Cliente envia requisição com URL pelo socket TCP com o objeto que o 
cliente quer (e.g somedepartment/home.index); 
3) Servidor recebe, constrói uma resposta com a requisição solicitada e envia 
pelo seu socket, 4) encerrando a conexão TCP após finalização; 
5) Cliente recebe resposta em html, mostra pro tradutor, que encontra uma 
quantidade x de objetivos referenciados; 
6) passos 1 a 5 se repetem x vezes; 
- Tempo de resposta (em RTT, ida e volta de um pequeno pacote): 1 para 
iniciar conexão, +1 para requisição http e primeiros bytes de resposta + 
tempo de transmissão do arquivo = 2RTT + tempo de transmissão do 
arquivo. 
 
● Problemas do HTTP não persistente 
 
- 2RTTS por objeto; 
- Overhead no SO em cada conexão TCP; 
- Browsers comumente abrem conexões TCP paralelas para buscar os objetos 
referenciados. 
 
 
● HTTP persistente 
 
- Múltiplos por vez via uma única conexão TCP; 
- Usado pelo HTTP 1.1: RFC 2068; 
- Servidor mantém conexão aberta após resposta; 
- Mensagens HTTP subsequentes cliente/servidor; 
- Sem pipeline: 
a) Cliente envia nova requisição quando a anterior já tiver sido recebida; 
b) 1 RTT por cada objeto referenciado. 
- Com pipeline: 
a) Padrão HTTP 1.1; 
b) Envio de requisição tão rápido quanto encontro de objetos; 
c) Velocidade média perto dos 1 RTT para todos os objetos 
referenciados. 
 
Mensagem de Requisição HTTP 
 
● request/response; 
● ASCII (modernidade tende a mudar isso para binário, pois são menos bits 
transmitidos, economizando assim banda passante). 
 
 
 
 
 
 
Método GET 
 
● Precisa ser seguro. Não pode gerar mudança de dados do servidor; 
● Precisa ser idempotente (n x n = n). Múltiplas requisições devem gerar o mesmo 
resultado de uma só, com algumas exceções (e.g blogs). A intenção é que pessoas 
distintas tenham acesso às mesmas informações. 
 
Método POST: Fazendo upload de conteúdo 
 
● Página web normalmente com forms (e.g google); 
● Conteúdo no “entity body”. 
 
Método URL 
 
● Usa GET; 
● Conteúdo do form é submetido no campo url da linha de requisição 
 
Tipos de Métodos 
 
HTTP/1.0 
 
● GET, POST; 
● HEAD: resposta normal mas o objeto requisitado não está na resposta enviada; 
 
HTTP/1.1 
 
● GET, POST, HEAD; 
● PUT: faz upload de arquivo no entity body para caminho especificado na url; 
● DELETE: especifica e deleta arquivo no campo url. 
 
O que esperar da resposta? 
 
 
 
Respostas comuns 
 
● 200 OK: bem sucedido, pacote será enviado; 
● 301 Moved Permanently: objeto movido, nova localização a seguir (location:); 
● 400 Bad Request: mensagem não compreendida;● 404 Not Found: documento não encontrado; 
● 505 HTTP Version Not Supported; 
● 1xx: informação; 
● 2xx: sucesso; 
● 3xx: redirecionamento; 
● 4xx: erro do cliente; 
● 5xx: erro do servidor. 
 
Estado usuario-servidor: cookies 
 
● Cabeçalho relacionado ao cookie nas mensagens de resposta e requisição HTTP; 
● Arquivo cookie mantido no computador do usuário e gerenciado pelo browser. Uma 
vez a comunicação estabelecida, o site (servidor) cria um cookie (ID) específico para 
o usuário, que fica armazenado e já é apresentado em uma nova conexão futura 
deste usuário. O site pode executar uma ação específica mediante ao cookie 
recebido; 
 
Para que servem cookies? 
 
● Uso de cookies: autorização, carrinho de compras, recomendações/preferências, 
estado da sessão do usuário, etc; 
● Cookies e privacidade (à parte, curiosidade): permitem que sites aprendam sobre 
você; você pode fornecer nome e email para os sites; ferramentas de busca usam 
redirecionamento e cookies para aprendizado; empresas de publicidade podem 
obter informações dos usuários através de sites. 
 
Web caches (servidor proxy) 
 
● O servidor proxy (by proxy) age em nome de alguém/algum outro servidor; 
● Web caches são memórias que guardam os objetos, respostas e informações; 
● O objetivo seria satisfazer a requisição do cliente sem envolver o servidor de origem; 
● Usuário no browser seta acesso web via proxy => browser envia todas as 
requisições HTTP para o proxy => proxy retorna objeto do cache, senão proxy 
requisita objeto do servidor origem e em seguida retorna o objeto ao cliente; 
● Proxy atua como servidor e cliente e é tipicamente instalado como ISP; 
● Benefícios do web caching: reduzir tempo de resposta ao cliente, redução de tráfego 
no enlace de acesso e economia de banda passante, além de servidores “pobres” 
com possibilidade de entregar conteúdo mais efetivamente; 
 
 
 
 
 
Exercício: Instalação de cache local 
 
Com os seguintes dados, calcule a) utilização do enlace de acesso e b) o atraso total. 
 
1) Tam. Médio objeto: 100K bits; 
2) Taxa média de requisição dos browsers para os servidores externos:15/segundo; 
3) Taxa média de dados para os browsers: 1,50 Mbps; 
4) RTT do roteador de saída para Internet para qualquer servidor externo: 2 segundos; 
5) BW do enlace de acesso: 1,51 Mbps. 
6) Supondo uma taxa de acerto de 40% (40% das requisições satisfeitas pelo cache, 
60% pelos servidores externos) 
 
R: 
 
a) calculando a taxa de dados para o browser: utilização de servidores externos x taxa 
média de dados para os browsers = 0,6 x 1,51 = 0,9 mbps. Utilização = 0,9/1,51 = 
0,59; 
b) 0,6 x (atraso dos servidores externos para rede) + 0,4 (atraso de requisições 
satisfeitas pelo cache, mínimo) = 0,6 x 2 + 0,4 x msecs (número muito pequeno pra 
fazer qualquer diferença) = 1,2s 
 
 
GET Condicional 
 
● Objetivo é não enviar o objeto caso o cache seja uma versão atualizada; 
● Proxy (cache) especifica data, e a resposta do servidor é vazia se o proxy estiver em 
dia. 
 
2.3. FTP 
 
Protocolo de Transferência de Arquivo 
 
● Transferência de arquivo do ou para host remoto; 
● Cliente => servidor; 
● RFC 959; 
● Servidor FTP: porta 21. 
 
Controle de Dados separados por conexões distintas 
 
● Cliente especifica o TCP para o servidor na porta 21; 
● Cliente obtém autorização; 
● Cliente navega pelo diretório remoto via envio de comandos da conexão de controle; 
● Servidor recebe comando para transferência de arquivo e abre conexão TCP de 
dados com cliente; 
● Após transferência, servidor fecha conexão, mas abre uma segunda, TCP de dados 
(porta 20), para mandar outro arquivo, que mantém “estado atual”. 
 
Comandos e respostas FTP 
 
Comandos: USER (username), PASS (password), LIST (list directory archives), RETR (get 
file), STOR (filename, armazena arquivo); 
 
Respostas (igual no http): 331 (username ok, password required), 125 (data connection 
already open, start transfer), 425 (can’t open data connection), 452 (error writing file). 
 
 
2.4. E-Mail 
 
Três componentes principais: agentes de usuário (1) . Servidor de email (2), e usam o 
protocolo da camada de transporte, simple mail transfer protocol, SMTP (3) 
 
1) Programa de email padrão (e.g gmail outlook etc), objetivo é ler, compor e editar 
mensagens, mensagens essas que são armazenadas no servidor; 
2) É o @... (e.g @cin), possui mailbox, fila de mensagens para serem enviadas, usa o 
protocolo smtp entre servidores de email (cliente = emissor, servidor = receptor); 
3) Correio eletrônico SMTP RFC 2821 usa TCP (pois transferência confiável) para 
emails entre cliente e servidor na porta 25. Consiste em três fases: handshaking, 
transferência e fechamento, e as interações de comando e resposta são iguais às 
anteriores, porém em ASCII 7-bits. 
 
 
Exemplo: alice escreve email para bob => user agent de alice envia para o servidor de 
email de bob, que é colocado na fila => lado cliente do smtp abre conexão tcp com servidor 
de bob => esse cliente envia a mensagem de alice via tcp => servidor de email de bob 
coloca a mensagem na caixa de entrada dele, ele abre lê e responde, e o processo se 
repete. 
 
Sobre SMTP 
 
● Usa conexões persistentes; 
● Usa CRLF.CRLF para determinar final da mensagem (início = DATA, final = ponto 
sozinho numa linha); 
● SMTP faz push/empurra, enquanto HTTP faz pull/puxa; 
● SMTP envia múltiplos objetos por mensagem, enquanto HTTP envia cada 
mensagem encapsulada em sua própria mensagem de resposta; 
● Para encontrar o servidor de destino, conecta-se ao DNS, que encontra o 
destinatário via IP. Geralmente, o email passará por outros servidores SMTP até 
encontrar o SMTP destinatário. Depois da mensagem ser verificada, ela será 
encaminhada para o servidor IMAP (Internet Mail Access Protocol) ou POP3 (Post 
Office Protocol), que será responsável pela entrega da mensagem ao destinatário; 
 
 
 
 
2.5. DNS 
 
O que é DNS? 
 
DNS (Domain Name System) é um protocolo da camada de aplicação e funciona como um 
sistema de tradução de endereços IP para nomes de domínio. Exemplo, cin.ufpe.br é só um 
amontoado de números sem o DNS. O DNS é uma base de dados distribuída 
hierarquicamente com muitos servidores de nome, e ele permite que esses hosts e 
servidores de nome se comuniquem para resolução de endereços/nomes. Alguns serviços 
do DNS são: 
 
● Tradução do nome do host para endereço IP; 
● Host aliasing (nome canônico e alternativo); 
● Mail server aliasing; 
● Distribuição de carga (replicação de servidores para criar um conjunto de endereços 
IP para o mesmo nome canônico); 
 
O DNS é descentralizado, por bons motivos: não se torna um único ponto de falha, distribui 
bem o volume de tráfego, descentraliza base de dados e propõe uma manutenção mais 
simples. 
 
 
 
Servidores Top Level Domain (TLD): org, net, com, edu, br, uk, fr, etc. network solutions 
detém .com, educause detém .edu. 
 
Servidores DNS autorizados: são organizacionais e provém hostnames autorizados para 
mapeamento de ip, e.g web e mail. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Servidor Local de nome