Trabalho - Rfc Http

13
FACULDADE SANTA MARIA - FSM Pedro César Vieira Barbosa PROTOCOLO HTTP/1.1 RECIFE 2008.

description

Esse trabalho tem como foco o estudo um pouco mais aprofundado 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 e acessados pro clientes em qualquer parte do mundo através da web, e na maioria das vezes as aplicações rodarão em interfaces sobre o protocolo HTTP.

Transcript of Trabalho - Rfc Http

Page 1: Trabalho - Rfc Http

FACULDADE SANTA MARIA - FSM

Pedro César Vieira Barbosa

PROTOCOLO HTTP/1.1

RECIFE

2008.

Page 2: Trabalho - Rfc Http

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

Page 3: Trabalho - Rfc Http

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

Page 4: Trabalho - Rfc Http

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

Page 5: Trabalho - Rfc Http

“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

Page 6: Trabalho - Rfc Http

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

Page 7: Trabalho - Rfc Http

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:

Page 8: Trabalho - Rfc Http

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

Page 9: Trabalho - Rfc Http

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

Page 10: Trabalho - Rfc Http

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.

Page 11: Trabalho - Rfc Http

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.

Page 12: Trabalho - Rfc Http

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,

Page 13: Trabalho - Rfc Http

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.