Introdução às Redes de Computadores/Protocolos de aplicação – princípios gerais
Em um modelo de comunicação, como o TCP/IP, as camadas mais inferiores têm a função de transmitir os dados enviados pela camada de aplicação de maneira confiável, mas não fornecem serviços diretos aos usuários. Já a camada de aplicação, fornece diretamente estes serviços, sendo assim, a camada de aplicação é “a razão de ser de uma rede de computadores”[1]. No modelo TCP/IP não há as camadas de seção e apresentação, que na maioria das aplicações são pouco usadas. Essas duas camadas estão incluidas na camada de aplicação.
Arquiteturas de aplicação
Uma Arquitetura de Aplicação define a estrutura de comunicação entre os utilizadores da aplicação. Existem basicamente três tipos de arquitetura: Cliente-Servidor, Peer-to-Peer e uma arquitetura híbrida, que é uma mescla das outros duas. Ao contrario de uma arquitetura de rede, que é fixa, ou seja, provê um conjunto específico de serviços as aplicaçõoes, a arquitetura de aplicação deve ser escolhida pelo desenvolvedor da aplicação, determinando o modo que a aplicação vai se comportar nos sistemas finais em uma rede.
Com essa classificação segundo a arquitetura (cliente-servidor, P2P ou híbrida) pode-se entender melhor como se comportam as aplicações em uma rede. Em qualquer uma dessas arquiteturas, uma aplicação se comunica através de pares de processos, onde um é rotulado cliente e outro servidor. Mesmo em uma aplicação do tipo P2P, o par que solicita um arquivo de outra máquina, é denominado cliente, e o outro que fornece é o servidor. Cliente e Servidor
Este modelo praticamente ocupava a única possibilidade e acabava assumindo como unanimidade o posto de arquitetura de aplicação, isso ocorria devido a computadores poderosos, com muita memória, serem muito caros. Com isso, a tendência era que existissem computadores potentes que centralizassem esses efeitos, por isso MainFrames eram utilizados para armazenar dados de clientes para fazer operações remotas.
Na atualidade, apesar do avanço da tecnologia, trazendo computadores pessoais com maior possibilidade de processamento e de memória, com custo baixo, esse modelo ainda se apresenta com muita força e aparentemente terá forças para continuar por muito tempo ainda.
No modelo de arquitetura Cliente-Servidor, existem dois processos envolvidos, um no host cliente e um outro no host servidor. A comunicação acontece quando um cliente envia uma solicitação pela rede ao processo servidor, e então o processo servidor recebe a mensagem, e executa o trabalho solicitado ou procura pelos dados requisitados e envia uma resposta de volta ao cliente, que estava aguardando. Nesta arquitetura o servidor tem uma aplicação que fornece um determinado serviço e os clientes tem aplicações que utilizam este serviço. Uma característica desta arquitetura, é que um cliente não se comunica com outro cliente, e o servidor, que tem um endereço fixo, esta sempre em funcionamento. Quase sempre um único servidor é incapaz de suportar as requisições de todos os clientes, devido a isso, na maioria dos casos são utilizados vários servidores que constituem um servidor virtual (server farm). Um exemplo claro de aplicação Cliente-Sevidor é a comunicação entre um browser, que é usado para visualizar páginas da internet, em um servidor web. Neste tipo de aplicação o cliente (browser) e o servidor (servidor web) comunicam-se trocando mensagens através do protocolo HTTP.
Peer-to-Peer
A arquitetura P2P (Peer-to-Peer) consiste em uma comunicação direta entre os clientes, não existe nenhuma divisão fixa entre cliente e servidor. Cada par (peer) ativo requisita e fornece dados a rede, desta forma não existe a dependência do servidor, isso aumenta significativamente a largura de banda e a redução de recursos. Esse tipo de arquitetura é utilizado principalmente por aplicações de compartilhamento de conteúdo, como arquivos contendo áudio, vídeo, dados ou qualquer coisa em formato digital. Outras aplicações orientadas a comunicações de dados, como a telefonia digital, videotelefonia e rádio pela internet também utilizam esta arquitetura. Como exemplo podemos citar o protocolo BitTorrent que utiliza a arquitetura peer-to-peer para compartilhamento de grandes quantidades de dados. Neste exemplo um cliente é capaz de preparar e transmitir qualquer tipo de ficheiro de dados através de uma rede, utilizando o protocolo BitTorrent.
Um peer (par) é qualquer computador que esteja executando uma instância de um cliente. Para compartilhar um arquivo ou grupo de arquivos, um nó primeiro cria um pequeno arquivo chamado "torrent" (por exemplo, Meuarquivo.torrent). Este arquivo contém metadados sobre os arquivos a serem compartilhados e sobre o tracker, que é o computador que coordena a distribuição dos arquivos. As pessoas que querem fazer o download do arquivo devem primeiro obter o arquivo torrent, e depois se conectar ao tracker, que lhes diz a partir de quais outros pares que se pode baixar os pedaços do arquivo.
Híbrida
Com uma pesquisa realizada pela empresa Xerox, foi detectado que pelo menos 70% dos usuários de P2P não compartilhavam arquivo, enquanto apenas 1% compartilhavam 50% destes, ou seja, a teoria que se tinha de “divisão de trabalho” pelos clientes, não valia na prática. Para isso então, buscou-se uma solução, e esta solução, representou a utilização da arquitetura do tipo híbrida.
Uma híbrida, mescla das outras duas: cliente-servidor/P2P. Esta arquitetura utiliza, por exemplo, para transferência de arquivos o P2P e a arquitetura cliente/servidor para pesquisar quais peers contêm o arquivo desejado. Uma aplicação muito utilizada neste tipo de arquitetura é a de mensagem instantânea. O Windows Live Messenger e o aMSN são bons exemplos, onde usuários podem bater papo online instantaneamente em tempo real. A comunicação desta aplicação é tipicamente P2P, no entanto, para iniciar uma comunicação, um usuário registra-se em um servidor, e verifica quem da sua lista de contatos também está registrado, para a partir de então começar uma comunicação. Essas aplicações também disponibilizam transferência de arquivos, suporte a grupos, emoticons, histórico de chat, suporte a conferência, suporte a Proxy, e outras ferramentas.
A Comunicação entre os Processos editar
Na Internet, as aplicações devem "conversar" entre si, ou seja, o que o usuário deseja deve ser entendido pela outra máquina e respondido. Essa comunicação é feita entre os processos, através da troca de mensagens. O remetente cria mensagens com seus pedidos ao destinatário, que recebe e gera as suas mensagens para responder (ou não) a solicitação.
Por exemplo, numa comunicação Web, o cliente solicita uma página da Internet, através de um determinado tipo de mensagem (no caso, uma requisição HTTP). O servidor recebe a requisição, e envia uma mensagem com a página para o cliente (através de uma resposta HTTP). Porém, se ocorre um erro, o servidor envia mensagens dizendo ao cliente que ouve algum erro.
Geralmente, a comunicação consiste em pares de processos, onde um processo em cada lado envia mensagens para o outro. Isso ocorre na rede através dos sockets, que são os "porta-vozes" de cada host para uma determinada aplicação.
Para que haja essa comunicação, é necessário que os hosts se identifiquem. Para isso, usam o endereço IP. Porém, é necessário também identificar qual processo naquela máquina irá levar as mensagens à aplicação, e essa identificação é chamada de número (ou endereço) de porta.
Protocolos de Camada de Aplicação editar
Para que dois processos se comuniquem, eles devem trocar mensagens. Porém, é necessário haver regras que padronizem como serão trocadas e tratadas essas mensagens. Por isso, existem os protocolos da camada de aplicação. Como em Tanenbaum[2], "mesmo na camada de aplicação existe a necessidade de protocolos de suporte, a fim de permitir que as aplicações funcionem." É necessário definir os tipos de mensagens a serem trocadas, a sintaxe dos vários tipos de mensagens, a semântica dos campos que compõem as mensagens e as regras que determinam quando e como um processo envia e responde as mensagens. No entanto, como explica Kurose, é importante não confundir os protocolos de camada de aplicação com as aplicações. São conceitos diferentes, apesar de os protocolos serem uma parcela significativa de uma aplicação. Uma aplicação é a interface com o usuário, ou seja, aquilo que é realmente acessado. Os protocolos se responsabilizam por definir como os processos irão se comunicar e como irão tratar as mensagens, para expor o que foi solicitado pelo usuário em sua aplicação. Por exemplo, para acessar uma página Web, um usuário executa um programa Browser e solicita uma página. O Browser usa o protocolo HTTP para enviar o pedido da página, assim como o servidor usa o mesmo protocolo para aceitar a requisição e devolver a página solicitada. O Browser interpreta a mensagem vinda do servidor e apresenta a página.
Dentre os protocolos de aplicação, pode-se citar: HTTP (HyperText Transfer Protocol), HTTPS (HyperText Transfer Protocol over Secure Socket Layer), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), Telnet, POP3 (Post Office Protocol version 3), e muitos outros.
O protocolo de Transporte para uma Aplicação editar
Uma aplicação necessita escolher um tipo de protocolo da camada de transporte, para que as mensagens sejam entregues a aplicação de destino. Uma vez feito essa escolha, a camada de transporte tem a responsabilidade de levar as mensagens pela rede. A internet oferece dois protocolos para a camada de transporte, o TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol). Para efetuar uma boa escolha, o desenvolvedor da aplicação deve fazer uma escolha atentando-se a necessidade de sua aplicação. Com relação ao transporte, podemos citar, por exemplo, a necessidade de transporte sem perdas, a necessidade de largura de banda na comunicação, a temporizaçã jugigigigo, no que se refere a aplicações interativas em tempo real, a necessidade de mecanismos de controle de congestionamento e controle de fluxo (ou seja, compatibilidade de velocidades do remetente e do receptor), entre outras.
O protocolo TCP oferece um serviço confiável de transferência de dados, ou seja, ele garante a entrega do dados do socket emissor ao socket receptor, na ordem e sem perdas, ou seja, ao iniciar a comunicação entre dois hosts com esse protocolo, é feito uma "conexão virtual" entre as portas dos hosts. O TCP utiliza o three-way-handshake para iniciar a comunicação. Portanto, aplicações que envolvem transferência de arquivos, como correio eletrônico, aplicações financeiras, visualizador de páginas da Web (browsers) e ate mesmo conexões remotas a computadores e mensagens instantâneas, que necessitam de confiabilidade na entrega dos dados, ou seja, que não haja perdas, utilizam o protocolo TCP. O TCP também oferece um serviço orientado para conexão, ou seja, ele faz com que o cliente e o servidor troquem mensagens sobre informações de controle da camada de transporte, antes da transferência de dados propriamente dita, e isso garante uma transferência orientada para conexão.
O protocolo UDP oferece um transporte simples e menos confiável, pois não é orientado para conexão, ou seja, não existem procedimentos de verificação de envio e recebimento de dados. No entanto, pode haver checagem de integridade e se algum pacote não for recebido, a aplicação do host de destino pode não fazer uma nova solicitação. Essa característica de "bombear" os dados para o destino à velocidade que quiser, faz do protocolo UDP mais rápido e ideal para certos tipos de aplicações. Existem aplicações que é preferível entregar os dados o mais rapidamente possível, mesmo que algumas informações se percam no caminho. É o caso, por exemplo, das transmissões de vídeo pela internet, onde a perda de um pacote de dados não interromperá a transmissão. Por outro lado, se os pacotes não chegarem ou demorarem a chegar, haverá congelamentos na imagem, causando irritação ao usuário. O mesmo acontece com aplicações de videoconferência, jogos em redes e telefonia pela internet.
Nem o TCP, nem o UDP oferecem garantia quanto a atrasos, ou seja, o TCP pode até garantir que os dados cheguem, porém não garante um tempo mínimo para que isso ocorra. O UDP também: os dados podem ser aceitos mais rápido que TCP, porém atrasos na rede podem tornar o serviço inútil.