Glossaire

Définitions des termes de réseau, de protocole temps réel, de cryptographie et d'authentification utilisés dans la documentation sgcWebSockets, sgcSign et sgcBiometrics. Chaque entrée renvoie au RFC ou à la spécification pertinente le cas échéant.

WebSocket: Protocole de messagerie bidirectionnel full-duplex sur une seule connexion TCP. Normalisé dans la RFC 6455. Utilisé par sgcWebSocketClient / sgcWebSocketServer comme transport pour MQTT, AMQP, STOMP, WAMP et des sous-protocoles personnalisés.
RFC 6455: Spécification IETF « The WebSocket Protocol » — définit la poignée de main, le découpage en trames, les trames de contrôle et la poignée de main de fermeture. Voir datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: Deuxième version majeure de HTTP, conçue pour réduire la latence grâce au multiplexage de flux, à la compression d'en-têtes et au push serveur. Normalisée dans la RFC 9113.
RFC 9113: « HTTP/2 » — la spécification consolidée qui remplace la RFC 7540. Définit les types de trames, le multiplexage de flux, le contrôle de flux, la compression d'en-têtes via HPACK et les règles de négociation de mise à niveau.
HPACK: Compression d'en-têtes pour HTTP/2, définie dans la RFC 7541. Utilise une table statique, une table dynamique et le codage Huffman pour réduire la surcharge d'en-têtes sur chaque flux HTTP/2.
RFC 7541: « HPACK : Header Compression for HTTP/2. » Spécifie les règles d'encodage binaire, les références d'en-têtes indexées et la négociation de la taille de la table dynamique utilisée par les terminaux HTTP/2.
ALPN: Application-Layer Protocol Negotiation, une extension TLS définie dans la RFC 7301. Permet à un client d'annoncer les protocoles applicatifs (par exemple « h2 », « http/1.1 ») pendant la poignée de main TLS afin que le serveur puisse en choisir un.
RFC 7301: « Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. » Définit l'extension ALPN utilisée pour négocier HTTP/2 sur TLS.
HTTP/3: Troisième version majeure de HTTP, qui s'exécute sur QUIC plutôt que TCP. Normalisée dans la RFC 9114. Supprime le blocage en tête de file et intègre TLS 1.3 au transport.
QUIC: Protocole de transport sécurisé, multiplexé, basé sur UDP, défini dans la RFC 9000. Transporte HTTP/3 et offre la migration de connexion, le 0-RTT et TLS 1.3 intégré.
MQTT: Message Queuing Telemetry Transport — un protocole publication-abonnement léger pour les appareils contraints. Deux versions majeures sont en usage en production : 3.1.1 et 5.0.
MQTT 3.1.1: Standard OASIS publié en 2014. Définit le flux original CONNECT/PUBLISH/SUBSCRIBE avec trois niveaux de QoS, les messages retenus et le Last Will and Testament. Voir OASIS MQTT 3.1.1.
MQTT 5.0: Standard OASIS publié en 2019. Ajoute les propriétés utilisateur, les codes de raison, les alias de sujet, les abonnements partagés, l'expiration de session et l'authentification améliorée par-dessus 3.1.1. Voir OASIS MQTT 5.0.
QoS (Quality of Service): Garantie de livraison de message MQTT. QoS 0 — au plus une fois (envoi sans confirmation). QoS 1 — au moins une fois (acquitté par PUBACK). QoS 2 — exactement une fois (poignée de main en quatre étapes : PUBLISH, PUBREC, PUBREL, PUBCOMP).
Message retenu: Un message MQTT stocké par le broker et délivré à chaque nouvel abonné dont le filtre de sujet correspond. Un message retenu par sujet ; publier un payload de longueur zéro avec l'indicateur retained le supprime.
Last Will and Testament (LWT): Un message MQTT enregistré au moment du CONNECT que le broker publie au nom du client si la connexion est fermée de manière anormale. Utilisé pour la détection de présence et la notification de déconnexion.
Broker: Le serveur central d'un protocole publication-abonnement (MQTT, AMQP, STOMP). Reçoit les messages des éditeurs, les associe aux abonnements et les transmet aux abonnés.
Topic: Une chaîne hiérarchique délimitée par des barres obliques qui identifie le canal auquel un message est publié. Les abonnés filtrent sur des motifs de sujet.
Topic avec joker: Un filtre de sujet MQTT qui contient + (joker à un seul niveau) ou # (joker multi-niveaux, doit être le segment final). Exemple : sensors/+/temperature correspond à un niveau ; sensors/# correspond à tous les descendants.
AMQP: Advanced Message Queuing Protocol — un protocole de messagerie binaire au niveau du fil, avec deux versions majeures incompatibles en usage en production : 0-9-1 (héritage RabbitMQ) et 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: Le protocole filaire popularisé par RabbitMQ. Définit le modèle exchange-queue-binding avec les types d'exchange direct, fanout, topic et headers.
AMQP 1.0: Standard OASIS / ISO (ISO/IEC 19464). Définit un modèle de transfert pair-à-pair basé sur des liens utilisé par Azure Service Bus, ActiveMQ Artemis et SwiftMQ.
STOMP: Simple (or Streaming) Text Oriented Messaging Protocol — un protocole de trames basé sur du texte conçu pour être implémentable dans n'importe quel langage. Versions 1.0, 1.1, 1.2. Utilisé par ActiveMQ et RabbitMQ.
WAMP: Web Application Messaging Protocol — combine les schémas RPC et Pub/Sub sur une seule connexion, généralement sur WebSocket. Défini sur wamp-proto.org.
WebRTC: Web Real-Time Communications — une API média et données pair-à-pair de qualité navigateur. Utilise ICE pour traverser les NAT, DTLS-SRTP pour le chiffrement média et SCTP-over-DTLS pour les canaux de données.
SDP: Session Description Protocol, défini dans la RFC 8866. Utilisé dans les échanges offre/réponse WebRTC pour décrire les flux médias, les codecs et les candidats ICE.
ICE: Interactive Connectivity Establishment — le framework de traversée de NAT qui collecte des paires d'adresses candidates (hôte, server-reflexive, relayée) et vérifie la connectivité de chaque paire. Défini dans la RFC 8445.
STUN: Session Traversal Utilities for NAT — un protocole pour découvrir l'IP publique d'un hôte et le mappage de ports. Spécifié dans la RFC 8489.
RFC 8489: « Session Traversal Utilities for NAT (STUN). » La révision actuelle ; rend obsolète la RFC 5389.
TURN: Traversal Using Relays around NAT — une extension de STUN qui relaie les médias via un serveur lorsque les chemins pair-à-pair échouent. Spécifié dans la RFC 8656.
RFC 8656: « Traversal Using Relays around NAT (TURN) : Relay Extensions to STUN. » La révision actuelle ; rend obsolète la RFC 5766.
RTCPeerConnection: La surface d'API W3C WebRTC qui représente une connexion entre deux pairs. Contient les SDP local et distant, l'état ICE et les pistes médias. sgcWebSockets fournit un composant Delphi (TsgcWebRTCPeerConnection) qui reflète l'API du navigateur.
DTLS: Datagram Transport Layer Security — TLS adapté aux transports non fiables de style UDP. Utilisé par WebRTC pour l'échange de clés SRTP. Version actuelle : DTLS 1.3.
RFC 9147: « The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. » Dernière spécification DTLS.
TLS 1.2: Transport Layer Security 1.2, défini dans la RFC 5246. Largement déployé ; encore requis par les terminaux HTTP/2 qui n'ont pas migré vers TLS 1.3.
TLS 1.3: Transport Layer Security 1.3, la révision majeure actuelle de TLS. Supprime les suites de chiffrement obsolètes, exige la forward secrecy et prend en charge la reprise 0-RTT. Spécifié dans la RFC 8446.
RFC 8446: « The Transport Layer Security (TLS) Protocol Version 1.3. »
JWT: JSON Web Token — un format de jeton compact et URL-safe qui transporte des revendications signées. Défini dans la RFC 7519. Utilisé pour l'authentification sans état.
RFC 7519: « JSON Web Token (JWT). » Spécifie l'ensemble des revendications, le format d'en-tête et les règles de sérialisation.
JWS: JSON Web Signature, défini dans la RFC 7515. Le mécanisme de signature utilisé par les JWT (header.payload.signature).
JWE: JSON Web Encryption, défini dans la RFC 7516. Le mécanisme de chiffrement utilisé pour produire des JWT chiffrés.
OAuth 2.0: Un framework d'autorisation qui permet à une application tierce d'obtenir un accès limité aux ressources d'un utilisateur sans partager ses identifiants. Défini dans la RFC 6749.
RFC 6749: « The OAuth 2.0 Authorization Framework. » Définit quatre types de grant principaux, le modèle access token / refresh token et le contrat entre les points de terminaison authorization et token.
PKCE: Proof Key for Code Exchange — une extension OAuth 2.0 qui atténue l'attaque par interception du code d'autorisation pour les clients publics. Définie dans la RFC 7636. Maintenant requise pour tous les clients OAuth 2.1.
RFC 7636: « Proof Key for Code Exchange by OAuth Public Clients. »
Grant OAuth Authorization Code: Le flux OAuth par redirection de navigateur utilisé par les applications web et natives. Le client reçoit un code du point de terminaison authorization et l'échange (côté serveur, avec PKCE) contre des jetons au point de terminaison token.
Grant OAuth Client Credentials: Le flux OAuth machine-à-machine où le client s'authentifie avec ses propres identifiants (sans utilisateur) pour obtenir un access token pour les appels de services backend.
Grant OAuth Device Authorization: Le flux OAuth pour les appareils à entrée contrainte (téléviseurs, outils CLI). Défini dans la RFC 8628. L'appareil interroge le point de terminaison token pendant que l'utilisateur s'authentifie sur un appareil secondaire.
Grant OAuth Resource Owner Password: Flux OAuth 2.0 hérité où le client collecte directement le nom d'utilisateur et le mot de passe et les envoie au point de terminaison token. Déconseillé dans OAuth 2.1 au profit du authorization-code + PKCE.
Refresh Token OAuth: Un jeton à longue durée de vie renvoyé avec un access token. Utilisé au point de terminaison token pour obtenir un nouvel access token sans demander à nouveau l'utilisateur.
DPoP: Demonstration of Proof-of-Possession — un mécanisme OAuth 2.0 qui lie les access tokens à une paire de clés détenue par le client, atténuant le vol de jetons bearer. Défini dans la RFC 9449.
OpenID Connect: Une couche d'identité construite par-dessus OAuth 2.0 qui renvoie un ID Token signé (JWT) avec l'access token, accompagné d'un point de terminaison UserInfo standardisé et d'un document de découverte.
WebAuthn: L'API W3C Web Authentication pour l'authentification sans mot de passe à l'aide d'identifiants à clé publique soutenus par des authentificateurs de plateforme ou des clés de sécurité itinérantes.
FIDO2: L'ombrelle FIDO Alliance pour WebAuthn + le CTAP (Client-To-Authenticator Protocol) utilisé entre le navigateur et un authentificateur externe.
U2F: Universal 2nd Factor — le protocole FIDO original pour les clés de sécurité de deuxième facteur. Remplacé par FIDO2 / CTAP2 mais toujours pris en charge par les YubiKeys hérités.
Server-Sent Events (SSE): Un protocole simple, basé sur le texte, de streaming unidirectionnel sur HTTP qui utilise Content-Type: text/event-stream. Fait partie du standard WHATWG HTML. Utilisé pour les notifications en direct et les réponses IA en streaming.
Socket.IO: Une bibliothèque de plus haut niveau par-dessus WebSocket (avec un repli HTTP long-polling) qui fournit des rooms, des namespaces, la reconnexion automatique et la prise en charge binaire. Protocole filaire distinct du WebSocket brut.
SignalR: La bibliothèque temps réel de Microsoft initialement pour ASP.NET. Utilise WebSocket, Server-Sent Events ou long polling comme transport, avec un RPC basé sur hub intégré et une négociation de transport automatique.
SignalR Core: Le SignalR repensé pour ASP.NET Core. Utilise un protocole filaire différent de SignalR classique — les clients doivent cibler la version de serveur correspondante.
Pusher: Un service de messagerie temps réel hébergé avec des sémantiques de canal et de présence. sgcWebSockets fournit un composant client Pusher typé.
MCP (Model Context Protocol): Un protocole ouvert introduit par Anthropic pour exposer des outils, des ressources et des prompts d'un serveur à une application hôte alimentée par un LLM. sgcWebSockets fournit à la fois un client MCP (TsgcWSAPIClient_MCP) et un serveur (TsgcWSAPIServer_MCP).
Cloud HSM: Un Hardware Security Module loué comme service cloud (par exemple AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). Les clés ne quittent jamais le HSM ; les opérations de signature sont distantes.
eIDAS: Electronic Identification, Authentication and Trust Services — le règlement de l'UE (910/2014, mis à jour par 2024/1183) qui définit les Signatures Électroniques Qualifiées (QES), les Prestataires de Services de Confiance Qualifiés et l'équivalence juridique des QES aux signatures manuscrites.
Signature de code: Appliquer une signature numérique à un exécutable, une bibliothèque ou un installateur afin que les systèmes d'exploitation et les utilisateurs puissent vérifier l'origine et l'intégrité avant de l'exécuter. Windows utilise Authenticode ; macOS utilise codesign ; Java utilise jarsigner.
Signature ClickOnce: Signature du manifeste de déploiement de Microsoft pour les applications .NET ClickOnce. Signe le manifeste d'application et le manifeste de déploiement avec un certificat Authenticode.
Signature NuGet: Ajout d'une signature PKCS#7 d'auteur ou de dépôt à un fichier .nupkg afin que les consommateurs puissent vérifier l'origine du paquet. Requis pour la liste sur nuget.org des paquets signés.
Signature VSIX: Signature d'un paquet Visual Studio Extension (.vsix) à l'aide de signatures OPC (Open Packaging Conventions) afin que la galerie Visual Studio puisse vérifier la provenance.
Windows Hello: Fonctionnalité de connexion biométrique / par code PIN de Microsoft dans Windows 10 et 11. Construite par-dessus le Windows Biometric Framework et le fournisseur d'identifiants de la plateforme.
Windows Biometric Framework: Le framework Windows en mode noyau et utilisateur qui abstrait les capteurs biométriques derrière une API commune. sgcBiometrics se construit directement sur WBF (Winbio*).
IOCP: I/O Completion Ports — la primitive Windows scalable d'E/S asynchrone. L'édition Enterprise de sgcWebSockets fournit un serveur IOCP de style Indy qui passe à l'échelle de dizaines de milliers de connexions WebSocket simultanées.
EPOLL: Le mécanisme Linux scalable de notification d'événements d'E/S. L'édition Enterprise de sgcWebSockets fournit un serveur EPOLL Linux64 qui correspond à la conception IOCP.
HTTP.SYS: L'écouteur HTTP en mode noyau de Windows (utilisé par IIS et Windows Communication Foundation). Le serveur HTTP.SYS Enterprise enregistre les préfixes URL auprès du noyau pour un débit élevé.
OpenSSL: La bibliothèque TLS/cryptographie open-source largement déployée (libssl + libcrypto). sgcWebSockets prend en charge à la fois OpenSSL 1.0.2/1.1.1 et l'OpenSSL 3.x actuel.
SChannel: Secure Channel — le fournisseur TLS/SSL Microsoft Windows intégré au système d'exploitation. sgcWebSockets prend en charge SChannel comme alternative à OpenSSL sur Windows ; aucune DLL à redistribuer.
gRPC: Un framework RPC moderne, contract-first, qui utilise Protocol Buffers sur des flux HTTP/2. Prend en charge les appels unaires, server-streaming, client-streaming et bidirectional-streaming.
Server Push: Un mécanisme HTTP/2 qui permet au serveur d'envoyer des ressources (PUSH_PROMISE) au client avant que le client ne les demande. Désormais désactivé par défaut dans les navigateurs Chromium ; sgcWebSockets le prend toujours en charge pour un usage backend à backend.
Multiplexage: Transporter plusieurs flux indépendants sur une seule connexion de transport. HTTP/2 multiplexe les flux sur une seule connexion TCP ; HTTP/3 multiplexe les flux sur une seule connexion QUIC sans blocage en tête de file au niveau de la couche transport.
Compression d'en-têtes: Réduction du coût en octets sur le fil des en-têtes HTTP répétés. HTTP/2 utilise HPACK ; HTTP/3 utilise QPACK. Les deux s'appuient sur une table dynamique par connexion des champs d'en-tête récemment utilisés.
Contrôle de flux: Le mécanisme qui empêche un émetteur de submerger un récepteur. HTTP/2 possède des fenêtres de contrôle de flux par flux et par connexion pilotées par les trames WINDOW_UPDATE.
Keep-alive: Trames de sonde périodiques envoyées pour maintenir une connexion active à travers les intermédiaires et détecter les pairs morts. WebSocket utilise les trames de contrôle PING/PONG ; MQTT utilise PINGREQ/PINGRESP à l'intervalle KeepAlive configuré.
CoAP: Constrained Application Protocol — un protocole RESTful basé sur UDP pour les appareils contraints, avec DTLS facultatif. Spécifié dans la RFC 7252.
RCON: Source Remote Console — le protocole d'administration à distance Valve / moteur Source utilisé par Counter-Strike, Garry's Mod et autres serveurs de jeu similaires. sgcWebSockets fournit un client RCON typé.

Glossaire

Besoin d'une définition ?