Feder 5 und Servlet 4 - Der PushBuilder

1. Einleitung

Die Server Push-Technologie - Teil von HTTP / 2 (RFC 7540) - ermöglicht es uns, Ressourcen proaktiv von der Serverseite an den Client zu senden. Dies ist eine wesentliche Änderung gegenüber dem Pull-basierten HTTP / 1.X-Ansatz.

Eine der neuen Funktionen von Spring 5 ist die Server-Push-Unterstützung, die mit der Jakarta EE 8 Servlet 4.0-API geliefert wird. In diesem Artikel erfahren Sie, wie Sie Server-Push verwenden und in Spring MVC-Controller integrieren .

2. Maven-Abhängigkeit

Beginnen wir mit der Definition der Abhängigkeiten, die wir verwenden werden:

 org.springframework spring-webmvc 5.2.8.RELEASE   javax.servlet javax.servlet-api 4.0.0 provided 

Die neuesten Versionen von spring-mvc und servlet-api finden Sie auf Maven Central.

3. HTTP / 2-Anforderungen

Um Server-Push verwenden zu können, müssen wir unsere Anwendung in einem Container ausführen, der HTTP / 2 und die Servlet 4.0-API unterstützt . Die Konfigurationsanforderungen für verschiedene Container finden Sie hier im Spring-Wiki.

Darüber hinaus benötigen wir auf der Clientseite HTTP / 2-Unterstützung . Natürlich haben die meisten aktuellen Browser diese Unterstützung.

4. PushBuilder- Funktionen

Die PushBuilder- Schnittstelle ist für die Implementierung des Server-Push verantwortlich. In Spring MVC können wir einen PushBuilder als Argument für die mit @RequestMapping annotierten Methoden einfügen .

An dieser Stelle ist es wichtig zu berücksichtigen, dass - wenn der Client keine HTTP / 2-Unterstützung hat - die Referenz als null gesendet wird .

Hier ist die Kern-API, die von der PushBuilder- Oberfläche angeboten wird :

  • path (String path) - Gibt die Ressource an, die gesendet werden soll
  • push () - sendet die Ressource an den Client
  • addHeader (String name, String value) - Gibt den Header an, den wir für die Push-Ressource verwenden

5. Kurzes Beispiel

Um die Integration zu demonstrieren, erstellen wir die Seite demo.jsp mit einer Ressource - logo.png :

     PushBuilder demo   PushBuilder demo

Wir werden auch zwei Endpunkte mit dem PushController- Controller verfügbar machen - einen, der Server-Push verwendet, und einen, der dies nicht tut:

@Controller public class PushController { @GetMapping(path = "/demoWithPush") public String demoWithPush(PushBuilder pushBuilder) { if (null != pushBuilder) { pushBuilder.path("resources/logo.png").push(); } return "demo"; } @GetMapping(path = "/demoWithoutPush") public String demoWithoutPush() { return "demo"; } }

Mit den Chrome-Entwicklungstools können wir die Unterschiede erkennen, indem wir beide Endpunkte aufrufen.

Wenn wir die demoWithoutPush- Methode aufrufen , werden die Ansicht und die Ressource vom Client mithilfe der Pull-Technologie veröffentlicht und verwendet:

Wenn wir die demoWithPush- Methode aufrufen , können wir die Verwendung des Push-Servers und die vorherige Bereitstellung der Ressource durch den Server sehen, was zu einer geringeren Ladezeit führt:

Die Server-Push-Technologie kann in vielen Szenarien die Ladezeit der Seiten unserer Anwendungen verbessern. Abgesehen davon müssen wir berücksichtigen, dass wir, obwohl wir die Latenz verringern, die Bandbreite erhöhen können - abhängig von der Anzahl der Ressourcen, die wir bedienen.

Es ist auch eine gute Idee, diese Technologie mit anderen Strategien wie Caching, Ressourcenminimierung und CDN zu kombinieren und Leistungstests für unsere Anwendung durchzuführen, um die idealen Endpunkte für die Verwendung von Server-Push zu ermitteln.

6. Fazit

In diesem kurzen Tutorial haben wir ein Beispiel für die Verwendung der Server-Push-Technologie mit Spring MVC unter Verwendung der PushBuilder- Oberfläche gesehen und die Ladezeiten bei Verwendung mit der Standard-Pull-Technologie verglichen.

Wie immer ist der Quellcode über GitHub verfügbar.