Türkiye'deki Kullanıcılar İçin CDN Node Seçimi Nasıl Yapılır?

PoP haritasını okumak: İstanbul var, trafik oraya mı gidiyor?

CDN sağlayıcılarının web sitelerindeki ağ haritaları büyük ölçüde ticari bir sunum aracı olarak tasarlanmıştır. İstanbul'a bir nokta koymak, Türkiye'den gelen trafiğin gerçekten o node'a bağlandığını garanti etmez. Bazı sağlayıcılar İstanbul PoP'unu yalnızca belirli plan seviyelerinde etkinleştirir; giriş veya orta seviye planlardaki trafik, peering yapılandırmasına bağlı olarak yakın Avrupa merkezlerine yönlenebilir.

Edge node'un kimliğini saptamanın birinci yolu, sağlayıcının döndürdüğü HTTP response header'larını okumaktır. Büyük CDN sağlayıcılarının çoğu bu bilgiyi response header'larına ekler; X-Cache-Status, CF-Ray, Via, X-Served-By veya Server-Timing gibi başlıklar hangi veri merkezinden yanıt geldiğini açıklar. Tarayıcınızın geliştirici araçlarında ağ sekmesini açarak CDN üzerindeki herhangi bir kaynağa tıklayıp bu başlıkları okuyabilirsiniz; alternatif olarak aşağıdaki komutla hem TTFB değerini hem de header'ları bir arada inceleyebilirsiniz:

curl -s -D - -o /dev/null https://siteniz.com/

Farklı ISS'ler üzerinden ölçüm yapmak da aynı ölçüde önemlidir. Büyük operatörler aynı CDN ağına farklı peering noktaları üzerinden bağlanabilir; bu, hangi İnternet servis sağlayıcısını kullandığınıza göre yönlendirmenin değişebileceği anlamına gelir. Yalnızca tek bir ağdan test yapmak geniş kullanıcı tabanını temsil etmeyebilir; bağımsız test platformlarının çoklu lokasyon özelliği, farklı Türkiye noktalarından eş zamanlı ölçüm yapmanıza olanak tanır.

Ping ve TTFB testi: nereden, nasıl çalıştırılır?

Ping, ağ gecikmesinin ham bir ölçüsüdür. Türkiye'deki bir kullanıcıdan İstanbul'daki bir sunucuya ping, koşullara bağlı olarak yaklaşık 5-25 ms arasında olmalıdır; aynı kullanıcı Frankfurt'taki bir sunucuya bağlandığında bu değer 40-70 ms'ye çıkabilir. Fark küçük görünebilir. Ama TLS el sıkışması, DNS çözümlemesi ve HTTP istek-yanıt döngüsü bu gecikmeyi gerçek kullanıcı deneyimine katlar ve LCP üzerinde net bir iz bırakır.

TTFB'yi ayrıntılı olarak ölçmek için curl ile zamanlama çıktısı alabilirsiniz:

curl -s -o /dev/null -w "dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\n" https://siteniz.com/

Bu çıktı gecikmenin DNS çözümlemesinde mi, TCP bağlantısında mı, TLS el sıkışmasında mı yoksa sunucu işleme süresinde mi biriktiğini ayırt etmenizi sağlar; her aşama ayrı bir satırda görünür. İstanbul PoP'u etkin olan bir CDN'de TLS süresi, Türkiye'den yapılan testte belirgin biçimde düşer, çünkü round-trip mesafesi kısalmıştır. TLS süresinde iyileşme görülmüyor ama DNS hızlanıyorsa, edge node değil DNS resolver değişikliği öne geçmiş olabilir.

Ölçümü birden fazla konumdan yapmak kritik önem taşır. Yalnızca İstanbul'dan iyi sonuç almak, ülkenin diğer bölgelerinde aynı kaliteyi garanti etmez; Türkiye'nin geniş coğrafyası ve ISS altyapısındaki farklılıklar, Doğu Anadolu ile İstanbul arasında kayda değer sapmalara yol açabilir. Yüksek TTFB görüyorsanız ve gecikmenin nerede biriktiğini bulmak istiyorsanız, sorunun sunucu katmanında mı yoksa render zincirinde mi olduğunu ayırt etmek süreci hızlandırır.

Anycast yönlendirme ve gerçek PoP tespiti: traceroute ile doğrulama

Anycast, aynı IP adresinin birden fazla coğrafi konumda aynı anda yayınlanmasına dayanır. Paketler BGP yönlendirme tablosuna göre en yakın PoP'a gider. Teoride bu idealdir; pratikte "en yakın" kavramı ağ topolojisine, ISS politikalarına ve peering anlaşmalarına göre şekillenir. İstanbul'da anycast PoP'u olan bir sağlayıcı, belirli bir ISS üzerinden gelen Türk trafiğini yine de Frankfurt'a yönlendiriyor olabilir, çünkü o ISS'in BGP politikası farklı bir rota belirliyor olabilir.

Traceroute bu yönlendirmeyi gözlemlemenin en doğrudan yoludur. Windows'ta tracert, Linux ve macOS'ta traceroute komutu ile CDN alan adınıza rota çizebilirsiniz:

traceroute siteniz.com

Çıktıdaki hop'ların IP adreslerini WHOIS ve IP geolocation araçlarıyla araştırın. Paket 4. ya da 5. hop'ta Türkiye dışına çıkıyorsa ve sağlayıcı "İstanbul PoP'u var" diyorsa, Türkiye'den gelen trafiğin gerçekten o PoP'a ulaşmadığı anlamına gelir. Bu durumda sağlayıcıyla doğrudan iletişime geçmek ya da üst plana geçişin bu davranışı değiştirip değiştirmediğini test etmek gerekir.

Aynı testi farklı ağlardan tekrarlayın. Kablo ve mobil bağlantılar, ev ve kurumsal ağlar farklı BGP rotaları izleyebilir; yalnızca tek bir noktadan çalıştırılan traceroute, gerçek kullanıcı trafiğinin yolunu tam olarak yansıtmayabilir. CDN kararının sağlamlığı, bu farklı rota senaryolarının hepsinde tutarlı sonuç vermesine bağlıdır.

Türkiye'deki ISS ve peering etkisi: göz ardı edilen değişken

Peering, iki ağın birbirinin trafiğini hangi noktadan ve hangi koşullarda taşıyacağına dair anlaşmadır. Bir CDN sağlayıcısının Türkiye'deki büyük ISS'lerle doğrudan peering anlaşması varsa, trafik İstanbul internet değişim noktaları üzerinden akar; yoksa trafik önce Avrupa'ya gidip döner. Bu, kullanıcı deneyiminde 50-100 ms'lik ek gecikme anlamına gelebilir; üstelik bu gecikme sabittir, uygulama katmanı optimizasyonlarıyla giderilemez.

Türkiye'de internet değişim noktası (IX) altyapısı gelişmiştir; İstanbul'da birden fazla aktif IX bulunmaktadır. Güçlü CDN sağlayıcıları bu IX'lere bağlıdır. Bir sağlayıcının IX üyeliğini araştırmak, peering kalitesini öngörmek için yararlı bir sinyal verir; ne var ki IX üyeliği tek başına yeterli değildir, üyenin hangi operatörlerle bağlantı kurduğu da önemlidir.

Aynı CDN sağlayıcısı, bir ISS abonesi olan kullanıcıya düşük TTFB verirken başka bir operatörün kullanıcısına farklı bir deneyim sunabilir. Bu farkı görmek için farklı ağlara erişiminiz yoksa, bağımsız test platformlarının çoklu lokasyon özelliğinden yararlanabilirsiniz. CDN katmanına bir reverse proxy eklediğinizde yönlendirme davranışı değişebilir; bu etkileşimi anlamak için reverse proxy'nin performansa katkısını ve risklerini incelemek faydalıdır. Peering tabanlı farklılıkları zaman içinde izlemek içinse düzenli periyodik ölçüm tutarlı bir referans noktası sağlar.

Cache hit oranı: edge'de kalmak ne anlama gelir?

İstanbul'da güçlü bir PoP olsa bile trafiğin büyük bölümü cache miss ile karşılanıyorsa, köken sunucuya gidip dönen her istek o PoP'u bypass eder. CDN'in değeri büyük ölçüde cache hit oranına bağlıdır; düşük hit oranı, coğrafi optimizasyonun sağlayabileceği kazancı önemli ölçüde törpüler. İyi bir İstanbul PoP ile düşük cache hit oranını bir arada bulundurmak, sağlayıcı değişikliğinin beklenen etkiyi yaratmamasının en yaygın nedenidir.

Cache hit oranını etkileyen başlıca etkenler içeriğin TTL değerleri, sorgu parametresi varyasyonları, cookie bazlı bölümleme ve dinamik içerik yüzdesidir. Sayfanın URL'si her kullanıcı için farklılaşıyorsa ya da oturum parametreleri URL'e dahilse, CDN her isteği taze kabul eder ve köken sunucuya gider. Hit oranı bu nedenle CDN kontrol panelinden düzenli olarak izlenmesi gereken bir metriktir.

Hit oranını artırmak için önce hangi URL'lerin cache'lenebilir olduğunu netleştirin. Statik varlıklar, CSS dosyaları, JavaScript ve görseller uzun TTL ile sorunsuz cache'lenir. HTML sayfaları daha dikkatli ele alınmalıdır; sayfanın içeriği kullanıcıya göre değişiyorsa, o sayfayı CDN'de cache'lemenin zararı faydasından büyük olabilir. Dinamik ve statik içeriği CDN kurallarında net biçimde ayırmak, İstanbul PoP'unun değerini gerçekten kullanılabilir kılar.

Karar kriterleri: hangi durumda hangi yapı işe yarar?

Tüm testleri yaptınız, TTFB değerlerinizi karşılaştırdınız. Türkiye odaklı bir site için CDN seçimi üç ana senaryoya göre şekillenir ve her birinde öncelik farklılaşır.

Trafiğin büyük bölümü Türkiye'den geliyor ve içerik ağırlıklı olarak statikse, İstanbul PoP'u etkin olan ve Türkiye'deki büyük ISS'lerle peering anlaşması bulunan bir sağlayıcı net avantaj sağlar. TTFB testinde 150 ms'nin altında tutarlı sonuç veren ve cache hit oranı yüksek olan seçenek önceliği almalıdır. Sağlayıcının ağ haritası değil, kendi ağınızdan ölçtüğünüz TTFB değerleri karar verici olmalıdır.

Trafik Türkiye ile Avrupa veya küresel arasında paylaşılıyorsa, İstanbul PoP'u olan ama küresel ağ kalitesi düşük bir sağlayıcı uluslararası ziyaretçileri yavaşlatabilir. Hem Türkiye hem de hedeflediğiniz uluslararası lokasyonlar için TTFB karşılaştırması yapmak gerekir. Tek bir bölgede iyileşme sağlanırken diğer bölgelerde gerileme yaşanması, sağlayıcı değişikliğinin net kazancını sıfırlayabilir.

İçerik büyük ölçüde dinamik, kişiselleştirilmiş ya da gerçek zamanlıysa CDN'in coğrafi optimizasyonu sınırlı katkı sağlar. Köken sunucunun Türkiye'de barındırılması ya da Türkiye'ye yakın bir altyapı tercih edilmesi daha etkili olabilir. CDN yine de TLS termination ve DDoS koruması amacıyla kullanılabilir; ancak ondan coğrafi gecikme kazancı beklememek gerekir. Dinamik sayfalardaki performans sorunlarını derinlemesine incelemek için TTFB düşük iken FCP'nin neden yüksek kalabileceğini anlamak bu senaryoda özellikle değerlidir.