streamalism.org

1. Inleiding

De Server Push-technologie - onderdeel van HTTP / 2 (RFC 7540) - stelt ons in staat om proactief bronnen naar de client te sturen vanaf de server. Dit is een grote verandering ten opzichte van de op HTTP / 1.X pull gebaseerde benadering.

Een van de nieuwe functies die Spring 5 met zich meebrengt, is de server-push-ondersteuning die wordt geleverd met Jakarta EE 8 Servlet 4.0 API. In dit artikel gaan we verkennen hoe u server push gebruikt en integreert met Spring MVC-controllers.

2. Maven Afhankelijkheid

Laten we beginnen met het definiëren van de afhankelijkheden die we gaan gebruiken:

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

De meest recente versies van spring-mvc en servlet-api zijn te vinden op Maven Central.

3. HTTP / 2-vereisten

Om server-push te gebruiken, moeten we dat doen voer onze applicatie uit in een container die HTTP / 2 en de Servlet 4.0 API ondersteunt. Configuratievereisten van verschillende containers zijn hier te vinden, in de Spring-wiki.

Bovendien zullen we hebben HTTP / 2-ondersteuning nodig aan de clientzijde; Natuurlijk hebben de meeste huidige browsers deze ondersteuning.

4. PushBuilder Kenmerken

De PushBuilder interface is verantwoordelijk voor het implementeren van server push. In Spring MVC kunnen we een PushBuilder als argument van de methoden geannoteerd met @RequestMapping.

Op dit punt is het belangrijk om te bedenken dat - als de client geen HTTP / 2-ondersteuning heeft, wordt de referentie verzonden als nul.

Hier is de kern-API die wordt aangeboden door de PushBuilder koppel:

• pad (tekenreekspad) - geeft de bron aan die we gaan verzenden
• Duwen() - stuurt de bron naar de klant
• addHeader (String naam, String waarde) - geeft de koptekst aan die we zullen gebruiken voor de gepushte bron

5. Snel voorbeeld

Om de integratie te demonstreren, maken we het demo.jsp pagina met één bron - logo.png:

     PushBuilder-demo PushBuilder-demo

We zullen ook twee eindpunten blootleggen met de PushController controller - een die server push gebruikt en een andere die niet:

@Controller openbare klasse PushController {@GetMapping (path = "/ demoWithPush") openbare String demoWithPush (PushBuilder pushBuilder) {if (null! = PushBuilder) {pushBuilder.path ("resources / logo.png"). Push (); } retourneer "demo"; } @GetMapping (path = "/ demoWithoutPush") openbare String demoWithoutPush () {retourneer "demo"; }}

Met behulp van de Chrome Development-tools kunnen we de verschillen zien door beide eindpunten aan te roepen.

Als we de demoWithoutPush methode, worden de weergave en de bron gepubliceerd en verbruikt door de klant met behulp van de pull-technologie:

Als we de demoWithPush methode, kunnen we het gebruik van de push-server zien en hoe de bron van tevoren door de server wordt geleverd, wat resulteert in een lagere laadtijd:

De server-push-technologie kan de laadtijd van de pagina's van onze applicaties in veel scenario's verbeteren. Dat gezegd hebbende, moeten we er rekening mee houden dat, hoewel we de latentie verminderen, we de bandbreedte kunnen vergroten - afhankelijk van het aantal bronnen dat we bedienen.

Het is ook een goed idee om deze technologie te combineren met andere strategieën, zoals Caching, Resource Minification en CDN, en om prestatietests uit te voeren op onze applicatie om de ideale eindpunten te bepalen voor het gebruik van server-push.

6. Conclusie

In deze korte zelfstudie hebben we een voorbeeld gezien van hoe u de serverpush-technologie met Spring MVC kunt gebruiken met behulp van de PushBuilder interface, en we vergeleken de laadtijden bij gebruik met de standaard pull-technologie.

Zoals altijd is de broncode beschikbaar op GitHub.