Glossário

Definições dos termos de redes, protocolos em tempo real, criptografia e autenticação utilizados na documentação do sgcWebSockets, sgcSign e sgcBiometrics. Cada entrada inclui um link para a RFC ou especificação relevante, quando aplicável.

WebSocket: Um protocolo de mensagens bidirecional e full-duplex sobre uma única conexão TCP. Padronizado na RFC 6455. Usado pelo sgcWebSocketClient / sgcWebSocketServer como transporte para MQTT, AMQP, STOMP, WAMP e subprotocolos personalizados.
RFC 6455: A especificação IETF "The WebSocket Protocol" — define o handshake, o framing, os frames de controle e o handshake de fechamento. Veja datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: A segunda versão principal do HTTP, projetada para reduzir a latência por meio de multiplexação de streams, compressão de cabeçalhos e server push. Padronizado na RFC 9113.
RFC 9113: "HTTP/2" — a especificação consolidada que substitui a RFC 7540. Define tipos de frame, multiplexação de streams, controle de fluxo, compressão de cabeçalhos via HPACK e as regras de negociação de upgrade.
HPACK: Compressão de cabeçalhos para HTTP/2, definida na RFC 7541. Usa uma tabela estática, uma tabela dinâmica e codificação Huffman para reduzir a sobrecarga de cabeçalhos em cada stream HTTP/2.
RFC 7541: "HPACK: Header Compression for HTTP/2." Especifica as regras de codificação binária, as referências de cabeçalho indexado e a negociação do tamanho da tabela dinâmica usadas por endpoints HTTP/2.
ALPN: Application-Layer Protocol Negotiation, uma extensão TLS definida na RFC 7301. Permite que um cliente anuncie protocolos de aplicação (por exemplo, "h2", "http/1.1") durante o handshake TLS para que o servidor escolha um.
RFC 7301: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension." Define a extensão ALPN usada para negociar HTTP/2 sobre TLS.
HTTP/3: A terceira versão principal do HTTP, executada sobre QUIC em vez de TCP. Padronizado na RFC 9114. Elimina o bloqueio head-of-line e integra o TLS 1.3 ao transporte.
QUIC: Um protocolo de transporte baseado em UDP, multiplexado e seguro, definido na RFC 9000. Transporta HTTP/3 e oferece migração de conexão, 0-RTT e TLS 1.3 integrado.
MQTT: Message Queuing Telemetry Transport — um protocolo de publish-subscribe leve para dispositivos com recursos limitados. Duas versões principais são utilizadas em produção: 3.1.1 e 5.0.
MQTT 3.1.1: Padrão OASIS publicado em 2014. Define o fluxo original CONNECT/PUBLISH/SUBSCRIBE com três níveis de QoS, mensagens retidas e Last Will and Testament. Veja OASIS MQTT 3.1.1.
MQTT 5.0: Padrão OASIS publicado em 2019. Adiciona propriedades de usuário, reason codes, topic aliases, assinaturas compartilhadas, expiração de sessão e autenticação aprimorada em cima do 3.1.1. Veja OASIS MQTT 5.0.
QoS (Quality of Service): Garantia de entrega de mensagens MQTT. QoS 0 — no máximo uma vez (fire-and-forget). QoS 1 — pelo menos uma vez (confirmado com PUBACK). QoS 2 — exatamente uma vez (handshake de quatro etapas: PUBLISH, PUBREC, PUBREL, PUBCOMP).
Retained message: Uma mensagem MQTT armazenada pelo broker e entregue a todo novo assinante cujo filtro de tópico corresponde. Uma mensagem retida por tópico; publicar um payload de tamanho zero com a flag retained limpa a mensagem.
Last Will and Testament (LWT): Uma mensagem MQTT registrada no momento do CONNECT que o broker publica em nome do cliente se a conexão for encerrada de forma anormal. Usada para detecção de presença e notificação de desconexão.
Broker: O servidor central em um protocolo publish-subscribe (MQTT, AMQP, STOMP). Recebe mensagens dos publicadores, faz a correspondência com as assinaturas e as encaminha para os assinantes.
Topic: Uma string hierárquica, delimitada por barras, que identifica o canal em que uma mensagem é publicada. Os assinantes filtram por padrões de tópico.
Wildcard topic: Um filtro de tópico MQTT contendo + (wildcard de nível único) ou # (wildcard de múltiplos níveis, deve ser o segmento final). Exemplo: sensors/+/temperature corresponde a um nível; sensors/# corresponde a todos os descendentes.
AMQP: Advanced Message Queuing Protocol — um protocolo de mensagens binário, em nível de fio, com duas versões principais incompatíveis em uso em produção: 0-9-1 (legado do RabbitMQ) e 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: O protocolo de fio popularizado pelo RabbitMQ. Define o modelo de exchange-queue-binding com os tipos de exchange direct, fanout, topic e headers.
AMQP 1.0: O padrão OASIS / ISO (ISO/IEC 19464). Define um modelo de transferência peer-to-peer baseado em links, utilizado por Azure Service Bus, ActiveMQ Artemis e SwiftMQ.
STOMP: Simple (or Streaming) Text Oriented Messaging Protocol — um protocolo de frames baseado em texto, projetado para ser implementável em qualquer linguagem. Versões 1.0, 1.1 e 1.2. Usado pelo ActiveMQ e pelo RabbitMQ.
WAMP: Web Application Messaging Protocol — combina os padrões RPC e Pub/Sub em uma única conexão, normalmente sobre WebSocket. Definido em wamp-proto.org.
WebRTC: Web Real-Time Communications — uma API de mídia e dados peer-to-peer com qualidade de navegador. Usa ICE para travessia de NAT, DTLS-SRTP para criptografia de mídia e SCTP-sobre-DTLS para canais de dados.
SDP: Session Description Protocol, definido na RFC 8866. Utilizado em trocas de offer/answer do WebRTC para descrever streams de mídia, codecs e candidatos ICE.
ICE: Interactive Connectivity Establishment — o framework de travessia de NAT que coleta pares de endereços candidatos (host, server-reflexive, relayed) e faz checks de conectividade em cada par. Definido na RFC 8445.
STUN: Session Traversal Utilities for NAT — um protocolo para descobrir o IP público e o mapeamento de portas de um host. Especificado na RFC 8489.
RFC 8489: "Session Traversal Utilities for NAT (STUN)." A revisão atual; torna obsoleta a RFC 5389.
TURN: Traversal Using Relays around NAT — uma extensão do STUN que retransmite mídia através de um servidor quando os caminhos peer-to-peer falham. Especificado na RFC 8656.
RFC 8656: "Traversal Using Relays around NAT (TURN): Relay Extensions to STUN." A revisão atual; torna obsoleta a RFC 5766.
RTCPeerConnection: A superfície da API W3C WebRTC que representa uma conexão entre dois peers. Mantém o SDP local e remoto, o estado do ICE e as media tracks. O sgcWebSockets fornece um componente Delphi (TsgcWebRTCPeerConnection) que reflete a API do navegador.
DTLS: Datagram Transport Layer Security — TLS adaptado para transportes não confiáveis no estilo UDP. Usado pelo WebRTC para troca de chaves SRTP. Versão atual: DTLS 1.3.
RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3." Especificação mais recente do DTLS.
TLS 1.2: Transport Layer Security 1.2, definido na RFC 5246. Amplamente implantado; ainda exigido por endpoints HTTP/2 que não migraram para TLS 1.3.
TLS 1.3: Transport Layer Security 1.3, a revisão principal atual do TLS. Remove ciphersuites legadas, exige forward secrecy e suporta retomada 0-RTT. Especificado na RFC 8446.
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3."
JWT: JSON Web Token — um formato de token compacto e seguro para URLs que carrega claims assinadas. Definido na RFC 7519. Usado para autenticação sem estado.
RFC 7519: "JSON Web Token (JWT)." Especifica o conjunto de claims, o formato do cabeçalho e as regras de serialização.
JWS: JSON Web Signature, definido na RFC 7515. O mecanismo de assinatura usado pelos JWTs (header.payload.signature).
JWE: JSON Web Encryption, definido na RFC 7516. O mecanismo de criptografia usado para produzir JWTs criptografados.
OAuth 2.0: Um framework de autorização que permite a uma aplicação de terceiros obter acesso limitado aos recursos de um usuário sem compartilhar suas credenciais. Definido na RFC 6749.
RFC 6749: "The OAuth 2.0 Authorization Framework." Define quatro tipos de grant principais, o modelo access token / refresh token e o contrato authorization endpoint / token endpoint.
PKCE: Proof Key for Code Exchange — uma extensão do OAuth 2.0 que mitiga o ataque de interceptação do authorization code para clientes públicos. Definida na RFC 7636. Agora exigida para todos os clientes OAuth 2.1.
RFC 7636: "Proof Key for Code Exchange by OAuth Public Clients."
OAuth Authorization Code grant: O fluxo OAuth com redirecionamento de navegador usado por aplicações web e nativas. O cliente recebe um code do authorization endpoint e o troca (do lado do servidor, com PKCE) por tokens no token endpoint.
OAuth Client Credentials grant: O fluxo OAuth machine-to-machine no qual o cliente se autentica com suas próprias credenciais (sem usuário) para obter um access token para chamadas a serviços de backend.
OAuth Device Authorization grant: O fluxo OAuth para dispositivos com entrada limitada (TVs, ferramentas CLI). Definido na RFC 8628. O dispositivo consulta o token endpoint enquanto o usuário se autentica em um dispositivo secundário.
OAuth Resource Owner Password grant: Fluxo legado do OAuth 2.0 no qual o cliente coleta diretamente o nome de usuário e a senha do usuário e os envia ao token endpoint. Descontinuado no OAuth 2.1 em favor do authorization code + PKCE.
OAuth Refresh Token: Um token de longa duração retornado junto com um access token. Usado no token endpoint para obter um novo access token sem precisar consultar o usuário novamente.
DPoP: Demonstration of Proof-of-Possession — um mecanismo do OAuth 2.0 que vincula access tokens a um par de chaves mantido pelo cliente, mitigando o roubo de bearer tokens. Definido na RFC 9449.
OpenID Connect: Uma camada de identidade construída sobre o OAuth 2.0 que retorna um ID Token assinado (JWT) junto com o access token, com um endpoint UserInfo padronizado e um documento de discovery.
WebAuthn: A API W3C Web Authentication para autenticação sem senha usando credenciais de chave pública respaldadas por autenticadores de plataforma ou chaves de segurança roaming.
FIDO2: O guarda-chuva da FIDO Alliance para o WebAuthn + o CTAP (Client-To-Authenticator Protocol) usado entre o navegador e um autenticador externo.
U2F: Universal 2nd Factor — o protocolo FIDO original para chaves de segurança como segundo fator. Substituído pelo FIDO2 / CTAP2, mas ainda suportado por YubiKeys legados.
Server-Sent Events (SSE): Um protocolo de streaming simples, baseado em texto e unidirecional, sobre HTTP, usando Content-Type: text/event-stream. Faz parte do padrão WHATWG HTML. Usado para notificações ao vivo e respostas em streaming de IA.
Socket.IO: Uma biblioteca de mais alto nível sobre o WebSocket (com fallback para HTTP long-polling) que fornece rooms, namespaces, reconexão automática e suporte a binários. Protocolo de fio distinto do WebSocket bruto.
SignalR: Biblioteca em tempo real da Microsoft originalmente para ASP.NET. Usa WebSocket, Server-Sent Events ou long polling como transporte, com RPC baseado em hubs integrado e negociação automática de transporte.
SignalR Core: O SignalR redesenhado para ASP.NET Core. Usa um protocolo de fio diferente do SignalR clássico — os clientes devem usar a versão de servidor correspondente.
Pusher: Um serviço de mensageria em tempo real hospedado, com semântica de canais e presença. O sgcWebSockets inclui um componente cliente Pusher tipado.
MCP (Model Context Protocol): Um protocolo aberto introduzido pela Anthropic para expor ferramentas, recursos e prompts de um servidor para uma aplicação host alimentada por LLM. O sgcWebSockets fornece tanto um cliente MCP (TsgcWSAPIClient_MCP) quanto um servidor (TsgcWSAPIServer_MCP).
Cloud HSM: Um Hardware Security Module alugado como serviço de nuvem (por exemplo, AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). As chaves nunca saem do HSM; as operações de assinatura são remotas.
eIDAS: Electronic Identification, Authentication and Trust Services — o regulamento da UE (910/2014, atualizado por 2024/1183) que define as Qualified Electronic Signatures (QES), os Qualified Trust Service Providers e a equivalência legal das QES a assinaturas manuscritas.
Code signing: Aplicar uma assinatura digital a um executável, biblioteca ou instalador para que sistemas operacionais e usuários possam verificar a origem e a integridade antes de executá-lo. Windows usa Authenticode; macOS usa codesign; Java usa jarsigner.
ClickOnce signing: Assinatura do manifesto de implantação da Microsoft para aplicações .NET ClickOnce. Assina o manifesto da aplicação e o manifesto de implantação com um certificado Authenticode.
NuGet signing: Adicionar uma assinatura PKCS#7 de autor ou de repositório a um arquivo .nupkg para que os consumidores possam verificar a origem do pacote. Necessária para a listagem de pacotes assinados em nuget.org.
VSIX signing: Assinar um pacote Visual Studio Extension (.vsix) usando assinaturas OPC (Open Packaging Conventions) para que a galeria do Visual Studio possa verificar a procedência.
Windows Hello: Recurso de login biométrico / PIN da Microsoft no Windows 10 e 11. Construído sobre o Windows Biometric Framework e o platform credential provider.
Windows Biometric Framework: O framework do Windows em modo kernel + modo usuário que abstrai sensores biométricos atrás de uma API comum. O sgcBiometrics é construído diretamente sobre o WBF (Winbio*).
IOCP: I/O Completion Ports — a primitiva escalável de I/O assíncrono do Windows. A edição Enterprise do sgcWebSockets inclui um servidor IOCP no estilo Indy que escala para dezenas de milhares de conexões WebSocket simultâneas.
EPOLL: O recurso escalável de notificação de eventos de I/O do Linux. A edição Enterprise do sgcWebSockets inclui um servidor EPOLL para Linux64 com design equivalente ao IOCP.
HTTP.SYS: O listener HTTP em modo kernel do Windows (usado pelo IIS e pelo Windows Communication Foundation). O servidor HTTP.SYS Enterprise registra prefixos de URL no kernel para alto throughput.
OpenSSL: A biblioteca de TLS/criptografia open-source amplamente implantada (libssl + libcrypto). O sgcWebSockets suporta tanto OpenSSL 1.0.2/1.1.1 quanto a atual OpenSSL 3.x.
SChannel: Secure Channel — o provedor TLS/SSL da Microsoft Windows integrado ao SO. O sgcWebSockets suporta SChannel como alternativa ao OpenSSL no Windows; sem DLLs para redistribuir.
gRPC: Um framework de RPC moderno, contract-first, que usa Protocol Buffers sobre streams HTTP/2. Suporta chamadas unárias, server-streaming, client-streaming e bidirectional-streaming.
Server Push: Um mecanismo do HTTP/2 que permite ao servidor enviar recursos (PUSH_PROMISE) ao cliente antes que o cliente os solicite. Agora desativado por padrão em navegadores baseados em Chromium; o sgcWebSockets ainda o suporta para uso backend-to-backend.
Multiplexing: Transportar múltiplos streams independentes sobre uma única conexão de transporte. O HTTP/2 multiplexa streams sobre uma conexão TCP; o HTTP/3 multiplexa streams sobre uma conexão QUIC sem bloqueio head-of-line na camada de transporte.
Header compression: Reduzir o custo em bytes na linha de cabeçalhos HTTP repetidos. O HTTP/2 usa HPACK; o HTTP/3 usa QPACK. Ambos dependem de uma tabela dinâmica por conexão de campos de cabeçalho usados recentemente.
Flow control: O mecanismo que impede um remetente de sobrecarregar um receptor. O HTTP/2 tem janelas de controle de fluxo por stream e por conexão, controladas por frames WINDOW_UPDATE.
Keep-alive: Frames de sonda periódicos enviados para manter uma conexão viva através de intermediários e detectar peers mortos. O WebSocket usa frames de controle PING/PONG; o MQTT usa PINGREQ/PINGRESP no intervalo KeepAlive configurado.
CoAP: Constrained Application Protocol — um protocolo RESTful baseado em UDP para dispositivos com recursos limitados, com DTLS opcional. Especificado na RFC 7252.
RCON: Source Remote Console — o protocolo de administração remota da Valve / Source-engine usado por Counter-Strike, Garry's Mod e servidores de jogos semelhantes. O sgcWebSockets inclui um cliente RCON tipado.

Glossário

Precisa da definição de um termo?