sgcWebSockets 2026.8: QUIC, HTTP/3, OpenSSL Estático e uma Reformulação do TLS | Blog eSeGeCe

sgcWebSockets 2026.8: QUIC, HTTP/3, OpenSSL Estático e uma Reformulação do TLS

· Lançamentos

sgcWebSockets 2026.8 é o maior lançamento do ano. São quatro novos componentes de transporte, QUIC e HTTP/3 tanto no lado do cliente quanto no do servidor, o OpenSSL agora pode ser vinculado dentro do seu executável, de modo que uma aplicação TLS é distribuída sem uma única DLL, e o sgcHTML cresce em mais de trinta componentes, ganha um dispatcher para WebBroker e DataSnap e se adapta à tela de um celular.

Por baixo, a camada TLS SChannel foi desmontada e reconstruída. Se você usa a pilha TLS do Windows, este é o lançamento a instalar: TLSOptions.Version era silenciosamente ignorado, um certificado revogado era aceito, uma conexão TLS 1.3 nunca era concluída, e uma renegociação substituía o certificado sem verificação alguma. Tudo isso foi corrigido, e a verificação de revogação, um piso de versão e a verificação de certificado de cliente no servidor agora estão disponíveis. O restante deste post é o passeio guiado, e cada seção tem um link para o artigo que cobre o recurso em profundidade.

QUIC e HTTP/3

Quatro novos componentes trazem QUIC (RFC 9000) e HTTP/3 (RFC 9114) para Delphi e C++ Builder: TsgcQUICClient, TsgcQUICServer, TsgcHTTP3Client e TsgcHTTP3Server. Eles rodam sobre o motor QUIC nativo do OpenSSL 3.5, portanto não há nenhuma pilha de terceiros para distribuir, e você obtém o TLS 1.3 embutido no handshake, streams multiplexados sem bloqueio de cabeça de fila, retomada 0-RTT e migração de conexão quando o cliente muda de rede.

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;

O cliente HTTP/3 fala todos os verbos HTTP, faz compressão de cabeçalhos QPACK, funciona de forma bloqueante ou assíncrona, descobre um endpoint HTTP/3 através de Alt-Svc e trata o 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;

Ambos precisam do pacote sgcQUIC com o sgcWebSockets Enterprise. Leia mais: Componentes QUIC Cliente e Servidor e Componentes HTTP/3 Cliente e Servidor.

OpenSSL dentro do executável

Distribuir libcrypto e libssl ao lado da aplicação sempre foi a parte menos agradável de entregar um cliente TLS. A partir da 2026.8 a biblioteca pode vincular o OpenSSL 3.5.7 estaticamente: adicione uma unit à cláusula uses do seu projeto e as DLLs desaparecem. Remova a unit e as DLLs voltam a ser carregadas exatamente como antes, então a escolha é uma mudança de uma linha em qualquer direção.

uses
  sgcWebSocket, sgcWebSocket_Classes,
  sgcIdSSLOpenSSL_Static;

Cobre clientes e servidores, 32 e 64 bits, a partir do Delphi XE2. Leia mais: Vinculação Estática do OpenSSL, Sem Mais DLLs.

sgcHTML: WebBroker, DataSnap e trinta novos componentes

As páginas sgcHTML não estão mais atreladas ao servidor sgcWebSockets. Um novo componente dispatcher as serve a partir de qualquer aplicação WebBroker, standalone, ISAPI, Apache ou CGI, e a partir de servidores DataSnap, onde a ponte adiciona atualizações WebSocket ao vivo na mesma porta dos seus endpoints 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

O conjunto de componentes cresceu bastante neste lançamento, e tudo continua sendo desenhado no servidor, sem nenhuma biblioteca do lado do cliente para carregar:

As páginas também se adaptam ao tamanho da tela agora. Em um celular o menu lateral se recolhe atrás de um botão e o conteúdo usa toda a largura, em um desktop nada muda. Defina a nova propriedade Responsive como False para o layout fixo anterior. Leia mais: sgcHTML em WebBroker e DataSnap.

A reformulação do TLS SChannel

O SChannel é a pilha TLS do Windows, aquela que você tem sem precisar distribuir o OpenSSL. Ela tinha um conjunto de problemas que eram invisíveis de fora, que é o pior tipo. TLSOptions.Version não era lido de forma alguma no Windows 11 e no Windows Server 2022, pedir TLS 1.3 no Windows 10 entregava silenciosamente TLS 1.2, e deixar a versão indefinida reativava SSL 3.0, TLS 1.0 e TLS 1.1. Um certificado de servidor revogado era aceito mesmo com VerifyCertificate definido como True, porque a cadeia era construída sem solicitar nenhum status de revogação. Após uma renegociação, um novo certificado era aceito sem verificação da cadeia nem do nome do host. As conexões que o Indy abre paralelamente, um redirecionamento HTTP para outro host ou um canal de dados FTP, vinham com uma configuração vazia, então rodavam com a verificação desligada e nada reportava isso.

Tudo isso foi corrigido, a versão negociada agora é verificada quando o handshake termina, e três novos grupos de opções vieram com o trabalho: verificação de revogação, um piso de versão e a criptografia forte do 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;

Os padrões de revogação são deliberadamente tolerantes: IgnoreRevocationOffline e IgnoreNoRevocationCheck são True, então ligar a verificação não pode quebrar uma conexão que funcionava antes, e o Timeout limita a obtenção de CRL e OCSP para que um respondedor inacessível não trave o handshake. Um certificado que está de fato revogado é sempre rejeitado.

No lado do servidor, o SChannel agora pode pedir um certificado ao cliente, o que nunca fazia antes. O certificado do cliente passa pelas mesmas verificações que um cliente aplica a um certificado de servidor, a cadeia, as datas e o evento OnSChannelVerifyPeer, sem a verificação do nome do host.

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

Mais duas correções pertencem a esta seção. Um cliente usando SChannel nunca percebia que a conexão havia caído quando a outra ponta a encerrava sem uma notificação de fechamento, como acontece quando um proxy reinicia, então OnDisconnect nunca disparava e o WatchDog nunca era executado. E uma conexão TLS 1.3 nunca era concluída, porque o ticket de sessão que o servidor envia logo após o handshake deixava o cliente esperando por dados que o servidor já havia enviado. O handshake agora respeita ConnectTimeout em vez de cobrir apenas o connect TCP, e uma notificação de fechamento é enviada antes de fechar, tanto em conexões SChannel quanto Apple e Android.

Limites do servidor e os motores IOCP / EPOLL

Os servidores ganharam um conjunto de limites que antes eram ilimitados. O servidor WebSocket aceita 10.000 conexões simultâneas por padrão em vez de um número ilimitado, e limita quantos frames de controle um cliente pode enviar por segundo (100), para que não possa ser inundado com pings. O servidor HTTP/2 ganhou MaxRequestSize, e o componente DTLS ganhou MaxConnections, HandshakeTimeout e IdleTimeout, para que uma enxurrada de pacotes isolados vindos de endereços inventados não encha mais a memória do servidor. Cada um deles pode ser aumentado ou definido como 0 para o comportamento anterior.

Os motores de alto desempenho receberam uma longa lista de reparos: vazamentos de memória e de handles e falhas em vários caminhos de limpeza, um cliente derrubando a linha logo após ser aceito, uma conexão liberada duas vezes quando o servidor era parado no meio da limpeza, um use after free com as threads de trabalho habilitadas, e um buffer perdido a cada mensagem processada. O keep-alive HTTP não funcionava de forma alguma, então a conexão era fechada após cada requisição e o servidor se enchia de sockets em TIME_WAIT. No Linux, cada requisição HTTP vazava pedaços da requisição analisada, e todos os workers compartilhavam uma única fila de conexões, então uma ou duas threads faziam quase todo o trabalho.

Duas novas opções fecham o conjunto, ambas desligadas por padrão: sondas de keep-alive e um timeout de inatividade, para que sockets semiabertos não se acumulem mais, e a distribuição round robin das novas conexões entre as threads de trabalho.

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

Leia mais: TCPKeepAlive e KeepAliveTimeout para Servidores IOCP e EPOLL. Obrigado ao Andrea por contribuir com o patch no qual várias das correções dos motores se baseiam.

Protocolos: STOMP, MQTT, AMQP e HTTP/2

O STOMP recebeu o maior volume de trabalho. Um Disconnect gracioso agora aguarda até que o broker o confirme com um recibo, então nada se perde ao fechar. As mensagens são entregues exatamente como o broker as enviou, usando content-length para ler o corpo, de modo que ele pode conter quebras de linha e zeros binários. Frames empacotados vários em uma mesma mensagem WebSocket são todos processados, um frame dividido entre duas mensagens é remontado, e frames binários não são mais ignorados. ACK e NACK enviam os cabeçalhos que a versão negociada exige, e os heart-beats começam somente depois que o servidor confirma a conexão.

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

O MQTT não constrói mais pacotes que os brokers rejeitam, um CONNECT com nome de usuário e sem senha ou um pacote MQTT 5 carregando um bloco maior de propriedades, e o cliente MQTT 5 parou de ler além do fim de um pacote: um pacote truncado costumava entregar à aplicação, como valores de propriedades, o que quer que viesse a seguir na memória. Agora ele respeita o que o broker lhe diz, do Keep Alive retornado no CONNACK até uma mensagem que chega apenas com um Topic Alias. O caminho de publicação QoS 2 envia a confirmação de acompanhamento correta, descarta uma mensagem que o broker rejeitou em vez de tentar de novo para sempre, e refaz as tentativas em um cronograma sensato.

O cliente AMQP 1.0 agora está protegido contra um broker mal-intencionado: frames chegando em pequenos pedaços, um tamanho de cabeçalho inválido, mensagens aninhadas em profundidade excessiva, uma mensagem pequena forjada para se expandir em uma quantidade enorme de memória. O tamanho máximo de frame padrão para AMQP 0.9.1 e 1.0 é de 1 MB em vez de praticamente ilimitado. A compressão de cabeçalhos HTTP/2 está protegida contra cabeçalhos forjados, a conexão rejeita um frame DATA para um stream nunca aberto, uma enxurrada de frames PRIORITY, a reutilização de números de stream e enxurradas de continuações vazias, e o servidor rejeita nomes e valores de cabeçalho que contenham quebras de linha ou nulos, o que evita o request smuggling. O crescimento de memória causado por streams resetados e o "CONCURRENT STREAM limit has been exceeded" após cerca de 100 requisições estão ambos corrigidos.

Servidor MCP

As ferramentas agora podem expor um JSON Schema completo para a sua entrada, declarando arrays com itens, enums, tipos inteiros e anuláveis, objetos aninhados e additionalProperties, que alguns clientes MCP exigem e sem os quais rejeitariam a ferramenta. O servidor também expõe os metadados do protocolo 2025-11-25: a anotação readOnlyHint e o título da anotação, os ícones das ferramentas, o título do servidor, o site e os ícones, e a declaração de suporte a tarefas em tools/list.

Duas correções importam se você já executa um. O servidor escrevia o seu id interno de conexão como uma mensagem no stream de eventos que um cliente abre com GET, o que clientes como o VS Code GitHub Copilot reportavam como "Failed to parse message". E a verificação de origem só era executada quando a requisição trazia um cabeçalho que os navegadores nunca enviam, então nunca era executada para o caso que deveria impedir: uma página web visitada pelo usuário podia alcançar um servidor MCP na própria máquina dele, listar as suas ferramentas, executá-las e ler os resultados. A origem agora é verificada em toda requisição, incluindo a verificação preliminar do navegador.

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

Exchanges de criptomoedas

Dois relatos de clientes motivaram a maior parte disso. Uma requisição que falha com um status de erro HTTP agora reporta os cabeçalhos com que o servidor respondeu, então Retry-After em um 429, ou os contadores de rate limit que as exchanges retornam, finalmente podem ser lidos. Os clientes de API prontos levantam EsgcHTTPAPIProtocolException, que descende da exceção levantada antes, então os handlers existentes continuam funcionando.

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;

Todo cliente de exchange costumava reenviar a sua lista completa de assinaturas em uma única rajada após reconectar, em uma conexão com poucos milissegundos de vida, então uma exchange que limita mensagens por segundo a fechava imediatamente e o ciclo se repetia. O replay agora é ritmado, e na Binance enviado como frames combinados. Há também um novo throttle do lado do cliente sobre as mensagens que você envia.

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']);

A Binance aposentou os endpoints listenKey sobre os quais o user data stream do Spot foi construído, então as atualizações de conta, de ordens e de saldo agora vêm da WebSocket API da Binance, por uma segunda conexão que o componente abre por conta própria e renova após uma reconexão. Os eventos chegam no mesmo formato, então os seus handlers continuam funcionando, mas a nova inscrição é assinada: Binance.ApiSecret agora precisa ser definido além de Binance.ApiKey. Binance.us e Futures ainda usam um listenKey. Os dados de mercado de USD-M Futures agora são servidos a partir de dois endereços, selecionados com a nova propriedade Binance.FuturesStreamEndpoint (bfsePublic por padrão, bfseMarket para os streams de aggregate trades, mark price, kline e liquidação).

Também corrigido: os preços e tamanhos da OKX eram arredondados para cinco casas decimais antes de serem enviados, então uma ordem em um instrumento com um tick mais fino não era a ordem que você pediu, e um valor abaixo de 0.00001 era enviado como zero. Os keepalives da OKX e da KuCoin agora enviam o ping de texto que cada exchange exige em vez de um ping WebSocket, e reconectam quando nenhum pong volta. Leia mais: Rate Limits da Binance: Agrupamento, Ritmo e 429s Legíveis.

zlib 1.3.1 e uma lista de materiais

O zlib incluído passa de 1.2.12 para 1.3.1, o que corrige o CVE-2022-37434, uma leitura além do limite no heap em inflate. Os objetos vinculados foram reconstruídos para Delphi 7 até Delphi 13, 32 e 64 bits, e verificados em todos os compiladores. Uma correção paralela: os objetos zlib não eram vinculados de forma alguma no Delphi 10 Seattle 64 bits, que escolhia os objetos de 32 bits e falhava ao compilar.

Todo setup agora também instala sbom.cdx.json, uma lista de materiais de software CycloneDX (SBOM) que relaciona os componentes a partir dos quais a biblioteca é construída, com as suas versões e licenças. Enterprise e All-Access informam as versões do Indy customizado e do seu zlib, Core, Standard e Professional registram que o Indy é o fornecido com o Delphi ou o C++ Builder. É gerado por edição no momento da construção do instalador, então sempre corresponde ao que você instalou. Leia mais: zlib 1.3.1 no sgcWebSockets e no sgcOpenAPI e sgcWebSockets agora instala o seu próprio SBOM.

Correções de segurança

Além do TLS, este lançamento fecha uma série de brechas. Leia a lista, e se um destes componentes está na sua aplicação, atualize.

Mais uma que é fácil passar despercebida: a maioria das opções TLS se perdia ao serem copiadas de um componente para outro. Somente o IO handler, os protocolos ALPN e as opções do OpenSSL eram copiados, então os arquivos de certificado, a senha, o certificado raiz, a versão do TLS e VerifyCertificate ficavam vazios, e um componente configurado dessa forma acabava não verificando nada.

Acréscimos menores

Também novidade em torno deste lançamento

Duas peças que acompanham a biblioteca ganharam os seus próprios artigos neste mês: os componentes de servidor REST, um servidor HTTP construído para APIs REST com CORS, métricas, endpoints de health, multi-tenancy e um plugin OpenAPI que transforma um único arquivo de especificação em roteamento, validação, segurança e Swagger UI, e o sgcProtoBuf, o gerador de código que transforma arquivos .proto em units Delphi. Leia mais: TsgcHTTPRESTServer: o Novo Componente de Servidor REST, Servidor REST + OpenAPI, Usuários, Multi-Tenancy e Métricas e sgcProtoBuf: De Arquivos .proto a Units Delphi.

A edição .NET

O sgcWebSockets .NET 2026.8 traz a metade compartilhada deste lançamento. Todo o trabalho de SChannel está lá, a versão que era ignorada, as configurações perdidas em conexões clonadas, a renegociação não verificada, a conexão TLS 1.3 que nunca era concluída, a conexão caída que passava despercebida, o handshake sem limite e a corrida na inicialização, além da notificação de fechamento antes de fechar e da verificação de certificado de cliente no servidor. As correções de IOCP e EPOLL, a validação do handshake e dos frames WebSocket, o endurecimento de MQTT, STOMP, AMQP e HTTP/2, as correções de segurança de OAuth2, WebAuthn, MCP e do protocolo Files, e as mudanças nas exchanges (o user data stream do Binance Spot, o replay ritmado na reconexão, os keepalives da OKX e da KuCoin) também estão incluídos. O Disconnect gracioso do STOMP com o seu recibo, e o limite de frames de controle no servidor WebSocket, também são novidade lá.

Atualizando

A 2026.8 é uma atualização drop-in para projetos 2026.x existentes, com duas coisas que vale saber antes de compilar. O user data stream do Binance Spot agora assina a sua inscrição, então Binance.ApiSecret precisa ser definido junto com Binance.ApiKey. E o servidor WebSocket agora aceita 10.000 conexões simultâneas por padrão em vez de um número ilimitado, então aumente MaxConnections ou defina-o como 0 se você opera acima disso.

Todo o resto fica desligado até que você peça: a verificação de revogação, o piso de versão, a criptografia forte, a verificação de certificado de cliente, o keep-alive nos motores IOCP e EPOLL, o throttle de mensagens e a lista de origens permitidas do MCP têm como padrão o comportamento anterior.

Clientes com uma assinatura ativa podem baixar a nova build na área de clientes, ou em esegece.com/products/websockets/download.

Dúvidas, comentários ou ajuda com a migração? Entre em contato. Você receberá uma resposta das pessoas que escreveram o código.