Czy warto zmienić całą strukturę plików obrazów użytkownika, aby skorzystać z prostego buforowania przeglądarki?

Na jednej z moich witryn mobilnych po prostu przechowuję zdjęcia profilu mojego użytkownika jako „1.jpg” w folderze użytkownika i stopniowo stamtąd przechodzę do dodatkowych przesyłanych zdjęć. Oznacza to, że za każdym razem, gdy zmieniają swoje zdjęcie profilowe, nazwa pliku pozostaje taka sama.

Chciałem skorzystać z buforowania obrazów, aby to samo stare zdjęcie nie było pobierane raz za razem, gdy profil użytkownika jest przeglądany i ponownie przeglądany, ale jednocześnie chcę, aby przeglądarki moich użytkowników pobierz nowy, jeśli się zmienił.

Z tego, co czytałem, wydaje się, że jedynym sposobem, aby to naprawdę zrobić, jest użycie losowych nazw plików i śledzenie wszystkich tych nazw plików w bazie danych, abyś mógł niedawno ustawić pamięć podręczną, która nie wygasa -zmienione zdjęcia są ponownie pobierane, ponieważ mają nową nazwę pliku. Piękno sposobu, w jaki do tej pory je tworzyłem, polega na tym, że mogę całkowicie pominąć bazę danych i uzyskać bezpośredni dostęp do plików, ponieważ ich lokalizacja jest przewidywalna.

Moje pytanie brzmi więc, czy warto zmienić całą strukturę plików mojej witryny, a także dodać element DB, aby skorzystać z wiecznego buforowania i automatycznego ponownego pobierania po nowym przesyłaniu?

To ogromne przedsięwzięcie, ale jeśli zostanie uznane za godne, nie mam problemu z tą drastyczną zmianą. Chcę tylko upewnić się, że tak robią „duzi chłopcy”, żebym nigdy więcej nie musiał zmieniać struktury plików.

Dzięki.

Jednym z często używanych rozwiązań jest nadanie adresom URL obrazów obrazu mniej więcej takiego:

http://www.example.com/path/to/images/1.jpg?v=123456

Oto /path/to/images/1.jpgrzeczywista ścieżka adresu URL obrazu, podczas gdy ?v=123456jest to tylko fikcyjne zapytanie przypięte na końcu adresu URL. Ciąg zapytania może być dowolny - numerem wersji, znacznikiem czasu, skrótem zawartości obrazu - pod warunkiem, że zmienisz go za każdym razem, gdy zmieni się obraz, i nie zmienisz go.

Sztuczka polega na tym, że serwer WWW, gdy zostanie poproszony o podanie takiego adresu URL, zignoruje ciąg zapytania, ponieważ w rzeczywistości adres URL wskazuje plik statyczny. Ale dla przeglądarki użytkownika (i dla wszystkich pośredniczących serwerów pośredniczących) adresy URL z różnymi ciągami zapytań będą zupełnie inne, więc każda zmiana ciągu zapytania zmusi przeglądarkę do ponownego załadowania pliku.

W ten sposób możesz skonfigurować serwer WWW do wysyłania Expiresi Cache-Controlnagłówki HTTP, aby umożliwić nieograniczone buforowanie, wiedząc, że możesz wymusić przeładowanie poprzez zmianę ciągu zapytania. Jednym ze sposobów na to, jeśli używasz Apache z mod_expires , jest umieszczenie .htaccesspliku w katalogu obrazów z liniami:

ExpiresActive On
ExpiresDefault "access plus 1 year"

Z tej techniki korzysta wiele popularnych stron internetowych. Na przykład, jeśli spojrzysz na źródło HTML tej samej strony, przekonasz się, że arkusz stylów jest ładowany z adresu URL takiego:

http://cdn.sstatic.net/stackoverflow/all.css?v=7cd8ea9d6f1e

Oto ?v=7cd8ea9d6f1efikcyjny ciąg zapytania, tak jak opisałem powyżej; możesz to potwierdzić, zmieniając go i widząc, że rzeczywiście nadal zwraca ten sam plik.

Jest więcej niż jeden sposób na buforowanie.

Warunkowe GET

Jeśli przechowujesz te obrazy w systemie plików i podajesz je bezpośrednio przez serwer WWW, prawdopodobnie używasz już warunkowego pobierania . Serwer WWW automatycznie użyje metadanych systemu plików, aby ustawić nagłówek ETAG, i automatycznie odpowie „304 bez modyfikacji”, jeśli przeglądarka uwzględni If-Modified-Sincelub If-Matchesnagłówki w swoim żądaniu. (Wszystkie przeglądarki będą.)

W takim przypadku cały obraz nie jest dostarczany z powrotem, więc masz oszczędności na przepustowości. Jednak żądanie GET będzie nadal wysyłane, więc nadal będziesz mieć narzut i opóźnienie żądania.

Możesz nieznacznie zmniejszyć liczbę żądań kosztem świeżości pamięci podręcznej, ustawiając Cache-Controlnagłówki z public,max-age=Nwartością dla twoich obrazów. Oznacza to, że pamięci podręczne mogą przechowywać zasób przez co najmniej max-agesekundy, zanim będą musiały sprawdzić, czy jest on zaktualizowany.

Jednak HTTP definiuje tylko jeden sposób unieważnienia pozycji pamięci podręcznej, co może nie pasować do semantyki aplikacji: jeśli POST lub PUT na adres URL, który aktualizuje zdjęcie profilowe, odpowiedz Location: [url of photo]nagłówkiem, a pozycja pamięci podręcznej dla tego adresu URL zostanie unieważniona.

(Jest to mechanizm, który pozwala buforować stronę z komentarzami, a następnie mieć przeładować stronę przymusowo przez przeglądarkę po postów użytkownika nowy komentarz. Przeglądarka będzie odpowiedzieć na POST /commentz 303 See Othera Location: /page/with/commentZauważ, że to nie wykorzystane. pracować w przeglądarce Firefox z powodu długotrwałego błędu ).

Jeśli nie masz dużego ruchu, to podejście do buforowania jest w porządku.

Zmiana adresów URL

Adres URL jest reprezentacją zasobu, więc innym sposobem zarządzania buforowaniem nie jest zmiana parametrów pamięci podręcznej dla zasobu, ale utworzenie zupełnie nowego zasobu z dyrektywą „buforuj na zawsze”. Takie podejście preferują „duzi chłopcy”, ponieważ pozwala im nie generować żadnych dodatkowych żądań, oszczędzając im dużą przepustowość. Minusem jest to, że wymaga znacznie więcej dodatkowej księgowości.

Są na to dwie ogólne techniki.

Ciągi zapytań

Serwery WWW ignorują ciągi zapytań podczas udostępniania pliku z systemu plików. Bufory, jednak nie należy: /1.jpg?t=12345a /1.jpg?t=67890to dwie zupełnie różne, niezwiązane zasoby, chociaż serwer myśli, że są takie same.

Tak więc jedną łatwą rzeczą jest dodanie znacznika czasu systemu plików jako ciągu zapytania za każdym razem, gdy odwołujesz się do zasobu w html i ustawiasz długi Expiresnagłówek. Przeglądarka będzie wówczas buforować ten zasób na zawsze i nie będzie wykonywać żadnych GET, dopóki ciąg zapytania nie ulegnie zmianie.

Minusem jest to, że trudne lub niemożliwe jest poinstruowanie serwera WWW o nowym adresie URL elementu, jeśli chcesz siłą unieważnić pamięć podręczną. Na przykład, jeśli przeglądarka ma buforowaną stronę HTML z /1.jpg?v=1odnośnikiem, ale zdarzyło się wyczyścić wpis dla /1.jpg?v=1(być może zabrakło miejsca na plik lub pamięć), wysyła nowe żądanie /1.jpg?v=1. Jeśli w międzyczasie obraz się zmienił /1.jpg?v=2, poprawną odpowiedzią jest:

1. Podaj starą wersję pliku. Zrobiłbyś to, gdybyś chciał, aby wszystkie zasoby były ze sobą spójne, tak jak były w pewnym momencie. Oto co powinieneś zrobić z plikami CSS, ponieważ nowy plik css ze starym plikiem HTML może nie działać poprawnie!
2. Przekieruj do nowej wersji pliku za pomocą 301 Moved Permanently. Zrobiłbyś to, jeśli chcesz, aby wszystkie zasoby były jak nowe.

Oba są trudne do wykonania z samym serwerem WWW, co oznacza, że ​​musisz wywołać aplikację internetową nawet w przypadku żądań obrazu, które mogą być zarówno bardziej skomplikowane, jak i bardziej wymagające zasobów. Serwery WWW bardzo szybko obsługują pliki, więc obciążenie aplikacji internetowej może w efekcie połknąć przyrost przepustowości i opóźnień.

Nazwy plików

Zamiast dodawać ciąg zapytania, zmieniasz nazwę pliku. Oznacza to, że łatwo jest przechowywać wiele wersji plików w systemie plików, ale prawdopodobnie będziesz musiał przechowywać metadane plików i wykonywać inne księgowanie bazy danych, aby śledzić zasoby i ich nazwy.

czytając o statusie http 304 Not Modified, powinieneś być w stanie odpowiedzieć na żądanie pobierania za pomocą 304, a tym samym powiedzieć serwerowi, aby używał buforowanych danych, zamiast wysyłania ich ponownie do przeglądarki. i przeczytaj to pytanie /programming/2978496/make-php-page-return-304-not-modified-if-it-hasnt-been-modified