1 of 20
2 of 20
3 of 20
4 of 20
5 of 20
6 of 20
7 of 20
8 of 20
9 of 20
10 of 20
11 of 20
12 of 20
13 of 20
14 of 20
15 of 20
16 of 20
17 of 20
18 of 20
19 of 20
20 of 20

site

doc

blog

success stories

Blog

Request: a jornada da requisição

Alguma vez você já ficou pensando sobre como funciona a internet por trás de todo o hardware interconectado? É um processo complicado que envolve não apenas o hardware, mas também uma variedade de sistemas e software.

Vamos nos focar em duas partes (o cliente e o servidor) que se comunicam entre si na internet. No nível superior desse intercâmbio, um cliente - por exemplo, um dispositivo - faz uma requisição de conteúdo na forma de dados, enquanto o servidor é responsável por entregar ao cliente o conteúdo solicitado.

Cada request, ou requisição em português, deve percorrer um longo caminho desde que sai de seu dispositivo, chega até os servidores e volta com uma resposta. Neste artigo, mais um da série que trata sobre conceitos básicos da edge computing, vamos explicar mais detalhes dessa jornada. Você também vai descobrir como a Plataforma de Edge Computing da Azion torna o processo mais rápido e eficiente, se comparada a outras soluções.

Como é respondida uma requisição na internet: passo a passo

Para criar uma rede é necessário conectar dois ou mais dispositivos computacionais que, por sua vez, podem estar conectados a um dispositivo central, como um servidor, ou a um sistema intermediário, como um router. Essa rede também pode criar conexões com outras redes para transmitir informações entre elas. Dessa forma, podemos considerar a internet como a maior das redes, na qual diferentes redes menores, provedores de serviços e dispositivos se comunicam entre si para atender às necessidades de conectividade que existem hoje.

Para poder criar uma rede interconectada de escala global, e garantir que ela funcione eficientemente, é necessário definir alguns modelos, conceitos e protocolos para padronizar os serviços da internet. Oferecer uma “linguagem comum”, para que todos os elementos envolvidos no processo possam se entender e atuar adequadamente.

Modelo OSI

Um desses esforços é o modelo OSI (Open System Interconnection), que divide o funcionamento da internet em 7 camadas:

De acordo com esse modelo, a interação entre usuários e computadores acontece na camada 7 (também chamada de camada de aplicação - application layer). Com essa ideia em mente, começaremos a definir o caminho que nossas requisições percorrem.

A jornada simplificada

Resumindo, essa é —da forma mais simplificada possível— a rota que segue uma requisição:

O início

O usuário envia uma requisição. Pode ser desde fazer uma busca no navegador, enviar um e-mail, fazer uma transferência bancária, até reproduzir o episódio mais recente de sua série favorita.

Próxima parada: protocolos DNS e HTTP

Da mesma forma que você precisa especificar os dados do destinatário para que uma carta chegue até seu destino, você deve enviar uma requisição que inclua todos os dados necessários para que seja resolvida corretamente e, assim, obter uma resposta adequada na internet.

Nessa fase, estão envolvidos dois protocolos. Um deles é o protocolo DNS (Domain Name System). Podemos dizer que as máquinas entendem melhor os números, então cada website, servidor ou rede está identificado com um endereço IP composto por uma série de números. Atualmente, os endereços IP podem ter dois formatos, dependendo da versão que o sistema está usando:

  • IPv4: a primeira versão dos endereços IP. Esses endereços são um número de 32 bits, dividido em quatro grupos de até três números. Por exemplo: 203.0.113.42.
  • IPv6: na versão mais recente, os endereços IP são um número de 128 bits, composto por seções de 16 bits, separados por dois pontos (:) e que usa uma notação hexadecimal. Por exemplo: 2001:0002:14:5:1:bf35:2610.

No entanto, é difícil para os usuários lembrar esses números. Por esse motivo, são usados os domínios, já que são compostos por nomes e estruturas mais fáceis de serem lembradas, como www.google.com ou www.azion.com. Explicado de uma forma mais simples, o protocolo DNS “traduz” a URL que você escreveu para essa série de números para que sua requisição possa ser entendida pela máquina e encaminhada até o destino adequado.

O protocolo HTTP (Hypertext Transfer Protocol, ou Protocolo de Transferência de Hipertexto em português) é o outro protagonista aqui. Sua função é facilitar a comunicação, já que usa padrões e regras predeterminados para fazer esse intercâmbio de informações sem dificuldades.

A primeira coisa é saber “para onde você quer ir” ou o que você quer consultar, e escrever o endereço do site ou URL (https://www.azion.com/, por exemplo) no browser. Para facilitar o processo de comunicação entre as duas partes, o protocolo HTTP oferece sua lógica de requisição-resposta:

  • Após escrever a URL (que o DNS tornará em um endereço IP para que a máquina entenda), a requisição é enviada usando um header (ou cabeçalho) que contém informações como:
    • o método: que indica o que você quer fazer, como obter, enviar, atualizar ou deletar informações;
    • a rota a seguir pela requisição, para chegar até uma página ou completar uma tarefa específica;
    • a versão do protocolo que está sendo usada;
    • o request body (corpo de dados) e headers contém informações adicionais como, por exemplo, sua localização ou preferências de idioma para lhe mostrar conteúdo específico ou customizado.
  • Quando o servidor resolve a requisição, envia para você uma resposta usando códigos de status. Por exemplo, um código 200 significa que o processo foi bem sucedido e agora você pode ver o conteúdo solicitado; também poderia mostrar um código 401 quando a requisição não foi autorizada pelo servidor, o famoso 404 quando o conteúdo solicitado não existe ou um código 501 quando o servidor experimenta um erro interno.

Mas antes de chegar até o servidor, uma última etapa precisa ser concluída…

Onde as conexões acontecem: BGP e Anycast

Cada uma dessas redes menores que compõem a internet, pode ser considerada um sistema autônomo (Autonomous System ou AS, em inglês). Para que os AS possam se comunicar entre si (seja internamente entre AS do mesmo provedor ou com AS de redes externas) foi desenvolvido o Border Gateway Protocol (BGP). Esse protocolo ajuda a definir qual é o melhor caminho que a requisição deve percorrer para chegar até o servidor adequado, de acordo com as políticas e regras de interconexão que foram configuradas pelos administradores para o intercâmbio de informações entre os AS.

Quando você envia uma requisição, seu dispositivo se conecta com uma rede e o BGP decide dinamicamente (quer dizer, enquanto vai encaminhando a requisição pode tomar decisões) as rotas que a requisição vai seguir, no mesmo estilo do GPS. Com ajuda dos routers, responsáveis por transportar o pacote de dados com a requisição, são criadas conexões entre os AS habilitados para se comunicar entre si até chegar ao servidor que possui as informações solicitadas.

Para cumprir essa tarefa, o BGP pode usar diferentes métodos para o roteamento da requisição:

  • unicast: existe apenas uma rota e um destino;
  • multicast: pode escolher entre vários destinos, mas são limitados e específicos;
  • anycast: também pode encaminhar a requisição até diferentes destinos, mas pode fazê-lo usando outros critérios que permitem escolher uma rota mais próxima e eficiente até o servidor que esteja disponível, mais saudável e mais perto do lugar onde a requisição foi gerada.

O conteúdo de um site pode estar armazenado em vários servidores e, com o método anycast, o protocolo BGP escolhe uma rota que leva até o servidor que o possui e que esteja mais próximo do usuário. Dessa forma, a requisição é resolvida rapidamente, já que os dados devem percorrer uma distância mais curta.

É assim que, finalmente, a requisição chega até o servidor e é resolvida; imediatamente, uma resposta é enviada pelo servidor, usando os códigos de status HTTP e seguindo o mesmo processo, mas na direção oposta. E tudo isso acontece em milissegundos!

Mais perto do usuário, mais rápido

Nas primeiras fases da internet, as requisições tinham que viajar até um servidor central onde estavam armazenadas as informações; isto implicava em demora para receber as respostas, um processo bastante tedioso e com uma comunicação praticamente nula entre as redes. Ao longo dos anos, surgiram soluções para melhorar a interconectividade, bem como novos e modernos equipamentos e dispositivos. Também se espalhou o uso de data centers e, posteriormente, nasceu a cloud computing, que possibilitou acelerar e virtualizar muitas tarefas na internet.

No entanto, a principal desvantagem desses modelos computacionais é que são centralizados, tornando-os em um ponto único de falha. Em outras palavras, se eles forem afetados por algum problema, ataque ou falha, perdem a conexão e não podem ser acessados. Além disso, embora sejam capazes de armazenar e processar enormes quantidades de dados, ainda ficam longe dos usuários finais, gerando alta latência, assim como um alto consumo de recursos e largura de banda para responder às requisições.

A introdução das CDNs (content delivery network, ou redes de distribuição de conteúdo em português) no final da década de 90 foi um grande passo na tentativa de corrigir alguns desses problemas. Uma CDN é composta por uma rede de pontos de presença (PoPs) distribuídos em diferentes localidades e localizados estrategicamente mais perto dos usuários, se comparado com os modelos tradicionais. Com os nodes ou servidores perto dos usuários, a requisição deve percorrer viagens mais curtas, pelas quais a resposta chega até o usuário mais rapidamente. Mas, você consegue imaginar que isso poderia ser ainda mais rápido e eficiente? Essa é a proposta da edge computing.

O princípio da edge computing é distribuir uma grande quantidade de recursos computacionais mais perto dos usuários para poder atender suas requisições com uma latência menor, já que os dados devem percorrer viagens mais curtas para serem processados. Para isso, a infraestrutura da edge computing é altamente descentralizada e está composta por edge locations amplamente distribuídas geograficamente.

Usando esse desenho, a rede pode atender rapidamente aos usuários e encaminhar suas requisições automaticamente até o node mais próximo, mas também até um node que seja o mais eficiente e esteja mais saudável no caso de um pico na demanda ou se algum servidor não estiver disponível. Dessa forma, as requisições já não devem ir até a cloud ou infraestrutura de origem. Além disso, facilita o processamento de dados em tempo real, indispensável para aplicações time-sensitive e de missão crítica.

Como uma requisição é resolvida no jeito Azion?

Um dos focos da Plataforma de Edge Computing da Azion é a otimização da entrega de conteúdo. Dessa forma, seus usuários podem se conectar a suas aplicações e sites para desfrutar de tudo o que você oferece com rapidez, segurança e sem interrupções, proporcionando uma excelente experiência. Para isso, oferecemos aos nossos clientes uma série de produtos e ferramentas que lhes permitem implementar, controlar, monitorar, escalar e automatizar o funcionamento de recursos no edge, em tempo real.

Infraestrutura descentralizada e distribuída

Se você quiser pedir seu prato favorito e o restaurante que o prepara fica no lado oposto da cidade, com certeza o pedido vai demorar bastante até chegar à sua casa e você vai ficar faminto e irritado. O mesmo acontece na internet, quando a requisição do usuário é respondida por um servidor que fica longe: o usuário deve aguardar para obter uma resposta, o que pode gerar fricção e até abandono do site. Ninguém quer aguardar, ainda mais hoje que já estamos tão acostumados a completar tarefas online em um piscar de olhos.

Agora imagine que o restaurante abra várias filiais, estrategicamente distribuídas pela cidade. Seu prato favorito está a dois blocos de distância, assim quando você o pedir na filial do seu bairro, chega rápido até sua porta. Uma das principais vantagens da edge computing é, precisamente, ter uma infraestrutura distribuída e descentralizada que permite estar bem perto do usuário. Dessa forma, as requisições podem ser atendidas rapidamente, com baixa latência e um menor consumo de largura de banda.

A Edge Network da Azion tem mais de 65 edge locations distribuídas ao redor do mundo. Não importa onde estejam seus usuários, com nossa rede você pode entregar conteúdo eficientemente, porque você pode atender suas requisições da edge location mais próxima, com melhor saúde e disponível o tempo todo.

Na Azion também usamos Intelligent DNS, que aproveita nossa infraestrutura global e o uso de anycast para estabelecer as rotas mais eficientes para encaminhar a requisição até o melhor destino possível. Isso garante que, quando começar a jornada de uma requisição feita por um usuário de qualquer um de nossos clientes e chegar à nossa rede, a edge location mais próxima desse usuário o atenderá.

Load Balancer da Azion

A jornada da requisição na internet não é linear. Uma requisição pode pegar atalhos ou fazer zig-zags entre diferentes subredes. Já vimos que o BGP, em conjunto com o anycast, é responsável por criar diferentes rotas para serem atendidas pelo servidor mais adequado. No entanto, existem diversos fatores que podem afetar uma rota, além da rapidez com que ela é resolvida. Podemos sinalizar duas situações clássicas que geram dores de cabeça aos administradores de qualquer rede: os picos de uso e quando um servidor ou qualquer outro componente da rede não está funcionando.

Por exemplo, datas como Black Friday, Cyber Monday ou Natal podem atrair um número exponencialmente maior de visitantes para suas aplicações ou sites. Isto pode sobrecarregar o servidor, que vai demorar no atendimento aos clientes e, talvez, parar de funcionar porque não é capaz de lidar com essa quantidade de trabalho. Esse cenário pode ser catastrófico para a reputação e para a receita da marca, já que essa experiência pode gerar desconforto em muitos clientes. Uma das formas de lidar com essa situação e evitar qualquer problema é tendo um load balancer (ou balanceador de carga). Essa ferramenta vai ser responsável por distribuir os workloads entre os diferentes nodes da rede para que nenhum servidor seja sobrecarregado.

O Load Balancer da Azion pode balancear o tráfego entre as edge locations mais próximas dos usuários, enquanto atende às requisições no edge, evitando qualquer congestionamento. Para isso, oferece múltiplos algoritmos de distribuição que permitem escolher o melhor método para seus servidores. Usando o Load Balancer, seus usuários não terão que “fazer fila” e aguardar até serem atendidos por um único servidor; ao invés disso, as requisições são distribuídas de uma forma mais inteligente por toda a rede, sem afetar a performance do serviço.

Edge Caching da Azion

O caching, ou armazenamento em cache, é outro método que pode ajudar no aceleramento da jornada de uma requisição. É o armazenamento de cópias de seu conteúdo e recursos que os usuários acessam com frequência em locais facilmente acessíveis.

Ter uma cópia do conteúdo na mão evita que a requisição viaje até a cloud ou infraestrutura de origem, tendo que baixar os dados cada vez que a página ou a aplicação sejam visitadas. A Edge Network da Azion também permite realizar esse processo muito mais perto do usuário, diretamente no próprio edge.

Acelere suas aplicações

Vivemos em um mundo hiperconectado que está se movendo cada vez mais rápido. E nenhum usuário tem vontade de esperar para receber resposta de nenhuma marca, então eles não hesitam em ir para o concorrente. Agora que você entende como são resolvidas as requisições na internet, você também sabe que não é uma tarefa fácil. No entanto, ter parceiros como a Azion não ajuda apenas a atender seus usuários e suas requisições, mas também possibilita que você tenha à sua disposição uma ampla gama de ferramentas e produtos que ajudarão a tornar a jornada das requisições um processo mais rápido e eficiente. Saiba mais sobre nossos produtos ou fale com o nosso time de especialistas para começar a criar o plano de serviço perfeito para as necessidades da sua empresa.