HTTP_Resumo_e_Metodos

Prévia do material em texto

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çãodo 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.