FACULDADE SANTA MARIA - FSM

Pedro César Vieira Barbosa

PROTOCOLO HTTP/1.1

RECIFE
2008.
PEDRO CÉSAR VIEIRA BARBOSA

PROTOCOLO HTTP/1.1

Trabalho da disciplina de Redes de computadores e

protocolos de comunicação seguros apresentado ao
professor Rafael Amorim para obtenção de nota.

Recife
2008
 PROTOCOLO HTTP/1.1

1. Introdução

Esse trabalho tem como foco o estudo do protocolo HTTP que foi escolhido justamente por ser
o protocolo que se encontra como base de praticamente toda comunicação via internet, principalmente
estando às vésperas da convergência dos sistemas de informação para o modelo Cloud Computing,
onde todas aplicações estão deixando de ser executadas nos desktops para rodarem em servidores
centralizados e acessados pro clientes em qualquer parte do mundo através da internet, e na maioria das
vezes as aplicações rodarão em interfaces sobre o protocolo HTTP.
O protocolo HTTP - acrônimo para Hiper Text Transfer Protocol - é um protocolo que
trabalha na camada de aplicação para distribuir de forma colaborativa sistemas de informações. Teve
seu início em 1990 com sua versão 0.9 como um protocolo simples para transferência de “dados
brutos” através da internet, esses dados eram transportados dados de forma “bruta” tanto devido à
pouca complexidade dos sistemas da época em relação aos tempos atuais como também devido à
baixíssima velocidade de conexão da internet à época.
Porém, sua versão 1.0 definida pela RFC 1945, permitiu ao protocolo transportar mensagens do
tipo MIME (Multipurpose Internet Mail Extensions), que contêm meta-informações sobre os dados
transferidos e também sobre as requisições e respostas sobre e conexão.
No entanto a versão 1.0 do protocolo, apesar de trazer muitas inovações, ainda não era hábil o
suficiente para trabalhar com a hieraquia da rede, que envolve proxies, cache, a necessidade da
persistência das conexões, virtual hosts, aplicações que conversam entre si usando esse protocolo,
estando em pontos geograficamente distantes, algumas aplicações até mesmo tendo esse protocolo
como pré-requisito para funcionar.
Devido a essa carência foi implementada a vesão 1.1 do protocolo HTTP, trazendo em seu bojo
as funções necessárias para assegurar que essas exigências mais rigorosas fossem atendidas de forma
confiável.
HTTP é usado hoje em dia como um protocolo genérico para comunicação entre sistemas de
informações diversos, inclusive dando apoio a outros protocolos como por exemplo: SMTP, NNTP,
FTP, Gopher entre outros.

2. Operação do protocolo HTTP/1.1

O protocolo HTTP é, basicamente, um protocolo de requisições e respostas, o cliente envia

uma requisição ao servidor, enviando nessa requisição o método a ser utilizado na comunicação, a URI
e a versão do protocolo seguida por uma mensagem do tipo MIME contendo entre outras coisas
informações sobre o cliente. O servidor recebe essa requisição e responde com outra mensagem
contendo a sua versão do protocolo, e contendo também uma mensagem que pode ser de sucesso – que
dará continuidade à comunicação, ou de erro, informando o motivo pelo qual a comunicação não poder
ser estabelecida, seguida de uma mensagem do tipo MIME contendo informações sobre o servidor.
A maioria das comunicações HTTP é iniciada por um cliente e consiste de uma requisição para
acessar algum serviço que se encontra configurado em algum servidor, essa é uma conexão HTTP
simples, o grau de complexidade da conexão vai aumentando dependendo da quantidade de
intermediários que aparecem entre o cliente e o servidor, esse intermediários são geralmente de três
tipos:

Proxy: Servidor que, na sua forma mais básica, tem a função de encaminhar mensagens de rede
do cliente para o servidor.

Gateway: Intermediário que tem a função de interligar redes traduzindo endereços e
encaminhando os pacotes para o destino correto, um proxy também pode ser interpretado como
um gateway, pois também tem a função de redirecionar pacotes, porém o proxy trabalha em
uma camada diferente do gateway.

Tunnel: Utilizado quando os dados precisam passar por um intermediário – um firewall - sem
que esse intermediário conheça o conteúdo da informação.

O principal objetivo da versão 1.1 é suportar a larga diversidade de aplicações que rodam
diretamente da web disponíveis atualmente, fornecendo a essas aplicações a confiabilidade necessária
para seu funcionamento.
Normalmente o protocolo HTTP funciona em conexões TCP/IP usando a porta 80, mas é
preciso deixar claro que isso é apenas uma convenção, pois outras portas podem ser utilizadas sem
perda de funcionalidades, isso significa também que nada obsta que o protocolo HTTP possa ser
utilizado sobre outras conexões que não TCP/IP seja na internet ou em outras redes. HTTP somente
exige como pré-requisito a confiabilidade, portanto qualquer protocolo que garanta isso pode ser usado
com HTTP.

2.1 Versionamento

A versão do protocolo HTTP é sempre definida por um número no formato

“INTEIRO.FRAÇÃO” a política de versionamento do protocolo é necessária para que tanto que o
cliente ao informar a versão do seu protocolo ao servidor, garanta o sucesso da comunicação fazendo
com que o servidor responda em um formato que sua versão consiga entender.
O número principal da versão somente é alterado quando são adicionadas implementações que
alteram sua forma de se comunicar, o número menor é alterado quando as implementações adicionam
características que são consideradas como incrementos mas que não alteram a forma de o protocolo
trabalhar internamente. O número de versão sempre é informado na primeira linha da comunicação, no
seguinte formato:

HTTP-Version = “HTTP” “/” “INTEIRO” “.” “FRAÇÃO”

É importante frisar que os números “INTEIRO” e “FRAÇÃO” são tratado como

independentes e ambos podem ser incrementados em até dois dígitos, portanto, ao contrário de
como estamos acostumados a interpretar em nosso sistema decimal, HTTP 2.4 é menor que HTTP
2.13 que por sua vez é menor que HTTP 12.5 e é importante saber também que zeros à esquerda
podem ser ignorados pelo destinatário da mensagem mas não por quem as envia (remetente). Por
isso gateways e proxies precisam ter o cuidado adicional ao encaminhar as mensagens entre
protocolos diferentes, no caso de um dos pontos estar usando uma versão maior do protocolo, ele
deve fazer o downgrade na versão dessa mensagem - convertendo a mensagem para uma versão
anterior - ou retornar uma mensagem de erro.

2.2 - URL HTTP

Existe um esquema utilizado para encontrar recursos de rede com o protocolo HTTP, essa seção
define a sintaxe que deve ser utilizada no endereçamento de URLs http:

“http:” “//” host [“:” porta] [caminho absotulo no host [“?” consulta] ]

Como padrão, se a porta não for informada, é assumida a porta 80 e se o caminho absoluto no
host não for informado o caminho padrão no host será o “/” (raiz) e no caso de um proxy receber um
endereço que não esteja completamente qualificado – no padrão FQDN – ele pode completar o nome
do host com seu domínio, no entanto se o endereço do host vier completamente qualificado o proxy não
deve alterar esse endereço. É importante salientar também que o nome do host é interpretado de forma
CASE SENSITIVE, já o caminho absoluto no host não.

2.3 – Formato de data e hora

O protocolo HTTP permite três formatos de data/hora, Vejamos os exemplos, assumindo a data
do dia seis de novembro do ano de 1994 às 08:49:37 hs.

Sun, 06 Nov 1994 08:49:37 GMT

Sunday, 06-Nov-94 08:49:37 GMT
Sun Nov 6 08:49:37 1994

O primeiro formato é preferido por apresentar o mesmo tamanho independente da data e hora
apresentada, o segundo é bastante usado ainda mas está baseado em um modelo obsoleto por usar na
data a representação do ano com apenas dois dígitos.
Clientes e servidores que utilizam HTTP/1.1 devem aceitar os três formatos para manter a
compatibilidade com o HTTP/1.0, no entanto devem gerar apenas no primeiro formato para representar
as datas em seus cabeçalhos. Esses pré-requisitos relacionados ao formato de data/hora são apenas para
o funcionamento interno do protocolo e não deve interferir na forma como essas informações podem
ser apresentadas na tela, ou em logs por exemplo.
É importante saber o HTTP interpreta as informações de data e hora de forma CASE-
SENSITIVE, ou seja, o mesmo caractere no formato maiúsculo e no formato minúsculo são
considerados caracteres diferentes.

2.4 Cabeçalho da mensagem HTTP

O cabeçalho HTTP (HEADER) da mensagem inclui os campos: general-header, request-header,

response-header e entity-header. Cada campo deve ser expresso pelo seu nome (não diferenciando
maiúsculas de minúsculas) seguido do separador dois pontos ( : ) e o valor do campo.
A ordem em que esses campos são enviados não faz diferença para o sucesso da comunicação,
porém é boa prática enviar o general-header primeiro, seguido pelo request-header ou response-header
e por último o entity-header.

2.5 - Corpo da mensagem

 O corpo da mensagem é o container onde são levados os dados de requisição ou de resposta, ou
seja, os dados que são o objeto da comunicação sem os quais a existência de todos os outros não se
justificaria. Geralmente é o recurso que foi solicitado ao servidor pelo cliente ou, na impossibilidade
de prosseguir, uma mensagem de erro.

2.6 – Métodos

O protocolo HTTP possui oito métodos, que indicam a forma ação a ser executada no recurso
específicado, em outras palavras o método diz o que fazer com a URL solicitada pelo cliente. São eles:

2.6.1. - OPTIONS: Solicita ao servidor a lista dos recursos aceitos por ele.
2.6.2. - GET: É o método mais comum, é utilizado na simples solicitação de um recurso
qualquer no servidor seguido de um retorno do servidor.
2.6.3. - HEAD: É o mesmo que o GET só que o sem que o recurso seja retornado. Geralmente
utilizado para obtenção de meta-informações por meio do cabeçalho da resposta.
2.6.4. - POST: Envia dados para serem processados pelo recurso, os dados seguem imbutidos
no corpo do comando e formatados como uma query string além de conter cabeçalhos
adicionais especificando seu tamanho e seu formato. Por isso esse método é reconhecido como
mais seguro para transferência de informações, ao contrário do método GET no qual as
informções são passadas na URL do recurso.
2.6.5. - PUT: Envia um recurso, como por exemplo um arquivo.
2.6.6. - DELETE: deleta um recurso, geralmente um arquivo.
2.6.7. - TRACE: Permite ao cliente saber como sua requisição está sendo tratada no servidor,
podendo usar essa informação para fazer um diagnóstico.
2.6.8. - CONNECT: Método utilizado para se conectar a um proxy e criar um túnel para que
as informações trafeguem em um canal seguro.

A lista dos métodos que podem ser utilizados em um determinado recurso pode ser especificada
em um campo do cabeçalho, ao receber a solicitação do cliente informando o método a ser utilizado no
recurso, o servidor irá retornar um código informando se o método solicitado é ou não permitido para
esse recurso. Essa verificação deve ser feita a cada conexão, devido ao fato de que a lista de métodos
permitidos em um recurso pode ser alterada dinamicamente. Alguns códigos de retorno que impedem a
execução de determinados métodos são:
 2.6.9. - Código 405: Método não permitido. O servidor conhece o método mas não permite
sua utilização no recurso.
2.6.10. - Código 501: Método não implementado ou desconhecido.

É importante observar que os métodos GET e HEAD devem ser implementados e permitidos
por todos os servidores, todos os outros são opcionais.

2.7 – Códigos de retorno

A primeira linha de uma mensagem de resposta é a linha de status, contém a versão do

protocolo seguida de um código numérico de retorno associado a uma frase, como no exemplo a seguir:

Status-Line = Versão_HTTP SP Código_de_Status SP Frase_Explicativa CRLF

O primeiro dígito do código de status define a classe da resposta. Existem 5 classes, são elas:

2.7.1. - 1xx: Informacional, apenas informa que a requisição foi recebida e que será dado
início ao processo.
2.7.2. - 2xx: Mensagem de sucesso. A requisição foi recebida, entendida e aceita. O o
processo foi iniciado e conluido com sucesso.
2.7.3. - 3xx: Redirecionamento. Outra ação deve ser tomada para que a requisição seja
atendida com sucesso.
2.7.4. - 4xx: Erro no cliente. A requisição contém algum erro, como por exemplo erro de
sintaxe.
2.7.5. - 5xx: Erro no servidor. O servidor falhou em atender uma requisição aparentemente
válida.

2.8 – Conexões

2.8.1. - Conexões persistentes: antes da implementação da versão 1.1 do protocolo HTTP, era
necessária uma conexão para cada solicitação de recurso, como um arquivo html, um arquivo
GIF, um arquivo CGI e assim sucessivamente, isso exigia um grande consumo de
processamento e de banda, pois a cada requisição de recurso deveria ser aberta uma nova
conexão que seria encerrada ao final dessa requisição. E normalmente para se obter o resultado
esperado mais simples como, por exemplo, o carregamento de uma página web, dezenas ou
centenas de requisições são necessárias. Causando um enorme desperdício de recursos de cpu e
 memória. A conexão persistente implementada com a chegada da versão 1.1 do protocolo HTTP
permite que todas essas solicitações simples sejam feitas na mesma conexão. A conexão
persistente trouxe consigo as seguintes vantagens:
2.8.1.1. - Pelo fato de abrir e fechar menos conexões, foi ganho tempo de processamento
e memória em roteadores e demais equipamentos de rede. Permitindo maior velocidade e
uso de hardware mais simples.
2.8.1.2. - O congestionamento na rede é diminuído devido ao menor números de pacotes
trafegando, pois já não há tantos pacotes TCP de abertura e encerramento de conexão.
2.8.1.3. - O tempo entre as requisições é diminuído drasticamente, visto que não há mais
um grande número de negociações handshaking, devido ao fato de não precisar mais ficar
abrindo novas conexões a cada requisição.

3 – Estudo de caso

Foi feito um estudo de caso baseado nos conhecimentos adquiridos sobre o protocolo HTTP
para fixar o aprendizado, através da verificação prática do que se estudou na teoria.
Para que esse estudo de caso tivesse uma conotação real e consequentemente uma melhor
utilidade para o aprendizado, o mesmo foi feito em um ambiente real capturando dados em um servidor
proxy de uma empresa em operação normal do dia-a-dia.
O hardware utilizado foi um Servidor Dell T105, com processador dual core e 3 GB de
Memória RAM, foram capturados dados de um determinado cliente da rede por um período de 30
minutos, o suficiente para analisar o funcionamento do protocolo HTTP/1.1.
O software utilizado foi o Wireshark (ex ethereal). O Wireshark atua como um Sniffing na
rede, sendo um analisador de pacotes de rede para o Unix e o Windows. Permite a interatividade com o
browser dos dados analisados, checagem em nível detalhado do pacote, inclusive de dados gravados em
disco. A ferramenta destacou-se pelo filtro apurado de protocolos e a possibilidade de visualizar o fluxo
reconstruído de uma sessão TCP.
Inicialmente é interessante mostrar algumas telas do analisador de protocolo na sequência
das negociações do protocolo, no entanto para não fugir do foco do trabalho, não serão mostradas as
negociações iniciais da conexão como o as feitas pelo protcolo ARP que precedem a atividade do
procolo HTTP. Serão apresentadas apenas as etapas referentes ao protocolo HTTP que é o foco do
nosso estudo.
O wireshark é por sua natureza uma ferramenta que traz a possibilidade de a interface de
rede trabalhar em modo promíscuo, ou seja, capturando todos os pacotes da rede que passar por ela, e
não somente os pacotes de rede destinados a ela, como é o modo normal de trabalho de uma interface
de rede. Porém, isso é uma faca de dois gumes, pois a quantidade de dados que ele captura é imensa e
pode dificultar a análise do tráfego devido ao monte de “lixo” que pode vir nessa captura, então para
isso existem os filtros do wireshark, onde devemos informar o tipo de tráfego que queremos analisar,
ou especificar os dispositivos de rede que queremos monitorar, enfim, existem uma gama muito grande
de possibilidades de utilização dos filtros, nesse estudo foi utilizado o seguinte filtro:

(ip.addr eq 192.168.0.1 and ip.addr eq 192.168.0.108) and http

Nesse filtro estamos filtrando os pacotes que estejam relacionados ao endereço IP

192.168.0.1 (o ip do proxy) e também os pacotes relacionados ao endereço IP 192.168.0.108 (cliente) e
ainda aplicamos um outro filtro no resultado desse primeiro filtro, no traáfego de dados entre esses dois
endereços IP filtramos somente os pacotes relacionados ao protocolo HTTP.
Segue abaixo uma tela do wireshark onde o servidor informa informa sua versão do
protocolo HTTP (indicado na imagem pelo número 1 em vermelho) e na linha seguinte o código de
retorno 200 (indicado na imagem pelo número 2 em vermelho), que como vimos no item 2.7.2 significa
que a requisição foi recebida, entendida e aceita.
 Na figura seguinte pode-se visualizar o cliente solicitando ao servidor a URI:
http://www.meebo.com/mcmd/events utilizando o método POST. Veja abaixo uma explicação mais
detalhada de como encontrar essas informações baseadas na imagem.

3.1. No painel superior vemos a linha em laranja, que é o pacote que está selecionado para ser
analisado, então nesse painel vemos que o endereço IP do cliente (192.168.0.108) está na
coluna SOURCE – do inglês: fonte, ORIGEM – e o IP do servidor (192.168.0.1) está na
coluna Destination – do inglês: destino – dessa forma, por essa linha do painel superior já
identificamos quem é quem nessa relação, além de já visualizarmos nas colunas seguintes o
protocolo e na coluna info vemos o método e o recurso solicitado.

3.2. No painel de leitura, localizado logo abaixo, vemos as informações de forma mais
detalhada, temos na sequencia (os números dos tópicos abaixo indicam os mesmos na tela):
3.2.1. - A data da transação;
3.2.2. - O tamanho do pacote;
3.2.3. - O método;
3.2.4. - O recurso requisitado;
3.2.5. - A versão do protocolo.
 Segue abaixo outra imagem onde o cliente solicita uma página do site de relacionamento
orkut e com sua URL completa, que nesse caso será ofuscada em parte para preservar a identidade e
privacidade do cliente que serviu de estudo.

Basicamente toda a análise do tráfego segue a mesma linha mudando apenas o recurso
solicitado dentre os mais comuns estão os arquivos HTML e imagens nos mais diversos formatos (JPG,
GIF, etc). Essa limitação se dá devido ao filtro aplicado restringindo apenas ao protocolo HTTP e ao
uso do cliente ser praticamente restrito a esses dois sites (Orkut e Meebo).

4 – Conclusão

Na era da informação o ativo mais importante da humanidade é a informação, vivemos em

uma era em que ao contrário da era anterior, onde quem tinha capital tinha poder, na nossa era atual (a
era da informação) quem tem informação tem poder. A prova disso é que fortunas são perdidas,
praticamente da noite para o dia, simplesmente por falta de informação ou por uma informação errada.
Essa mudança de fase, além de mudar o principal ativo da humanidade, mudou também a forma como
esse ativo é transmitido entre as pessoas, a informação hoje em dia desconhece distâncias, virtualmente
nada é longe, com a chegada da internet tudo está a um clique de distância, a informação tornou-se
imaterial e por isso mesmo, teve seu custo reduzido, pois não precisa mais de um suporte material para
ser distribuída. No entanto, no lugar do suporte material para a transmissão dessa informação temos um
novo suporte, que são os protocolos, e é preciso fazer um estudo minucioso sobre esses novos meios de
transmissão de algo tão valioso para nossa sociedade.
Concluo esse trabalho com a grande satisfação de entender um pouco mais sobre esse
protocolo que considero muito importante por ser a base onde todas as aplicações tendem a trabalhar,
principalmente com a tendência atual da larga utilização da computação em nuvem (Cloud
Computing). Apesar de se pensar muito nos protocolos específicos de segurança, é preciso entender a
base de tudo, o “chão” onde as aplicações seguras devem “pisar”, de nada adianta sermos fortes se não
estivermos pisando em um chão seguro, além do mais, quem estuda segurança sabe que: “uma corrente
é tão forte quanto seu elo mais fraco”, e portanto a falta de um melhor entendimento do protocolo
HTTP, pode dificultar ou prejudicar a implementação de outros protocolos e/ou aplicações seguros que
possivelmente serão implementados paralelamente ou sobre o HTTP.

5 – REFERENCIAS

PAZERA, E. Focus On SDL: 1 ed. Muska & Lipman/Premier-Trade, 2002. 336 p. RFC 2616 -
Hypertext Transfer Protocol -- HTTP/1.1. (http://www.w3.org/Protocols/rfc2616/rfc2616.html),
1999, data de última consulta 18 de Dezembro de 2008.