Bu belge
Apache HTTP sunucusu, sunucunun başarımını çeşitli yollarla arttırmak üzere tasarlanmış bir dizi önbellekleme özelliğine sahiptir.
Bu belgeden azami yararı sağlayabilmek için temel bir HTTP bilginizin olması ve URL’lerin Dosya Sistemine Eşlenmesi ile İçerik Uzlaşımı belgelerini okumuş olmanız gerekir.
HTTP protokolü
RFC2616'nın 13. bölümünde açıklanan satıriçi önbellekleme
mekanizması için yerleşik bir destek içerir ve bunun getirilerinden
yararlanmak için
İçeriğin taze olmadığı durumda içeriğin kaybolmasına sebep olan basit iki durumlu anahtar/değer önbelleklemesinin tersine, HTTP önbelleği eskimiş içeriği tutan ve bu eski içeriğin değişip değişmediğini özgün sunucuya soran ve duruma göre onu tekrar taze duruma getiren bir mekanizma içerir.
HTTP önbelleğinde bulunan bir girdi şu üç durumdan birinde olabilir:
İçerik çok eski (tazelik ömründen daha yaşlı) ise bayat sayılır. Bir HTTP önbelleği böyle bir içeriği istemciye sunmadan önce özgün sunucuya bağlanıp bayat içeriğin hala yeterince taze olup olmadığına bakmalıdır. Özgün sunucu, içerik geçersizse yenisini gönderecektir, aksi takdirde, (ideal olanı budur) içeriğin hala geçerli olduğunu belirten bir kod ile yanıt verecektir. İçerik tekrar taze hale gelince süreç kaldığı yerden devam eder.
HTTP protokolü belli koşullar altında önbelleğin bayat içeriği
sunmasına izin vermez. Örneğin, bir içeriği özgün sunucuda tazeleme
çabasının bir 5xx hatasıyla başarısız olması veya başka bir tazeleme
isteğinin henüz sonuçlanmamış olması bu çeşit koşullardandır. Bu
durumlarda yanıta bir Warning
başlığı eklenir.
HTTP önbelleklemesinin çalışması ile ilgili bütün ayrıntılar RFC2616'nın 13. bölümünde bulunabilir.
Bu aşama çok erken gerçekleşen bir aşama olup isteğin işlenmesi sırasında isteğin çözümlenmesinin hemen sonrasıdır. İçerik önbellekte mevcutsa hemen sunulur ve geri kalan istek işleme işlemi iptal edilir.
Bu senaryoda önbellek sunucunun önüne vidalanmış gibi davranır.
Sunucuda gerçekleşecek bir dizi işlemin büyük çoğunluğunun yapılmadan geçilmesi nedeniyle bu en yüksek başarımlı kiptir. Bu kip ayrıca, sunucu işlemlerinin kimlik doğrulama ve yetkilendirme aşamalarının da yapılmadan geçilmesini sağlar. Bu bakımdan bu kip seçilirken bu durum dikkate alınmalıdır.
Bu aşama geç bir aşama olup, isteğin tamamen işlenmesinin sonrasıdır.
Bu senaryoda önbellek sunucunun arkasına vidalanmış gibi davranır.
Bu kip en esneğidir. Önbelleğin, süzme zincirinin hassas olarak denetlenen bir noktasında oluşması sağlanabilir ve önbelleklenen içerik istemciye gönderilmeden önce süzülüp kişiselleştirilebilir.
URL önbellekte yoksa
Önbellekteki içerik bayatsa, 304 Not Modified
yanıtı
verirse içerik tekrar taze olarak imlenir ve önbellekteki içerik
süzgeç tarafından kaydedilmeden sunulur.
Bir sanal konak birçok farklı sunucu takma adından biri olarak
bilindiği takdirde On
değeri atanmışsa önbellekten sunulan sayfa sayısında büyük bir artış
olduğu görülür. Bunun sebebi içeriği sunan sanal konağın isminin
önbellek anahtarının içinde kullanılmasıdır. Yönergeye
On
değerini atamak suretiyle çok isimli ve rumuzlu sanal
konaklar için farklı önbellek girdileri oluşturulmaz, bunun yerine her
meşru sanal konak için ayrı bir önbellek tutulur.
Önbelleklenmek üzere tasarlanmış iyi biçimli bir içerik tazelik ömrünü
Cache-Control
başlığının max-age
veya
s-maxage
alanlarıyla ya da bir Expires
başlığını içererek bildirmelidir.
Aynı zamanda, özgün sunucunun tanımladığı tazelik ömrü, bir istemci
tarafından istekte bir Cache-Control
başlığı kullanılarak
geçersiz kılınmak istenebilir. Bu durumda hangi tazelik ömrü daha
kısaysa o geçerli olur.
Tazelik ömrü istekte veya yanıtta mevcut değilse öntanımlı bir tazelik
ömrü kullanılır. Öntanımlı tazelik ömrü önbellekli içerik için bir saat
olmakla birlikte
Bir yanıt Expires
başlığını değil de
Last-Modified
başlığını içeriyorsa
Yerel içerik için, ya da kendi Expires
başlığını
tanımlamayan uzak içerik için tazelik ömrünü max-age
ve
Expires
ekleyerek hassas olarak ayarlamak
için
Tazelik ömrünün üst sınırı
Önbellekteki içeriğin zaman aşımına uğrayıp bayat hale gelmesi, httpd’nin özgün isteği aktarmak yerine isteği değişikliğe uğratarak şartlı bir istek yapması sonucunu doğurur.
Özgün önbellekli yanıtta bir ETag
başlığı mevcutsa,
If-None-Match
başlığı ekler.
Özgün önbellekli yanıtta bir Last-Modified
başlığı
mevcutsa, If-Modified-Since
başlığı ekler. Bunlardan
birinin varlığı isteği koşullu yapar.
Bir koşullu istek özgün sunucu tarafından alındığında, özgün sunucu
ETag
veya Last-Modified
başlığının isteğe
uygun olarak değişip değişmediğine bakmalıdır. Değişmemişse, özgün
sunucu kısa ve öz bir "304 Not Modified" yanıtı ile yanıt vermelidir.
Bunun önbellekteki anlamı şudur: Eskimiş içerik hala tazedir ve içerik
yeni tazelik ömrüne ulaşıncaya kadar sonraki isteklerde
kullanılmalıdır.
İçerik değişmişse, bir şartlı istek yapılmamış gibi içeriğin kendisi sunulur.
Şartlı istekler çifte yarar sağlar. Birinci olarak, böyle bir istek özgün sunucuya yapılıyorsa ve iki içerik de aynıysa bunu saptamak kolay olur ve özkaynağın tamamını aktarma külfetinden kurtulunur.
İkinci olarak, iyi tasarlanmış bir özgün sunucu, koşullu istekler tam
bir yanıt üretmekten önemli ölçüde ucuz olacak şekilde tasarlanmış
olacaktır. Durağan dosyalar için bu genellikle
stat()
veya benzeri bir sistem çağrısıyla dosya
boyutları ve değişiklik zamanına bakmak şeklinde gerçekleşir.
Böylelikle, yerel içeriği bir değişiklik olmadığı takdirde önbellekten
sunmak daha hızlı olacaktır.
Özgün sunucular koşullu istekleri desteklemek için her türlü çabayı göstermelidir. Ancak, koşullu istekler desteklenmiyorsa, özgün sunucu istek koşullu değilmiş gibi yanıt vermeli, önbellek ise, içerik değişmiş ve yani içerik önbelleğe kaydedilmiş gibi yanıt vermelidir. Bu durumda, önbellek basit bir iki durumlu (içerik ya tazedir ya da silinmiş) önbellek gibi davranacaktır.
HTTP önbelleğin tarafından önbelleklenebilecek içerik RFC2616 Section 13.4 Response Cacheability belgesinde tanımlanmış olup, bunlar şöyle özetlenebilir:
İçerik zamana bağımlıysa ya da istek kısmen bile olsa HTTP uzlaşımıyla
bağdaşmıyorsa önbelleğe alınmamalıdır. Bu içerik önbelleklenemeyeceğini
Cache-Control
başlığını kullanarak sunucuya
bildirmelidir.
İçerik sıkça değişiyorsa, tazelik ömrü dakikalar veya saniyelerle ifade ediliyorsa, içerik yine de önbelleklenebilir. Ancak, tam yanıtların düzenli olarak üretilmemesinin temini için özgün sunucunun koşullu istekleri doğru olarak desteklemesi sağlanmalıdır.
İstemcinin sağladığı istek başlıklarına dayanarak değişen içerik,
Vary
yanıt başlığının akıllıca kullanımıyla
önbelleklenebilir.
Özgün sunucu, istekteki başlık değerlerine dayanarak farklı içeriklerle yanıt vermeye ayarlandığı takdirde, örneğin aynı URL'de farklı dillerde içerik sunmak gibi, HTTP'nin önbellekleme mekanizması aynı URL'de aynı sayfanın değişik sürümlerini önbelleklemeyi mümkün kılar.
Bu özgün sunucu tarafından bir Vary
başlığı eklenerek
yapılır. Bir sayfanın farklı sürümleri arasındaki farkları saptarken
önbellek tarafından hangi başlıkların hesaba katılacağını
Vary
başlığı belirler.
Örneğin, bir yanıt şöyle bir başlık ile alınmışsa,
İçeriğin farklı sürümleri yan yana önbelleklenebilir.
Vary
başlığını
kullanarak başlıkta listelenmiş istek başlıklarının uygun değerlerini
saptar ve istemciye hangi sürümle yanıt verileceğine karar verir.
Tipik olarak modül şöyle yapılandırılır:
En önemlisi önbelleklenen dosyaların yerel olarak saklanması olup işletim sisteminin sağladığı bellekiçi önbelleklemeden de ayrıca faydalanılmış olur. Bu bakımdan, dosyalar disk üzerinde saklansa bile sıkça erişilen dosyalar işletim sistemi sayesinde aslında bellekten sunulmuş olacaklardır.
Vary
başlığında
tanımlı elemanlardan oluşur.
Özeti oluşturan karakterler 64 karakterlik bir karakter kümesinden
seçildiğinden oluşturulması olası farklı özet sayısı 64^22’dir.
Örneğin, bir URL’nin xyTGxSMO2b68mBCykqkp1w
gibi bir
özeti olabilir. Bu özet, bu URL ile erişilen dosyalar önbellek içinde
saklanırken dosya ismi öneki olarak kullanılır. Ancak bununla
yetinilmez ve içerik
/var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w
gibi bir önek
getirilebilirdi.
Bu tekniğin asıl amacı belli bir dizin içinde bulunabilecek
dosyaların ve alt dizinlerin sayısını düşük tutmaktır. Bu sayının
büyük olması çoğu işletim sisteminde başarımın düşmesine sebep olur.
Her URL için önbellekte en az iki dosya saklanır. Biri genellikle URL hakkındaki temel verilerden oluşan ".header" dosyasıdır, diğeri ise sunulacak içeriğin bire bir kopyası olan ".data" dosyasıdır.
"Vary" başlığı üzerinden içeriğin uzlaşıldığı durumda URL için bir ".vary" dizini oluşturulur. Bu dizin her biri farklı bir uzlaşıma ait çok sayıda ".data" dosyası içerebilir.
Bunun yerine httpd önbellek içeriğini düzenli aralıklarla
temizleyebilmeniz için
Ayrıca,
Şekil 1:
Önbelleğin büyümesi ve düzenli aralıklarla temizlenmesi.
Apache HTTP sunucusu, SSL oturumları, kimlik doğrulama bilgileri gibi önbelleklenebilen özel bilgiler için socache arayüzü içinde düşük seviyeli bir paylaşımlı nesne önbelleğine sahiptir.
Her gerçeklenime uygun ek modüller de sağlanmıştır:
socache
arayüzünü kullanır.
Dosya sisteminin yavaş olabildiği veya dosya tanıtıcılarının kullanımının pahalıya mal olduğu sistemlerde, sunucunun başlatılması sırasında dosyaların belleğe yüklenmesi seçeneği vardır.
Dosyaların açılmasının yavaş olduğu sistemlerde, dosyaların sunucunun başlatılması sırasında açılması ve dosya tanıtıcısını önbelleklenmesi seçeneği vardır. Bu seçeneklerin duruk dosyalara erişimin yavaş olduğu sistemlere de bir yardımı olabilir.
Bir dosyanın açılması işlemi, özellikle de ağ dosya sistemlerinde bulunan dosyalar için önemli bir gecikme kaynağı olabilir. Önbellekte, çok sunulan dosyaların kendilerinin değil, açık dosya tanıtıcılarının saklanması httpd’yi bu tür gecikmelerden koruyabilir. httpd’de tek türde dosya tanıtıcı önbelleklemesi yapılabilmektedir.
CacheFile
yönergesi ilehttpd’de mevcut önbelleklemenin en temel şekli
Büyük miktarda dosyayı bu anlamda önbelleklemeyi tasarlıyorsanız işletim sisteminizin açık dosya tanıtıcılarının sayısı ile ilgili sınırlamasını uygun bir değere ayarlamanız gerekebilir.
Eğer httpd çalışırken dosya silinmişse httpd ilk başlatıldığındaki haline ilişkin dosya tanıtıcıyı sağlamaya ve dolayısıyla dosya içeriğini sunmaya devam edecektir. Yani, dosya silinmiş ve artık dosya sisteminde görünmüyor olsa bile httpd durdurulup dosya tanıtıcıları kapanmadıkça dosyaların silinmesiyle açılan yer serbest kalmayacaktır.
İçeriğin sistem belleğinden sunulması içerik sunmanın evrensel olarak en hızlı yoludur. Dosyaların bir disk denetleyiciden okunması ya da daha kötüsü uzak bir ağdan okunması bellekten okumayla karşılaştırılamayacak ölçüde yavaş işlemlerdir. Disk denetleyiciler genellikle fiziksel süreçleri denetlerler. Ağ erişimi ise band genişliği sınırlamalarından etkilenir. Halbuki bellek erişimi sadece nano saniyeler mertebesinde gerçekleşir.
Sistem belleği en pahalı saklama ortamı olması sebebiyle en verimli şekilde kullanımı önemlidir. Dosyaları sistem belleğinde saklamakla sistemin kullanabileceği bellek miktarını azaltmış olursunuz. İşletim sistemi önbelleklemesinde göreceğiniz gibi bu öyle basit bir konu değildir. httpd’nin kendi kullandığı belleğin bir kısmını önbellek olarak ayırırken çok fazla bellek kullanmamak önemlidir. Aksi takdirde işletim sistemi belleğin yetmediği noktada belleği diske takaslayacağından istenen başarım artışı sağlanamayacaktır.
Günümüz iştetim sistemlerinin hemen hemen tamamında bellek içi dosya/veri saklama işlemlerini çekirdek yönetir. Bu güçlü bir özelliktir ve işletim sistemlerinin büyük çoğunluğu bunu böyle yapar. Örneğin, Linux’ta bir dosyanın ilk defa okunduğunda ve ikinci kez okunduğunda işlemcinin ne kadar meşgul edildiğine bakalım:
Küçük bir dosya için bile okuma süresi bakımından büyük fark ortaya çıkmaktadır. Bunun sebebi çekirdeğin dosya içeriğini bellek daha güncel amaçlar için lazım olana dek bellek içinde saklamasıdır.
Sisteminizde yeterince yedek bellek olduğundan eminseniz, bu önbellekte daha fazla dosya saklanacağından emin olabilirsiniz. Bundan, önbelleğin sistem belleğinde verimli biçimde tutulması için httpd’de ek bir yapılandırmaya gidilmesinin gerekmediği sonucu çıkarılabilir.
Bundan başka, işletim sistemi dosyaların değiştiği ve silindiği zamanları bildiğinden bu tür dosyaların içerikleri gerektiğinde önbellekten kendiliğinden silinmiş olur. Bellek içinde dosya saklarken dosyaların değiştirilme zamanlarını bilme olanağı olmadığından bu durum httpd’ye büyük yarar sağlar.
İşletim sisteminin dosyaların önbelleklenmesi için sağladığı bunca yarara ve başarım artışına karşın bellek içinde dosya önbelleklemenin httpd tarafından yerine getirilmesinin daha iyi olacağı bazı durumlar vardır.
MMapFile
yönergesi ileOn
değerinin atandığı öntanımlı durumda
Olası .htaccess
dosyalarının dosya sisteminin tamamında
taranması çok pahalı bir işlem olduğundan
Örneğin, yapılandırmanız bir özkaynağa IP adresine göre erişime izin
veriyorsa bu içeriğin önbelleğe alınmayacağından emin olmalısınız.
Bunu
Off
atandığı takdirde, istek işleme
aşamalarının tamamı yerine getirilir ve güvenlik modeli değişmeden
kalır.
Son kullanıcılarıın isteklerine önbellekten hizmet sunulduğundan önbelleğin kendisi içerikle etkileşime geçmek isteyenlerin veya içeriği tahrif etmek isteyenlerin hedefi haline gelebilir. httpd’yi çalıştıran kullanıcı tarafından her zaman önbelleğe yazılabileceğini akıldan çıkarmamak önemlidir. Bu durumda alışılmışın tersine tüm içeriğin Apache kullanıcısı tarafından yazılamamasının sağlanması önerilir.
Eğer Apache kullanıcısı, örneğin bir CGI sürecindeki açık nedeniyle
tehlikeye atılırsa, önbellek hedef alınabilir.
Bu risk, Apache kullanıcısını kullanan diğer saldırı türleriyle
karşılaştırıldığında daha yüksektir.
httpd bir önbellekli vekil sunucu olarak çalıştığında önbellek zehirlenmesi adı verilen sorunla karşılaşılma olasılığı vardır. Önbellek zehirlenmesi, vekil sunucunun özgün sunucudan yanlış (ve genellikle istenmeyen) içerik almasına sebep olan bir saldırı türünü betimlemek için yaygın olarak kullanılan bir terimdir.
Örneğin httpd’nin çalıştığı sistemin kullandığı DNS sunucuları DNS önbellek zehirlenmesinden etkilenebilecek durumdaysa, bir saldırgan httpd’nin istekleri almak için başvuracağı kaynak sunucunun yerini değiştirebilir. Diğer bir örnek, HTTP istek kaçakçılığı adı verilen bir saldırı türüdür.
Bu belge HTTP istek kaçakçılığını derinliğine incelenmesi için uygun yer değildir (böyle kaynaklara arama motorunuzla erişebilirsiniz). Bununla birlikte, vekil tarafından kaynak sunucudan alınan içeriği tamamen denetim altına almak amacıyla kaynak sunucudaki bir açığı istismar etmeye yönelik bir dizi istek yapılabileceğinin olasılık dahilinde olduğunu bilmenizde yarar vardır.
Vary mekanizması aynı URL'nin çok sayıda sürümünün yan yana
önbelleklenmesini mümkün kılar. İstemci tarafından sağlanan başlık
değerlerine bağlı olarak, önbellek istemciye gönderilecek doğru yanıtı
bulacaktır. Normal kullanımda olası değerlerin çok geniş olduğunun
bilindiği durumda bir başlığı (örn, User-Agent
)
değişikliğe uğratma çabası bu mekanizmayı bir sorun haline getirebilir.
Sitenin tanınırlığına bağlı olarak aynı URL'nin binlerce hatta
milyonlarca önbellek girdisi oluşabilir ve bunlar önbellekteki diğer
girdilerin yerini alabilir.
Diğer yandan, belli bir özkaynağın URL'sinin her istekte
değiştirilmesi ihtiyacı ortaya çıkabilir. Bu normalde URL dizgesine bir
"cachebuster" dizgesi eklenerek yapılır. Bu içerik sunucu tarafından
anlamlı bir tazelik ömrüyle önbelleklenebilir olarak imlenmişse bu
girdiler kısa zamanda önbellekteki meşru girdilerin yerini alabilir.