Android istemci ağ performans ayarı için HTTP / 2 protokol yükseltmesi
Bir
Genel Bakış
HTTP / 2 (Köprü Metni Aktarım Protokolü Sürüm 2) protokolü ilk olarak Aralık 2014'te önerildi ve RFC 7540 resmi olarak Mayıs 2015'te yayınlandı. HTTP / 2 protokolünün doğuşunun ardından Google, Facebook ve diğer yabancı internet firmaları hızlı bir şekilde takip etti ve yerli internet firmaları da mobil tarafta HTTP / 2 protokolünü tanıtmaya başladı.
JDnin kablosuz terminalindeki kullanıcı ziyaretlerinin sayısı hızla arttı ve kablosuz terminaldeki görüntü içeriği de metinden, resimlerden çeşitli videolara, canlı yayınlara ve VR'ye kadar çeşitlilik gösteriyor. Bu nedenle, ağ performansını optimize etmek ve gelecekteki iş geliştirme için bir temel oluşturmak için HTTP / 2 protokolü gereklidir. İyi bir temel. Ek olarak, yurtiçi operatörler çeşitli trafik kaçırma ve reklam ekleme sorunları ile zorlu bir ortama sahiptir.Site çapında HTTPS projesinin ilerlemesiyle, HTTP / 2 protokolü HTTPS + HTTP / 1.X'ten fazlasını getirebilen HTTPS'ye dayanmaktadır. İyi deneyim.
JDnin Android istemcisi 2016 sonunda HTTP / 2 protokolünü yükseltti. JDnin 2017'deki 618 ve Double 11 promosyonundan sonra, Sitenin tamamında sıfır arıza, JD mobil terminalinin HTTP / 2 çağına girdiğini gösteriyor .
İki
Android istemcisi HTTP / 2 protokol sürecini tanıtıyor
İkili çerçeveleme
HTTP 1.1'in performans sınırlamalarını aşmak ve HTTP, HTTP yöntemleri, durum kodları, URI'ler ve başlık alanlarının anlamını değiştirmeden iletim performansını iyileştirmek için uygulama katmanı ile taşıma katmanı arasına ikili bir çerçeveleme katmanı eklenir. , Düşük gecikme ve yüksek verim elde etmek için.
İkili çerçeveleme katmanında, HTTP2.0 iletilen tüm bilgileri daha küçük mesajlara ve çerçevelere böler ve bunlar için ikili biçim kodlamasını kullanır.
Sıkıştırılmış başlık
HTTP / 1.x başlığının, çerez ve kullanıcı aracısı nedeniyle şişmesi kolaydır ve her seferinde tekrar tekrar gönderilmelidir.
HTTP2.0, iletilmesi gereken başlığın boyutunu azaltmak için HPACK algoritma sıkıştırmasını kullanır İletişim önbelleğindeki her iki taraf, yalnızca tekrarlanan başlıkların iletimini önlemekle kalmayıp aynı zamanda iletilmesi gereken paket sayısını da azaltan ve böylece gecikmeyi azaltan bir başlık alanları tablosu.
Çoğullama
İstemci ve sunucu, HTTP mesajlarını bağımsız çerçevelere ayırabilir, bunları sırasız gönderebilir ve son olarak diğer uçta yeniden birleştirebilir.
Bir bağlantıda aynı anda çok sayıda istek başlatılabilir ve aynı anda yanıtlar geri gönderilebilir.
Üç
Android istemcisi, HTTP / 2 protokolüne göre optimize edilmiştir
HttpDns şemasıyla uyumlu
İstemcinin birleşik arayüzünün ve görüntüsünün HTTP / 2 ağ talebi, operatörün LocalDNS çözünürlüğünün ele geçirilmesini önleyen, kullanıcı çözünürlüğü başarı oranını iyileştiren ve sunucu çözünürlüğü anahtarının etkin süresini hızlandıran ve arızaları azaltan kendi geliştirdiği HttPDns hizmetine uyarlanmıştır. Etki alanı
Android yerel ağ arayüzü HttpUrlConnection, HTTP / 2 protokolünü desteklemediğinden, JD mobil istemci ağ modülü, Squarein açık kaynak ağ bileşeni Okhttp'yi entegre eder. Okhttp bileşeni, HTTP / 2 protokolünü yerel olarak destekler. Bununla birlikte, HttpDns hizmetiyle uyumlu olduğunda, aşağıdakilerin ele alınması gerekir sorun:
Soru 1: URL'deki ana bilgisayar HttpDns IP'si ile değiştirildikten sonra HTTP / 2 protokol dönüşümü: yetki alanı düzeltildi
JD istemci ağ modülü, istek URL'sindeki Ana Bilgisayar alanını HttpDns tarafından verilen IP ile değiştirerek ve ardından arka plan nginx sunucusunun isteği doğru şekilde iletebilmesini sağlamak için Başlığa Ana Bilgisayar alanını ekleyerek HttpDns'e erişir. HTTP / 2 protokolü RFC belgesinde, HTTP / 1.xHeader'daki Host alanı yerine yetki alanı kullanılır. Okhttp, V3.6.0'dan önceki iki alan arasında dönüşüm yapmadı, bu da nginx sunucusunun doğru: otoriteyi alamamasına neden oldu Alan, istek iletimini gerçekleştirmek için yanlış gönderildi.Sorun 2: URL'deki ana bilgisayar HttpDns IP'si ile değiştirildikten sonra, SSL / TLS el sıkışmasının başlangıcındaki SNI alanı düzeltildi
SNI (Sunucu Adı Göstergesi), bir sunucu için birden fazla alan adı ve sertifika kullanan SSL / TLS uzantısı sorununu çözmektir. Çalışma prensibi, SSL / TLS bağlantısı kurmak için sunucuya bağlanmadan önce ziyaret edilecek sitenin alan adını (Ana Bilgisayar Adı) göndermektir, böylece sunucu bu alan adına göre uygun bir sertifika döndürür. SNI aktarım işlemi, taşıma katmanı (TCP) katmanına dayandığından, Host ile HTTP protokol katmanına dayalı Üstbilgi alanı etkili değilse, Okhttp'nin Sni iletim süreci burada değiştirilir ve Sni parametreleri uygulama katmanından şeffaf olarak Sni'nin mevcut URL'yi sunucu tarafından tanıyamadığı için ayrıştırması sorununu çözen taşıma katmanı.Sorun 3: HTTP / 2 uzun bağlantı kurulumunun el sıkışma sürecinde ağ etki alanı adı doğrulama sorununu düzeltin
Alan adı doğrulaması, Https el sıkışma sürecinde sertifikanın geçerliliğini doğrulamanın önemli bir parçasıdır.Amaç, sunucu tarafından verilen sertifika yetkilisinin meşruiyetini doğrulamaktır. Alan adı doğrulamasını basitçe görmezden gelirseniz, aracıya bir fırsat verecektir. Okhttp el sıkışma işlemi Ana Bilgisayarı, URL'den ayrıştırılır. URL'deki Ana Bilgisayar, HttpDns'nin IP adresiyle değiştirilirse, Https el sıkışma doğrulama işlemi başarısız olur. Bu, aynı zamanda Okhttp aktarım katmanı el sıkışma sürecinden geçer. Geçiş doğrudur. Ana bilgisayar alanı, HttpDns IP doğrudan bağlantı senaryosuna uyarlanmıştır.İstemci HTTP / 2 uzun bağlantı yönetimi optimizasyonu
sorun bulundu : Android istemcisinin HTTP / 2 protokol güncellemesinden sonra belirli sayıda kullanıcı, uygulamanın arka planda uzun bir süre sonra ön plana geçtiğini veya JD uygulamasının uzun bir uyku döneminden sonra uyandığını bildirdi.
Problem analizi : Bu tür bir şikayete yanıt olarak, sonuca analiz yoluyla ulaşılır: müşterinin düzenli bir uzun ağ bağlantısı bağlantısı sürdürmesi gerekir ve Android sistem sürümünün yinelenmesi sırasında, sistem daha sıkı güç tüketimi ve trafik yönetimine sahip olduğundan, uyku veya Boşta kalır Bu süreçte ağ bağlantısı sistem seviyesinde kapatıldı ve uygulama katmanı bağlantısı zamanında bildirilmedi bu da ağ talebinin zaman aşımına uğramasına, zaman aşımı isteği için bekleme süresinin çok uzun olmasına ve kullanıcı deneyiminin son derece zayıf olmasına neden oldu.
İyileştirme planı : Uzun bağlantı kesildikten sonra istek zaman aşımını iyileştirmek için, istemci Okhttp için bir Ping çerçevesi sinyal mekanizması ekler. İşlem şu şekildedir:
İstemci, HTTP / 2 protokolüne dayalı olarak ağ iletişimini gerçekleştirir. HTTP / 2, alt katmandan çoklama uygular. Birden çok istek, istekler için bir bağlantı paylaşır. İstemci boştayken, bağlantı canlı kalır
Burada, sunucuya düzenli aralıklarla Ping çerçeveleri göndermek için uygulanır.Sunucu, sonucu belirtilen süre içinde döndürebilirse, bir sonraki kalp atışı turuna devam edin
Toplam n kalp atışından sonra (n, sunucu tarafından gönderilen sinyal sayısıdır), hala boş durumdaysa, bağlantıyı kesmek için sunucuya aktif olarak bir Goaway çerçevesi gönderir ve ardından yerel bağlantıyı keser
N kalp atışı döngüsü içinde bir kalp atışı zaman aşımı tespit edilirse, yerel bağlantı doğrudan serbest bırakılacak ve bağlantı sonraki talepte yeniden başlatılacaktır.
Etkiyi geliştirin : Ping çerçeve kalp atışı mekanizmasının kullanılmaya başlanmasından sonra, uyku ya da uzun süre ön plana geçme nedeniyle oluşan yükleme zaman aşımı şikayetleri neredeyse ortadan kalktı.
BTW : JD istemcisi, uzun bağlantı kalp atışı işlevini sunarken HTTP / 2.0'ı başlattıktan sonra, Okhttp yetkililerine uzun bağlantının hayatta kalma durumunu değerlendirme ihtiyacını da önerdi.
Okhttp, bağlantının kullanılabilirliğini belirlemek için bu yıl en son sürüm 3.10.0'a HTTP / 2 kalıcı bağlantı Ping / Pong mekanizmasını ekledi.
Artık tüm geliştiriciler, uzun bağlantı zaman aşımı sorununu iyileştirmek için resmi sürümü kullanabilir.
SSL / TLS el sıkışma sürecinin derin optimizasyonu
JD Mobile Terminal, el sıkışma sürecini derinlemesine optimize etmiştir.Önemli optimizasyon noktalarından biri, HTTP / 2 el sıkışma sürecini optimize etmek için Oturum Bilet / Oturum Önbelleği mekanizmasının tanıtılmasıdır.
Mevcut HTTPS ve HTTP / 2 protokollerinin bir bağlantı kurması gerekir. Her yeni TLS bağlantısı, paylaşılan bir şifreleme anahtarı oluşturmak için bir el sıkışma gerektirir. Bu el sıkışma işlemi, standart TCP el sıkışma işlemine ek olarak iki ek gidiş-dönüş işlemi gerektirir (Toplam 7 el sıkışma), istek verimliliğinde gecikmeye neden olur. TLS, bir oturumu yeniden kullanma gibi fazladan gidiş-gelişleri ortadan kaldırmak için kullanılabilecek çeşitli özelliklere sahiptir. İki standart oturum yeniden kullanım mekanizması, oturum kimlikleri (RFC 5246) ve oturum biletleridir (RFC 5077). Bu teknolojilerden birini kullanarak bir istemci yeniden kullanabilir Önceden oluşturulan oturum için, bu oturum daha önce sunucuyla başarılı bir şekilde el sıkıştı ve bu da bir gidiş-dönüş sürecini azaltabilir.
Şu anda, JD Android istemcisi TLS oturum bileti yeniden kullanım mekanizmasını desteklemektedir Oturum biletleri, yalnızca sunucu tarafından bilinen bir güvenlik anahtarı ile şifrelenen ve son olarak mobil terminale kaydedilen oturum bilgileridir. Mobil terminal TLS anlaşması olduğunda, sunucu şifresini başarıyla çözebildiği sürece oturum bileti bilgilerini getirin, hızlı anlaşma tamamlanabilir.
Oturum biletleri çözümünün işlevsel özellikleri, oturum kimlikleri çözümünden önemli ölçüde daha iyidir, çünkü oturum kimlikleri sunucu tarafında ek depolama ek yükü gerektirir ve küme depolama tutarlılığı sağlar ve sunucu için ek performans ek yükü nispeten büyüktür. Oturum biletleri, endüstride şiddetle tavsiye edilen bir uygulama çözümüdür Oturum bileti sunucu anahtarlarının potansiyel güvenlik riskleriyle ilgili olarak, JD sunucusu, güvenliği sağlamak için düzenli anahtar değiştirme ve birleşik dağıtım yöntemlerini benimser.
Kullanıcı erişim kalitesi izleme ve ağ felaket toleransı optimizasyonu
HTTP / 2 protokolüne ilk erişim nedeniyle, istemci uygulamasının kararlılığı hala bilinmemektedir, bu nedenle erişim kalitesinin ve felaket toleransının izlenmesinde aşağıdaki optimizasyonlar yapılmıştır:
Çevrimiçi kullanıcı sayısının keskin bir şekilde arttığı göz önüne alındığında, sunucunun performansı üzerinde aşırı baskıya neden olabilir. İstemci, HTTP / 2 protokol açık durumunu kontrol etmek için bir çevrimiçi anahtar ekler; bir anormallik meydana geldiğinde, anahtar zamanında geri dönecek şekilde ayarlanabilir
HTTP / 2 açıldıktan sonra, bir istisna gömülü nokta rapor edilir.Bir istisna varsa, izleme platformu üzerinden problem zamanında bulunabilir ve problem kullanıcının anormal detayları sorgulanabilir
Anormal bir HTTP / 2 isteği oluştuğunda, istemci bir eski sürüme düşürme yeniden deneme mekanizması başlatacaktır. Buradaki düşürme stratejisi, yeniden deneme, protokol düşürme, yerleşik arama testi, akıllı yönlendirme ve diğer stratejiler dahil olmak üzere biraz daha karmaşıktır. Amaç, istemciyi geliştirmektir. Ağ afet toleransı. Yazar burada ayrıntılı olarak tanıtmayacaktır.
Uygulama, geliştirme ve çalıştırma ve bakım personelindeki ağ performansı istatistikleri verilerinin izlenmesini ekleyin, ağ performansını kapsamlı bir şekilde izleyebilir, aşağıdaki şekil, HTTP / 2 tamamen yüklendikten sonra yerel arabirimin yanıt süresinin% 30 arttığını ve iyileştirme etkisinin önemli olduğunu göstermektedir
Wanton
sonuç olarak
Tam site HTTPS döneminin açıklığa kavuşturan çağrısına yanıt olarak, JD Mobil Terminalleri 2016'nın sonunda HTTP / 2 protokolünün tam çevrimiçi dağıtımını gerçekleştirdi. On milyonlarca eşzamanlı trafikle bir yıldan fazla süren testin ardından, birçok zor sorun çözüldü. Ağ güvenliği ve verimliliği açısından, JDnin kablosuz terminalleri performansı hala sürekli olarak optimize ediyor ve geliştiriyor. Sistem mimarisi veya teknik ayrıntılardan bağımsız olarak, işletim ve bakım ve geliştirme ekipleri çok fazla enerji ve ter harcadı. Size gelecekte daha fazla özü göstereceğiz. Lütfen bizi takip edin!
