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.