Aby odpowiedzieć na pytanie, dlaczego działa buforowanie, mimo że serwer WWW nie zawierał nagłówków:
- Wygasa:
[a date]
- Cache-Control: max-age =
[seconds]
Serwer uprzejmie poprosił pośredników proxy, aby nie buforowali zawartości (tj. Element powinien być przechowywany tylko w prywatnej pamięci podręcznej, tj. Tylko na własnym komputerze lokalnym):
Ale serwer zapomniał dołączyć jakichkolwiek wskazówek dotyczących buforowania:
- zapomnieli dołączyć Expires , więc przeglądarka wie, że będzie używać kopii z pamięci podręcznej do tej daty
- zapomnieli uwzględnić Max-Age , więc przeglądarka wie, jak długo buforowany element jest dobry
- zapomnieli dołączyć E-Tag , więc przeglądarka może wykonać warunkowe żądanie
Ale w odpowiedzi zawarli datę ostatniej modyfikacji :
Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT
Ponieważ przeglądarka zna datę modyfikacji pliku, może wykonać żądanie warunkowe . Poprosi serwer o plik, ale poinstruuje serwer, aby wysłał plik tylko wtedy, gdy był modyfikowany od 2012/10/16 3:13:38:
GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT
Serwer odbiera żądanie, zdaje sobie sprawę, że klient ma już najnowszą wersję. Zamiast wysyłać klienta 200 OK
, a następnie zawartość strony, zamiast tego mówi ci, że twoja buforowana wersja jest dobra:
304 Not Modified
Twoja przeglądarka musiała cierpieć z powodu opóźnienia w wysłaniu żądania do serwera i czekać na odpowiedź, ale zaoszczędziła konieczności ponownego pobierania statycznej zawartości.
Dlaczego Max-Age ? Dlaczego wygasa ?
Ponieważ Last-Modified jest do bani.
Nie wszystko na serwerze ma przypisaną datę. Jeśli tworzę stronę w locie, nie ma z tym żadnej daty - jest teraz . Ale jestem całkowicie skłonny pozwolić użytkownikowi buforować stronę główną przez 15 sekund:
200 OK
Cache-Control: max-age=15
Jeśli użytkownik uderzy F5, będzie nadal pobierał wersję z pamięci podręcznej przez 15 sekund. Jeśli jest to korporacyjny serwer proxy, wszyscy 67198 użytkowników trafiających na tę samą stronę w tym samym 15-sekundowym oknie otrzymają tę samą zawartość - wszystko obsługiwane z zamkniętej pamięci podręcznej. Wydajność wygrywa dla każdego.
Zaletą dodawania Cache-Control: max-age
jest to, że przeglądarka nie musi nawet wykonywać warunkowego żądania.
- jeśli podałeś tylko
Last-Modified
, przeglądarka musi wykonać żądanie If-Modified-Since
i czekać na 304 Not Modified
odpowiedź
- jeśli to określiłeś
max-age
, przeglądarka nie będzie musiała nawet cierpieć w obie strony sieci; zawartość wyjdzie prosto z pamięci podręcznych
Różnica między „Cache-Control: max-age” a „Expires”
Expires
jest starszym odpowiednikiem nowoczesnego (ok. 1998) Cache-Control: max-age
nagłówka:
Expires
: określasz datę (fuj)
max-age
: określasz sekundy (dobroć)
Jeśli oba są określone, przeglądarka używa max-age
:
200 OK
Cache-Control: max-age=60
Expires: 20180403T192837
Żadna witryna internetowa napisana po 1998 roku nie powinna Expires
już używać , a zamiast tego używać max-age
.
Co to jest ETag?
ETag jest podobny do Last-Modified , z tym wyjątkiem, że nie musi to być data - po prostu musi być czymś .
Jeśli rowversion
wyciągam listę produktów z bazy danych, serwer może wysłać ostatni jako ETag, a nie datę:
200 OK
ETag: "247986"
Mój ETag może być hashem SHA1 zasobu statycznego (np. Obraz, js, css, czcionka) lub strony wyrenderowanej w pamięci podręcznej (tj. To właśnie robi wiki Mozilla MDN; haszuje ostateczny znacznik):
200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
I dokładnie tak, jak w przypadku żądania warunkowego opartego na Last-Modified :
GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT
304 Not Modified
Mogę wykonać warunkowe żądanie na podstawie ETag:
GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
304 Not Modified
An ETag
jest lepszy od, Last-Modified
ponieważ działa w przypadku rzeczy innych niż pliki lub rzeczy, które mają pojęcie daty . Po prostu jest