5. tavasz és 4. Servlet - A PushBuilder

1. Bemutatkozás

A Server Push technológia - a HTTP / 2 (RFC 7540) része - lehetővé teszi számunkra, hogy a szerver felől proaktív módon küldjön erőforrásokat az ügyfélnek. Ez jelentős változás a HTTP / 1.X pull-alapú megközelítéshez képest.

A Spring 5 egyik új funkciója - a Jakarta EE 8 Servlet 4.0 API-val járó szerver push támogatás. Ebben a cikkben feltárjuk hogyan kell használni a szerver push-t és integrálni a Spring MVC vezérlőkkel.

2. Maven-függőség

Kezdjük azzal, hogy meghatározzuk azokat a függőségeket, amelyeket használni fogunk:

 org.springframework spring-webmvc 5.2.8.RELEASE javax.servlet javax.servlet-api 4.0.0 biztosított 

A spring-mvc és a servlet-api legújabb verziói a Maven Central oldalon találhatók.

3. HTTP / 2 követelmények

A szerver push használatához szükségünk lesz rá futtassa az alkalmazásunkat egy olyan tárolóban, amely támogatja a HTTP / 2-t és a Servlet 4.0 API-t. A különféle konténerek konfigurációs követelményeit itt találja, a Spring wiki-ben.

Ezenkívül megtesszük HTTP / 2 támogatásra van szüksége az ügyfél oldalon; természetesen a legtöbb jelenlegi böngésző rendelkezik ezzel a támogatással.

4. PushBuilder Jellemzők

A PushBuilder interfész felelős a szerver push végrehajtásáért. Tavaszi MVC-ben beadhatunk egy PushBuilder -vel kommentált módszerek érveléseként @RequestMapping.

Ezen a ponton fontos figyelembe venni, hogy - ha az ügyfél nem rendelkezik HTTP / 2 támogatással - a hivatkozás a következő néven lesz elküldve nulla.

Itt található a PushBuilder felület:

  • útvonal (karakterlánc útvonal) - azt az erőforrást jelzi, amelyet el fogunk küldeni
  • nyom() - elküldi az erőforrást az ügyfélnek
  • addHeader (karakterlánc neve, karakterlánc értéke) - azt a fejlécet jelöli, amelyet a letolt erőforráshoz használunk

5. Gyors példa

Az integráció bemutatásához elkészítjük a demo.jsp oldal egy erőforrással - logo.png:

     PushBuilder bemutató PushBuilder bemutató

Két végpontot is kiteszünk a PushController vezérlő - az egyik kiszolgálói push-ot használ, a másik pedig nem:

@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"; }}

A Chrome fejlesztői eszközök segítségével mindkét végpont meghívásával láthatjuk a különbségeket.

Amikor felhívjuk a demoWithoutPush módszer, a nézetet és az erőforrást az ügyfél közzéteszi és felhasználja a pull technológiával:

Amikor felhívjuk a demoWithPush módszerrel láthatjuk a push kiszolgáló használatát és azt, hogy az erőforrást hogyan szállítja előre a kiszolgáló, ami alacsonyabb betöltési időt eredményez:

A szerver push technológia számos esetben javíthatja alkalmazásai oldalainak betöltési idejét. Ennek ellenére figyelembe kell vennünk, hogy bár csökkentjük a látenciát, növelhetjük a sávszélességet - a kiszolgált erőforrások számától függően.

Célszerű kombinálni ezt a technológiát más stratégiákkal, például a gyorsítótárral, az erőforrás-csökkentéssel és a CDN-vel, valamint teljesítményteszteket futtatni alkalmazásunkon a kiszolgálói push használatához szükséges ideális végpontok meghatározásához.

6. Következtetés

Ebben a gyors bemutatóban láttunk egy példát arra, hogyan kell használni a kiszolgálói push technológiát a Spring MVC-vel a PushBuilder interfészt, és összehasonlítottuk a terhelés idejét annak használatakor a standard pull technológiával.

Mint mindig, a forráskód is elérhető a GitHubon.


$config[zx-auto] not found$config[zx-overlay] not found