Jaka jest zaleta hostowania zasobów statycznych w oddzielnej domenie?


24

Zauważyłem, że wiele witryn hostuje swoje zasoby w domenie innej niż główna, np. StackExchange za pomocą sstatic.net, Barnes & Noble za pomocą imagesbn.com itp.

Rozumiem, że umieszczenie zasobów statycznych na osobnym hoście ma wiele zalet, być może dzięki wydajnemu serwerowi plików statycznych, takim jak nginx, zwalniając główny serwer, aby mógł skupić się na udostępnianiu treści dynamicznych. Podobnie outsourcing do wspólnej sieci CDN, takiej jak chmurowa Akamai, jest logiczny.

Jakie są jednak zalety korzystania z oddzielnej domeny? Dlaczego sstatic.net zamiast static.stackexchange.com?

Aktualizacja : Kilka odpowiedzi pomija podstawowe pytanie. Rozumiem, że podział na wiele hostów ma wiele zalet - równoległe pobieranie, cieńszy serwer WWW itp. Jednak bardziej nieuchwytne jest to, dlaczego wiele domen . Dlaczego sstatic.net zamiast static.stackexchange.com jako host współdzielonych zasobów? Do tej pory tylko jedna odpowiedź rozwiązała ten problem.

Odpowiedzi:


22

Wiele witryn ma ustawionych całkiem sporo plików cookie, które mają na celu wsparcie pewnego rodzaju stanu.

Umieszczając zasoby statyczne (bezstanowe) w zupełnie innej domenie, możesz zmniejszyć rozmiar żądań HTTP. W niektórych przypadkach istnieje tak wiele plików cookie, że pojedyncze żądanie HTTP wymaga przesłania dwóch pakietów TCP. Posiadanie oddzielnej domeny jest jednym ze sposobów zmniejszenia liczby pakietów żądających różnych części strony.

Inne metody mające ten sam cel to scalanie wielu obrazów w jedną duszkę i łączenie wszystkich Javascript w jednym pliku.


23

Oprócz korzystania z sieci CDN używanie oddzielnych domen dla danych statycznych oznacza również:

  1. Możesz użyć lekkiego serwera WWW, który nie musi ładować wszystkich modułów / rozszerzeń, które serwer sieci Web z treściami dynamicznymi musi ładować przy każdym pojedynczym żądaniu. Brak konieczności skanowania każdego katalogu w ścieżce URI w celu odczytania plików .htaccess zwiększa również liczbę jednoczesnych żądań, które serwer może obsłużyć.

  2. Dodanie dodatkowej subdomeny oznacza zwiększenie liczby równoległych pobrań, które może wykonać przeglądarka.

  3. Jeśli skonfigurujesz poprawnie (np. Twoja witryna jest hostowana www.example.comzamiast example.com), możesz również skorzystać z subdomeny bez plików cookie, zmniejszając ruch i czas podróży w obie strony.

Jedynym minusem jest to, że jeśli używasz sesji SSL, potrzebujesz podpisanego certyfikatu i oddzielnego statycznego adresu IP dla dodatkowych domen. Ale w większości przypadków korzyści przeważają nad tą niewielką niedogodnością.

Edytować:

Przepraszam, źle odczytałem twoje pytanie. Jeśli zastanawiasz się, dlaczego niektóre osoby używają oddzielnych SLD, na nawias odpowiedziałby nawias nr 3. Wyjaśniono to również na stronie sstatic.net :

Jeśli Twoja domena to www.example.org, możesz hostować komponenty statyczne na static.example.org. Jeśli jednak ustawiłeś już pliki cookie w domenie najwyższego poziomu example.org w przeciwieństwie do www.example.org, wówczas wszystkie żądania do static.example.org będą zawierać te pliki cookie. W takim przypadku możesz kupić zupełnie nową domenę, hostować tam komponenty statyczne i zachować tę domenę bez plików cookie. Wieśniak! używa yimg.com, YouTube używa ytimg.com, Amazon używa images-amazon.com i tak dalej.

Ale inkarnacja wspomina także o dobrym punkcie na temat używania osobnego ogólnego SLD zamiast subdomeny istniejącego SLD, gdy prowadzisz dużą sieć witryn, które współużytkują pewne zasoby.

Wreszcie, jak zauważa Niels Basjes, jednym z powodów wyeliminowania plików cookie jest ograniczenie liczby pakietów używanych do wykonania żądania. Myślę, że wytyczne YSlow stwierdzają, że większość sieci ma maksymalny rozmiar pakietu 1500 bajtów, więc utrzymanie go poniżej 1500 bajtów zmniejszy obciążenie TCP. To także pokazuje kolejną zaletę używania sstatic.netzamiast static.webmasters.stackexchange.com.


Dlaczego potrzebujesz osobnego adresu IP?
Mihalis Bagos

2
Ponieważ szyfrowanie jest tradycyjnie stosowane przed wysłaniem nazwy domeny. SNI , który to łagodzi, nie jest jeszcze powszechnie obsługiwany - wykluczasz IE na XP.
phihag

@ Mihalis: Aby dodać do komentarza phihag, należy również wykluczyć Windows Mobile 6.5 i starszy, Android 2.x i starszy, Blackberry Browser, Safari na XP ... Pełna lista obsługiwanych / nieobsługiwanych programów można znaleźć tutaj : en.wikipedia.org/wiki/Server_Name_Indication#No_support
Lèse majesté

3
Nie pytam o to, dlaczego używać wielu subdomen - to ma dla mnie sens. Pytam o oddzielne pełne domeny. Dlaczego sstatic.net zamiast static.stackexchange.com?
Michael Ekstrand

5

Lèse majesté omówiła główne punkty, ale aby rozwinąć dalej, dodam, że posiadanie jednej domeny dla wszystkich różnych stron Stack Exchange oznacza, że ​​ktoś przeglądający je pobierze tylko zawartość statyczną, taką jak JavaScript. Na przykład przechodząc do superużytkownika, użytkownik użyje buforowanej zawartości, ponieważ pochodzi ona z tego samego miejsca.

Jest więcej przydatnych informacji na ten temat w Yahoo i Google .


5

Głównym powodem są pliki cookie. To, co zasugerował Niels w swojej odpowiedzi, to tylko niewielka konsekwencja, a nie prawdziwy powód. Bez plików cookie rozmiar żądania jest mniejszy, więc oszczędza trochę przepustowości.

Jednak prawdziwa różnica wynika z pamięci podręcznej przeglądarki. Ponieważ zawartość jest statyczna (tzn. Nie zmienia się), przeglądarki mogą buforować ją na lokalnym dysku twardym i unikać za każdym razem ładowania pliku z Internetu. Zamiast całego pliku serwer sieciowy wysyła po prostu odpowiedź 304, co oznacza, że ​​treść się nie zmieniła.

Gdy witryna korzysta z plików cookie, przeglądarki uważają, że zawartość pliku może być różna dla różnych użytkowników, więc nie buforują tych plików. Udostępnienie pliku z domeny bez plików cookie zapewnia prawidłowe buforowanie przeglądarki.

Jest to główny powód, ponieważ skraca czas ładowania i znacznie zmniejsza przepustowość.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.