Glossario

Definizioni dei termini di networking, protocolli in tempo reale, crittografia e autenticazione utilizzati nella documentazione di sgcWebSockets, sgcSign e sgcBiometrics. Ogni voce rimanda all'RFC o alla specifica pertinente, ove disponibile.

WebSocket: Protocollo di messaggistica bidirezionale e full-duplex su una singola connessione TCP. Standardizzato in RFC 6455. Utilizzato da sgcWebSocketClient / sgcWebSocketServer come trasporto per MQTT, AMQP, STOMP, WAMP e sottoprotocolli personalizzati.
RFC 6455: La specifica IETF "The WebSocket Protocol" — definisce l'handshake, il framing, i frame di controllo e l'handshake di chiusura. Vedi datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: La seconda versione principale di HTTP, progettata per ridurre la latenza tramite multiplexing dei flussi, compressione delle intestazioni e server push. Standardizzata in RFC 9113.
RFC 9113: "HTTP/2" — la specifica consolidata che sostituisce RFC 7540. Definisce i tipi di frame, il multiplexing dei flussi, il controllo di flusso, la compressione delle intestazioni tramite HPACK e le regole di negoziazione dell'upgrade.
HPACK: Compressione delle intestazioni per HTTP/2, definita in RFC 7541. Utilizza una tabella statica, una tabella dinamica e la codifica Huffman per ridurre l'overhead delle intestazioni su ciascun flusso HTTP/2.
RFC 7541: "HPACK: Header Compression for HTTP/2." Specifica le regole di codifica binaria, i riferimenti alle intestazioni indicizzate e la negoziazione della dimensione della tabella dinamica utilizzata dagli endpoint HTTP/2.
ALPN: Application-Layer Protocol Negotiation, un'estensione TLS definita in RFC 7301. Permette al client di annunciare i protocolli applicativi (ad es. "h2", "http/1.1") durante l'handshake TLS in modo che il server ne possa scegliere uno.
RFC 7301: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension." Definisce l'estensione ALPN utilizzata per negoziare HTTP/2 su TLS.
HTTP/3: La terza versione principale di HTTP, eseguita su QUIC anziché su TCP. Standardizzata in RFC 9114. Elimina il blocco head-of-line e integra TLS 1.3 nel trasporto.
QUIC: Protocollo di trasporto sicuro e multiplexato basato su UDP, definito in RFC 9000. Trasporta HTTP/3 e offre migrazione della connessione, 0-RTT e TLS 1.3 integrato.
MQTT: Message Queuing Telemetry Transport — un protocollo publish-subscribe leggero per dispositivi con risorse limitate. Due versioni principali sono in uso in produzione: 3.1.1 e 5.0.
MQTT 3.1.1: Standard OASIS pubblicato nel 2014. Definisce il flusso originale CONNECT/PUBLISH/SUBSCRIBE con tre livelli di QoS, messaggi retained e Last Will and Testament. Vedi OASIS MQTT 3.1.1.
MQTT 5.0: Standard OASIS pubblicato nel 2019. Aggiunge proprietà utente, reason code, alias di topic, sottoscrizioni condivise, scadenza della sessione e autenticazione avanzata rispetto a 3.1.1. Vedi OASIS MQTT 5.0.
QoS (Quality of Service): Garanzia di consegna dei messaggi MQTT. QoS 0 — al massimo una volta (fire-and-forget). QoS 1 — almeno una volta (con conferma PUBACK). QoS 2 — esattamente una volta (handshake in quattro passi: PUBLISH, PUBREC, PUBREL, PUBCOMP).
Messaggio retained: Un messaggio MQTT memorizzato dal broker e consegnato a ogni nuovo sottoscrittore il cui filtro di topic corrisponde. Un solo messaggio retained per topic; pubblicare un payload di lunghezza zero con il flag retained lo cancella.
Last Will and Testament (LWT): Un messaggio MQTT registrato al momento del CONNECT che il broker pubblica per conto del client se la connessione viene chiusa in modo anomalo. Utilizzato per il rilevamento della presenza e per le notifiche di disconnessione.
Broker: Il server centrale in un protocollo publish-subscribe (MQTT, AMQP, STOMP). Riceve i messaggi dai publisher, li confronta con le sottoscrizioni e li inoltra ai sottoscrittori.
Topic: Una stringa gerarchica, delimitata da barre, che identifica il canale su cui viene pubblicato un messaggio. I sottoscrittori filtrano in base a pattern di topic.
Topic con wildcard: Un filtro di topic MQTT che contiene + (wildcard di un solo livello) o # (wildcard multilivello, deve essere il segmento finale). Esempio: sensors/+/temperature corrisponde a un livello; sensors/# corrisponde a ogni discendente.
AMQP: Advanced Message Queuing Protocol — un protocollo di messaggistica binario, a livello di wire, con due versioni principali incompatibili in uso in produzione: 0-9-1 (RabbitMQ legacy) e 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: Il protocollo wire reso popolare da RabbitMQ. Definisce il modello exchange-queue-binding con i tipi di exchange direct, fanout, topic e headers.
AMQP 1.0: Lo standard OASIS / ISO (ISO/IEC 19464). Definisce un modello di trasferimento peer-to-peer basato su link, utilizzato da Azure Service Bus, ActiveMQ Artemis e SwiftMQ.
STOMP: Simple (or Streaming) Text Oriented Messaging Protocol — un protocollo a frame basato su testo, progettato per essere implementabile in qualsiasi linguaggio. Versioni 1.0, 1.1, 1.2. Utilizzato da ActiveMQ e RabbitMQ.
WAMP: Web Application Messaging Protocol — combina i pattern RPC e Pub/Sub su un'unica connessione, in genere su WebSocket. Definito su wamp-proto.org.
WebRTC: Web Real-Time Communications — un'API peer-to-peer per media e dati di livello browser. Utilizza ICE per attraversare il NAT, DTLS-SRTP per la crittografia dei media e SCTP-over-DTLS per i data channel.
SDP: Session Description Protocol, definito in RFC 8866. Utilizzato negli scambi offer/answer di WebRTC per descrivere flussi multimediali, codec e candidate ICE.
ICE: Interactive Connectivity Establishment — il framework di NAT-traversal che raccoglie coppie di indirizzi candidate (host, server-reflexive, relayed) e verifica la connettività di ciascuna coppia. Definito in RFC 8445.
STUN: Session Traversal Utilities for NAT — un protocollo per scoprire l'IP pubblico di un host e il relativo mapping di porta. Specificato in RFC 8489.
RFC 8489: "Session Traversal Utilities for NAT (STUN)." La revisione attuale; rende obsoleto RFC 5389.
TURN: Traversal Using Relays around NAT — un'estensione di STUN che inoltra i media tramite un server quando i percorsi peer-to-peer falliscono. Specificato in RFC 8656.
RFC 8656: "Traversal Using Relays around NAT (TURN): Relay Extensions to STUN." La revisione attuale; rende obsoleto RFC 5766.
RTCPeerConnection: L'interfaccia API W3C WebRTC che rappresenta una connessione tra due peer. Contiene l'SDP locale e remoto, lo stato ICE e le tracce multimediali. sgcWebSockets include un componente Delphi (TsgcWebRTCPeerConnection) che rispecchia l'API del browser.
DTLS: Datagram Transport Layer Security — TLS adattato a trasporti inaffidabili di tipo UDP. Utilizzato da WebRTC per lo scambio delle chiavi SRTP. Versione attuale: DTLS 1.3.
RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3." Ultima specifica DTLS.
TLS 1.2: Transport Layer Security 1.2, definito in RFC 5246. Ampiamente diffuso; ancora richiesto dagli endpoint HTTP/2 che non sono migrati a TLS 1.3.
TLS 1.3: Transport Layer Security 1.3, l'attuale revisione principale di TLS. Rimuove le ciphersuite legacy, richiede la forward secrecy e supporta la ripresa 0-RTT. Specificato in RFC 8446.
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3."
JWT: JSON Web Token — un formato di token compatto e URL-safe che trasporta claim firmati. Definito in RFC 7519. Utilizzato per l'autenticazione stateless.
RFC 7519: "JSON Web Token (JWT)." Specifica l'insieme di claim, il formato dell'intestazione e le regole di serializzazione.
JWS: JSON Web Signature, definito in RFC 7515. Il meccanismo di firma utilizzato dai JWT (header.payload.signature).
JWE: JSON Web Encryption, definito in RFC 7516. Il meccanismo di crittografia utilizzato per produrre JWT cifrati.
OAuth 2.0: Un framework di autorizzazione che permette a un'applicazione di terze parti di ottenere un accesso limitato alle risorse di un utente senza condividerne le credenziali. Definito in RFC 6749.
RFC 6749: "The OAuth 2.0 Authorization Framework." Definisce quattro grant type principali, il modello access token / refresh token e il contratto tra authorization endpoint e token endpoint.
PKCE: Proof Key for Code Exchange — un'estensione di OAuth 2.0 che mitiga l'attacco di intercettazione del codice di autorizzazione per i client pubblici. Definito in RFC 7636. Ora richiesto per tutti i client OAuth 2.1.
RFC 7636: "Proof Key for Code Exchange by OAuth Public Clients."
OAuth Authorization Code grant: Il flusso OAuth con redirect tramite browser utilizzato dalle applicazioni web e native. Il client riceve un codice dall'authorization endpoint e lo scambia (lato server, con PKCE) per ottenere token al token endpoint.
OAuth Client Credentials grant: Il flusso OAuth machine-to-machine in cui il client si autentica con le proprie credenziali (senza utente) per ottenere un access token per le chiamate ai servizi backend.
OAuth Device Authorization grant: Il flusso OAuth per dispositivi con input limitato (TV, strumenti CLI). Definito in RFC 8628. Il dispositivo interroga il token endpoint mentre l'utente si autentica su un dispositivo secondario.
OAuth Resource Owner Password grant: Flusso legacy di OAuth 2.0 in cui il client raccoglie direttamente username e password dell'utente e li invia al token endpoint. Deprecato in OAuth 2.1 in favore di authorization-code + PKCE.
OAuth Refresh Token: Un token di lunga durata restituito insieme a un access token. Utilizzato al token endpoint per ottenere un nuovo access token senza richiedere nuovamente all'utente.
DPoP: Demonstration of Proof-of-Possession — un meccanismo di OAuth 2.0 che lega gli access token a una coppia di chiavi in possesso del client, mitigando il furto dei bearer token. Definito in RFC 9449.
OpenID Connect: Un livello di identità costruito su OAuth 2.0 che restituisce un ID Token firmato (JWT) insieme all'access token, con un endpoint UserInfo standardizzato e un documento di discovery.
WebAuthn: L'API W3C Web Authentication per l'autenticazione senza password tramite credenziali a chiave pubblica, supportate da authenticator di piattaforma o security key roaming.
FIDO2: L'ombrello della FIDO Alliance che comprende WebAuthn + il CTAP (Client-To-Authenticator Protocol) utilizzato tra il browser e un authenticator esterno.
U2F: Universal 2nd Factor — il protocollo FIDO originale per security key di secondo fattore. Sostituito da FIDO2 / CTAP2 ma ancora supportato dalle YubiKey legacy.
Server-Sent Events (SSE): Un protocollo di streaming unidirezionale, testuale e semplice, su HTTP che utilizza Content-Type: text/event-stream. Fa parte dello standard WHATWG HTML. Utilizzato per notifiche live e risposte AI in streaming.
Socket.IO: Una libreria di livello superiore basata su WebSocket (con fallback HTTP long-polling) che offre stanze, namespace, riconnessione automatica e supporto binario. Protocollo wire distinto rispetto al WebSocket grezzo.
SignalR: La libreria in tempo reale di Microsoft originariamente pensata per ASP.NET. Utilizza WebSocket, Server-Sent Events o long polling come trasporto, con RPC integrato basato su hub e negoziazione automatica del trasporto.
SignalR Core: La nuova versione di SignalR per ASP.NET Core. Utilizza un protocollo on-the-wire diverso da quello del SignalR classico — i client devono puntare alla versione di server corrispondente.
Pusher: Un servizio di messaggistica in tempo reale in hosting con semantica di canali e presenza. sgcWebSockets include un componente client Pusher tipizzato.
MCP (Model Context Protocol): Un protocollo aperto introdotto da Anthropic per esporre strumenti, risorse e prompt da un server a un'applicazione host basata su LLM. sgcWebSockets include sia un client MCP (TsgcWSAPIClient_MCP) sia un server (TsgcWSAPIServer_MCP).
Cloud HSM: Un Hardware Security Module utilizzato come servizio cloud (ad es. AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). Le chiavi non lasciano mai l'HSM; le operazioni di firma sono remote.
eIDAS: Electronic Identification, Authentication and Trust Services — il regolamento UE (910/2014, aggiornato dal 2024/1183) che definisce le firme elettroniche qualificate (QES), i Qualified Trust Service Provider e l'equivalenza legale delle QES rispetto alle firme autografe.
Code signing: Applicare una firma digitale a un eseguibile, una libreria o un installer in modo che sistemi operativi e utenti possano verificarne origine e integrità prima dell'esecuzione. Windows usa Authenticode; macOS usa codesign; Java usa jarsigner.
Firma ClickOnce: La firma dei manifesti di deployment Microsoft per le applicazioni ClickOnce .NET. Firma il manifesto dell'applicazione e il manifesto di deployment con un certificato Authenticode.
Firma NuGet: Aggiungere una firma autore o repository PKCS#7 a un file .nupkg in modo che i consumatori possano verificarne l'origine. Richiesta per la pubblicazione di pacchetti firmati su nuget.org.
Firma VSIX: Firmare un pacchetto Visual Studio Extension (.vsix) utilizzando firme OPC (Open Packaging Conventions) affinché la gallery di Visual Studio possa verificarne la provenienza.
Windows Hello: La funzionalità di accesso biometrico / PIN di Microsoft in Windows 10 e 11. Costruita sul Windows Biometric Framework e sul credential provider di piattaforma.
Windows Biometric Framework: Il framework Windows kernel-mode + user-mode che astrae i sensori biometrici dietro un'API comune. sgcBiometrics si basa direttamente su WBF (Winbio*).
IOCP: I/O Completion Ports — la primitiva scalabile di I/O asincrono di Windows. L'edizione Enterprise di sgcWebSockets include un server IOCP in stile Indy che scala fino a decine di migliaia di connessioni WebSocket concorrenti.
EPOLL: Il meccanismo Linux scalabile di notifica degli eventi I/O. L'edizione Enterprise di sgcWebSockets include un server EPOLL Linux64 con design analogo a IOCP.
HTTP.SYS: Il listener HTTP kernel-mode di Windows (utilizzato da IIS e Windows Communication Foundation). Il server Enterprise HTTP.SYS registra i prefissi di URL nel kernel per ottenere elevato throughput.
OpenSSL: La libreria open source TLS/crittografica ampiamente diffusa (libssl + libcrypto). sgcWebSockets supporta sia OpenSSL 1.0.2/1.1.1 sia l'attuale OpenSSL 3.x.
SChannel: Secure Channel — il provider TLS/SSL Microsoft Windows integrato nel sistema operativo. sgcWebSockets supporta SChannel come alternativa a OpenSSL su Windows; nessuna DLL da ridistribuire.
gRPC: Un framework RPC moderno, contract-first, che utilizza Protocol Buffers su flussi HTTP/2. Supporta chiamate unary, server-streaming, client-streaming e bidirectional-streaming.
Server Push: Un meccanismo HTTP/2 che permette al server di inviare risorse (PUSH_PROMISE) al client prima che le richieda. Ora disabilitato di default nei browser basati su Chromium; sgcWebSockets continua a supportarlo per l'uso backend-to-backend.
Multiplexing: Trasportare più flussi indipendenti su un'unica connessione di trasporto. HTTP/2 multiplexa i flussi su una sola connessione TCP; HTTP/3 li multiplexa su una sola connessione QUIC senza blocco head-of-line a livello di trasporto.
Compressione delle intestazioni: Ridurre il costo in byte-on-wire delle intestazioni HTTP ripetute. HTTP/2 utilizza HPACK; HTTP/3 utilizza QPACK. Entrambi si basano su una tabella dinamica per connessione di campi di intestazione usati di recente.
Controllo di flusso: Il meccanismo che evita che un mittente sovraccarichi un destinatario. HTTP/2 dispone di finestre di controllo di flusso per stream e per connessione, gestite dai frame WINDOW_UPDATE.
Keep-alive: Frame di probe periodici inviati per mantenere attiva una connessione attraverso gli intermediari e rilevare peer non più attivi. WebSocket utilizza frame di controllo PING/PONG; MQTT utilizza PINGREQ/PINGRESP all'intervallo KeepAlive configurato.
CoAP: Constrained Application Protocol — un protocollo RESTful basato su UDP per dispositivi con risorse limitate, con DTLS opzionale. Specificato in RFC 7252.
RCON: Source Remote Console — il protocollo di amministrazione remota Valve / Source engine utilizzato da Counter-Strike, Garry's Mod e server di gioco simili. sgcWebSockets include un client RCON tipizzato.

Glossario

Hai bisogno della definizione di un termine?