用語集

sgcWebSockets、sgcSign、sgcBiometrics の各ドキュメントで使用されているネットワーク、リアルタイムプロトコル、暗号化、認証関連の用語の定義集です。各エントリは、該当する RFC または仕様へのリンクを備えています。

WebSocket: 単一の TCP 接続上で動作する、双方向・全二重のメッセージングプロトコル。RFC 6455 として標準化されています。sgcWebSocketClient / sgcWebSocketServer において、MQTT、AMQP、STOMP、WAMP、およびカスタムサブプロトコルのトランスポートとして利用されます。
RFC 6455: IETF 仕様「The WebSocket Protocol」 — ハンドシェイク、フレーミング、制御フレーム、クローズハンドシェイクを定義します。datatracker.ietf.org/doc/html/rfc6455 をご参照ください。
HTTP/2: HTTP の 2 つ目のメジャーバージョン。ストリーム多重化、ヘッダー圧縮、サーバープッシュにより遅延を削減することを目的としています。RFC 9113 として標準化されています。
RFC 9113: 「HTTP/2」 — RFC 7540 に置き換わる統合仕様。フレーム種別、ストリーム多重化、フロー制御、HPACK によるヘッダー圧縮、アップグレード交渉ルールを定義します。
HPACK: HTTP/2 用のヘッダー圧縮。RFC 7541 として定義されています。静的テーブル、動的テーブル、ハフマン符号化を使用して、各 HTTP/2 ストリームのヘッダーオーバーヘッドを削減します。
RFC 7541: 「HPACK: Header Compression for HTTP/2」。HTTP/2 エンドポイントで使用される、バイナリ符号化規則、インデックス付きヘッダー参照、動的テーブルサイズ交渉について規定します。
ALPN: Application-Layer Protocol Negotiation。RFC 7301 として定義された TLS 拡張です。TLS ハンドシェイク中にクライアントがアプリケーションプロトコル (例: 「h2」「http/1.1」) を提示し、サーバーが選択できるようにします。
RFC 7301: 「Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension」。TLS 上で HTTP/2 を交渉するために使用される ALPN 拡張を定義します。
HTTP/3: HTTP の 3 つ目のメジャーバージョン。TCP の代わりに QUIC 上で動作します。RFC 9114 として標準化されています。ヘッドオブラインブロッキングを解消し、TLS 1.3 をトランスポートに統合しています。
QUIC: RFC 9000 で定義された、UDP ベースで多重化されたセキュアなトランスポートプロトコル。HTTP/3 を伝送し、接続マイグレーション、0-RTT、TLS 1.3 統合を提供します。
MQTT: Message Queuing Telemetry Transport — 制約のあるデバイス向けの軽量なパブリッシュ・サブスクライブ型プロトコル。実用化されているメジャーバージョンは 3.1.1 と 5.0 の 2 つです。
MQTT 3.1.1: 2014 年に公開された OASIS 標準。3 つの QoS レベル、保持メッセージ、Last Will and Testament を備えた、CONNECT/PUBLISH/SUBSCRIBE フローを定義します。OASIS MQTT 3.1.1 をご参照ください。
MQTT 5.0: 2019 年に公開された OASIS 標準。3.1.1 に対して、ユーザープロパティ、リーズンコード、トピックエイリアス、共有サブスクリプション、セッション有効期限、拡張認証を追加します。OASIS MQTT 5.0 をご参照ください。
QoS (Quality of Service): MQTT のメッセージ配信保証。QoS 0 — 最大 1 回 (fire-and-forget)。QoS 1 — 少なくとも 1 回 (PUBACK で確認応答)。QoS 2 — 確実に 1 回 (PUBLISH、PUBREC、PUBREL、PUBCOMP の 4 ステップハンドシェイク)。
保持メッセージ: ブローカーが保存し、トピックフィルタが一致する新規サブスクライバーすべてに配信される MQTT メッセージ。1 トピックにつき 1 件の保持メッセージが保持されます。長さ 0 のペイロードを retained フラグ付きで発行するとクリアされます。
Last Will and Testament (LWT): CONNECT 時に登録される MQTT メッセージで、接続が異常終了した場合にブローカーがクライアントに代わって発行します。プレゼンス検出や切断通知に利用されます。
ブローカー: パブリッシュ・サブスクライブ型プロトコル (MQTT、AMQP、STOMP) における中央サーバー。パブリッシャーからメッセージを受信し、サブスクリプションと照合してサブスクライバーに転送します。
トピック: スラッシュ区切りの階層的な文字列で、メッセージが発行されるチャネルを識別します。サブスクライバーはトピックパターンでフィルタリングを行います。
ワイルドカードトピック: + (1 階層ワイルドカード) または # (複数階層ワイルドカード、最終セグメントに限る) を含む MQTT トピックフィルタ。例: sensors/+/temperature は 1 階層のみに一致し、sensors/# はすべての配下に一致します。
AMQP: Advanced Message Queuing Protocol — バイナリ・ワイヤレベルのメッセージングプロトコル。実用化されている、互換性のないメジャーバージョンが 2 つあります: 0-9-1 (RabbitMQ レガシー) と 1.0 (OASIS / ISO/IEC 19464)。
AMQP 0-9-1: RabbitMQ によって広まったワイヤプロトコル。direct、fanout、topic、headers の各エクスチェンジタイプを持つ、エクスチェンジ・キュー・バインディングモデルを定義します。
AMQP 1.0: OASIS / ISO 標準 (ISO/IEC 19464)。Azure Service Bus、ActiveMQ Artemis、SwiftMQ で使用される、ピアツーピアのリンクベース転送モデルを定義します。
STOMP: Simple (または Streaming) Text Oriented Messaging Protocol — あらゆる言語で実装可能なように設計されたテキストベースのフレームプロトコル。バージョンは 1.0、1.1、1.2 があります。ActiveMQ と RabbitMQ で利用されています。
WAMP: Web Application Messaging Protocol — 通常 WebSocket 上で動作する単一接続で、RPC と Pub/Sub パターンを統合します。wamp-proto.org で定義されています。
WebRTC: Web Real-Time Communications — ブラウザ品質のピアツーピアメディア・データ API。NAT 越えに ICE、メディア暗号化に DTLS-SRTP、データチャネルに SCTP-over-DTLS を使用します。
SDP: Session Description Protocol。RFC 8866 として定義されています。WebRTC のオファー/アンサー交換内で、メディアストリーム、コーデック、ICE 候補を記述するために使用されます。
ICE: Interactive Connectivity Establishment — 候補アドレスペア (ホスト、サーバーリフレキシブ、リレー) を収集し、各ペアの接続性チェックを行う NAT 越えフレームワーク。RFC 8445 として定義されています。
STUN: Session Traversal Utilities for NAT — ホストの外部向け IP およびポートマッピングを発見するためのプロトコル。RFC 8489 として規定されています。
RFC 8489: 「Session Traversal Utilities for NAT (STUN)」。現行リビジョンで、RFC 5389 を廃止します。
TURN: Traversal Using Relays around NAT — ピアツーピア経路が確立できない場合にサーバー経由でメディアを中継する STUN 拡張。RFC 8656 として規定されています。
RFC 8656: 「Traversal Using Relays around NAT (TURN): Relay Extensions to STUN」。現行リビジョンで、RFC 5766 を廃止します。
RTCPeerConnection: 2 つのピア間の接続を表す W3C WebRTC API。ローカルおよびリモートの SDP、ICE 状態、メディアトラックを保持します。sgcWebSockets には、ブラウザ API をミラーリングした Delphi コンポーネント (TsgcWebRTCPeerConnection) が含まれます。
DTLS: Datagram Transport Layer Security — UDP 型の信頼性のないトランスポートに対応した TLS。WebRTC が SRTP の鍵交換に使用します。現行バージョンは DTLS 1.3 です。
RFC 9147: 「The Datagram Transport Layer Security (DTLS) Protocol Version 1.3」。最新の DTLS 仕様です。
TLS 1.2: Transport Layer Security 1.2。RFC 5246 として定義されています。広く展開されており、TLS 1.3 に移行していない HTTP/2 エンドポイントでは引き続き必要です。
TLS 1.3: Transport Layer Security 1.3、現行の TLS メジャーリビジョン。レガシー暗号スイートを排除し、前方秘匿性を必須とし、0-RTT 再開をサポートします。RFC 8446 として規定されています。
RFC 8446: 「The Transport Layer Security (TLS) Protocol Version 1.3」。
JWT: JSON Web Token — 署名付きクレームを保持する、コンパクトで URL セーフなトークン形式。RFC 7519 として定義されています。ステートレスな認証に用いられます。
RFC 7519: 「JSON Web Token (JWT)」。クレームセット、ヘッダー形式、シリアル化規則を規定します。
JWS: JSON Web Signature。RFC 7515 として定義されています。JWT で使用される署名メカニズムです (header.payload.signature)。
JWE: JSON Web Encryption。RFC 7516 として定義されています。暗号化された JWT の生成に使用される暗号化メカニズムです。
OAuth 2.0: サードパーティアプリケーションが、ユーザーの資格情報を共有することなく、ユーザーのリソースへの限定的なアクセスを取得できるようにする認可フレームワーク。RFC 6749 として定義されています。
RFC 6749: 「The OAuth 2.0 Authorization Framework」。4 つのコアグラントタイプ、アクセストークン / リフレッシュトークンモデル、認可エンドポイント / トークンエンドポイントの契約を定義します。
PKCE: Proof Key for Code Exchange — パブリッククライアントにおける認可コード傍受攻撃を緩和する OAuth 2.0 拡張。RFC 7636 として定義されています。OAuth 2.1 のすべてのクライアントで必須です。
RFC 7636: 「Proof Key for Code Exchange by OAuth Public Clients」。
OAuth Authorization Code グラント: Web およびネイティブアプリケーションで使用されるブラウザリダイレクト型 OAuth フロー。クライアントは認可エンドポイントからコードを受け取り、それをトークンエンドポイントで (サーバー側、PKCE を併用して) トークンと交換します。
OAuth Client Credentials グラント: クライアントが自身の資格情報 (ユーザーなし) で認証し、バックエンドサービス呼び出し用のアクセストークンを取得する、マシンツーマシン型の OAuth フロー。
OAuth Device Authorization グラント: 入力に制約のあるデバイス (TV、CLI ツール) 向けの OAuth フロー。RFC 8628 として定義されています。ユーザーが別のデバイスで認証する間、デバイスはトークンエンドポイントをポーリングします。
OAuth Resource Owner Password グラント: クライアントがユーザー名とパスワードを直接収集し、トークンエンドポイントに送信するレガシー OAuth 2.0 フロー。OAuth 2.1 では、認可コード + PKCE が推奨され、本フローは非推奨となりました。
OAuth Refresh トークン: アクセストークンと併せて返される長寿命のトークン。トークンエンドポイントで利用し、ユーザーに再度入力を求めることなく新しいアクセストークンを取得します。
DPoP: Demonstration of Proof-of-Possession — アクセストークンをクライアントが保持する鍵ペアに紐付け、ベアラートークン窃取を緩和する OAuth 2.0 メカニズム。RFC 9449 として定義されています。
OpenID Connect: OAuth 2.0 上に構築された ID レイヤー。アクセストークンと併せて署名付き ID トークン (JWT) を返し、標準化された UserInfo エンドポイントとディスカバリードキュメントを提供します。
WebAuthn: プラットフォーム認証器またはローミングセキュリティキーに支えられた公開鍵資格情報による、パスワードレス認証用の W3C Web Authentication API。
FIDO2: WebAuthn と、ブラウザと外部認証器の間で使用される CTAP (Client-To-Authenticator Protocol) を包括する、FIDO Alliance のアンブレラ仕様です。
U2F: Universal 2nd Factor — 第 2 要素セキュリティキー向けの初代 FIDO プロトコル。FIDO2 / CTAP2 に置き換えられましたが、レガシー YubiKey では引き続きサポートされています。
Server-Sent Events (SSE): Content-Type: text/event-stream を使用した、HTTP 上のシンプルなテキストベースの一方向ストリーミングプロトコル。WHATWG HTML 標準の一部です。ライブ通知や AI ストリーミング応答に利用されます。
Socket.IO: WebSocket (HTTP ロングポーリングのフォールバック付き) 上に構築された高レベルライブラリで、ルーム、ネームスペース、自動再接続、バイナリサポートを提供します。素の WebSocket とは異なるワイヤプロトコルを使用します。
SignalR: もともと ASP.NET 向けに開発された Microsoft のリアルタイムライブラリ。トランスポートに WebSocket、Server-Sent Events、ロングポーリングを使用し、ハブベースの RPC とトランスポートの自動交渉を内蔵しています。
SignalR Core: ASP.NET Core 向けに再設計された SignalR。クラシック SignalR とは異なるワイヤプロトコルを使用するため — クライアントは対応するサーバーバージョンに合わせる必要があります。
Pusher: チャネルおよびプレゼンスのセマンティクスを備えたホスト型リアルタイムメッセージングサービス。sgcWebSockets には、型付きの Pusher クライアントコンポーネントが含まれます。
MCP (Model Context Protocol): Anthropic が提唱したオープンプロトコルで、LLM ベースのホストアプリケーションに対して、サーバーからツール、リソース、プロンプトを公開できます。sgcWebSockets には MCP クライアント (TsgcWSAPIClient_MCP) とサーバー (TsgcWSAPIServer_MCP) の両方が含まれます。
Cloud HSM: クラウドサービスとしてレンタル提供される Hardware Security Module (例: AWS CloudHSM、Azure Dedicated HSM、Google Cloud HSM)。鍵は HSM から外部に出ることがなく、署名操作はリモートで実行されます。
eIDAS: Electronic Identification, Authentication and Trust Services — 適格電子署名 (QES)、適格トラストサービスプロバイダ、および QES と手書き署名の法的同等性を定義する EU 規則 (910/2014、2024/1183 で更新)。
コード署名: 実行可能ファイル、ライブラリ、インストーラーにデジタル署名を施し、実行前に OS およびユーザーが発行元と完全性を検証できるようにすること。Windows は Authenticode、macOS は codesign、Java は jarsigner を使用します。
ClickOnce 署名: ClickOnce .NET アプリケーション向けの Microsoft のデプロイメントマニフェスト署名。Authenticode 証明書でアプリケーションマニフェストとデプロイメントマニフェストに署名します。
NuGet 署名: 消費者がパッケージの発行元を検証できるよう、.nupkg ファイルに PKCS#7 の作成者またはリポジトリ署名を付与すること。nuget.org に署名済みパッケージを掲載する際に必要です。
VSIX 署名: Visual Studio Extension (.vsix) パッケージに OPC (Open Packaging Conventions) 署名を施し、Visual Studio ギャラリーで出所を検証できるようにすること。
Windows Hello: Windows 10 および 11 における Microsoft の生体認証 / PIN サインイン機能。Windows Biometric Framework とプラットフォーム資格情報プロバイダの上に構築されています。
Windows Biometric Framework: 生体センサーを共通の API で抽象化する、Windows のカーネルモード + ユーザーモードフレームワーク。sgcBiometrics は WBF (Winbio*) を直接利用して構築されています。
IOCP: I/O Completion Ports — Windows のスケーラブルな非同期 I/O プリミティブ。sgcWebSockets Enterprise エディションには、数万の同時 WebSocket 接続にスケールする Indy スタイルの IOCP サーバーが付属しています。
EPOLL: Linux のスケーラブルな I/O イベント通知機構。sgcWebSockets Enterprise エディションには、IOCP の設計に対応する EPOLL Linux64 サーバーが付属しています。
HTTP.SYS: Windows のカーネルモード HTTP リスナー (IIS および Windows Communication Foundation で使用)。Enterprise HTTP.SYS サーバーは、高スループットを実現するため、URL プレフィックスをカーネルに登録します。
OpenSSL: 広く展開されているオープンソースの TLS / 暗号化ライブラリ (libssl + libcrypto)。sgcWebSockets は OpenSSL 1.0.2/1.1.1 および現行の OpenSSL 3.x の両方をサポートします。
SChannel: Secure Channel — OS に統合された Microsoft Windows の TLS/SSL プロバイダ。sgcWebSockets は Windows 上で OpenSSL に代わる選択肢として SChannel をサポートします。再配布する DLL は不要です。
gRPC: HTTP/2 ストリーム上で Protocol Buffers を用いる、契約優先のモダンな RPC フレームワーク。単項、サーバーストリーミング、クライアントストリーミング、双方向ストリーミングの各呼び出しをサポートします。
サーバープッシュ: クライアントからの要求前に、サーバーがリソースを (PUSH_PROMISE で) クライアントに送信できる HTTP/2 メカニズム。現在 Chromium ベースのブラウザではデフォルト無効ですが、sgcWebSockets はバックエンド間用途で引き続きサポートします。
多重化: 単一のトランスポート接続上で、複数の独立したストリームを伝送すること。HTTP/2 は 1 本の TCP 接続上でストリームを多重化し、HTTP/3 は 1 本の QUIC 接続上で、トランスポート層のヘッドオブラインブロッキングなしにストリームを多重化します。
ヘッダー圧縮: 繰り返される HTTP ヘッダーのワイヤ上のバイト数を削減すること。HTTP/2 は HPACK、HTTP/3 は QPACK を使用します。両者とも、最近使用されたヘッダーフィールドの接続単位の動的テーブルに依存します。
フロー制御: 送信側が受信側を圧倒するのを防ぐメカニズム。HTTP/2 は WINDOW_UPDATE フレームで駆動される、ストリーム単位および接続単位のフロー制御ウィンドウを備えます。
キープアライブ: 中継機器越しに接続を維持し、応答のないピアを検出するため、定期的に送信されるプローブフレーム。WebSocket は PING/PONG 制御フレームを使用し、MQTT は設定された KeepAlive 間隔で PINGREQ/PINGRESP を使用します。
CoAP: Constrained Application Protocol — 制約のあるデバイス向けの RESTful な UDP ベースプロトコル。オプションで DTLS をサポートします。RFC 7252 として規定されています。
RCON: Source Remote Console — Counter-Strike、Garry's Mod などのゲームサーバーで使用される Valve / Source エンジンのリモート管理プロトコル。sgcWebSockets には、型付きの RCON クライアントが含まれます。

用語集

用語の定義をお求めですか?