WeChat terminali çapraz platform bileşeni mars serisi sinyal iletim ağ modülünün zaman aşımı
mars, WeChat resmi C ++ tarafından yazılmış, işletmeden bağımsız ve platformdan bağımsız bir terminal temel bileşenidir. Şu anda WeChat Android, iOS, Windows, Mac, Windows Phone ve diğer platformlarda kullanılmaktadır ve açık kaynak için hazırlanmaktadır. Esas olarak aşağıdakileri içerir Ayrı parçalar:
-
COMM: Soket, iş parçacığı, ileti kuyruğu ve coroutine gibi temel araçları içeren temel kitaplık;
-
XLOG: Mobil terminallerin özelliklerini tam olarak dikkate alan, yüksek performans, yüksek kullanılabilirlik, güvenlik ve hataya dayanıklı günlük işlevleri sağlayan genel günlük modülü; (ayrıntılar için orijinal metni okuyun: yüksek performanslı günlük modülü xlog)
-
SDT: ağ teşhis modülü;
-
STN: terminal ile sunucu arasındaki küçük veri sinyalleşme kanalından sorumlu sinyal iletim ağı modülü. Mobil ağlarda WeChat terminallerinin çok sayıda optimizasyon deneyimini ve başarısını içerir ve büyük WeChat kullanıcılarının testinden geçmiştir.
Bu makale herkes için STN'yi (Sinyal İletim İletim Ağı Modülü) tanıtacaktır. STN'nin karmaşıklığından dolayı bu modül, giriş için birden çok bölüme ayrılacaktır.Bu makalenin ana içeriği WeChat'te okuma ve yazma zaman aşımlarının düşünülmesi ve tasarlanmasıdır.
Zaman aşımı ve tasarım hedeflerini okuyun ve yazın
TCP / IP'de zaman aşımı tasarımı
WeChat sinyal iletişimi temel olarak TCP / IP protokolünü kullanır ve veriler uygulama katmanı, taşıma katmanı, ağ katmanı ve bağlantı katmanından geçer (bkz. Şekil 1). Bunlar arasında, bağlantı katmanı ve taşıma katmanı, protokol bir zaman aşımı yeniden iletim mekanizması sağlar.
Şekil 1 TCP / IP protokolünü kullanma
Bağlantı katmanında zaman aşımı ve yeniden iletim
Bağlantı katmanında, genellikle hibrit otomatik tekrar talebi (yani HARQ) kullanılır. HARQ, FEC (ileri beslemeli hata düzeltme) ve ARQ'yu (otomatik tekrar isteği) birleştiren bir teknolojidir. İlke, Şekil 2'de gösterilmiştir.
Şekil 2 HARQ prensibi
İki doğrulama ve zaman aşımı mekanizmasını kullanarak, bağlantı katmanı, güvenilir olmayan fiziksel aygıtlar temelinde güvenilir bilgi iletimini gerçekleştirir. Bu çözüm hem cep telefonlarının hem de RNC'nin desteğini gerektirir ve şu anda EDGE, HSDPA, HSUPA, UMTS ve LTE'de desteklenmektedir.
Taşıma katmanının zaman aşımı ve yeniden iletimi
Taşıma katmanı (TCP katmanı) güvenilir iletim sağlar Ancak, TCP katmanının dayandığı bağlantı güvenilmezdir TCP güvenilmez bir ortamda nasıl güvenilir hizmetler sağlar? Cevap, zaman aşımı ve yeniden iletimdir. TCP, veri gönderirken bir zamanlayıcı ayarlar.Zamanlayıcı aştığında ve ACK alınmadığında, veri yeniden iletilir. Bu nedenle, zaman aşımı ve yeniden iletimin anahtarı, zamanlayıcı aralığının ve yeniden iletim frekansının nasıl belirleneceğidir.
Geleneksel Unix uygulamasında, zamanlayıcının aralığı verilerin (yani, RTT) gidiş dönüş süresine bağlıdır ve yeniden iletim zaman aşımı aralığı (yani, RTO) RTT'ye göre hesaplanır. Ağ yönlendirmesindeki, trafikteki vb. Değişiklikler nedeniyle RTT sık sık değişir ve RTT ölçümü de son derece karmaşıktır (yumuşatma algoritması, Karn algoritması, Jabcson algoritması vb.). "TCP / IP Ayrıntılı Açıklamada", yeniden iletim mekanizmasının gerçek ölçümü Şekil 3'te gösterilmektedir. Yeniden iletim aralığı 1, 3, 6, 12, 24, 48 ve 64 saniyeden fazla olacak şekilde yuvarlanır. Bu çarpma ilişkisine "üstel geri çekilme" denir.
Şekil 3 Gerçek ölçümün yeniden iletim mekanizması
Mobil terminalde, RTO'nun tasarımı ve yeniden deneme frekansı, geleneksel uygulama ile tutarlı mı? Bunun üzerine fiili ölçüm yaptık ve ölçülen veriler aşağıdaki gibidir:
Şekil 4, OPPO cep telefonu TCP zaman aşımının yeniden iletim aralığını sırayla göstermektedir:
Şekil 4 OPPO cep telefonu TCP zaman aşımı yeniden iletim aralığı
SamSung'daki TCP zaman aşımı yeniden iletim aralığı, Şekil 5'te gösterildiği gibi aşağıdaki gibidir.
Şekil 5 Samsung cep telefonu TCP zaman aşımı yeniden iletim aralığı
Birçok gerçek testten sonra, RTO'nun değeri, farklı üreticilerin Android sistemlerinin uygulanmasına bağlı olarak farklı ayarlanabilse de, temelde "üstel geri çekilme" ilkesine uygun olduklarını görebiliriz.
Daha sonra, iOS sistemindeki TCP RTO'nun deneysel verilerine bakın. Şekil 6 deneydeki ilk verileri göstermektedir.
Şekil 6 iOS sistemi için TCP RTO'nun ilk deneysel verileri
Yukarıdaki veriler, üstel geri çekilme ile tam olarak uyumlu görünmüyor. İlk yeniden deneme daha sık olacak ve RTO sonunda 26s'lik küçük bir değerde sabitlenecek.
İkinci testten sonra, verilerde Şekil 7'de gösterildiği gibi yeni değişiklikler bulundu.
Şekil 7 iOS sisteminin TCP RTO'sunun ikinci deneysel verileri
RTO'nun son değeri 26 saniyeden 24 saniyeye düşürüldü.Sonuçta birçok testten sonra iOS'ta TCP RTO yasası bulunamadı, ancak iOS'un daha agresif bir zaman aşımı ayarı benimsediği ve yeniden denemede daha aktif olduğu görülebiliyor.
Okuma ve yazma zaman aşımının hedefi
Yukarıdaki araştırma ve deney sayesinde, TCP / IP'de protokol yığınının zaman aşımını ve yeniden iletimi kontrol etmemize yardımcı olduğunu bulabiliriz. Ve mobil ağların kararsız özelliklerine uyum sağlamak için daha aktif bir strateji kullanarak Android ve iOS'un mobil işletim sistemlerinde optimize edildi.
Bu, uygulama katmanımızın artık zaman aşımı ve yeniden iletim kontrolüne ihtiyaç duymadığı anlamına mı geliyor? aslında değil. Bağlantı katmanında HARQ, düğümler arasında her veri çerçevesinin güvenilir iletimini sağlar, taşıma katmanında, TCP zaman aşımı yeniden iletim mekanizması uçtan uca her TCP veri paketinin güvenilir iletimini sağlar; WeChat'in bulunduğu uygulama katmanında, yine de "isteklerin" ayrıntı düzeyiyle güvenilir iletim sağlamamız gerekiyor.
Öyleyse, uygulama katmanının zaman aşımı yeniden iletim mekanizması ne tür bir hizmet sağlamalıdır?
İlk olarak, uygulama katmanı yeniden iletimine bir göz atalım. Uygulama katmanında, yeniden iletim yöntemi şu şekildedir: mevcut bağlantıyı kesmek, bağlantıyı yeniden kurmak ve isteği göndermek. Bu yeniden iletim yöntemi nasıl bir etki sağlayabilir? TCP katmanının zaman aşımı yeniden iletim mekanizmasına bakıldığında, bir zaman aşımı yeniden iletimi gerçekleştiğinde, yeniden iletim aralığının bir "üstel geri çekilme" kuralıyla keskin bir şekilde arttığı görülebilir. Android sisteminde, TCP 16 dakikaya kadar arızayı onaylamaz; iOS sisteminde TCP, 1 ile bir buçuk ile 3 buçuk dakika arasında arızayı onaylamaz. Bu değerler, çoğu uygulamada "kullanıcı deneyimi" için kabul edilemez. Bu nedenle, uygulama katmanının zaman aşımı yeniden iletiminin hedefi öncelikle şu olmalıdır:
-
Kabul edilebilir kullanıcı deneyimi aralığında, başarı oranını olabildiğince artırın
Başarı oranını olabildiğince artırmak, sınırlı bir süre içinde olabildiğince çok yeniden deneme yapmak anlamına mı geliyor? aslında değil. Ağ, yüksek gecikmeli / düşük hızlı bir ağ olduğunda, daha hızlı bir uygulama katmanı yeniden iletimi, "isteğin" bu ağda başarılı olmasının zor olmasına neden olacaktır. Bu nedenle, uygulama katmanı zaman aşımı yeniden iletiminin ikinci hedefi:
-
Zayıf ağlar altında kullanılabilirliği sağlayın
TCP bağlantısı, sabit bir fiziksel hat ile yapılan bir bağlantıdır.Bağlanan hat, ara cihazda büyük dalgalanmalar veya şiddetli tıkanıklık varsa, istek sınırlı bir süre içinde başarılı olsa bile, düşük performans ve yavaş yanıt getirecektir. kullanıcı deneyimi. Uygulama katmanının yeniden bağlanmasıyla, beklenen üç hedef şunlardır:
-
Ağ hassasiyeti ile yeni bağlantıları hızla keşfedin
Uygulama katmanı zaman aşımı yeniden iletiminin aşağıdaki etkileri getirebileceği sonucuna vardık:
-
Geçersiz bekleme süresini azaltın ve yeniden deneme sayısını artırın: TCP katmanının yeniden iletim aralığı çok büyük olduğunda, bağlantıyı kesin ve yeniden bağlanın, böylece TCP katmanı pozitif bir yeniden bağlanma aralığını korur ve başarı oranını artırır;
-
Bağlantının değiştirilmesi: Bağlantıda büyük dalgalanmalar veya ciddi tıkanıklık olduğunda, bağlantı değiştirilerek daha iyi performans elde edilebilir (genellikle IPPort bu şekilde değiştirilecektir).
WeChat okuma ve yazma zaman aşımı
Şema 1: Toplam okuma ve yazma zaman aşımı
TCP katmanının zaman aşımı yeniden iletim tasarımında, zaman aşımı aralığı, TCP paketlerinin gidiş-dönüş süresi olan RTT'ye bağlıdır. Aynı şekilde WeChat'in erken tasarımında, uygulama katmanındaki "isteklerin" gidiş dönüş süresini analiz ettik ve RTT'sini şu şekilde ayrıştırdık:
-
Zamana benzer TCP paket iletim süresi göndermeyi isteyin;
-
Zaman alıcı yanıt sinyal alımı analog ACK iletimi zaman alıcı;
-
Sunucu işleme talep süresi - TCP alıcı uç, veri paketlerini nispeten sabit bir zamanda alır ve işler, WeChat sunucusu ise farklı sinyalleme hizmetleri nedeniyle mantık işleme süresinde önemli bir farka sahiptir, bu nedenle karşılaştırılamaz;
-
Bekleme süresi, uygulamadaki eşzamanlı isteklerin sayısından etkilenir.
Bu nedenle, Şekil 8'de gösterildiği gibi uygulama katmanının toplam okuma ve yazma zaman aşımını öneriyoruz. Minimum ağ hızı, farklı ağlara göre farklı değerler alır.
Şekil 8 Uygulama katmanında toplam okuma ve yazma zaman aşımı
Şema 2: Adım adım okuma ve yazma zaman aşımı
Gerçek kullanım sürecinde, bunun yalnızca kullanılabilir bir çözüm olduğunu, yüksek performanslı bir çözüm olmadığını gördük: zaman aşımı süresi ayarı, eksiksiz bir tek sinyal etkileşim süresi tahminini tamamlamak için zayıf bir ağ kullanır. Bu, zaman aşımı süresini çok uzatır ve ağ dalgalandığında veya tıkandığında, sorunu hassas bir şekilde tespit edip tekrar denemek imkansızdır. Daha fazla analiz, sunucunun dönüş paketinin boyutunu tahmin edemeyeceğimizi gösteriyor, bu nedenle tahmin için en büyük dönüş paketi kullanılıyor (şu anda WeChat'teki en büyük iade paketi 128 KB'ye ulaşabilir). Bununla birlikte, gönderilen veri, TCP iletiminde MSS'den daha büyük olduğunda, veriler bölümler halinde iletilecek ve bölümler alıcı uca ulaştıktan sonra yeniden birleştirilecektir. Sunucunun yanıt paketi büyükse, istemci birden çok veri bölümü alabilir. Bu nedenle, Şekil 9'da gösterildiği gibi, birinci veri segmentinin varış zamanını tahmin edebilir ve ilk paket zaman aşımını önerebiliriz.
Şekil 9 İlk paket zaman aşımı hesaplaması
İlk paket zaman aşımı sorunu bulma döngüsünü kısaltır, ancak ilk veri segmenti zamanında gelirse ve sonraki veri paketleri kaybolursa, sorunu keşfetmek için yine de tüm okuma ve yazma zaman aşımını beklememiz gerektiğini gördük. Bu amaçla, iki veri segmenti arasındaki zaman aşımı süresi olan bir paket zaman aşımı getirdik. Paket zaman aşımı ilk paket zaman aşımından sonra olduğu için, bu aşama sunucunun isteği aldığını ve talebin işlenmesini tamamladığını onaylamıştır, bu nedenle bekleme süresini, istek iletim süresini, sunucu işlem süresini hesaplamaya gerek yoktur ve yalnızca ağ RTT'sini tahmin etmeye gerek yoktur. .
Mevcut çözümde, farklı ağlar altındaki sabit RTT'ler kullanılmaktadır. "İlk paket alındı" bağlamından dolayı, paketin zaman aşımı aralığı büyük ölçüde kısaltılır, böylece ani ağ dalgalanmalarına, tıkanıklığa ve ani arızalara karşı duyarlılık artar ve uygulamaların daha yüksek performans elde etmesine olanak sağlanır.
Şema 3: Dinamik okuma ve yazma zaman aşımı
Yukarıdaki şemada, toplam okuma ve yazma zaman aşımı ve ilk paket zaman aşımı için bazı tahminler kullanılır ve bu iki zaman aşımını daha büyük değerler yapar. Gerçek zamanlı dinamik ağ hızı vb. Elde edebilirsek, Şekil 10'da gösterildiği gibi daha iyi bir zaman aşımı mekanizması elde edebiliriz.
Şekil 10 Gerçek zamanlı dinamik ağ hızı altında zaman aşımı tahmini
Ancak ideal dolu, gerçek acımasız:
-
Dinamik ağ hızının araç yöntemleriyle ölçülmesi gerekir, gerçek zamanlı gereksinimler yüksektir ve ağ dalgalanmalarının etkisi dikkate alınmalıdır;
-
Sunucu dinamiği için zaman alıcı, sunucunun zaman alıcı farklı hizmet sinyalleme işlemlerini yayınlamasını gerektirir;
-
Gerçek paket boyutu yalnızca sunucu tarafından bildirilebilir.
Yukarıdaki üç yaklaşım, hem istemci hem de sunucu için büyük trafik ve performans tüketir, bu nedenle bu değişkenleri dinamikleştirmek mümkün görünmemektedir.
Bu nedenle, dinamik optimizasyonu farklı bir perspektiften düşünmemiz gerekiyor Cep telefonlarının ağ koşulları kabaca yüksek kaliteli, normal ve zayıf olarak sınıflandırılabilir.Üç ağ koşulu için farklı derecelere ayarlamak da bir dinamik optimizasyon aracıdır. Analiz için yüksek kaliteli ağ koşullarını buradan seçin:
-
Ağın iyi durumda olduğu nasıl belirlenir? Şebeke hızı hızlı ve kararlıdır.Ağ modülünün karşılığı, sinyal gönderme ve alımını kısa sürede tamamlayabilmesi ve sinyal gönderme ve alımını kısa sürede uzun süre tamamlayabilmesidir.
-
Ağ dalgalanmaları olsa bile, yakında düzelmesi beklenebilir.
Şekil 11 Yüksek kaliteli ağ koşullarının optimizasyonu
Ağ koşullarının iyi bir analizine dayanarak, bu tür optimizasyonları yapabiliriz (Şekil 11'de gösterildiği gibi):
-
İstemci ağ ortamı iki duruma bölünmüştür: Mükemmel ve Değerlendiriliyor;
-
Hızlı ve kararlı ağ hızı koşul 1, sinyal hatası veya ağ türü anahtarlama koşul 2'dir.
Exc durumuna girdikten sonra, sinyal gönderme ve alma beklentisini kısaltır, yani ilk paketin zaman aşımı süresini kısaltırız.Bunun nedeni, kullanıcının ağının iyi durumda olduğuna inanmamızdır.Daha kısa bir zaman aşımı süresi ayarlanabilir ve ağ dalgalanmalarıyla karşılaşıldığında beklenir. Hızlı bir şekilde iyileşebilir, böylece mümkün olan en kısa sürede zaman aşımına uğrayabilir ve tekrar deneyebilir ve böylece kullanıcı deneyimini iyileştirebilir.
sonuç olarak
TCP / IP protokol yığınındaki bağlantı katmanı ve taşıma katmanı, zaman aşımı yeniden iletimi sağlasa da, iletimin güvenilirliği garanti edilir. Ancak, uygulama katmanının farklı güvenilirlik gereksinimleri vardır ve bu, uygulamanın yüksek performans ve yüksek kullanılabilirliğini sağlamak için ek bir uygulama katmanı zaman aşımı yeniden iletim mekanizması gerektirir. Yazar, kendi deneyimlerime dayanarak, uygulama katmanı zaman aşımı yeniden iletiminin tasarım hedefi şu şekilde özetliyor:
-
Kabul edilebilir kullanıcı deneyimi aralığında, başarı oranını olabildiğince artırın;
-
Zayıf ağlar altında kullanılabilirliği sağlayın;
-
Ağ hassasiyeti ile yeni bağlantılar hızlı bir şekilde bulunabilir.
Bu hedeflere uygun olarak, mars STN'nin zaman aşımı yeniden iletim mekanizması, toplam okuma ve yazma zaman aşımı, ilk paket zaman aşımı, paket zaman aşımı ve dinamik zaman aşımı dahil olmak üzere çoklu çözümlerin bir kombinasyonu kullanılarak kullanımda sürekli olarak geliştirilir. Öyle bile olsa, STN'nin zaman aşımı yeniden iletim mekanizması, küçük veri iletimi için nispeten uygun olan ve ileri-geri iletişim modu ile sınırlı olan bir sinyalleşme kanalı gibi birçok eksikliğe ve sınırlamaya sahiptir. mars STN yeni sorunları keşfetmeye ve gelişmeye devam edecek ve tüm gelişmeler WeChat'in büyük kullanıcıları arasında doğrulanacaktır. Aynı zamanda, daha fazla ve daha geniş deneyim alışverişi, sorunlar hakkında geri bildirim, yeni fikirlerin çakışmaları vb.
Yazar hakkında: Cao Shaokun, WeChat mobil müşteri geliştirme mühendisidir. 2014 yılında Tencent'e katılmıştır ve mobil Q çapraz platform mobil hizmet çerçevesi MSF'nin geliştirilmesi ve optimizasyonu ile ilgilenmektedir. 2015 yılında, ağ bileşenlerinin geliştirilmesi ve bakımına katılmak için WeChat terminali temel geliştirme grubuna transfer olmuştur.
Teknolojik yol, ortak ilerleme, katkıda bulunmaya hoş geldiniz, taslaklar gönderin ve makaledeki hataları düzeltin, lütfen mobile@csdn.net adresine bir e-posta gönderin
Mobil geliştirmeyle ilgili en son bilgiler ve teknolojiler için lütfen mobilehub genel WeChat hesabını (ID: mobilehub) takip edin.
