Jaka jest różnica między kodem stanu HTTP 200 (pamięć podręczna) a kodem stanu 304?

Korzystam z wtyczki Google „Page Speed” dla przeglądarki Firefox, aby uzyskać dostęp do mojej witryny.

Niektóre składniki na mojej stronie są oznaczone statusem HTTP:

200 200 (pamięć podręczna) 304

Według „Szybkości strony” Google.

To, co mnie myli, to różnica między 200 (pamięć podręczna) a 304.

Odświeżyłem stronę wiele razy (ale nie wyczyściłem pamięci podręcznej) i zawsze wydaje się, że mój favicon.ico i kilka obrazów ma status = 200 (pamięć podręczna), podczas gdy niektóre inne obrazy mają status http 304.

Nie rozumiem, dlaczego różnica.

AKTUALIZACJA :

Korzystając z Google „Page Speed”, otrzymuję „200 (pamięć podręczna)” dla http://example.com/favicon.ico, a także http://cdn.example.com/js/ga.js

Ale otrzymuję status http „304” dla http://cdn.example.com/js/combined.min.js

Nie rozumiem, dlaczego mam dwa pliki JavaScript znajdujące się w tym samym katalogu / js /, jeden zwraca status HTTP 304, a drugi kod stanu 200 (pamięć podręczna).

Elementy o kodzie „200 (pamięć podręczna)” zostały wypełnione bezpośrednio z pamięci podręcznej przeglądarki, co oznacza, że ​​oryginalne żądania dotyczące elementów zostały zwrócone z nagłówkami wskazującymi, że przeglądarka może je buforować (np. Datą przyszłą Expireslub Cache-Control: max-agenagłówkami) i że na Po uruchomieniu nowego żądania te buforowane obiekty były nadal przechowywane w lokalnej pamięci podręcznej i jeszcze nie wygasły.

Z drugiej strony, 304s są odpowiedzią serwera po sprawdzeniu przez przeglądarkę, czy plik został zmodyfikowany od czasu ostatniej buforowanej wersji (odpowiedź brzmi „nie”).

Aby uzyskać najbardziej optymalną wydajność sieci, najlepiej jest ustawić daleką przyszłość Expires:lub Cache-Control: max-agenagłówek dla wszystkich zasobów, a następnie, gdy trzeba zmienić zasób, zmienić rzeczywistą nazwę pliku zasobu lub dołączyć ciąg wersji do żądań tego zasobu. Eliminuje to potrzebę dokonywania jakichkolwiek żądań, chyba że zasób zdecydowanie zmienił się z wersji w pamięci podręcznej (nie ma potrzeby tej odpowiedzi 304). Google ma więcej informacji na temat prawidłowego korzystania z długoterminowego buforowania .

200 (pamięć podręczna) oznacza, że ​​Firefox po prostu używa wersji buforowanej lokalnie. Jest to najszybszy, ponieważ nie jest wysyłane żadne żądanie do serwera WWW.

304 oznacza, że ​​Firefox wysyła warunkowe żądanie „Jeśli-Zmodyfikowane-Od” do serwera WWW. Jeśli plik nie został zaktualizowany od daty wysłanej przez przeglądarkę, serwer internetowy zwraca odpowiedź 304, która zasadniczo mówi Firefoksowi, aby użył swojej wersji buforowanej. Nie jest tak szybki jak 200 (pamięć podręczna), ponieważ żądanie jest nadal wysyłane do serwera sieci Web, ale serwer nie musi wysyłać zawartości pliku.

Do twojego ostatniego pytania nie wiem, dlaczego dwa pliki JavaScript w tym samym katalogu zwracają różne wyniki.

To też rzuciło mnie na długi czas. Pierwszą rzeczą, którą zweryfikuję, jest to, że nie przeładowujesz strony, klikając przycisk odświeżania, który zawsze spowoduje warunkowe żądanie zasobów i zwróci 304 dla wielu elementów strony. Zamiast tego przejdź do paska adresu, wybierz stronę i naciśnij Enter, jakbyś właśnie wpisał ten sam adres URL, co da ci lepszy wskaźnik tego, co jest właściwie buforowane. W tym artykule świetnie się spisuje, wyjaśniając różnicę między żądaniami warunkowymi i bezwarunkowymi oraz sposób, w jaki wpływa na nich przycisk odświeżania: http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about- warunkowe-http-żądania-i-przycisk-odświeżania.aspx

HTTP 304 jest „niezmodyfikowany”. Twój serwer internetowy zasadniczo informuje przeglądarkę „ten plik nie zmienił się od czasu ostatniego żądania”. Podczas gdy HTTP 200 mówi przeglądarce, że „tutaj jest skuteczna odpowiedź” - która powinna zostać zwrócona, gdy przeglądarka uzyskuje dostęp do pliku po raz pierwszy lub po raz pierwszy uzyskuje dostęp do zmodyfikowanej kopii.

Aby uzyskać więcej informacji na temat kodów stanu, odwiedź http://en.wikipedia.org/wiki/List_of_HTTP_status_codes .

Na twoje ostatnie pytanie, dlaczego? Spróbuję wyjaśnić to, co wiem

Krótkie wyjaśnienie tych trzech kodów statusu w kategoriach laika.

• 200 - sukces (żądania przeglądarki i pobranie pliku z serwera)

Jeśli buforowanie jest włączone na serwerze

• 200 (z pamięci podręcznej) - plik znaleziony w przeglądarce, więc przeglądarka nie wysyła żądania z serwera
• 304 - przeglądarka żąda pliku, ale jest odrzucany przez serwer

W przypadku niektórych plików przeglądarka decyduje się na żądanie z serwera, a dla niektórych decyduje się na odczyt z zapisanych (buforowanych) plików. Dlaczego to ? Każdy plik ma datę ważności, więc

Jeśli plik nie wygasł, przeglądarka będzie korzystać z pamięci podręcznej (200 pamięci podręcznej).

Jeśli plik wygasł, przeglądarka żąda serwera pliku. Plik kontrolny serwera w obu miejscach (przeglądarka i serwer). Jeśli znaleziono ten sam plik, serwer odrzuca żądanie. Zgodnie z protokołem przeglądarka wykorzystuje istniejący plik.

spójrz na tę konfigurację nginx

location / {
    add_header Cache-Control must-revalidate;
    expires     60;
    etag on;

    ...
}

Tutaj wygaśnięcie jest ustawione na 60 sekund, więc wszystkie pliki statyczne są buforowane przez 60 sekund. Więc jeśli poprosisz o plik ponownie w ciągu 60 sekund, przeglądarka odczyta z pamięci (200 pamięci). Jeśli poprosisz po 60 sekundach, przeglądarka zażąda serwera (304).

Zakładałem, że plik nie zostanie zmieniony po 60 sekundach, w takim przypadku otrzymasz 200 (tzn. Zaktualizowany plik zostanie pobrany z serwera).

Tak więc, jeśli serwery są skonfigurowane z różnymi wygasającymi i buforującymi nagłówkami (politykami), stan może się różnić.

W twoim przypadku używasz cdn, głównym celem cdn jest wysoka dostępność i szybka dostawa. Dlatego używają wielu serwerów. Chociaż wygląda na to, że pliki znajdują się w tym samym katalogu, cdn może używać wielu serwerów do udostępniania treści, jeśli serwery te mają różne konfiguracje. Następnie te statusy mogą ulec zmianie. Mam nadzieję, że to pomoże.