HTTP/1.1 ve HTTP/2: Fark Nedir?
Köprü Metni Aktarım Protokolü veya HTTP, 1989’daki icadından bu yana World Wide Web’de iletişim için fiili standart olan bir uygulama protokolüdür. 1997’de HTTP/1.1’in piyasaya sürülmesinden yakın zamana kadar protokolde çok az revizyon yapıldı. Ancak 2015 yılında, özellikle mobil platformlar ve sunucu yoğun grafikler ve videolarla uğraşırken gecikmeyi azaltmak için çeşitli yöntemler sunan HTTP/2 adlı yeniden tasarlanmış bir sürüm kullanıma girdi. HTTP/2 o zamandan beri giderek daha popüler hale geldi ve bazı tahminler dünyadaki tüm web sitelerinin yaklaşık üçte birinin bunu desteklediğini gösteriyor. Bu değişen ortamda, web geliştiricileri HTTP/1.1 ve HTTP/2 arasındaki teknik farkları anlamaktan yararlanabilir ve gelişen en iyi uygulamalar hakkında bilinçli ve verimli kararlar almalarına olanak tanır.
Bu makaleyi okuduktan sonra, HTTP/1.1 ve HTTP/2 arasındaki temel farkları anlayacak ve HTTP/2’nin daha verimli bir Web protokolü elde etmek için benimsediği teknik değişikliklere odaklanacaksınız.
Arka plan
HTTP/2’nin HTTP/1.1’de yaptığı belirli değişiklikleri bağlamsallaştırmak için, önce her birinin tarihsel gelişimine ve temel işleyişine üst düzey bir göz atalım.
HTTP/1.1
1989 yılında Timothy Berners-Lee tarafından World Wide Web için bir iletişim standardı olarak geliştirilen HTTP, bir istemci bilgisayar ile yerel veya uzak bir web sunucusu arasında bilgi alışverişi yapan üst düzey bir uygulama protokolüdür. Bu işlemde, bir istemci veya gibi bir yöntemi çağırarak bir sunucuya metin tabanlı bir istek gönderir. Yanıt olarak sunucu, istemciye HTML sayfası gibi bir kaynak gönderir.GETPOST
Örneğin, alan adında bir web sitesini ziyaret ettiğinizi varsayalım. Bu URL’ye gittiğinizde, bilgisayarınızdaki web tarayıcısı burada gösterilene benzer şekilde metin tabanlı bir mesaj biçiminde bir HTTP isteği gönderir:www.example.com
GET /index.html HTTP/1.1
Host: www.example.com
Bu istek, ‘den sonra listelenen ana bilgisayar sunucusundan veri isteyen yöntemi kullanır. Bu isteğe yanıt olarak, web sunucusu, HTML’de çağrılan resimlere, stil sayfalarına veya diğer kaynaklara ek olarak istekte bulunan istemciye bir HTML sayfası döndürür. İlk veri çağrısında tüm kaynakların istemciye döndürülmediğini unutmayın. İstekler ve yanıtlar, web tarayıcısı ekranınızdaki HTML sayfasının içeriğini oluşturmak için gerekli tüm kaynakları alana kadar sunucu ve istemci arasında gidip gelecektir.GETHost:example.com
Bu istek ve yanıt alışverişini, aktarım katmanının (genellikle İletim Kontrol Protokolü veya TCP kullanarak) ve ağ katmanlarının (İnternet Protokolü veya IP kullanarak) üzerinde oturan internet protokolü yığınının tek bir uygulama katmanı olarak düşünebilirsiniz:
Bu yığının alt seviyeleri hakkında tartışılacak çok şey var, ancak HTTP/2 hakkında üst düzey bir anlayış kazanmak için yalnızca bu soyutlanmış katman modelini ve HTTP’nin nerede yer aldığını bilmeniz gerekir.
HTTP/1.1’e bu temel genel bakıştan sonra, şimdi HTTP/2’nin erken gelişimini anlatmaya geçebiliriz.
HTTP/2 (İngilizce)
HTTP/2, sıkıştırma, çoğullama ve önceliklendirme gibi teknikleri kullanarak web sayfası yükleme gecikmesini azaltmak amacıyla öncelikle Google’da geliştirilen SPDY protokolü olarak başladı. Bu protokol, IETF’nin (İnternet Mühendisliği Görev Gücü) Köprü Metni Aktarım Protokolü çalışma grubu httpbis, standardı bir araya getirdiğinde HTTP/2 için bir şablon görevi gördü ve Mayıs 2015’te HTTP/2’nin yayınlanmasıyla sonuçlandı. En başından beri, Chrome, Opera, Internet Explorer ve Safari dahil olmak üzere birçok tarayıcı bu standardizasyon çabasını destekledi. Kısmen bu tarayıcı desteği nedeniyle, 2015’ten bu yana protokolün önemli bir benimsenme oranı olmuştur ve özellikle yeni siteler arasında yüksek oranlar vardır.
Teknik açıdan bakıldığında HTTP/1.1 ve HTTP/2’yi birbirinden ayıran en önemli özelliklerden biri, internet protokol yığınında uygulama katmanının bir parçası olarak düşünülebilecek ikili çerçeveleme katmanıdır. Tüm istekleri ve yanıtları düz metin biçiminde tutan HTTP/1.1’in aksine, HTTP/2, fiiller, yöntemler ve başlıklar gibi HTTP semantiğini korurken tüm iletileri ikili biçimde kapsüllemek için ikili çerçeveleme katmanını kullanır. Uygulama düzeyinde bir API, geleneksel HTTP biçimlerinde iletiler oluşturmaya devam eder, ancak temel katman daha sonra bu iletileri ikili dosyalara dönüştürür. Bu, HTTP/2’den önce oluşturulan web uygulamalarının yeni protokolle etkileşim kurarken normal şekilde çalışmaya devam edebilmesini sağlar.
Mesajların ikiliye dönüştürülmesi, HTTP/2’nin HTTP/1.1’de bulunmayan veri teslimine yönelik yeni yaklaşımları denemesine olanak tanır, bu da iki protokol arasındaki pratik farklılıkların kökeninde yer alan bir karşıtlıktır. Bir sonraki bölümde, HTTP/1.1’in dağıtım modeline ve ardından HTTP/2’nin hangi yeni modellerin mümkün olduğuna göz atılacaktır.
Teslimat Modelleri
Önceki bölümde belirtildiği gibi, HTTP/1.1 ve HTTP/2 semantiği paylaşır ve her iki protokolde de sunucu ve istemci arasında dolaşan isteklerin ve yanıtların, ve gibi tanıdık yöntemler kullanılarak üst bilgiler ve gövdeler içeren geleneksel olarak biçimlendirilmiş iletiler olarak hedeflerine ulaşmasını sağlar. Ancak HTTP/1.1 bunları düz metin mesajlarına aktarırken, HTTP/2 bunları ikili olarak kodlayarak önemli ölçüde farklı dağıtım modeli olanaklarına izin verir. Bu bölümde, öncelikle HTTP/1.1’in dağıtım modeli ile verimliliği nasıl optimize etmeye çalıştığını ve bundan kaynaklanan sorunları kısaca inceleyeceğiz, ardından HTTP/2’nin ikili çerçeveleme katmanının avantajlarını ve istekleri nasıl önceliklendirdiğinin bir açıklamasını yapacağız.GETPOST
HTTP/1.1 — Boru Hattı ve Hat Başı Engelleme
Bir istemcinin HTTP isteğinde aldığı ilk yanıt genellikle tam olarak işlenmiş sayfa değildir. Bunun yerine, istenen sayfanın ihtiyaç duyduğu ek kaynaklara bağlantılar içerir. İstemci, sayfanın tam olarak işlenmesi için sunucudan bu ek kaynakları gerektirdiğini ancak sayfayı indirdikten sonra keşfeder. Bu nedenle, istemcinin bu kaynakları almak için ek isteklerde bulunması gerekir. HTTP/1.0’da, istemci her yeni istekte TCP bağlantısını kesmek ve yeniden yapmak zorunda kaldı, bu hem zaman hem de kaynak açısından maliyetli bir işti.GET
HTTP/1.1, kalıcı bağlantılar ve ardışık düzen sunarak bu sorunu çözer. Kalıcı bağlantılarda HTTP/1.1, doğrudan kapatılması söylenmedikçe bir TCP bağlantısının açık tutulması gerektiğini varsayar. Bu, istemcinin her birine yanıt beklemeden aynı bağlantı üzerinden birden çok istek göndermesine olanak tanır ve HTTP/1.1’in HTTP/1.0 üzerindeki performansını büyük ölçüde artırır.
Ne yazık ki, bu optimizasyon stratejisinde doğal bir darboğaz var. Birden çok veri paketi aynı hedefe giderken birbirini geçemediğinden, kuyruğun başındaki gerekli kaynağı alamayan bir isteğin arkasındaki tüm istekleri engelleyeceği durumlar vardır. Bu, hat başı (HOL) engelleme olarak bilinir ve HTTP/1.1’de bağlantı verimliliğini optimize etmeyle ilgili önemli bir sorundur. Ayrı, paralel TCP bağlantıları eklemek bu sorunu hafifletebilir, ancak istemci ile sunucu arasında olası eşzamanlı TCP bağlantılarının sayısının sınırları vardır ve her yeni bağlantı önemli miktarda kaynak gerektirir.
Bu sorunlar, bir sonraki bölümde daha fazla bilgi edineceğiniz bir konu olan bu sorunları çözmek için yukarıda bahsedilen ikili çerçeveleme katmanını kullanmayı öneren HTTP/2 geliştiricilerinin zihninde ön plandaydı.
HTTP/2 — İkili Çerçeveleme Katmanının Avantajları
HTTP/2’de, ikili çerçeveleme katmanı istekleri/yanıtları kodlar ve bunları daha küçük bilgi paketlerine bölerek veri aktarımının esnekliğini büyük ölçüde artırır.
Bunun nasıl çalıştığına daha yakından bakalım. HOL engellemenin etkisini azaltmak için birden çok TCP bağlantısı kullanması gereken HTTP/1.1’in aksine, HTTP/2 iki makine arasında tek bir bağlantı nesnesi oluşturur. Bu bağlamda, birden fazla veri akışı vardır. Her akış, tanıdık istek/yanıt biçiminde birden çok iletiden oluşur. Son olarak, bu mesajların her biri çerçeve adı verilen daha küçük birimlere bölünür:
En ayrıntılı düzeyde, iletişim kanalı, her biri belirli bir akışa etiketlenmiş bir grup ikili kodlu çerçeveden oluşur. Tanımlayıcı etiketler, bağlantının aktarım sırasında bu çerçeveleri serpiştirmesine ve diğer uçta yeniden birleştirmesine izin verir. Araya eklenen istekler ve yanıtlar, arkalarındaki iletileri engellemeden paralel olarak çalışabilir, bu işlem çoğullama adı verilir. Çoğullama, hiçbir iletinin başka bir iletinin bitmesini beklemesini sağlayarak HTTP/1.1’deki satır başı engelleme sorununu çözer. Bu aynı zamanda sunucuların ve istemcilerin eşzamanlı istekler ve yanıtlar gönderebileceği anlamına gelir, bu da daha fazla kontrol ve daha verimli bağlantı yönetimi sağlar.
Çoğullama, istemcinin paralel olarak birden çok akış oluşturmasına izin verdiğinden, bu akışların yalnızca tek bir TCP bağlantısı kullanması gerekir. Kaynak başına tek bir kalıcı bağlantıya sahip olmak, ağ genelinde bellek ve işlem ayak izini azaltarak HTTP/1.1’i geliştirir. Bu, daha iyi ağ ve bant genişliği kullanımı ile sonuçlanır ve böylece genel işletme maliyetini azaltır.
İstemci ve sunucu aynı güvenli oturumu birden çok istek/yanıt için yeniden kullanabildiğinden, tek bir TCP bağlantısı HTTPS protokolünün performansını da artırır. HTTPS’de, TLS veya SSL el sıkışması sırasında, her iki taraf da oturum boyunca tek bir anahtarın kullanılması konusunda anlaşır. Bağlantı kesilirse, daha fazla iletişim için yeni oluşturulan bir anahtar gerektiren yeni bir oturum başlar. Bu nedenle, tek bir bağlantının sürdürülmesi, HTTPS performansı için gereken kaynakları büyük ölçüde azaltabilir. HTTP/2 belirtimleri TLS katmanını kullanmayı zorunlu kılmasa da, birçok büyük tarayıcının yalnızca HTTPS ile HTTP/2’yi desteklediğini unutmayın.
İkili çerçeveleme katmanında bulunan çoğullama, HTTP/1.1’in belirli sorunlarını çözse de, aynı kaynağı bekleyen birden çok akış yine de performans sorunlarına neden olabilir. HTTP/2’nin tasarımı bunu dikkate alır, ancak bir sonraki bölümde tartışacağımız bir konu olan akış önceliklendirmesini kullanarak.
HTTP/2 — Akış Önceliklendirme
Akış önceliklendirme yalnızca aynı kaynak için rekabet eden isteklerin olası sorununu çözmekle kalmaz, aynı zamanda geliştiricilerin uygulama performansını daha iyi optimize etmek için isteklerin göreli ağırlığını özelleştirmesine de olanak tanır. Bu bölümde, HTTP/2’nin bu özelliğinden nasıl yararlanabileceğiniz konusunda daha iyi bir fikir sağlamak için bu önceliklendirme sürecini inceleyeceğiz.
Artık bildiğiniz gibi, ikili çerçeveleme katmanı, mesajları paralel veri akışları halinde düzenler. Bir istemci bir sunucuya eşzamanlı istekler gönderdiğinde, her akışa 1 ile 256 arasında bir ağırlık atayarak istediği yanıtlara öncelik verebilir. Daha yüksek sayı, daha yüksek önceliği gösterir. Buna ek olarak, istemci, bağımlı olduğu akışın kimliğini belirterek her akışın başka bir akışa bağımlılığını da belirtir. Üst tanımlayıcı atlanırsa, akışın kök akışa bağımlı olduğu kabul edilir. Bu, aşağıdaki şekilde gösterilmiştir:
Çizimde kanal, her biri benzersiz bir kimliğe sahip ve belirli bir ağırlıkla ilişkilendirilmiş altı akış içerir. Akış 1’in kendisiyle ilişkilendirilmiş bir üst kimliği yoktur ve varsayılan olarak kök düğümle ilişkilendirilir. Diğer tüm akışların bazı ebeveyn kimlikleri işaretlenmiştir. Her akış için kaynak tahsisi, sahip oldukları ağırlığa ve ihtiyaç duydukları bağımlılıklara bağlı olacaktır. Örneğin, şekilde aynı ağırlığa ve aynı ana akışa atanmış olan 5 ve 6 numaralı akışlar, kaynak tahsisi için aynı önceliğe sahip olacaktır.
Sunucu bu bilgileri, isteklerin verilerini alacağı sırayı belirlemesine olanak tanıyan bir bağımlılık ağacı oluşturmak için kullanır. Önceki şekilde yer alan akışlara bağlı olarak, bağımlılık ağacı aşağıdaki gibi olacaktır:
Bu bağımlılık ağacında, akış 1 kök akışa bağımlıdır ve kökten türetilen başka bir akış yoktur, bu nedenle kullanılabilir tüm kaynaklar diğer akışlardan önce akış 1’e ayrılır. Ağaç, akış 2’nin akış 1’in tamamlanmasına bağlı olduğunu gösterdiğinden, akış 2, akış 1 görevi tamamlanana kadar devam etmeyecektir. Şimdi 3. ve 4. akışlara bakalım. Bu akışların her ikisi de akış 2’ye bağlıdır. Akış 1’de olduğu gibi, akış 2, mevcut tüm kaynakları akış 3 ve 4’ten önce alacaktır. Akış 2 görevini tamamladıktan sonra, akış 3 ve 4 kaynakları alacaktır; Bunlar, ağırlıklarına göre gösterildiği gibi 2:4 oranında bölünür ve bu da Akış 4 için daha yüksek bir kaynak yığını ile sonuçlanır. Son olarak, akış 3 bittiğinde, akış 5 ve 6 mevcut kaynakları eşit parçalar halinde alacaktır. Bu, akış 4 daha yüksek bir kaynak yığını alsa bile, akış 4 görevini tamamlamadan önce gerçekleşebilir; Daha düşük bir seviyedeki akışların, bir üst seviyedeki bağımlı akışlar biter bitmez başlamasına izin verilir.
Bir uygulama geliştiricisi olarak, isteklerinizdeki ağırlıkları ihtiyaçlarınıza göre ayarlayabilirsiniz. Örneğin, web sayfasında bir küçük resim sağladıktan sonra yüksek çözünürlüklü bir görüntünün yüklenmesi için daha düşük bir öncelik atayabilirsiniz. HTTP/2, bu ağırlık atama olanağını sağlayarak, geliştiricilerin web sayfası oluşturma üzerinde daha iyi kontrol sahibi olmalarını sağlar. Protokol ayrıca istemcinin, kullanıcı etkileşimine yanıt olarak çalışma zamanında bağımlılıkları değiştirmesine ve ağırlıkları yeniden tahsis etmesine olanak tanır. Bununla birlikte, belirli bir akışın belirli bir kaynağa erişimi engellenirse, bir sunucunun atanan öncelikleri kendi başına değiştirebileceğini unutmamak önemlidir.
Arabellek Taşması
İki makine arasındaki herhangi bir TCP bağlantısında, hem istemci hem de sunucu, henüz işlenmemiş gelen istekleri tutmak için belirli bir miktarda arabellek alanına sahiptir. Bu arabellekler, aşağı akış ve yukarı akış bağlantılarının eşit olmayan hızlarına ek olarak çok sayıda veya özellikle büyük istekleri hesaba katma esnekliği sunar.
Bununla birlikte, bir tamponun yeterli olmadığı durumlar vardır. Örneğin, sunucu, sınırlı bir arabellek boyutu veya daha düşük bir bant genişliği nedeniyle istemci uygulamasının başa çıkamayacağı bir hızda büyük miktarda veri gönderiyor olabilir. Benzer şekilde, bir istemci bir sunucuya büyük bir görüntü veya video yüklediğinde, sunucu arabelleği taşabilir ve bazı ek paketlerin kaybolmasına neden olabilir.
Arabellek taşmasını önlemek için, bir akış kontrol mekanizması, göndericinin alıcıyı verilerle boğmasını önlemelidir. Bu bölüm, HTTP/1.1 ve HTTP/2’nin farklı dağıtım modellerine göre akış denetimiyle başa çıkmak için bu mekanizmanın farklı sürümlerini nasıl kullandığına genel bir bakış sağlayacaktır.
HTTP/1.1
HTTP/1.1’de akış denetimi, temel alınan TCP bağlantısına dayanır. Bu bağlantı başlatıldığında, hem istemci hem de sunucu, sistem varsayılan ayarlarını kullanarak arabellek boyutlarını belirler. Alıcının arabelleği kısmen verilerle doluysa, gönderene alma penceresini, yani arabelleğinde kalan kullanılabilir alan miktarını söyleyecektir. Bu alma penceresi, alıcının açılış sinyalini aldığını onaylamak için gönderdiği veri paketi olan ACK paketi olarak bilinen bir sinyalde tanıtılır. Tanıtılan bu alma penceresi boyutu sıfırsa, gönderen, istemci dahili arabelleğini temizleyene ve ardından veri iletimine devam etmek isteyene kadar daha fazla veri göndermez. Burada, temel alınan TCP bağlantısına dayalı alma pencerelerinin kullanılmasının yalnızca bağlantının her iki ucunda da akış denetimi uygulayabileceğini unutmamak önemlidir.
HTTP/1.1, arabellek taşmasını önlemek için aktarım katmanına dayandığından, her yeni TCP bağlantısı ayrı bir akış kontrol mekanizması gerektirir. Ancak HTTP/2, akışları tek bir TCP bağlantısı içinde çoğullar ve akış denetimini farklı bir şekilde uygulamak zorunda kalır.
HTTP/2 (İngilizce)
HTTP/2, tek bir TCP bağlantısı içinde veri akışlarını çoğullar. Sonuç olarak, TCP bağlantısı seviyesindeki alma pencereleri, tek tek akışların dağıtımını düzenlemek için yeterli değildir. HTTP/2, istemcinin ve sunucunun aktarım katmanına güvenmek yerine kendi akış denetimlerini uygulamasına izin vererek bu sorunu çözer. Uygulama katmanı, kullanılabilir arabellek alanını ileterek istemci ve sunucunun alma penceresini çoğullanmış akışlar düzeyinde ayarlamasına olanak tanır. Bu ince ölçekli akış kontrolü, bir çerçeve aracılığıyla ilk bağlantıdan sonra değiştirilebilir veya korunabilir.WINDOW_UPDATE
Bu yöntem, uygulama katmanı seviyesindeki veri akışını kontrol ettiğinden, akış kontrol mekanizmasının, alma penceresini ayarlamadan önce bir sinyalin nihai hedefine ulaşmasını beklemesi gerekmez. Aracı düğümler, kendi kaynak tahsislerini belirlemek ve buna göre değişiklik yapmak için akış denetimi ayarları bilgilerini kullanabilir. Bu şekilde, her aracı sunucu kendi özel kaynak stratejisini uygulayarak daha fazla bağlantı verimliliği sağlayabilir.
Akış kontrolündeki bu esneklik, uygun kaynak stratejileri oluştururken avantajlı olabilir. Örneğin, istemci bir görüntünün ilk taramasını getirebilir, kullanıcıya görüntüleyebilir ve kullanıcının daha kritik kaynakları getirirken önizlemesine izin verebilir. İstemci bu kritik kaynakları getirdikten sonra, tarayıcı görüntünün kalan kısmını almaya devam edecektir. Akış denetiminin istemciye ve sunucuya uygulanmasının ertelenmesi, böylece web uygulamalarının algılanan performansını iyileştirebilir.
Akış kontrolü ve daha önceki bir bölümde bahsedilen akış önceliklendirmesi açısından, HTTP/2 daha fazla optimizasyon olasılığını açan daha ayrıntılı bir kontrol düzeyi sağlar. Bir sonraki bölümde, bir bağlantıyı benzer şekilde geliştirebilen protokole özgü başka bir yöntem açıklanacaktır: sunucu gönderimi ile kaynak isteklerini tahmin etme.
Kaynak İsteklerini Tahmin Etme
Tipik bir web uygulamasında, istemci bir istek gönderir ve HTML’de, genellikle sitenin dizin sayfasında bir sayfa alır. İstemci, dizin sayfası içeriğini incelerken, sayfayı tam olarak oluşturmak için CSS ve JavaScript dosyaları gibi ek kaynaklar getirmesi gerektiğini keşfedebilir. İstemci, bu ek kaynaklara yalnızca ilk isteğinden yanıt aldıktan sonra ihtiyaç duyduğunu belirler ve bu nedenle bu kaynakları getirmek ve sayfayı bir araya getirmeyi tamamlamak için ek isteklerde bulunmalıdır. Bu ek istekler sonuçta bağlantı yükleme süresini artırır.GETGET
Bununla birlikte, bu sorunun çözümleri vardır: sunucu, istemcinin ek dosyalara ihtiyaç duyacağını önceden bildiğinden, sunucu bu kaynakları istemciye istemeden önce göndererek istemciye zaman kazandırabilir. HTTP/1.1 ve HTTP/2’nin bunu başarmak için farklı stratejileri vardır ve bunların her biri bir sonraki bölümde açıklanacaktır.
HTTP/1.1 — Kaynak Satır İçi
HTTP/1.1’de, geliştirici istemci makinenin sayfayı işlemek için hangi ek kaynaklara ihtiyaç duyacağını önceden biliyorsa, gerekli kaynağı doğrudan sunucunun ilk isteğe yanıt olarak gönderdiği HTML belgesine dahil etmek için kaynak satır içi adı verilen bir teknik kullanabilir. Örneğin, bir istemcinin bir sayfayı oluşturmak için belirli bir CSS dosyasına ihtiyacı varsa, bu CSS dosyasının satır içi, istemciye istemeden önce gerekli kaynağı sağlayarak istemcinin göndermesi gereken toplam istek sayısını azaltır.GET
Ancak kaynak satır içi ile ilgili birkaç sorun vardır. Kaynağı HTML belgesine dahil etmek, daha küçük, metin tabanlı kaynaklar için uygun bir çözümdür, ancak metin olmayan biçimlerdeki daha büyük dosyalar, HTML belgesinin boyutunu büyük ölçüde artırabilir, bu da sonuçta bağlantı hızını azaltabilir ve bu tekniğin kullanılmasından elde edilen orijinal avantajı geçersiz kılabilir. Ayrıca, satır içi kaynaklar artık HTML belgesinden ayrı olmadığından, istemcinin zaten sahip olduğu kaynakları reddetmesi veya önbelleğine bir kaynak yerleştirmesi için bir mekanizma yoktur. Birden çok sayfa kaynak gerektiriyorsa, her yeni HTML belgesinin kodunda aynı kaynak bulunur ve bu da daha büyük HTML belgelerine ve kaynağın başlangıçta önbelleğe alınmasından daha uzun yükleme sürelerine yol açar.
Bu nedenle, kaynak satır içi oluşturmanın önemli bir dezavantajı, istemcinin kaynağı ve belgeyi ayıramamasıdır. Bağlantıyı optimize etmek için daha ince bir kontrol seviyesine ihtiyaç vardır, bu da HTTP/2’nin sunucu itme ile karşılamaya çalıştığı bir ihtiyaçtır.
HTTP/2 — Sunucu Gönderimi
HTTP/2, bir istemcinin ilk isteğine birden çok eşzamanlı yanıt sağladığından, bir sunucu, istenen HTML sayfasıyla birlikte bir istemciye bir kaynak gönderebilir ve istemci istemeden önce kaynağı sağlayabilir. Bu işleme sunucu gönderimi denir. Bu şekilde, bir HTTP/2 bağlantısı, gönderilen kaynak ile belge arasındaki ayrımı korurken aynı kaynak satır içi hedefini gerçekleştirebilir. Bu, istemcinin, gönderilen kaynağı ana HTML belgesinden ayrı olarak önbelleğe almaya veya reddetmeye karar verebileceği ve kaynak satır içi oluşturmanın büyük dezavantajını düzeltebileceği anlamına gelir.GET
HTTP/2’de bu işlem, sunucu istemciye bir kaynak göndereceğini bildirmek için bir çerçeve gönderdiğinde başlar. Bu çerçeve yalnızca iletinin başlığını içerir ve istemcinin sunucunun hangi kaynağı göndereceğini önceden bilmesini sağlar. Kaynak zaten önbelleğe alınmışsa, istemci yanıt olarak bir çerçeve göndererek göndermeyi reddedebilir. Çerçeve ayrıca, sunucunun hangi kaynakları göndereceğini bildiği için istemciyi sunucuya yinelenen bir istek göndermekten kurtarır.PUSH_PROMISERST_STREAMPUSH_PROMISE
Burada, sunucu itmenin vurgusunun istemci kontrolü olduğuna dikkat etmek önemlidir. Bir istemcinin sunucu gönderme önceliğini ayarlaması veya hatta devre dışı bırakması gerekiyorsa, bu HTTP / 2 özelliğini değiştirmek için herhangi bir zamanda bir çerçeve gönderebilir.SETTINGS
Bu özelliğin çok fazla potansiyeli olmasına rağmen, sunucu gönderimi her zaman web uygulamanızı optimize etmenin cevabı değildir. Örneğin, bazı web tarayıcıları, istemcide kaynak zaten önbelleğe alınmış olsa bile, gönderilen istekleri her zaman iptal edemez. İstemci yanlışlıkla sunucunun yinelenen bir kaynak göndermesine izin verirse, sunucu gönderimi bağlantıyı gereksiz yere kullanabilir. Sonunda, sunucu itme geliştiricinin takdirine bağlı olarak kullanılmalıdır. Sunucu gönderiminin stratejik olarak nasıl kullanılacağı ve web uygulamalarının nasıl optimize edileceği hakkında daha fazla bilgi için Google tarafından geliştirilen PRPL modeline göz atın. Sunucu gönderimi ile ilgili olası sorunlar hakkında daha fazla bilgi edinmek için Jake Archibald’ın blog gönderisine bakın HTTP/2 gönderimi düşündüğümden daha zor.
Sıkıştırma
Web uygulamalarını en iyi duruma getirmenin yaygın bir yöntemi, istemci ile sunucu arasında dolaşan HTTP iletilerinin boyutunu azaltmak için sıkıştırma algoritmaları kullanmaktır. HTTP/1.1 ve HTTP/2’nin her ikisi de bu stratejiyi kullanır, ancak ilkinde tüm iletinin sıkıştırılmasını yasaklayan uygulama sorunları vardır. Aşağıdaki bölümde bunun neden böyle olduğu ve HTTP/2’nin nasıl bir çözüm sağlayabileceği tartışılacaktır.
HTTP/1.1
Gzip gibi programlar, özellikle CSS ve JavaScript dosyalarının boyutunu küçültmek için HTTP mesajlarında gönderilen verileri sıkıştırmak için uzun süredir kullanılmaktadır. Bununla birlikte, bir iletinin başlık bileşeni her zaman düz metin olarak gönderilir. Her başlık oldukça küçük olmasına rağmen, bu sıkıştırılmamış verilerin yükü, daha fazla istek yapıldıkça bağlantı üzerinde daha da ağırlaşır, özellikle de birçok farklı kaynak ve dolayısıyla birçok farklı kaynak isteği gerektiren karmaşık, API ağırlıklı web uygulamalarını cezalandırır. Ek olarak, çerezlerin kullanımı bazen başlıkları çok daha büyük hale getirebilir ve bu da bir tür sıkıştırma ihtiyacını artırabilir.
Bu darboğazı çözmek için HTTP/2, bir sonraki bölümde daha ayrıntılı olarak tartışılan bir konu olan başlıkların boyutunu küçültmek için HPACK sıkıştırmasını kullanır.
HTTP/2 (İngilizce)
HTTP/2’de tekrar tekrar ortaya çıkan temalardan biri, daha ince ayrıntılar üzerinde daha fazla kontrol sergilemek için ikili çerçeveleme katmanını kullanma yeteneğidir. Aynı şey başlık sıkıştırma söz konusu olduğunda da geçerlidir. HTTP/2, başlıkları verilerinden ayırarak bir başlık çerçevesi ve bir veri çerçevesi ile sonuçlanabilir. HTTP/2’ye özgü sıkıştırma programı HPACK daha sonra bu başlık çerçevesini sıkıştırabilir. Bu algoritma, başlık meta verilerini Huffman kodlamasını kullanarak kodlayabilir ve böylece boyutunu büyük ölçüde azaltabilir. Ek olarak, HPACK daha önce iletilen meta veri alanlarını takip edebilir ve bunları istemci ile sunucu arasında paylaşılan dinamik olarak değiştirilmiş bir dizine göre daha da sıkıştırabilir. Örneğin, aşağıdaki iki isteği alın:
İstek #1
method: GET
scheme: https
host: example.com
path: /academy
accept: /image/jpeg
user-agent: Mozilla/5.0 ...
İstek #2
method: GET
scheme: https
host: example.com
path: /academy/images
accept: /image/jpeg
user-agent: Mozilla/5.0 ...
Bu isteklerdeki , , , ve gibi çeşitli alanlar aynı değerlere sahiptir; Yalnızca alan farklı bir değer kullanır. Sonuç olarak, gönderirken istemci, yalnızca bu ortak alanları yeniden oluşturmak ve alanı yeni kodlamak için gereken dizinlenmiş değerleri göndermek için HPACK’i kullanabilir. Ortaya çıkan başlık çerçeveleri aşağıdaki gibi olacaktır:methodschemehostacceptuser-agentpathRequest #2path
İstek #1 için Başlık Çerçevesi
method: GET
scheme: https
host: example.com
path: /academy
accept: /image/jpeg
user-agent: Mozilla/5.0 ...
İstek #2 için Başlık Çerçevesi
path: /academy/images
HPACK ve diğer sıkıştırma yöntemlerini kullanan HTTP/2, istemci-sunucu gecikmesini azaltabilecek bir özellik daha sağlar.
Son
Bu noktadan noktaya analizden de görebileceğiniz gibi, HTTP/2, HTTP/1.1’den birçok yönden farklıdır, bazı özellikler web uygulaması performansını daha iyi optimize etmek için kullanılabilecek daha yüksek düzeyde kontrol sağlar ve diğer özellikler yalnızca önceki protokolü geliştirir. Artık iki protokol arasındaki farklılıklar hakkında üst düzey bir bakış açısı kazandığınıza göre, HTTP/2’de çoğullama, akış önceliklendirme, akış kontrolü, sunucu itme ve sıkıştırma gibi faktörlerin web geliştirmenin değişen manzarasını nasıl etkileyeceğini düşünebilirsiniz.
HTTP/1.1 ve HTTP/2 arasında bir performans karşılaştırması görmek isterseniz, farklı gecikme süreleri için protokolleri karşılaştıran bu Google demosuna göz atın. Testi bilgisayarınızda çalıştırdığınızda, sayfa yükleme sürelerinin bant genişliği, sınama sırasında mevcut olan istemci ve sunucu kaynakları gibi çeşitli etkenlere bağlı olarak değişebileceğini unutmayın. Daha kapsamlı testlerin sonuçlarını incelemek isterseniz, HTTP/2 – Gerçek Dünya Performans Testi ve Analizi makalesine bir göz atın. Son olarak, modern bir web uygulamasının nasıl oluşturulacağını keşfetmek isterseniz, Ubuntu 18.04’te Django ve React ile Müşteri Bilgilerini Yönetmek için Modern Bir Web Uygulaması Nasıl Oluşturulur öğreticimizi takip edebilir veya Ubuntu 20.04’te HTTP/2 Desteği ile Nginx Nasıl Kurulur öğreticimizle kendi HTTP/2 sunucunuzu kurabilirsiniz.
HTTP/1.1 ve HTTP/2: Fark Nedir? | Dijital Okyanus (digitalocean.com)