Escrito por Ozir Francisco Andrade Zotto - DITEC-A - Ramal 418

Até o final dos anos 80 as informações compartilhadas na Internet consistiam, primariamente, de trocas de mensagens de correio eletrônico e arquivos de dados de computadores. Nessa época começaram a surgir os arquivos multimídia que, além de textos, continham também figuras, sons e ligações (hyperlinks) que permitiam ao usuário "saltar" dentro de arquivos de um modo não linear, ou até mesmo saltar para outros arquivos contendo informações relacionadas.

Foi necessário criar novos protocolos para atender a esses novos requerimentos. O padrão de arquivo HTML (HyperText Markup Language) e o padrão servidor HTTP (HyperText Transfer Protocol) resultaram de um projeto do CERN (European Particle Physics Laboratory), em 1989. Estes padrões forneceram as bases para o surgimento da WWW - o serviço de maior popularidade da Internet e grande responsável pelo seu atual crescimento exponencial.

Este artigo, que se propõe a fazer uma breve análise do protocolo HTTP, é um resumo de uma pesquisa apresentada na disciplina Redes de Computadores, como parte do Curso de Pós-graduação em Ciência da Computação na Universidade Estadual de Londrina. Este curso é fruto de um convênio de cooperação técnica e financeira realizado entre a Celepar - Companhia de Informática do Paraná, a UEL - Universidade Estadual de Londrina, e a Sercomtel - Serviço de Telecomunicações Telefônicas de Londrina, e é ministrado pelos professores da UFRGS - Universidade Federal do Rio Grande do Sul.

1. INTRODUÇÃO

No final dos anos 60 a crescente importância dos computadores originou múltiplos desafios.

A história da Internet começa nesta época, com o Departamento de Defesa dos Estados Unidos patrocinando pesquisas para conectar uma rede experimental denominada ARPANET, e outras várias redes de rádio e satélite. Sob a influência da "guerra fria", um dos objetivos do projeto tinha propósito militar - a rede deveria ser capaz de funcionar e de manter o fluxo de comunicação e informações mesmo durante potenciais desconexões de localidades individuais, como em casos de ataques de bombas.

No modelo ARPANET a comunicação ocorre sempre entre um computador fonte e um destinatário. Ela foi desenhada para requerer o mínimo de informações dos computadores clientes. Para sustentar este modelo, um conjunto de protocolos foi desenvolvido para permitir que computadores e redes distribuídas de computadores enviem e recebam informações entre si, com independência tecnológica de rede e de sistema operacional, em interconexões universais e confirmação ponto-a-ponto. Quando um destes pontos não está ativo, a comunicação pode ser redirecionada através de locais alternativos até sua final destinação. O protocolo desenvolvido para este propósito foi chamado o Internet-working Protocol, ou "IP", como ficou mais conhecido.

O protocolo IP espalhou-se rapidamente pela comunidade militar como um meio para os pesquisadores compartilharem informações computadorizadas. Como os militares tinham numerosos projetos de pesquisa em conjunto com universidades em todo o país e o protocolo provia um meio efetivo para mover informações através de diversas redes, o IP rapidamente difundiu-se para fora da comunidade militar, incluindo instituições de pesquisa da OTAN e universidades européias. Hoje o protocolo IP é um padrão onipresente mundial.

A ARPANET original foi abandonada em 1990, substituída pelos backbones da National Science Foundation, que desde meados dos anos 80 passou a custear o crescimento da Internet.

No final dos anos 80 um novo problema emergiu na Internet. Até então, as informações compartilhadas consistiam primariamente de trocas de mensagens de correio eletrônico (e-mail) e arquivos de dados de computadores.

Vários protocolos de e-mail e protocolos de transferência de arquivos tinham evoluído para manipular estes requerimentos. Entretanto, novos tipos de arquivos estavam começando a surgir na Internet. Estes eram arquivos multimídia, que continham não apenas figuras ou sons, mas também ligações
(hyperlinks) que permitiam ao usuário "saltar" dentro de arquivos de um modo não linear, ou até mesmo saltar para outros arquivos contendo informações relacionadas.

Em 1989, o CERN (European Particle Physics Laboratory) iniciou um projeto interno bem sucedido, que levou a um esforço para criar padrões para passar este novo tipo de informação através da Internet. Os componentes básicos consistiam de padrões para a criação de arquivos hipertexto multimídia e um padrão para "servir" estes arquivos padronizados quando requisitados. O padrão de arquivo é chamado HyperText Markup Language, ou HTML. O padrão servidor é chamado HyperText Transfer Protocol, ou HTTP. Um servidor HTTP enviará arquivos HTML através da Internet para outros clientes que os requisitem.
Estes dois padrões forneceram as bases para o surgimento de toda uma nova abordagem para a autoria, gerenciamento e publicação de informação computadorizada distribuída - a WWW (World Wide Web) - o serviço de maior popularidade e de crescimento exponencial na Internet.

Este documento tem como proposta fazer uma breve análise do protocolo HTTP, um dos pilares da solução em escala global para o problema de distribuição e heterogeneidade de informação que caracteriza a Internet. Na seção 2 mostramos a contextualização do HTTP na arquitetura Internet, e uma comparação desta arquitetura em relação à arquitetura OSI. Na seção 3 descrevemos algumas das operações básicas do HTTP e na seção 4 concluímos, comentando algumas das características que as novas versões do HTTP deverão incluir, para superar suas atuais limitações.

2. O PROTOCOLO HTTP

2.1 CONTEXTO

O protocolo HTTP é um protocolo do nível de aplicação (Figura 1), que possui objetividade e rapidez necessárias para suportar sistemas de informação distribuídos cooperativos de hipermídia.

2.2 O MODELO OSI E A ARQUITETURA INTERNET

Na arquitetura de rede de comunicação utilizada pela Internet, as camadas de Sessão, Apresentação e Aplicação do modelo OSI estão englobadas numa única camada (Figura 2), que faz o tratamento adequado, embora com menor versatilidade no controle exercido sobre os elementos da rede.

Estes diferentes modelos possuem áreas de atuação bem definidas. As diferenças entre os dois referem-se, principalmente, à filosofia de acesso aos dados, à funcionalidade, à complexidade, ao desempenho, ao suporte de comunicação e disponibilidade de produtos.

2.3 PROPÓSITOS

O protocolo HTTP está sendo usado globalmente pela World Wide Web desde 1990. Sistemas de informação práticos requerem maior funcionalidade do que simples recuperação, incluindo pesquisa, atualização no front-end e anotação. HTTP permite um conjunto aberto de métodos para ser usado para indicar o propósito de uma requisição. Ele constrói na disciplina de referência provida pela Uniform Resource Identifier (URI), como uma locação (URL) ou nome (URN) para indicar em cujo recurso um método é para ser aplicado. As mensagens são passadas em um formato similar ao usado pelo Internet Mail e o Multipurpose Internet Mail Extensions (MIME).

HTTP também é usado como um protocolo genérico para comunicação entre agentes usuários e proxies/gateways com outros protocolos Internet, tais como SMTP, NNTP, FTP, Gopher e WAIS, permitindo acesso básico hipermídia para recursos disponíveis de aplicações diversas e simplificando a implementação de agentes usuários.

2.4 TERMINOLOGIA
Resumo dos termos dos participantes e objetos da comunicação HTTP:

connection (conexão)

Circuito virtual na camada de transporte estabelecido entre dois programas aplicativos para o propósito de comunicação.

message (mensagem)

A unidade básica de comunicação HTTP, consistindo de uma seqüência estruturada de octetos de sintaxe definida e transmitida via conexão.

request (pedido)

Uma mensagem de requisição HTTP.

response (resposta)

Uma mensagem de resposta HTTP.

resource (recurso)

Um objeto de dados da rede ou serviço que pode ser identificado por uma URI.

entity (entidade)

Uma representação particular de um recurso de dados, ou resposta de um recurso de serviço, que pode ser incluído numa mensagem de pedido ou de resposta.

client (cliente)

Um programa aplicativo que estabelece conexões para o propósito de enviar pedidos.

user agent (agente usuário)

O cliente que inicia o pedido. Normalmente "browsers", editores, "spiders" (robôs que pesquisam através da rede), ou outras ferramentas de usuário final.

server (servidor)

Um programa aplicativo que aceita conexões para atender pedidos e enviar respostas.

origin server (servidor de origem)

O servidor no qual um dado recurso reside ou é para ser criado.

proxy (procuração)

Um programa intermediário que atua duplamente como servidor e como cliente para fazer pedidos em nome de outros clientes. Proxies são geralmente usadas como portais clientes através de firewalls e como auxiliares de aplicações para manipular pedidos via protocolos não implementados pelo agente usuário.

gateway

Um servidor que atua como intermediário para outros servidores. Gateways são geralmente usados como
portais clientes através de firewalls e como tradutores de protocolos em sistemas não-HTTP.
tunnel (túnel)

É um programa intermediário que atua como um relé cego entre duas conexões. Uma vez ativo, o túnel não é considerado parte da conexão HTTP. O túnel deixa de existir quando ambos os fins da conexão ligada deixam de existir.

cache

Um local de armazenamento de mensagens de resposta do programa e o subsistema que controla o armazenamento, recuperação e exclusão destas mensagens. O acesso fácil às mensagens armazenáveis reduz o tempo de resposta e consumo de tráfego na rede no futuro, em pedidos equivalentes.

Qualquer programa dado pode ser capaz de ser cliente ou servidor. O uso destes dois termos refere-se apenas ao papel que está sendo executado pelo programa para uma conexão particular, ao invés de programas de uso geral. Assim também, cada servidor pode atuar como servidor de origem, proxy, gateway ou túnel, mudando o comportamento baseado na natureza de cada pedido.

3. VISÃO GERAL DAS OPERAÇÕES

O protocolo HTTP é baseado no paradigma pedido/resposta. Um cliente estabelece uma conexão com um servidor e envia um pedido ao servidor, o qual o analisa e responde. A conexão deve ser estabelecida antes de cada pedido de cliente e encerrada após a resposta. As mensagens seguem o formato da RFC822, atualizada pelas RFC1327 e RFC0987.

3.1 PEDIDO

Uma mensagem de pedido de um cliente a um servidor inclui o método a ser aplicado ao recurso, o identificador do recurso e a versão do protocolo em uso.

O formato da mensagem de pedido enviada do cliente ao servidor é descrito abaixo, de acordo com a notação BNF :

Request = Simple-Request | Full-Request
Simple-Request = "Get" SP Request-URI CRLF
Full-Request = Request-Line * ( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ]

3.2 RESPOSTA

Após receber e interpretar uma mensagem de pedido, um servidor responde na forma de um mensagem de resposta HTTP:

Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line * ( General-Header | Response-Header | Entity-Header ) CRLF [ Entity-Body ]

3.2.1 STATUS-LINE (LINHA DE ESTADO)

A primeira linha de uma Full-Response é a Status-Line, consistindo da versão do protocolo, seguida de um código de status e sua frase de texto associada, com cada elemento separado pelo caráter SP. Nenhum CR (carriage return) ou LF (line feed) é permitido, exceto o CRLF final da seqüência.

Status-Line=HTTP-Version SP Status-code SP Reason-Phrase CRLF

3.2.2 CÓDIGOS DE STATUS

O elemento Status-Code é um inteiro de 3 dígitos, resultado da tentativa para entender e satisfazer o pedido. O primeiro dígito define a classe da resposta. Os últimos dois dígitos não têm nenhuma categorização. Existem 5 valores para o primeiro dígito:

1xx: Informacional - Não usado, mas reservado para futuro uso.
2xx: Sucesso - A ação foi recebida, entendida e aceita.
3xx: Redirecionamento - Ações adicionais devem ser executadas para completar o pedido.
4xx: Erro no cliente - O pedido contém erro de sintaxe ou não pode ser completado.
5xx: Erro no servidor - O servidor falhou em completar um pedido aparentemente válido.

3.3 ENTIDADE

Mensagens Pedido-Completo (Full-Request) e Resposta-Completa (Full-Response) podem transferir uma entidade com alguns pedidos e respostas. Uma entidade consiste de campos Entity-Header (Cabeçalho da Entidade) e Entity-Body (Corpo da Endidade):

Entity-Header = Allow | Content-Encoding | Content-Lenght | Content-Type | Expires | Last-Modified extension-header
extension-header = HTTP-header
Entity-Body = *OCTET

3.4 DEFINIÇÕES DE MÉTODOS

O conjunto de métodos comuns é definido abaixo. Embora este conjunto possa ser expandido, métodos adicionais não podem ser assumidos, compartilharem a mesma semântica para clientes e servidores expandidos separadamente.

3.4.1 GET

O método GET recupera qualquer informação (na forma de uma entidade) que é identificada pelo pedido Request-URI. Se o Request-Uri refere-se a um processo produtor de dados, ele retornará o produto do processo e não o texto fonte.

A semântica do Get muda para "conditional Get" se a mensagem de pedido inclui um campo de cabeçalho If-Modified-Since, que traz o recurso apenas se o mesmo foi alterado depois da data referida.

3.4.2 HEAD

O método HEAD é idêntico ao Get, exceto que o servidor não precisa retornar nenhuma Entity-Body na resposta.

Este método é freqüentemente utilizado para testar a validade e acessibilidade de ligações de hipertextos, além de modificações recentes.

3.4.3 POST

O método POST é utilizado para solicitar que o servidor destino aceite a entidade constante no pedido como um novo subordinado ao recurso constante no URI. Permite um método uniforme para cobrir as seguintes funções:

• anotação de recursos existentes;
• postar uma mensagem em um bulletin board, newsgroup, mailing list.
• abastecer um processo com um bloco de dados;
• estender uma base de dados com uma operação de append.
  

As aplicações não devem armazenar respostas ao Post em cache, pois não há meio de saber se o servidor retornará uma resposta equivalente em futuros pedidos.

3.5 CARACTERÍSTICAS ADICIONAIS

Existem alguns elementos do protocolo que são usados em algumas implementações HTTP, mas não consistentemente e corretamente através de muitas aplicações HTTP. Os implementadores devem estar atentos para estas características, mas não confiar em sua presença ou interoperabilidade em outras aplicações HTTP.

3.5.1 PUT

O método PUT requisita que a entidade seja armazenada sob o Request-Uri do pedido. Se o Request-Uri refere-se a algum recurso existente, a entidade deve ser considerada como uma nova versão daquela existente no servidor de origem. Se o Request-Uri não aponta para um recurso existente, e aquela URI é capaz de ser definida como um novo recurso pelo agente usuário requisitante, o servidor de origem pode criar o recurso com aquela URI.

3.5.2 DELETE

O método DELETE requer que o servidor de origem apague o recurso identificado pelo Request-Uri.3.5.3 LINK
O método LINK estabelece uma ou mais ligações de relacionamento entre o recurso existente pelo Request-Uri e outros recursos.

3.5.4 UNLINK

O método UNLINK remove uma ou mais ligações de relacionamento entre o recurso existente pelo Request-Uri e outros recursos.

4. CONCLUSÃO

Apesar das habilidades do HTTP serem responsáveis pelo tremendo sucesso do serviço WWW da Internet, este protocolo não foi originalmente planejado para ser usado como um protocolo de informações comerciais. O crescente enfoque comercial da Internet chamou a atenção para várias limitações básicas do HTTP. As principais limitações tratam da incapacidade de oferecer dados convencionais de marketing que mostrem que tipos de visitantes navegam pelo "site", e como os recursos oferecidos estão sendo utilizados.

Muitas empresas que estão pensando em investir mais em sua presença na Internet querem respostas para algumas perguntas relativamente simples, tais como:

• Quantas pessoas estão visitando o "site"?
• De onde elas vêm?
• Quanto tempo gastam no "site"?
• Como se movimentam no "site"?
• Para onde vão depois que saem?
• Qual é o efeito que as informações do "site" têm sobre elas?
  

A versão atual do protocolo HTTP dificulta a coleta de informações básicas de marketing. Novos protocolos, como o HTTP-NG estão sendo propostos, para dar conta da expansão e crescente comercialização da World Wide Web.

REFERÊNCIAS BIBLIOGRÁFICAS

BERNERS-LEE, T. et al. HyperText Transfer Protocol: HTTP/1.0, seventh release. W3Consortium. http://www.w3.org/pub/WWW/Protocols/rfc822/ Overview.html May, 1996.

BRISA. Gerenciamento de Redes. São Paulo : Makron, 1993.

CROCKER, D. H. et al. RFC 822: standard for ARPA Internet Text Messages W3Consortium. http://www.w3.org/pub/WWW/Protocols/rfc822/Overview.html. May, 1996.

CUTLER, M.; HALL, D. Sob medida : novos protocolos propostos podem superar o limite dos atuais. Internet World, v. 1, n.3, p.120-123, Nov. 1995.

EDDINGS, J. Como Funciona a Internet. São Paulo : Quark, 1994.

KROL, E. The whole Internet user’s guide & catalog. Sebastopol : O’Reilly & Associates, 1994.

TANENBAUM, A. S. Computer networks. Englewood Cliffs : Prentice-Hall, 1988.

TELLEEN, S. L. Intranet Concepts. Amdahl Corporation.http://www.amdahl.com/doc/products/bsg/intra/concepts.html. Feb. 1996.