streamalism.org

1. Áttekintés

Ebben az oktatóanyagban megismerkedhetünk a HTTP gyorsítótárával. Megvizsgáljuk a kliens és a Spring MVC alkalmazás közötti mechanizmus megvalósításának különböző módjait is.

2. A HTTP gyorsítótárának bemutatása

Amikor egy weboldalt megnyitunk egy böngészőben, az általában sok forrást tölt le a webszerverről:

Például ebben a példában egy böngészőnek három erőforrást kell letöltenie egyhez /Belépés oldalt. Gyakran előfordul, hogy a böngésző minden weboldalhoz több HTTP kérést is elküld. Ha nagyon gyakran kérünk ilyen oldalakat, az nagy hálózati forgalmat okoz, és hosszabb ideig tart ezeknek az oldalaknak a kiszolgálása.

A hálózati terhelés csökkentése érdekében a HTTP protokoll lehetővé teszi, hogy a böngészők gyorsítótárba helyezzék ezen erőforrások egy részét. Ha engedélyezve van, a böngészők az erőforrás másolatát elmenthetik a helyi gyorsítótárba. Ennek eredményeként a böngészők ezeket az oldalakat a helyi tárhelyről szolgálhatják ki ahelyett, hogy a hálózaton keresztül kérnék:

A webkiszolgáló egy a hozzáadásával utasíthatja a böngészőt egy adott erőforrás gyorsítótárába Gyorsítótár-vezérlés fejléc a válaszban.

Mivel az erőforrások helyi másolatként vannak tárolva,fennáll annak a veszélye, hogy az elavult tartalmat a böngészőből jelenítik meg. Ezért a webszerverek általában lejárati időt adnak a Gyorsítótár-vezérlés fejléc.

A következő szakaszokban hozzáadjuk ezt a fejlécet a Spring MVC vezérlő válaszában. Később a Spring API-kat is látni fogjuk, amelyek a lejárati idő alapján ellenőrzik a gyorsítótárazott erőforrásokat.

3. Gyorsítótár-vezérlés a vezérlő válaszában

3.1. Használata ResponseEntity

Ennek legegyszerűbb módja ahasználja a CacheControl építő osztály biztosította a Spring:

@GetMapping ("/ hello / {name}") @ResponseBody public ResponseEntity hello (@PathVariable String name) {CacheControl cacheControl = CacheControl.maxAge (60, TimeUnit.SECONDS) .noTransform () .mustRevalidate (); return a ResponseEntity.ok () .cacheControl (cacheControl) .body ("Hello" + név); }

Ez hozzáadja a Gyorsítótár-vezérlés fejléc a válaszban:

@Test void whenHome_thenReturnCacheHeader () Exception {this.mockMvc.perform (MockMvcRequestBuilders.get ("/ hello / baeldung")) .andDo (MockMvcResultHandlers.print ()) .andExpect (MockMvcRkes.). andExpect (MockMvcResultMatchers.header () .string ("Cache-Control", "max-age = 60, must-revalidate, no-transform")); }

3.2. Használata HttpServletResponse

Gyakran a vezérlőknek vissza kell adniuk a nézet nevét a kezelő módszerből. Azonban aResponseEntity osztály nem engedi meg, hogy egyszerre adjuk vissza a nézet nevét és foglalkozzunk a kéréstesttel.

Alternatív megoldásként az ilyen vezérlőkhöz beállíthatjuk a Gyorsítótár-vezérlés fejléc a HttpServletResponse közvetlenül:

@GetMapping (value = "/ home / {name}") public String home (@PathVariable String name, final HttpServletResponse response) {response.addHeader ("Cache-Control", "max-age = 60, must-revalidate, no -transzformáció "); hazatérni"; }

Ez hozzáadja a Gyorsítótár-vezérlés fejléc a HTTP-válaszban, hasonlóan az utolsó szakaszhoz:

@Test void whenHome_thenReturnCacheHeader () Exception {this.mockMvc.perform (MockMvcRequestBuilders.get ("/ home / baeldung")) .andDo (MockMvcResultHandlers.print ()) .andExpect (MockMvcResult). andExpect (MockMvcResultMatchers.header () .string ("Cache-Control", "max-age = 60, must-revalidate, no-transform")) .andExpect (MockMvcResultMatchers.view (). name ("home")); }

4. Gyorsítótár-vezérlés statikus erőforrásokhoz

Általában a tavaszi MVC alkalmazás sok statikus erőforrást szolgál ki, például HTML, CSS és JS fájlokat. Mivel az ilyen fájlok sok hálózati sávszélességet fogyasztanak, ezért fontos, hogy a böngészők gyorsítótárazzák őket. Ezt újra engedélyezzük a Gyorsítótár-vezérlés fejléc a válaszban.

A tavasz lehetővé teszi számunkra, hogy ellenőrizzük ezt a gyorsítótár-viselkedést az erőforrás-feltérképezés során:

@Orride public void addResourceHandlers (final ResourceHandlerRegistry registry) {register.addResourceHandler ("/ resources / **"). AddResourceLocations ("/ resources /") .setCacheControl (CacheControl.maxAge (60, TimeUnit.SECONDS) .no. mustRevalidate ()); }

Ez biztosítja, hogy minden erőforrásalatt meghatározott/erőforrások a-val térnek vissza Gyorsítótár-vezérlés fejléc a válaszban.

5. Gyorsítótár-vezérlés az interceptorokban

A tavaszi MVC alkalmazásban elfogókat használhatunk minden elő- és utófeldolgozáshoz minden kéréshez. Ez egy másik helyőrző, ahol szabályozhatjuk az alkalmazás gyorsítótár-viselkedését.

Most ahelyett, hogy egyéni elfogót használnánk, a WebContentInterceptor Spring szolgáltatta:

@Orride public void addInterceptors (InterceptorRegistry nyilvántartás) {WebContentInterceptor interceptor = új WebContentInterceptor (); interceptor.addCacheMapping (CacheControl.maxAge (60, TimeUnit.SECONDS) .noTransform () .mustRevalidate (), "/ login / *"); register.addInterceptor (elfogó); }

Itt regisztráltuk a WebContentInterceptor és hozzáadta a Gyorsítótár-vezérlés fejléc hasonló az utolsó néhány szakaszhoz. Nevezetesen különbözőeket adhatunk hozzá Gyorsítótár-vezérlés fejlécek különböző URL-mintákhoz.

A fenti példában minden, a kezdőbetűvel rendelkező kérelemhez /Belépés, hozzáadjuk ezt a fejlécet:

@Test void, amikor azInterceptor_thenReturnCacheHeader () kivételt dob ​​a {this.mockMvc.perform (MockMvcRequestBuilders.get ("/ login / baeldung")) .andDo (MockMvcResultHandlers.print ()). andExpect (MockMvcResultMatchers.header () .string ("Cache-Control", "max-age = 60, must-revalidate, no-transform")); }

6. Gyorsítótár ellenőrzése a tavaszi MVC-ben

Eddig különböző módokat vitattunk meg a Gyorsítótár-vezérlés fejléc a válaszban. Ez azt jelzi, hogy az ügyfelek vagy böngészők tárolják az erőforrásokat az olyan konfigurációs tulajdonságok alapján, mint például max-életkor.

Ez általában célszerű minden erőforráshoz hozzáadni a gyorsítótár lejárati idejét. Ennek eredményeként a böngészők elkerülhetik a lejárt erőforrások kiszolgálását a gyorsítótárból.

Bár a böngészőknek mindig ellenőrizniük kell a lejáratot, előfordulhat, hogy nem szükséges minden alkalommal újratölteni az erőforrást. Ha egy böngésző igazolni tudja, hogy egy erőforrás nem változott a kiszolgálón, akkor továbbra is kiszolgálja annak gyorsítótárazott változatát. Erre a célra a HTTP két válaszfejlécet biztosít számunkra:

1. Etag - HTTP válasz fejléc, amely egyedi kivonatértéket tárol annak megállapítására, hogy a gyorsítótárazott erőforrás megváltozott-e a szerveren - ennek megfelelő Ha-nincs-meccs a kérés fejlécének tartalmaznia kell az utolsó Etag értéket
2. Utoljára módosítva - egy HTTP válasz fejléc, amely az erőforrás utolsó frissítésének időegységét tárolja - ennek megfelelő If-Unmodified-Since a kérés fejlécében szerepelnie kell az utoljára módosított dátumnak

Ezen fejlécek bármelyikét használhatjuk annak ellenőrzésére, hogy lejárt erőforrást kell-e újból beolvasni. A fejlécek érvényesítése utána szerver vagy újból elküldheti az erőforrást, vagy pedig 304 HTTP-kódot küldhet, ami azt jelzi, hogy nincs változás. Ez utóbbi esetben a böngészők továbbra is használhatják a gyorsítótárazott erőforrást.

A Utoljára módosítva fejléc csak másodpercek pontosságát tárolhatja. Ez korlátozást jelenthet olyan esetekben, amikor rövidebb lejáratra van szükség. Ezért ajánlott használni Etag helyette. Mivel Etag a fejléc hash értéket tárol, egyedülálló kivonatot készíthet akár finomabb időközönként is, például nanoszekundumig.

Ennek ellenére nézzük meg, hogy néz ki a használata Utoljára módosítva.

A Spring néhány hasznos módszert kínál annak ellenőrzésére, hogy a kérelem tartalmaz-e lejárati fejlécet vagy sem:

@GetMapping (value = "/ productInfo / {name}") public ResponseEntity validate (@PathVariable karakterlánc neve, WebRequest kérés) {ZoneId zoneId = ZoneId.of ("GMT"); long lastModifiedTimestamp = LocalDateTime.of (2020, 02, 4, 19, 57, 45) .atZone (zoneId) .toInstant (). toEpochMilli (); if (request.checkNotModified (lastModifiedTimestamp)) {return ResponseEntity.status (304) .build (); } return ResponseEntity.ok (). body ("Hello" + név); }

A tavasz biztosítja a checkNotModified () módszer annak ellenőrzésére, hogy az erőforrás módosult-e az utolsó kérés óta:

@Test void whenValidate_thenReturnCacheHeader () Exception {HttpHeaders header = new HttpHeaders (); fejlécek.add (IF_UNMODIFIED_SINCE, "kedd, 2020. február 4., 19:57:25 GMT"); this.mockMvc.perform (MockMvcRequestBuilders.get ("/ productInfo / baeldung"). fejlécek (fejlécek)) .andDo (MockMvcResultHandlers.print ()) .andExpect (MockMvcResultMatchers.status (). is (304)); }

7. Következtetés

Ebben a cikkben a HTTP használatával tároltuk a Gyorsítótár-vezérlés válasz fejléc a Spring MVC-ben. Vagy felvehetjük a fejlécet a vezérlő válaszába a ResponseEntity osztály vagy a statikus erőforrások erőforrás-feltérképezése révén.

Ezt a fejlécet hozzáadhatjuk bizonyos URL-mintákhoz a Spring elfogók segítségével is.

Mint mindig, a kód elérhető a GitHubon.