Da comunicação em rede ao processamento de uma requisição em um API Gateway
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Apresentação do capítulo
corporativas parecem, à primeira vista, uma tecnologia concentrada na camada de aplicação: um consumidor envia uma requisição, um serviço executa uma operação e devolve uma resposta. Entretanto, essa visão esconde uma cadeia extensa de mecanismos. Antes de um método chegar ao , o nome do host precisa ser resolvido, pacotes precisam ser roteados, uma conexão precisa ser estabelecida, parâmetros criptográficos precisam ser negociados e políticas de segurança podem ser avaliadas em diferentes componentes da infraestrutura.
Este capítulo apresenta essa cadeia de maneira progressiva. O objetivo não é transformar o leitor imediatamente em especialista em redes, mas fornecer um modelo mental suficientemente preciso para compreender onde uma chamada pode falhar, qual componente possui cada responsabilidade e por que tecnologias como , , , e dependem de fundamentos anteriores. Nos capítulos seguintes, cada uma dessas áreas será explorada em profundidade.
A abordagem combina contexto histórico, teoria de protocolos e aplicação prática em ambientes corporativos. Sempre que possível, o texto relaciona os conceitos a plataformas como Axway e Azure Management. Os exemplos utilizam uma fictícia de clientes bancários para demonstrar o caminho completo da comunicação sem expor detalhes de ambientes reais.
Como estudar este capítulo
Leia as seções em sequência na primeira passagem. Depois, refaça a leitura acompanhando o diagrama ponta a ponta e tente classificar cada possível falha pela camada em que ela ocorre. Essa prática prepara o raciocínio de usado por equipes de e integração.
Objetivos de aprendizagem
Distinguir Internet, Web, , e , evitando o uso desses termos como sinônimos.
Explicar como padrões técnicos são definidos por organizações como , Editor, ,
IEEE, , OpenID Foundation e Initiative.
Compreender , endereçamento, roteamento, portas, conexões, resolução de
nomes e proteção criptográfica em nível conceitual.
Descrever o caminho completo de uma requisição desde o consumidor até um
protegido por um .
Identificar responsabilidades típicas de firewalls, balanceadores, , , provedores de
identidade e serviços de .
Usar o modelo de camadas para organizar investigações de erros de , , , ,
autenticação, roteamento e aplicação.
Estrutura do capítulo
1.1 Por que fundamentos de rede importam para
1.2 Internet, Web e : conceitos diferentes
1.3 Evolução histórica da Internet às plataformas de
1.4 Ecossistema de padronização
1.5 : como os protocolos são documentados
1.6 Comunicação em rede e
1.7 Modelos OSI e /
1.8 Endereçamento e roteamento
1.9 e resolução de nomes
1.10 , , portas e
1.11 , firewall, e balanceamento
1.12 , e confiança
1.13 Anatomia de uma mensagem
1.14 e o conceito de recurso
1.15 e plataforma de
1.16 Jornada ponta a ponta
1.17 orientado por camadas
1.18 Aplicação em ambientes corporativos e bancários
Resumo, exercícios, glossário e referências
1.1 Por que fundamentos de rede importam para
Uma equipe de trabalha na interseção entre desenvolvimento, infraestrutura, identidade e segurança. O recebe mensagens de aplicação, mas a disponibilidade desse ponto de entrada depende de elementos que existem antes da aplicação: , rotas, endereços, portas, conexões e certificados. Por isso, um erro observado como "a não responde" pode ter causas completamente diferentes, desde um nome que não resolve até uma política que rejeita um .
A mesma resposta também pode esconder origens distintas. Um código 502 pode indicar que o não conseguiu estabelecer comunicação com o ; um 401 normalmente se relaciona à autenticação, mas pode ser produzido pelo próprio , por um provedor de identidade ou pelo serviço; um pode ocorrer no consumidor, no balanceador, no ou no . Sem uma visão de camadas, o diagnóstico tende a virar tentativa e erro.
O conhecimento fundamental também melhora decisões de arquitetura. Ao compreender onde a confidencialidade é garantida, o arquiteto consegue diferenciar proteção de transporte e proteção da própria mensagem. Ao entender conexão e sessão, consegue avaliar efeitos de , e terminação . Ao compreender resolução de nomes, consegue projetar , múltiplos ambientes e estratégias de descoberta de serviços com menos suposições incorretas.
Neste material, a expressão "fundamentos" não significa conteúdo superficial. Significa estudar os mecanismos que sustentam as tecnologias mais visíveis. 2.0, , OpenID Connect, e políticas de serão mais fáceis de compreender quando estiver claro o que ocorre antes, durante e depois da transmissão de uma requisição.
Aplicação no trabalho
Quando um consumidor informa que recebe , a pergunta inicial não deve ser apenas "qual política do falhou?". Primeiro, determine se houve resolução , estabelecimento , negociação e chegada da requisição ao listener do . Só depois avance para , autenticação e roteamento.
1.2 Internet, Web e : conceitos diferentes
Internet
A Internet é uma infraestrutura global formada pela interconexão de redes independentes. Cada organização pode operar seus próprios enlaces, roteadores, sistemas autônomos e políticas, mas a comunicação é possível porque os participantes adotam protocolos comuns. O termo internet, em sentido genérico, significa uma rede de redes; Internet, com inicial maiúscula, costuma designar o sistema público global que utiliza a família de protocolos .
O funcionamento da Internet é descentralizado. Não existe um único servidor central que encaminhe todas as mensagens. Operadores de telecomunicações, provedores de nuvem, empresas, universidades e governos administram partes da infraestrutura. O roteamento entre essas partes permite que pacotes atravessem múltiplas redes até alcançar o destino. Essa característica explica por que latência, perda de pacotes e caminhos assimétricos podem variar mesmo quando cliente e servidor não mudam.
World Wide Web
A Web é um sistema de recursos interligados que utiliza a Internet como infraestrutura. Ela foi concebida em torno de identificadores de recursos, representações transferidas entre clientes e servidores e links que conectam documentos. Navegadores e servidores web popularizaram o , mas a Internet já existia antes da Web e continua transportando muitos protocolos que não pertencem à Web.
Dizer que uma é acessada pela Web geralmente significa que ela usa tecnologias associadas à Web, especialmente , e formatos como . Isso não transforma toda em uma página web. A interface pode ser consumida por aplicativos móveis, sistemas batch, dispositivos, microsserviços ou parceiros, sem qualquer interação humana por navegador.
e
é uma interface criada para permitir que um software utilize capacidades oferecidas por outro software. A interface define operações, dados esperados, respostas, erros e regras de uso. existem em diferentes níveis: bibliotecas locais, sistemas operacionais, bancos de dados, mensageria e interfaces remotas. Portanto, não é sinônimo de e não é sinônimo de .
Uma é uma interface remota projetada segundo princípios do estilo arquitetural e normalmente exposta sobre . Na prática de mercado, muitas interfaces são chamadas de apenas porque usam e métodos . Uma avaliação mais rigorosa também observa identificação de recursos, semântica dos métodos, ausência de estado de sessão no servidor, e arquitetura em camadas.
Distinção essencial
Internet é a infraestrutura de redes. Web é um sistema construído sobre essa infraestrutura. é um protocolo de aplicação. é um contrato entre softwares. é um estilo arquitetural. Esses conceitos se relacionam, mas não são equivalentes.
1.3 Evolução histórica: da comutação de pacotes às plataformas de
As primeiras redes de computadores eram frequentemente construídas para ambientes específicos e possuíam pouca interoperabilidade. A pesquisa em comutação de pacotes introduziu a ideia de dividir dados em unidades menores que poderiam atravessar a rede por caminhos compartilhados. Em vez de reservar um circuito físico exclusivo durante toda a comunicação, a rede poderia utilizar sua capacidade de maneira estatística e reconstruir os dados no destino.
A ARPANET, operacional a partir de 1969, foi um dos projetos que demonstraram a viabilidade dessa abordagem em uma rede de longa distância. Ela não era a Internet moderna, mas forneceu experiência técnica e organizacional para a evolução posterior. O desafio seguinte não era apenas conectar computadores em uma mesma rede, mas permitir que redes diferentes se comunicassem sem exigir uma tecnologia física única.
O conjunto / surgiu para resolver esse problema de interconexão. A camada oferece um mecanismo de endereçamento e entrega de datagramas entre redes, enquanto protocolos de transporte como fornecem propriedades adicionais aos aplicativos. A adoção de / pela ARPANET em 1983 é tradicionalmente tratada como um marco na consolidação da Internet moderna.
No fim da década de 1980 e início da década de 1990, a Web acrescentou uma camada de publicação e navegação de recursos. , e formaram um sistema simples, extensível e distribuído.
Com o crescimento de aplicações dinâmicas, o passou a transportar não apenas documentos para pessoas, mas dados entre sistemas.
Nos anos 2000, arquiteturas orientadas a serviços e web ganharam importância na integração corporativa. tornou-se popular por alinhar a integração à infraestrutura já difundida da Web. Posteriormente, nuvem, microsserviços, aplicativos móveis e ecossistemas de parceiros elevaram o número de e consumidores, criando a necessidade de governança, proteção e observabilidade em escala.
É nesse contexto que surgem as plataformas modernas de gerenciamento de . Um passa a funcionar como ponto controlado de exposição e mediação, enquanto componentes de management plane cuidam de configuração, catálogo, publicação, análise e ciclo de vida. Produtos como Axway e Azure Management representam implementações corporativas dessa evolução.
Figura 1 - Linha do tempo simplificada da infraestrutura de rede até as plataformas de .
Leitura crítica
A evolução não ocorreu como substituição completa. Tecnologias antigas e novas coexistem. /1.1 continua presente ao lado de /2 e /3; 1.2 ainda pode coexistir com 1.3; sistemas legados podem ser expostos por modernos. Arquitetura corporativa exige compreender essas combinações.
1.4 Ecossistema de padronização e referências técnicas
e Editor
A Internet Engineering Task Force ( ) é uma comunidade aberta responsável pelo desenvolvimento de muitos padrões utilizados na Internet. O trabalho é organizado em grupos que discutem problemas técnicos, analisam propostas e produzem documentos. Protocolos como , , , , 2.0 e diversos mecanismos de segurança são definidos ou atualizados nesse ecossistema.
O Editor publica e mantém a série . Uma recebe um número permanente e não é editada depois da publicação. Quando uma especificação precisa ser corrigida ou substituída, uma nova é publicada e registra sua relação com documentos anteriores, por exemplo "updates" ou "obsoletes". Essa característica é importante: ao pesquisar um protocolo, o profissional deve verificar se a encontrada ainda é atual.
, , IEEE e outros organismos
O National Institute of Standards and Technology ( ) publica padrões e guias amplamente utilizados em segurança, criptografia, identidade e gestão de riscos. Embora seja uma instituição dos Estados Unidos, suas publicações influenciam organizações em vários países. Para , documentos do ajudam a organizar controles de proteção durante desenvolvimento, implantação e operação.
O World Wide Web Consortium ( ) produz padrões relacionados à plataforma Web, incluindo tecnologias utilizadas por navegadores. O Institute of Electrical and Electronics Engineers (IEEE) mantém padrões importantes nas camadas física e de enlace, como as famílias Ethernet e Wi-Fi. Esses padrões ficam abaixo do , mas afetam diretamente conectividade, capacidade e comportamento da rede.
OpenID Foundation mantém especificações relacionadas a identidade, incluindo OpenID Connect e perfis usados em ecossistemas financeiros. Initiative mantém a especificação , utilizada para descrever contratos de forma legível por pessoas e ferramentas. OASIS mantém padrões como . Cada organismo atua em um domínio, e projetos corporativos frequentemente combinam especificações de várias fontes.
Como avaliar a autoridade de uma documentação
Documentações de fabricantes explicam como um produto implementa um padrão, mas não substituem a especificação normativa. Para entender o comportamento do Azure , consulte a Microsoft; para entender o Axway , consulte a Axway. Entretanto, para compreender a semântica de , consulte a aplicável. A distinção evita confundir decisão de produto com requisito de protocolo.
Uma estratégia de estudo eficiente possui três níveis. Primeiro, uma introdução didática estabelece o vocabulário. Depois, a especificação oficial esclarece requisitos normativos e casos de borda. Por fim, a documentação do produto demonstra como configurar ou observar aquele comportamento em uma implementação específica. Essa sequência reduz o risco de aprender apenas procedimentos sem compreender os fundamentos.
Regra de ouro
Para responder "o que o protocolo permite?", procure a especificação. Para responder "como o produto implementa ou configura isso?", procure a documentação do fabricante. Para responder "qual controle é recomendado?", procure guias de segurança e risco, como e .
1.5 : como protocolos são documentados e evoluem
significa for Comments, nome histórico que permaneceu mesmo quando parte da série passou a registrar padrões consolidados. Nem toda é um Internet Standard. Existem documentos em trilhas e categorias diferentes, incluindo Standards Track, Best Current Practice, Informational e Experimental. Por isso, citar apenas um número sem verificar o status pode levar a conclusões erradas.
Antes da publicação, propostas da normalmente circulam como Internet-Drafts. Um draft é um documento de trabalho temporário: pode mudar, expirar ou nunca se tornar . Durante a análise, participantes discutem interoperabilidade, segurança, clareza e experiência de implementação. O objetivo não é apenas produzir uma descrição elegante, mas permitir que implementações independentes se comuniquem corretamente.
utilizam palavras normativas como MUST, MUST NOT, SHOULD e MAY de acordo com convenções específicas. Em uma leitura técnica, essas palavras indicam níveis diferentes de obrigatoriedade. MUST descreve requisito indispensável para conformidade; SHOULD admite exceções justificadas; MAY indica opção permitida. Traduções informais podem suavizar essas diferenças e alterar a interpretação.
A evolução de demonstra a importância de acompanhar relações entre documentos. antigas podem permanecer muito citadas, embora tenham sido substituídas. A semântica moderna de está consolidada na 9110, enquanto versões de transporte possuem documentos próprios. também recebeu uma especificação consolidada mais recente na 9293, que substitui a histórica 793.
Ao estudar uma , comece pelo resumo, status, relação com outros documentos e sumário. Depois, identifique terminologia, modelo de funcionamento, requisitos normativos e seção de segurança. Não é necessário memorizar todo o documento. O objetivo inicial é aprender a localizar a fonte formal de uma dúvida e interpretar o trecho relevante no contexto correto.
Vocabulário normativo simplificado
MUST requisito obrigatório
MUST NOT comportamento proibido
SHOULD recomendado, salvo motivo técnico justificável
MAY opção permitida pela especificação
Exemplo de investigação
Ao encontrar uma configuração que aceita 1.0, não conclua apenas com base na tela do produto que a versão é recomendada. Verifique o padrão, as orientações de segurança vigentes e a política da organização. Capacidade técnica de configuração não equivale a decisão segura.
1.6 Comunicação em rede, pacotes e
Aplicações trabalham com mensagens significativas para o negócio: uma requisição para consultar cliente, uma resposta ou um de acesso. A infraestrutura de rede, porém, precisa transportar esses dados por meios com limites de tamanho, endereços e regras próprias. Para isso, cada camada acrescenta informações de controle ao conteúdo recebido da camada superior. Esse processo é chamado .
Em uma chamada sobre e , a aplicação produz bytes de uma mensagem . organiza esses bytes em registros protegidos. trata o fluxo como uma sequência confiável e cria segmentos. acrescenta endereços de origem e destino aos datagramas. A tecnologia de enlace cria quadros adequados ao meio local, como Ethernet ou Wi-Fi. No destino, cada camada remove e interpreta seu cabeçalho antes de entregar o conteúdo à camada superior.
Essa separação permite evolução independente. A mesma aplicação pode funcionar sobre diferentes redes físicas, e o mesmo enlace pode transportar diferentes protocolos de camada superior. Também explica por que ferramentas de diagnóstico exibem visões distintas: uma captura de pacotes pode mostrar endereços e portas, enquanto do mostram métodos, caminhos e .
O tamanho dos dados importa. Interfaces possuem uma Maximum Transmission Unit ( ), e mensagens maiores precisam ser divididas ou ajustadas aos limites do caminho. Problemas de e fragmentação podem produzir sintomas difíceis de perceber, como conexões que funcionam para mensagens pequenas, mas falham com certificados grandes, extensos ou uploads.
não significa que todas as camadas sejam igualmente visíveis em cada componente. Um roteador encaminha principalmente com base em informações . Um balanceador de camada 4 pode usar e porta. Um de camada 7 interpreta . Um pode inspecionar método, , e corpo. Quanto mais alta a camada de atuação, maior a compreensão semântica da mensagem e, normalmente, maior o custo de processamento.
Figura 2 - Visão simplificada do de uma chamada protegida por .
Relação com observabilidade
de aplicação, do , distribuídos e capturas de pacotes observam níveis diferentes. Uma investigação completa pode precisar correlacionar timestamp, endereço, porta, , método , correlation ID e ID.
1.7 Modelos OSI e /
Modelos em camadas são ferramentas conceituais. Eles ajudam a separar responsabilidades e organizar o raciocínio, mas não representam com perfeição todos os detalhes de uma implementação. O modelo OSI descreve sete camadas: física, enlace, rede, transporte, sessão, apresentação e aplicação. O modelo / costuma ser apresentado com quatro ou cinco camadas, agrupando funções de maneira mais próxima à arquitetura da Internet.
Na prática de , as camadas mais citadas são rede, transporte e aplicação. pertence à camada de rede; e pertencem à camada de transporte; , e protocolos de identidade aparecem na camada de aplicação. é frequentemente posicionado entre aplicação e transporte, embora sua classificação varie conforme o modelo usado. O importante é compreender sua função e não disputar apenas o número da camada.
O modelo OSI é útil em porque incentiva uma ordem. Primeiro, existe conectividade física ou virtual? Depois, o endereço está alcançável? A porta aceita conexão? A negociação conclui? A mensagem é válida? A autenticação é aceita? A regra de negócio funciona? Esse caminho reduz investigações que começam em políticas complexas quando o problema é uma rota inexistente.
Termos como "balanceador L4" e " L7" derivam desse vocabulário. Um dispositivo L4 toma decisões principalmente com base em endereços e portas de transporte. Um componente L7 interpreta o protocolo de aplicação e pode rotear por host, path ou . Um é tipicamente um componente de camada de aplicação, embora dependa de recursos das camadas inferiores.
Tabela 1 - Mapeamento aproximado entre OSI e TCP/IP.
OSI
TCP/IP aproximado
Exemplos no contexto de APIs
7 Aplicação
Aplicação
HTTP, DNS, OAuth, OpenID Connect
6 Apresentação
Aplicação
JSON, codificação, serialização, TLS em alguns modelos
5 Sessão
Aplicação
Sessões lógicas, negociação e contexto
4 Transporte
Transporte
TCP, UDP, QUIC
3 Rede
Internet
IPv4, IPv6, roteamento
2 Enlace
Acesso à rede
Ethernet, Wi-Fi, VLAN
1 Física
Acesso à rede
Cabo, fibra, rádio
1.8 Endereçamento e roteamento
O protocolo fornece endereçamento lógico e entrega de datagramas entre redes. Um endereço identifica uma interface em determinado contexto de rede, não necessariamente uma pessoa, aplicação ou máquina de forma permanente. Equipamentos podem possuir múltiplos endereços, endereços podem mudar e mecanismos intermediários podem traduzir origens e destinos.
utiliza endereços de 32 bits e costuma ser representado em quatro números decimais. utiliza 128 bits e representação hexadecimal, oferecendo espaço muito maior e outras melhorias arquiteturais. Em redes corporativas, privado continua comum, enquanto pode aparecer de forma crescente em ambientes externos, cloud e redes modernas. Uma pode ser publicada com registros para uma ou ambas as famílias.
A máscara ou prefixo identifica qual parte do endereço corresponde à rede. Quando o destino está fora da rede local, o host envia o datagrama ao padrão. Roteadores consultam suas tabelas e encaminham o pacote salto a salto. Cada roteador decide o próximo caminho; ele não precisa conhecer a lógica da , apenas informações suficientes para alcançar a rede de destino.
Roteamento é diferente de roteamento de . O primeiro ocorre na infraestrutura e escolhe caminhos entre redes. O segundo ocorre em e e pode escolher um com base em host, caminho, versão, ou política. Uma falha de rota impede a conexão antes de o analisar ; uma falha de roteamento de ocorre depois que a mensagem já chegou ao .
Em nuvem e datacenters, rotas podem ser influenciadas por redes virtuais, peering, túneis, appliances de segurança e regras de saída. O fato de duas aplicações estarem na mesma empresa não garante conectividade direta. Arquitetos devem tratar caminho de rede, resolução de nomes, regras de firewall e dependências de saída como parte explícita do desenho.
Exemplo conceitual de endereçamento
IPv4 privado de exemplo: 10.20.30.40/24
Rede aproximada: 10.20.30.0/24
Gateway padrão: 10.20.30.1
Destino externo: encaminhado ao gateway
Diagnóstico
Se o nome resolve, mas a conexão expira sem resposta, investigue caminho , firewall, rota e listener. Se a conexão é recusada imediatamente, o destino pode estar alcançável, porém sem serviço escutando naquela porta ou com rejeição ativa.
1.9 e resolução de nomes
O Domain Name System permite utilizar nomes hierárquicos em vez de depender de endereços fixos. Em uma como :// .exemplo.com, o host .exemplo.com precisa ser resolvido para um endereço que o cliente possa alcançar. Essa resolução pode envolver local, resolvedor corporativo, servidores recursivos e servidores autoritativos.
O é distribuído e hierárquico. A zona responsável por um domínio publica registros que descrevem como nomes devem ser resolvidos. Registros A associam nomes a endereços ; associam a ; cria um alias para outro nome; TXT transporta informações textuais usadas por diferentes mecanismos; SRV pode indicar serviços e portas. Em arquiteturas de , CNAMEs são comuns para desacoplar o endereço público da infraestrutura física ou do provedor.
O Time to Live ( ) orienta por quanto tempo uma resposta pode permanecer em . alto reduz consultas e pode melhorar eficiência, mas torna mudanças mais lentas para consumidores que ainda mantêm dados antigos. baixo acelera transições, mas aumenta consultas e não elimina todos os intermediários. Estratégias de migração e disaster recovery precisam considerar esse comportamento.
Split-horizon ocorre quando o mesmo nome retorna respostas diferentes conforme a origem da consulta. Um consumidor interno pode receber endereço privado, enquanto um consumidor externo recebe um público. Essa técnica é útil, mas pode causar confusão quando testes realizados de redes diferentes produzem resultados distintos.
também se relaciona a . O cliente normalmente valida se o certificado apresentado pelo servidor é válido para o nome solicitado. Assim, apontar um nome para outro não basta: o precisa apresentar certificado compatível e responder adequadamente ao host ou esperado. Falhas de nome e certificado frequentemente aparecem juntas durante migrações.
Exemplo de verificação de resolução e conexão
$ nslookup api.exemplo.com
Nome: api.exemplo.com
Address: 203.0.113.20
$ curl -v https://api.exemplo.com/clientes
* Host api.exemplo.com:443 was resolved
* Connected to api.exemplo.com (...) port 443
Ponto de atenção
Um ping bem-sucedido não comprova que uma está disponível. ICMP pode ser bloqueado, e a depende de , rota, porta, e . Da mesma forma, um ping bloqueado não prova indisponibilidade do serviço .
1.10 , , portas e
fornece um fluxo de bytes confiável e ordenado entre dois . Antes da troca de dados, uma conexão é estabelecida por meio do three-way : , - e . A conexão mantém números de sequência, confirma recebimentos e retransmite dados quando necessário. Essas propriedades simplificam o trabalho de protocolos como /1.1 e /2.
Confiabilidade possui custo. precisa controlar estado, janelas, retransmissões e congestionamento. Perdas de pacotes podem aumentar latência, mesmo quando a aplicação recebe todos os bytes ao final. Conexões persistentes e pools evitam repetir para cada requisição, mas exigem configuração cuidadosa de e limites em clientes, e .
e
oferece datagramas sem estabelecimento de conexão e sem garantia de entrega ou ordem no próprio protocolo. Isso não significa que aplicações sobre sejam necessariamente não confiáveis; elas podem implementar os mecanismos necessários. tradicionalmente utiliza em muitas consultas, com alternativas e extensões para outros cenários.
/3 utiliza , que opera sobre e incorpora recursos de transporte e segurança. A escolha permite reduzir alguns custos de estabelecimento e evitar certos efeitos de bloqueio entre fluxos. Entretanto, para o profissional de , o ponto principal neste capítulo é reconhecer que moderno não depende exclusivamente de em todas as versões.
Portas e
Uma porta identifica um ponto lógico de comunicação no host. costuma utilizar 443 e 80 por convenção, mas serviços podem operar em outras portas. O par endereço e porta identifica um de transporte; combinado aos de origem e destino e ao protocolo, forma a identificação de uma comunicação.
é uma abstração utilizada pelo sistema operacional para permitir que aplicações enviem e recebam dados. Um servidor cria um , associa endereço e porta e passa a escutar conexões. Se o processo não estiver escutando, o cliente pode receber conexão recusada. Se um firewall descartar os pacotes silenciosamente, o cliente tende a aguardar até um .
Conexões distintas no caminho
Cliente 10.1.5.20:53144 -> Gateway 10.2.8.10:443
porta efêmera porta do serviço
Gateway 10.2.8.10:48720 -> Backend 10.3.9.15:8443
nova conexão listener do backend
Implicação arquitetural
A conexão cliente- e a conexão - são normalmente independentes. O pode terminar , reutilizar conexões de e aplicar diferentes. Isso explica por que um problema pode existir apenas em um dos lados.
1.11 , firewall, e balanceamento de carga
Network Address Translation modifica informações de endereço e, em muitos casos, de porta durante a passagem do tráfego. permite que endereços privados utilizem um conjunto menor de endereços públicos e é frequente em redes corporativas e nuvem. Como consequência, o endereço observado pelo servidor pode ser o endereço do dispositivo intermediário, não o endereço original do consumidor.
Para preservar informações de origem na camada de aplicação, podem acrescentar como Forwarded ou X-Forwarded-For. Esses exigem uma cadeia de confiança: aceitar valores enviados diretamente por qualquer cliente permite falsificação. O componente de borda deve remover ou sobrescrever valores não confiáveis antes de repassar a informação.
Firewall
Firewalls aplicam regras para permitir, rejeitar ou descartar tráfego segundo critérios como endereço, porta, protocolo e estado de conexão. Firewalls de aplicação podem analisar protocolos de nível superior. Em ambientes de , diferentes camadas de firewall podem existir no consumidor, na rede, na borda pública, no e no host.
Uma liberação de firewall precisa considerar direção, origem, destino, porta e protocolo. Solicitações vagas como "liberar a " são insuficientes. Além disso, o retorno normalmente depende do estado da conexão, e tráfego de saída para provedores de identidade, validação de certificados ou serviços externos também pode exigir regras específicas.
comum, e balanceador
Um comum, também chamado forward ou de saída, atua em nome do cliente. O navegador, sistema operacional ou aplicação conhece esse intermediário e envia a ele a requisição destinada a outro servidor. O decide se permite a saída, estabelece a conexão com o destino e devolve a resposta ao consumidor. Empresas usam forward para controle de acesso à Internet, auditoria, filtragem, e aplicação de políticas de egress. Para o servidor de destino, a conexão normalmente parece vir do , que oculta ou substitui o endereço de rede do cliente.
Um recebe requisições em nome de servidores internos. Ele pode terminar , aplicar regras, normalizar , comprimir respostas e ocultar a topologia de . Um possui características de , mas acrescenta funções específicas de gestão, segurança e governança de .
No , o consumidor acredita estar conversando com o próprio serviço publicado. direciona o nome da ao , e o escolhe qual servidor interno receberá a chamada. Assim, o forward representa clientes e controla tráfego de saída; o reverse representa servidores e controla tráfego de entrada. Os dois podem encaminhar e manipular , mas ocupam lados opostos da relação e possuem raízes de confiança diferentes.
Comparação entre proxy comum e proxy reverso.
Aspecto
Proxy comum / forward proxy
Proxy reverso / reverse proxy
Representa
O cliente ou uma rede de clientes
O servidor ou um conjunto de backends
Fluxo principal
Saída da rede para serviços externos
Entrada de consumidores para serviços publicados
Quem conhece o proxy
Normalmente o cliente é configurado para usá-lo
O cliente acessa o nome do serviço e pode nem perceber o intermediário
O que oculta
A origem e a topologia da rede cliente
A localização e a quantidade de servidores internos
Usos frequentes
Egress, filtragem, auditoria e cache
Terminação TLS, roteamento, balanceamento, WAF e proteção de backends
Relação com APIs
Controla quais APIs externas os consumidores podem chamar
Publica APIs internas e encaminha chamadas aos backends corretos
Com , um forward pode apenas criar um túnel com o método CONNECT, sem ler o protegido, ou pode realizar inspeção quando dispositivos clientes confiam em uma corporativa — operação sensível que cria duas sessões e exige governança. Um reverse pode operar em pass-through, preservando até o , terminar e encaminhar internamente, ou terminar e recriptografar a chamada em outra sessão . Esses modos não são equivalentes e devem aparecer explicitamente no diagrama de confiança.
Balanceadores distribuem tráfego entre múltiplas instâncias para aumentar capacidade e disponibilidade. Algoritmos podem considerar round-robin, conexões ativas, pesos, latência ou afinidade. determinam quais instâncias podem receber tráfego. Um serviço pode parecer disponível em um teste local e ainda falhar externamente se o balanceador considerar todas as instâncias não saudáveis.
Erro comum
Terminar no balanceador não significa necessariamente que o trecho até o esteja sem proteção; pode existir recriptografia. O desenho deve registrar cada , onde termina, qual certificado é validado e quais de contexto são confiáveis.
1.12 , e o estabelecimento de confiança
O que protege — e o que permanece fora do seu alcance
protege a comunicação contra leitura indevida, alteração e falsificação dentro do modelo de ameaça considerado. é transportado em um canal protegido por . O protocolo negocia parâmetros criptográficos, autentica pelo menos o servidor na configuração comum e estabelece chaves de sessão utilizadas para proteger os dados transmitidos.
Depois do , os registros usam chaves de sessão e criptografia autenticada para oferecer confidencialidade e integridade aos bytes em trânsito naquele . Um observador de rede ainda pode inferir metadados como endereços , portas, volume e duração das conexões. também não corrige autorização incorreta, malicioso, comprometido, vazamento em ou dados já descriptografados na aplicação. Ele protege o canal entre duas terminações; não declara que toda a jornada de negócio é segura.
Como o estabelece confiança e chaves
O servidor apresenta um certificado que associa uma chave pública a identidades, geralmente nomes . O cliente verifica assinatura, período de validade, cadeia de certificação, uso permitido e correspondência do nome. A confiança depende das autoridades certificadoras aceitas pelo cliente. Em ambientes corporativos, certificados podem ser emitidos por autoridades públicas ou por PKIs internas.
No início, o ClientHello anuncia versões suportadas, suites criptográficas, grupos de troca de chaves e extensões. informa o nome esperado para que um endereço compartilhado selecione o certificado correto; permite negociar /1.1, /2 ou outro protocolo. O servidor responde com os parâmetros escolhidos, sua cadeia de certificados e prova de posse da chave privada. Uma troca efêmera, normalmente baseada em ECDHE no moderno, produz o segredo do qual derivam as chaves de sessão sem transmitir essas chaves pela rede. Mensagens Finished autenticam o transcript do e detectam alteração da negociação.
No , cliente e servidor negociam versão e algoritmos compatíveis. 1.3 simplificou e modernizou partes do protocolo em relação a versões anteriores. A aplicação só deve enviar informações sensíveis depois que o canal está estabelecido e validado. Quando a negociação falha, nenhuma política do pode ser executada porque a mensagem de aplicação ainda não foi recebida.
1.3 removeu opções criptográficas antigas, reduziu mensagens em claro e normalmente completa um novo em um round trip. Retomada de sessão com PSK ou tickets reduz custo e latência, mas tickets e suas chaves também precisam de expiração e rotação. O modo 0- pode enviar dados antes de concluir um novo , porém permite em determinadas condições; por isso deve ser restrito a operações realmente seguras e idempotentes ou permanecer desabilitado em sensíveis.
: autenticação bilateral no canal
acrescenta autenticação do cliente no nível . Além de validar o certificado do servidor, o servidor solicita e valida um certificado apresentado pelo cliente. Isso é comum em integrações B2B e financeiras. autentica uma identidade técnica ligada ao certificado; autorização de negócio ainda pode depender de , escopo, contrato e contexto.
Quando é exigido, o servidor envia CertificateRequest com informações sobre CAs e algoritmos aceitos. O cliente apresenta sua cadeia e produz CertificateVerify, uma assinatura sobre o transcript que prova possuir a chave privada correspondente — enviar apenas um certificado copiado não basta. O servidor valida cadeia, validade, usos de chave, políticas e, conforme o ambiente, revogação; depois mapeia subject, , ou dados cadastrados para uma identidade técnica. Esse mapeamento precisa ser explícito e auditável.
A operação de depende de ciclo de vida: emissão segura, armazenamento da chave privada, distribuição da cadeia, renovação antes da expiração, rotação sem indisponibilidade e revogação quando um parceiro ou workload perde confiança. Certificados de clientes diferentes não devem compartilhar indiscriminadamente a mesma chave. Em meshes e comunicações internas, identidades de workload e automação podem reduzir trabalho manual, mas não eliminam a necessidade de definir quem confia em qual e para qual finalidade.
não substitui , ou autorização do recurso. O certificado responde principalmente qual sistema possui a chave e participa do canal; um pode representar usuário, consentimento, audiência e escopos. Em arquiteturas combinadas, o primeiro associa o certificado a um cliente autorizado, depois valida o e aplica políticas de negócio. Vincular o ao certificado, quando o perfil adotado prevê essa proteção, também reduz o valor de um roubado fora do canal autorizado.
pode terminar em vários pontos. Uma conexão externa pode terminar no ou balanceador, seguida por outra conexão até o . O pode criar uma terceira conexão até o . Cada trecho possui , configuração, , certificado e risco próprios. Documentar apenas "a usa " é insuficiente para compreender a arquitetura.
Exemplo de por
Cliente --TLS 1--> Balanceador --TLS 2--> API Gateway --TLS 3--> Backend
cert. público cert. interno mTLS opcional
Cada seta representa uma conexão e uma validação potencialmente diferente.
Diagnóstico de
Mensagens como certificate unknown, hostname mismatch, unknown , expired certificate, no shared cipher ou protocol version apontam para classes diferentes de falha. A captura do erro e a identificação do são essenciais.
1.13 Anatomia de uma mensagem
segue um modelo de requisição e resposta. A requisição contém método, alvo, campos de cabeçalho e, quando aplicável, conteúdo. A resposta contém código de status, e conteúdo. define semântica: um método não é apenas uma palavra, e um código não é apenas um número. Clientes, , e tomam decisões com base nesses significados.
O método solicita uma representação e é considerado seguro e idempotente no modelo do protocolo. envia conteúdo para processamento definido pelo recurso. é associado à criação ou substituição do estado no alvo e é idempotente. solicita remoção e também possui semântica idempotente, embora respostas e efeitos observáveis possam variar. aplica modificações parciais segundo o formato utilizado.
carregam metadados. Host ou :authority identifica a autoridade de destino; Content-Type descreve o tipo do conteúdo enviado; Accept indica representações aceitas; Authorization transporta credenciais de aplicação; -Control orienta ; traceparent pode propagar contexto de . frequentemente validam, removem, acrescentam ou transformam .
Códigos 2xx indicam sucesso; 3xx tratam redirecionamento; 4xx indicam que a requisição não pode ser atendida nas condições apresentadas; 5xx indicam falha do servidor ou de um intermediário. O código deve ser interpretado com o corpo, , componente emissor e contexto. Um 404 pode significar recurso inexistente no ou rota não publicada no .
é no sentido de que cada requisição deve conter as informações necessárias para sua interpretação. Aplicações podem construir sessões usando ou , mas isso ocorre acima da semântica básica do protocolo. corporativas costumam preferir explícitos e contexto por requisição para facilitar distribuição e escalabilidade.
Requisição e resposta HTTP simplificadas
GET /v1/clientes/123 HTTP/1.1
Host: api.exemplo.com
Accept: application/json
Authorization: Bearer <token>
X-Correlation-ID: 7ad3c8c0
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
X-Correlation-ID: 7ad3c8c0
{"id":123,"nome":"Cliente de Exemplo"}
Tabela 2 - Interpretação inicial de códigos comuns em gateways.
Código
Interpretação inicial
Possível origem em APIs
200
Operação concluída
Backend ou resposta sintetizada pelo gateway
400
Requisição inválida
Schema, parâmetro, header ou sintaxe
401
Não autenticado
Token ausente/inválido ou certificado não associado
403
Autenticado sem autorização
Escopo, papel, contrato ou política
404
Recurso ou rota não encontrado
Gateway, backend ou versão incorreta
429
Limite excedido
Rate limit ou quota
502
Resposta inválida do upstream
Falha gateway-backend
503
Serviço indisponível
Sem instâncias saudáveis ou proteção de capacidade
504
Timeout do upstream
Backend não respondeu no prazo
1.14 e o conceito de recurso
foi descrito por Roy Fielding como um estilo arquitetural para sistemas hipermídia distribuídos. Um estilo arquitetural é um conjunto de restrições que produz determinadas propriedades. combina cliente-servidor, , , interface uniforme, sistema em camadas e código sob demanda opcional. O resultado pretendido inclui escalabilidade, visibilidade e evolução independente de componentes.
O conceito central é recurso. Um recurso representa algo que pode ser identificado: cliente, conta, pagamento, contrato ou coleção. O consumidor interage com representações do recurso, como ou . A identifica o recurso; o método expressa a intenção; e conteúdo completam a mensagem. Essa separação evita desenhar a interface apenas como chamadas de procedimento disfarçadas.
significa que o servidor não deve depender de contexto de sessão oculto entre requisições para interpretar a próxima operação. Cada requisição traz o contexto necessário. Isso facilita distribuição entre instâncias e aumenta visibilidade, mas pode elevar o tamanho das mensagens. de acesso são um exemplo de contexto explicitamente transportado.
A interface uniforme limita variações e permite que intermediários compreendam a comunicação. Semântica correta de métodos e status, representações autodescritivas e hipermídia fazem parte do modelo. Muitas comerciais adotam apenas uma parte dessas restrições. É útil reconhecer a diferença entre como definido academicamente e o uso coloquial de " ".
Sistema em camadas permite inserir , , e balanceadores sem exigir que o consumidor conheça toda a topologia. Essa restrição se conecta diretamente ao mundo de : o cliente chama uma autoridade pública e não precisa saber qual microsserviço, ou datacenter processará a operação.
Exemplo de modelagem orientada a recursos
GET /clientes/123 obter representação do cliente
PUT /clientes/123 substituir estado conforme contrato
PATCH /clientes/123 aplicar alteração parcial
DELETE /clientes/123 solicitar remoção
GET /clientes/123/contas navegar para sub-recursos
Cuidado com verbos na
Rotas como /consultarCliente ou /deletarCliente aproximam a interface de . Nem todo uso é automaticamente incorreto, mas o desenho deve ser intencional e coerente com o estilo escolhido.
1.15 e plataforma de
Um é um intermediário especializado que recebe chamadas de consumidores e as encaminha a serviços de . No caminho, aplica políticas relacionadas a segurança, tráfego, mediação, roteamento e observabilidade. Essa posição permite padronizar controles sem duplicar toda a implementação em cada serviço.
O não deve ser confundido com toda a plataforma de Management. A plataforma pode incluir management plane, catálogo, portal de desenvolvedores, analytics, gestão de produtos, subscriptions, credenciais e ciclo de vida. O é o componente de runtime ou data plane que processa o tráfego. Produtos diferentes usam nomes e separações próprias, mas a distinção conceitual é útil.
Segurança no pode incluir validação de , , 2.0, , assinatura, allowlists e proteção contra conteúdo malformado. Controle de tráfego pode incluir , quotas, spike arrest e circuit breaking. Mediação pode transformar , paths e formatos. Observabilidade coleta , métricas e para operação e auditoria.
Centralização traz benefícios e riscos. Políticas consistentes aumentam governança, mas o pode se tornar ponto crítico de capacidade e disponibilidade. Regras excessivamente complexas elevam latência e dificultam manutenção. Lógica de negócio profunda no cria acoplamento e reduz clareza de responsabilidades. O desenho deve manter equilíbrio entre controles transversais e domínio do .
Axway fornece recursos de gestão, entrega e segurança de , com políticas e componentes de administração. Azure Management oferece uma plataforma gerenciada com , management plane e portal. Apesar das diferenças de produto, os fundamentos deste capítulo se aplicam a ambos: listeners, certificados, , upstreams, políticas , identidade, e capacidade.
Figura 3 - Responsabilidades transversais normalmente concentradas no .
Limite de responsabilidade
O pode validar que um contém escopo adequado, mas o continua responsável por regras de autorização ligadas aos dados e ao domínio, como verificar se o cliente autenticado pode acessar aquela conta específica.
1.16 Jornada ponta a ponta de uma chamada de
Considere um aplicativo corporativo que consulta :// .exemplo.com/v1/clientes/123. Antes de enviar a mensagem, a biblioteca cliente interpreta a , identifica o esquema , o host, a porta padrão 443 e o caminho. Ela consulta a resolução de nomes, possivelmente utilizando do processo, sistema operacional e resolvedor configurado.
Após obter um endereço, o cliente inicia uma conexão de transporte. Em /1.1 ou /2 sobre , ocorre o three-way . Em seguida, inicia o . O cliente informa capacidades, versão e nome de servidor; o apresenta certificado e negocia chaves. Se a validação falhar, a operação termina antes de existir requisição útil para o .
Com o canal estabelecido, o cliente envia método, caminho, e corpo. Um componente de borda pode receber a conexão, aplicar regras de firewall de aplicação, limitar tamanho e encaminhar a mensagem. O seleciona a publicada com base em host, path, método e configuração. Políticas podem validar certificado cliente, , escopos, e limites de consumo.
Se a requisição for aceita, o determina o , constrói ou reutiliza uma conexão e envia uma mensagem . O executa autenticação complementar ou autorização de domínio, consulta dependências e produz resposta. O recebe essa resposta, pode transformá-la, remover internos, registrar métricas e devolvê-la ao consumidor.
A resposta percorre conexões independentes. O não necessariamente conhece o endereço original do cliente, e o cliente não conhece o endereço do . controlados podem propagar correlation IDs, identidade técnica e informações de origem. Cada salto deve possuir contratos claros para evitar spoofing, perda de contexto e exposição de detalhes internos.
Em caso de falha, o componente que detecta o problema pode gerar a resposta. Um 401 pode ser produzido pela política do sem chamar o . Um 502 pode ser produzido porque a conexão falhou. Um 500 pode vir do e apenas atravessar o . Identificar o emissor real é uma das habilidades centrais de .
Figura 4 - Principais componentes na jornada ponta a ponta.
Sequência detalhada
A aplicação monta a , os , o conteúdo e suas configurações de .
O host é resolvido por ; o cliente escolhe um endereço retornado.
A rota e as regras de rede permitem ou impedem a chegada ao .
A conexão ou é estabelecida.
negocia parâmetros, valida certificados e cria chaves de sessão.
A borda recebe a requisição e pode aplicar proteção inicial.
O identifica a e executa políticas de entrada.
Credenciais são validadas localmente ou com sistemas de identidade.
O seleciona o e encaminha a requisição.
O executa regras de negócio e acessa dependências.
A resposta retorna ao , que aplica políticas de saída.
Métricas, e são registrados; a resposta retorna ao cliente.
Pergunta operacional
Em qual dessas etapas a chamada parou? Essa pergunta é mais útil do que "a está fora?" porque transforma um sintoma amplo em hipóteses verificáveis.
1.17 orientado por camadas
eficiente começa com evidências, não com alterações. Registre horário com fuso, , consumidor, método, correlation ID, código, duração e mensagem completa. Compare uma chamada que falha com outra que funciona. Mudanças recentes em , certificado, rota, política, ou credencial ajudam a priorizar hipóteses, mas não substituem a validação.
A investigação pode seguir de baixo para cima. Primeiro, o nome resolve para o endereço esperado? Segundo, existe conectividade até a porta? Terceiro, o conclui e o certificado é válido? Quarto, a requisição chega ao ? Quinto, qual política ou rota é selecionada? Sexto, o responde? Sétimo, a regra de negócio conclui? Essa ordem evita analisar quando a conexão nem existe.
Também é necessário observar em cadeia. O do consumidor deve ser coerente com o da borda, do e do . Se o aguarda 60 segundos, mas o balanceador encerra em 30, o limite efetivo é 30. automático pode multiplicar carga e transformar lentidão em indisponibilidade. , e circuit breakers precisam ser projetados em conjunto.
devem permitir correlação entre . Um correlation ID estável facilita seguir a transação, enquanto IDs e spans mostram dependências e duração. Cuidado com dados sensíveis: , certificados privados, senhas e pessoais não devem ser registrados indiscriminadamente. Observabilidade precisa equilibrar diagnóstico, segurança, privacidade e custo.
O oferece um ponto privilegiado de observação, mas não enxerga tudo. Se o falha antes do listener, pode não existir de política. Se o aceita a conexão e trava internamente, o observa apenas . Se o cliente cancela a requisição, o pode continuar processando. A interpretação exige combinar fontes.
Tabela 3 - Matriz inicial de troubleshooting.
Camada/etapa
Teste ou evidência
Falhas comuns
DNS
nslookup/dig, cache, registro esperado
NXDOMAIN, IP antigo, split DNS
Rede
rota, firewall, conexão à porta
timeout, reset, conexão recusada
TLS
openssl/curl -v, cadeia e nome
CA desconhecida, expirado, mismatch
HTTP
método, path, headers, tamanho
400, 404, 405, 413
Gateway
trace de política, API selecionada
401, 403, 429, rota incorreta
Upstream
pool, health check, conexão backend
502, 503, 504
Aplicação
logs, trace, banco e dependências
500, lentidão, regra de negócio
Prática recomendada
Antes de reiniciar um componente, preserve evidências. Reinícios podem aliviar sintomas e apagar estado útil para a análise. Em ambientes críticos, siga procedimentos de incidente, mudança e comunicação definidos pela organização.
1.18 Aplicação em ambientes corporativos e bancários
Instituições financeiras operam com requisitos elevados de confidencialidade, integridade, disponibilidade, rastreabilidade e segregação. Uma chamada pode atravessar internet pública, redes privadas, zonas de segurança, múltiplos , provedores de identidade, sistemas legados e plataformas em nuvem. Cada fronteira acrescenta controles e também complexidade operacional.
é frequentemente utilizado para autenticar participantes técnicos e estabelecer confiança entre organizações ou camadas internas. 2.0 e podem representar autorização delegada, escopos e contexto do cliente. O uso conjunto não é redundância simples: protege e autentica o canal/participante técnico, enquanto podem transportar autorização de aplicação e consentimento conforme o ecossistema.
corporativos aplicam padrões comuns e evitam que cada implemente de forma diferente validação de certificados, , quotas e . Entretanto, políticas devem ser versionadas, testadas e observadas como software. Uma mudança em , algoritmo, ou transformação pode afetar muitas ao mesmo tempo.
Arquiteturas híbridas podem utilizar um on-premises e outro em cloud. Uma requisição pode passar por Axway na borda corporativa e Azure próximo a serviços em Azure, ou o caminho inverso conforme o desenho. Nesses casos, é essencial definir qual camada autentica, qual autoriza, quais podem atravessar, onde termina e como IDs de correlação são preservados.
Risco de não se limita a ataques externos. Configuração incorreta, inventário incompleto, credenciais excessivas, dependências inseguras e consumo de de terceiros podem expor dados e operações. O Security Top 10 e o SP 800-228 oferecem estruturas para estudar vulnerabilidades e controles em fases de pré-runtime e runtime.
O conhecimento das camadas também melhora comunicação entre equipes. Em vez de atribuir genericamente uma falha ao , redes pode confirmar caminho e firewall; segurança pode validar certificados e trust; identidade pode analisar ; plataforma pode verificar policy e ; aplicação pode investigar regra de negócio. Um vocabulário comum reduz o tempo de resolução.
Cenário bancário simplificado
Parceiro apresenta certificado ao . O valida cadeia, validade e identidade cadastrada. Em seguida, valida o e seus escopos. O ainda verifica autorização sobre o recurso solicitado. registram a transação sem gravar segredos.
Resumo do capítulo
dependem de uma cadeia formada por , rede, transporte, , , e
.
Internet, Web, , e são conceitos relacionados, porém distintos.
e Editor definem e publicam muitos protocolos; fabricantes documentam suas
implementações.
separa responsabilidades e permite que camadas evoluam de forma
relativamente independente.
associa nomes a informações de resolução; trata endereçamento e roteamento;
fornece fluxo confiável; protege o canal; define mensagens e semântica de aplicação.
Um é o data plane que aplica políticas e encaminha tráfego; Management
abrange um ciclo de vida mais amplo.
Conexões cliente- e - são independentes e podem ter certificados,
e falhas diferentes.
por camadas começa com evidências e identifica a etapa exata em que a
transação parou.
Questões de revisão
Explique por que Internet e Web não são sinônimos.
Qual é a diferença entre uma e uma ?
Por que a documentação do fabricante não substitui uma ?
O que ocorre durante e desencapsulamento?
Como o modelo de camadas ajuda a investigar falhas?
Qual é a diferença entre roteamento e roteamento de ?
Como de influencia migrações e ?
Por que uma conexão recusada e um sugerem hipóteses diferentes?
Qual é a diferença entre a conexão cliente- e - ?
O que protege e o que ele não resolve sozinho?
Por que e podem ser usados em conjunto?
Como interpretar um código produzido pelo em vez do ?
Quais responsabilidades são adequadas ao e quais devem permanecer no ?
Como desalinhados entre componentes afetam uma chamada?
Descreva, em ordem, a jornada completa de uma requisição .
Estudos de caso
Caso 1 - Certificado trocado durante migração
Uma equipe altera o de .exemplo.com para um novo balanceador. Alguns consumidores acessam normalmente, enquanto outros recebem erro de hostname ou cadeia não confiável. O parece correto nos testes da equipe responsável.
Analise as possíveis causas considerando , split-horizon, , certificado apresentado pelo novo , cadeia intermediária e diferentes. Liste as evidências que você coletaria antes de alterar novamente o .
Caso 2 - 504 intermitente
Uma apresenta 504 em horários de pico. O registra parte das operações concluídas após 40 segundos, mas o possui de 30 segundos. O cliente realiza duas tentativas automáticas.
Explique como e podem aumentar carga e produzir operações duplicadas. Proponha um conjunto de análises envolvendo latência, idempotência, capacidade, limite do e comportamento do consumidor.
Caso 3 - 401 apenas em um ambiente
O mesmo funciona em homologação, mas recebe 401 em produção. O formato do parece correto e a possui o mesmo path nos dois ambientes.
Investigue diferenças possíveis de issuer, audience, chave de assinatura, relógio, escopo, policy, cadeia e produto de . Explique quais dados podem ser registrados com segurança para comparar as duas execuções.
Glossário essencial
Termo
Definição no contexto do capítulo
API
Interface que define como softwares podem utilizar capacidades oferecidas por outro componente.
API Gateway
Intermediário especializado que recebe, protege, medeia e encaminha chamadas de API.
Backend/Upstream
Serviço de destino para o qual o gateway encaminha a requisição.
DNS
Sistema distribuído de nomes utilizado para resolver nomes e outros dados associados.
Encapsulamento
Processo em que cada camada acrescenta informações de controle aos dados.
Endpoint
Ponto de comunicação identificado por informações como esquema, host, porta e caminho.
HTTP
Protocolo de aplicação com modelo de requisição e resposta e semântica padronizada.
IP
Protocolo responsável por endereçamento e encaminhamento de datagramas entre redes.
mTLS
TLS com autenticação do cliente por certificado, além da autenticação do servidor.
Proxy reverso
Intermediário que recebe requisições em nome de servidores internos.
REST
Estilo arquitetural para sistemas hipermídia distribuídos.
RFC
Documento publicado na série Request for Comments, que pode registrar padrões, práticas ou informação.
Socket
Abstração do sistema operacional usada por aplicações para comunicação em rede.
TCP
Protocolo de transporte que oferece fluxo confiável e ordenado de bytes.
TLS
Protocolo que protege comunicações e estabelece confiança criptográfica.
URI
Identificador compacto de um recurso abstrato ou físico.
Referências oficiais e leituras recomendadas
- About . ://www. .org/process/ / - Visão geral do papel das e do processo da .
Editor. ://www. -editor.org/ - Pesquisa e status de .
9293 - Transmission Control Protocol. ://www. -editor.org/ /rfc9293 - Especificação consolidada do .
8200 - Specification. ://www. -editor.org/ /rfc8200 - Especificação do .
1034 - Concepts and Facilities. ://www. -editor.org/ /rfc1034 - Fundamentos conceituais do .
1035 - Implementation and Specification. ://www. -editor.org/ /rfc1035 - Formato e funcionamento do .
9113 - /2. ://www. -editor.org/ /rfc9113 - Especificação do /2.
9114 - /3. ://www. -editor.org/ /rfc9114 - Especificação do /3.
8446 - 1.3. ://www. -editor.org/ /rfc8446 - Especificação do 1.3.
Roy Fielding - Architectural Style. ://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Capítulo da dissertação que descreve .
SP 800-228. ://csrc. .gov/pubs/sp/800/228/final - Diretrizes de proteção de em sistemas cloud-native.
Security Project. :// .org/www-project- -security/ - Riscos e materiais de segurança de .
Microsoft - Azure Management concepts. ://learn.microsoft.com/azure/ -management/ -management-key-concepts - Conceitos e componentes do Azure Management.
Microsoft - Management overview. ://learn.microsoft.com/azure/ -management/ -management- -overview - Papel do no data plane.
Axway - Introduction to . ://docs.axway.com/bundle/axway-open-docs/page/docs/api_mgmt_overview/api_mgmt_components/apigateway/index. - Visão geral oficial do Axway .
