TLS el sıkışma süresi yüksekse hangi ayarlar incelenmeli?

TLS el sıkışma süresi, bir ziyaretçinin tarayıcısı ile sunucu arasında güvenli bağlantı kurulurken geçen kritik süredir. Bu değer yükseldiğinde sayfa henüz yüklenmeye başlamadan gecikme oluşur; özellikle e-ticaret, kurumsal portal ve yoğun trafik alan WordPress sitelerinde kullanıcı deneyimi doğrudan etkilenir. Sorunu doğru analiz etmek için yalnızca SSL sertifikasına bakmak yeterli değildir; ağ yolu, sunucu yapılandırması, protokol desteği ve hosting altyapısı birlikte değerlendirilmelidir.

TLS el sıkışma süresi neden yükselir?

TLS handshake süreci; DNS çözümleme, TCP bağlantısı, şifreleme algoritması seçimi, sertifika doğrulama ve oturum anahtarı oluşturma adımlarından oluşur. Bu adımların herhangi birinde gecikme varsa tarayıcı, güvenli bağlantıyı geç kurar. Kullanıcı açısından bu durum “site yavaş açılıyor” şeklinde algılanır.

Yüksek TLS süresi çoğu zaman tek bir nedene bağlı değildir. Eski TLS sürümleri, yanlış yapılandırılmış sertifika zinciri, uzak veri merkezi, OCSP gecikmesi veya sunucuda aşırı yük aynı anda etkili olabilir. Bu nedenle ölçüm yaparken yalnızca toplam süreye değil, bağlantının hangi aşamada beklediğine bakılmalıdır.

İlk kontrol: TLS sürümü ve şifreleme paketleri

Modern tarayıcılar TLS 1.2 ve TLS 1.3 ile en verimli bağlantıyı kurar. TLS 1.3, el sıkışma adımlarını azalttığı için gecikmeyi düşürmede önemli avantaj sağlar. Eğer sunucu hâlâ TLS 1.0 veya TLS 1.1 destekliyorsa hem güvenlik riski oluşur hem de yapılandırma karmaşıklaşabilir.

Nelere dikkat edilmeli?

• TLS 1.3 desteğinin aktif olup olmadığı kontrol edilmelidir.
• Eski ve zayıf cipher suite seçenekleri devre dışı bırakılmalıdır.
• ECDHE tabanlı modern anahtar değişim algoritmaları tercih edilmelidir.
• Sunucu yazılımı eskiyse OpenSSL, Nginx, Apache veya LiteSpeed sürümleri incelenmelidir.

Burada yapılan yaygın hata, tüm eski protokolleri açık bırakarak “uyumluluğu artırmaya” çalışmaktır. Güncel kullanıcı kitlesinde bu yaklaşım çoğunlukla gereksizdir ve güvenlik ile performans dengesini olumsuz etkiler.

Sertifika zinciri doğru yapılandırılmış mı?

TLS el sıkışma süresini artıran önemli nedenlerden biri eksik veya hatalı ara sertifika zinciridir. Tarayıcı, sertifikanın güvenilirliğini doğrulamak için fazladan sorgu yapmak zorunda kalırsa bağlantı gecikir. Bu durum özellikle mobil ağlarda daha belirgin hale gelir.

Sunucuda yalnızca alan adı sertifikası değil, doğru intermediate sertifikalar da eksiksiz tanımlanmalıdır. Ayrıca gereksiz uzun sertifika zincirleri kullanılmamalıdır. Sertifika yenileme sonrası yapılandırmanın otomatik olarak bozulmadığından emin olmak için düzenli kontrol yapılması gerekir.

OCSP Stapling ve sertifika doğrulama gecikmesi

Tarayıcı, sertifikanın iptal edilip edilmediğini kontrol etmek için sertifika otoritesine ek istek gönderebilir. Bu istek yavaş yanıt verirse TLS handshake süresi yükselir. OCSP Stapling aktif olduğunda sunucu, doğrulama bilgisini hazır şekilde tarayıcıya sunar ve ek gecikme azalır.

Kurumsal sitelerde bu ayar küçük görünse de yüksek trafikte belirgin fark yaratabilir. Kontrol sırasında OCSP Stapling’in gerçekten çalışıp çalışmadığı test edilmeli; yalnızca yapılandırma dosyasında yazıyor olması yeterli kabul edilmemelidir.

Sunucu konumu ve ağ gecikmesi

TLS el sıkışması birden fazla gidiş-dönüş iletişim gerektirdiği için fiziksel mesafe önemlidir. Hedef kitle Türkiye’deyken sunucu Avrupa dışı bir bölgede konumlanıyorsa, bağlantı kurulmadan önce bile gecikme oluşabilir. Bu nedenle veri merkezi lokasyonu, performans analizinde öncelikli kriterlerden biridir.

CDN kullanımı, statik içeriklerde yükü azaltabilir; ancak TLS sonlandırmanın nerede yapıldığı doğru planlanmalıdır. CDN ile origin sunucu arasında ek TLS bağlantısı kuruluyorsa, yanlış yapılandırma beklenen hız kazancını sınırlayabilir.

HTTP/2, HTTP/3 ve bağlantı yeniden kullanımı

HTTP/2, tek bağlantı üzerinden birden fazla isteğin daha verimli taşınmasını sağlar. HTTP/3 ise QUIC protokolü sayesinde bağlantı kurulumunda bazı gecikmeleri azaltabilir. Ancak bu protokollerin aktif olması tek başına yeterli değildir; tarayıcı, CDN ve sunucu tarafında uyumlu yapılandırma gerekir.

Keep-Alive ayarlarının kapalı olması veya çok kısa tutulması, her istekte yeniden bağlantı kurulmasına neden olabilir. Bu da TLS el sıkışma maliyetini artırır. Özellikle WordPress gibi çok sayıda CSS, JavaScript ve görsel dosya çağıran sistemlerde bağlantı yeniden kullanımı performans için kritiktir.

Sunucu yükü ve kaynak kullanımı

TLS işlemleri CPU kullanır. Yoğun trafik, sınırlı işlemci kaynağı veya yanlış yapılandırılmış web sunucusu TLS yanıtlarını geciktirebilir. Paylaşımlı hosting ortamlarında aynı fiziksel kaynakları kullanan diğer siteler de dolaylı etki yaratabilir.

Bu noktada yalnızca anlık hız testiyle karar verilmemelidir. CPU load, RAM kullanımı, worker limitleri, PHP-FPM yoğunluğu ve web sunucusu bağlantı limitleri birlikte izlenmelidir. Sorun yalnızca belirli saatlerde yaşanıyorsa kapasite veya kaynak paylaşımı kaynaklı olma ihtimali artar.

WordPress tarafında hangi noktalar kontrol edilmeli?

WordPress eklentileri doğrudan TLS protokolünü yönetmez; ancak sayfa başına istek sayısını artırarak bağlantı yükünü büyütebilir. Çok sayıda harici font, reklam etiketi, analiz script’i veya üçüncü taraf API çağrısı varsa tarayıcı farklı alan adlarıyla ayrı TLS el sıkışmaları yapmak zorunda kalabilir.

Pratik kontrol listesi

• Gereksiz üçüncü taraf script’leri kaldırın veya erteleyin.
• Font dosyalarını mümkünse yerel sunucudan servis edin.
• Statik dosyaları sıkıştırın ve önbellekleme başlıklarını doğru ayarlayın.
• CDN kullanıyorsanız TLS ayarlarının origin ile uyumlu olduğundan emin olun.
• SSL yönlendirmelerinde zincirleme 301 hatası olmadığını kontrol edin.

Bir diğer sık hata, HTTP’den HTTPS’ye, ardından www veya non-www sürümüne birden fazla yönlendirme yapmaktır. Her yönlendirme ek bağlantı ve bekleme süresi oluşturabilir. Tek adımda doğru kanonik adrese yönlendirme yapılması daha sağlıklıdır.

Ölçüm yaparken nasıl ilerlenmeli?

Sağlıklı değerlendirme için farklı lokasyonlardan ve farklı saatlerde test yapılmalıdır. İlk ziyaret ile tekrar ziyaret ayrılmalı; çünkü oturum yeniden kullanımı aktifse ikinci bağlantı daha hızlı olabilir. Sadece tek bir araçtaki puana bakmak yerine TTFB, SSL negotiation, DNS ve TCP süreleri ayrı ayrı incelenmelidir.

Teknik ekip veya hizmet sağlayıcı ile görüşürken “site yavaş” demek yerine ölçülen TLS süresini, test lokasyonunu, saat aralığını ve kullanılan protokolü paylaşmak çözümü hızlandırır. Eğer sorun altyapı kaynaklıysa daha güncel web sunucusu, doğru TLS yapılandırması ve hedef kitleye yakın sunucu seçimi kalıcı iyileşme sağlayabilir. Bu aşamada mevcut hosting paketinin kaynakları, güvenlik özellikleri ve protokol desteği performans kararının merkezinde yer almalıdır.