Słownik

Definicje terminów sieciowych, protokołów czasu rzeczywistego, kryptografii i uwierzytelniania używanych w dokumentacji sgcWebSockets, sgcSign i sgcBiometrics. Każde hasło zawiera odnośnik do odpowiedniego RFC lub specyfikacji, jeśli jest dostępna.

WebSocket: Dwukierunkowy, pełnodupleksowy protokół wymiany wiadomości działający na jednym połączeniu TCP. Ustandaryzowany w RFC 6455. Wykorzystywany przez sgcWebSocketClient / sgcWebSocketServer jako transport dla MQTT, AMQP, STOMP, WAMP i własnych podprotokołów.
RFC 6455: Specyfikacja IETF „The WebSocket Protocol” — definiuje handshake, ramkowanie, ramki kontrolne i procedurę zamknięcia. Zobacz datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: Druga główna wersja HTTP, zaprojektowana w celu zmniejszenia opóźnień poprzez multipleksowanie strumieni, kompresję nagłówków i server push. Ustandaryzowana w RFC 9113.
RFC 9113: „HTTP/2” — skonsolidowana specyfikacja zastępująca RFC 7540. Definiuje typy ramek, multipleksowanie strumieni, kontrolę przepływu, kompresję nagłówków przez HPACK oraz reguły negocjacji upgrade.
HPACK: Kompresja nagłówków dla HTTP/2, zdefiniowana w RFC 7541. Używa tablicy statycznej, dynamicznej oraz kodowania Huffmana, aby zmniejszyć narzut nagłówków w każdym strumieniu HTTP/2.
RFC 7541: „HPACK: Header Compression for HTTP/2”. Określa zasady kodowania binarnego, odniesienia do indeksowanych nagłówków oraz negocjację rozmiaru tablicy dynamicznej używaną przez punkty końcowe HTTP/2.
ALPN: Application-Layer Protocol Negotiation, rozszerzenie TLS zdefiniowane w RFC 7301. Pozwala klientowi zareklamować protokoły aplikacyjne (np. „h2”, „http/1.1”) podczas handshake TLS, aby serwer mógł wybrać jeden z nich.
RFC 7301: „Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”. Definiuje rozszerzenie ALPN używane do negocjacji HTTP/2 przez TLS.
HTTP/3: Trzecia główna wersja HTTP, działająca na QUIC zamiast TCP. Ustandaryzowana w RFC 9114. Eliminuje blokadę head-of-line i integruje TLS 1.3 w warstwie transportowej.
QUIC: Multipleksowany, bezpieczny protokół transportowy oparty na UDP, zdefiniowany w RFC 9000. Przenosi HTTP/3 i oferuje migrację połączeń, 0-RTT oraz zintegrowane TLS 1.3.
MQTT: Message Queuing Telemetry Transport — lekki protokół publikacja-subskrypcja dla urządzeń o ograniczonych zasobach. W produkcji używane są dwie główne wersje: 3.1.1 i 5.0.
MQTT 3.1.1: Standard OASIS opublikowany w 2014 roku. Definiuje oryginalny przepływ CONNECT/PUBLISH/SUBSCRIBE z trzema poziomami QoS, wiadomościami retained oraz Last Will and Testament. Zobacz OASIS MQTT 3.1.1.
MQTT 5.0: Standard OASIS opublikowany w 2019 roku. Dodaje właściwości użytkownika, kody powodu, aliasy tematów, subskrypcje współdzielone, wygasanie sesji oraz rozszerzone uwierzytelnianie ponad 3.1.1. Zobacz OASIS MQTT 5.0.
QoS (jakość usługi): Gwarancja dostarczenia wiadomości MQTT. QoS 0 — co najwyżej raz (fire-and-forget). QoS 1 — co najmniej raz (potwierdzane przez PUBACK). QoS 2 — dokładnie raz (czteroetapowy handshake: PUBLISH, PUBREC, PUBREL, PUBCOMP).
Wiadomość retained: Wiadomość MQTT przechowywana przez brokera i dostarczana każdemu nowemu subskrybentowi, którego filtr tematu pasuje. Jedna wiadomość retained na temat; opublikowanie pustego ładunku z flagą retained usuwa ją.
Last Will and Testament (LWT): Wiadomość MQTT zarejestrowana w czasie CONNECT, którą broker publikuje w imieniu klienta, jeśli połączenie zostanie zamknięte nieprawidłowo. Wykorzystywana do wykrywania obecności i powiadamiania o rozłączeniu.
Broker: Centralny serwer w protokole publikacja-subskrypcja (MQTT, AMQP, STOMP). Odbiera wiadomości od wydawców, dopasowuje je do subskrypcji i przekazuje subskrybentom.
Temat (topic): Hierarchiczny ciąg znaków rozdzielany ukośnikami, identyfikujący kanał, na którym publikowana jest wiadomość. Subskrybenci filtrują według wzorców tematów.
Temat z wildcardami: Filtr tematu MQTT zawierający + (wildcard jednopoziomowy) lub # (wildcard wielopoziomowy, musi być ostatnim segmentem). Przykład: sensors/+/temperature dopasowuje jeden poziom; sensors/# dopasowuje wszystkich potomków.
AMQP: Advanced Message Queuing Protocol — binarny protokół wymiany wiadomości na poziomie wire, z dwiema niekompatybilnymi wersjami głównymi używanymi w produkcji: 0-9-1 (legacy RabbitMQ) i 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: Protokół wire spopularyzowany przez RabbitMQ. Definiuje model exchange-queue-binding z typami exchange: direct, fanout, topic i headers.
AMQP 1.0: Standard OASIS / ISO (ISO/IEC 19464). Definiuje peer-to-peer model przesyłania oparty na linkach, używany przez Azure Service Bus, ActiveMQ Artemis i SwiftMQ.
STOMP: Simple (lub Streaming) Text Oriented Messaging Protocol — tekstowy protokół ramkowy zaprojektowany tak, aby można go było zaimplementować w każdym języku. Wersje 1.0, 1.1, 1.2. Używany przez ActiveMQ i RabbitMQ.
WAMP: Web Application Messaging Protocol — łączy wzorce RPC i Pub/Sub w jednym połączeniu, zwykle przez WebSocket. Zdefiniowany na wamp-proto.org.
WebRTC: Web Real-Time Communications — przeglądarkowe API peer-to-peer dla mediów i danych. Wykorzystuje ICE do przechodzenia przez NAT, DTLS-SRTP do szyfrowania mediów oraz SCTP-over-DTLS dla kanałów danych.
SDP: Session Description Protocol, zdefiniowany w RFC 8866. Używany wewnątrz wymiany offer/answer WebRTC do opisu strumieni mediów, kodeków i kandydatów ICE.
ICE: Interactive Connectivity Establishment — framework do przechodzenia przez NAT, który zbiera pary adresów kandydatów (host, server-reflexive, relayed) i sprawdza łączność każdej pary. Zdefiniowany w RFC 8445.
STUN: Session Traversal Utilities for NAT — protokół do wykrywania publicznego adresu IP i mapowania portów hosta. Określony w RFC 8489.
RFC 8489: „Session Traversal Utilities for NAT (STUN)”. Bieżąca wersja; zastępuje RFC 5389.
TURN: Traversal Using Relays around NAT — rozszerzenie STUN, które przekazuje media przez serwer, gdy ścieżki peer-to-peer zawodzą. Określone w RFC 8656.
RFC 8656: „Traversal Using Relays around NAT (TURN): Relay Extensions to STUN”. Bieżąca wersja; zastępuje RFC 5766.
RTCPeerConnection: Powierzchnia API W3C WebRTC reprezentująca połączenie między dwoma peerami. Przechowuje lokalne i zdalne SDP, stan ICE oraz ścieżki mediów. sgcWebSockets dostarcza komponent Delphi (TsgcWebRTCPeerConnection), który odzwierciedla API przeglądarki.
DTLS: Datagram Transport Layer Security — TLS dostosowane do nieniezawodnych transportów typu UDP. Używane przez WebRTC do wymiany kluczy SRTP. Aktualna wersja: DTLS 1.3.
RFC 9147: „The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”. Najnowsza specyfikacja DTLS.
TLS 1.2: Transport Layer Security 1.2, zdefiniowany w RFC 5246. Szeroko stosowany; nadal wymagany przez punkty końcowe HTTP/2, które nie zmigrowały do TLS 1.3.
TLS 1.3: Transport Layer Security 1.3, bieżąca główna rewizja TLS. Usuwa przestarzałe zestawy szyfrów, wymaga forward secrecy i wspiera wznawianie 0-RTT. Określony w RFC 8446.
RFC 8446: „The Transport Layer Security (TLS) Protocol Version 1.3”.
JWT: JSON Web Token — kompaktowy, bezpieczny dla URL format tokena niosący podpisane oświadczenia. Zdefiniowany w RFC 7519. Używany do bezstanowego uwierzytelniania.
RFC 7519: „JSON Web Token (JWT)”. Określa zestaw oświadczeń, format nagłówka i zasady serializacji.
JWS: JSON Web Signature, zdefiniowany w RFC 7515. Mechanizm podpisywania używany przez JWT (header.payload.signature).
JWE: JSON Web Encryption, zdefiniowany w RFC 7516. Mechanizm szyfrowania używany do tworzenia szyfrowanych JWT.
OAuth 2.0: Framework autoryzacji, który pozwala aplikacji trzeciej uzyskać ograniczony dostęp do zasobów użytkownika bez udostępniania jego danych logowania. Zdefiniowany w RFC 6749.
RFC 6749: „The OAuth 2.0 Authorization Framework”. Definiuje cztery podstawowe typy uprawnień (grant), model access token / refresh token oraz kontrakt authorization endpoint / token endpoint.
PKCE: Proof Key for Code Exchange — rozszerzenie OAuth 2.0 ograniczające atak przechwycenia kodu autoryzacyjnego dla klientów publicznych. Zdefiniowane w RFC 7636. Obecnie wymagane dla wszystkich klientów OAuth 2.1.
RFC 7636: „Proof Key for Code Exchange by OAuth Public Clients”.
OAuth grant Authorization Code: Przepływ OAuth z przekierowaniem przeglądarki, używany przez aplikacje webowe i natywne. Klient otrzymuje kod z authorization endpoint i wymienia go (po stronie serwera, z PKCE) na tokeny w token endpoint.
OAuth grant Client Credentials: Przepływ OAuth maszyna-maszyna, w którym klient uwierzytelnia się własnymi danymi (bez użytkownika), aby uzyskać access token dla wywołań usług backendu.
OAuth grant Device Authorization: Przepływ OAuth dla urządzeń o ograniczonych możliwościach wprowadzania (telewizory, narzędzia CLI). Zdefiniowany w RFC 8628. Urządzenie odpytuje token endpoint, podczas gdy użytkownik uwierzytelnia się na drugim urządzeniu.
OAuth grant Resource Owner Password: Przestarzały przepływ OAuth 2.0, w którym klient bezpośrednio zbiera nazwę użytkownika i hasło i wysyła je do token endpoint. Wycofany w OAuth 2.1 na rzecz authorization-code + PKCE.
OAuth Refresh Token: Długoterminowy token zwracany wraz z access token. Używany w token endpoint do uzyskania nowego access token bez ponownego pytania użytkownika.
DPoP: Demonstration of Proof-of-Possession — mechanizm OAuth 2.0, który wiąże access tokeny z parą kluczy przechowywaną przez klienta, ograniczając kradzież bearer-tokenów. Zdefiniowany w RFC 9449.
OpenID Connect: Warstwa tożsamości zbudowana na OAuth 2.0, która zwraca podpisany ID Token (JWT) wraz z access token, z ustandaryzowanym endpointem UserInfo i dokumentem discovery.
WebAuthn: API W3C Web Authentication do uwierzytelniania bezhasłowego z wykorzystaniem poświadczeń klucza publicznego wspieranych przez autentykatory platformy lub roamingowe klucze bezpieczeństwa.
FIDO2: Zbiorcza nazwa FIDO Alliance dla WebAuthn + CTAP (Client-To-Authenticator Protocol) używanego między przeglądarką a zewnętrznym autentykatorem.
U2F: Universal 2nd Factor — oryginalny protokół FIDO dla kluczy bezpieczeństwa drugiego składnika. Zastąpiony przez FIDO2 / CTAP2, ale nadal wspierany przez starsze YubiKey.
Server-Sent Events (SSE): Prosty, tekstowy, jednokierunkowy protokół strumieniowy przez HTTP używający Content-Type: text/event-stream. Część standardu WHATWG HTML. Używany do powiadomień na żywo i strumieniowych odpowiedzi AI.
Socket.IO: Biblioteka wyższego poziomu na WebSocket (z fallbackiem na HTTP long-polling), która zapewnia pokoje, przestrzenie nazw, automatyczne ponowne łączenie i obsługę danych binarnych. Odrębny protokół wire od surowego WebSocket.
SignalR: Biblioteka czasu rzeczywistego Microsoftu, początkowo dla ASP.NET. Wykorzystuje WebSocket, Server-Sent Events lub long polling jako transport, z wbudowanym RPC opartym na hubach i automatyczną negocjacją transportu.
SignalR Core: Przeprojektowany SignalR dla ASP.NET Core. Wykorzystuje inny protokół wire niż klasyczny SignalR — klienci muszą być zgodni z wersją serwera.
Pusher: Hostowana usługa wiadomości w czasie rzeczywistym z semantyką kanałów i obecności. sgcWebSockets dostarcza typowany komponent klienta Pusher.
MCP (Model Context Protocol): Otwarty protokół wprowadzony przez Anthropic do udostępniania narzędzi, zasobów i promptów z serwera do aplikacji hosta zasilanej LLM. sgcWebSockets dostarcza zarówno klienta MCP (TsgcWSAPIClient_MCP), jak i serwer (TsgcWSAPIServer_MCP).
Cloud HSM: Hardware Security Module wynajmowany jako usługa w chmurze (np. AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). Klucze nigdy nie opuszczają HSM; operacje podpisywania są zdalne.
eIDAS: Electronic Identification, Authentication and Trust Services — rozporządzenie UE (910/2014, zaktualizowane przez 2024/1183) definiujące Kwalifikowane Podpisy Elektroniczne (QES), Kwalifikowanych Dostawców Usług Zaufania oraz prawną równoważność QES z podpisami odręcznymi.
Podpisywanie kodu: Nakładanie cyfrowego podpisu na plik wykonywalny, bibliotekę lub instalator, aby systemy operacyjne i użytkownicy mogli zweryfikować pochodzenie i integralność przed uruchomieniem. Windows używa Authenticode; macOS używa codesign; Java używa jarsigner.
Podpisywanie ClickOnce: Microsoftowe podpisywanie manifestów wdrożeniowych dla aplikacji ClickOnce .NET. Podpisuje manifest aplikacji i manifest wdrożeniowy certyfikatem Authenticode.
Podpisywanie NuGet: Dodanie podpisu autora lub repozytorium PKCS#7 do pliku .nupkg, aby konsumenci mogli zweryfikować pochodzenie pakietu. Wymagane do publikacji podpisanych pakietów w nuget.org.
Podpisywanie VSIX: Podpisywanie pakietu rozszerzenia Visual Studio (.vsix) przy użyciu podpisów OPC (Open Packaging Conventions), aby galeria Visual Studio mogła zweryfikować pochodzenie.
Windows Hello: Funkcja logowania biometrycznego / PIN w Windows 10 i 11. Zbudowana na Windows Biometric Framework i dostawcy poświadczeń platformy.
Windows Biometric Framework: Framework Windows w trybie jądra i użytkownika, który abstrahuje sensory biometryczne za wspólnym API. sgcBiometrics opiera się bezpośrednio na WBF (Winbio*).
IOCP: I/O Completion Ports — skalowalny prymityw async-I/O Windows. Edycja sgcWebSockets Enterprise dostarcza serwer IOCP w stylu Indy, który skaluje się do dziesiątek tysięcy równoczesnych połączeń WebSocket.
EPOLL: Skalowalny mechanizm powiadamiania o zdarzeniach I/O w Linuksie. Edycja sgcWebSockets Enterprise dostarcza serwer EPOLL Linux64 o tej samej konstrukcji co IOCP.
HTTP.SYS: Słuchacz HTTP w trybie jądra Windows (używany przez IIS i Windows Communication Foundation). Enterprise HTTP.SYS server rejestruje prefiksy URL w jądrze dla wysokiej przepustowości.
OpenSSL: Szeroko stosowana otwarta biblioteka TLS/kryptografii (libssl + libcrypto). sgcWebSockets obsługuje zarówno OpenSSL 1.0.2/1.1.1, jak i bieżący OpenSSL 3.x.
SChannel: Secure Channel — dostawca TLS/SSL Microsoft Windows zintegrowany z systemem. sgcWebSockets obsługuje SChannel jako alternatywę dla OpenSSL na Windows; bez bibliotek DLL do redystrybucji.
gRPC: Nowoczesny framework RPC oparty na kontrakcie, używający Protocol Buffers przez strumienie HTTP/2. Obsługuje wywołania unarne, strumieniowe po stronie serwera, strumieniowe po stronie klienta i dwukierunkowo strumieniowe.
Server Push: Mechanizm HTTP/2 pozwalający serwerowi wysłać zasoby (PUSH_PROMISE) do klienta zanim klient ich zażąda. Obecnie domyślnie wyłączony w przeglądarkach opartych na Chromium; sgcWebSockets nadal go obsługuje dla zastosowań backend-to-backend.
Multipleksowanie: Przenoszenie wielu niezależnych strumieni jednym połączeniem transportowym. HTTP/2 multipleksuje strumienie przez jedno połączenie TCP; HTTP/3 multipleksuje strumienie przez jedno połączenie QUIC bez blokady head-of-line w warstwie transportowej.
Kompresja nagłówków: Zmniejszanie kosztu bajtów na wire powtarzających się nagłówków HTTP. HTTP/2 używa HPACK; HTTP/3 używa QPACK. Oba opierają się na dynamicznej tablicy ostatnio używanych pól nagłówka per połączenie.
Kontrola przepływu: Mechanizm zapobiegający przeciążeniu odbiorcy przez nadawcę. HTTP/2 ma okna kontroli przepływu per strumień i per połączenie sterowane ramkami WINDOW_UPDATE.
Keep-alive: Okresowe ramki sondujące wysyłane w celu utrzymania połączenia przez pośredników i wykrycia martwych peerów. WebSocket używa ramek kontrolnych PING/PONG; MQTT używa PINGREQ/PINGRESP w skonfigurowanym interwale KeepAlive.
CoAP: Constrained Application Protocol — RESTful protokół oparty na UDP dla urządzeń o ograniczonych zasobach, z opcjonalnym DTLS. Określony w RFC 7252.
RCON: Source Remote Console — protokół zdalnej administracji Valve / Source-engine używany przez Counter-Strike, Garry's Mod i podobne serwery gier. sgcWebSockets dostarcza typowanego klienta RCON.

Słownik

Brakuje definicji terminu?