Protocolo HTTP – Como funciona?

Neste artigo iremos nos aprofundar na estrutura do protocolo de comunicação que viabiliza a comunicação na WEB, o protocolo HTTP.

Protocolo HTTP

Hypertext Transfer Protocol, o HTTP é um protocolo de transferência de mensagens sobre Internet.

O protocolo HTTP rege a estrutura e define os tipos de mensagens trocadas entre os pares. Ele é definido pelas RFCs 1945 (versão 1.0) e 2116 com base na arquitetura cliente-servidor. 

As RFCs 2116 ficou obsoleta e uma nova RFC foi lançada, RFC 7231 (versão1.1). 

Ainda há as que definem o protocolo com criptografia TLS como a RFC 2817 (Upgrading to TLS Within HTTP/1.1).  

As RFCs que tratam a segunda versão do procotolo HTTP sem e com criptografia são respectivamente as RFCs 7540 e 8740. 

De forma breve e objetiva, a arquitetura cliente-servidor estabelece uma separação no nível de atuação, criando limites específicos para cada ponta da comunicação.

Cada ponta se preocupa em desempenhar apenas o seu papel correspondente, o restante é transparente.  

Arquitetura Cliente/servidor

Continuando … Os objetos web solicitados pelo cliente geralmente estão hospedados no servidor. 

Pode acontecer dos dados estarem armazenados em um SGBD separado fisicamente do servidor principal.

Ainda assim, uma vez que o servidor receba a requisição uma consulta é realizada ao SGBD retornando os objetos requisitados.  

Posteriormente, o servidor responderá com o conteúdo solicitado.  

Não há tratamento de perda de pacotes, ou seja, o servidor não precisa verificar se o cliente recebeu sua mensagem.

Isso permite menor overhead do servidor, garantindo maior performance.  

Além disto, o HTTP é um protocolo stateless, ou seja, não possui estado armazenado. Isso significa que caso haja repetição de solicitações não serão tratadas, já que o estado do cliente não é conhecido pelo servidor. 

Ele responderá a todas as mensagens, mesmo que sejam redundantes. Contudo, há situações em que será preciso manter um estado persistente.

Neste caso, utiliza-se os cookies. Para ler nosso artigo sobre cookies acesse o link.

Overview TCP

Dito isto, podemos definir os dois tipos de mensagens existentes em uma comunicação via HTTP.

As mensagens podem ser do tipo, request e response. Essa comunicação, ou seja, a envio de mensagens request e response ocorre por meio de um protocolo da camada de transporte denominado TCP.

O TCP – Transmission Control Protocol – é um protocolo que fornece suporte à perda de pacotes na camada de transporte do TCP/IP. 

Basicamente, dentro de uma transmissão TCP a informação é particionada de forma que haja um controle sobre os pacotes enviados.

Esse controle permite que o destino recomponha a informação de acordo com a sequência de pacotes. 

Na ocorrência de perda de pacote no caminho é possível solicitar ao remente que o pacote específico seja reenviado. 

Modos de comunicação do TCP

Vale salientar ainda, que o HTTP possui dois modos de comunicação: persistente e não-persistente. 

No caso do protocolo HTTP o tipo de comunicação utilizada é determinado no momento que o cliente envia sua requisição.

Geralmente, trata-se de uma comunicação não-persistente.  

O que isso quer dizer? Que toda vez que uma mensagem é enviada e recebida pelo destino, a conexão é encerrada.

Caso tivesse sido definida a comunicação persistente há um processo de estabelecimento e encerramento de conexão entre as partes. 

Iremos explorar este protocolo em um futuro artigo. Por hora, essa explicação é o suficiente para entendermos a dinâmica do HTTP.

HTTP REQUEST – ESTRUTURA 

Definimos as mensagens e como o protocolo opera. 

OK, mas como é organizada uma mensagem HTTP? Qual a sua estrutura? Basicamente, as mensagens HTTP Request são formadas por 3 campos: request line, header line e entity body.  

Campos HTTP Request

O primeiro campo, request line, corresponde a primeira linha do pacote contendo as informações de versão do protocolo e método utilizado. 

O método geralmente é acompanhado de um caminho que se encontra no servidor alvo.

A grande maioria dos casos de requisição HTTP o método utilizado é o denominado GET. 

Iremos ver com mais detalhes neste artigo, mas de forma resumida o GET solicita um objeto web ao servidor, por exemplo: uma página.  

O segundo campo, denominado header line, engloba a informação entre as segunda e quarta linhas do exemplo apresentado na Figura 2.

Observando cada linha verificamos que o endereço do host é determinado na estrutura, ou seja, o servidor ao qual será enviada a requisição.  

Além disso, a mensagem ainda define o tipo de conexão estabelecida entre as partes pelo parâmetro “connection”.

Este parâmetro está setado como “close”, ou seja, conexão TCP não-persistente.  

Outras informações que encontramos neste campo são: o agente e features de preferência do usuário.

Em nosso exemplo a solicitação foi realizada a partir de um navegador Mozilla na versão 5.0. 

Contudo, existem várias features que podem ser configuradas de acordo com a preferência do cliente.  

Em nosso exemplo, a feature apresentada corresponde ao parâmetro “accept-language:fr”. 

Essa determina a preferência do usuário com relação ao idioma adotado. 

Caso o servidor não possua a opção solicitada será enviado o modo default relacionado à feature. 

Métodos HTTP – GET e POST

Antes de continuarmos a falar sobre a estrutura da mensagem response, vamos voltar no tema de métodos existentes para o protocolo HTTP.

Neste artigo iremos citar alguns deles, caso o leitor queira se aprofundar em sua busca aconselho uma leitura sobre as RFCs aqui citadas.  

Falamos até agora brevemente do método GET. Contudo, ainda não definimos o que é um método HTTP. 

Pois bem … um método HTTP é um comando que irá informar ao servidor quais ações ele deverá executar para um determinado recurso.  

O método GET portanto, solicita ao servidor o envio dos objetos web de um determinado recurso, como por exemplo uma página.

Os objetos web são os elementos que compõem uma página, como: texto, imagem, vídeo e inclusive a página em si.  

Outro método bastante comum, não tanto quando o GET, é o método POST. Neste caso, o cliente está submetendo uma informação ao servidor.

O servidor por sua vez recebe e trata esta informação que é enviada encapsulada no campo entity body da mensagem. 

Um exemplo intuitivo do método POST seria o preenchimento de um formulário, ou de um cadastro em um site de compras.  

Restrição de acesso com POST

Repare que como o servidor é obrigado a tratar a informação de post, muitos sites colocam limitações a este método. 

Um usuário malicioso poderia utilizar este campo para enviar um Trojan, ou um código malicioso a ser executado no servidor.

Por isso, caso você tente realizar uma requisição do tipo POST por um agente que não seja um navegador, por exemplo: uma API JAVA, essa requisição retornará um erro de não permissão. 

Para saber mais sobre alguns destes métodos acima citados, acesse o artigo Métodos HTTP clique aqui.

HTTP Response – Estrutura

Até agora falamos sobre mensagens HTTP do tipo Request e seus campos.

Mas qual a estrutura de uma mensagem HTTP Response? 

O servidor pode executar uma série de ações em background (visão do usuário) em decorrência de uma requisição.

Podemos citar como exemplo as querys realizadas junto ao banco de dados com objetivo retornar os dados solicitados.  

As ações executadas no servidor irão variar de acordo com o método utilizado (cliente) e configuração do servidor.

De uma forma geral, uma mensagem HTTP do tipo RESPONSE possui três campos: Status Line, header Lines, Entity Dody. 

Esses três campos são apresentados na figura abaixo, mas vamos descrever cada um deles.  

Campos HTTP Response

O primeiro item da nossa lista é o Status Line. Nesta linha temos informado pelo servidor a versão do protocolo HTTP, que em nosso exemplo é o 1.1.

Além disso, o status code da mensagem. Esse dado que nos informa se uma solicitação foi respondida com sucesso (200 ok).

Caso contrário, havendo algum erro, o status code correspondente estará descrito na mensagem.

Iremos entrar em mais detalhes sobre o status code posteriormente em outro artigo do site.

O Header lines descreve as informações de estrutura/configuração da mensagem, os metadados. 

Já falamos que o HTTP utiliza conexões TCP. Neste caso o servidor está respondendo da mesma forma que o cliente (em nosso exemplo anterior) com uma conexão não persistente.

Temos ainda informações sobre o pedido como data, e servidor remetente, nosso caso uma Apache 2.2.3 instalado em uma máquina CentOS.

Por fim os tamanho e tipo do conteúdo são informações relacionadas aos dados. Da mesma forma, o campo última modificação também corresponde aos dados.

Contudo, você pode estar se perguntando, “Por que enviar na mensagem a última modificação da página?

Esa informação será estremamente útil quando lidarmos com cache. Esse assunto ficará em stand by por enquanto, e será abordado em outro artigo.

Como ocorre uma conexão HTTP? 

Já mencionamos que a conexão ocorre via protocolo da camada de trasnporte TCP de maneira não persistente.

Isso significa, que basta o usuário enviar uma requisição para iniciar a conexão. Essa requisição será respondida pelo servidor com o conteúdo solicitado.

Em caso de erro, ou inexistncia do conetúdo uma mensagem de erro será enviada.

Exemplo GET

Vamos citar duas exemplos ara os métodos principais: GET e POST.

Suponha este exemplo: Um usuário A (Alice) está navegando na internet e acessa a página da amazon pela primeira vez.

Alice estará solicitando o conteúdo da página ao servidor. Neste caso, qual o método utilizado?

A solicitação de Alice será encaminhada em uma mensagem request com o método GET defindo.

O pacote contendo a Request HTTP possui basicamente a URL alvo do método, ex: GET: https://www.amazon.com; o host de destino; o tipo de conexão, que gerelamente é não persistente (close); e o agente do usuário utilizado na ação, em nosso caso o browser mozilla.

Ao receber este mensagem, o servidor irá verificar seus arquivos, banco de dados e outros repositórios para entregar o conteúdo pedido.

Uma vez que este conteúdo é encontrado, uma mensagem do tipo response é enviado ao cliente.

A Response HTTP retorna os objetos web dentro de seu campo entity body. Em nosso exemplo será a página inicial da amazon.

Contudo, o conteúdo não se restringe apenas à página. Campos de controle como header line e status line (descritos anteriormente) definem o metadados deste pacote.

Exemplo POST

De maneira similar, o POST é enviado pelo usuário. Contudo, seu objetivo é bem diferente.

O método POST implica em submeter ao servidor algum conteúdo que está contido no campo Entity Body.

Além disso, o servidor é obrigado a tratar, lidar com aquele conteúdo. Por isso, pode haver restrições como mencionado anteriormente.

Suponha que desta vez, Alice irá preencher um formulário de cadastro no site da amazom.

Dessa forma, o usuário (Alice) envia um pacote contendo a Request HTTP com o conteúdo de seu formulário.

Ao receber este mensagem, o servidor irá verificar seus arquivos, banco de dados e outros repositórios para entregar o conteúdo pedido.

Uma vez que este conteúdo é encontrado, uma mensagem do tipo response é enviado ao cliente.

Os campos varim de acordo com o formulário, contudo, um agregado de informações será enviado ao servidor.

Após receber e identificar a request com método POST, o servidor irá tratar o conteúdo do Entity Body.

Uma verificação e posterior atualização do banco de dados será realizada. Neste caso, a requisição POST ocasionou uma sucessão de querys no banco de dados backend.

Caso a atualização de conteúdo seja bem sucedida, uma mensagem do tipo Response HTTP será enviada com dados semelhantes ao exemplo anterior (método GET).

Caso contrário, o cliente ainda receberá a resposta. Contudo, podendo identificar o tipo de erro que ocorreu pelo status code da mensagem.

Veja mais:

HTTP Client – Requisições GET e POST com API JAVA

Métodos HTTP

Cookies – Protocolo HTTP

Apache HTTPS Server configurar

Instalar APACHE em WINDOWS 

Instalação de servidores em Docker

Referências Bibliográficas

• Kurose, James F., and Keith W. Ross. “Redes de Computadores e a Internet.” Pearson – 6° edição
• Tanenbaum, Andrew et al. “Redes de Computadores.”  Editora Pearson – 5° edição.a Pearson – 5° edição.