Web sunucuları bir sayfa gönderdiğinde neden istenmeden tüm gerekli CSS, JS ve görüntüleri göndermiyorlar?

Bir web sayfası tek bir CSS dosyası ve bir resim içerdiğinde, tarayıcılar ve sunucular neden bu geleneksel zaman alıcı rota ile zaman harcıyorlar:

1. tarayıcı web sayfası için bir başlangıç ​​GET isteği gönderir ve sunucu yanıtını bekler.
2. tarayıcı, css dosyası için başka bir GET isteği gönderir ve sunucu yanıtını bekler.
3. tarayıcı resim dosyası için başka bir GET isteği gönderir ve sunucu yanıtını bekler.

Bunun yerine ne zaman bu kısa, doğrudan, zaman kazandıran rotayı kullanabilirler?

1. Tarayıcı bir web sayfası için bir GET isteği gönderir.
2. Web sunucusu cevap verir ( index.html ve ardından style.css ve image.jpg )

Kısa cevap "Çünkü HTTP bunun için tasarlanmadı".

Tim Berners-Lee , verimli ve genişletilebilir bir ağ protokolü tasarlamadı. Bir tasarım hedefi sadelikti. (Üniversitedeki ağ sınıfımın profesörü, işi profesyonellere bırakması gerektiğini söyledi.) Ana hatlarıyla belirttiğiniz sorun, HTTP protokolüyle ilgili birçok sorundan yalnızca biri. Orijinal haliyle:

• Protokol sürümü yoktu, sadece kaynak için bir istek vardı
• Başlık yoktu
• Her istek yeni bir TCP bağlantısı gerektiriyordu
• Sıkıştırma yoktu

Protokol daha sonra bu sorunların çoğunu ele almak için revize edildi:

• İstekler sürümlendi, şimdi talepler benziyor GET /foo.html HTTP/1.1
• Hem istek hem de yanıtla birlikte meta bilgiler için başlıklar eklendi
• Bağlantıların yeniden kullanılmasına izin verildi. Connection: keep-alive
• Belge boyutu önceden bilinmese bile bağlantıların yeniden kullanılmasına izin vermek için yığın yanıtlar verildi.
• Gzip sıkıştırma eklendi

Bu noktada HTTP, geriye dönük uyumluluk kırılmadan mümkün olduğu ölçüde ele alınmıştır.

Bir sayfanın ve tüm kaynaklarının müşteriye gönderilmesi gerektiğini öneren ilk kişi siz değilsiniz. Aslında, Google SPDY denilen bir protokol tasarladı .

Bugün hem Chrome hem de Firefox, onu destekleyen sunuculara HTTP yerine SPDY kullanabilir. SPDY web sitesinden HTTP ile karşılaştırıldığında temel özellikleri şunlardır:

• SPDY, istemci ve sunucunun, benzer başlıklar (örneğin çerezler) birden fazla istek için tekrar tekrar gönderildiğinde bant genişliği kullanımını azaltan istek ve yanıt başlıklarını sıkıştırmasına olanak tanır.
• SPDY, tek bir bağlantı üzerinden birden fazla, aynı anda çoğaltılmış isteklere izin verir, istemci ve sunucu arasında gidiş dönüşlerde tasarruf sağlar ve düşük öncelikli kaynakların yüksek öncelikli istekleri engellemesini önler.
• SPDY, sunucunun, istemeden istekte bulunmasını beklemeden müşterinin ihtiyaç duyduğunu bildiği kaynakları (örn. JavaScript ve CSS dosyaları) aktif olarak istemesine olanak sağlar ve sunucunun kullanılmayan bant genişliğini etkin bir şekilde kullanmasını sağlar.

Web sitenizi SPDY ile birlikte destekleyen tarayıcılara sunmak istiyorsanız, bunu yapabilirsiniz. Örneğin Apache'nin mod_spdy'si var .

SPDY, sunucu push teknolojisine sahip HTTP sürüm 2 için temel haline geldi .

Web tarayıcınız, web sayfasını (HTML) sunucudan indirinceye kadar bu kaynakları birleştiren ek kaynaklar hakkında bir şey bilmiyor.

Merak ediyor olabilirsiniz, sunucu neden kendi HTML'sini ayrıştırmıyor ve web sayfasının ilk talebi sırasında tüm ek kaynakları web tarayıcısına göndermiyor? Kaynaklar birden fazla sunucuya yayılmış olabilir ve web tarayıcısı tüm bu kaynaklara ihtiyaç duymayabilir;

Web tarayıcısı bir kaynak önbelleği tutar, böylece aynı kaynakları onları barındıran sunuculardan tekrar tekrar indirmek zorunda kalmaz. Hepsi aynı jQuery kütüphanesini kullanan bir web sitesinde farklı sayfalarda gezinirken, bu kütüphaneyi her seferinde, sadece ilk seferinde indirmek istemezsiniz.

Böylece, web tarayıcısı sunucudan bir web sayfası aldığında, önbellekte bulunmadığı bağlantılı kaynakları kontrol eder ve bu kaynaklar için ek HTTP istekleri yapar. Oldukça basit, çok esnek ve genişletilebilir.

Bir web tarayıcısı genellikle paralel olarak iki HTTP isteği yapabilir. Bu AJAX'a benzemez - ikisi de web sayfalarını yüklemek için eşzamanlı olmayan yöntemlerdir - eşzamansız dosya yüklemesi ve eşzamansız içerik yüklemesi. Canlı tutma ile tek bir bağlantı kullanarak birkaç istek yapabiliriz ve boru hattıyla yanıt beklemek zorunda kalmadan birkaç istek yapabiliriz. Bu tekniklerin her ikisi de çok hızlıdır, çünkü çoğu genel gider genellikle TCP bağlantılarını açmak / kapatmaktan gelir:

Biraz web geçmişi ...

Web sayfaları düz metin e-posta olarak başladı, bilgisayar sistemleri bu fikir etrafında tasarlandı ve herkes için ücretsiz bir iletişim platformu oluşturdu. web sunucuları o zamanlar hala özeldi. Daha sonra, görüntüler, stiller, komut dosyaları vb. Ek MIME türleri biçiminde "email spec" e daha fazla katman eklenmiştir. Sonuçta, MIME, Çok Amaçlı İnternet Posta Uzantısı anlamına gelir . Er ya da geç, esasen multimedya e-posta iletişimi, standart web sunucuları ve web sayfalarını gördük.

HTTP, verilerin çoğu zaman e-posta olmasa da, e-postaya benzer mesajlar bağlamında iletilmesini gerektirir.

Bunun gibi bir teknoloji geliştikçe, geliştiricilerin mevcut yazılımı bozmadan aşamalı olarak yeni özellikler eklemelerine izin vermesi gerekir. Örneğin, teknik özelliklere yeni bir MIME türü eklendiğinde - JPEG diyelim - web sunucularının ve web tarayıcılarının bunu yapması biraz zaman alacaktır. Sadece aniden JPEG'i teknik özelliklere zorlamayın ve tüm tarayıcılara göndermeye başlayın, web tarayıcısının desteklediği kaynakları talep etmesine izin verin, bu da herkesi mutlu eder ve teknolojiyi ilerletir. Bir ekran okuyucu bir web sayfasındaki tüm JPEG'lere ihtiyaç duyuyor mu? Muhtemelen değil. Cihazınız Javascript'i desteklemiyorsa bir sürü Javascript dosyası indirmeye zorlanmalı mıyım? Muhtemelen değil. Sitenizi düzgün bir şekilde dizine eklemek için Googlebot’un tüm Javascript dosyalarınızı indirmesi gerekiyor mu? Hayır!

Kaynak: Node.js. gibi olaya dayalı bir web sunucusu geliştirdim. Buna Hızlı Sunucu denir .

Referanslar:

• HTTP kalıcı bağlantı (canlı tutma)
• HTTP boru hattı
• HTTP / 1.1 Bağlantıları (RFC 2616)

Daha fazla okuma:

• SPDY, http multiplexing'den farklı mıdır, bağlantıları canlı tutun
• Neden HTTP / 2.0 ilginç görünmüyor

Çünkü bu kaynakların ne olduğunu bilmiyorlar. Bir web sayfasının gerektirdiği varlıklar HTML'ye kodlanır. Ancak bir ayrıştırıcı bu varlıkların ne olduğunu belirledikten sonra, kullanıcı aracısı tarafından talep edilebilir.

Ek olarak, bu varlıklar bilindikten sonra, ayrı ayrı sunulmaları gerekir, böylece uygun başlıklar (yani içerik türü) sunulabilir, böylece kullanıcı aracısı nasıl işleneceğini bilir.

Çünkü, örneğinizde, web sunucusu , müşterinin zaten elinde olup olmadığına bakılmaksızın , her zaman CSS ve görüntüler gönderir, böylece bant genişliğini büyük oranda boşa harcarsınız (ve böylece amacınızı yerine getirmek için gecikmeyi azaltmak yerine , bağlantıyı daha yavaş hale getirir ). CSS, JavaScript ve resim dosyalarının genellikle tam da bu nedenle çok uzun zaman aşımına uğrayan zamanlarla gönderildiğini unutmayın (bunları değiştirmeniz gerektiğinde olduğu gibi, tekrar uzun süre önbelleğe alınacak yeni kopyaya zorlamak için sadece dosya adını değiştirirsiniz).

Şimdi, " Tamam, ancak müşteri zaten bu kaynakların bir kısmına sahip olduğunu gösterebildiğinden, sunucunun tekrar göndermeyeceğini " söyleyerek bu bant genişliği israfına çalışmayı deneyebilirsiniz . Gibi bir şey:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

Ardından, yalnızca değişmemiş dosyaların bir TCP bağlantısı üzerinden gönderilmesini sağlayın (kalıcı bağlantı üzerinden HTTP boru hattını kullanarak). Ve tahmin et ne oldu? O nasıl zaten (ayrıca kullanabilirsiniz çalışır If-Modified-Since yerine If-None-Match ).

Ancak, çok fazla bant genişliği boşa harcayarak gecikmeyi azaltmak istiyorsanız (orijinal isteğinizde olduğu gibi), bugün web sitenizi tasarlarken standart HTTP / 1.1 kullanarak bunu yapabilirsiniz. Çoğu insanın bunu yapmamasının nedeni, buna değmeyeceğini düşünmeleridir.

Bunu yapmak için, CSS veya JavaScript’lerin ayrı bir dosyaya sahip olmanıza gerek yoktur, bunları <style>ve <script>etiketlerini kullanarak ana HTML dosyasına ekleyebilirsiniz (muhtemelen elle bile yapmanız gerekmez, şablon motorunuz muhtemelen otomatik olarak yapabilir) . URI'yi kullanarak veri dosyasını HTML dosyasına da dahil edebilirsiniz :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Tabi ki, base64 kodlaması, bant genişliği kullanımını biraz arttırır, ancak israf edilen bant genişliğini umursamıyorsanız, bu bir sorun olmamalıdır.

Şimdi, gerçekten önemsiyorsanız, web komut dosyalarını her iki dünyanın da en iyisini elde etmek için yeterince akıllı hale getirebilirsiniz: ilk istek üzerine (kullanıcının çerezleri yoktur), yalnızca tek bir HTML'ye gömülü her şeyi (CSS, JavaScript, resimler) gönderin Yukarıda açıklandığı gibi dosya, dosyaların harici kopyaları için bir link rel = "prefetch" etiketleri ekleyin ve bir çerez ekleyin. Kullanıcı zaten (örn. Daha önce ziyaret ettiği) bir çerez varsa, o zaman ona sadece normal bir HTML göndermek <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">vb

Böylece ilk ziyaretinizde tarayıcı sadece tek bir HTML dosyası ister ve her şeyi alır ve gösterirdi. Sonra (boştayken) belirtilen harici CSS, JS, resimleri önceden yüklerdi. Kullanıcı bir dahaki sefere ziyaret ettiğinde, tarayıcı yalnızca değiştirilmiş kaynakları talep eder ve alır (muhtemelen sadece yeni HTML).

Ekstra CSS + JS + görüntü verileri, web sitesinde yüzlerce kez tıklasanız bile, yalnızca iki kez gönderilir. Önerdiğiniz çözümün önerdiği gibi yüzlerce kez çok daha iyi. Ve asla (değil ilk kez, ne de sonraki günler) birden kullanmak bir gecikme artan gidiş-dönüş.

Şimdi, eğer kulağa çok iş gibi geliyorsa ve SPDY gibi başka bir protokolle gitmek istemiyorsanız , Apache için mod_pagespeed gibi modüller var, bu çalışmaların bir kısmını sizin için otomatik olarak yapabilir (birden fazla CSS / JS dosyasını birleştirerek) Birine, küçük CSS'leri otomatik olarak yerleştirme ve küçük resim yapma, orijinallerin yüklenmesini, tembel yükleme görüntülerini vb. bekletmeden web sayfanızın tek bir satırını değiştirmenize gerek kalmadan küçük yer tutucuya çizili görüntüler yapın.

HTTP2, SPDY'ye dayanır ve tam olarak önerdiğiniz şeyi yapar:

Yüksek düzeyde, HTTP / 2:

• metin yerine ikili
• sipariş ve engelleme yerine tamamen çoğaltılır
• bu nedenle paralellik için bir bağlantı kullanabilir
• ek yükü azaltmak için başlık sıkıştırmayı kullanır
• Sunucuların proaktif olarak yanıtları istemci önbelleklerine “itmesine” izin verir

Daha fazlası için tıklayın HTTP 2 Faq

Çünkü bu şeylerin aslında gerekli olduğunu varsaymaz .

Protokol, belirli bir dosya türü veya kullanıcı aracısı için herhangi bir özel işlem tanımlamaz. Bir HTML dosyası ile PNG görüntüsü arasındaki farkı bilmiyor. İstediğiniz şeyi yapmak için, Web sunucusunun dosya türünü tanımlaması, başka hangi dosyaları yönlendirdiğini bulmak için ayrıştırması ve sonra ne yapmak istediğinizi göz önüne alarak hangi dosyaların gerçekten gerekli olduğunu belirlemesi gerekir. dosya . Bununla ilgili üç büyük sorun var.

İlk sorun, sunucu ucundaki dosya türlerini tanımlamanın standart ve sağlam bir yolunun bulunmamasıdır . HTTP, Content-Type mekanizmasıyla yönetir, ancak sunucuya yardım etmez, bu da kendi başına halletmesi gerekir (kısmen Content-Type'a ne koyacağını bilmesi için). Dosya adı uzantıları, bazen kötü amaçlı amaçlar için yaygın olarak desteklenir, ancak kırılgan ve kolayca kandırılabilir. Dosya sistemi meta verileri daha az kırılgandır, ancak çoğu sistem bunu çok iyi desteklemez, bu nedenle sunucular bile rahatsız etmez. İçerik koklama (bazı tarayıcılar ve Unix filekomutunun yapmayı denediği gibi) eğer pahalı yapmaya istekli iseniz güçlü olabilir, ancak güçlü koklama, sunucu tarafında pratik olması için çok pahalı ve ucuz koklama yeterince sağlam değildir.

İkinci sorun, bir dosyayı ayrıştırmanın hesaplamalı olarak pahalı bir yöntemdir . Bu, ilkiyle biraz bağlantılıdır, çünkü içeriği sağlam bir şekilde kesmek istiyorsanız, dosyayı bir sürü farklı potansiyel yolla ayrıştırmanız gerekir, ancak dosya türünü tanımladıktan sonra da geçerlidir, çünkü referansların ne olduğunu bulmak için. Bir seferde sadece birkaç dosya yaptığınız zaman, tarayıcıda olduğu gibi o kadar da kötü değil, fakat bir Web sunucusu aynı anda yüzlerce veya binlerce isteği yerine getirmek zorunda. Bu ekler ve eğer çok ileri giderse, işleri birden fazla istekten daha yavaşlatabilir. Slashdot veya benzeri sitelerden bir bağlantıyı ziyaret ettiyseniz, yalnızca yüksek kullanım nedeniyle sunucunun acı verici bir şekilde yavaş olduğunu bulmak için bu prensibi eylem halinde gördünüz.

Üçüncü sorun, sunucunun dosyayla ne yapmak istediğinizi bilmesinin bir yolu olmamasıdır . Bir tarayıcı HTML'de referans olarak alınacak dosyalara ihtiyaç duyabilir, ancak dosyanın yürütülmekte olduğu tam içeriğe bağlı olarak gerekmeyebilir. Bu yeterince karmaşık olurdu, ancak Web’de sadece tarayıcılardan daha fazlası var: örümcekler, yayın toplayıcılar ve sayfa kazıma karışımları arasında, HTML’de başvurulan dosyalara ihtiyaç duymayan birçok kullanıcı aracısı türü var : bunlar sadece HTML'nin kendisini önemser. Bu diğer dosyaları bu tür kullanıcı aracısına göndermek yalnızca bant genişliğini boşa harcar.

Sonuç olarak, bu bağımlılıkları sunucu tarafında bulmak, değerinden daha fazla sorun oluşturuyor . Bunun yerine, müşterinin neye ihtiyacı olduğunu bulmasına izin verdiler.