Protocolo de Transferência de Hipertexto
Função | Transmissão de hipertexto |
---|---|
Acrônimo | HTTP |
Data de criação | 1990 |
Porto | 80 |
RFC |
1996 : RFC 1945 1997 : RFC 2068 1999 : RFC 2616 2014 : RFC 7230 a 7237 2015 : RFC 7540 |
O ' Protocolo de Transferência de Hipertexto (HTTP, literalmente "hipertexto deprotocolo de transferência ") é umprotocolo de comunicação cliente-servidordesenvolvido para a World Wide Web . HTTPS(com S para seguro , ou seja, “seguro”) é a variante segura que usa os protocolos Transport Layer Security (TLS).
HTTP é um protocolo da camada de aplicativo . Ele pode funcionar em qualquer conexão confiável; na verdade, o protocolo TCP é usado como a camada de transporte. Um servidor HTTP usa a porta 80 por padrão (443 para HTTPS).
Os clientes HTTP mais conhecidos são navegadores da web que permitem ao usuário acessar um servidor que contém os dados. Também existem sistemas para recuperar automaticamente o conteúdo de um site, como aspiradores de pó ou rastreadores de sites .
O HTTP foi inventado por Tim Berners-Lee com endereços da web e HTML para criar a World Wide Web . Naquela época, o File Transfer Protocol (FTP) já estava disponível para a transferência de arquivos, mas não suportava a noção de formato de dados introduzida por Multipurpose Internet Mail Extensions (MIME). A primeira versão do HTTP era muito básica, mas já incluía suporte para cabeçalhos MIME para descrever os dados transmitidos. Essa primeira versão ainda é parcialmente utilizável hoje, conhecida como HTTP / 0.9.
Dentro Maio de 1996, HTTP / 1.0 foi lançado e é descrito no RFC 1945. Esta versão oferece suporte a servidores HTTP virtuais, gerenciamento de cache e identificação.
Dentro janeiro de 1997, HTTP / 1.1 eventualmente se torna um padrão IETF . É descrito na RFC 2068 da IETF, depois na RFC 2616 emJunho de 1999. Esta versão adiciona suporte para pipelining (ou pipelining) e negociação de tipo de conteúdo (formato de dados, idioma).
Dentro março de 2012, o trabalho em HTTP / 2.0 está começando na IETF, adotando o SPDY como material de partida.
Dentro fevereiro de 2014, a especificação para HTTP 1.1 foi republicada. Ele foi dividido em vários RFCs e corrigido para todas as suas imprecisões, RFC 7230 a RFC 7237.
No protocolo HTTP, um método é um comando que especifica um tipo de solicitação, ou seja, solicita que o servidor execute uma ação. Em geral, a ação diz respeito a um recurso identificado pela URL após o nome do método.
Na ilustração ao lado, uma solicitação GET é enviada para recuperar a página inicial do site www.perdu.com:
GET / HTTP/1.1 Host: www.perdu.comExistem muitos métodos, sendo os mais comuns GET, HEAD e POST:
GET Este é o método mais comum para solicitar um recurso. Uma solicitação GET não tem efeito sobre o recurso, deve ser possível repetir a solicitação sem efeito. HEAD Este método solicita apenas informações sobre o recurso, sem solicitar o próprio recurso. POST Este método é usado para transmitir dados para processamento a um recurso (na maioria das vezes de um formulário HTML). O URI fornecido é o URI de um recurso ao qual os dados enviados serão aplicados. O resultado pode ser a criação de novos recursos ou a modificação de recursos existentes. Devido à má implementação de métodos HTTP (para Ajax ) por alguns navegadores (e o padrão HTML que suporta apenas métodos GET e POST para formulários), este método é frequentemente usado como um substituto para a solicitação PUT, que deve ser usada para atualização Recursos. OPTIONS Este método é utilizado para obter as opções de comunicação de um recurso ou do servidor em geral. CONNECT Este método permite que um proxy seja usado como um túnel de comunicação. TRACE Este método pede ao servidor para retornar o que recebeu, a fim de testar e diagnosticar a conexão. PUT Este método permite substituir ou adicionar um recurso no servidor. O URI fornecido é o do recurso em questão. PATCH Este método permite, ao contrário do PUT, fazer uma modificação parcial de um recurso. DELETE Este método permite excluir um recurso do servidor.Esses três últimos métodos geralmente requerem acesso privilegiado.
Alguns servidores permitem outros métodos de gerenciamento de seus recursos (por exemplo, WebDAV ).
A conexão entre o cliente e o servidor nem sempre é direta, podendo haver máquinas intermediárias servindo como retransmissores:
O HTTP permite a identificação do visitante através da transmissão de um nome e uma senha . Existem 2 modos de identificação: Básico e Resumo ( RFC 2617). O primeiro modo transmite a senha em claro e, portanto, só deve ser usado com o protocolo HTTPS. O segundo modo permite a identificação sem transmitir a senha em claro. A identificação, entretanto, é freqüentemente realizada por uma camada de aplicativo superior ao HTTP.
No início da World Wide Web , foi planejado adicionar recursos de negociação de conteúdo ao protocolo HTTP, inspirando-se em particular no MIME . Até então, o protocolo HTTP 0.9 era extremamente simples.
Solicitação:
GET /page.htmlO método GETé o único possível. O servidor reconhece que está lidando com uma solicitação HTTP 0.9 porque a versão não é especificada após o URI.
Responder :
<html> <head> <title>Exemple</title> </head> <body> <p>Ceci est une page d'exemple.</p> </body> </html>Para responder a uma solicitação HTTP 0.9, o servidor envia o conteúdo da resposta diretamente, sem metadados. Ele nunca deve se comportar dessa maneira para solicitações HTTP de versão superior.
Não há necessidade de procurar versões inferiores a 0.9 do protocolo HTTP: elas não existem, porque o HTTP 0.9 inicialmente não tinha um número de versão. Ele teve que ser atribuído quando o HTTP 1.0 chegou.
HTTP 1.0O protocolo HTTP 1.0, descrito na RFC 1945, permite o uso de cabeçalhos especificados na RFC 822. O gerenciamento da conexão permanece idêntico ao HTTP 0.9: o cliente estabelece a conexão, envia uma solicitação, o servidor responde e fecha imediatamente a conexão.
Uma solicitação HTTP tem o seguinte formato:
Ligne de commande (Commande, URL, Version de protocole) En-tête de requête [Ligne vide] Corps de requêteAs respostas HTTP têm o seguinte formato:
Ligne de statut (Version, Code-réponse, Texte-réponse) En-tête de réponse [Ligne vide] Corps de réponseSolicitação:
GET /page.html HTTP/1.0 Host: example.com Referer: http://example.com/ User-Agent: CERN-LineMode/2.15 libwww/2.17b3A versão do protocolo HTTP é especificada após o URI. A solicitação deve ser encerrada com uma nova linha dupla ( CRLFCRLF ). HTTP 1.0 também suporta os métodos HEAD e POST. Podemos ver o uso de cabeçalhos inspirados em MIME para transferir metadados:
Host Usado para especificar o site da Web em questão, o que é necessário para um servidor que hospeda vários sites no mesmo endereço IP ( host virtual baseado em nome ). Este é o único cabeçalho realmente importante. Referer Indica o URI do documento que forneceu um link para o recurso solicitado. Este cabeçalho permite que os webmasters vejam de onde vêm os visitantes. User-Agent Indica o software usado para conectar. Normalmente, é um navegador da web ou rastreador da web .Responder :
HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-modified: Fri, 09 Aug 1996 14:21:40 GMT <TITLE>Exemple</TITLE> <P>Ceci est une page d'exemple.</P>A primeira linha fornece o código de status HTTP (200 neste caso).
Date Hora em que a mensagem é gerada. Server Indica qual modelo de servidor HTTP está respondendo à solicitação. Content-Type Indica o tipo MIME do recurso. Content-Length Indica o tamanho em bytes do recurso. Expires Indica quando o recurso deve ser considerado obsoleto; permite que os navegadores da web determinem por quanto tempo armazenar o recurso em cache . Last-Modified Indica a data da última modificação do recurso solicitado. HTTP 1.1O protocolo HTTP 1.1 é descrito pelo RFC 2616, o que torna o RFC 2068 obsoleto. A diferença com o HTTP 1.0 é um melhor gerenciamento de cache. O cabeçalho Host torna-se obrigatório nas solicitações.
As principais preocupações das duas primeiras versões do protocolo HTTP são, por um lado, o grande número de conexões ao carregar uma página complexa (contendo muitas imagens ou animações) e, por outro lado, o tempo de abertura de 'uma conexão entre o cliente e servidor ( estabelecer uma conexão TCP leva três vezes a latência entre o cliente e o servidor). Experimentos com conexões persistentes foram, no entanto, realizados com HTTP 1.0 (notavelmente pelo uso do cabeçalho Connection: Keep-Alive ), mas isso só foi desenvolvido definitivamente com HTTP 1.1.
Por padrão, o HTTP 1.1 usa conexões persistentes, ou seja, a conexão não é fechada imediatamente após uma solicitação, mas permanece disponível para uma nova solicitação. Esse recurso geralmente é conhecido como keep-alive . Também é permitido a um cliente HTTP enviar várias solicitações na mesma conexão sem esperar por respostas. Esse recurso é chamado de pipelining . A persistência das conexões permite acelerar o carregamento de páginas com diversos recursos, ao mesmo tempo que reduz a carga na rede.
O gerenciamento da persistência de uma conexão é feito pelo cabeçalho Connection .
HTTP 1.1 oferece suporte à negociação de conteúdo. Um cliente HTTP 1.1 pode acompanhar a solicitação de um recurso de cabeçalhos indicando quais idiomas e formatos de dados são preferidos. Esses são cabeçalhos cujos nomes começam com Aceitar- .
Os cabeçalhos adicionais compatíveis com HTTP 1.1 são:
Connection Este cabeçalho pode ser enviado pelo cliente ou servidor e contém uma lista de nomes especificando as opções a serem usadas com a conexão atual. Se uma opção tiver parâmetros, eles serão especificados pelo cabeçalho com o mesmo nome da opção ( Keep-Alive, por exemplo, para especificar o número máximo de solicitações por conexão). O nome close é reservado para especificar que a conexão deve ser fechada após o processamento da solicitação atual. Accept Este cabeçalho lista os tipos de conteúdo MIME aceitos pelo cliente. O caractere estrela * pode ser usado para especificar todos os tipos / subtipos. Accept-Charset Especifica as codificações de caracteres aceitas. Accept-Language Especifica os idiomas aceitos.A ordem de preferência de cada opção (tipo, codificação ou idioma) é especificada pelo parâmetro opcional q contendo um valor decimal entre 0 ( inaceitável ) e 1 ( aceitável ) inclusive (3 casas decimais no máximo após a vírgula), igual a 1 por padrão.
O suporte para conexões persistentes também deve funcionar nos casos em que o tamanho do recurso não é conhecido com antecedência (recurso gerado dinamicamente pelo servidor, fluxo externo ao servidor, etc.).
Para isso, a codificação de transferência denominada chunked permite que o recurso seja transmitido em pedaços consecutivos, cada um precedido por uma linha de texto dando seu tamanho em hexadecimal. A transferência termina com um bloco de tamanho zero, para o qual os cabeçalhos finais podem ser enviados.
Os cabeçalhos adicionais relacionados a esta codificação de transferência são:
Transfer-Encoding Especifica a codificação de transferência. O único valor definido pela especificação RFC 2616 é fragmentado . Trailer Lista todos os cabeçalhos que aparecem após a última música transferida. TE Enviado pelo cliente para especificar as codificações de conteúdo suportadas ( Content-Encoding , não deve ser confundido com Transfer-Encoding porque chunked é obrigatoriamente suportado por clientes e servidores que implementam o padrão HTTP / 1.1) e especifica se o cliente tem suporte. - Trailer cabeça adicionando trailers à lista. HTTP 1.1 bisO RFC 2616 incluía muitas imprecisões. O grupo de trabalho HTTP levou alguns anos para esclarecer a especificação sem modificar a semântica, conforme recomendado no estatuto operacional do grupo para este trabalho. Dentrojunho de 2014, 8 novos documentos foram publicados, tornando obsoleta a RFC 2616:
Uma nova versão do HTTP, HTTP / 2, foi desenvolvida dentro do grupo de trabalho Hypertext Transfer Protocol Bis (httpbis) da Internet Engineering Task Force , e aprovada como um padrão RFC no.18 de fevereiro de 2015. O desenvolvimento do HTTP / 2 começou após a criação do protocolo SPDY proposto pelo Google para reduzir o tempo de carregamento das páginas web. O grupo de trabalho httpbis inicialmente se absteve de propor uma nova versão do HTTP, concentrando sua atividade no esclarecimento das especificações do HTTP 1.1. Considerando a chegada do SPDY e sua rápida adoção na web, com implementações notadamente em dois dos principais navegadores da web , Google Chrome e Mozilla Firefox , Mark Nottingham, “presidente” da httpbis, expressou a opinião de que era hora de considerar o HTTP / 2 e propôs emendar o regulamento do httpbis nesse sentido, iniciando assim o desenvolvimento do novo protocolo.
SPDY foi uma opção natural para servir de base para HTTP / 2. Duas outras propostas concorrentes foram então enviadas à IETF: o protocolo “HTTP Speed + Mobility” da Microsoft e uma proposta para atualizar o HTTP (“Network-Friendly HTTP Upgrade”). DentroJulho de 2012, a httpbis publicou um convite à manifestação de interesse (“Convite à Manifestação de Interesse”) com o objetivo de recolher as opiniões dos Web players sobre as propostas. Entre as respostas obtidas está a do Facebook que indicou sua preferência pelo SPDY. Dentronovembro de 2012, a IETF lançou o primeiro rascunho do HTTP / 2, que é uma cópia direta do SPDY.
Após mais de 2 anos de discussões, o RFC é aprovado em fevereiro de 2015 pelo IETF Steering Group, e é publicado em Maio de 2015.
O módulo de suporte ao protocolo HTTP / 2 está disponível desde a versão 2.4.17 do servidor web Apache, e desde a versão 1.9.5 do Nginx.
HTTP / 3Uma nova versão do HTTP, HTTP / 3, é a terceira e próxima versão principal do protocolo de transferência de hipertexto usado para trocar informações na World Wide Web. Isso é baseado no protocolo QUIC, desenvolvido pelo Google em 2012.
A semântica HTTP é consistente de versão para versão. Isso ocorre porque os mesmos métodos de consulta, códigos de status e campos de mensagem são geralmente aplicáveis a todas as versões.
Enquanto HTTP / 1 e HTTP / 2 usam TCP como protocolo de transporte, HTTP / 3 usa QUIC, um protocolo de camada de transporte mais adequado para a web. A mudança para o QUIC visa resolver um grande problema de HTTP / 2 denominado "Bloqueio Head-of-line", graças a um encapsulamento dos pacotes em UDP. De fato, com HTTP / 2 baseado em TCP, uma conexão é composta de vários fluxos. Essa conexão é chamada de multiplexada. No entanto, quando um fluxo sofre perda de pacotes, toda a conexão fica mais lenta. Com o HTTP / 3 baseado no protocolo QUIC, não temos mais esse problema, pois todos os fluxos são independentes sendo encapsulados em UDP, um protocolo de transporte que não requer conexão.