http://www.bildirgec.org/ tr-tr 40 bildirgec.org - ofo - beğendikleri ofo <p>Google, “<a href="http://code.google.com/speed/">Let’s make the web faster</a>” vizyonu çerçevesinde pazara sürekli yeni ürünler/teknolojiler çıkartmaya devam ediyor.</p> <p><a href="http://dev.chromium.org/spdy/spdy-whitepaper">Şuradan</a> tamamını okuyabileceğiniz döküman ile HTTP protokolüne alternatif geliştirdiğini de öğrenmiş olduk.<br><div class="imajorta"><img src='http://www.bildirgec.org/imaj/cherry blossom girl/spdy.jpg' alt="\"\"" border="0"><br></div><br>Yeni protokole SPDY (SPeeDY şeklinde telaffuz ediliyor) ismini vermişler ve SSL üstünde çalışmasını sağlamışlar.</p> <p>SPDY protokolünün tanımını yaptıkları dokümanda, HTTP’nin şu limitlerinden bahsediyorlar;</p> <p><strong>Bağlantı başına tek istek</strong> : HTTP, aynı anda tek kaynak talep edebilir, getirebilir. HTTP protokolü aynı anda tek istekte bulunabiliyor ve bu istekleri FIFO (First In, First Out) mantığı ile kuyruğa alıp işliyor.</p> <p>tarayıcılar bu problemi çözebilmek için, aynı anda 2 bağlantı açıyorlardı, 2008 yılından beri hemen hemen tüm tarayıcılar, aynı anda bağlantı sayısını 6′ya çıkarttılar.</p> <p><strong>Sadece istemci istekte bulunabilir</strong>: HTTP protokolünde, sunucudan isteği sadece istemci yapabilir. Hatta sunucu, istemci’nin bir kaynağa ihtiyacı olduğunu bilse bile, istemci adına bu kaynağa erişip, sonucu istemciye döndüremez.</p> <p><strong>Request ve Response Header’larının sıkıştırılamaması</strong>: Günümüzde request header’larının boyutu, 200 bayt ile 2 kilobayt arasında değişiyor. Uygulamanızda cookie vs. kullanıyorsanız, boyut ortalama 700-800 bayt oluyor. Her isteğin (request) ve cevabın (response) headerında yer alan bilginin sıkıştırılmadan taşınması, önemli gecikmelere yol açmaktadır.</p> <p><strong>Gereksiz header bilgileri</strong>: Header’da hiç değişmeyecek bilgilerin (User-Agent, Host, Accept, … gibi) tekrar tekrar gönderilmesi gereksizdir. HTTP protokolü, bu bilgileri her isteğin ve cevabın headerına ekliyor.</p> <p><strong>Veri sıkıştırmasının varsayılan olmaması</strong>: HTTP protokolünde veri, varsayılan olarak sıkıştırılmamış formattadır. SPDY protokolünde Google, varsayılan olarak verinin tamamının sıkıştırılmış formatta olmasını sağlıyor.</p> <p>Yapılan ölçümlemeye göre, sunucundan yapılan yükleme işlemlerinin %50 azalması iki kat hızlı sörf deneyimi sunacaktır. Birkaç yüz milisaniye, tek bir kullanıcı için çok önemli olmasa da, aynı anda yüzlerce, binlerce, hatta milyonlarca kullanıcıya hizmet veren web sunucular için çok önemlidir.</p> <p>Google, SPDY protokolü ile tam olarak neyi hedefliyor?</p> <ul> <li>Tek TCP bağlantısında birden fazla HTTP (SPDY) isteği gerçekleştirebilmeyi</li> </ul> <ul> <li>Header’ın gereksiz kısımlarını silerek, kalan kısımlarını da sıkıştırarak, bandwith kullanımını azaltmayı</li> </ul> <ul> <li>Web sunucular açısından, HTTP protokolünden daha kolay uygulanabilir, işlenebilir olmasını</li> </ul> <ul> <li>Sunucunun, hazır olduğu zaman, istemciye veri gönderebilmesini.</li> </ul> <p>Ayrıca Google, web’in geleceğinde SSL’in anahtar rolü olduğuna inandığı için, SPDY protokolünü SSL üzerine kurmuş durumda.</p> <p>HTTP GET ve HTTP POST komutlarının değişmeden kalması öngörülüyor, fakat SPDY ile yeni komutların da geleceği haber veriliyor.</p> <p>Şu ana kadar Google, hafızada çalışan bir web sunucusu hazırlamış durumda, üstelik yakında açık kaynak olarak halka açmayı da planlıyor.</p> <p>Chrome browser’ının da hem HTTP, hem de SPDY protokollerini destekleyen bir sürümünü (kod adı “flip”) çıkartmışlar, <a href="http://src.chromium.org/viewvc/chrome/trunk/src/net/flip/">şuradan</a> kaynak kodlarını indirebilirsiniz.</p> <p>Bu prototipleri kullanarak yapılan testlerde ortaya çıkan sonuç;</p> <p>“Top 100″ listesinde yer alan 25 site, ev kullanıcısı bağlantı kapasitesini simule ederek, %1 paket kaybı ile 10′ar defa download edildi ve ortalamalar alındı.</p> <p><strong>SSL olmayan sitelerde hız artışı</strong> : %27 – %60 arasında,</p> <p><strong>SSL olan sitelerde hız artışı</strong> : %39 – %55 arasında.</p> <p>Bu sonuçlara rağmen, Google’ın tek başına başarıyı yakalaması çok zor. Mutlaka sektör’deki diğer büyük firmalar’ın SPDY protokolünü desteklemesi lazım.</p><p>Bu yazı <a href="http://www.bildirgec.org/uye/ofo">ofo</a> tarafından <a href=" http://www.bildirgec.org/yazi/google-http-protokolune-alternatif-olarak ">bildirgec.org</a> adresli sitede yayımlanmak üzere yazılmıştır. Kaynak gösterilmeksizin kopyalanamaz.</p><hr>Pilli Projeleri: <a href="http://pilli.com">Pilli.com: Kolektif Bağımsız İçerik</a> | <a href="http://sosyomat.com">Sosyomat.com: Arkadaşını Etiketle</a> | <a href="http://put.io">Put.io: Online Cloud Storage</a> Thu, 19 Nov 2009 15:09:00 GMT 227659@http://www.bildirgec.org/ http://www.bildirgec.org/yazi/google-http-protokolune-alternatif-olarak