30-11-2010

Desenvolvimento de aplicações Web I
O PROTOCOLO HTTP

É a rede…
É necessário conhecer o
funcionamento do proto...
30-11-2010

HTTP e TCP/IP
O HTTP está no topo da stack do protocolo TCP/IP

Layer de Aplicação

HTTP

Layer de Transporte
...
30-11-2010

HTTP e TCP/IP
O TCP fornece mecanismos que asseguram
uma conexão robusta (byte pipe)
Handshake, números sequen...
30-11-2010

Ciclo básico Pedido/Resposta HTTP
Pedir um determinado recurso através
do seu URL
http://www.exemplo.com/cont1...
30-11-2010

Pedidos de HTTP
Ambos os pedidos e respostas HTTP
são tipos de mensagens da internet
(RF 822), e partilham um ...
30-11-2010

A linha de pedidos em detalhe
Consiste em 3 principais partes
O método de pedido seguido de 1 espaço
O HTTP 1....
30-11-2010

Porque é importante?
Quando estamos a programar para a Web poderá ser
necessário formar pedidos HTTP em “bruto...
30-11-2010

Cabeçalho HTTP
Os cabeçalhos aparecem normalmente em 4 tipos,
alguns para pedidos outros para respostas alguns...
30-11-2010

Cabeçalhos de pedido
Host – o nome do anfitrião (e opcionalmente o porto) do
servidor para o qual o pedido foi...
30-11-2010

Utilizar os cabeçalhos de pedidos
(Anti-leeching)

Muitas vezes, algumas pessoas utilizam a nossa largura de
b...
30-11-2010

Utilizar os cabeçalhos de pedidos
(Compressão HTTP)

A compressão via HTTP é habilitada através da utilização ...
30-11-2010

Cabeçalhos de resposta
Server - o nome do servidor e versão
Server: Microsoft-IIS/5.0
Pode ser problemático po...
30-11-2010

Mais cabeçalhos de entity
Content-Type – especifica o tipo de media do corpo da
entidade (MIME)
Corresponde ao...
30-11-2010

A importância dos cabeçalhos
Poderá ser necessário ir mais além do que o básico controlo
de cache:
Prazos para...
30-11-2010

Enviar os dados via método GET
Os dados enviados pelo método GET podem ser submetidos de 2
formas:
Escrita no ...
30-11-2010

Enviar os dados via método POST
No caso do método POST podemos gerar os pedidos programando-os ou,
de uma form...
30-11-2010

Considerações acerca do HTTP
O protocolo HTTP é stateless
Não existe memória de um pedido para o próximo

Como...
Upcoming SlideShare
Loading in...5
×

Dawi o protocolo-http

117

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
117
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dawi o protocolo-http

  1. 1. 30-11-2010 Desenvolvimento de aplicações Web I O PROTOCOLO HTTP É a rede… É necessário conhecer o funcionamento do protocolo HTTP para podermos programar correctamente no Ambiente Web. Se a rede não funcionar correctamente programadores/ utilizadores irão ter problemas. Mais tarde ou mais cedo vamos precisar/necessitar de utilizar: cache; autenticação, optimizar, entre outras… Quando começamos a utilizar ferramentas como o AJAX conhecer o HTTP torna-se muito importante. Introdução ao HTTP HTTP (Hyper Text Transfer Protocol) É um layer de aplicação semelhante ao SMTP, POP, IMAP, FTP, etc. É um protocolo simples que define a forma como os clientes realizam pedidos de dados ao servidor e como este responde de volta. Tipicamente este serviço corre em cima do TCP/IP Existem 3 versões (0.9, 1.0, 1.1) das quais 2 ainda são utilizadas RFC 1945 HTTP 1.0 (1996) RFC 2616 HTTP 1.1 (1999) 1
  2. 2. 30-11-2010 HTTP e TCP/IP O HTTP está no topo da stack do protocolo TCP/IP Layer de Aplicação HTTP Layer de Transporte TCP Layer de Rede IP Layer de dados Interfaces de Rede HTTP e TCP/IP O protocolo IP fornece pacotes que são encaminhados baseado no endereço IP de partida e chegada. O TCP fornece segmentos que são incorporados nos pacotes IP e adiciona o cabeçalho com informação do porto de destino e origem. Os portos permitem ao TCP suportar protocolos múltiplos que conectam serviços em portas por omissão. HTTP no porto 80 http com SSL(HTTPS) no porto 443 FTP no porto 21 SMTP no porto 25 2
  3. 3. 30-11-2010 HTTP e TCP/IP O TCP fornece mecanismos que asseguram uma conexão robusta (byte pipe) Handshake, números sequenciais, flags de controlo, checksum. O stream de dados é cortado em pedaços que são novamente juntos de uma forma organizada na outra ponta da ligação. Os segmentos de TCP que são enviados dentro de pacotes IP, levam esses pedaços de dados Estes pedaços de dados são o conteúdo da mensagem de HTTP. Exemplo de HTTP sobre TCP/IP GET /index.html HTTP/1.1 <CRLF> Host: www.hostname.com Com… A mensagem HTTP é cortada em pedaços pequenos, o suficiente para caberem num segmento de TCP Estes pedaços movem-se nos segmentos no interior do TCP e são utilizados para juntá-los de forma correcta na outra ponta da ligação Os segmentos são enviados para o destino correcto dentro dos datagramas IP Problemas … HTTP sobre TCP/IP HTTP/1.0 abre e fecha uma nova conexão TCP para cada operação. Uma vez que a maioria dos objectos Web são de pequenas dimensões esta prática implica uma maior fracção de pacotes sejam TCP. Acrescenta-se ainda ao ponto anterior os lentos mecanismos de controlo de congestionamento do TCP e deparamo-nos com operações HTTP/1.0 que utilizam o TCP de forma menos eficiente. HTTP 1.1 lida com este problemas utilizando ligações persistentes usando o Keep-Alive 3
  4. 4. 30-11-2010 Ciclo básico Pedido/Resposta HTTP Pedir um determinado recurso através do seu URL http://www.exemplo.com/cont1.hmtl http://www.exemplo.com HTTP REQUEST HTTP RESPONSE Cliente HTTP Servidor HTTP Recurso cont1.html HTTP ciclo de pedido/resposta exemplo 2 Tipos e utilização de Proxies Os proxys são intermediários HTTP Actuam tanto como clientes como servidores A maioria dos proxys pode ser distinguido pelo local onde estão colocados e a forma como obtêm os dados Explicit Transparent Intercepting Reverse 3 principais razões para utilizações de proxys Segurança Performance Filtragem de conteúdos 4
  5. 5. 30-11-2010 Pedidos de HTTP Ambos os pedidos e respostas HTTP são tipos de mensagens da internet (RF 822), e partilham um formato geral: Uma linha de início, seguida de CRLF (nova linha) Linha de pedido para pedidos Linha de informação para as respostas Zero ou mais mensagens de cabeçalho Nomedocampo “:” [valor do campo] CRLF Uma linha vazia 2 CRLF marcam o final dos cabeçalhos Um corpo da mensagem opcional Exemplo de um pedido HTTP Outro Pedido HTTP 5
  6. 6. 30-11-2010 A linha de pedidos em detalhe Consiste em 3 principais partes O método de pedido seguido de 1 espaço O HTTP 1.1 inclui os métodos: GET, POST, HEAD, TRACE, OPTIONS, PUT, DELETE e CONNECT Os mais utilizados são GET, POST e o HEAD O URI pedido seguido de um espaço O endereço URL associado ao recurso A versão HTTP seguida por CRLF 0.9, 1.0, 1.1 Pedido HTTP - Os métodos GET É, de longe, o método mais utilizado Retorna um recurso do servidor Suporta a passagem de “query strings arguments” HEAD Retorna apenas os cabeçalhos associados a um recurso mas não a entidade em si. Muito útil para o diagnóstico e análise do protocolo POST Permite o envio de entidades de dados em vez de URL Pode transmitir argumentos bastante maiores do que o GET Os argumentos não são apresentados no URL. Pedido HTTP - Mais métodos OPTIONS Mostra os métodos disponíveis para utilizar com um determinado recurso ou servidor TRACE Método de diagnóstico para avaliar o impacto de proxies ao longo da cadeia de pedidos. PUT, DELETE Utilizados na publicação HTTP (WebDav) CONNECT Uma extensão comum para correr outros protocolos sobre o HTTP Existem ainda mais métodos… 6
  7. 7. 30-11-2010 Porque é importante? Quando estamos a programar para a Web poderá ser necessário formar pedidos HTTP em “bruto” Por exemplo, através de JavaScript utilizando AJAX para formarmos um pedido HTTP utilizando o método GET ou POST para transmitirmos dados. xmlhttp = ajaxhttp(); xmlhttp.open("POST", url, true); xmlhttp.setRequestHeader("Content-Type", "application/xwwwform-urlencoded"); xmlhttp.send("ret=" + escape(param)); Nos formulários HTML ao atribuirmos um valor ao atributo action <form action=“GET|POST”> estamos a especificar o método HTTP para transmitir os dados. Um olhar mais detalhado ao URI URI absolutos Vs caminhos absolutos Proxies explícitos requerem URIs absolutos O cliente está directamente ligado ao proxy O protocolo e o nome do servidor necessitam ser resolvidos Pode ser necessário URL completos para os serviços Web Atenção com problemas como www vs no www Gramática para os caminho absolutos É igual aos URIs absolutos menos a primeira parte http://hostname O “/” equivale à raiz dos documentos no servidor No HTTP 1.1 com “name-based virtual host” o protocolo já redirecciona para a document root apropriada A resposta HTTP A resposta consiste também em 3 grandes partes A versão HTTP seguida de um espaço O código de estado seguido de um espaço 5 grupo de de 3 dígitos indicam o resultado da tentativa de satisfazer o pedido do cliente. 1xx são de informação 2xx são de sucesso 3xx são de recursos alternativos (redirects) 4xx indicam erros do cliente 5xx indicam erros no servidor A “frase resultado” seguida de CRLF 7
  8. 8. 30-11-2010 Cabeçalho HTTP Os cabeçalhos aparecem normalmente em 4 tipos, alguns para pedidos outros para respostas alguns apara ambos Cabeçalhos gerais Fornecem informação acerca das mensagens de pedido e resposta. Cabeçalhos de pedidos Fornecem informação específica de mensagens de pedido. Cabeçalhos da resposta Fornecem informação específica de mensagens de resposta. Cabeçalhos de entidades Fornecem informação acerca das entidades de resposta e pedido São também possíveis cabeçalhos de extensão Os cabeçalhos gerais (detalhado) Conexão - permite ao cliente e servidor gerir os estado da ligação Connection: Keep-Alive (HTTP 1.0) Connection: close (HTTP 1.1) Data – quando a mensagem foi criada Date: Sat, 31-May-03 15:00:00 GMT Via – mostra os proxies que manipularam a mensagem Via 1.1 www.mproxy.com (Squid/1.4) Cache-Control – está entre os headers mais complexos, permite enviar directivas de cache Cache-Control:no-cache Problemas com caches Após realizarmos um pedido, se o fizermos novamente o pedido do mesmo recurso, o browser não irá realizar uma nova ligação ao servidor (depende das opções seleccionadas no browser), mas sim utilizar os dados em cache. Isto pode causar problemas. Exemplo: estarmos a ver conteúdo desactualizado Exemplo: problemas com o AJAX Uma solução para cache desactualizadas é adicionar cabeçalhos de controlo de cache É bom sabermos o que é cache e como utilizá-la correctamente Quais os conteúdos que queremos colocar em cache? 8
  9. 9. 30-11-2010 Cabeçalhos de pedido Host – o nome do anfitrião (e opcionalmente o porto) do servidor para o qual o pedido foi enviado. Necessário para anfitriões virtuais baseados em nomes Host: www.port80.com Referer – o endereço ou recurso a partir da qual o pedido foi gerado. http://www.host.com/login.asp User-Agente – nome da aplicação que realizou o pedido (Browser). User-Agent: Mozilla/4.0 (compatible; MSIE 6.0) Cabeçalhos de pedido Accept e as suas variantes – informa o servidor das capacidades do cliente e as suas preferências. Permite a negociação de conteúdos Accept: image/gif, image/jpeg;q=0.5 Accept – variantes para a linguagem, codificação, charset If-Modified-Since e outras condicionais Utilizado frequentemente pelos browsers para gerirem a cache If-Modified-Since: Sat, 31-May-03 15:00:00 GMT Cookie – permite enviar as cookies para o servidor que as atribuiu Cookie: id=13412; level=3 Utilizar os cabeçalhos de pedidos - Browser sniffing User-Agent: é normalmente utilizado para a detecção do browser que está a ser utilizado como cliente e desta forma apresentar diferentes conteúdos dependendo do browser utilizado. Uma abordagem melhor (para determinar qual é o cliente) é mesmo injectar um script no cliente de forma a fazer o profiling do cliente. No futuro, à medida que a diversidade de dispositivos com acesso a rede aumenta, o conceito de browser vai evoluir significativamente 9
  10. 10. 30-11-2010 Utilizar os cabeçalhos de pedidos (Anti-leeching) Muitas vezes, algumas pessoas utilizam a nossa largura de banda ligando directamente (hotlink) aos nossos objectos (Gif, flash, etc.) sem retornar os objectos relacionados (ex. Publicidade). Isto pode ser prejudicial se o nosso modelo de negócio estiver relacionado com publicidade à volta dos objectos “roubados” Uma forma muito simples de anti-leeching seria verificar o cabeçalho REFERER antes de enviar o objecto. Utilizar os cabeçalhos de pedidos (Negociação de conteúdos) O Browser envia os cabeçalhos Accept indicando o tipo de conteúdos que este pode lidar Utilizar os cabeçalhos de pedidos (Negociação de conteúdos) Um “q-rating” pode indicar qual a preferência que o Browser tem pelos dados solicitados A negociação de conteúdos permite-nos pedir qualquer coisa como “logo” e receber de volta a imagem apropriada (PNG, JPG, etc.) com base nas capacidades do dispositivo Isto leva a conteúdos sem extensões o que a longo termo ajuda na manutenção A negociação dos conteúdos permite também que a linguagem seja automaticamente negociada. 10
  11. 11. 30-11-2010 Utilizar os cabeçalhos de pedidos (Compressão HTTP) A compressão via HTTP é habilitada através da utilização de cabeçalhos Accept O browser envia os cabeçalhos indicando o tipo de compressão que aceita (gzip ou deflated). O servidor utilizando mod_gzip httpzip, etc. envia o conteúdo comprimido ou não. Apenas funciona com texto (html, css, JS) e atinge uma compressão de cerca de 70% Aumento do tempo de resposta, o que é mau para ligações de alta velocidade apesar de poupar largura de banda. Para ligações de baixa velocidade é claramente vantajoso Exemplo de compressão HTTP Considerações sobre compressão Considerações sobre TTFB (Time To First Byte) vs TTLB (Time To Last Byte) e redes Tempos necessários para descomprimir Bugs… In Internet Explorer, … The bytes that remain to be decoded in the buffer may be small (8 bytes or less) and the data contained in the buffer decompresses to 0 bytes. … When shtml receives 0 bytes, it thinks that all the data is read and closes the data stream. As a result, the HTML page sometimes appears truncated. Typically, if it is for a referenced file such as a .js or a .css file type, the HTTP connection stops responding. A maioria destes problemas é resolvido através de aplicações comerciais instaladas no lado do servidor 11
  12. 12. 30-11-2010 Cabeçalhos de resposta Server - o nome do servidor e versão Server: Microsoft-IIS/5.0 Pode ser problemático por razões de segurança Segurança ou obscuridade?? Vary – Diz ao cliente e proxies de cache quais os cabeçalhos que foram utilizados para a negociação dos conteúdos Vary: User-Agent, Accept Set-Cookie – é desta forma que o servidor coloca uma cookie no cliente Set-Cookie: id=1234, path=/shop, expires=Sat, 31-May-03 15:00:00 GMT; secure Cabeçalhos Entity Allow – lista os métodos de pedido que podem ser utilizados numa entidade Allow: GET, HEAD, POST Location – indica uma localização alternativa ou nova da entidade Utilizada com o código de resposta 3xx (redirects) Location: http://www.ibm.com/us/ Content-Encoding – especifica a codificação realizada no corpo da resposta Corresponde ao cabeçalho de pedido Accept-Encoding Content-Encoding: gzip Mais cabeçalhos de entity Content-Length – o tamanho do corpo da entidade em bytes Este valor diminui quando a compressão é aplicada Content-Lenght: 24000 Content-Location – O URL real no caso da localização do recurso ser diferente do que o URL pedido Muitas vezes utilizado para mostrar um index ou página por omissão Content-Location:http://www.foo.com/home.html 12
  13. 13. 30-11-2010 Mais cabeçalhos de entity Content-Type – especifica o tipo de media do corpo da entidade (MIME) Corresponde ao cabeçalho Accept Content-Type: image/png Este é o cabeçalho mais importante para o browser. Este cabeçalho indica ao browser o tipo de dados que está a receber. Server: file extension -> Mime type Browser: Mime type -> acção (mostrar, descarregar) Sem o Mime Type o browser tem em conta apenas a extensão do ficheiro Carregar um ficheiro do disco Exemplo de utilização Ás vezes é necessário classificar os dados de saída do servidor com um MIME type apropriado Mais cabeçalhos de entity: relacionado com cache Expires – atribui uma data a partir da qual a cache se torna obsoleta Expires: Sat, 31-May-08 19:00:00 GMT Last-Modified – Data/hora em que a entidade foi modificada pela última vez Last-Modified: Fri 30-May-07 09:00:00 GMT Etag – identificador único de um determinado recurso Utilizado com pedidos condicionais para validar instâncias do recurso em cache If-Match, If-None-Match Etag: adkskdashjgk07563AF 13
  14. 14. 30-11-2010 A importância dos cabeçalhos Poderá ser necessário ir mais além do que o básico controlo de cache: Prazos para Expirar os conteúdos E outro tipo de dicas para controlo de cache Em último caso, poderá ser necessário modificar as “query strings” de forma a acabar com problemas de caches mal configuradas. Enviar dados sobre o HTTP Os dados podem ser primariamente enviados de 2 formas: Envio de uma “Query String” através de pedidos GET Envio dos dados através de pedidos POST Em ambos os casos, os dados são enviados de uma forma especial chamada x-www-form-urlencoded que irá substituir os espaços pelo carácter + os caracteres especiais pelo seu valor em hexadecimal e separa os argumentos individuais a serem enviados com o &. Enviar os dados via método GET Neste caso podemos ver os dados submetidos no URL do pedido que estamos a realizar. Os dados enviados são apelidados de “Query String” e está depois do ponto de interrogação (?) No URL Exemplo: http://www.utad.pt/index.php?aluno=al12556 Exemplo: http://www.utad.pt/index.php?anodematricula=2 Este tipo de envio tem algumas desvantagens como: A tecnologia está mais exposta - (reconhecimento visual) É fácil encontrar os parâmetros É mais difícil de manter a longo prazo O tamanhos dos dados a enviar está condicionado pelo tamanho do URL Apesar disto os URLs baseados no método GET são portáveis – é possível fazer o bookmark da página, enviar por msn, etc. 14
  15. 15. 30-11-2010 Enviar os dados via método GET Os dados enviados pelo método GET podem ser submetidos de 2 formas: Escrita no próprio link <a href=“http://www.utad.pt/index.php?aluno=al12556”> Como resultado de uma submissão: <form action= href=http://www.utad.pt/index.php method=“get”> <label>Aluno: <input type=“text” name=“aluno” /></label> <input type=“submit” value=“Submit” /> </form> Enviar os dados via método GET O exemplo abaixo exemplifica quais as querys strings e a maneira como são formadas Enviar os dados via método GET Os dados são enviados no próprio pedido 15
  16. 16. 30-11-2010 Enviar os dados via método POST No caso do método POST podemos gerar os pedidos programando-os ou, de uma forma mais fácil, através de formulários <form action=“http://www.fakesite.com/cgi-bin/submitquery. pl” method=“post”> Query: <input type=“text” name=“query” /> <input type=“submit” value=“Submit” /> </form> O pedido POST envia os dados no corpo da mensagem mas também de acordo com x-www-form-urlencoded . Sendo assim podemos ter um corpo de mensagem como: Name=Al+Smith&Age=30&Sex=male Não existe tamanho limite para os dados a enviar, no entanto existem alguns problemas com os browsers, por exemplo o refresh da página. Enviar os dados via método POST Um análise ao pedido mostra as diferenças entre os pedidos POST e GET Quais as diferenças Os métodos GET e POST têm utilizações diferentes O GET é utilizado quando pedidos múltiplos podem ter a mesma resposta. O método POST deve ser utilizado quando é modificado o estado do servidor. Muitos programadores utilizam o GET para modificar o estado do servidor porque é mais fácil Problemas – os estados do servidor podem ser alterados inadvertidamente por spiders, browsers, etc. 16
  17. 17. 30-11-2010 Considerações acerca do HTTP O protocolo HTTP é stateless Não existe memória de um pedido para o próximo Como podemos aceder a informação de pedidos anteriores? Hidden filds nos formulários que são enviados para o cliente Dados nas URLs strings Cookies Session cookies ou cookies persistentes Adaptado de: Credits to Prof. Thomas A. Powell (http://classes.pint.com/) 17

×