Sehen Sie unten die Unterschiede zwischen HTTP 1.1 und HTTP 2.0:
Im traditionellen HTTP-Verhalten muss der Client beim Stellen mehrerer Anfragen über dieselbe Verbindung auf die Antwort jeder Anfrage warten, bevor er die nächste sendet. Dieser sequenzielle Ansatz erhöht die Ladezeit der Ressourcen einer Website erheblich. Um dieses Problem zu lösen, führte HTTP/1.1 eine Funktion namens Pipelining ein, die es einem Client ermöglicht, mehrere Anfragen zu senden, ohne auf die Antworten des Servers zu warten. Der Server wiederum antwortet dem Client in derselben Reihenfolge, in der er die Anfragen empfangen hat.
Während Pipelining als Lösung erschien, war es mit Herausforderungen konfrontiert:
In dem Bemühen, das Laden von Seiten von Servern, die HTTP/1.1 unterstützen, zu optimieren, implementierten Webbrowser einen Workaround. Sie öffnen sechs bis acht parallele Verbindungen zum Server, was die gleichzeitige Übertragung mehrerer Anfragen ermöglicht. Diese Parallelität zielt darauf ab, die mit Pipelining verbundenen Probleme zu mildern und die Gesamtladezeiten der Seite zu verbessern.
Die Wahl von sechs bis acht parallelen Verbindungen durch Webbrowser basiert auf Optimierungsüberlegungen. Die spezifischen Gründe für die Wahl dieser Zahl können einen Kompromiss zwischen Ressourcennutzung, Netzwerkeffizienz und der Vermeidung potenzieller Engpässe beinhalten.
Als Reaktion auf die beim Pipelining aufgetretenen Einschränkungen führte HTTP/2 eine Funktion namens Multiplexing ein. Multiplexing ermöglicht eine effizientere Kommunikation zwischen Client und Server, indem die gleichzeitige Übertragung von mehreren Anfragen und Antworten über eine einzige Verbindung ermöglicht wird.
HTTP/2 nutzt einen binären Framing-Mechanismus, was bedeutet, dass HTTP-Nachrichten in kleinere, unabhängige Einheiten namens Frames zerlegt werden. Diese Frames können verschachtelt und unabhängig voneinander über die Verbindung gesendet werden. Am empfangenden Ende werden die Frames wieder zusammengesetzt, um die ursprüngliche HTTP-Nachricht zu rekonstruieren.
Dieser binäre Framing-Mechanismus ist grundlegend, um Multiplexing in HTTP/2 zu erreichen. Er ermöglicht es dem Browser, mehrere Anfragen über dieselbe Verbindung zu senden, ohne auf Blocking-Probleme zu stoßen. Folglich verwenden Browser wie Chrome dieselbe Verbindungs-ID für HTTP/2-Anfragen, was eine effiziente und unterbrechungsfreie Kommunikation zwischen Client und Server ermöglicht.
Im Wesentlichen verbessert die Multiplexing-Funktion von HTTP/2, die durch den binären Framing-Mechanismus ermöglicht wird, die Effizienz und Geschwindigkeit des Datenaustauschs zwischen Clients und Servern, indem sie die gleichzeitige Übertragung mehrerer Requests und Responses über eine einzige Verbindung erleichtert.
Um die Leistung des HTTP/2-Protokolls zu verbessern, werden die Anfragen standardmäßig in einem Thread-Pool (standardmäßig 32) dispatcht, jedes Mal wenn eine neue HTTP/2-Anfrage vom Server empfangen wird. Dies vermeidet Wartezeiten, wenn eine einzelne Verbindung viele gleichzeitige Anfragen sendet, die ohne diesen Thread-Pool eine sequenzielle Verarbeitung (im Kontext des Verbindungs-Threads) erfordern würden.
Das Verhalten des Thread-Pools kann mit den folgenden Eigenschaften konfiguriert werden.
Um die Anfragen feinabzustimmen und auszuwählen, welche Anfragen im Thread-Pool verarbeitet werden müssen (weil sie zeitaufwendig sind), während andere im Verbindungsthread verarbeitet werden können, können Sie das Ereignis OnHttp2BeforeAsyncRequest verwenden. Dieses Ereignis wird ausgelöst, bevor die Anfrage in den Thread-Pool eingereiht wird. Verwenden Sie den Parameter Async , um festzulegen, ob die Anfrage threaded ist oder nicht.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/fast-request' then
ASync := False;
end;