HTTP/2, daha önce uygulamalarımızda yapılan HTTP/1.1 geçici çözümlerinin çoğunu geri almamıza ve taşıma katmanının kendisinde bu kaygıları gidermemize olanak tanıyarak, uygulamalarımızı daha hızlı, daha basit ve daha güçlü (ender bir kombinasyon) haline getirir. Daha da iyisi, uygulamalarımızı optimize etmek ve performansı artırmak için yepyeni fırsatların da önünü açıyor!
HTTP/2'nin birincil hedefleri, tam istek ve yanıt çoğaltmayı etkinleştirerek gecikmeyi azaltmak, HTTP başlık alanlarının etkili bir şekilde sıkıştırılması yoluyla protokol ek yükünü en aza indirmek ve istek önceliği ve sunucu aktarması için destek eklemektir. Bu gereksinimleri uygulamak için yeni akış denetimi, hata işleme ve yükseltme mekanizmaları gibi diğer protokol geliştirmelerini destekleyen çok sayıda destek ekibi bulunmaktadır. Ancak bunlar her web geliştiricisinin anlaması ve uygulamalarında yararlanacağı en önemli özelliklerdir.
HTTP/2, HTTP'nin uygulama anlamını hiçbir şekilde değiştirmez. HTTP yöntemleri, durum kodları, URI'ler ve başlık alanları gibi tüm temel kavramlar yerinde kalır. Bunun yerine HTTP/2, verilerin biçimlendirme (çerçevelenmiş) ve istemci ile sunucu arasında aktarılma şeklini değiştirir. Her ikisi de tüm süreci yönetir ve tüm karmaşıklığı yeni çerçeveleme katmanı içindeki uygulamalarımızdan gizler. Sonuç olarak, mevcut tüm uygulamalar değişiklik yapılmadan teslim edilebilir.
Neden HTTP/1.2 olmasın?
HTTP Çalışma Grubu tarafından belirlenen performans hedeflerine ulaşmak için HTTP/2, önceki HTTP/1.x sunucuları ve istemcileriyle geriye dönük uyumlu olmayan yeni bir ikili çerçeveleme katmanını kullanıma sunar. Bu nedenle ana protokol sürümü artışı, HTTP/2 olarak yapılır.
Bununla birlikte, ham TCP soketleriyle çalışarak bir web sunucusu (veya özel bir istemci) uygulamıyorsanız herhangi bir değişiklik görmezsiniz. Yeni, düşük seviyeli çerçevelemenin tamamı sizin adınıza istemci ve sunucu tarafından gerçekleştirilir. Gözlemlenebilir tek fark, daha iyi performans ve istek önceliği, akış denetimi ve sunucu aktarma gibi yeni özelliklerin kullanılabilirliği olacak.
SPDY ve HTTP/2'nin kısa geçmişi
SPDY, Google'da geliştirilen ve 2009 ortalarında duyurulan deneysel bir protokoldür. SPDY'nin ana hedefi, HTTP/1.1'in bilinen performans sınırlamalarından bazılarını ele alarak web sayfalarının yükleme gecikmesini azaltmaktır. Özetle, özetlenen proje hedefleri aşağıdaki gibi belirlendi:
- Sayfa yükleme süresini% 50 oranında azaltmayı (PLT) hedefleme.
- Web sitesi yazarlarının içerikte değişiklik yapma zorunluluğunu ortadan kaldırın.
- Dağıtım karmaşıklığını en aza indirin ve ağ altyapısında değişiklik yapılmasını önleyin.
- Açık kaynak topluluğuyla iş ortaklığı yaparak bu yeni protokolü geliştirin.
- Deneysel protokolü doğrulamak (geçersiz kılmak) için gerçek performans verileri toplama.
İlk duyurudan kısa bir süre sonra, her iki Google yazılım mühendisi Mike Belshe ve Roberto Peon yeni SPDY protokolünün deneysel uygulaması için ilk sonuçlarını, dokümanlarını ve kaynak kodlarını paylaştılar:
Şu ana kadar SPDY'yi yalnızca laboratuvar koşullarında test ettik. İlk sonuçlar çok cesaret verici: Ev ağı bağlantıları simülasyonu üzerinden en popüler 25 web sitesini indirdiğimizde performansta ciddi bir iyileşme olduğunu gördük. Sayfaların% 55'e kadar daha hızlı yüklendiğini gördük. (Chromium Blogu)
Hızlı bir şekilde 2012'ye gelindiğinde, yeni deneysel protokol Chrome, Firefox ve Opera'da desteklenmeye başladı ve altyapılarına SPDY dağıtımı yapan büyük (ör. Google, Twitter, Facebook) ve küçük çaplı çok sayıda site vardı. Aslında SPDY, sektörde giderek benimsenerek fiili bir standart haline gelme yolundaydı.
Bu trendi gözlemleyen HTTP Çalışma Grubu (HTTP-WG), SPDY'den alınan dersleri almak, bunları geliştirip iyileştirmek ve resmi bir "HTTP/2" standardı sunmak için yeni bir çaba başlattı. Yeni bir başlatma belgesi taslağı hazırlandı, HTTP/2 teklifleri için açık bir çağrı yapıldı ve çalışma grubu içindeki birçok tartışmadan sonra SPDY spesifikasyonu yeni HTTP/2 protokolü için başlangıç noktası olarak kabul edildi.
Sonraki birkaç yıl boyunca SPDY ve HTTP/2 paralel olarak gelişmeye devam etti. SPDY ise HTTP/2 standardına yönelik yeni özellikleri ve teklifleri test etmek için kullanılan deneysel bir dal olarak hizmet verdi. Kağıt üzerinde iyi görünen bir yaklaşım uygulamada işe yaramayabilir Sonunda, üç yıllık bu süreç sonucunda bir düzineden fazla ara taslak ortaya çıktı:
- Mart 2012: HTTP/2 için teklif çağrısı
- Kasım 2012: HTTP/2'nin ilk taslağı (SPDY'ye göre)
- Ağustos 2014: HTTP/2 taslak-17 ve HPACK taslak-12 yayınlandı
- Ağustos 2014: HTTP/2 için Çalışma Grubu'nun son çağrısı
- Şubat 2015: IESG, HTTP/2 ve HPACK taslaklarını onayladı
- Mayıs 2015: RFC 7540 (HTTP/2) ve RFC 7541 (HPACK) yayınlandı
2015'in başlarında IESG, yayın için yeni HTTP/2 standardını inceleyip onayladı. Bundan kısa bir süre sonra, Google Chrome ekibi TLS için SPDY ve NPN uzantısını kullanımdan kaldırma planını duyurdu:
HTTP/2'nin HTTP/1.1'den yapılan birincil değişiklikleri performansın artırılmasına odaklanır. Multiplexing, başlık sıkıştırma, öncelik belirleme ve protokol anlaşması gibi bazı temel özellikler, SPDY adlı daha eski açık ancak standart olmayan bir protokolde yapılan işten geliştirilmiştir. Chrome, SPDY'yi Chrome 6'dan beri desteklemektedir ancak avantajların çoğu HTTP/2'de mevcut olduğundan veda etmenin zamanı geldi. 2016'nın başlarında SPDY desteğini kaldırmayı ve aynı zamanda Chrome'da ALPN'yi destekleyen NPN adlı TLS uzantısı desteğini de kaldırmayı planlıyoruz. Sunucu geliştiricilerin HTTP/2 ve ALPN'ye geçmeleri önemle tavsiye edilir.
HTTP/2'ye yol açan açık standartlar sürecine katkıda bulunduğumuz için mutluyuz. Standartlaştırma ve uygulama konusunda sektördeki geniş katılım göz önüne alındığında, bu yaklaşımın geniş ölçüde benimsenmesini umuyoruz. (Chromium Blogu)
SPDY ile HTTP/2'nin birlikte evrimi, sunucu, tarayıcı ve site geliştiricilerinin yeni protokol geliştirilirken bu protokolle gerçek dünya deneyimi kazanmalarını sağladı. Sonuç olarak, HTTP/2 standardı henüz kullanıma sunulmamış en iyi ve en kapsamlı şekilde test edilen standartlardan biridir. HTTP/2, IESG tarafından onaylandığı zaman, kapsamlı olarak test edilmiş ve üretime hazır düzinelerce istemci ve sunucu uygulaması vardı. Aslında, son protokolün onaylanmasından yalnızca haftalar sonra, birçok popüler tarayıcı (ve birçok site) tam HTTP/2 desteği dağıttığı için birçok kullanıcı bu özelliğin avantajlarından yararlanmaya başlamıştı.
Tasarım ve teknik hedefler
HTTP protokolünün daha önceki sürümleri, uygulama kolaylığı sağlamak için kasıtlı olarak tasarlanmıştır: HTTP/0.9, Dünya Çapında Web'in önyüklemesini yapmak için kullanılan tek satırlı bir protokoldür; HTTP/1.0, HTTP/0.9'a yönelik popüler uzantıları bilgi amaçlı bir standartla belgelemiştir; HTTP/1.1, resmi bir IETF standardını kullanıma sunmuştur. HTTP'nin Özet Geçmişi bölümüne bakın. Bu nedenle, HTTP/0.9-1.x tam olarak amacını yerine getirmiştir: HTTP, internette en yaygın olarak kullanılan uygulama protokollerinden biridir.
Ne yazık ki uygulama basitliği, uygulama performansını da olumsuz etkiledi: HTTP/1.x istemcilerinin eşzamanlılık elde etmek ve gecikmeyi azaltmak için birden fazla bağlantı kullanması gerekir; HTTP/1.x, istek ve yanıt üst bilgilerini sıkıştırmaz ve bu da gereksiz ağ trafiğine neden olur. HTTP/1.x, etkili kaynak önceliklendirmesine izin vermez ve bu da temel TCP bağlantısının yetersiz kullanımına neden olur.
Bu sınırlamalar önemli değildi, ancak web uygulamaları gündelik hayatımızda kapsam, karmaşıklık ve önem açısından büyümeye devam ettikçe web'in hem geliştiricileri hem de kullanıcıları üzerinde gittikçe daha fazla yük oluşturdular. Bu da HTTP/2'nin ele almak üzere tasarlandığı boşluktur:
HTTP/2, başlık alanı sıkıştırma olanağı sunarak ve aynı bağlantı üzerinde birden fazla eşzamanlı değişime imkan tanıyarak ağ kaynaklarının daha verimli kullanılmasını ve gecikmenin daha az algılanmasını sağlar. Daha da özel olarak, istek ve yanıt mesajlarının aynı bağlantı üzerinde eklenmesine olanak tanır ve HTTP üst bilgisi alanları için etkili bir kodlama kullanır. Ayrıca isteklerin önceliklendirilmesi, daha önemli isteklerin daha hızlı tamamlanmasına imkan tanıyarak performansı daha da artırır.
Elde edilen protokol ağ için daha uygundur çünkü HTTP/1.x'e kıyasla daha az TCP bağlantısı kullanılabilir. Bu da diğer akışlarla ve daha uzun ömürlü bağlantılarda daha az rekabet anlamına gelir. Böylece mevcut ağ kapasitesi daha çok kullanılır. Son olarak HTTP/2, ikili mesaj çerçevelemesi sayesinde mesajların daha verimli bir şekilde işlenmesini sağlar. (Hypertext Transfer Protocol sürüm 2, Taslak 17)
HTTP/2'nin, önceki HTTP standartlarının yerini değil, kapsamını genişlettiğini unutmayın. HTTP'nin uygulama anlamları aynıdır ve sunulan işlevlerde ya da HTTP yöntemleri, durum kodları, URI'lar ve başlık alanları gibi temel kavramlarda herhangi bir değişiklik yapılmadı. Bu değişiklikler açıkça HTTP/2 çalışması kapsamında kapsam dışındadır. Bununla birlikte, üst seviye API aynı kalsa da alt düzey değişikliklerin, önceki protokollerin performans sınırlamalarını nasıl ele aldığını anlamak önemlidir. İkili çerçeveleme katmanı ve özelliklerine kısa bir göz atalım.
İkili çerçeveleme katmanı
HTTP/2'deki tüm performans geliştirmelerinin merkezinde, HTTP mesajlarının istemci ile sunucu arasında nasıl kapsülleneceğini ve aktarılacağını belirleyen yeni ikili çerçeveleme katmanı vardır.
"Katman", yuva arayüzü ve uygulamalarımızda gösterilen daha yüksek HTTP API'si arasında optimize edilmiş yeni bir kodlama mekanizmasının kullanıma sunulması için bir tasarım seçimi anlamına gelir: Fiiller, yöntemler ve başlıklar gibi HTTP anlamları etkilenmez, ancak aktarım sırasında bunların kodlanma şekli farklıdır. Yeni satırla sınırlandırılmış düz metin HTTP/1.x protokolünden farklı olarak, tüm HTTP/2 iletişimi, her biri ikili biçimde kodlanmış olan daha küçük mesajlara ve çerçevelere bölünür.
Sonuç olarak, hem istemci hem de sunucu birbirini anlamak için yeni ikili kodlama mekanizmasını kullanmalıdır: HTTP/1.x istemcisi yalnızca HTTP/2 sunucusunu anlamaz ve bunun tersi de geçerlidir. Neyse ki, istemci ve sunucu bizim adımıza tüm gerekli çerçeveleme işini yerine getirdiğinden, uygulamalarımız tüm bu değişikliklerden haberdar olmaya devam ediyor.
Akışlar, mesajlar ve çerçeveler
Yeni ikili çerçeveleme mekanizmasının kullanıma sunulmasıyla birlikte, istemci ile sunucu arasındaki veri alışverişi değiştirilmiştir. Bu süreci açıklamak için HTTP/2 terminolojisini tanıyalım:
- Akış: Kurulan bir bağlantı içinde bir veya daha fazla mesaj taşıyabilen, çift yönlü bayt akışı.
- Mesaj: Mantıksal bir istek veya yanıt mesajıyla eşlenen tam bir kare dizisi.
- Çerçeve: Her biri en azından çerçevenin ait olduğu akışı tanımlayan bir çerçeve başlığı içeren, HTTP/2'deki en küçük iletişim birimidir.
Bu terimlerin ilişkisi aşağıdaki gibi özetlenebilir:
- Tüm iletişim, herhangi bir sayıda çift yönlü akış taşıyabilen tek bir TCP bağlantısı üzerinden gerçekleştirilir.
- Her akışın, çift yönlü mesajları taşımak için kullanılan benzersiz bir tanımlayıcısı ve isteğe bağlı öncelik bilgileri vardır.
- Her mesaj, bir veya daha fazla çerçeveden oluşan, istek ya da yanıt gibi mantıksal bir HTTP mesajıdır.
- Çerçeve, belirli bir veri türünü (ör. HTTP üstbilgileri, ileti yükü vb. Farklı akışlardan alınan karelere araya eklenebilir ve ardından her karenin başlığındaki yerleşik akış tanımlayıcısı aracılığıyla yeniden birleştirilebilir.
Kısacası, HTTP/2, HTTP protokolü iletişimini ikili kodlamalı çerçevelere ayırır. Daha sonra bunlar, belirli bir akışa ait olan ve hepsi tek bir TCP bağlantısı içinde çoğaltılan mesajlarla eşlenir. Bu, HTTP/2 protokolünün sağladığı diğer tüm özelliklerin ve performans optimizasyonlarının etkinleştirilmesini sağlayan temeldir.
İstek ve yanıt çoğullama
HTTP/1.x'te, istemci performansı iyileştirmek için birden çok paralel istek yapmak isterse birden çok TCP bağlantısı kullanılmalıdır (bkz. Birden Çok TCP Bağlantısı Kullanma). Bu davranış, HTTP/1.x yayınlama modelinin doğrudan bir sonucudur. HTTP/1.x, aynı anda bağlantı başına yalnızca bir yanıtın verilebilmesini sağlar (yanıt sıraya ekleme). Daha da kötüsü, bu durum satır başı engellemeye ve temel TCP bağlantısının verimsiz kullanılmasına yol açar.
HTTP/2'deki yeni ikili çerçeveleme katmanı bu sınırlamaları ortadan kaldırır ve istemci ile sunucunun HTTP mesajını bağımsız çerçevelere ayırmasına, araya eklemesine ve daha sonra diğer tarafta yeniden birleştirmesine izin vererek tam istek ve yanıt çoğullamayı etkinleştirir.
Anlık görüntü, aynı bağlantı içinde yayındaki birden fazla akışı yakalar. İstemci sunucuya bir DATA çerçevesi (akış 5) iletirken sunucu da akış 1 ve 3 için istemciye araya eklemeli bir kare dizisi iletir. Bunun sonucunda, üç paralel akış devam ediyor.
Bir HTTP mesajını bağımsız çerçevelere bölme, birbirine ekleme ve diğer tarafta yeniden birleştirme özelliği HTTP/2'deki en önemli tek iyileştirmedir. Hatta tüm web teknolojileri yığınında sayısız performans avantajının dalga etkisi sunarak aşağıdakileri yapabilmemizi sağlar:
- Herhangi birini engellemeden birden fazla isteği paralel olarak ekleyin.
- Herhangi birini engellemeden birden fazla yanıtı paralel olarak ekleyin.
- Birbirine paralel olarak birden çok istek ve yanıt göndermek için tek bir bağlantı kullanın.
- Gereksiz HTTP/1.x geçici çözümlerini kaldırın (birleştirilmiş dosyalar, birleşik resimler ve alan parçalama gibi HTTP/1.x için optimize etme bölümüne bakın).
- Gereksiz gecikmeleri ortadan kaldırarak ve mevcut ağ kapasitesinden daha fazla verim alarak daha düşük sayfa yüklenme süreleri sağlayın.
- ve çok daha fazlası...
HTTP/2'deki yeni ikili çerçeveleme katmanı, HTTP/1.x'te bulunan başa baş engelleme sorununu çözer ve istek ve yanıtların paralel olarak işlenmesini ve yayınlanmasını sağlamak için çoklu bağlantı ihtiyacını ortadan kaldırır. Sonuç olarak bu, uygulamalarımızı daha hızlı, daha basit ve daha ucuz hale getiriyor.
Akış önceliği
Bir HTTP mesajı birçok bağımsız çerçeveye bölünebildiğinde ve birden fazla akışa ait karelerin çoğullamasına izin verildiğinde, karelerin hem istemci hem de sunucu tarafından araya eklendiği ve iletildiği sıra önemli bir performans unsuru haline gelir. HTTP/2 standardı bunu kolaylaştırmak için her bir akışın ilişkili bir ağırlığı ve bağımlılığına sahip olmasına izin verir:
- Her bir akışa 1 ile 256 arasında bir tam sayı ağırlığı atanabilir.
- Her akışa başka bir akışa açık bir bağımlılık verilebilir.
Akış bağımlılıklarının ve ağırlıklarının kombinasyonu, istemcinin yanıtları nasıl almayı tercih ettiğini ifade eden bir "önceliklendirme ağacı" oluşturmasına ve iletmesine olanak tanır. Buna karşılık sunucu; CPU, bellek ve diğer kaynakların tahsisini denetleyerek akış işlemeye öncelik vermek için bu bilgileri kullanabilir ve yanıt verileri kullanılabilir olduğunda, yüksek öncelikli yanıtların istemciye en uygun şekilde sunulmasını sağlamak için bant genişliğinin ayrılmasını sağlar.
HTTP/2 içindeki bir akış bağımlılığı, başka bir akışın benzersiz tanımlayıcısına üst öğe olarak başvuruda bulunularak tanımlanır. Tanımlayıcı atlanırsa akışın "kök akışa" bağlı olduğu söylenir. Bir akış bağımlılığı bildirilmesi, mümkünse üst akışa bağımlılıklarından önce kaynak ayrılması gerektiğini belirtir. Başka bir deyişle "Lütfen D yanıtını C yanıtından önce işleyip teslim edin".
Aynı üst öğeyi (diğer bir deyişle, kardeş akışları) paylaşan akışlara, ağırlıklarıyla orantılı kaynaklar tahsis edilmelidir. Örneğin, A akışının ağırlığı 12 ve bir kardeş B akışının ağırlığı 4 ise bu akışların her birinin alması gereken kaynakların oranını belirlemek için:
- Tüm ağırlıkları toplayın:
4 + 12 = 16 - Her akış ağırlığını toplam ağırlığa bölün:
A = 12/16, B = 4/16
Bu nedenle, A akışı dörtte üçlük, B akışı ise mevcut kaynakların dörtte birini almalı; B akışı ise A akışı için ayrılan kaynakların üçte birini almalıdır. Yukarıdaki resimde birkaç tane daha uygulamalı örnek üzerinde çalışalım. Soldan sağa:
- Ne A akışı ne de B bir ana bağımlılığı belirtmez ve örtülü "kök akışa" bağlı olduğu söylenir; A'nın ağırlığı 12, B'nin ağırlığı 4'tür. Bu nedenle, orantısal ağırlıklara göre: B akışı, A akışı için ayrılan kaynakların üçte birini almalıdır.
- D akışı kök akışına, C akışı D'ye bağlıdır. Bu nedenle D, kaynakların tamamını C'den önce alır. Ağırlıklar önemsizdir çünkü C'nin bağımlılığı daha güçlü bir tercih belirtir.
- D Akışı, C'den önce kaynakların tam tahsisini; C Akışı ise A ve B'den önce kaynakların tam tahsisini; B Akışı ise A akışına ayrılan kaynakların üçte birini alacaktır.
- D akışı, E ve C'den önce kaynakların tam tahsisini almalı; E ve C, A ve B'den önce eşit ayırma almalıdır. A ve B, ağırlıklarına göre orantılı bir ayırma almalıdır.
Yukarıdaki örneklerde de gösterildiği gibi, akış bağımlılıkları ve ağırlıklarının kombinasyonu, kaynak önceliklendirme için anlamlı bir dil sağlar. Bu, farklı bağımlılıklara ve ağırlıklara sahip birçok kaynak türüne sahip olduğumuzda göz atma performansını artırmak için kritik bir özelliktir. Daha da iyisi, HTTP/2 protokolü istemcinin bu tercihleri herhangi bir noktada güncellemesine de olanak tanır ve böylece tarayıcıda daha fazla optimizasyon yapılabilir. Başka bir deyişle, kullanıcı etkileşimi ve diğer sinyallere göre bağımlılıkları değiştirebilir ve ağırlıkları yeniden tahsis edebiliriz.
Kaynak başına bir bağlantı
Yeni ikili çerçeveleme mekanizması sayesinde, HTTP/2 artık paralel olarak Multiplex akışlar için birden fazla TCP bağlantısına ihtiyaç duymamaktadır. Her akış, araya eklenen ve öncelik atanabilen birçok çerçeveye bölünür. Sonuç olarak, tüm HTTP/2 bağlantıları kalıcıdır ve kaynak başına yalnızca bir bağlantı gerekir. Bu da performans açısından sayısız avantaj sağlar.
Hem SPDY hem de HTTP/2 için en etkili özellik, tıkanıklık kontrolü olan tek bir kanalda rastgele çoğullamadır. Bunun ne kadar önemli olduğu ve ne kadar iyi işlediği beni gerçekten şaşırtıyor. Bu konuda hoşuma giden en iyi metriklerden biri, yalnızca tek bir HTTP işlemi taşıyan (ve böylece bu işlemin tüm ek yükü taşımasını sağlayan) bağlantıların oranıdır. HTTP/1 için aktif bağlantılarımızın% 74'ü yalnızca tek bir işlem gerçekleştirir. Kalıcı bağlantılar hepimizin istediği kadar faydalı olmaz. Ancak HTTP/2'de bu sayı %25'e düşüyor. Genel giderlerin azaltılması açısından bu büyük bir kazanç. (HTTP/2 Firefox'ta Yayında, Patrick McManus)
Çoğu HTTP aktarımı kısa ve patlaklıyken TCP uzun ömürlü toplu veri aktarımları için optimize edilmiştir. HTTP/2, aynı bağlantıyı yeniden kullanarak her bir TCP bağlantısından daha verimli bir şekilde yararlanabilir ve ayrıca genel protokol ek yükünü önemli ölçüde azaltabilir. Ayrıca daha az bağlantının kullanılması, tam bağlantı yolunda (yani istemci, aracı ve kaynak sunucular) bellek ve işleme ayak izini azaltır. Bu, genel operasyonel maliyetleri azaltır ve ağ kullanımı ile kapasiteyi iyileştirir. Sonuç olarak, HTTP/2'ye geçiş yalnızca ağ gecikmesini azaltmakla kalmayacak, aynı zamanda işleme hızını iyileştirmeye ve operasyonel maliyetleri azaltmaya da yardımcı olacaktır.
Akış denetimi
Akış kontrolü, gönderenin istemeyebileceği veya işleyemeyeceği verilerle alıcıyı bunaltmasını engelleyen bir mekanizmadır: Alıcı meşgul veya çok fazla yük altında olabilir ya da belirli bir akış için yalnızca sabit miktarda kaynak tahsis etmeye istekli olabilir. Örneğin, istemci yüksek öncelikli büyük bir video akışı istemiş, ancak kullanıcı videoyu duraklatmış ve istemci artık gereksiz verilerin getirilmesini ve arabelleğe alınmasını önlemek için sunucudan yapılan yayınlamayı duraklatmak veya kısıtlamak istiyor olabilir. Alternatif olarak, bir proxy sunucu hızlı giriş akışına sahip olabilir ve yukarı akış bağlantılarını yavaşlatabilir ve benzer şekilde aşağı akışın, kaynak kullanımını kontrol etmek için yukarı akışın hızıyla eşleşecek şekilde veri teslim etme hızını düzenlemek isteyebilir ve bu böyle devam eder.
Yukarıdaki koşullar size TCP akış kontrolünü hatırlatıyor mu? Sorun, benzer bir sorun olduğu için bunların birbiriyle aynı olması gerekir (bkz. Akış Kontrolü). Ancak, HTTP/2 akışları tek bir TCP bağlantısı içinde çoğaltıldığı için TCP akış denetimi yeterince ayrıntılı değildir ve ayrı ayrı akışların yayınını düzenlemek için gerekli uygulama düzeyinde API'leri sağlamaz. HTTP/2, bu sorunu ele almak için istemci ile sunucunun kendi akış ve bağlantı düzeyinde akış denetimini uygulamaya olanak tanıyan bir dizi basit yapı taşı sunar:
- Akış kontrolü yönlüdür. Alıcıların her biri, her akış ve bağlantının tamamı için istediği herhangi bir pencere boyutunu ayarlamayı seçebilir.
- Akış kontrolü krediye dayalıdır. Her alıcı, ilk bağlantısını ve akış akışı kontrol penceresini (bayt cinsinden) tanıtır. Gönderen,
DATAkaresi yayınladığında kısalır ve alıcı tarafından gönderilen birWINDOW_UPDATEkaresi aracılığıyla artar. - Akış denetimi devre dışı bırakılamaz. HTTP/2 bağlantısı kurulduğunda, istemci ve sunucu değişimi
SETTINGSçerçevelerini kullanır. Bu da akış denetimi pencere boyutlarını her iki yönde de ayarlar. Akış denetimi penceresinin varsayılan değeri 65.535 bayt olarak ayarlanmıştır. Ancak alıcı, büyük bir maksimum pencere boyutu (2^31-1bayt) belirleyebilir ve herhangi bir veri alındığında birWINDOW_UPDATEçerçevesi göndererek bu boyutu koruyabilir. - Akış denetimi uçtan uca değil, atlamadan ibarettir. Diğer bir deyişle, bir aracı, kaynak kullanımını kontrol etmek ve kendi ölçütlerine ve bulgularına dayalı olarak kaynak tahsis mekanizmaları uygulamak için bu aracı kullanabilir.
HTTP/2, akış kontrolünü uygulamak için belirli bir algoritma belirtmez. Bunun yerine basit yapı taşlarını sağlar ve uygulamayı istemci ile sunucuya erteler. Böylece, kaynak kullanımını ve tahsisini düzenlemek için özel stratejiler uygulamak ve web uygulamalarımızın gerçek ve algılanan performansını (bkz. Hız, Performans ve İnsan Algısı) iyileştirebilecek yeni teslim yetenekleri uygulamak için kullanılır.
Örneğin, uygulama katmanı akış kontrolü, tarayıcının belirli bir kaynağın yalnızca bir kısmını getirmesini, akış akış denetimi penceresini sıfıra indirerek getirme işlemini beklemeye almasını ve daha sonra devam ettirmesini sağlar. Başka bir deyişle, tarayıcının bir resmin önizlemesini veya ilk taramasını getirmesine, görüntülemesine, diğer yüksek öncelikli getirmelerin devam etmesine izin vermesine ve daha önemli kaynakların yüklenmesi tamamlandığında getirme işlemine devam etmesine olanak tanır.
Sunucudan aktarma
HTTP/2'nin yeni ve güçlü bir özelliği de sunucunun tek bir istemci isteği için birden çok yanıt gönderebilmesidir. Yani, orijinal isteğe verilen yanıta ek olarak sunucu, istemcinin her birini açıkça istemek zorunda kalmadan istemciye ek kaynaklar aktarabilir (Şekil 12-5).
Bir tarayıcıda neden böyle bir mekanizmaya ihtiyacımız olur? Tipik bir web uygulaması, düzinelerce kaynaktan oluşur. Bu kaynakların tümü, sunucu tarafından sağlanan belge incelenerek istemci tarafından bulunur. Sonuç olarak, ek gecikmeyi ortadan kaldırıp sunucunun ilişkili kaynakları önceden aktarmasına izin vermeye ne dersiniz? Sunucu, istemcinin hangi kaynaklara ihtiyaç duyacağını zaten bilir; bu da sunucu aktarma işlemidir.
Aslında bir CSS, JavaScript veya başka bir öğeyi veri URI'si yoluyla satır içine aldıysanız (Kaynak Satırı İçine Ekleme bölümüne bakın) zaten sunucu aktarma konusunda uygulamalı bir deneyime sahipsiniz demektir. Kaynağı manuel olarak belgede satır içine alarak aslında istemcinin talep etmesini beklemeden bu kaynağı istemciye iletiriz. HTTP/2 ile aynı sonuçları sağlayabiliriz ancak ek performans avantajları sunar. İtme kaynakları şunlar olabilir:
- İstemci tarafından önbelleğe alındı
- Farklı sayfalarda tekrar kullanılmış
- Diğer kaynaklarla birlikte çok katmanlı
- Sunucu tarafından önceliklendirilir
- Müşteri tarafından reddedildi
PUSH_PROMISE 101
Tüm sunucu push akışları, PUSH_PROMISE çerçeveleri aracılığıyla başlatılır. Bu çerçeveler, sunucunun açıklanan kaynakları istemciye aktarma niyetine sinyal gönderir ve aktarılan kaynakları isteyen yanıt verilerinden önce sunulması gerekir. Bu teslimat siparişi kritik öneme sahiptir: İstemcinin, bu kaynaklar için yinelenen istekler oluşturmamak amacıyla sunucunun hangi kaynakları aktarmaya çalıştığını bilmesi gerekir. Bu gereksinimi karşılamak için en basit strateji, yalnızca söz edilen kaynağın HTTP üst bilgilerini içeren tüm PUSH_PROMISE karelerini üst kaynağın yanıtının (yani DATA kare) önüne göndermektir.
İstemci bir PUSH_PROMISE karesi aldığında, isterse akışı reddetme (RST_STREAM karesi aracılığıyla) seçeneğine sahiptir. (Bu durum, örneğin kaynağın zaten
önbelleğe alınmış olmasından kaynaklanabilir.) Bu, HTTP/1.x'e göre
önemli bir iyileştirmedir. Buna karşılık, HTTP/1.x için popüler bir "optimizasyon" olan kaynak satır içine alma kullanımı "zorunlu aktarmaya" eşdeğerdir: İstemci bu özelliği devre dışı bırakamaz, iptal edemez veya satır içi kaynağı tek tek işleyemez.
HTTP/2 ile istemci, sunucu push işleminin nasıl kullanıldığını tam olarak kontrol eder. İstemci, eşzamanlı olarak aktarılan akış sayısını sınırlayabilir, akış ilk açıldığında ne kadar verinin aktarıldığını kontrol etmek için ilk akış denetimi penceresini ayarlayabilir veya sunucu aktarımını tamamen devre dışı bırakabilir. Bu tercihler, HTTP/2 bağlantısının başındaki SETTINGS kareleri aracılığıyla iletilir ve herhangi bir zamanda güncellenebilir.
Aktarılan her kaynak, satır içi kaynağın aksine, bağımsız olarak çoğaltılmasına, önceliklendirilmesine ve istemci tarafından işlenmesine olanak tanıyan bir akıştır. Tarayıcı tarafından zorunlu kılınan tek güvenlik kısıtlaması, aktarılan kaynakların aynı kaynak politikasına uymasıdır: Sunucu, sağlanan içerik için yetkili olmalıdır.
Başlık sıkıştırma
Her HTTP aktarımı, aktarılan kaynağı ve özelliklerini açıklayan bir dizi üstbilgi içerir. HTTP/1.x'te bu meta veriler her zaman düz metin olarak gönderilir ve aktarım başına 500-800 bayt arasında bir ek yük ve HTTP çerezleri kullanılıyorsa bazen kilobayt daha fazla ekler. (Bkz. Protokol Ek Yükünü Ölçme ve Denetleme.) Bu ek yükü azaltmak ve performansı iyileştirmek için HTTP/2, iki basit ancak güçlü teknik kullanan HPACK sıkıştırma biçimini kullanarak istek ve yanıt başlığı meta verilerini sıkıştırır:
- İletilen üst bilgi alanlarının statik bir Huffman kodu aracılığıyla kodlanmasına olanak tanır ve böylece tekil aktarım boyutu küçültülür.
- Hem istemcinin hem de sunucunun, önceden görülen başlık alanlarının dizine eklenmiş bir listesini tutması ve güncellemesi (diğer bir deyişle, paylaşılan bir sıkıştırma bağlamı oluşturması) ve bu veri, daha sonra iletilen değerleri etkili bir şekilde kodlamak için bir referans olarak kullanılmasını gerektirir.
Huffman kodlaması, aktarılırken bağımsız değerlerin sıkıştırılmasına olanak tanır ve daha önce aktarılan değerlerin dizine eklenen listesi, tam başlık anahtarları ve değerlerini verimli bir şekilde aramak ve yeniden oluşturmak için kullanılabilecek dizin değerlerini aktararak yinelenen değerleri kodlamamıza olanak tanır.
Diğer bir optimizasyon olarak, HPACK sıkıştırma bağlamı statik ve dinamik bir tablodan oluşur: Statik tablo, spesifikasyonda tanımlanır ve tüm bağlantıların kullanabileceği yaygın HTTP üst bilgi alanlarının bir listesini (ör.geçerli başlık adları) sağlar. Dinamik tablo başlangıçta boştur ve belirli bir bağlantıdaki takas edilen değerlere göre güncellenir. Bunun sonucunda, daha önce görülmemiş değerler için statik Huffman kodlaması ve dizinlerin her iki taraftaki statik veya dinamik tablolarda zaten bulunan değerlerle değiştirilmesi kullanılarak her isteğin boyutu azaltılır.
HPACK güvenliği ve performansı
HTTP/2 ve SPDY'nin önceki sürümleri, tüm HTTP üst bilgilerini sıkıştırmak için özel bir sözlükle birlikte zlib'i kullanıyordu. Bu durum, aktarılan başlık verilerinin boyutunda% 85 ila% 88 oranında azalma ve sayfa yüklenme süresinde önemli bir iyileşme sağladı:
Yükleme bağlantısının yalnızca 375 Kb/sn olduğu düşük bant genişliğine sahip DSL bağlantısında, özellikle başlık sıkıştırma isteğinde bulunmak belirli sitelerde (diğer bir deyişle, çok sayıda kaynak isteği yayınlayanlar) sayfa yükleme süresinde önemli iyileşmeler sağladı. Sadece başlığın sıkıştırılması nedeniyle sayfa yükleme süresinde 45-1142 ms'lik bir azalma tespit ettik. (SPDY teknik belgesi, chromium.org)
Ancak 2012 yazında, TLS ve SPDY sıkıştırma algoritmalarına karşı bir "CRIME" güvenlik saldırısı yayınlandı. Bu durum, oturumların ele geçirilmesine neden olabilir. Bunun sonucunda, zlib sıkıştırma algoritmasının yerini, özellikle keşfedilen güvenlik sorunlarını gidermek, verimli ve basit bir şekilde uygulamak ve tabii ki HTTP üst bilgisi meta verilerinin iyi bir şekilde sıkıştırılmasını sağlamak amacıyla tasarlanan HPACK aldı.
HPACK sıkıştırma algoritmasıyla ilgili tüm ayrıntılar için IETF HPACK - HTTP/2 için Üstbilgi Sıkıştırma bölümüne bakın.
Daha fazla bilgi
- "HTTP/2" – Makalenin tamamı Ilya Grigorik tarafından hazırlanmıştır
- "HTTP/2 kurulumu" – Surma tarafından farklı arka uçlarda HTTP/2'yi ayarlama
- "HTTP/2 burada, optimizasyon yapalım!" – Velocity 2015'ten Ilya Grigorik tarafından yapılan sunum
- "HTTP/2 Push için Parmak Kuralları" – Push'un ne zaman ve nasıl kullanılacağı konusunda Tom Bergan, Simon Pelchat ve Michael Buettner tarafından yapılan bir analiz.