Statik kaynakları ayrı bir alanda barındırmanın avantajı nedir?


24

Bir çok sitenin kaynaklarını ana siteden ayrı bir alanda barındırdığını fark ettim, örneğin, sstatic.net kullanarak StackExchange, imagesbn.com kullanarak Barnes & Noble vb.

Statik kaynaklarınızı, muhtemelen nginx gibi verimli bir statik dosya web sunucusuyla, ana sunucuyu dinamik içerik sunmaya odaklanmak için serbest bırakarak, ayrı bir ana bilgisayara yerleştirmenin faydaları olduğunu biliyorum. Benzer şekilde, cloudfront Akamai gibi paylaşılan bir CDN'ye dış kaynak sağlamak mantıklıdır.

Yine de ayrı bir alan kullanmanın faydası nedir? Neden static.stackexchange.com yerine sstatic.net?

Güncelleme : Birkaç cevap temel soruyu özlüyor. Paralel yüklemeler, ince web sunucusu, vb Ama ne daha zor olmasının nedeni katıdır - Birden konaklar arasında bölünmesine yarar olduğunu anlamak alanlar . Neden paylaşılan kaynaklar için ana bilgisayar olarak static.stackexchange.com yerine sstatic.net? Şimdiye kadar sadece bir cevap buna değindi.

Yanıtlar:


22

Birçok sitenin oldukça fazla çerez seti vardır, bu çerezlerin bir tür durumu destekleme amacı vardır.

Statik (durumsuz) kaynakları tamamen farklı bir alana koyarak, http isteklerinin boyutunu azaltabilirsiniz. Bazı durumlarda, tek bir http isteğinin aktarılması için iki TCP paketi aldığı çok fazla çerez vardır. Dolayısıyla, ayrı bir etki alanına sahip olmak, sayfanın çeşitli bölümlerini istemek için paket sayısını azaltmanın yollarından biridir.

Aynı amacı taşıyan diğer yöntemler, çok sayıda görüntüyü tek bir hareketli grafikte birleştirmek ve tüm Javascript'i tek bir dosyada birleştirmek.


23

CDN kullanımının yanı sıra, statik veriler için ayrı alan adlarının kullanılması da şu anlama gelir:

  1. Dinamik içerik web sunucunuzun her bir istek üzerine yüklemesi gereken tüm modülleri / uzantıları yüklemesi gerekmeyen hafif bir web sunucusu kullanabilirsiniz. .Htaccess dosyalarını okumak için URI yolundaki her dizini taramak zorunda olmamak aynı zamanda sunucunun işleyebileceği eşzamanlı istek sayısını da artırır.

  2. Fazladan bir alt etki alanı eklemek, tarayıcının gerçekleştirebileceği paralel indirme sayısını artırmanız anlamına gelir.

  3. Düzgün kurulursa (örneğin siteniz www.example.comyerine barındırılıyorsa example.com), aynı zamanda cookieless bir alt alan adından da yararlanarak trafiği ve gidiş dönüş sürelerini azaltabilirsiniz.

Tek dezavantajı, eğer SSL oturumları kullanıyorsanız, ek alan (lar) için imzalı bir sertifikaya ve ayrı bir statik IP'ye ihtiyacınız var. Ancak, faydalar çoğu durumda bu küçük rahatsızlıktan daha ağır basmaktadır.

Düzenle:

Üzgünüm, sorunuzu yanlış anladım. Neden bazı kişilerin ayrı SLD'ler kullandığını soruyorsanız, bu parantezin # 3 üzerindeki cevabını verir. Ayrıca sstatic.net'te açıklanmıştır :

Etki alanınız www.example.org ise, statik bileşenlerinizi static.example.org sitesinde barındırabilirsiniz. Bununla birlikte, www.example.org adresinin aksine example.org üst düzey alanındaki example çerezleri ayarladıysanız, static.example.org adresine yapılan tüm istekler bu çerezleri içerecektir. Bu durumda, yepyeni bir alan adı satın alabilir, statik bileşenlerinizi orada barındırabilir ve bu alan adının çerezsiz kalmasını sağlayabilirsiniz. Yahoo! yimg.com, YouTube ytimg.com, Amazon ise images-amazon.com vb. kullanıyor.

Ancak, enkarne, belirli varlıkları paylaşan geniş bir site ağı çalıştırırken, mevcut bir SLD'nin alt alanı yerine ayrı bir genel SLD kullanma konusunda da iyi bir noktaya değinmektedir.

Son olarak, Niels Basjes'in belirttiği gibi, çerezleri ortadan kaldırmanın sebeplerinden biri bir talebi gerçekleştirmek için kullanılan paket sayısını en aza indirmektir. YSlow yönergelerinin çoğu ağın maksimum paket büyüklüğünde 1500 bayt olduğunu, bu nedenle 1500 baytın altında tutulmasının TCP ek yükünü azaltacağını düşünüyorum. Bu aynı zamanda kullanım sstatic.netyerine başka bir avantaj gösterir static.webmasters.stackexchange.com.


Neden ayrı bir IP'ye ihtiyacınız var?
Mihalis Bagos

2
Şifreleme, etki alanı adı gönderilmeden önce geleneksel olarak uygulandığından. Bunu hafifleten SNI henüz evrensel olarak desteklenmiyor - IE’de XP’yi hariç tutuyorsunuz.
phihag

@Mihalis: Sadece phihag'ın yorumuna eklemek için, Windows Mobile 6.5 ve daha üstü, Android 2.x ve üstü, Blackberry Browser, XP'de Safari hariç tutulacaktı ... Desteklenen / desteklenmeyen yazılımların tam listesi burada bulunabilir : en.wikipedia.org/wiki/Server_Name_Indication#No_support
Lèse majesté

3
Neden birden fazla alt etki alanı kullandığımı sormuyorum - bu benim için anlamlı. Ayrı tam etki alanları hakkında soruyorum. Neden static.stackexchange.com yerine sstatic.net?
Michael Ekstrand

5

Lèse majesté ana noktaları ele aldı, ancak daha fazla genişletmek için, tüm Stack Exchange siteleri için tek bir etki alanına sahip olmanın, onları gezen birinin yalnızca bir kez JavaScripts gibi statik içeriği indireceği anlamına geldiğini eklerim. Örneğin Süper Kullanıcıya gitmek, bir kullanıcı aynı yerden olduğundan önbelleğe alınmış içeriği kullanacaktır.

Yahoo ve Google’da bunun hakkında daha faydalı bilgiler var .


5

Asıl sebep çerezlerdir. Niels'in cevabında önerdiği şey, asıl sebep değil, sadece küçük bir sonuçtur. Çerezler olmadan istek boyutu daha küçüktür, bu nedenle bazı bant genişliklerinden tasarruf edilir.

Ancak, asıl fark tarayıcı önbelleğinden geliyor. İçerik statik olduğundan (yani değişmediğinden), tarayıcılar yerel sabit diskte önbelleğe alabilir ve her seferinde dosyayı Internet'ten yüklemekten kaçınabilir. Tüm dosya yerine, web sunucusu yalnızca 304 yanıt göndererek, içeriğin değişmediğini gösterir.

Site çerez kullandığında, tarayıcılar dosya içeriğinin farklı kullanıcılar için farklı olabileceğini düşünüyor, bu yüzden bu dosyaları önbelleğe almıyorlar. Dosyaya, çerez içermeyen alan adından sunulması, tarayıcı önbelleğe almanın düzgün çalışmasını sağlar.

Yükleme sürelerini iyileştirmesi ve bant genişliğini önemli ölçüde azaltması temel nedeni budur.


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.