sgcWebSockets 2026.8: QUIC, HTTP/3, statyczny OpenSSL i przebudowa TLS | Blog eSeGeCe

sgcWebSockets 2026.8: QUIC, HTTP/3, statyczny OpenSSL i przebudowa TLS

· Wydania

sgcWebSockets 2026.8 to największe wydanie tego roku. Pojawiły się cztery nowe komponenty transportowe, QUIC i HTTP/3 zarówno po stronie klienta, jak i serwera, OpenSSL może teraz zostać wlinkowany w plik wykonywalny, więc aplikacja korzystająca z TLS jest dostarczana bez ani jednej biblioteki DLL, a sgcHTML powiększa się o ponad trzydzieści komponentów, zyskuje dyspozytor dla WebBroker i DataSnap oraz dostosowuje się do ekranu telefonu.

Pod spodem warstwa TLS SChannel została rozłożona na części i zbudowana od nowa. Jeśli korzystasz ze stosu TLS systemu Windows, to jest wydanie, które warto zainstalować: TLSOptions.Version było po cichu ignorowane, unieważniony certyfikat był akceptowany, połączenie TLS 1.3 nigdy nie dochodziło do skutku, a renegocjacja podmieniała certyfikat całkowicie bez weryfikacji. Wszystko to zostało naprawione, a sprawdzanie unieważnień, minimalna wersja oraz weryfikacja certyfikatu klienta na serwerze są teraz dostępne. Reszta tego wpisu to przewodnik po nowościach, a każda sekcja zawiera odnośnik do artykułu, który omawia daną funkcję szczegółowo.

QUIC i HTTP/3

Cztery nowe komponenty wprowadzają QUIC (RFC 9000) i HTTP/3 (RFC 9114) do Delphi i C++ Builder: TsgcQUICClient, TsgcQUICServer, TsgcHTTP3Client i TsgcHTTP3Server. Działają na natywnym silniku QUIC z OpenSSL 3.5, więc nie ma stosu innej firmy do wdrażania, a TLS 1.3 jest wbudowany w handshake, dostajesz multipleksowane strumienie bez blokowania początku kolejki, wznawianie 0-RTT oraz migrację połączenia, gdy klient zmienia sieć.

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;

Klient HTTP/3 obsługuje każdą metodę HTTP, wykonuje kompresję nagłówków QPACK, pracuje w trybie blokującym lub asynchronicznym, wykrywa punkt końcowy HTTP/3 poprzez Alt-Svc i obsługuje 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;

Oba wymagają pakietu sgcQUIC wraz z sgcWebSockets Enterprise. Czytaj więcej: Komponenty klienta i serwera QUIC oraz Komponenty klienta i serwera HTTP/3.

OpenSSL wewnątrz pliku wykonywalnego

Wdrażanie libcrypto i libssl obok aplikacji zawsze było najmniej przyjemną częścią dostarczania klienta TLS. Od wersji 2026.8 biblioteka potrafi linkować OpenSSL 3.5.7 statycznie: dodaj jedną jednostkę do klauzuli uses swojego projektu, a biblioteki DLL znikają. Usuń tę jednostkę, a biblioteki DLL są ładowane ponownie dokładnie tak jak wcześniej, więc wybór sprowadza się do zmiany jednej linii w obie strony.

uses
  sgcWebSocket, sgcWebSocket_Classes,
  sgcIdSSLOpenSSL_Static;

Obejmuje to klientów i serwery, 32 i 64 bity, od Delphi XE2 wzwyż. Czytaj więcej: Statyczne linkowanie OpenSSL, koniec z bibliotekami DLL.

sgcHTML: WebBroker, DataSnap i trzydzieści nowych komponentów

Strony sgcHTML nie są już związane z serwerem sgcWebSockets. Nowy komponent dyspozytora serwuje je z dowolnej aplikacji WebBroker, samodzielnej, ISAPI, Apache lub CGI, a także z serwerów DataSnap, gdzie mostek dodaje aktualizacje WebSocket na żywo na tym samym porcie co Twoje punkty końcowe 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

Zestaw komponentów znacznie się powiększył w tym wydaniu, a wszystko nadal jest rysowane na serwerze, bez żadnej biblioteki po stronie klienta do załadowania:

Strony dostosowują się teraz również do rozmiaru ekranu. Na telefonie boczne menu chowa się za przyciskiem, a treść zajmuje pełną szerokość, na komputerze nic się nie zmienia. Ustaw nową właściwość Responsive na False, aby wrócić do poprzedniego stałego układu. Czytaj więcej: sgcHTML na WebBroker i DataSnap.

Przebudowa TLS w SChannel

SChannel to stos TLS systemu Windows, ten, który dostajesz bez wdrażania OpenSSL w ogóle. Miał zestaw problemów niewidocznych z zewnątrz, czyli najgorszy możliwy rodzaj. TLSOptions.Version w ogóle nie było odczytywane w Windows 11 i Windows Server 2022, żądanie TLS 1.3 w Windows 10 po cichu dawało TLS 1.2, a pozostawienie wersji niezdefiniowanej włączało z powrotem SSL 3.0, TLS 1.0 i TLS 1.1. Unieważniony certyfikat serwera był akceptowany nawet przy VerifyCertificate ustawionym na True, ponieważ łańcuch był budowany bez pytania o jakikolwiek status unieważnienia. Po renegocjacji nowy certyfikat był akceptowany bez sprawdzenia łańcucha ani nazwy hosta. Połączenia, które Indy otwiera dodatkowo, przekierowanie HTTP na inny host czy kanał danych FTP, wracały z pustą konfiguracją, więc działały z wyłączoną weryfikacją i nic tego nie zgłaszało.

Wszystko to zostało naprawione, wynegocjowana wersja jest teraz sprawdzana po zakończeniu handshake'u, a wraz z tymi pracami pojawiły się trzy nowe grupy opcji: sprawdzanie unieważnień, minimalna wersja oraz silna kryptografia 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;

Domyślne ustawienia unieważnień są celowo pobłażliwe: IgnoreRevocationOffline i IgnoreNoRevocationCheck mają wartość True, więc włączenie sprawdzania nie może zepsuć połączenia, które wcześniej działało, a Timeout ogranicza pobieranie CRL i OCSP, więc nieosiągalny serwer odpowiedzi nie zablokuje handshake'u. Certyfikat, który faktycznie został unieważniony, jest zawsze odrzucany.

Po stronie serwera SChannel może teraz poprosić klienta o certyfikat, czego wcześniej nigdy nie robił. Certyfikat klienta przechodzi te same kontrole, które klient stosuje do certyfikatu serwera, łańcuch, daty i zdarzenie OnSChannelVerifyPeer, bez sprawdzania nazwy hosta.

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

Należą tu jeszcze dwie poprawki. Klient używający SChannel nigdy nie zauważał, że połączenie zniknęło, gdy druga strona zerwała je bez powiadomienia o zamknięciu, co zdarza się przy restarcie serwera proxy, więc OnDisconnect nigdy się nie wywoływało, a WatchDog nigdy nie ruszał. Poza tym połączenie TLS 1.3 w ogóle nie dochodziło do skutku, ponieważ bilet sesji wysyłany przez serwer zaraz po handshake'u zostawiał klienta czekającego na dane, które serwer już wysłał. Handshake respektuje teraz ConnectTimeout, zamiast obejmować wyłącznie połączenie TCP, a powiadomienie o zamknięciu jest wysyłane przed zamknięciem, zarówno w połączeniach SChannel, jak i Apple oraz Android.

Limity serwera oraz silniki IOCP / EPOLL

Serwery otrzymały zestaw limitów, które wcześniej były nieograniczone. Serwer WebSocket akceptuje domyślnie 10 000 jednoczesnych połączeń zamiast nieograniczonej liczby i ogranicza liczbę ramek kontrolnych, jakie klient może wysłać w ciągu sekundy (100), więc nie da się go zalać pingami. Serwer HTTP/2 zyskał MaxRequestSize, a komponent DTLS MaxConnections, HandshakeTimeout i IdleTimeout, więc zalew pojedynczych pakietów ze zmyślonych adresów nie zapełnia już pamięci serwera. Każdy z nich można podnieść lub ustawić na 0, aby przywrócić poprzednie zachowanie.

Silniki o wysokiej wydajności doczekały się długiej listy napraw: wycieki pamięci i uchwytów oraz awarie na kilku ścieżkach czyszczenia, klient zrywający połączenie tuż po zaakceptowaniu, połączenie zwalniane dwukrotnie, gdy serwer był zatrzymywany w trakcie czyszczenia, użycie po zwolnieniu przy włączonych wątkach roboczych oraz bufor gubiony przy każdej przetworzonej wiadomości. HTTP keep-alive w ogóle nie działało, więc połączenie było zamykane po każdym żądaniu, a serwer zapełniał się gniazdami w stanie TIME_WAIT. W systemie Linux każde żądanie HTTP powodowało wyciek fragmentów sparsowanego żądania, a wszystkie wątki robocze współdzieliły jedną kolejkę połączeń, więc jeden lub dwa wątki wykonywały prawie całą pracę.

Całość dopełniają dwie nowe opcje, obie domyślnie wyłączone: sondy keep-alive i limit czasu bezczynności, dzięki czemu półotwarte gniazda przestają się gromadzić, oraz rozdzielanie nowych połączeń pomiędzy wątki robocze w trybie round robin.

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

Czytaj więcej: TCPKeepAlive i KeepAliveTimeout dla serwerów IOCP i EPOLL. Podziękowania dla Andrei za przekazanie łatki, na której opiera się kilka poprawek w silnikach.

Protokoły: STOMP, MQTT, AMQP i HTTP/2

STOMP otrzymał najwięcej uwagi. Łagodne Disconnect czeka teraz, aż broker potwierdzi je pokwitowaniem, więc przy zamykaniu nic nie ginie. Wiadomości są dostarczane dokładnie w takiej postaci, w jakiej wysłał je broker, z użyciem content-length do odczytania treści, więc może ona zawierać znaki końca linii i zera binarne. Ramki upakowane po kilka w jednej wiadomości WebSocket są przetwarzane wszystkie, ramka podzielona na dwie wiadomości jest składana z powrotem, a ramki binarne nie są już ignorowane. ACK i NACK wysyłają nagłówki wymagane przez wynegocjowaną wersję, a heart-beaty startują dopiero po potwierdzeniu połączenia przez serwer.

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

MQTT nie buduje już pakietów odrzucanych przez brokery, takich jak CONNECT z nazwą użytkownika i bez hasła czy pakiet MQTT 5 niosący większy blok właściwości, a klient MQTT 5 przestał czytać poza koniec pakietu: obcięty pakiet potrafił wcześniej przekazać aplikacji jako wartości właściwości cokolwiek, co znajdowało się dalej w pamięci. Respektuje teraz to, co mówi mu broker, od wartości Keep Alive zwróconej w CONNACK po wiadomość przychodzącą z samym Topic Alias. Ścieżka publikowania QoS 2 wysyła prawidłowe potwierdzenie następcze, odrzuca wiadomość odrzuconą przez brokera zamiast ponawiać ją w nieskończoność i ponawia próby według rozsądnego harmonogramu.

Klient AMQP 1.0 jest teraz zabezpieczony przed niepoprawnym brokerem: ramkami przychodzącymi w małych kawałkach, nieprawidłowym rozmiarem nagłówka, wiadomościami zagnieżdżonymi zbyt głęboko, małą wiadomością spreparowaną tak, by rozwinąć się w ogromną ilość pamięci. Domyślny maksymalny rozmiar ramki dla AMQP 0.9.1 i 1.0 wynosi 1 MB zamiast praktycznie nieograniczonego. Kompresja nagłówków HTTP/2 jest zabezpieczona przed spreparowanymi nagłówkami, połączenie odrzuca ramkę DATA dla strumienia, który nigdy nie został otwarty, zalew ramek PRIORITY, ponowne użycie numeru strumienia oraz zalew pustych ramek kontynuacji, a serwer odrzuca nazwy i wartości nagłówków zawierające znaki końca linii lub bajty zerowe, co zapobiega przemycaniu żądań. Naprawiono zarówno przyrost pamięci przy resetowanych strumieniach, jak i błąd "CONCURRENT STREAM limit has been exceeded" pojawiający się po około 100 żądaniach.

Serwer MCP

Narzędzia mogą teraz udostępniać kompletny schemat JSON Schema dla swoich danych wejściowych, deklarując tablice z elementami, wyliczenia, typy całkowite i dopuszczające wartość null, obiekty zagnieżdżone oraz additionalProperties, czego niektórzy klienci MCP wymagają i bez czego odrzuciliby narzędzie. Serwer udostępnia też metadane protokołu 2025-11-25: adnotację readOnlyHint i tytuł adnotacji, ikony narzędzi, tytuł serwera, stronę internetową i ikony oraz deklarację obsługi zadań w tools/list.

Dwie poprawki mają znaczenie, jeśli już go uruchamiasz. Serwer zapisywał swój wewnętrzny identyfikator połączenia jako wiadomość w strumieniu zdarzeń, który klient otwiera metodą GET, co klienci tacy jak VS Code GitHub Copilot zgłaszali jako "Failed to parse message". Poza tym sprawdzanie origin uruchamiało się tylko wtedy, gdy żądanie niosło nagłówek, którego przeglądarki nigdy nie wysyłają, więc nigdy nie działało w przypadku, któremu miało zapobiegać: strona internetowa odwiedzona przez użytkownika mogła dotrzeć do serwera MCP na jego własnym komputerze, wylistować jego narzędzia, uruchomić je i odczytać wyniki. Origin jest teraz sprawdzany przy każdym żądaniu, łącznie ze wstępnym zapytaniem przeglądarki.

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

Giełdy kryptowalut

Większość tych zmian wynikła z dwóch zgłoszeń klientów. Żądanie, które kończy się statusem błędu HTTP, zgłasza teraz nagłówki, którymi odpowiedział serwer, więc Retry-After przy kodzie 429 czy liczniki limitów zwracane przez giełdy można wreszcie odczytać. Gotowe klienty API zgłaszają EsgcHTTPAPIProtocolException, który dziedziczy po zgłaszanym wcześniej wyjątku, więc istniejące procedury obsługi nadal działają.

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;

Każdy klient giełdy wysyłał wcześniej po ponownym połączeniu całą swoją listę subskrypcji w jednej serii, na połączeniu liczącym kilka milisekund, więc giełda ograniczająca liczbę wiadomości na sekundę zamykała je od razu i cykl się powtarzał. Powtórka jest teraz rozłożona w czasie, a na Binance wysyłana jako połączone ramki. Jest też nowe ograniczanie tempa po stronie klienta dla wiadomości, które wysyłasz.

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 wycofał punkty końcowe listenKey, na których zbudowany był strumień danych użytkownika Spot, więc aktualizacje konta, zleceń i sald przychodzą teraz z Binance WebSocket API, przez drugie połączenie, które komponent otwiera sam i odnawia po ponownym połączeniu. Zdarzenia docierają w tej samej postaci, więc Twoje procedury obsługi nadal działają, ale nowa subskrypcja jest podpisywana: Binance.ApiSecret musi być teraz ustawione tak samo jak Binance.ApiKey. Binance.us i Futures nadal używają listenKey. Dane rynkowe USD-M Futures są teraz serwowane z dwóch adresów, wybieranych nową właściwością Binance.FuturesStreamEndpoint (bfsePublic domyślnie, bfseMarket dla strumieni zagregowanych transakcji, ceny mark, kline i likwidacji).

Naprawiono również: ceny i wielkości OKX były zaokrąglane do pięciu miejsc po przecinku przed wysłaniem, więc zlecenie na instrumencie o drobniejszym kroku notowania nie było tym zleceniem, o które prosiłeś, a wartość poniżej 0.00001 była wysyłana jako zero. Keepalive w OKX i KuCoin wysyła teraz tekstowy ping wymagany przez każdą z tych giełd zamiast pinga WebSocket i łączy się ponownie, gdy nie przychodzi pong. Czytaj więcej: Limity Binance: grupowanie, rozkładanie w czasie i czytelne kody 429.

zlib 1.3.1 i zestawienie komponentów

Dołączony zlib przechodzi z wersji 1.2.12 na 1.3.1, co koryguje CVE-2022-37434, odczyt poza zakresem sterty w inflate. Linkowane obiekty zostały przebudowane dla Delphi 7 do Delphi 13, 32 i 64 bity, oraz zweryfikowane na każdym kompilatorze. Poprawka poboczna: obiekty zlib w ogóle nie były linkowane w Delphi 10 Seattle 64 bity, które wybierało obiekty 32-bitowe i nie kompilowało się.

Każdy instalator instaluje teraz również sbom.cdx.json, zestawienie komponentów oprogramowania w formacie CycloneDX, wymieniające składniki, z których zbudowana jest biblioteka, wraz z ich wersjami i licencjami. Enterprise i All-Access podają wersje dostosowanego Indy i jego zlib, Core, Standard i Professional odnotowują, że Indy jest tym dostarczonym z Delphi lub C++ Builder. Jest generowane osobno dla każdej edycji w czasie budowania instalatora, więc zawsze odpowiada temu, co zainstalowałeś. Czytaj więcej: zlib 1.3.1 w sgcWebSockets i sgcOpenAPI oraz sgcWebSockets instaluje teraz własny SBOM.

Poprawki bezpieczeństwa

Poza TLS to wydanie zamyka szereg luk. Przeczytaj listę i jeśli któryś z tych komponentów jest w Twojej aplikacji, zaktualizuj ją.

Jeszcze jedna rzecz, którą łatwo przeoczyć: większość opcji TLS ginęła przy kopiowaniu z jednego komponentu do drugiego. Kopiowane były tylko IO handler, protokoły ALPN i opcje OpenSSL, więc pliki certyfikatów, hasło, certyfikat główny, wersja TLS i VerifyCertificate pozostawały puste, a komponent skonfigurowany w ten sposób ostatecznie niczego nie weryfikował.

Mniejsze dodatki

Nowości wokół tego wydania

Dwa elementy dostarczane z biblioteką doczekały się w tym miesiącu własnych artykułów: komponenty serwera REST, czyli serwer HTTP zbudowany pod API REST, z CORS, metrykami, punktami końcowymi kondycji, wielodostępnością i wtyczką OpenAPI, która zamienia jeden plik specyfikacji w routing, walidację, zabezpieczenia i Swagger UI, oraz sgcProtoBuf, generator kodu zamieniający pliki .proto w jednostki Delphi. Czytaj więcej: TsgcHTTPRESTServer: nowy komponent serwera REST, Serwer REST + OpenAPI, Użytkownicy, wielodostępność i metryki oraz sgcProtoBuf: od plików .proto do jednostek Delphi.

Edycja .NET

sgcWebSockets .NET 2026.8 przenosi wspólną część tego wydania. Wszystkie prace nad SChannel są tam obecne, ignorowana wersja, ustawienia gubione przy klonowanych połączeniach, niesprawdzana renegocjacja, połączenie TLS 1.3, które nigdy nie dochodziło do skutku, niezauważone zerwane połączenie, nieograniczony handshake i wyścig przy starcie, a do tego powiadomienie o zamknięciu przed zamknięciem oraz weryfikacja certyfikatu klienta na serwerze. Uwzględnione są również poprawki IOCP i EPOLL, walidacja handshake'u i ramek WebSocket, uszczelnienie MQTT, STOMP, AMQP i HTTP/2, poprawki bezpieczeństwa OAuth2, WebAuthn, MCP i protokołu Files oraz zmiany dotyczące giełd (strumień danych użytkownika Binance Spot, rozłożona w czasie powtórka po ponownym połączeniu, keepalive w OKX i KuCoin). Łagodne Disconnect w STOMP wraz z pokwitowaniem oraz limit ramek kontrolnych na serwerze WebSocket są tam również nowością.

Aktualizacja

2026.8 to aktualizacja typu drop-in dla istniejących projektów 2026.x, z dwiema rzeczami, o których warto wiedzieć przed budowaniem. Strumień danych użytkownika Binance Spot podpisuje teraz swoją subskrypcję, więc Binance.ApiSecret musi być ustawione obok Binance.ApiKey. Poza tym serwer WebSocket akceptuje teraz domyślnie 10 000 jednoczesnych połączeń zamiast nieograniczonej liczby, więc podnieś MaxConnections lub ustaw je na 0, jeśli pracujesz powyżej tej liczby.

Wszystko inne pozostaje wyłączone, dopóki o to nie poprosisz: sprawdzanie unieważnień, minimalna wersja, silna kryptografia, weryfikacja certyfikatu klienta, keep-alive w silnikach IOCP i EPOLL, ograniczanie tempa wiadomości oraz lista dozwolonych origin w MCP domyślnie zachowują poprzednie zachowanie.

Klienci z aktywną subskrypcją mogą pobrać nową kompilację ze strefy klienta lub z esegece.com/products/websockets/download.

Pytania, uwagi lub pomoc w migracji? Skontaktuj się z nami. Odpowiedź otrzymasz od osób, które napisały ten kod.