HTTP/2.0 O kadar da ilgi çekici değil

Heryerde “http/2.0” çılgınlığı başlarken, http/1.x  üzerine ne gibi faydalar sağlayacağı konusunda biraz araştırma yaptım.

Açıkcası, http/2.0 benim için biraz hayal kırıklığı oldu.

HTTP/2.0 Neden hayalkırıklığı?

Öncelikle, böyle bir değişimi, HTTP/1.x den gelen alışkanlık üzerine, biz yazılımcıları ve web geliştiricilerini hatta servis sağlayacıları, en azından 20 yıl başka bir protokole geçmeden idare etmesi gerektiğini düşünüyorum.

Nasıl ki, http protokolü, gopher’ın yerini, SSH protokolü, TELNET, REXEC, RSH, gibi protokollerin yerini aldıysa, http/2.0 ‘ın, mimari değişikliklerle http/1.0 daki pek çok sorunu gidererek insanların hızlı bi şekilde kabul etmesini sağlamalıdır.

Fakat gördüğüm kadarıyla, ortada sadece 3 başlık dönmekte. HTTP/1.x ‘in session/cookie tabanlı çalışmasıyla güven açıklarına sebep olması, bir bağlantı üzerinden sadece bi istek kabul etmesi, ve bu yüzden tarayıcıların paralel istekler yapması (ki bu da belirli bir sınıra kadar çalışmaktadır), SPDY kabiliyetleri için ek moduller bileşenler gerektirmesi (ki bu da her tarayıcı/web serverda tam olarak desteklenmemektedir henüz).

HTTP protokolü üzerinden gönderilen ve istenilen tüm cookieler bantgenişliğinin büyük kısmını oluşturmaktadır. Özellikle gerekli gereksiz bıraklın cookieler, web serverların ziyaretçi bilgisayarlar üzerinde hakimiyeti olmamasından dolayı, ihtiyaç haline gelmiş, bazı kötü niyetli yaklaşımlarla bu cookieler elle değiştirilerek, güvenlik açıkları olarak kullanılmıştır. HTTP/2.0 protokol olarak geldiği için, konseptte tüm cookie yeteneklerini kaldırmalı, session/kimlik eşleştirmeli bir sistem kullanmalıdır. Fakat, geri dönüşlü destek maksadıyla, HTTP/2.0 cookieleri egale etmemektedir. Bu da cookielerin kullanımını azaltmayacağı, kaldırmayacağı için, “pek de yardımcı olmuyor” düşüncesi akla gelmektedir. Bu bağlamda da, HTTP/2.0 gerçekte sadece HTTP/1.x üzerinde bazı güncellemeler yaparak, ancak HTTP/1.2 kıvamında bir protokol olabilecektir.

“Load-balancing” meselesi

“Load Balancer” olarak adlandırdığımız sistemler/cihazlar/yazılımlar istekleri HTTP serverlar üzerine çözümlenmiş hostnameler arasında dağıtmakla yükümlüdür. Temel kriterleri “URI düzeni”, “Sunucu ulaşılabilirliği” ve bazen de nispeten “geo-lokasyon” tabanlı dağıtım yapmak üzerinedir[2].

Load balancer’lar yüksek trafik yoğunluğu görürler. HTTP server çiftliği üzerine bu trafiği dağıtırlar, ve elbette DoS türü ataklarda en çok etkilenenler olurlar.

Zamanla HTTP/2.0 standarlaştığında, Load balancerlar, 40Gb/s gibi bir trafikle muhattap olurken, 1TB/s trafikle yüzleşmeleri gerekecektir. Load balancerler içeriğin hiç bir kısmıyla muhattap olmayıp, sadece HTTP headerlarla işlem yaparlar, ve genellikle sadece durum (http status code) dönerler. Bant genişliğinin düşürülmesi yönündeki beklentilerden dolayı binary içerik, ve headerların içerikle beraber paket olarak transfer edilmesinden dolayı, HTTP/2.0 üzerinde IEFT[1] ‘nin load balancer’ların rolünü algılayabilecek bir implamantasyon geliştirmesi gerekir ki, load balancerlar işlevlerini tam olarak yerine getirebilsinler. Aksi halde HTTP/2.0 paketleri üzerinde cevap olarak ancak “null” veri dönebilecektir. Sırf HTTPS uygulanmasıyla HTTP load balancerlerın ihtiyacı azalmayacağı aşikar. Üstelik HTTP ve HTTPS karışık isteklerin uygulanması, ciddi soru işaretleri getirmektedir akla.

SPDY Mevzusu

SPDY yıllarca oldukça yol katetti ve “proof of concept” tarzında pek çok sürüm yayınlandı. Fakat yazılım geliştirmede benim de yöntem olarak gördüğüm üzere, “her zaman prototipi bir kenara at, sil baştan yaz, zira eninde sonunda bir kenara atılacaktır”

Buna istinaden, SPDY ‘nin tasarım yaklaşımı derinlemesine kusurlu buluyorum.

Örneğin; standartlaşmış HTTP headerları tanımlamak, ortalama 4byte uzunluğunda ve içerik texti ile, ve bunu deflate olarak sıkıştırıp bant genişliğinden tasarruf sağlamak, http load balancer’ların işlevlerini yerine getirmelerine engel olacaktır. HTTP load balancerların, headerları hızlı bir şekilde ayıklayıp işlem yapması gerekmektedir ki trafiği uygun şekilde, ekstra kaynak tüketmeden yönlendirebilsin.

Bu durum  SPDY ‘nin http 80 portu üzerinden verimli bir şekilde çalışamayacağı gerçeğini beraberinde getirirken, kendine özel tanımlanmış/adanmış bir portla ancak ekstra firewall kuralları/filtreleri getirecektir.

Elbette SPDY’nin DoS potansiyelini de unutmamak gerekir. Şüpheli trafiklerin bu protokol üzerinden ayıklanması da sunucu taraflı işlemler getirecektir.

Hız ve Mobil Uyumluluk

SPDY nin mobil uyumluluk konusunda ele alınıyor olması gerçekten beni şaşırtıyor. WebSocket’in gerçtekten mobil uyumlulukla tam olarak ilgisi olmadığı ortada. HTTP/2.0 başlığı altında ele alındığında, mobil uyumluluk sadece bant genişliği kullanımının azaltılması olarak lanse oluyor. Bu durumda SPDY, WebSocket uyumluluğunun HTTP/2.0 için bir artısı olduğunu da düşünmüyorum.

Sonuç

Tüm bunlar göz önünde bulundurulduğunda, “bir an önce çıkmasını bekliyorum!” diyemiyorum. HTTP/2.0 ile büyük sitelerin az miktarda olan bant genişliği tasarrufları genel HTTP kullanıcıları için yeterli yada positif bir kazanç sağlamayacaklardır.

İnternetteki HTTP/1.1  rolünü düşündüğümüzde, korkarım ki HTTP/2.0 ‘ın eksik ve yetersiz planlaması, kritik ihtiyaçlara olan yaklaşımı mutlaka yayını ve adaptasyonu geciktirecektir.

Bence, sil baştan, HTTP/2.0 ‘ın gerçekten ne yapması gerektiği konusuna eğilinmeli, basit bir tasarımla prototiplenmeli ve HTTP/1.x bu şekilde geride bırakılmalıdır.

 

[1]http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

[2] transport level işlev olmasına rağmen IPv6 ile birlikte  adaptasyonun gecikmesini önlemek için, es geçilmiştir[3].

[3] Şaka değil, ciddiyim.

 

This post is also available in: İngilizce

, , , , ,