Dawi o protocolo-http
-
Upload
carolina-espirito-santo -
Category
Documents
-
view
129 -
download
2
Transcript of Dawi o protocolo-http
30-11-2010
1
O PROTOCOLO HTTP
Desenvolvimento de aplicações Web I
É 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)
30-11-2010
2
HTTP e TCP/IP
HTTP
TCP
IP
Interfaces de Rede
O HTTP está no topo da stack do protocolo TCP/IP
Layer de Aplicação
Layer de Transporte
Layer de Rede
Layer de dados
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
30-11-2010
3
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
Os segmentos são enviados
para o destino correcto
dentro dos datagramas IP
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
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
30-11-2010
4
Ciclo básico Pedido/Resposta HTTP
Pedir um determinado recurso através do seu URLhttp://www.exemplo.com/cont1.hmtl
HTTP REQUEST
HTTP RESPONSE
http://www.exemplo.com
Recursocont1.html
Servidor HTTP
ClienteHTTP
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
30-11-2010
5
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
30-11-2010
6
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…
30-11-2010
7
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/xwww-
form-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
30-11-2010
8
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?
30-11-2010
9
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
30-11-2010
10
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.
30-11-2010
11
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_gziphttpzip, 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
30-11-2010
12
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
30-11-2010
13
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
30-11-2010
14
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 “querystrings” 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.
30-11-2010
15
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 querysstrings e a maneira como são formadas
Enviar os dados via método GET
� Os dados são enviados no próprio pedido
30-11-2010
16
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.
30-11-2010
17
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/)