sgcWebSockets 2026.8 : QUIC, HTTP/3, OpenSSL statique et refonte de TLS | Blog eSeGeCe

sgcWebSockets 2026.8 : QUIC, HTTP/3, OpenSSL statique et refonte de TLS

· Versions

sgcWebSockets 2026.8 est la plus importante version de l'année. Il y a quatre nouveaux composants de transport, QUIC et HTTP/3 côté client comme côté serveur, OpenSSL peut désormais être lié à l'intérieur de votre exécutable, de sorte qu'une application TLS se livre sans la moindre DLL, et sgcHTML gagne plus de trente composants, un répartiteur WebBroker et DataSnap, et s'adapte à l'écran d'un téléphone.

En dessous, la couche TLS SChannel a été démontée et reconstruite. Si vous utilisez la pile TLS de Windows, c'est la version à installer : TLSOptions.Version était silencieusement ignoré, un certificat révoqué était accepté, une connexion TLS 1.3 ne se terminait jamais, et une renégociation remplaçait le certificat sans aucune vérification. Tout cela est corrigé, et la vérification de révocation, un plancher de version et la vérification du certificat client sur le serveur sont maintenant disponibles. Le reste de cet article est la visite guidée, et chaque section renvoie à l'article qui traite la fonctionnalité en profondeur.

QUIC et HTTP/3

Quatre nouveaux composants apportent QUIC (RFC 9000) et HTTP/3 (RFC 9114) à Delphi et C++ Builder : TsgcQUICClient, TsgcQUICServer, TsgcHTTP3Client et TsgcHTTP3Server. Ils s'appuient sur le moteur QUIC natif d'OpenSSL 3.5, il n'y a donc aucune pile tierce à déployer, et vous obtenez TLS 1.3 intégré à la négociation, des flux multiplexés sans blocage de tête de ligne, la reprise 0-RTT et la migration de connexion lorsque le client change de réseau.

uses
  sgcQUIC_Client;

var
  oClient: TsgcQUICClient;
begin
  oClient := TsgcQUICClient.Create(nil);
  oClient.Host := 'www.example.com';
  oClient.Port := 443;
  oClient.OnQUICConnect    := OnQUICConnect;
  oClient.OnQUICStreamData := OnQUICStreamData;

  oClient.Active := True;          // TLS 1.3 handshake in a single flight
  oClient.WriteData('ping');       // send bytes on a QUIC stream
end;

Le client HTTP/3 gère tous les verbes HTTP, effectue la compression d'en-têtes QPACK, fonctionne en mode bloquant ou asynchrone, découvre un point de terminaison HTTP/3 grâce à Alt-Svc et prend en charge le server push.

uses
  sgcHTTP3_Client;

var
  oClient: TsgcHTTP3Client;
  vBody: string;
begin
  oClient := TsgcHTTP3Client.Create(nil);
  oClient.OnResponse := OnResponse;
  oClient.OnAltSvc   := OnAltSvc;

  oClient.Connect('www.example.com', 443);
  vBody := oClient.Get('https://www.example.com/');
end;

Les deux nécessitent le pack sgcQUIC avec sgcWebSockets Enterprise. En savoir plus : Composants client et serveur QUIC et Composants client et serveur HTTP/3.

OpenSSL à l'intérieur de l'exécutable

Déployer libcrypto et libssl à côté de l'application a toujours été la partie la moins agréable de la livraison d'un client TLS. À partir de 2026.8, la bibliothèque peut lier OpenSSL 3.5.7 de façon statique : ajoutez une unité à la clause uses de votre projet et les DLL disparaissent. Retirez l'unité et les DLL sont de nouveau chargées exactement comme avant, le choix se résume donc à une seule ligne dans un sens comme dans l'autre.

uses
  sgcWebSocket, sgcWebSocket_Classes,
  sgcIdSSLOpenSSL_Static;

Cela couvre les clients et les serveurs, en 32 et 64 bits, depuis Delphi XE2. En savoir plus : Liaison statique d'OpenSSL, fini les DLL.

sgcHTML : WebBroker, DataSnap et trente nouveaux composants

Les pages sgcHTML ne sont plus liées au serveur sgcWebSockets. Un nouveau composant répartiteur les sert depuis n'importe quelle application WebBroker, autonome, ISAPI, Apache ou CGI, et depuis les serveurs DataSnap, où la passerelle ajoute des mises à jour WebSocket en direct sur le même port que vos points de terminaison REST.

uses
  Web.HTTPApp, sgcHTMX_Engine_Server_WebBroker, sgcHTMX_Router;

// Any WebBroker host: the engine's Owner is the web module,
// so the standard WebBroker dispatcher calls it automatically
FEngine := TsgcHTMX_Engine_Server_WebBroker.Create(WebModule1);
FEngine.Router := FRouter;   // your htmx routes and the page

L'ensemble de composants s'est beaucoup enrichi dans cette version, et tout est toujours dessiné sur le serveur, sans bibliothèque côté client à charger :

Les pages s'adaptent aussi désormais à la taille de l'écran. Sur un téléphone, le menu latéral se replie derrière un bouton et le contenu occupe toute la largeur, sur un ordinateur de bureau rien ne change. Mettez la nouvelle propriété Responsive à False pour retrouver la mise en page fixe précédente. En savoir plus : sgcHTML sur WebBroker et DataSnap.

La refonte de TLS SChannel

SChannel est la pile TLS de Windows, celle dont vous disposez sans déployer OpenSSL du tout. Elle présentait un ensemble de problèmes invisibles de l'extérieur, ce qui est la pire des situations. TLSOptions.Version n'était pas lu du tout sur Windows 11 et Windows Server 2022, demander TLS 1.3 sur Windows 10 vous donnait silencieusement TLS 1.2, et laisser la version indéfinie réactivait SSL 3.0, TLS 1.0 et TLS 1.1. Un certificat serveur révoqué était accepté même avec VerifyCertificate à True, parce que la chaîne était construite sans demander le moindre état de révocation. Après une renégociation, un nouveau certificat était accepté sans aucune vérification de la chaîne ni du nom d'hôte. Les connexions qu'Indy ouvre en parallèle, une redirection HTTP vers un autre hôte ou un canal de données FTP, revenaient avec une configuration vide, elles fonctionnaient donc avec la vérification désactivée et rien ne le signalait.

Tout cela est corrigé, la version négociée est désormais contrôlée à la fin de la négociation, et trois nouveaux groupes d'options sont arrivés avec ce travail : la vérification de révocation, un plancher de version et le chiffrement fort de Windows.

// client
oClient.TLSOptions.Version     := tls1_3;   // highest version to use
oClient.TLSOptions.SChannel_Options.VersionMin := tls1_2;   // lowest accepted
oClient.TLSOptions.SChannel_Options.UseStrongCrypto := True;
oClient.TLSOptions.SChannel_Options.Revocation.Check   := scrcChainExcludeRoot;
oClient.TLSOptions.SChannel_Options.Revocation.Timeout := 5000;  // ms

// or all of it in one line
oClient.TLSOptions.Preset := tlspSecureDefaults;

Les valeurs par défaut de la révocation sont volontairement tolérantes : IgnoreRevocationOffline et IgnoreNoRevocationCheck sont à True, activer la vérification ne peut donc pas casser une connexion qui fonctionnait auparavant, et le Timeout borne la récupération des CRL et OCSP afin qu'un répondeur injoignable ne puisse pas bloquer la négociation. Un certificat réellement révoqué est toujours rejeté.

Côté serveur, SChannel peut maintenant demander un certificat au client, ce qu'il ne faisait jamais auparavant. Le certificat client passe par les mêmes contrôles qu'un client applique à un certificat serveur, la chaîne, les dates et l'événement OnSChannelVerifyPeer, sans la vérification du nom d'hôte.

oServer.SSLOptions.VerifyCertificate := True;
oServer.SSLOptions.VerifyCertificate_Options.FailIfNoCertificate := True;

Deux autres corrections ont leur place ici. Un client utilisant SChannel ne remarquait jamais que la connexion avait disparu lorsque l'autre extrémité la coupait sans notification de fermeture, comme lors du redémarrage d'un proxy, OnDisconnect ne se déclenchait donc jamais et le WatchDog ne s'exécutait jamais. Et une connexion TLS 1.3 ne se terminait jamais, parce que le ticket de session que le serveur envoie juste après la négociation laissait le client attendre des données que le serveur avait déjà envoyées. La négociation respecte désormais ConnectTimeout au lieu de ne couvrir que la connexion TCP, et une notification de fermeture est envoyée avant la fermeture, sur les connexions SChannel, Apple et Android.

Limites des serveurs et moteurs IOCP / EPOLL

Les serveurs ont reçu un ensemble de limites qui étaient auparavant sans borne. Le serveur WebSocket accepte 10 000 connexions simultanées par défaut au lieu d'un nombre illimité, et plafonne le nombre de trames de contrôle qu'un client peut envoyer chaque seconde (100), afin qu'il ne puisse pas être inondé de pings. Le serveur HTTP/2 a gagné MaxRequestSize, et le composant DTLS MaxConnections, HandshakeTimeout et IdleTimeout, de sorte qu'un déluge de paquets isolés provenant d'adresses inventées ne remplit plus la mémoire du serveur. Chacune d'elles peut être augmentée ou mise à 0 pour retrouver le comportement précédent.

Les moteurs haute performance ont reçu une longue liste de réparations : fuites de mémoire et de handles et plantages sur plusieurs chemins de nettoyage, un client coupant la ligne juste après avoir été accepté, une connexion libérée deux fois lorsque le serveur était arrêté au milieu du nettoyage, une utilisation après libération avec les threads de travail activés, et un buffer perdu à chaque message traité. Le keep-alive HTTP ne fonctionnait pas du tout, la connexion était donc fermée après chaque requête et le serveur se remplissait de sockets en TIME_WAIT. Sous Linux, chaque requête HTTP laissait fuir des morceaux de la requête analysée, et tous les workers partageaient une seule file de connexions, si bien qu'un ou deux threads faisaient presque tout le travail.

Deux nouvelles options complètent l'ensemble, désactivées par défaut toutes les deux : les sondes keep-alive et un délai d'inactivité, pour que les sockets semi-ouvertes ne s'accumulent plus, et la distribution en tourniquet des nouvelles connexions entre les threads de travail.

Server.IOHandlerOptions.IOHandlerType := iohEPOLL;
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Enabled  := True;
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Time     := 60;  // seconds idle before probing
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Interval := 10;  // seconds between probes
Server.IOHandlerOptions.KeepAliveTimeout            := 120; // seconds

En savoir plus : TCPKeepAlive et KeepAliveTimeout pour les serveurs IOCP et EPOLL. Merci à Andrea pour le correctif sur lequel plusieurs des corrections des moteurs sont basées.

Protocoles : STOMP, MQTT, AMQP et HTTP/2

STOMP a reçu le plus de travail. Un Disconnect propre attend désormais que le broker le confirme par un accusé de réception, rien n'est donc perdu à la fermeture. Les messages sont délivrés exactement tels que le broker les a envoyés, en utilisant content-length pour lire le corps, qui peut donc contenir des sauts de ligne et des zéros binaires. Les trames regroupées à plusieurs dans un même message WebSocket sont toutes traitées, une trame répartie sur deux messages est réassemblée, et les trames binaires ne sont plus ignorées. ACK et NACK envoient les en-têtes que la version négociée exige, et les battements de cœur ne démarrent qu'après que le serveur a confirmé la connexion.

oSTOMP.DisconnectTimeout := 10000;   // ms to wait for the receipt, 0 = return at once
oSTOMP.ACKEx(vMessageId, vSubscriptionId);
ShowMessage('STOMP ' + oSTOMP.NegotiatedVersion);

MQTT ne construit plus de paquets que les brokers rejettent, un CONNECT avec un nom d'utilisateur et sans mot de passe ou un paquet MQTT 5 transportant un bloc de propriétés plus grand, et le client MQTT 5 a cessé de lire au-delà de la fin d'un paquet : un paquet tronqué transmettait auparavant à l'application, comme valeurs de propriétés, tout ce qui suivait en mémoire. Il respecte maintenant ce que le broker lui indique, du Keep Alive renvoyé dans le CONNACK jusqu'à un message arrivant avec seulement un Topic Alias. Le chemin de publication en QoS 2 envoie la bonne confirmation de suivi, écarte un message refusé par le broker au lieu de réessayer indéfiniment, et réessaie selon un rythme raisonnable.

Le client AMQP 1.0 est désormais protégé contre un broker malveillant : des trames arrivant en petits morceaux, une taille d'en-tête invalide, des messages imbriqués trop profondément, un petit message conçu pour se dilater en une énorme quantité de mémoire. La taille maximale de trame par défaut pour AMQP 0.9.1 et 1.0 est de 1 Mo au lieu d'être pratiquement illimitée. La compression d'en-têtes HTTP/2 est protégée contre les en-têtes forgés, la connexion rejette une trame DATA pour un flux jamais ouvert, un déluge de trames PRIORITY, la réutilisation de numéros de flux et les déluges de continuations vides, et le serveur rejette les noms et les valeurs d'en-tête contenant des sauts de ligne ou des nuls, ce qui empêche le request smuggling. La croissance de la mémoire due aux flux réinitialisés et le "CONCURRENT STREAM limit has been exceeded" après une centaine de requêtes sont tous deux corrigés.

Serveur MCP

Les outils peuvent maintenant exposer un JSON Schema complet pour leur entrée, en déclarant des tableaux avec leurs éléments, des enums, des types entiers et nullables, des objets imbriqués et additionalProperties, ce que certains clients MCP exigent et rejetteraient sinon. Le serveur expose aussi les métadonnées du protocole 2025-11-25 : l'annotation readOnlyHint et le titre d'annotation, les icônes d'outil, le titre du serveur, son site web et ses icônes, ainsi que la déclaration de prise en charge des tâches dans tools/list.

Deux corrections comptent si vous en exécutez déjà un. Le serveur écrivait son identifiant de connexion interne comme un message sur le flux d'événements qu'un client ouvre avec GET, ce que des clients tels que VS Code GitHub Copilot signalaient par "Failed to parse message". Et la vérification de l'origine ne s'exécutait que lorsque la requête portait un en-tête que les navigateurs n'envoient jamais, elle ne s'exécutait donc jamais pour le cas qu'elle devait justement empêcher : une page web visitée par l'utilisateur pouvait atteindre un serveur MCP sur sa propre machine, lister ses outils, les exécuter et lire les résultats. L'origine est maintenant vérifiée à chaque requête, y compris lors de la vérification préliminaire du navigateur.

MCPServer.MCPOptions.HTTPStreamable.AllowedOrigins.Add('https://*.example.com');

Plateformes d'échange crypto

Deux signalements de clients sont à l'origine de l'essentiel de ces changements. Une requête qui échoue avec un statut d'erreur HTTP rapporte désormais les en-têtes renvoyés par le serveur, si bien que Retry-After sur un 429, ou les compteurs de limite de débit que renvoient les plateformes, peuvent enfin être lus. Les clients d'API prêts à l'emploi lèvent EsgcHTTPAPIProtocolException, qui descend de l'exception levée auparavant, les gestionnaires existants continuent donc de fonctionner.

try
  vResponse := oBinance.GetAggregateTrades('BTCUSDT');
except
  on E: EsgcHTTPAPIProtocolException do
  begin
    if E.ErrorCode = 429 then
      Sleep(E.RetryAfterMs);
    vWeight := E.GetHeader('X-MBX-USED-WEIGHT-1M');
    // E.ResponseHeaders holds the complete list
  end;
end;

Chaque client de plateforme renvoyait auparavant toute sa liste d'abonnements en une seule rafale après une reconnexion, sur une connexion vieille de quelques millisecondes, si bien qu'une plateforme limitant le nombre de messages par seconde la fermait aussitôt et le cycle recommençait. La réémission est maintenant cadencée, et sur Binance envoyée sous forme de trames combinées. Il y a également une nouvelle limitation côté client sur les messages que vous envoyez.

oBinance.Throttle.Enabled     := True;
oBinance.Throttle.MaxMessages := 4;      // per window
oBinance.Throttle.IntervalMs  := 1000;
// paced reconnect replay is on by default:
// oBinance.Throttle.PaceResubscribe := False;  restores the old burst

// subscribe a whole watchlist with ONE frame
oBinance.SubscribeStreams(['btcusdt@trade', 'ethusdt@trade', 'bnbusdt@trade']);

Binance a retiré les points de terminaison listenKey sur lesquels reposait le flux de données utilisateur Spot, les mises à jour de compte, d'ordres et de soldes proviennent donc maintenant de l'API WebSocket de Binance, via une seconde connexion que le composant ouvre lui-même et renouvelle après une reconnexion. Les événements arrivent sous la même forme, vos gestionnaires continuent donc de fonctionner, mais le nouvel abonnement est signé : Binance.ApiSecret doit désormais être renseigné en plus de Binance.ApiKey. Binance.us et Futures utilisent toujours un listenKey. Les données de marché des Futures USD-M sont maintenant servies depuis deux adresses, sélectionnées avec la nouvelle propriété Binance.FuturesStreamEndpoint (bfsePublic par défaut, bfseMarket pour les flux d'agrégats de transactions, de prix mark, de kline et de liquidations).

Également corrigé : les prix et les tailles OKX étaient arrondis à cinq décimales avant d'être envoyés, si bien qu'un ordre sur un instrument au pas plus fin n'était pas l'ordre demandé, et une valeur inférieure à 0.00001 était envoyée comme zéro. Les keepalives OKX et KuCoin envoient maintenant le ping texte que chaque plateforme exige au lieu d'un ping WebSocket, et se reconnectent lorsqu'aucun pong ne revient. En savoir plus : Limites de débit Binance : regroupement, cadencement et 429 lisibles.

zlib 1.3.1 et une nomenclature logicielle

Le zlib embarqué passe de 1.2.12 à 1.3.1, ce qui corrige CVE-2022-37434, une lecture hors limites dans le tas au sein d'inflate. Les objets liés ont été reconstruits pour Delphi 7 à Delphi 13, en 32 et 64 bits, et vérifiés sur chaque compilateur. Une correction annexe : les objets zlib n'étaient pas liés du tout sur Delphi 10 Seattle 64 bits, qui prenait les objets 32 bits et échouait à la compilation.

Chaque installateur installe désormais aussi sbom.cdx.json, une nomenclature logicielle CycloneDX qui liste les composants à partir desquels la bibliothèque est construite, avec leurs versions et leurs licences. Enterprise et All-Access indiquent les versions de l'Indy personnalisé et de son zlib, Core, Standard et Professional indiquent que l'Indy utilisé est celui fourni avec Delphi ou C++ Builder. Elle est générée par édition au moment de la construction de l'installateur, elle correspond donc toujours à ce que vous avez installé. En savoir plus : zlib 1.3.1 dans sgcWebSockets et sgcOpenAPI et sgcWebSockets installe désormais son propre SBOM.

Corrections de sécurité

Au-delà de TLS, cette version comble un certain nombre de failles. Lisez la liste, et si l'un de ces composants est présent dans votre application, mettez à jour.

Une autre qu'il est facile de manquer : la plupart des options TLS étaient perdues lorsqu'elles étaient copiées d'un composant à un autre. Seuls le gestionnaire d'entrée/sortie, les protocoles ALPN et les options OpenSSL étaient copiés, les fichiers de certificat, le mot de passe, le certificat racine, la version TLS et VerifyCertificate restaient donc vides, et un composant configuré ainsi finissait par ne rien vérifier du tout.

Ajouts plus modestes

Également nouveau autour de cette version

Deux éléments livrés avec la bibliothèque ont eu droit à leur propre article ce mois-ci : les composants serveur REST, un serveur HTTP conçu pour les API REST avec CORS, métriques, points de terminaison de santé, multi-tenancy et un plugin OpenAPI qui transforme un seul fichier de spécification en routage, validation, sécurité et Swagger UI, et sgcProtoBuf, le générateur de code qui transforme les fichiers .proto en unités Delphi. En savoir plus : TsgcHTTPRESTServer : le nouveau composant serveur REST, Serveur REST + OpenAPI, Utilisateurs, multi-tenancy et métriques et sgcProtoBuf : des fichiers .proto aux unités Delphi.

L'édition .NET

sgcWebSockets .NET 2026.8 reprend la moitié commune de cette version. Tout le travail sur SChannel s'y trouve, la version ignorée, les paramètres perdus sur les connexions clonées, la renégociation non vérifiée, la connexion TLS 1.3 qui ne se terminait jamais, la connexion coupée qui passait inaperçue, la négociation sans borne et la course au démarrage, ainsi que la notification de fermeture avant la fermeture et la vérification du certificat client sur le serveur. Les corrections IOCP et EPOLL, la validation de la négociation et des trames WebSocket, le durcissement de MQTT, STOMP, AMQP et HTTP/2, les corrections de sécurité OAuth2, WebAuthn, MCP et du protocole Files, ainsi que les changements sur les plateformes d'échange (le flux de données utilisateur Binance Spot, la réémission cadencée à la reconnexion, les keepalives OKX et KuCoin) sont également inclus. Le Disconnect STOMP propre avec son accusé de réception, et la limite de trames de contrôle sur le serveur WebSocket, y sont nouveaux eux aussi.

Mise à jour

2026.8 est une mise à jour directe pour les projets 2026.x existants, avec deux points à connaître avant de compiler. Le flux de données utilisateur Binance Spot signe maintenant son abonnement, Binance.ApiSecret doit donc être renseigné en plus de Binance.ApiKey. Et le serveur WebSocket accepte désormais 10 000 connexions simultanées par défaut au lieu d'un nombre illimité, augmentez donc MaxConnections ou mettez-le à 0 si vous dépassez ce chiffre.

Tout le reste est désactivé tant que vous ne le demandez pas : la vérification de révocation, le plancher de version, le chiffrement fort, la vérification du certificat client, le keep-alive sur les moteurs IOCP et EPOLL, la limitation des messages et la liste des origines autorisées MCP conservent tous le comportement précédent par défaut.

Les clients disposant d'un abonnement actif peuvent télécharger la nouvelle version depuis l'espace client, ou depuis esegece.com/products/websockets/download.

Des questions, des remarques ou besoin d'aide pour la migration ? Contactez-nous. Vous obtiendrez une réponse des personnes qui ont écrit le code.