Web hızlandırma, önce protokol!
Yazar Luo Cheng
Düzenle Xiaozhi
Web sitelerini ve uygulamaları ziyaret ederken, genellikle çeşitli performans sorunlarıyla karşılaşırsınız. Örneğin, web sayfaları yavaş yükleniyor, video kartları, ağ hataları, vb. Etkileyen ana faktörlerden biri ağ protokolüdür. Bu makale sistematik olarak TCP, UDP, HTTP1.1, HTTPS (en son TLS1.3 protokolü dahil), SPDY, HTTP2 ve diğer protokollerin sorunlarını ve belirli senaryolarda ağ protokollerinin optimizasyonu yoluyla erişim hızının nasıl elde edileceğini tanıtacaktır. Desteklemek.
Not: Bu makale, Tencent TEG Altyapı Departmanında kıdemli bir mühendis olan Luo Cheng tarafından ArchSummit 2017 Shenzhen istasyonunda yapılan bir konuşmadan derlenmiştir.
Önsöz: Web performansı optimizasyonu sorunları
WEB performans optimizasyonu söz konusu olduğunda, birçok performans sorunu ile karşılaştığımız anlamına gelir.
Yukarıdaki resimde gösterildiği gibi, bu kelime dizisini görünce, ağa erişememe veya sayfanın yüklendiği veya içeriğin% 99 oranında sıkışmış olabileceği gibi birçok sahnenin aklınızda görüneceğine inanıyorum. Video donmaları, kısa videolar ve canlı yayınlar ve kablosuz ağdan 4G ağlara yeniden yükleme dahil olmak üzere yüklenemiyor. Bu kadar çok web sorunuyla karşılaşmanın ana nedeni nedir?
Kısa bir liste yapıp bunu aşağıdaki iki durumda özetleyeyim.
Doğrudan sayfayla ilgili sayfanın boyutu, sayfadaki öğe türlerinin sayısı, yani bir sayfa ne kadar büyükse, o kadar çok öğe ve daha sık dinamik etkileşimler, karşılık gelen performans daha fazla etkilenebilir. Sayfa optimizasyonu aynı zamanda ön uç optimizasyonu için ana savaş alanıdır.
Kullanıcının cep telefonu donanımının performansı ve yazılımın işletim sistemi sürümü dahil olmak üzere ağ ortamı ve terminal yapılandırması da performansı etkileyecektir. Bu ikisi esas olarak operatörlerin ve kullanıcıların konfigürasyonu ile ilgilidir ve aynı zamanda etki yaratma zorluğumuzun bir parçasıdır.
Ağ protokolü
Bugün ağ protokolüne odaklanacağım. Ağ protokolü çok önemli ve kritik bir faktördür, ancak herkes tarafından göz ardı edilmesi kolaydır. Peki ağ protokolleri söz konusu olduğunda, hangi ağ protokolleriyle karşılaşacağız veya kullanacağız?
Daha sonra, kısaca tanıtmak için örnek olarak en yaygın İnternet yeni nesil HTTP2 protokolünü alıyorum.
Yukarıdaki şekilde gösterildiği gibi, WEB'in talep ettiği protokol yığınının geçmesi gerekir. Şeklin sol tarafı istemcidir ve sağ tarafı veri merkezi veya sunucudur.
İstemciden istek gönderildikten sonra, ilk olarak HTTP 1.1 protokolünden geçecektir. Öyleyse neden başlık HTTP2 isteği, ancak HTTP1.1'den bahsediyor? Bunun nedeni, HTTP2'nin yepyeni bir protokol olmasına rağmen, hala HTTP1.1'in semantiğinin çoğunu kullanmasıdır. Örneğin, GET istekleri ve POST isteklerinin tümü, HTTP 1.1'in anlamını kullanır. Sayfalar veya JavaScript için hala HTTP 1.1'in anlamını kullanıyoruz. HTTP1.1'in bir sonraki katmanı HTTP2'dir. HTTP2 yepyeni çerçeve kontrol semantiğini kullanır.Başka bir deyişle, HTTP2 çerçevesi, HTTP2 HEADERS; POST istek gövdesi kullanarak kapsüllemeyi gerçekleştiren GET isteği gibi HTTP1.1'in anlamını kapsüller. Veriler, HTTP2 veri çerçevesi kullanılarak kapsüllenir. Daha sonra TLS protokolüne, aktarım şifreleme katmanına ulaşır, o zaman burada neden şifreleme var?
Bunun ana nedeni, HTTP2 RFC7540 protokolünün iki HTTP2 uygulaması olduğunu şart koşmasıdır; biri şifreleme için TLS kullanmak için zorunlu olan H2; diğeri ise C'nin açık olduğu, düz metin olan ve şifreleme gerektirmeyen H2C'dir. Anlaşma çok şart koşulmuş olsa da, tüm tarayıcılar, tüm işletim sistemleri dahil olmak üzere tüm ana akım uygulamalar şimdiye kadar TLS şifrelemesini kullandı. Başka bir deyişle, HTTP2 kullanıyorsanız, TLS şifrelemesini kullanmanız gerekir, bu nedenle bu süreçte TLS sorunlarıyla karşılaşırsınız. Daha sonra TCP katmanı ve ardından IP ağ katmanı, Ethernet ve taşıyıcı ağ fiziksel katmanları ve ardından sağdaki sunucu protokolü aşağıdadır. Her iki taraftaki bağlantı noktaları simetrik olarak düşünülebilir, bu nedenle daha fazla giriş yapılmaz.
Bu kadar çok anlaşma varken hangilerine dikkat etmeliyiz? Veya daha spesifik olarak, web uygulaması geliştiricilerimizin çoğu için hangilerine dikkat etmemiz gerekiyor? Yukarıdaki şekilde beyaz noktalı çizginin üstündeki kısım, müşterinin etki veya optimizasyon uygulayabileceği kısım, yani önerilen protokol. TCP, TLS protokolleri ve HTTP sonrası dahil. Anlaşmayı optimize etmemiz gerektiği açık, ardından hangi sorunları yaşayacaklarını analiz edeceğim.
HTTP 1.1 performansı
HTTP1.1'in performans sorunları
En yaygın kullanılan ve en eski HTTP1.1 protokolüyle başlayalım.
Web geliştirme ile temas halinde olan öğrenciler, HTTP1.1'in en büyük performans probleminin tek linkli seri olduğunu bilirler. Bir TCP bağlantısında birden fazla istek olduğunda. Şekil 2'de gösterildiği gibi. Talepler ancak arka arkaya gönderilebilir ki bu en büyük problemidir.
İkinci sorun, başlığın sıkıştırılmamasıdır. Başlık, özellikle HTTP, Çerez ve Ana Bilgisayar isteklerinde aynı tarayıcı modeline sahip olduğunda, her istek aynı bilgiyi taşıyorsa, bu açıkça tekrarlanır. Bu gereksizdir, bant genişliğini boşa harcar ve performans sorunlarından kullanıcının erişim hızını etkiler. neden? Operatörün ağının yukarı bağlantı ve aşağı bağlantı bant genişliği ciddi ölçüde asimetrik olduğundan, yukarı bağlantı bant genişliği muhtemelen aşağı bağlantı bant genişliğinin yalnızca 1 / 10'u veya hatta 1 / 10'undan daha azdır. Yani, bant genişliği on veya bir megabit ise, yukarı bağlantı yalnızca 100K olabilir Düzinelerce K. Başlığın ortalama boyutu 1500 bayt ise, bir seferde gönderilen on başlık olabilir ve bant genişliği kullanıcı erişim performansını etkileyecektir. Bu nedenle 3G ve 4G'nin mobil ağ ortamında sıkıştırılmamış başlık sorunu daha önemlidir.
HTTP1.1 optimizasyonu
Pek çok optimizasyon metodu ve optimizasyon stratejisi var ve bunlar çok etkilidir.Peki ne var?
Özetle, HTTP1.1 için iki ana optimizasyon yönü vardır.
İlk nokta, eşzamanlı bağlantıların sayısını artırmak; ikinci nokta, gönderilen istek sayısını azaltmaktır. Yukarıdaki şekilde gösterildiği gibi, ister birden çok TCP bağlantısı olan tek bir etki alanı adı, ister etki alanı bölünmesi olsun, birden çok etki alanı adının kullanılması eşzamanlı bağlantıların sayısını artırmaktır. Eşzamanlı bağlantıların eşzamanlı istekler olmadığı unutulmamalıdır. Çünkü HTTP1.1 tek bir bağlantıda eşzamanlı istekleri uygulamaya çalıştı ancak başarısız oldu. Boru hattı gibi, çünkü satır başı engellemesi var. Bu nedenle, yalnızca eşzamanlı bağlantıların sayısını artırarak kullanıcı erişim performansını iyileştirebilir. Ek olarak, önbelleğe alma, CSS Sprite, data uri, resim inlineing vb. Gibi başka optimizasyon stratejileri de vardır. Bunun özü, istek sayısını azaltmaktır, yani istek sayısını azaltmak için tek bir yanıtta birden çok yanıt döndürülür.
Bu HTTP 1.1 optimizasyon stratejileri ve yöntemleri, HTTP 1.1 çağında çok iyi sonuçlar elde etti ve aynı zamanda etkilidirler.
HTTPS / HTTP2, HTTP1.1'in eskimesini hızlandırır
HTTPS'nin genel site trendi gittikçe daha belirgin hale geldikçe, HTTP2'nin resmi sürümü yavaş yavaş ana akım haline geldi ve HTTP1.1'in optimizasyon stratejisi geçersiz hale geldi. Neden öyle diyorsun?
HTTPS performansının bir özelliği veya dezavantajı, bağlantı maliyetinin çok yüksek olmasıdır. HTTP 1.1 performansı artırmak için eşzamanlı bağlantıları artırma yöntemini kullanırsa, yüksek bağlantı maliyeti nedeniyle eşzamanlı bağlantıların eşzamanlı maliyeti de yüksek olacak ve bu da performansı düşürecektir. .
HTTP2'nin özelliği çoğullamayı desteklemesidir. Bir bağlantıda birden çok isteğe izin verilir ve eşzamanlı isteklere izin verilir. HTTP1.1'in istek sayısını azaltması biraz gereksizdir, aksine önbellek isabet oranını ve performansı düşürebilir.
Dolayısıyla, bu seviyeden http1.1'in optimizasyon stratejisi çalışmayabilir ve yan etkiler üretmeyebilir.
HTTP ve HTTPS Karşılaştırması
HTTP VS HTTPS bağlantı maliyeti
Şimdi kısaca HTTPS'nin bağlantı maliyetinin neden yüksek olduğunu anlatayım? Protokol düzeyinde, yüksek bağlantı maliyeti nerede?
Yukarıdaki şekilde gösterildiği gibi, soldaki şekil bir istek süreci veya HTTP 1.1'in maliyetidir. HTTP1.1 isteği çok basittir, yalnızca bir TCP bağlantısı kurması ve ardından tamamlanması için HTTP isteğini ve yanıtını göndermesi gerekir. Toplam işlem, bir HTTP isteğini uygulamak için yalnızca iki RTT gerektirir.
Sağdaki resim bir HTTPS isteğidir. İlk olarak, HTTPS, üç yönlü bir el sıkışma yoluyla bir TCP bağlantısı kurar, ardından bir HTTP 1.1 isteği gönderir. HTTP 1.1 verileri neden burada? Çünkü kullanıcıların aktif olarak URL girmelerine izin verilirse, çoğu kullanıcı aktif olarak HTTPS girmeyecektir. Örneğin, Tencent.com'u ziyaret ederken https://www.qq.com değil, www.qq.com veya http: / /www.qq.com. Kullanıcıyı HTTPS kullanmaya zorlamak için bir 302 atlama döndürülecektir. 302 atlama ile ilgili olarak, HTTPS tarafından kullanılan bağlantı noktası 443 ve HTTP 80'dir; yeni bağlantı noktası yeni bir TCP bağlantısı yeniden kurulmalıdır, bu nedenle başka bir TCP bağlantısı vardır Kurulum süreci; TCP bağlantısı kurulduktan sonra TLS el sıkışma aşaması başlar.
TLS el sıkışmasının iki aşaması vardır; tam anlaşmanın ilk aşaması; protokol sürümü, şifre paketi, sertifika talep etme ve sertifikayı doğrulamayı içerir; İstemci sertifikayı aldıktan sonra, sertifikanın imzası doğru olsa bile, sertifika süresi geçerlidir, ancak sertifikanın yine de doğrulanması gerekir Sertifikanın durumu aktif olarak iptal edilebilir, sertifikanın anahtarı da sızdırılabilir veya CA'ya saldırılabilir, bu nedenle sertifika durumunu sorgulamak gerekir. Sertifikanın durumunu sorgulamak OCSP'dir. Çevrimiçi sertifika durum kontrolü. Sertifikanın durumunu sorgulamak için, bir CA'nın üç noktalı DNS'sini çözmeniz, bir TCP bağlantısı kurmanız ve ardından OCSP'yi içeren bir istek yanıtı oluşturmanız gerekir. Bir HTTP isteği ile tamamlanır ve üç yönlü el sıkışması tamamdır. Bundan sonra, TLS tam el sıkışmasının ikinci aşaması, simetrik bir anahtarla, yani asimetrik anahtar değişim hesaplamasında anlaşmaya başlar; tamamlandıktan sonra, tüm TLS süreci üzerinde görüşülür ve HTTP şifreli veriler gönderilir. Şimdiye kadar dokuzuncu RTT'ye ulaştı, yani http1.1'den 7 RTT daha fazla. Bu kavram nedir?
Optimize edilmemiş HTTPS, HTTP'den önemli ölçüde daha yavaştır
Yukarıdaki şekilde gösterildiği gibi, en iyi kablosuz ağ ortamında ortalama RTT 70 milisaniye, 7 RTT 490 milisaniye, 4G 100 milisaniye, 3G 200 milisaniye ve 7 RTT bir saniyeden fazladır. Ve bu sadece bir istektir, genellikle bir sayfa için birçok istek vardır ve istekler arasında tıkanmaya neden olan bağımlılıklar olabilir. Bu durumda, bir sayfanın birkaç saniye daha uzun olması normaldir ve zaman alıcı yalnızca ağ süresidir; ve protokolün hükümleri nedeniyle, bu, diğer birçok zaman alıcı dahil ağ etkileşimi olmalıdır. Mobil terminalin nispeten zayıf performansı nedeniyle, hesaplama zaman alıcı, sertifika doğrulama, anahtar hesaplama, içerik simetrik şifreleme ve şifre çözme hesaplamalarından bahsetmişken, hesaplama düzeyinde birkaç yüz milisaniye daha fazla olması da çok normaldir.
Yukarıdaki analizden sonra, temel bir sonuca varabiliriz, yani optimize edilmemiş HTTPS, HTTP'den çok daha yavaştır. Yani HTTPS, yavaş mı yoksa yavaş mı demektir?
Yavaşlığın nedenini bulmak veya performans darboğazını bulmak için, yukarıdaki analiz yalnızca ağ protokol teorisine dayanmaktadır.Aslında, deneysel ortamda, gerçek iş ortamında ve kullanıcı senaryosunda, hala çok yavaş ve yavaş mı? Nerede?
Bu amaçla iki aşamalı analiz yaptık.
Çevrimdışı simülasyon testi
İlki, çevrimdışı simülasyon testidir. Çevrimdışı simülasyon testi, esas olarak mobil terminal içindir, çünkü mobil terminal cep telefonu performansı, tümü mobil terminale eğilimlidir ve giderek daha fazla trafiktir. Mobil terminalin iki özelliği vardır: Birincisi, cep telefonu ekranı nispeten küçüktür ve verileri görüntülemek veya sayfa performansını görüntülemek ve hata ayıklama günlüklerini görüntülemek uygun değildir; ikincisi, veri analizi komut dosyalarını ve kontrol komut dosyalarını çalıştırmak uygun değildir. Bu yüzden cep telefonunu ve bilgisayarı USB kullanarak bağlarız ve oluşturduğumuz farklı sayfaları tekrar tekrar ziyaret etmek için uzaktan hata ayıklama protokolü aracılığıyla cep telefonundaki tarayıcıyı kontrol ederiz. Bu sayfada yer alan unsurlar çok fazla olmalıdır ve farklı türleri de vardır.
Bu nedenle, çevrimdışı simülasyon testini otomatikleştirmeliyiz, insan uygulamasına güvenmek verimli değildir ve bu kadar çok sayfa ve senaryoyu test edemez. Verilerin yıldan yıla ve aydan aya karşılaştırmalarına dikkat edin.Önemli değilse, testte yüz adet veri elde edilse bile, bin adet veri sorunu açıklayamaz, çünkü veri hataları özellikle büyüktür.Periyodik yıldan yıla ve aylık karşılaştırmalar 10.000'den fazla veri gerektirir. Açıklayıcı bir önemi olabileceğini düşünüyorum.
Bir başka büyük hata da WIFI. InterContinental Hotel, Tencent Building veya Netac Building'de bile, kullanılan Wi-Fi genellikle veri ve anlaşmanın analizi üzerinde büyük bir etkiye sahip olan ağ titremesinden muzdariptir, çünkü anlaşma muhtemelen sadece bir BT olacaktır, bu yüzden birkaç yüz milisaniye Gergin ağ ortamında, sonuçlara müdahale eden sorunlara neden olmak kolaydır. Bu nedenle, bu hataları ortadan kaldırmak için, genellikle cep telefonlarını ve PC'leri USB ile bağlarız, wifi'yi atlarız ve doğrudan kablolu ağları kullanırız çünkü kablolu ağlar, özellikle wifi kablosuzdan çok daha kararlıdır.
Araç trafik kontrolüdür, çünkü gerçek kullanıcılarımızın ağ ortamı son derece farklıdır. Farklı IP, farklı bant genişliği, farklı paket kaybı oranı, bu nedenle laboratuvardaki ortamı simüle etmek için bu aracı kullanıyoruz. Çevrimdışı simülasyon verileri elbette gerçek işimizin performansını temsil edemez.
Çevrimiçi iş hızı veri toplama
İkinci bölüm, çevrimiçi veri analizidir.
Sunucu tarafında veri toplama çözümünün iki avantajı vardır.
İlk nokta, müşterinin toplayamadığı verileri toplayabilmesidir ve alt düzey bilgi ve iş bilgilerini toplayabilir. Yukarıdaki şekilde gösterildiği gibi, sol taraf, cep telefonlarını, STW'yi veya yük dengeleyiciyi kullanabilen istemci tarafı ve sağ taraf, iş sunucusudur. İş bilgileriyle ilgili olarak, işletmenin genel işlem süresi, LB ile iş sunucusu arasındaki müşteri için mevcut olmayan etkileşim yoluyla elde edilebilir. İkinci nokta, TCP RTT, TCP bağlantısı yeniden kullanımı, TLS SESSION yeniden kullanımı, TLS protokol sürümü, şifre paketi, el sıkışma süresi, asimetrik anahtar değişimi hesaplama süresi, HTTP2 başlığı sıkıştırma oranı vb. Dahil olmak üzere protokol bilgileriyle ilgilidir. Müşterilerin alamayacağı tüm bilgiler.
Bazı bilgiler istemci tarafından toplanabilir ancak istemcinin geliştirme maliyeti çok yüksektir çünkü Android'in farklı işletim sistemleri için geliştirilmesi gereken IOS ve windows gibi farklı sürümleri vardır.Sunucu tarafında sadece bir geliştirme gereklidir. Veriler çerez içerisine konulur ve müşteriye geri gönderilir.Müşteri bilgileri JS veya sıradan sayfalar üzerinden alabilir.İlgi aldıktan sonra, protokole ilişkin bilgiler bir veri parçası halinde birleştirilir ve analiz için veri platformuna raporlanır.
Peki bu kadar çok veriyle, veri platformumuz bunu nasıl analiz ediyor?
Çok boyutlu veri analizi
Yukarıdaki şekilde gösterildiği gibi, büyük miktarda veri nedeniyle, analiz için yalnızca birkaçı yakalanır. Soldaki veri boyutu, örneğin, TCP'nin yeniden kullanımı, TCP bağlantısının yeniden kullanılması anlamına gelir, TLS1.2, TLS protokol sürümünün 1.2 olduğu anlamına gelir; sağda, başlangıç yükleme süresi, sayfa etkinlik süresi, iş işleme süresi vb. Gibi kullanıcı performansıyla ilgili izleme göstergeleri bulunur. Boyutlar, bu boyutlar da birbirleriyle birleştirilerek üç veya dört yüz boyut elde edilebilir. Yukarıdaki şekilde gösterildiği gibi, 4G ağı altında HTTP2 kullanan, TLS1.2 protokolünü kullanan ve TLS Oturumunu çoklamadan ECDHE kullanan Tencent X beş çekirdekli tarayıcının ilk ekran süresi nedir? Çok boyutlu karşılaştırma sayesinde, yavaş faktörü kolayca ayırt edebiliriz. X5'te çok fazla 4G var, bu yüzden ne kadarı 3G altında ve ne kadarı wifi altında? Çok boyutlu kapsamlı karşılaştırma sayesinde darboğazın bulunduğu yüzeyden görülebilir.
Bu nedenle, çok boyutlu veri analizinin nihai amacı performans darboğazlarını bulmak ve optimizasyon yönlerini hızlandırmaktır.Peki, optimizasyon talimatları nelerdir?
WEB erişim hızı optimizasyon yönü
Üç optimizasyon yönü vardır. İlk anlaşma; ikinci kaynak; üçüncü kullanıcı davranışı.
Anlaşma
TCP hız optimizasyonu
Peki, protokol seviyesi nasıl optimize edilir? Protokolün en alt katmanı TCP'dir ve TCP'nin en belirgin performans sorunu, bir TCP bağlantısı kurmak ve ardından uygulama katmanı verilerini göndermek için üç yönlü bir el sıkışma gerektirmesidir.Sıradan el sıkışma ile karşılaştırıldığında, bir RTT'yi boşa harcar. Yukarıdaki resmin sol tarafı normal bir tokalaşmadır. Her TCP bağlantısının bir el sıkışma oluşturması gerekir ve herhangi bir hareket grubu verisi olmadan SYN paketleri göndererek RTT boşa harcanır.
TFO, TCP HIZLI AÇIK'tır. Uygulama katmanı verileri, SYN paketi ile aynı anda gönderilir.Ancak, bunun öncülü, SYN paketinin el sıkışma ilk kez kurulduğunda ve bağlantı kurulduğunda gönderilmesi gerektiğidir.Aradaki fark, sunucunun SYN + ACK döndürdüğünde bir COOKIE döndürmesidir. Bundan sonra, kullanıcı bir TCP bağlantısı başlatır, SYN paketini gönderir, bu çerezi getirir ve ardından doğrudan HTTP verilerini getirebilir. Başka bir deyişle, uygulama katmanı verileri SYN paketinin gönderildiği anda gönderilir, bu da RTT'nin performans üzerindeki etkisini azaltır. TCP HIZLI AÇMA performansı bir gelir verisidir. 80 noktalı verinin neredeyse yüz milisaniye arttığını gördük. Ancak dezavantajı, işletim sistemi desteğine ihtiyaç duyması, IOS9 + veya linux kervel3.7 + gerektirmesi ve Windows sistemlerini desteklememesidir. Diğer bir optimizasyon şeması, üç tıkanıklık penceresini ona çıkaran tıkanıklık kontrolüdür.
Genel olarak, TCP protokol seviyesinde hız optimizasyonu için sınırlı bir alan vardır, çünkü optimizasyon maliyeti çok yüksektir, ancak yüksek nerede? İşletim sisteminin ve çekirdeğin desteğine ihtiyacı var. Yalnızca sunucu tarafında bir yükseltme ise, maliyeti destekliyor, araştırıyor ve geliştiriyoruz, ancak en önemlisi, kullanıcının işletim sisteminin yükseltilmesi ve geniş ağ ekipmanındaki yazılım protokol yığınının veya İşletim sistemi yükseltmeleri ve bu düzeyde dağıtım baskısı çok yüksektir. Bu nedenle, TCP düzeyindeki optimizasyon maliyeti çok yüksektir.
TLS hız optimizasyonu - oturum yeniden kullanımı
TLS, şifreleme katmanıdır ve şifreleme katmanıyla ilgili en büyük sorun, tam anlaşmadır. Tam el sıkışma ile ilgili olarak, temas halinde olan öğrenciler oturum kimliği konusunda çok net olmalı ve sürecini tanıtmayacağım.
Burada esas olarak iki noktayı paylaşıyorum. Yukarıda gösterildiği gibi. İlk nokta, IOS Qzone optimizasyonu ile ilgili. Oturum kimliği aracılığıyla el sıkışma süresi yaklaşık% 50 artırılabilir. İkinci nokta, oturum bileti mekanizmasının daha gelişmiş olmasıdır, çünkü sunucunun bellek depolama, bilet gönderme ve sunucu sağlamak için önbellek sağlamasına gerek yoktur. Sadece kontrol et. Oturum kimliğinin depolama için bellek sağlaması ve ardından oturum önbelleğinin vurulup vurulmadığını öğrenmesi gerekir.IOS oturum biletlerini desteklemediğinden, IOS oturum kimliğinin önbellek isabet oranını iyileştirmek için dağıtılmış oturum önbelleğine dikkat etmeniz gerekir. Pek çok senaryoda, el sıkışmayı basitleştirmenin bir yolu yoktur. Örneğin, kullanıcı APP'yi ilk kez açıp tarayıcıyı açtığında veya kullanıcı oturumu kapatıp tarayıcıyı yeniden başlattığında veya tarayıcı sayfasını kapatıp tekrar açtığı zaman. Sonuç olarak, oturum biletlerinin tümü sabit diskte depolanmak yerine belleğe dayandığından, oturum önbelleğinin basitleştirilmiş el sıkışması gerçekleştirilemez.
TLS hız optimizasyonu-Yanlış Başlangıç
Tam bir el sıkışma için optimize edilmiş yöntem, önleyici bir çalıştırma olan yanlış başlangıçtır. TFO fikrine benzer şekilde, yukarıdaki şeklin sol tarafında gösterildiği gibi, sıradan bir el sıkışma vardır.Bir bağlantı kurmak ve uygulama katmanı verilerini göndermek için iki RTT dört yönlü TLS el sıkışması gerçekleştirilmelidir. Yanlış başlangıç, clientKeyExchange'in değiş tokuş edilmediği, yani uygulama katmanı verilerinin, tam el sıkışmanın ikinci aşamasında birlikte gönderildiği ve bir RTT'yi yükselttiği zamandır. Yanlış başlatma nasıl etkinleştirilir? Aslında, istemci şimdi temelde desteklemektedir.Sunucu etkinleştirmek istiyorsa, PFS (Perfect Forward Password) şifrelemesini destekleyen algoritmanın yapılandırmasına dikkat etmeniz gerekir.Örneğin, önce ECDHE ve DHE algoritmaları yapılandırılabilir ve el sıkışma süresi değiştirilir. % 30 artırın.
TLS hız optimizasyonu-OCSP Zımbalama
OCSP Zımbalama. Az önce bahsedilen senaryolardan bazıları, sertifikayı aktif olarak iptal etmektir, bu nedenle sertifikanın durumunu kontrol etmek gerekir, çünkü bazı durumlarda, sertifikanın imzasını ve sertifikanın sertifikanın durumunu bulamadığını doğrulamak için geçen süreyi doğrulayın. Daha gerçek zamanlı denetim. Sertifikamızın düzenlenmesinden üç yıl sonra okulda sorunlar olabilir, bu nedenle periyodik denetimler yapacaktır.
Normal süreç benzerdir. İstemci merhaba sertifikayı aldığında, sürece eklenen 3 RTT'nin OCSP'nin durumunu ve içeriğini istemek için CA sitesine gitmesi gerekir. Yukarıdaki şekilde gösterildiği gibi, sağda OCSP Zımbalama vardır. İşlemi, sunucu aracısının CA'nın sertifika durumunu yayınlama işlevini yerine getirmesine eşdeğerdir. CA sitesinden OCSP içeriğini önceden talep eder ve yerel sunucuya kaydeder.Sonra el sıkışırken imza gibi olur İçeriği müşteriye iade edilir ve ardından müşteri içeriği doğrular. CA sitesiyle doğrudan etkileşime girmesi gerekmediğinden, OCSP Zımbalama'nın üç RTT'yi azalttığı görülüyor ve etki çok açık olmalı.
Ancak durum böyle değil, neden? İstemci OCSP'yi önbelleğe alacağından, istek olmaksızın yedi gün önbelleğe alınabilir.Yani bu yedi günlük süre boyunca, kullanıcı web sitesini birçok kez ziyaret ederse, binlerce kez olabilir çünkü bir sayfa için çok sayıda istek vardır. Dolayısıyla, bu üç RTT'yi artırmak için sadece 1 prob olasılığı olabilir. Herkesin bu etkinin mutlaka elde edilmediğinin farkında olması gerekir.
TLS hız optimizasyonu-dinamik kayıt boyutu
Şimdi kayıt blok boyutunun dinamik ayarı olan dinamik kayıt boyutunu analiz edelim.
TLS protokol düzeyinde satır engellemenin başını, yani satır başı engelleme sorununun arka planını kısaca açıklayayım.TLS protokol iletiminin en temel birimi kayıt olduğundan, bir kayıt bloğu 16K'yı ve Nginx gibi bazı sunucu uygulamalarını geçemez. En eski sürümün varsayılan boyutu 16K'dır. Peki 16K'ya ne olacak? Ortada bir bayt kaybederseniz veya TCP çipi bir segmenti kaybettiğinde, 16K doğrulanamaz. 15.99K veri alınsa bile, bir veri kaybı nedeniyle bununla başa çıkmanın bir yolu yoktur. Paketin kaybı, tüm kaydın işlenmesini engeller.
Nasıl çözeceksin? İki yol var.
Birincisi, arabelleği uygun şekilde azaltmaktır, örneğin, gerçek isim sistemi olmadan 4K'ya değiştirmek, kaybolsa bile, 16K verilerini değil, yalnızca 4k verilerini etkileyecektir.
İkincisi, TCP'nin yavaş başlangıç prensibinden öğrenmektir. Bulut parlaması bir yama sağlar. TLS bağlantısı henüz kurulduğunda, ağ durumu ve tıkanıklık bilinmediği için kayıt ayarı 1K'ya düşürülür. Gönderme hızı artırıldıktan sonra kayıt boyutu 16K olarak ayarlanır. Muhtemelen böyle bir fikir ve açık kaynak kodu da var, eğer ilgileniyorsanız, öğrenebilirsiniz.
Az önce bahsedilen bu optimizasyon stratejileri TLS1.2 ve önceki sürümler içindir. Ardından, devrim niteliğinde, çok yenilikçi ve dönüm noktası olan bir protokol olan TLS1.3 sürümünü tanıtacağız.
TLS1.3 hız optimizasyonu
TLS1.3 hız optimizasyonu-ORTT El Sıkışma
Performanstaki yenilikçi nokta, tam bir 1RTT el sıkışma ve 0RTT'nin basitleştirilmiş bir el sıkışma elde edebilmesidir. Başka bir deyişle, TLS bağlantı seviyesinde hiçbir el sıkışma prensibi RTT gecikmesini artırmayacaktır. TLS1.3 hala taslak aşamasındadır. Erken denemek isterseniz burada kullanılabileceği için burada tanıtılmıştır. Çünkü OpenSSL1.1.1 ve Nginx1.13.0, TLS1.3'ün en son draftını20 zaten desteklemektedir. Ve TLS1.3 ile ilgili en son tartışma bu sonbaharda resmen açıklanabilir. İstemci kendi başına kontrol edebiliyorsa, deneyebilirsiniz, Firefox da dahil olmak üzere TLS1.3'ü destekler. Tabii ki, bunların hepsi taslak versiyonlar, bu yüzden onları burada tanıtacağım. Spesifik süreç aslında daha karmaşık, bu yüzden burada ayrıntılara girmeyeceğim.
HTTPS hız optimizasyonu
HTTPS hız optimizasyonu-HSTS 302 sıçramayı azaltır
HSTS aslında HTTP'nin başlığıdır. İşlevi, sunucunun istemciye gelecekte web sitemi ziyaret ettiğinizde, belirtilen süre içinde HTTPS kullanmanız gerektiğini ve HTTP kullanmamanız gerektiğini söylemesidir. Bununla birlikte, HSTS'nin HTTP aracılığıyla döndürülmesiyle ilgili bir sorunu var ve bu muhtemelen bir aracı tarafından ele geçirilecek. Başka bir deyişle, istemci sunucunun HSTS gönderdiğini asla bilemez ve https kullanmanın bir yolu yoktur. Bu durumda, zayıf bir ön yükleme listesi mekanizması vardır.Örneğin, Chrome tarayıcısı web sitenizi beyaz listede oluşturacak ve bir erişim isteği gönderdiğinizde, varsayılan olarak HTTPS kullanacaktır; Aynısı istemci için de geçerlidir.
HTTPS hız optimizasyonu-SPDYHTTP2
SPDY ve HTTP2. SPDY'den neden bahsediliyor? İki ana nokta var.
İlk nokta, çünkü HTTP2 şu anda çok popüler ve resmi olarak yayınlandı, ancak SPDY'de başlık sıkıştırma algoritması dışında tüm özellikleri ve en önemli özellikleri kullanılıyor, bu yüzden önce SPDY protokolünü inceledim ve şimdi mümkün. Çoğu kişi yalnızca HTTP2'yi bilir ancak SPDY'yi bilmiyor. Bu yüzden, anlaşmaya saygı göstermek için, çünkü yaratıcısı o.
İkinci nokta, çoğu eski istemcinin yalnızca SPDY'yi desteklemesidir.Örneğin, Android 4.4 ve önceki sürümler ve IOS artık SPDY'yi de desteklemektedir. Eski sürümlerle uyumlu olmak için performanslarını artırın ve aynı anda SPDY ve HTTP2'yi destekleyin.
Üç özelliği vardır.
İlki çoklamadır. Tek bir bağlantı üzerinden aynı anda birden fazla istek gönderilir ve istek ile istek arasındaki protokol seviyesi bağımsız veya bağımlı olabilir. Örneğin, ikinci istek ilk işlenirse, önceden iade edilebilir. HTTP 1.1 ile karşılaştırıldığında, aynı zamanda ardışık düzen çalışmaları da yapmıştır. İstemcinin aynı anda birden fazla istek göndermesine izin verir, ancak sunucu kesin sırayla geri dönmelidir, aksi takdirde karışıklık olur. Hangi talebin hangi yanıta karşılık geldiğini bilmez. Bu, üçüncü istek ilk olarak işlense bile önceden iade edilemeyeceği anlamına gelir; başka bir deyişle, dört isteğin tümü işlenir, ancak üçüncü istek kaybedilirse, tüm sıra sorun olur. HTTP2'nin en güçlü özelliği, yüz isteği hatta yüzden fazla isteği birlikte gönderebilen çoklamadır.
SPDY ve HTTP2 ile ilgili olarak, iki noktayı kolayca gözden kaçırabilirsiniz. İlk nokta başlık sıkıştırmadır. Sıkıştırılmış veriler ve tanıtım sayfalarının sıkıştırma oranı muhtemelen% 89 veya% 90 olacaktır, ama durum bu mu? Test sonucunda, ilk istek bir TCP bağlantısı üzerinden gönderildiğinde, o andaki HTTP2'nin sıkıştırma oranının sadece% 30 olduğu, ikinci istek gerçekleştiğinde ise sıkıştırma oranının% 60'a, üçüncü isteğin daha sonra% 90'a ulaşabildiği bulunmuştur. SPDY, zlib tabanlı bir sıkıştırma algoritması kullandığından, HTTP2 Hpack tabanlı bir sıkıştırma algoritması kullandığından, bunlar durum uzayına göre sıkıştırılır, bu nedenle bilgi daha fazla ve tekrarlıysa, bu bağlantı üzerinde tekrar tekrar okuduğunuzda, Sıkıştırma oranı daha yüksek olacaktır. Dolayısıyla, ilk istek gerçekleştiğinde, başlık çok fazla gereksiz değildir ve sıkıştırma oranı yalnızca% 30 olabilir.
Performans optimizasyonu açısından bizim için bir ilham kaynağı, bir sonraki sayfaya bir sayfa yerleştirilecekse, veri biriktirmek için önceden sayfaya veya alan adı bağlantısına iki boş istek gönderebilmemizdir. Gerçek kullanıcı talebi başlatıldığında, üçüncü işbirliğine ulaşılarak kullanıcının kafa sıkıştırma oranı% 90'a ulaşabilir.
İkincisi, sunucu itmedir. Nginx server push'u desteklemediğinden, bu uygulama Çin'de hala nadiren kullanılmaktadır, ancak gerçekten çok kullanışlıdır. Örneğin, istemci bir html isterse, html css ve görüntüler içerir.Normalde, html'yi ayrıştırdıktan sonra, sırasıyla CSS istekleri ve görüntü istekleri gönderir, ancak sunucu sayfanın sunucu iletimini desteklediğini bilirse, istemcinin yalnızca Bir http isteği gönderdiğinizde, sunucu doğrudan css ve resimleri birlikte gönderir, böylece önce birden çok yanıt gönderilmez. Bu, satır içi yapmaya benzer, ancak satır içi yapmaya kıyasla iki avantajı olan sunucu aktarımının rolüdür. Satır içi oluşturma, önbelleği etkileyecek ve arka plan şablonunun bakımı da dahil olmak üzere html boyutunu artıracaktır. Bu aynı zamanda geliştirme ve bakım maliyetlerini de artırır. Müşteriler için Yalnızca birden çok istek açısından.
HTTP2 pratik öneriler
İnternette HTTP2P'nin pratik önerileri ve prensip bilgisi hakkında halihazırda pek çok bilgi var, bu yüzden size esas olarak pratikte kendi deneyimlerimizden ve deneyimlerimizden bazılarını anlatıyorum.
-
İlk olarak, bir bağlantı kullanın veya daha az bağlantı kullanın. Çok fazla bağlantı kullanmayın, neden? İlk olarak, daha az bağlantı ve daha az anlaşma maliyeti vardır. İkincisi, sıkıştırma oranı yüksektir, çünkü bir bağlantıda biriken çok fazla bilgi vardır ve sıkıştırma oranı daha yüksek olacaktır. Üçüncüsü, TCP'nin özelliklerinden daha iyi yararlanın Neden? TCP'nin tıkanıklık kontrolü akış kontrolü tek bir bağlantıya dayandığından, özellikle ağ tıkanıklığı durumunda birçok bağlantı kullanılırsa tıkanıklık katsayısı büyütülecek ve ağ tıkanıklığı artacaktır.Bir bağlantı kullanırsanız, pencerenin kapalı olduğunu bileceksiniz. Tıkanıklık, yanıt çok yavaş ve gönderilmeye devam etmeyecek, ancak birden fazla bağlantı olması durumunda, herkes onu göndermeye çalışabilir, bu da ağ tıkanıklığını artıracaktır.
-
İkinci olarak, daha az alan adı kullanın; bu, aynı zamanda bağlantıları daha iyi kullanmak ve DNS çözümleme süresini azaltmaktır.
-
Üçüncüsü, çok sayıda alan adı kullanmanız gerekiyorsa, birden fazla alan adını aynı IP'ye çözümlemeye çalışın ve aynı sertifikayı kullanın. Çünkü istemci tarafından uygulanan perspektif standardı, eğer birden fazla alan adı aynı ip ve aynı sertifikayı yeniden kullanabiliyorsa, bu bağlantıyı yeniden kullanacağım ve yeni bir bağlantı oluşturmayacağımdır. Örneğin, krom tarayıcı; satır içi yerine esnek sunucu push kullanımı; TLS1.2 ile ilgili olarak, varsayılan olarak TLS1.2'den önceki bir sürümü kullanıyorsa, HTPP2 kullanılamaz. TLS1.2 tüm şifre paketlerini desteklemez. Birçok şifre paketi kara listeye aittir. Bu aynı zamanda HTPP2'nin düşük kullanım oranının nedenlerinden biridir; HTPP2 tüm sorunları çözmez. Çok öğeli, çoklu bağlantı için uygundur Senaryoda, sayfanızın kendisi çok basitse, yalnızca birkaç istekle, sıradan TLS kullanmak sorun değil, bu senaryoda erişim performansını iyileştirmeyecektir. Ancak genel olarak herkese kesinlikle tavsiye edilir.
kullanıcı davranışı
Önceden oluşturulmuş bağlantı
Önceden oluşturulmuş bağlantı, en basit ve en etkili hız optimizasyon çözümüdür Neden? Önceden kurulmuş bağlantı fikri, kullanıcı gerçek bir bağlantı başlatmadan önce bir bağlantı kurmaktır. Bu durumda, bağlantıdan kaynaklanan maliyet ve gecikme kullanıcı tarafından algılanmaz. Önceki optimizasyon şemaları serisinde, 0 RTT anlaşması olsa bile, bilet doğrulama gibi bazı hesaplamalar vardır.
Önceden oluşturulmuş bağlantılara ne dersiniz? İki yöntem var.
İlk nokta bağlantı başlığı etiketidir, örneğin bağlantı tarayıcıya, yani sunucuya geri dönebileceğini söyler; veya tarayıcıya sayfanın bir sonraki sayfayı ziyaret etmesi gerekebileceğini söyler, ardından benimle önceden bir ön bağlantı kurar. Bu, bağlantı başlığını destekleyen tarayıcılarda mümkündür. Ya bu özellik desteklenmiyorsa?
İkinci nokta JS kontrol sayfasındandır. Örneğin, arka plan sayfasında bir JS var ve ziyaret etmek üzere olduğunuz sayfa için onunla önceden bağlantı kurabilirsiniz. Kullanıcı bir istek başlattığında, JS bunun için önceden bir bağlantı kurmuştur. Diğer birçok senaryo var. Birincisi, ana sayfanın alt sayfa bağlantıları için önceden oluşturulabilmesidir.Örneğin, Baidu ana sayfası, Baidu ana sayfası çok basit, arama sonuçları çok farklı, ancak arama sonucu web sitesi de sabitlenebilir AA.com, kurulumu kolay Bağlantı; ikinci Qzone'da bazı kullanıcılar Qzone'u açabilir ve fotoğraf albümlerini görüntüleyebilir ve bazı kullanıcılar hediyelere erişmek için sıklıkla alışveriş merkezi pandantifini ve alışveriş merkezini ziyaret eder, böylece kullanıcıların sık ziyaret ettiği sayfalara göre önceden farklı doğrudan ön bağlantılar kurabiliriz. Önceden oluşturulmuş bağlantı da zamanla kesilebilir.
Peki bundan nasıl kaçınılır? Korumak için uzun bir bağlantı kullanabilirsiniz. Örneğin, HTTP2 tarayıcısının bağlantısı üç dakikadan daha uzun bir süre içinde kesilecek ve HTTP'nin bağlantısı beş dakikadan daha uzun bir süre içinde kesilecektir. Uzun bir bağlantıyı sürdürmek için, bu sayfalara uzun bağlantı tutma isteklerini periyodik olarak başlatmak için JS kullanabiliriz. Bu durumda, bağlantı eşdeğerdir Önceden oluşturulmuş bağlantıların bir avantajı olan ziyaret sırasında kullanıcı tarafından kurulan durumu her zaman koruyacaktır.
HTTPS'nin hızıyla ilgili temel bir sonuç, HTTPS'nin erişim hızının HTTP 1.1'i aşabileceğidir. En kritik ve temel nokta, HTTPS'nin çoğullamayı kullanabilmesidir, ancak HTTP1.1 bunu yapamaz. Optimizasyon yöntemi düğümleriyle ilgili olarak, yukarıdaki şekilde gösterildiği gibi, bu iki yıl önceki verilerdir ve optimizasyon stratejileri HTTP2 ve SPDY dahil olmak üzere aynıdır, önemli bir fark yoktur.
HTTP2 gelecek mi?
Daha önce bahsedilen HTTP2'nin güçlü özelliklerinden bazıları bizim için çok faydalıdır. Günümüzde HTTP2 yeni nesil İnternet protokolü olarak kabul ediliyor, ancak bu gerçekten bizim geleceğimiz mi? Başka bir deyişle, HTTP2 önümüzdeki on yılda en yetkili ve baskın protokol mü? Cevap Evet. Evet. Çoklama, başlık sıkıştırma, sunucu itme, öncelik vb. Birçok özelliği nedeniyle tasarım çok gelişmiş, performans da son derece iyi ve birçok performans sorununu çözüyor.
Ancak cevap hayır da olabilir. neden? Geçerli HTTP2, TCP protokolüne ve TLS protokolüne dayandığından, bazı sorunlar vardır.
İlk olarak, TCP protokolünün üç yönlü bir el sıkışması vardır. TFO'yu destekleyebilmesine rağmen, TFO işletim sistemi desteği gerektirir. Ve TFO, COOKIE'yi almak için ilk kez bir bağlantı kurduğunda, anlaşmayı gerçekleştirmek için ek bir RTT'ye ihtiyaç duyulur. Ek olarak, TLS1.3, 0RTT el sıkışmasını destekler, ancak TLS, TCP başlığını doğrulamaz ve pencere sayısının değiştirilmesi, seri numarasının değiştirilmesi vb. Gibi tümünün ele geçirilebileceği bir kurcalama riski olabilir.
En büyük problem, TCP'nin satır başının bloke olmasıdır.Örneğin, segmentleri ilettiğimizde, ikinci segment kaybolursa, iletim başarısız olur.Güvenilirliğini ve sırasını sağlamak için ikinci segment gelene kadar beklememiz gerekir. Uygulama katmanına yüklenebilir Maalesef, HTTP2'nin çoğullama doğası nedeniyle, varsayımsal 50 istek bir TCP platformunda gönderilirse, hat başı engelleme sorununu ağırlaştıracaktır. TCP yeniden iletimi ile ilgili olarak, yeniden iletimin sıra numarası, yeniden iletimin belirsizliğine neden olacak orijinal sıra numarasıyla aynıdır. Tıkanıklık kontrolü ile ilgili olarak, işletim sistemi yükseltmeleri gereklidir, ancak TCP yükseltmeleri pahalıdır ve kullanıcıların ve ağ ekipmanı aracılarının destek için yükseltme yapmalarını gerektirir.
Yani protokol açısından, HTTP2 önümüzdeki on yılda en baskın veya en kasıtlı ve yetkili protokol değil.Peki çok rekabetçi bir protokol nedir? HTTP2'yi uygulamak için UDP kullanan QUIC protokolüdür. Aşağıdakiler onun özellikleridir.
QUIC protokolünü benimseyin
HTTP2 server push TLS 1.3 0RTT UDP packet packet
CLB QUIC 15%
yazar hakkında
2011 2011 2015 2015 TEG STGW HTTPS, SPDY, HTTP2, QUIC ve diğer uygulama katmanı protokolleri, yüksek performanslı sunucu teknolojisi, bulut ağ teknolojisi, kullanıcı erişim hızı, dağıtılmış dosya aktarımı vb. Hakkında derin bir anlayışa sahip olun.
Bugünün TavsiyesiOkumak için aşağıdaki resme tıklayın
30
