Glossar

Definitionen zu den Netzwerk-, Echtzeit-Protokoll-, Kryptographie- und Authentifizierungsbegriffen, die in der Dokumentation von sgcWebSockets, sgcSign und sgcBiometrics verwendet werden. Jeder Eintrag verlinkt — wo passend — auf die zugehörige RFC oder Spezifikation.

WebSocket: Ein bidirektionales Vollduplex-Messaging-Protokoll über eine einzige TCP-Verbindung. Standardisiert in RFC 6455. sgcWebSocketClient/sgcWebSocketServer nutzen es als Transport für MQTT, AMQP, STOMP, WAMP und eigene Subprotokolle.
RFC 6455: Die IETF-Spezifikation „The WebSocket Protocol“ — definiert Handshake, Framing, Kontroll-Frames und den Closing-Handshake. Siehe datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: Die zweite große HTTP-Version, entwickelt, um die Latenz durch Stream-Multiplexing, Header-Komprimierung und Server-Push zu senken. Standardisiert in RFC 9113.
RFC 9113: „HTTP/2“ — die konsolidierte Spezifikation, die RFC 7540 ablöst. Definiert Frame-Typen, Stream-Multiplexing, Flusskontrolle, Header-Komprimierung per HPACK und die Regeln zur Upgrade-Aushandlung.
HPACK: Header-Komprimierung für HTTP/2, definiert in RFC 7541. Nutzt eine statische Tabelle, eine dynamische Tabelle und Huffman-Codierung, um den Header-Overhead in jedem HTTP/2-Stream zu reduzieren.
RFC 7541: „HPACK: Header Compression for HTTP/2.“ Spezifiziert die binären Kodierungsregeln, indizierten Header-Referenzen und die Aushandlung der Größe der dynamischen Tabelle, die HTTP/2-Endpunkte verwenden.
ALPN: Application-Layer Protocol Negotiation, eine TLS-Erweiterung, definiert in RFC 7301. Erlaubt einem Client, während des TLS-Handshakes Anwendungsprotokolle anzukündigen (z. B. „h2“, „http/1.1“), damit der Server eines auswählen kann.
RFC 7301: „Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension.“ Definiert die ALPN-Erweiterung zur Aushandlung von HTTP/2 über TLS.
HTTP/3: Die dritte große HTTP-Version, die statt über TCP über QUIC läuft. Standardisiert in RFC 9114. Beseitigt Head-of-Line-Blocking und integriert TLS 1.3 in den Transport.
QUIC: Ein UDP-basiertes, gemultiplextes und sicheres Transportprotokoll, definiert in RFC 9000. Trägt HTTP/3 und bietet Connection Migration, 0-RTT und integriertes TLS 1.3.
MQTT: Message Queuing Telemetry Transport — ein schlankes Publish-Subscribe-Protokoll für ressourcenbeschränkte Geräte. Zwei Hauptversionen sind produktiv im Einsatz: 3.1.1 und 5.0.
MQTT 3.1.1: 2014 veröffentlichter OASIS-Standard. Definiert den ursprünglichen CONNECT/PUBLISH/SUBSCRIBE-Ablauf mit drei QoS-Stufen, Retained Messages und Last Will and Testament. Siehe OASIS MQTT 3.1.1.
MQTT 5.0: 2019 veröffentlichter OASIS-Standard. Ergänzt User Properties, Reason Codes, Topic Aliases, Shared Subscriptions, Session Expiry und erweiterte Authentifizierung über 3.1.1 hinaus. Siehe OASIS MQTT 5.0.
QoS (Quality of Service): MQTT-Zustellgarantie für Nachrichten. QoS 0 — höchstens einmal (Fire-and-Forget). QoS 1 — mindestens einmal (bestätigt per PUBACK). QoS 2 — genau einmal (vierstufiger Handshake: PUBLISH, PUBREC, PUBREL, PUBCOMP).
Retained message: Eine MQTT-Nachricht, die der Broker speichert und an jeden neuen Abonnenten ausliefert, dessen Topic-Filter passt. Eine Retained Message pro Topic; das Veröffentlichen einer Payload mit Länge null und gesetztem Retained-Flag löscht sie.
Last Will and Testament (LWT): Eine zum CONNECT-Zeitpunkt registrierte MQTT-Nachricht, die der Broker stellvertretend für den Client veröffentlicht, wenn die Verbindung unerwartet endet. Wird für Präsenzerkennung und Trennungsbenachrichtigungen genutzt.
Broker: Der zentrale Server in einem Publish-Subscribe-Protokoll (MQTT, AMQP, STOMP). Empfängt Nachrichten von Publishern, gleicht sie mit Abonnements ab und leitet sie an Subscriber weiter.
Topic: Eine hierarchische, durch Schrägstriche getrennte Zeichenkette, die den Kanal identifiziert, an den eine Nachricht veröffentlicht wird. Subscriber filtern auf Topic-Muster.
Wildcard topic: Ein MQTT-Topic-Filter, der + (Single-Level-Wildcard) oder # (Multi-Level-Wildcard, muss das letzte Segment sein) enthält. Beispiel: sensors/+/temperature passt auf eine Ebene; sensors/# passt auf jeden Nachkommen.
AMQP: Advanced Message Queuing Protocol — ein binäres Messaging-Protokoll auf Wire-Ebene mit zwei inkompatiblen Hauptversionen, die produktiv im Einsatz sind: 0-9-1 (RabbitMQ-Legacy) und 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: Das Wire-Protokoll, das durch RabbitMQ populär wurde. Definiert das Exchange-Queue-Binding-Modell mit den Exchange-Typen Direct, Fanout, Topic und Headers.
AMQP 1.0: Der OASIS-/ISO-Standard (ISO/IEC 19464). Definiert ein Peer-to-Peer-, linkbasiertes Transfer-Modell, das von Azure Service Bus, ActiveMQ Artemis und SwiftMQ verwendet wird.
STOMP: Simple (oder Streaming) Text Oriented Messaging Protocol — ein textbasiertes Frame-Protokoll, das in jeder Sprache implementierbar sein soll. Versionen 1.0, 1.1, 1.2. Wird von ActiveMQ und RabbitMQ genutzt.
WAMP: Web Application Messaging Protocol — kombiniert RPC- und Pub/Sub-Muster über eine einzige Verbindung, typischerweise über WebSocket. Definiert unter wamp-proto.org.
WebRTC: Web Real-Time Communications — eine browsergerechte Peer-to-Peer-Medien- und Daten-API. Nutzt ICE für die NAT-Traversierung, DTLS-SRTP für Medienverschlüsselung und SCTP-über-DTLS für Datenkanäle.
SDP: Session Description Protocol, definiert in RFC 8866. Wird in WebRTC-Offer/Answer-Austauschen verwendet, um Medienströme, Codecs und ICE-Kandidaten zu beschreiben.
ICE: Interactive Connectivity Establishment — das Framework zur NAT-Traversierung, das Kandidaten-Adresspaare (Host, Server-Reflexive, Relayed) sammelt und jedes Paar per Connectivity-Check prüft. Definiert in RFC 8445.
STUN: Session Traversal Utilities for NAT — ein Protokoll, um die öffentliche IP-Adresse und das Port-Mapping eines Hosts zu ermitteln. Spezifiziert in RFC 8489.
RFC 8489: „Session Traversal Utilities for NAT (STUN).“ Die aktuelle Revision; löst RFC 5389 ab.
TURN: Traversal Using Relays around NAT — eine STUN-Erweiterung, die Medien über einen Server weiterleitet, wenn Peer-to-Peer-Pfade scheitern. Spezifiziert in RFC 8656.
RFC 8656: „Traversal Using Relays around NAT (TURN): Relay Extensions to STUN.“ Die aktuelle Revision; löst RFC 5766 ab.
RTCPeerConnection: Die W3C-WebRTC-API-Oberfläche, die eine Verbindung zwischen zwei Peers repräsentiert. Hält lokales und entferntes SDP, ICE-Status und Medien-Tracks. sgcWebSockets liefert eine Delphi-Komponente (TsgcWebRTCPeerConnection) mit, die die Browser-API spiegelt.
DTLS: Datagram Transport Layer Security — TLS angepasst an unzuverlässige UDP-artige Transporte. Wird von WebRTC für den SRTP-Schlüsselaustausch genutzt. Aktuelle Version: DTLS 1.3.
RFC 9147: „The Datagram Transport Layer Security (DTLS) Protocol Version 1.3.“ Aktuelle DTLS-Spezifikation.
TLS 1.2: Transport Layer Security 1.2, definiert in RFC 5246. Weit verbreitet; weiterhin erforderlich für HTTP/2-Endpunkte, die noch nicht auf TLS 1.3 migriert sind.
TLS 1.3: Transport Layer Security 1.3, die aktuelle Haupt-TLS-Revision. Entfernt Legacy-Cipher-Suites, erfordert Forward Secrecy und unterstützt 0-RTT-Resumption. Spezifiziert in RFC 8446.
RFC 8446: „The Transport Layer Security (TLS) Protocol Version 1.3.“
JWT: JSON Web Token — ein kompaktes, URL-sicheres Token-Format mit signierten Claims. Definiert in RFC 7519. Wird für zustandslose Authentifizierung verwendet.
RFC 7519: „JSON Web Token (JWT).“ Spezifiziert das Claim-Set, das Header-Format und die Serialisierungsregeln.
JWS: JSON Web Signature, definiert in RFC 7515. Der Signiermechanismus, den JWTs verwenden (Header.Payload.Signature).
JWE: JSON Web Encryption, definiert in RFC 7516. Der Verschlüsselungsmechanismus zur Erzeugung verschlüsselter JWTs.
OAuth 2.0: Ein Autorisierungs-Framework, das einer Drittanwendung begrenzten Zugriff auf die Ressourcen eines Nutzers verschafft, ohne dessen Anmeldedaten zu teilen. Definiert in RFC 6749.
RFC 6749: „The OAuth 2.0 Authorization Framework.“ Definiert vier zentrale Grant-Typen, das Access-Token-/Refresh-Token-Modell und den Vertrag zwischen Authorization-Endpoint und Token-Endpoint.
PKCE: Proof Key for Code Exchange — eine OAuth 2.0-Erweiterung, die den Authorization-Code-Interception-Angriff für Public Clients abschwächt. Definiert in RFC 7636. Inzwischen für alle OAuth 2.1-Clients verpflichtend.
RFC 7636: „Proof Key for Code Exchange by OAuth Public Clients.“
OAuth Authorization Code grant: Der Browser-Redirect-OAuth-Flow, den Web- und Native-Anwendungen nutzen. Der Client erhält einen Code vom Authorization-Endpoint und tauscht ihn (serverseitig, mit PKCE) am Token-Endpoint gegen Tokens ein.
OAuth Client Credentials grant: Der Machine-to-Machine-OAuth-Flow, bei dem sich der Client mit eigenen Anmeldedaten (ohne Benutzer) authentifiziert, um ein Access-Token für Backend-Servicecalls zu erhalten.
OAuth Device Authorization grant: Der OAuth-Flow für eingabe-eingeschränkte Geräte (TVs, CLI-Tools). Definiert in RFC 8628. Das Gerät pollt den Token-Endpoint, während sich der Nutzer auf einem zweiten Gerät authentifiziert.
OAuth Resource Owner Password grant: Legacy-OAuth 2.0-Flow, bei dem der Client Benutzername und Passwort des Nutzers direkt erfasst und an den Token-Endpoint sendet. In OAuth 2.1 zugunsten von Authorization-Code + PKCE als veraltet markiert.
OAuth Refresh Token: Ein langlebiges Token, das zusammen mit einem Access-Token zurückgegeben wird. Wird am Token-Endpoint verwendet, um ein neues Access-Token zu erhalten, ohne den Nutzer erneut anzufragen.
DPoP: Demonstration of Proof-of-Possession — ein OAuth 2.0-Mechanismus, der Access-Tokens an ein clientseitig gehaltenes Schlüsselpaar bindet und so Bearer-Token-Diebstahl abschwächt. Definiert in RFC 9449.
OpenID Connect: Eine Identitätsschicht auf Basis von OAuth 2.0, die neben dem Access-Token ein signiertes ID-Token (JWT) zurückgibt — mit standardisiertem UserInfo-Endpoint und Discovery-Dokument.
WebAuthn: Die W3C-Web-Authentication-API für passwortlose Authentifizierung mit Public-Key-Credentials, gestützt auf plattformseitige Authenticators oder mobile Security Keys.
FIDO2: Das FIDO-Alliance-Dachprojekt für WebAuthn + das CTAP (Client-To-Authenticator Protocol), das zwischen Browser und externem Authenticator verwendet wird.
U2F: Universal 2nd Factor — das ursprüngliche FIDO-Protokoll für Second-Factor-Security-Keys. Durch FIDO2 / CTAP2 abgelöst, von älteren YubiKeys aber weiterhin unterstützt.
Server-Sent Events (SSE): Ein einfaches, textbasiertes, unidirektionales Streaming-Protokoll über HTTP mit Content-Type: text/event-stream. Teil des WHATWG-HTML-Standards. Wird für Live-Benachrichtigungen und KI-Streaming-Antworten genutzt.
Socket.IO: Eine höhere Bibliothek auf WebSocket-Basis (mit HTTP-Long-Polling-Fallback), die Rooms, Namespaces, automatischen Reconnect und Binärunterstützung bietet. Eigenes Wire-Protokoll, unabhängig vom reinen WebSocket.
SignalR: Microsofts Echtzeit-Bibliothek, ursprünglich für ASP.NET. Nutzt WebSocket, Server-Sent Events oder Long Polling als Transport, mit eingebautem Hub-basiertem RPC und automatischer Transport-Aushandlung.
SignalR Core: Das neu entwickelte SignalR für ASP.NET Core. Verwendet ein anderes Wire-Protokoll als das klassische SignalR — Clients müssen die passende Server-Version ansteuern.
Pusher: Ein gehosteter Echtzeit-Messaging-Dienst mit Channel- und Presence-Semantik. sgcWebSockets liefert eine typisierte Pusher-Client-Komponente mit.
MCP (Model Context Protocol): Ein offenes Protokoll, eingeführt von Anthropic, um Tools, Ressourcen und Prompts von einem Server an eine LLM-gestützte Host-Anwendung bereitzustellen. sgcWebSockets liefert sowohl einen MCP-Client (TsgcWSAPIClient_MCP) als auch einen MCP-Server (TsgcWSAPIServer_MCP) mit.
Cloud HSM: Ein Hardware Security Module, gemietet als Cloud-Dienst (z. B. AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). Schlüssel verlassen das HSM nie; Signieroperationen erfolgen remote.
eIDAS: Electronic Identification, Authentication and Trust Services — die EU-Verordnung (910/2014, aktualisiert durch 2024/1183), die qualifizierte elektronische Signaturen (QES), qualifizierte Vertrauensdiensteanbieter und die rechtliche Gleichstellung der QES mit handschriftlichen Unterschriften definiert.
Code signing: Das Anbringen einer digitalen Signatur an einer ausführbaren Datei, Bibliothek oder einem Installer, damit Betriebssysteme und Nutzer Herkunft und Integrität vor dem Ausführen prüfen können. Windows nutzt Authenticode; macOS nutzt codesign; Java nutzt jarsigner.
ClickOnce signing: Microsofts Signierung von Deployment-Manifesten für ClickOnce-.NET-Anwendungen. Signiert das Anwendungs- und das Deployment-Manifest mit einem Authenticode-Zertifikat.
NuGet signing: Das Hinzufügen einer PKCS#7-Autoren- oder Repository-Signatur zu einer .nupkg-Datei, damit Nutzer die Herkunft des Pakets prüfen können. Erforderlich für das Listing signierter Pakete auf nuget.org.
VSIX signing: Das Signieren eines Visual Studio Extension-Pakets (.vsix) mit OPC-Signaturen (Open Packaging Conventions), damit der Visual Studio-Gallery die Herkunft überprüfen kann.
Windows Hello: Microsofts biometrische/PIN-Anmeldefunktion in Windows 10 und 11. Baut auf dem Windows Biometric Framework und dem plattformseitigen Credential Provider auf.
Windows Biometric Framework: Das Windows-Framework im Kernel- und User-Mode, das biometrische Sensoren hinter einer gemeinsamen API abstrahiert. sgcBiometrics baut direkt auf WBF (Winbio*) auf.
IOCP: I/O Completion Ports — das skalierbare Async-I/O-Primitiv von Windows. Die sgcWebSockets Enterprise-Edition liefert einen IOCP-Server im Indy-Stil mit, der auf zehntausende gleichzeitiger WebSocket-Verbindungen skaliert.
EPOLL: Die skalierbare I/O-Ereignisbenachrichtigung unter Linux. Die sgcWebSockets Enterprise-Edition liefert einen EPOLL-Linux64-Server mit, der dem IOCP-Design entspricht.
HTTP.SYS: Der HTTP-Listener im Windows-Kernelmodus (genutzt von IIS und Windows Communication Foundation). Der Enterprise HTTP.SYS-Server registriert URL-Präfixe im Kernel für hohen Durchsatz.
OpenSSL: Die weit verbreitete Open-Source-TLS-/Kryptographie-Bibliothek (libssl + libcrypto). sgcWebSockets unterstützt sowohl OpenSSL 1.0.2/1.1.1 als auch das aktuelle OpenSSL 3.x.
SChannel: Secure Channel — der ins Betriebssystem integrierte TLS/SSL-Provider von Microsoft Windows. sgcWebSockets unterstützt SChannel als Alternative zu OpenSSL unter Windows — ohne DLLs, die mitverteilt werden müssen.
gRPC: Ein modernes, Contract-First-RPC-Framework, das Protocol Buffers über HTTP/2-Streams nutzt. Unterstützt Unary-, Server-Streaming-, Client-Streaming- und Bidirectional-Streaming-Aufrufe.
Server Push: Ein HTTP/2-Mechanismus, mit dem der Server Ressourcen (PUSH_PROMISE) an den Client sendet, bevor dieser sie anfragt. In Chromium-basierten Browsern inzwischen standardmäßig deaktiviert; sgcWebSockets unterstützt ihn weiterhin für Backend-zu-Backend-Anwendungen.
Multiplexing: Mehrere unabhängige Streams über eine einzige Transportverbindung führen. HTTP/2 multiplext Streams über eine TCP-Verbindung; HTTP/3 multiplext Streams über eine QUIC-Verbindung — ohne Head-of-Line-Blocking auf der Transportschicht.
Header compression: Reduktion des Bytes-on-Wire-Aufwands für wiederholte HTTP-Header. HTTP/2 nutzt HPACK; HTTP/3 nutzt QPACK. Beide beruhen auf einer pro Verbindung geführten dynamischen Tabelle kürzlich verwendeter Header-Felder.
Flow control: Der Mechanismus, der verhindert, dass ein Sender einen Empfänger überlastet. HTTP/2 hat Flusskontroll-Fenster pro Stream und pro Verbindung, gesteuert über WINDOW_UPDATE-Frames.
Keep-alive: Regelmäßig gesendete Probe-Frames, um eine Verbindung über Vermittlungsstellen hinweg am Leben zu halten und tote Peers zu erkennen. WebSocket nutzt PING/PONG-Kontroll-Frames; MQTT nutzt PINGREQ/PINGRESP im konfigurierten KeepAlive-Intervall.
CoAP: Constrained Application Protocol — ein RESTful, UDP-basiertes Protokoll für ressourcenbeschränkte Geräte, mit optionalem DTLS. Spezifiziert in RFC 7252.
RCON: Source Remote Console — das Remote-Administrationsprotokoll der Valve-/Source-Engine, genutzt von Counter-Strike, Garry’s Mod und ähnlichen Game-Servern. sgcWebSockets liefert einen typisierten RCON-Client mit.

Glossar

Fehlt dir ein Begriff?