Ab sgcWebSockets 2024.2.0 wurde der HTTP/2-Server beim Empfang von HTTP/2-Anfragen verbessert. Standardmäßig wird jetzt jede neue HTTP/2-Anfrage in eine Queue gestellt und von einem der Threads im Thread-Pool abgearbeitet. So wird das Problem vermieden, dass mehrere Anfragen über dieselbe Verbindung sequenziell verarbeitet werden.
Sieh dir unten die Unterschiede zwischen HTTP 1.1 und HTTP 2.0 an:
HTTP 1.1
Beim traditionellen HTTP-Verhalten muss der Client bei mehreren Anfragen über dieselbe Verbindung jeweils auf die Antwort warten, bevor er die nächste Anfrage sendet. Dieser sequenzielle Ansatz erhöht die Ladezeit der Ressourcen einer Website erheblich. Um das zu lösen, führte HTTP/1.1 ein Feature namens Pipelining ein, mit dem ein Client mehrere Anfragen senden kann, ohne auf die Antworten des Servers zu warten. Der Server antwortet dem Client wiederum in derselben Reihenfolge, in der er die Anfragen erhalten hat.
So vielversprechend Pipelining auch wirkte — es brachte Probleme mit sich:
- Server-Ignoranz oder beschädigte Antworten: Manche Server ignorierten Pipeline-Anfragen oder beschädigten die Antworten, was zu unzuverlässiger Kommunikation führte.
- Head-of-Line Blocking: Die erste Anfrage in der Pipeline konnte nachfolgende Anfragen blockieren und so die Verarbeitung anderer Anfragen verzögern. Dieses Phänomen, bekannt als Head-of-Line Blocking, führte zu langsameren Ladezeiten.
Um das Laden von Seiten über HTTP/1.1-Server zu optimieren, implementierten Webbrowser einen Workaround: Sie öffnen sechs bis acht parallele Verbindungen zum Server und ermöglichen so das gleichzeitige Senden mehrerer Anfragen. Diese Parallelität soll die mit Pipelining verbundenen Probleme abmildern und die Gesamtladezeit verbessern.
Die Wahl von sechs bis acht parallelen Verbindungen durch die Browser basiert auf Optimierungsüberlegungen. Die genauen Gründe für diese Zahl liegen wahrscheinlich in einem Trade-off zwischen Ressourcennutzung, Netzwerk-Effizienz und der Vermeidung möglicher Engpässe.
HTTP 2.0
Als Antwort auf die Einschränkungen des Pipelinings führte HTTP/2 das Feature Multiplexing ein. Multiplexing ermöglicht eine effizientere Kommunikation zwischen Client und Server, indem es das gleichzeitige Senden mehrerer Anfragen und Antworten über eine einzige Verbindung erlaubt.
HTTP/2 nutzt einen binären Framing-Mechanismus, das heißt, HTTP-Nachrichten werden in kleinere, unabhängige Einheiten namens Frames zerlegt. Diese Frames können verschachtelt und unabhängig voneinander über die Verbindung gesendet werden. Auf der Empfängerseite werden die Frames wieder zur ursprünglichen HTTP-Nachricht zusammengesetzt.
Dieser binäre Framing-Mechanismus ist die Grundlage des Multiplexing in HTTP/2. Er ermöglicht dem Browser, mehrere Anfragen über dieselbe Verbindung zu senden, ohne in Blockierungsprobleme zu geraten. Browser wie Chrome nutzen daher dieselbe Verbindungs-ID für HTTP/2-Anfragen und ermöglichen so eine effiziente, ununterbrochene Kommunikation zwischen Client und Server.
Im Kern verbessert das Multiplexing-Feature von HTTP/2 — ermöglicht durch den binären Framing-Mechanismus — die Effizienz und Geschwindigkeit des Datenaustauschs zwischen Clients und Servern, indem es das gleichzeitige Senden mehrerer Anfragen und Antworten über eine einzige Verbindung ermöglicht.
TsgcWebSocketHTTPServer-Komponente
Um die Leistung des HTTP/2-Protokolls zu verbessern, werden Anfragen standardmäßig in einem Thread-Pool (Standard: 32) abgearbeitet, sobald der Server eine neue HTTP/2-Anfrage erhält. So werden Wartezeiten vermieden, wenn eine einzelne Verbindung viele gleichzeitige Anfragen sendet, die ohne diesen Thread-Pool sequenziell (im Kontext des Verbindungs-Threads) verarbeitet werden müssten.
Das Verhalten des PoolOfThreads kann über folgende Eigenschaften konfiguriert werden.
- HTTP2Options.PoolOfThreads.Enabled: (Standard: true) aktiviert das Abarbeiten der http/2-Anfragen im Thread-Pool statt im Verbindungs-Thread.
- HTTP2Options.Threads: (Standard: 32) die Anzahl der Threads zur Verarbeitung der HTTP/2-Anfragen. Wähle eine Zahl passend zur Anzahl der Prozessoren deines Servers.
Zum Feinjustieren der Anfragen — welche im Thread-Pool verarbeitet werden müssen (weil sie zeitaufwendig sind) und welche im Verbindungs-Thread bleiben können — kannst du das Ereignis OnHttp2BeforeAsyncRequest nutzen. Dieses Ereignis wird ausgelöst, bevor die Anfrage in den Thread-Pool eingereiht wird. Über den Parameter Async legst du fest, ob die Anfrage im Thread läuft oder nicht.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/time-consuming-request' then
ASync := False;
end;