Protocolo de Transferência de Hipertexto
Origem: Wikipédia, a enciclopédia livre.
Sinta-se livre para editá-la para que esta possa atingir um nível de qualidade superior.
HTTP significa HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto) e é um protocolo da camada de "Aplicação" do modelo [OSI], utilizado para transferência de dados na World Wide Web. Esse é o protocolo da World Wide Web (www). O mesmo transfere dados de hiper-midia(imagens,sons e textos). Algumas de suas características são: geralmente este protocolo, utiliza a porta 80 e é usado para a comunicação de "sites". Este comunica na linguagem HTML(Hipertext Markup Language), contudo para haver comunicação, com o servidor do "site", teremos de utilizar comandos proprios do mesmo, os quais não são em HTML.
Para podermos aceder a outro documento no documento actual que estamos a usar, apresenta-se-nos uma âncora que liga os documentos (link ou ancora), e estes documentos encontram-se num "site" e para aceder nós temos de digitar o respectivo endereço, denominado URI (Universal Resource Indentifier), mas não confundam URI com URL(Universal Resource Locator), que é um tipo de URI que pode ser diretamente localizada.
Índice |
[editar] Considerações iniciais
O HyperText Transfer Protocol (HTTP) é um protocolo de rede responsável pela transferência de dados e pela comunicação entre cliente e servidor na World Wide Web (WWW). O protocolo HTTP surgiu da necessidade de distribuir informações pela Internet. Para que essa distribuição fosse possível, foi necessário criar uma forma padronizada de comunicação entre os clientes e os servidores da Web. Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre computadores na Internet e a especificar como seriam realizadas as transações entre clientes e servidores, através do uso de regras básicas (cf. EMBRATEL, HTTP. Disponível em: http://www.embratel.net.br/internet/tecnologia/tecnologia/protocolos_http.html Acesso em: 15 fev. 2002).
Este protocolo tem sido usado pela WWW desde 1990. A primeira versão de HTTP, chamada HTTP/0.9, era um protocolo simples para a transferência de dados no formato de texto ASCII pela Internet, através de um único método de requisição, chamado GET. A versão HTTP/1.0 foi desenvolvida, entre 1992 e 1996, para suprir a necessidade de transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens do tipo MIME44 (Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamados POST e HEAD.
No HTTP/1.1, versão atual do protocolo descrito na RFC 2616 por Fielding et al (1999, p. 7) foi desenvolvido um conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidores proxy que permite uma melhor organização da cache; novos métodos de requisições; entre outros. Fielding et al (1999, p. 7) afirma que o HTTP também é usado como um protocolo genérico para comunicação entre os agentes de usuários e proxies/gateways com outros protocolos, como o SMTP, NNTP, FTP, Gopher, e WAIS, permitindo o acesso a recursos disponíveis em aplicações diversas.
[editar] Funcionamento do protocolo HTTP
Um sistema de comunicação em rede possui diversos protocolos que trabalham cooperativamente para o fornecimento de serviços. Para que o protocolo HTTP consiga transferir seus dados pela Web, é necessário que os protocolos TCP e IP (Internet Protocol) tornem possível a conectividade entre clientes e servidores através de sockets TCP/IP.
De acordo com Fielding et al (1999, p. 10), o HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos de rede, baseando-se no paradigma de requisição e resposta. Um programa requisitante (cliente) estabelece uma conexão com um outro programa receptor(servidor) e envia uma requisição para o servidor na forma de um método de requisição, contendo a URI (Uniform Resource Identifiers), a versão do protocolo, uma mensagem MIME (Padrão utilizado para codificar dados em formato de textos ASCII para serem transmitidos pela Internet) contendo os modificadores da requisição, informações sobre o cliente e, possivelmente, o conteúdo no corpo da mensagem.
O servidor responde com uma linha de status (status line) incluindo sua versão de protocolo e um código de operação bem sucedida ou um código de erro, seguido pelas informações do servidor, metainformações da entidade e possível conteúdo no corpo da mensagem, após enviar a resposta encerra-se a conexão estabelecida.
[editar] Mensagem HTTP
O protocolo HTTP faz a comunicação entre o cliente e o servidor através de mensagens. O cliente envia uma mensagem de requisição de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitação. Segundo Foscarini (2001, p. 13), os dois tipos de mensagens existentes no protocolo, utilizam um formato genérico, definido na RFC 822, para a transferência de entidades.
Uma mensagem tanto de requisição quanto de resposta é composta, conforme definido na RFC 2616 (Fielding et al, 1999, p. 21), por uma linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha em branco obrigatória finalizando o cabeçalho, e por fim o corpo da mensagem podendo ser opcional em determinados casos. Nesta seção serão apresentados os campos que compõem uma mensagem mais detalhadamente.
[editar] Cabeçalho da mensagem
O cabeçalho da mensagem, identificado como header, é utilizado para transmitir informações adicionais entre o cliente e o servidor. O header é especificado imediatamente após a linha inicial da transação (método), tanto para a requisição do cliente quanto para a resposta do servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabeçalhos que poderão ser incluídos na mensagem os quais são: general-header, requestheader, response-header e entity-header (cf. Fielding et al, 1999, p. 21). Estes cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem transmitida (general-header), a requisição e os clientes (request-header) que comunicam suas configurações e os formatos de documentos desejados como resposta (cf. Bastos & Ladeira, 2001). Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente, para transmitir informações que descrevem as configurações do servidor e do recurso identificado pelo URI de requisição, e que não pertence à linha de status (responseheader). Na RFC 2616 (cf. Fielding et al, 1999) estão descritos todos os campos que pertencem a estes cabeçalhos.
[editar] Corpo da mensagem
Uma mensagem HTTP pode conter um corpo de dados que são enviados abaixo das linhas de cabeçalho. Em uma mensagem de resposta, o corpo da mensagem é o recurso que foi requisitado pelo cliente, ou uma mensagem de erro caso este recurso não seja possível. Já em uma mensagem de requisição, o corpo pode conter dados que serão enviados diretamente pelo usuário ou um arquivo que será enviado para o servidor. Quando uma mensagem HTTP tiver um corpo, poderão ser incluídos cabeçalhos de entidades que descrevem suas características, como por exemplo, o Content-Type que informa o tipo MIME dos dados no corpo da mensagem e o Content-Length que informa a quantidade de bytes que o corpo da mensagem contém. A Tabela 2 apresenta alguns tipos MIME.
- Tabela 2 – Alguns tipos MIME [1]
| Exemplo | Descrição |
|---|---|
| text/plain | Arquivo no formato texto (ASCII) |
| text/html | Arquivo no formato HTML, utilizado como padrão para documentos Web |
| Image/gif | Imagem com o formato GIF |
| Image/jpeg | Imagem com o format JPEG |
| application/zip | Arquivo compactado |
[editar] Requisição
De acordo com Fielding (1999, p. 24), uma mensagem de requisição do cliente é composta pelos seguintes campos: uma linha inicial (Request-Line); linhas de cabeçalhos (Request-header); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma requisição é composta por três partes separadas por espaços: o método (Method), a identificação do URI (Request-URI) e a versão do HTTP (HTTP-Version) utilizado. Segundo Bastos & Ladeira ( BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.) Request-URI é um identificador de recurso uniforme (Uniform Resource Identifier) que identifica sobre qual recurso será aplicada a requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de URL (Uniform Resource Locater), no qual é composto pela identificação do protocolo, pelo endereço do computador servidor e pelo documento requisitado (cf. Embratel, 2002).
[editar] Métodos
O protocolo HTTP define oito métodos que indicam a ação a ser realizada no recurso especificado. Conforme Bastos & Ladeiras (2001), o método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso.
- GET: É o método mais comum: solicita algum recurso como um arquivo ou um script CGI (qualquer dado que estiver identificado pelo URI) por meio do protocolo HTTP. O método GET é reconhecido por todos os servidores.
Exemplo. Vemos abaixo uma “conversa” entre um cliente e um servidor http. O servidor possui a URL www.exemplo.com, porta 80.
Pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um newline duplo, cada um composto por um carriage return seguido de um Line Feed):
GET /index.html HTTP/1.1 Host: www.exemplo.com
O cabeçalho "Host" reconhece vários diferentes nomes DNS que tenham o mesmo IP.
Resposta do servidor (seguido por uma linha em branco e o texto da página solicitada):
HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8
- HEAD: É o mesmo que GET, mas sem que o recurso seja retornado. É usado para obter meta-informações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.
- POST: Envia dados para serem processados (por exemplo, dados de um formulário HTML) para o recurso especificado. Os dados são incluídos no corpo do comando.
A utilização do método POST em uma requisição ocorre quando é necessário enviar dados ao servidor para serem processados geralmente por um programa script identificado no Request-URI. Uma requisição por meio desse método sempre requer que as informações submetidas sejam incluídas no corpo da mensagem e formatadas como uma query string, além de conter cabeçalhos adicionais especificando seu tamanho (Content-Lenght) e seu formato (Content-Type). Por isso, esse método oferece uma maior segurança em relação aos dados transferidos, ao contrário do método GET que os dados são anexados a URL, ficando visíveis ao usuário (cf. 46 HERRMANN, Eric. Aprenda em 1 semana programação CGI em Perl 5. Rio de Janeiro: Campus, 1997).
Exemplo:
POST /index.html HTTP/1.0 Accept: text/html If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 30 Nome=NamePessoa&Idade=99&Curso=Computacao
- PUT: Envia certo recurso.
- DELETE: Exclui o recurso.
- TRACE: Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido.
- OPTIONS: Recupera os métodos HTTP que o servidor aceita.
- CONNECT: Serve para uso com um proxy que possa se tornar um túnel SSL (um túnel pode ser usado, por exemplo, para criar uma conexão segura).
Um servidor HTTP deve implementar ao menos os métodos GET e HEAD.
[editar] Resposta
Para Fielding et al (1999, p. 26), uma mensagem de resposta do servidor é composta pelos seguintes campos: uma linha inicial (Status-Line); linhas de cabeçalhos (Responseheader); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma resposta, chamada de linha de status, também possui três partes separadas por espaços: a versão do protocolo HTTP (HTTP-Version), um código de status (Status-Code) da resposta, que fornece o resultado da requisição, e uma frase (Reason-Phrase) de justificativa que descreve o código do status.
[editar] Códigos de retorno
O Status-Line de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não (cf. Herrman, 1997, p. 53). Esta situação é fornecida através de um código de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). De acordo com Fielding et al (1999, p. 37), o código de status é formado por três dígitos e o primeiro dígito representa a classe que pertence classificada em cinco tipos:
- 1xx: Informational (Informação) – utilizada para enviar informações para o cliente de que sua requisição foi recebida e está sendo processada;
- 2xx: Success (Sucesso) – indica que a requisição do cliente foi bem sucedida;
- 3xx: Redirection (Redirecionamento) – informa a ação adicional que deve ser tomada para completar a requisição;
- 4xx: Client Error (Erro no cliente) – avisa que o cliente fez uma requisição que não pode ser atendida;
- 5xx: Server Error (Erro no servidor) – ocorreu um erro no servidor ao cumprir uma requisição válida.
O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode definir seus próprios códigos.
[editar] Conexões
Segundo Hirata ( p5,. HIRATA, Renato. Desempenho em Servidores Web de Grande Porte. 1999. Proposta de Tese de Mestrado – Universidade Estadual de Campinas, São Paulo, 1999. Disponível em: http://www.ic.unicamp.br/~ra951407/PROPOSTA.DOC. Acesso em: 25 fev. 2002), o HTTP/1.0 é um protocolo stateless. Isto significa que as conexões entre um cliente e um servidor são encerradas após o envio de cada requisição ou resposta. Cada vez que uma conexão é estabelecida ou encerrada, é consumida uma grande quantidade de tempo da CPU, de largura de banda e de memória. Na maioria das vezes, para se obter o resultado esperado, é necessário realizar mais de uma solicitação de recursos através de várias conexões. Por exemplo, no caso de uma página Web, que consiste de diversos arquivos (.html, .gif, .css, etc) é preciso que sejam feitas várias requisições para compor a página. O ideal seria que apenas uma conexão fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, o overhead ocasionado pelas conexões. Este tipo de conexão é chamado de conexão persistente (Persistent Connection).
A conexão persistente, implementada como conexão padrão no protocolo HTTP/1.1, possibilita que uma conexão seja estabelecida para enviar várias requisições em seqüência sem a necessidade de esperar por cada resposta, no qual serão recebidas na mesma ordem em que as solicitações foram enviadas, este processo é chamado de pipelining (cf. Fielding et al, 1999, p. 30). Se uma requisição incluir o cabeçalho Connection: close, a conexão será encerrada após o envio da resposta correspondente. Utiliza-se este cabeçalho quando não há suporte a conexões persistentes, quando for a última requisição a ser enviada nesta conexão, ou ainda, sempre que quiser encerrar a conexão mesmo que nem todas as requisições tenham sido completadas. Além disso, o servidor pode fechar uma conexão se estiver ociosa por um determinado período de tempo.
[editar] Considerações finais
De acordo com o que foi apresentado, o HTTP é um protocolo de uso genérico que pode ser usado para diversos tipos de tarefas, através da extensão dos seus métodos de requisição e resposta, códigos de erros e cabeçalhos. Desta forma, o protocolo HTTP é uma alternativa para a comunicação de aplicações distribuídas em applets Java na Internet, devido à utilização deste protocolo como forma de comunicação padrão entre servidores Web. Além disso, permite que estas aplicações sejam executadas sem a necessidade de utilizar uma arquitetura proprietária.
[editar] Esquema de comunicação HTTP
Pedido basico de http cliente - servidor:
GET <ficheiro> HTTP/1.1
Host: <ip>
User-Agent: <Agente1>
Connection: <tipo²>
- 1 Agente que faz a ligação ao servidor, normalmente um browser
- ² Indica como o servidor deve proceder com a conexão, é comumente utilizado para requisições persistentes.
[editar] Referências
- ↑ Fonte: Fielding et al, 1999
