O HTTP funciona como um protocolo de requisicao-resposta no modelo computacional cliente-servidor . Um navegador web , por exemplo, pode ser o cliente e uma aplicacao em um computador que hospeda um sitio da web pode ser o servidor . O cliente submete uma mensagem de requisicao HTTP para o servidor. O servidor, que fornece os recursos , como arquivos HTML e outros conteudos, ou realiza outras funcoes de interesse do cliente, retorna uma mensagem resposta para o cliente. A resposta contem informacoes de estado completas sobre a requisicao e pode tambem conter o conteudo solicitado no corpo de sua mensagem.

Um navegador web e um exemplo de agente de usuario (AU). Outros tipos de agentes de usuario incluem o software de indexacao usado por provedores de consulta ( web crawler ), navegadores vocais , aplicacoes moveis e outros software que acessam, consomem ou exibem conteudo web.

O HTTP e projetado para permitir intermediacoes de elementos de rede para melhorar ou habilitar comunicacoes entre clientes e servidores. Sites web de alto trafego geralmente se beneficiam dos servidores de cache web que entregam conteudo em nome de servidores de upstream para melhorar o tempo de resposta. Navegadores web armazenam os recursos web acessados anteriormente e reutilizam-nos quando possivel para reduzir o trafego de rede. Servidores proxy HTTP nas fronteiras de redes privadas podem facilitar a comunicacao para o cliente sem um endereco globalmente roteavel, transmitindo mensagens com servidores externos.

Basicamente, o HTTP define como clientes Web requisitam paginas Web aos servidores e como elas as transferem a clientes. Quando um usuario solicita uma pagina Web (acessa uma URL), o navegador envia ao servidor mensagens de requisicao HTTP para os objetos da pagina. O servidor, por sua vez, recebe estas requisicoes e responde com mensagens de resposta HTTP que contem os objetos (...). O protocolo HTTP utiliza por padrao a porta 80 para comunicacao (MACEDO et al., 2018). ^{[ 5 ]}

O HyperText Transfer Protocol e um protocolo de aplicacao responsavel pelo tratamento de pedidos e respostas entre cliente e servidor na World Wide Web . Ele surgiu da necessidade de distribuir informacoes pela Internet e para que essa distribuicao fosse possivel foi necessario criar uma forma padronizada de comunicacao entre os clientes e os servidores da Web e entendida por todos os computadores ligados a Internet. Com isso, o protocolo HTTP passou a ser utilizado para a comunicacao entre computadores na Internet e a especificar como seriam realizadas as transacoes entre clientes e servidores, atraves do uso de regras basicas.

Este protocolo tem sido usado pela WWW desde 1990. A primeira versao de HTTP, chamada HTTP/0.9, era um protocolo simples para a transferencia de dados no formato de texto ASCII pela Internet, atraves de um unico metodo de requisicao, chamado GET . A versao HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de transferir nao apenas texto. Com essa versao, o protocolo passou a transferir mensagens do tipo MIME44 ( Multipurpose Internet Mail Extension ) e foram implementados novos metodos de requisicao, chamados POST e HEAD .

No HTTP/1.1, versao do protocolo descrito na RFC 2616 , ^{[ 6 ]} foi desenvolvido um conjunto de implementacoes adicionais ao HTTP/1.0, como por exemplo: o uso de conexoes persistentes; o uso de servidores proxy que permitem uma melhor organizacao da cache ; novos metodos de requisicoes; entre outros. Afirma-se que o HTTP tambem e usado como um protocolo generico para comunicacao entre os agentes de utilizadores e proxies / gateways com outros protocolos, como o SMTP , NNTP , FTP , Gopher , e WAIS , permitindo o acesso a recursos disponiveis em aplicacoes diversas. ^{[ 6 ]}

O HTTP/2 foi publicado como RFC 7540 em maio de 2015.

Uma sessao HTTP e uma sequencia de transacoes de rede de requisicao-resposta. Um cliente HTTP inicia uma requisicao estabelecendo uma conexao Transmission Control Protocol (TCP) para uma porta particular de um servidor (normalmente a porta 80. Veja Lista de portas dos protocolos TCP e UDP ). Um servidor HTTP ouvindo naquela porta espera por uma mensagem de requisicao de cliente. Recebendo a requisicao, o servidor retorna uma linha de estado, como "HTTP/1.1 200 OK", e uma mensagem particular propria. O corpo desta mensagem normalmente e o recurso solicitado, apesar de uma mensagem de erro ou outra informacao tambem poder ser retornada.

O termo cookie e derivado do ingles que significa biscoito. Recebeu esse nome de uma antiga giria usada pelos programadores que consistia em um programa que chamava um procedimento e recebia de volta algo que seria necessario apresentar novamente mais tarde para realizar algum trabalho. Foi criado pela Netscape para solucionar o problema do envio e solicitacao de arquivos, que eram esquecidos pelo servidor e que poderiam ser usados por outros computadores com o mesmo IP conforme (TANEMBAUM, 2003), o que causava problemas, pois nao se sabia na realidade se era ou nao aquele usuario mesmo. Os cookies sao arquivos ou strings e nao sao programas executaveis. Eles sao tratados como dados pelo navegador, nao existe nenhuma maneira dele ser usado como virus, apesar de que podem ser explorados bugs no servidor e causar a ativacao de um cookie como virus, por um hacker. Basicamente ele e um grupo de dados trocados entre o servidor de paginas e o navegador colocado em um ficheiro criado no computador do usuario. Serve para manter a persistencia das sessoes HTTP. Ele funciona da seguinte forma: Um usuario solicita uma pagina da Web, nisso o servidor pode fornecer informacoes adicionais acompanhando a pagina solicitada. Essas informacoes podem incluir um cookie, um pequeno arquivo ou string (com quatro KB no maximo). Este cookie pode ter ate 5 campos (figura abaixo): Domain, Path, Content, Expires, Secure. Domain informa de onde veio o cookie. O navegador confirma que os servidores estao enviando dados fieis a respeito de seu dominio. Cada dominio pode armazenar no maximo 20 cookies por cliente. O campo Path e um caminho na estrutura de diretorios do servidor que identifica as partes da arvore de arquivos do servidor que podem usar o cookie. Frequentemente, ele obtem o simbolo / (barra), que representa a arvore inteira. O campo Content utiliza a forma nome = valor, podendo o servidor definir da maneira que quiser tanto o valor quanto o nome, e e nele que fica armazenado o conteudo do cookie. Expires e o campo que faz o cookie persistir, nele contem a data e o horario, e se ele estiver ausente o navegador descartara automaticamente apos o termino da sessao. O ultimo campo define se ele e seguro ou nao.

Figura x: Alguns exemplos de cookie.?Fonte: (TANEMBAUM, 2003).

O cookie e usado para identificar um usuario que configurou uma pagina web, para que na proxima vez que ele entrar ela esteja configurada do modo em que ele deixou. Pode ser usado tambem quando se faz a solicitacao de armazenamento de senha, na vez posterior em que entrar no site, a sua senha sera lembrada. E usado tambem em sites de compra, como e-commerce, armazenando os produtos que o cliente colocou no carrinho para que no final da compra nao necessite fazer todo o processo novamente.

Um sistema de comunicacao em rede possui diversos protocolos que trabalham em conjunto para o fornecimento de servicos. Para que o protocolo HTTP consiga transferir seus dados pela Web, e necessario que os protocolos TCP e IP ( Internet Protocol , Protocolo de Internet) tornem possivel a conexao entre clientes e servidores atraves de sockets TCP/IP .

De acordo com Fielding, ^{[ 7 ]} o HTTP utiliza o modelo cliente-servidor , como a maioria dos protocolos de rede, baseando-se no paradigma de requisicao e resposta. Um programa requisitante (cliente) estabelece uma conexao com um outro programa receptor (servidor) e envia-lhe uma requisicao, contendo a URI , a versao do protocolo, uma mensagem MIME (padrao utilizado para codificar dados em formato de textos ASCII para serem transmitidos pela Internet) contendo os modificadores da requisicao, informacoes sobre o cliente e, possivelmente, o conteudo no corpo da mensagem.

O servidor responde com uma linha de status ( status line ) incluindo sua versao de protocolo e com os codigos de erro informando se a operacao foi bem sucedida ou fracasso, seguido pelas informacoes do servidor, metainformacoes da entidade e possivel conteudo no corpo da mensagem. Apos o envio da resposta pelo servidor, encerra-se a conexao estabelecida.

O protocolo HTTP faz a comunicacao entre o cliente e o servidor por meio de mensagens. O cliente envia uma mensagem de requisicao de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitacao. Segundo Foscarini, ^{[ 8 ]} os dois tipos de mensagens existentes no protocolo utilizam um formato generico, definido na RFC 822 , para a transferencia de entidades.

Uma mensagem, tanto de requisicao quanto de resposta, e composta, conforme definido na RFC 2616 , ^{[ 9 ]} por uma linha inicial, nenhuma ou mais linhas de cabecalhos, uma linha em branco obrigatoria finalizando o cabecalho e por fim o corpo da mensagem, opcional em determinados casos. Nessa sessao serao apresentados os campos que compoem uma mensagem mais detalhadamente; ou seja, o HTTP apresenta o sitio ou local onde esta a pagina da Internet.

Cabecalho da mensagem editar

O cabecalho da mensagem ( header ) e utilizado para transmitir informacoes adicionais entre o cliente e o servidor. Ele e especificado imediatamente apos a linha inicial da transacao (metodo), tanto para a requisicao do cliente quanto para a resposta do servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabecalhos que poderao ser incluidos na mensagem os quais sao: general-header , request-header , response-header e entity-header . ^{[ 10 ]}

Esses cabecalhos sao utilizados para enviar informacoes adicionais sobre a mensagem transmitida ( general-header ), a requisicao e os clientes ( request-header ) que comunicam suas configuracoes e os formatos de documentos desejados como resposta. ^{[ 11 ]} Alem disso, sao utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente, para transmitir informacoes que descrevem as configuracoes do servidor e do recurso identificado pelo URI de requisicao, e que nao pertence a linha de status ( response-header ). Na RFC 2616 , ^{[ 12 ]} estao descritos todos os campos que pertencem a esses cabecalhos.

Corpo da mensagem editar

Uma mensagem HTTP pode conter um corpo de dados que sao enviados abaixo das linhas de cabecalho. Em uma mensagem de resposta, o corpo da mensagem e o recurso que foi requisitado pelo cliente, ou ainda uma mensagem de erro, caso este recurso nao seja possivel. Ja em uma mensagem de requisicao, o corpo pode conter dados que serao enviados diretamente pelo usuario ou um arquivo que sera enviado para o servidor. Quando uma mensagem HTTP tiver um corpo, poderao ser incluidos cabecalhos de entidades que descrevem suas caracteristicas, como por exemplo, o Content-Type que informa o tipo MIME dos dados no corpo da mensagem e o Content-Length que informa a quantidade de bytes que o corpo da mensagem contem. A tabela ao lado apresenta alguns tipos MIME.

Requisicao editar

De acordo com Fielding, ^{[ 14 ]} uma mensagem de requisicao do cliente e composta pelos seguintes campos: uma linha inicial ( Request-Line ); linhas de cabecalhos ( Request-header ); uma linha em branco obrigatoria e um corpo de mensagem opcional. A linha inicial de uma requisicao e composta por tres partes separadas por espacos: o metodo ( Method ), a identificacao do URI ( Request-URI ) e a versao do HTTP ( HTTP-Version ) utilizado.

Segundo Bastos & Ladeira, ^{[ 15 ]} Request-URI e um identificador uniforme de recurso (Uniform Resource Identifier) que identifica sobre qual recurso sera aplicada a requisicao. No protocolo HTTP, o tipo de URI utilizado e chamado de URL (Uniform Resource Locator), composto pela identificacao do protocolo, pelo endereco do computador servidor e pelo documento requisitado. ^{[ 16 ]}

O protocolo HTTP define oito metodos (GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS e CONNECT) que indicam a acao a ser realizada no recurso especificado. Conforme Bastos e Ladeiras, ^{[ 17 ]} o metodo determina o que o servidor deve fazer com o URL fornecido no momento da requisicao de um recurso. Um servidor HTTP deve implementar ao menos os metodos GET e HEAD. Os metodos GET e POST sao os que aparecem mais comumente durante o desenvolvimento web .

Uma solicitacao HTTP , ou HTTP Request e uma maneira do navegador mostrar uma pagina da internet utilizando um dos oito metodos de solicitacao do protocolo HTTP. ^{[ 18 ]}

Alem de solicitar um determinado arquivo, envia varias informacao para o servidor, sendo elas: o seu IP , a versao do navegador que esta usando, que pagina utilizou para pedir a HTTP Request e a idioma que voce usa, entre outros. ^{[ 18 ]}

GET editar

O metodo GET requisita uma representacao do recurso especificado. Requisicoes usando GET devem apenas recuperar dados e nao devem ter qualquer outro efeito. (Isto tambem e verdade para alguns outros metodos HTTP.) O W3C publicou principios de orientacoes sobre esta distincao, "O projeto de aplicacoes web devem ser informados pelos principios acima, mas tambem por limitacoes relevantes."

Abaixo segue um exemplo de uma comunicacao entre um cliente e um servidor HTTP. O servidor possui a URL www.exemplo.com , porta 80.

O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um newline duplo, cada um composto por um carriage return seguido de um Line Feed ):

GET /index.html HTTP/1.1
Host: www.exemplo.com

O cabecalho Host reconhece varios diferentes nomes DNS que tenham o mesmo IP .

A resposta do servidor (seguida por uma linha em branco e o texto da pagina solicitada):

HTTP/1.1 200 OK
Date: Mon, 23?May 2005?22:38:34 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

HEAD editar

Variacao do GET em que o recurso nao e retornado. E usado para obter metainformacoes por meio do cabecalho da resposta, sem ter que recuperar todo o conteudo.

POST editar

Envia dados para serem processados (por exemplo, dados de um formulario HTML) para o recurso especificado. Os dados sao incluidos no corpo do comando. Sua utilizacao em uma requisicao ocorre quando e necessario enviar dados ao servidor para serem processados, geralmente por um programa script identificado no Request-URI . Uma requisicao por meio desse metodo sempre requer que as informacoes submetidas sejam incluidas no corpo da mensagem e formatadas como uma query string , alem de conter cabecalhos adicionais especificando seu tamanho ( Content-Length ) e seu formato ( Content-Type ). Por isso, esse metodo oferece uma maior seguranca em relacao aos dados transferidos, ao contrario do metodo GET que os dados sao anexados a URL, ficando visiveis ao usuario. ^{[ 19 ]} Por exemplo:

 POST /index.html HTTP/1.0
 Accept: text/html
 If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 41

 Nome=NomePessoa&Idade=99&Curso=Computacao

PUT editar

O metodo PUT envia os dados de forma semelhante ao POST, atraves do corpo do HTTP a diferenca entre os 2 metodos e semantica. Por exemplo:

Caso voce necessite atualizar os dados de um usuario, utilizando o metodo PUT voce pode os atualizar diversas vezes, pois o PUT vai sobrescrever os dados com isso ficara somente com um unico registro atualizado.

Se voce executasse este mesmo procedimento utilizando o metodo POST, voce criaria diversos registros para cada requisicao realizada.

DELETE editar

Exclui o recurso.

TRACE editar

Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediarios estao mudando em seu pedido.

OPTIONS editar

Recupera os metodos HTTP que o servidor aceita.

CONNECT editar

Serve para uso com um proxy que possa se tornar um tunel SSL e TLS (um tunel pode ser usado, por exemplo, para criar uma conexao segura).

Ver tambem: Lista de codigos de status HTTP

Do HTTP/1.0 em diante, a primeira linha da resposta HTTP e chamada linha de estado e inclui um codigo de estado numerico (como " 404 ") e uma frase de razao textual (como "Not Found" - Nao Encontrado). A maneira que o agente de usuario manipula a resposta depende primeiramente do codigo e secundariamente nos cabecalhos de resposta . Codigos de estado personalizados podem ser usados, uma vez que, se o agente de usuario encontrar um codigo que ele nao reconheca, ele pode usar o primeiro digito do codigo para determinar a classe geral da resposta.

Da mesma forma, as frases de razao padroes sao apenas recomendacoes e podem ser substituidas com "equivalentes locais" a criterio do desenvolvedor web. Se o codigo de estado indicou um problema, o agente de usuario pode mostrar a frase de razao para o usuario, para que sejam fornecidas informacoes adicionais sobre a natureza do problema. O padrao tambem permite que o agente de usuario tente interpretar a frase de razao , apesar disto poder ser imprudente uma vez que o padrao especifica explicitamente que os codigos de estado sao legiveis por maquina e as frases de razao sao legiveis por homens.

No HTTP/0.9 e 1.0, a conexao e fechada apos um unico par de requisicao/resposta. No HTTP/1.1 um mecanismo de persistencia de vida (keep-alive) foi introduzido, onde uma conexao pode ser reutilizada para mais de uma requisicao. Tais conexoes persistentes reduzem a latencia de requisicao perceptivel, pois o cliente nao precisa renegociar a conexao TCP apos a primeira requisicao ter sido enviada. Outro efeito colateral positivo e que em geral a conexao se torna mais rapida com o tempo devido ao mecanismo de inicio-lento do TCP.

A versao 1.1 do protocolo tambem faz melhoras na otimizacao de comprimento de banda para o HTTP/1.0. Por exemplo, o HTTP/1.1 introduziu a codificacao de transferencia em partes para permitir que o conteudo em conexoes persistentes sejam transmitidos em vez de armazenados temporariamente para posterior transmissao. O pipelining HTTP reduz ainda mais o tempo de atraso, permitindo que os clientes enviem varias requisicoes antes de esperar por cada resposta. Outra melhoria para o protocolo foi o byte serving , onde um servidor transmite apenas a porcao de um recurso solicitado explicitamente por um cliente.

O HTTP e um protocolo sem estado . Um protocolo sem estado nao exige que o servidor HTTP retenha informacoes ou estado sobre cada usuario para a duracao de varias solicitacoes. Entretanto, algumas aplicacoes web implementam estado ou sessoes do lado servidor usando um ou mais de um dos metodos a seguir:

• Variaveis ocultas dentro de formularios web ;
• Cookies HTTP ;
• Parametros de query string , por exemplo, /index.php?session_id=algum_codigo_unico_de_sessao.

Para Fielding, ^{[ 20 ]} uma mensagem de resposta do servidor e composta pelos seguintes campos: uma linha inicial ( Status-Line ); linhas de cabecalhos ( Responseheader ); uma linha em branco obrigatoria e um corpo de mensagem opcional. A linha inicial de uma resposta, chamada de linha de status, possui por sua vez tres partes separadas por espacos: a versao do protocolo HTTP ( HTTP-Version ), um codigo de status ( Status-Code ) da resposta, que fornece o resultado da requisicao, e uma frase de justificativa ( Reason-Phrase ) que descreve o codigo do status.

Codigos de retorno editar

A linha inicial de uma resposta HTTP indica ao cliente se sua requisicao foi bem sucedida ou nao. ^{[ 21 ]} Essa situacao e fornecida atraves de um codigo de retorno ( Status-Code ) e uma frase explicativa ( Reason-Phrase ). De acordo com Fielding, ^{[ 22 ]} o codigo de status e formado por tres digitos e o primeiro digito representa a classe que pertence classificada em cinco tipos:

• 1xx : Informational (Informacao) ? utilizada para enviar informacoes para o cliente de que sua requisicao foi recebida e esta sendo processada;
• 2xx : Success (Sucesso) ? indica que a requisicao do cliente foi bem sucedida;
• 3xx : Redirection (Redirecionamento) ? informa a acao adicional que deve ser tomada para completar a requisicao;
• 4xx : Client Error (Erro no cliente) ? avisa que o cliente fez uma requisicao que nao pode ser atendida;
• 5xx : Server Error (Erro no servidor) ? ocorreu um erro no servidor ao cumprir uma requisicao valida.

O protocolo HTTP define somente alguns codigos em cada classe descritos na RFC 2616 , mas cada servidor pode definir seus proprios codigos.

Conexoes editar

Segundo Hirata, ^{[ 23 ]} o HTTP/1.0 e um protocolo sem estado. Isto significa que as conexoes entre um cliente e um servidor sao encerradas apos o envio de cada requisicao ou resposta. Cada vez que uma conexao e estabelecida ou encerrada, e consumida uma grande quantidade de tempo da CPU, de largura de banda e de memoria.

Na maioria das vezes, para se obter o resultado esperado, e necessario realizar mais de uma solicitacao de recursos atraves de varias conexoes. Por exemplo, no caso de uma pagina Web, que consiste de diversos arquivos (.html, .gif, .css, etc.) e preciso que sejam feitas varias requisicoes para compor a pagina, uma conexao nao-persistente. O ideal seria que apenas uma conexao fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, a sobrecarga ocasionada pelas conexoes, uma conexao persistente.

A conexao persistente, implementada como conexao padrao no protocolo HTTP/1.1, possibilita que uma conexao seja estabelecida para enviar varias requisicoes em sequencia sem a necessidade de esperar por cada resposta, no qual serao recebidas na mesma ordem em que as solicitacoes foram enviadas, um processo chamado de pipelining . ^{[ 24 ]} Pode tambem dar-se o caso de ser estabelecida uma conexao sem pipelining , em que o cliente so faz nova requisicao quando o servidor lhe envia a resposta, ou seja, o servidor fica inactivo ate o objecto (.html, .gif, .css, etc) atingir o seu destino no cliente.

Se uma requisicao incluir o cabecalho Connection: close , a conexao sera encerrada apos o envio da resposta correspondente. Utiliza-se este cabecalho quando nao ha suporte a conexoes persistentes, quando for a ultima requisicao a ser enviada nesta conexao, ou ainda, sempre que quiser encerrar a conexao mesmo que nem todas as requisicoes tenham sido completadas. Alem disso, o servidor pode fechar uma conexao se estiver ociosa por um determinado periodo de tempo.

Outros protocolos editar

Existem outros tipos de protocolos como o FTP (File Transfer Protocol, ou Protocolo de Transferencia de Arquivos), usado para envio de arquivos do computador para um servidor na Web, o SMTP (Simple Mail Transfer Protocol, ou Protocolo de Transferencia de Correio Simples), protocolo usado para correio eletronico , entre outros protocolos.

Pedido basico de HTTP cliente-servidor:

GET <ficheiro> HTTP/1.1
Host: <ip>
User-Agent: <Agente>
Connection: <tipo>

O agente e quem faz a ligacao ao servidor, normalmente um navegador . O tipo indica como o servidor deve proceder com a conexao. E comumente utilizado para requisicoes persistentes.

Uma requisicao completa pode exigir muitas informacoes. A requisicao abaixo - utilizando o metodo POST - fora retirada do Mozilla Firefox v3.6b5 (pt-BR, para Windows):

POST /diretorio/arquivo.html HTTP/1.1
Host: www.exemplo.com
User-Agent: Mozilla/5.0 (Windows; U; 
Windows NT
 6.1; pt-BR; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-alive: 115
Cookie: nome=valor; nome2=valor2
Connection: keep-alive
Content-Length: 28

usuario=exemplo&senha=123456

• HTTP/2 - Revisao do HTTP baseada no SPDY
• HTTP/3 - Revisao do HTTP baseada no QUIC
• HTTP referrer
• Hyper Text Transfer Protocol Secure (HTTPS)
• Internet Relay Chat
• Lista de codigos de status HTTP
• QUIC ? Protocolo de aplicacao que usa o UDP no lugar do TCP
• Representational State Transfer (REST)
• Sistema de Arquivos Interplanetario
• SPDY ? Um aprimoramento do HTTP proposto pela Google
• Telnet
• Web cache
• WebSockets
• World Wide Web (WWW)

• T. Berners-Lee, R. Fielding, H. Frystyk (maio de 1996). ≪Hypertext Transfer Protocol -- HTTP/1.0≫ (em ingles). Internet Engineering Task Force . Consultado em 21 de junho de 2009 . Arquivado do original em 5 de maio de 2005   !CS1 manut: Nomes multiplos: lista de autores ( link )
• BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.
• cf. 46 HERRMANN, Eric. Aprenda em 1 semana programacao CGI em Perl 5. Rio de Janeiro: Campus, 1997
• MACEDO, R. T. et al. Redes de computadores. 1. ed, 2018, Santa Maria, RS. p.?139.

• ≪Desenvolvimento do protocolo HTTP≫ (em ingles)  
• ≪Desmistificando o protocolo HTTP≫