Quando se trata de HTTP, o primeiro pensamento que vem à mente é sobre como usar internet, é o cenário onde realmente vemos o uso do HTTP na prática. Nós acessamos sites onde seus endereços começam com http: // e, portanto, precisamos saber o que realmente está acontecendo ao fazer isso.
No momento em que você acessou este repositório, entre o navegador e o GitHub aconteceu uma comunicação, e essa comunicação tem duas partes bem conhecidas que chamamos client-server ou em Português Cliente-Servidor.
Toda a internet é baseada nesta arquitetura onde há um cliente que solicita e um servidor que responde.
Cliente (navegador como Chrome ou Firefox) -> Internet -> Servidor (usando PHP, JAVA ou NET entre outros)
Como em qualquer comunicação. devesse haver algumas regras para que as duas partes possam se entender com sucesso. Pensando na comunicação do seu navegador com o Git ou algum outro site este conjunto de regras é basicamente um protocolo, onde neste cenário é HTTP.
Os protocolos são definidos, especificados e disponibilizados para implementação em ambas as partes, para consultar a especificação HTTP, você pode usar o seguinte endereço: https://tools.ietf.org/html/rfc2616
Cliente (navegador como Chrome ou Firefox) -> Regras de comunicação? -> Servidor (usando PHP, JAVA ou NET entre outros)
HTTP é um protocolo que define as regras de comunicação entre cliente e servidor na internet.
Cliente (navegador como Chrome ou Firefox) -> HTTP (protocolo) -> Servidor (usando PHP, JAVA ou NET entre outros)
✔️ Na internet sempre existe um cliente e um servidor
✔️ Deve haver regras de comunicação entre o cliente e o servidor
✔️ As regras são definidas dentro de um protocolo
✔️ HTTP é o protocolo mais importante da internet
✔️ Por padrão, os dados são trafegados como texto simples na web.
✔️ Somente com HTTPS a web é segura
✔️ O protocolo HTTPS nada mais é do que o protocolo HTTP mais uma camada adicional de segurança, TLS / SSL
✔️ O tipo de criptografia de chave pública / chave privada
✔️ O que são certificados digitais?
✔️ Os certificados têm identidade e validade
✔️ As chaves públicas estão no certificado, a chave privada está apenas no servidor
✔️ O que é uma autoridade de certificação?
A autoridade de certificação (CA), também conhecido como um Autoridade de Certificação, é uma empresa ou organização que atua para validar as identidades de entidades (como sites, endereços de email, empresas ou pessoas físicas) e vinculá-las a chaves criptográficas através da emissão de documentos eletrônicos conhecidos como certificados digitais. Um certificado digital fornece:
Autenticação, servindo como credencial para validar a identidade da entidade para a qual é emitida.
Criptografia, para comunicação segura em redes inseguras, como a Internet.
Integridade de documentos assinado com o certificado para que não possam ser alterados por terceiros em trânsito.
✔️ URL são os endereços da web
✔️ Um URL começa com o protocolo (por exemplo https: //) seguido pelo domínio (https://github.com)
✔️ Depois que o domínio pode vir a porta, se não estiver definida, a porta padrão deste protocolo é usada
✔️ Após o domínio: porta, o caminho para um recurso é especificado (/ devgabrieldejesus / http-basics)
✔️ Um recurso é algo concreto no aplicativo que queremos acessar
✔️ O protocolo HTTP segue o modelo Solicitação-Resposta
A comunicação realizada pelo HTTP segue o modelo cliente-servidor, baseando-se nos conceitos de request (pedido) e response (resposta). Um request corresponde a um pedido feito ao servidor. Uma mensagem de requisição do cliente é composta pelos seguintes campos de maneira geral:
Linha de pedido: formada pelo identificador do método HTTP (GET, POST, PUT, DELETE, etc.), URI do recurso (endereço para o qual será enviado o pedido) e versão do protocolo (geralmente, HTTP 1.1 e HTTP 2);
Cabeçalho: contém meta-informações sobre a requisição, como a identificação do cliente que está fazendo o pedido;
Corpo: contém os dados da requisição.
Já o response corresponde à resposta que é enviada pelo servidor. Geralmente, ele é composto dos seguintes componentes:
Linha de status: contém informações como a versão do protocolo utilizado no servidor, código numérico do status da resposta e o texto associado ao status;
Cabeçalho: é bem similar ao cabeçalho do pedido, ou seja, contém meta-informações e informações adicionais sobre o seu pedido e conteúdo de resposta;
Corpo: conteúdo de resposta para a requisição realizada (no caso de acesso a um site, seria o HTML para que o browser renderize a página, por exemplo).
De fato, essa comunicação baseada nesse modelo cliente/servidor é extremamente rápida e eficiente. Porém, existe um problema grande: toda essa comunicação que ocorre através do protocolo HTTP é baseada em texto puro, o que é completamente inseguro. E aqui entra o HTTPS.
✔️ Sempre é o cliente que inicia a comunicação
✔️ Um pedido deve ter todas as informações para o servidor gerar a resposta
✔️ HTTP não tem estado, não guarda informações entre as solicitações
Cada página visitada gera um novo par de requisição/resposta), duas estratégias podem ser usadas, já que o HTTP por si só, não permite guardar o estado das requisições e respostas:
Você possui um cadastro no site e um programa escrito no servidor é responsável por armazenar suas informações ; ou
Um programa escrito em linguagem cliente (como JavaScript), gerencia essas informações através dos cookies e de bancos de dados que os próprios navegadores disponibilizam para as aplicações, para armazenamento temporário dessas informações.
✔️ Cabeçalho de resposta
✔️ Códigos de resposta (código de status)
Usado para definir os detalhes da pesquisa ou enviar dados do formulário
✔️ GET: Receber dados (Os parâmetros são enviados na própria URL (usando [?] E concatenando com [&])
✔️ POST: Enviar dados (Parâmetros no corpo da solicitação)
✔️ DELETE: Remover um recurso
✔️ PUT / PATCH: Atualizar um recurso
✔️ REST é um padrão arquitetônico para comunicações entre aplicativos
✔️ Os recursos são definidos via URI
Em alguns cabeçalhos HTTP, devemos especificar algum formato. Os formatos são chamados na documentação dos tipos MIME. E na definição do cabeçalho usamos a seguinte estrutura: tipo / subtipo. Os tipos conhecidos são:
texto, imagem, aplicativo, áudio e vídeo
E alguns subtipos:
text -> text / plain, text / html, text / css, text / javascript
Imagem -> imagem / gif, imagem / png, imagem / jpeg
Audio -> audio / midi, audio / mpeg, audio / webm, audio / ogg, audio / wav
video -> video / mp4
Application -> application / xml, application / pdf
HTTP 2 (originalmente chamado de HTTP/2.0) é uma revisão importante do protocolo de rede HTTP usado pela World Wide Web. Ele foi derivado do protocolo SPDY experimental anterior, originalmente desenvolvido pelo Google.
HTTP 2 foi desenvolvido pelo Grupo de Trabalho HTTP (também chamado de httpbis, onde “bis” significa “segundo”) da Força-Tarefa de Engenharia da Internet.
HTTP 2 é a primeira nova versão de HTTP desde HTTP 1.1, padronizado no RFC 2068 em 1997.
O Grupo de Trabalho submeteu HTTP 2 ao IESG para consideração como um padrão proposto em dezembro de 2014, e o IESG aprovou a publicação como um padrão proposto em 17 de fevereiro de 2015.
A especificação HTTP 2 foi publicada como RFC 7540 em 14 de maio de 2015.