Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5

[-]
Tags
blokta yeni protokol http 2

HTTP / 2 - Blokta yeni protokol
#1
Gelecek zaten burada
İnternet, son 20 yılda derin biçimde gelişti. Yine de HTTP (1999 yılından beri kullanımda olan) hırsız değil.

Şimdiye kadar.

HTTP / 2 gelecek ve zaten burada. Standart henüz kesinleşti ve büyük tarayıcılar onu desteklemeye başladı. HTTP / 2'nin odak noktası performans, özellikle son kullanıcı tarafından algılanan gecikme süresi, ağ ve sunucu kaynağı kullanımı.

HTTP / 2'nin indirilmesindeki bu güzel demo dosyasını kontrol edin . Bu karşılaştırmada görebileceğiniz gibi çoklama gerçekten harika .

HTTP / 2 için temel hedefler şunlardır:

Tam istek ve yanıt çoklama özelliğini etkinleştirerek gecikmeyi azaltın
HTTP üstbilgi alanlarının etkin şekilde sıkıştırılması yoluyla protokol yükünü en aza indirin
İstek önceliklendirme ve sunucu itme desteği ekleyin
Ilya Grigorik en Kaydırma sunumu : HTTP / 2 geliyor, en optimize edelim! 
Ya da, dün en iyi uygulamaların (bugünün HTTP / 2 anti-kalıpları) neden (bazıları) oldukları.
Tek bir bağlantı
Bir ana hedef, tarayıcılardan web sitesine tek bir bağlantı kullanılmasına izin vermektir. Yüksek düzeyde, HTTP / 2 metinsel değil ikili haldedir ve engelleme yerine tamamen çoğullanmıştır. Dolayısıyla, yükü azaltmak için paralellik ve üstbilgi sıkıştırması için bir bağlantı kullanabilir. HTTP / 2, sunucuların istemci önbelleklerine proaktif bir şekilde yanıt gönderir.

HTTP / 2, iki özellikten oluşur: Köprü Metni Aktarım Protokolü sürüm 2 - RFC7540 ve HPACK - HTTP / 2 için üstbilgi sıkıştırması -  RFC7541 . IESG  resmen onayladı  HTTP / 2 ve  HPACK teknik özellikleri ve onlar için geliyorlarmış  RFC Editör yakında bazı editoryal süreçler geçmesi, RFC numaraları atanacaktır ve yayınlanacak.

Muhtemelen bildiğiniz gibi, HTTP / 1, onları pahalı hale getirdiğinden, web performans topluluğunun mantra " HTTP isteklerini önlemek " dir. HTTP / 2 ile spriting, satır içi yerleştirme, konstantifikasyon ve bu gibi teknikler artık gerekli olmamalıdır (bazı durumlarda alt-optimizasyonlara neden olabilirler). Tarayıcı, yanıt verilerini en iyi şekilde sunmak için sunucuya güvenir. Sadece bayt sayısı veya saniye başına talep değil, baytların teslim edilme sırası değil.

Tatlı HTTP / 2 avantajlarından bazıları şunlardır:

Çoklama ve eşzamanlılık: Aynı TCP bağlantısında birkaç ardışık istek gönderilebilir ve yanıtlar sipariş dışı alınabilir - istemci ve sunucu arasında çoklu bağlantıya duyulan gereksinim ortadan kalkar
Akım bağımlılıkları: İstemci hangi kaynaklardan diğerlerinden daha önemli olduğunu sunucuya gösterebilir
Başlık sıkıştırması: HTTP üstbilgi boyutu büyük ölçüde azaltılır
Sunucu itme: Sunucu, istemcinin henüz talep etmediği kaynakları gönderebilir
 

Tek bir HTTP / 2 bağlantısı, birden çok akışı açık akışlar içerebilir; uç noktaları birden çok akıştan çerçeveleri birbirine karıştırır.  Akışlar kurulabilir ve tek taraflı olarak kullanılabilir veya istemci veya sunucu tarafından paylaşılabilir ve bunlar herhangi bir uç nokta tarafından kapatılabilir.  Çerçevelerin bir akış içinde gönderilme sırası önemlidir.  Alıcılar, çerçeveleri aldığı sıraya göre işler.  Akışların çoğullaması, birçok akıştan gelen paketlerin aynı bağlantı üzerinden karıştırıldığı anlamına gelir.  İki (veya daha fazla) tek tek veri dizisi tek bir veri dizisine dönüştürülür ve daha sonra diğer taraftan tekrar bölünür.
 

Tek bir HTTP / 2 bağlantısı, birden çok akışı açık akışlar içerebilir; uç noktaları birden çok akıştan çerçeveleri birbirine karıştırır. Akışlar kurulabilir ve tek taraflı olarak kullanılabilir veya istemci veya sunucu tarafından paylaşılabilir ve bunlar herhangi bir uç nokta tarafından kapatılabilir. Çerçevelerin bir akış içinde gönderilme sırası önemlidir. Alıcılar, çerçeveleri aldığı sıraya göre işler. Akışların çoğullaması, birçok akıştan gelen paketlerin aynı bağlantı üzerinden karıştırıldığı anlamına gelir. İki (veya daha fazla) tek tek veri dizisi tek bir veri dizisine dönüştürülür ve daha sonra diğer taraftan tekrar bölünür.

Web uygulaması dağıtımını optimize etme
Uygulamaları daha hızlı, daha basit ve daha sağlam yapmaya ne dersiniz? HTTP / 2, daha önce uygulamalarla yapılan birçok HTTP / 1.1 geçici çözümünü geri almanıza ve bu endişeleri taşıma katmanı içinde çözmenize izin vererek gerçekleşir.

HTTP / 1.x, "satır başı engelleme" adı verilen, bir seferde yalnızca bir isteğin bir bağlantıda bekletilebileceği bir sorunu vardır. HTTP / 1.1 , bunu boruhattı ile düzeltmeyi denedi , ancak sorunu tam olarak ele almadı (büyük veya yavaş bir yanıt hala diğerlerinin önünü tıkayabilir). Bu, istemcileri hangi bağlantıların kökene ne zaman bağlanacağını belirlemek için çeşitli buluşsal yöntemler (sıklıkla tahmin ediliyor) kullanmaya zorlar.

Bir sayfanın mevcut bağlantıların on katına veya daha fazlasına yüklenmesi yaygın olduğu için, bu durum performansı ciddi şekilde etkileyebilir - sıklıkla engellenen isteklerin şelale çıkarılmasına neden olur. Çoklama, birden fazla istek ve yanıt mesajının aynı anda uçuşa gelmesine izin vererek bu problemleri giderir. Bir mesajın bir bölümünü tel üzerinde başka bir mesajın parçası ile karıştırmak bile mümkündür. Bu da, bir müşterinin bir sayfa yüklemek için menşe başına sadece bir bağlantı kullanmasına izin verir.

Her zaman önbelleğe almayı başardık, ancak küçük istemler çok pahalı olduğu için, bozulma (önbellekte baytların yeni bir güncelleme yaparken getirmesi gereken yeni oranla oranı) için hiçbir zaman optimizasyon yapamadık. Artık böyle değil.

HTTP / 2 daha önce mümkün değildi uygulamaları artırabilen yeni optimizasyonlar, bir dizi sağlar ve zaten aştı spdy kabulü. Chrome, 2016'nın başında SPDY'yi (ve NPN'yi) istifade edemez.

Chrome'da yeni TLS + NPN / ALPN bağlantıları (26 Mayıs 2015 - Chrome telemetri):

~% 27 pazarlık HTTP / 1

~% 28 pazarlık SPDY / 3.1

~ 45% HTTP / 2 müzakere

Web sitelerinizi veya uygulamalarınızı düzgün çalışmaya devam etmelerini sağlamak için değiştirmeniz gerekmez. HTTP / 2, protokolün ilk kez yeniden yazılması değildir. HTTP yöntemleri, durum kodları ve semantikler aynıdır ve protokolü temsil etmek için HTTP / 1.x ile aynı API'ları (muhtemelen bazı küçük eklemelerle birlikte) kullanmak da mümkün olmalıdır. Tüm temel kavramlar (HTTP yöntemleri, durum kodları, URI'ler ve üstbilgi alanları gibi) yerinde kalır. Bunun yerine, HTTP / 2, verilerin nasıl formatlandıracağını (çerçeve içine alınır) ve istemci ile sunucu arasında taşınır ve her ikisi de tüm işlemi yönetir ve tüm karmaşıklığı yeni çerçeveleme katmanı içerisindeki uygulamalardan gizler.

Sonuç olarak, mevcut tüm uygulamalar değiştirilmeden teslim edilebilir. Uygulama kodunuz ve HTTP API'larınız kesintisiz çalışmaya devam edecektir. Başvurunuz muhtemelen daha iyi performans gösterecek ve hem istemci hem de sunucu üzerinde daha az kaynak tüketecektir. Tüm çerçeveler (örn. Üstbilgiler, veri vb.) Tek TCP bağlantısı üzerinden gönderilir ve çerçeve iletimi, akış bağımlılıklarına ve ağırlıklara dayalı olarak önceliklendirilir. VERİ çerçeveleri akış başına ve bağlantı akışı denetimine tabidir.

Iyi kullanılan teknoloji
"Tüm Firefox (M36) HTTP işlemlerinin% 9'u HTTP / 2 üzerinden gerçekleşiyor. Aslında SPDY olanlardan daha fazla HTTP / 2 bağlantısı var. Mozilla'daki Platform Yazılım Mühendisi Patrick McManus , "Bu iyi uygulanan bir teknolojidir" diye ekliyor ve yükü azaltmak için büyük bir kazanma hakkında ekliyor:

"Hoşuma gittiğimden büyük bir metrik, yalnızca tek bir HTTP işlemini gerçekleştiren bağlantıların fraksiyonudur (ve dolayısıyla bu işlemin üstesinden gelinir). HTTP / 1 için, etkin bağlantılarımızın% 74'ü yalnızca tek bir işlemi taşır - kalıcı bağlantılar sadece hepimizin istediği kadar yararlı değildir. Ancak HTTP / 2'de bu sayı% 25'e düştü. "

HTTP / 3 ve sonrası
 

Müşterilerin ve sunucuların, bu yeni protokolün sunduğu tüm güçlerden gerçekten yararlanmak için uygulamaların düzeltilmesini görmeye başlamadık, ancak bunun, daha hızlı sayfa yüklemelerine ve daha duyarlı web sitelerine yol açması ihtimali çok iyi.

Kısaca: daha iyi web deneyimi.

" İnternetin hızını arttırmak için RTT'yi düşürmenin başka yollarını aramalıyız . Atlantik çapraz RTT'leri 150 ms'den 100 ms'e düşürürsek ne olur? BitGo'nun kurucu ortağı ve CEO'su Mike Belshe , bu, İnternet'in hızı üzerinde 3.9 Mbps'den 10 Mbps'ye hatta bir Gbps'ye kadar bir kullanıcının bant genişliğini arttırmaktan daha büyük bir etkiye sahip olacağını söyledi .

Google'daki Geliştirici Savunucusu Ilya Grigorik , masaüstünde ve mobilde tutarlı bir şekilde 100 ms işleme süresi olan bir dünyanın hayalini kuruyor. Rüyayı gerçekleştirmek için daha iyi İnternet altyapısı kurmaya yardımcı oluyor ve kapsamlı ücretsiz çevrimiçi kitabında daha fazlasını okuyabiliyor (ve yapmalıdır) .

Şu anda, insanlar HTTP / 2'yi kapıdan çıkarmaya çok heveslidir ve bu sayede performansı artırmak için TLS sertifikalarını ve DNS girdilerini istemciye bastırmak gibi daha gelişmiş ve deneysel özellikler bırakılmıştır. Denemeler iyi giderse, HTTP / 3 bunları içerebilir. Fakat şimdilik, yeni protokolü kutu üzerinde kutlayalım.

Emin misiniz
Ara
Cevapla
Teşekkür eden:


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Google'a göre en yaygın 5 HTTP hatası harunergenc.com@gmail.com 0 49 04-06-2017, Saat: 13:42
Son Yorum: harunergenc.com@gmail.com

Hızlı Menü:


Konuyu Okuyanlar: 1 Ziyaretçi