İnterneti hızlandıran protokol, QUIC'in Tencent'teki uygulaması ve performans optimizasyonu
Yazar Luo Cheng
Düzenle Xiaozhi
Bu makale esas olarak QUIC protokolünün Tencent ve Tencent Cloud'daki uygulama ve performans optimizasyonunu tanıtmaktadır. QUIC protokolünün arka planını ve temel özelliklerini anlamak için bugün iki tweet okuyabilirsiniz.
Önüne yaz
Uygulamanız varsa, herhangi bir değişiklik yapmadan erişim hızını% 15'ten fazla artırabilirsiniz. Özellikle ağ zayıf olduğunda erişim hızı% 20'den fazla artırılabilir.
Uygulamanız sık sık 4G ve WIFI ağları arasında değiştiriliyorsa bağlantısı kesilmez, yeniden bağlanması gerekmez ve kullanıcıların hiçbir algısı olmaz. Uygulamanız hem TLS güvenliğini hem de çoklama gücünü gerektiriyorsa.
HTTP2'nin yeni nesil İnternet protokolü olduğunu yeni duyduysanız, TLS1.3'ün devrim niteliğinde ve kilometre taşı olan bir protokol olduğunu fark ettiyseniz, ancak bu iki protokol başka bir yeni protokolden etkilendi. meydan okuma.
Ortaya çıkan bu protokole "hızlı" denirse, yeni nesil İnternet aktarım protokolü olarak standardize edilmektedir.
Bu anlaşmayı anlamak için biraz zaman harcamak ister misiniz? Bu anlaşmayı araştırmak için enerji harcamak istiyor musunuz? İşletmeyi bu sözleşmeyi kullanmaya tamamen zorlamaya istekli misiniz?
Tencent'te QUIC uygulaması
Tencent Güvenli Bulut Ağ Geçidi (STGW) ve Tencent Bulut Yük Dengesi (Bulut Yük Dengesi), Temmuz 2017'de sunucuda Quic protokolünü zaten desteklemiştir. Mühendislik uygulamasında da birçok optimizasyon noktası vardır ve bunlar üretim ortamında da gerçekleştirilmiştir. Daha iyi bir etki. Mevcut açık kaynaklı çözümlerle karşılaştırıldığında, STGW uygulamasının aşağıdaki avantajları vardır:
yüksek performans.
-
Nginx'i tamamen eşzamansız olay güdümlü çerçeveyi yeniden kullanın.
-
Özel anahtar proxy hesaplama kümesi imza hesaplamasını hızlandırır.
-
Küresel önbellek hızlanır ve hesaplama miktarını azaltırken erişim hızını artırır.
güçlü fonksiyonlar.
-
Nginx'in mevcut tüm modül talimatlarını ve zengin üçüncü taraf modüllerini destekleyin.
-
Üçüncü taraf işlevlerini çok esnek bir şekilde eklemek için Nginx modül çerçevesini yeniden kullanın.
istikrar.
-
Kod tamamen özerk ve kontrol edilebilir.
-
Tencent'in yüz milyonlarca eşzamanlı trafiğinin testinden geçiyor.
Aynı zamanda, Qzone, WEB oyun sayfası ve Tencent Cloud CLB dahil olmak üzere Tencent'in birçok işletmesinde gri tonlamalı QUIC protokolünü de destekliyoruz. Ayrıntılı gelir verileri için lütfen Bölüm 6'ya bakın.
QUIC çevrimdışı test planı
QUIC protokolünü kullanmaya karar vermeden önce, QUIC protokolünün özellikleri ve performansı hakkında kapsamlı bir test yapmamız gerekir Nasıl test edilir? İşte test planı hakkında kısa bir konuşma.
Özel talimat gerektiren test 2016 sonunda gerçekleştirildi. Şu anda tüm alan adlarının süresi dolmuştur ve başka test yapılamaz.
Sayfa yapısı
Httparchive.org'daki istatistiklere göre, aşağıdaki sayfalar oluşturulmuştur:
test ortamı
Cep telefonu: Huawei mate9 Kullanıcı Aracısı: MHA-AL00 Build / HUAWEIMHA-AL00) AppleWebKit / 537.36 (KHTML, Gecko gibi) Chrome / 55.0.2883.91 Mobile Safari / 537.36 İşletim sistemi: Android 7.0 Server QUIC programı: caddy 0.9.4Web sitesi ve müşteri dağılımı aşağıdaki gibidir:
QUIC test çerçevesi
-
, müşteri tarafından başlatılan bir kullanıcı talebini belirtir.
-
html'den gönderilen kaynak talebini belirtir.
-
bir veri raporu talebini belirtir.
Test süreci
Tüm test süreci python komut dosyaları ve adb kabuk araçlarıyla otomatikleştirilir. Mobil terminal ile PC terminalinin kontrol süreci farklıdır. Kısa tanıtımlar aşağıdaki gibidir:
Mobil test süreci
Hazırlıklar:
Telefonun usb hata ayıklama seçeneğini açın.
PC'ye adb yükleyin.
Cihazın adb devices komutu ile bulunabilmesini sağlamak için cep telefonunu PC'ye USB üzerinden bağlayın.
Önbellek denetimini yapılandırın: önbellek yok, sunucuda saklama yok. İstemci önbelleğe almayı devre dışı bırakın.
Otomatik test süreci aşağıdaki gibidir:
Android Chrome'u başlatın.
Https://www.helloworlds.cc adresini ziyaret edin.
Sayfa yüklendikten sonra, yükleme olayı tetiklenecek ve her zaman noktası raporlanacaktır.
PC tarafı işlem
PC tarafı adb'ye ihtiyaç duymaz, sadece kromu kontrol etmek için webbrowser modülünü kullanın.
Test sonucu
Şirketin intranetinin dengesiz WIFI ortamı nedeniyle, birkaç test, verilerin büyük ölçüde dalgalandığını ve 4G ortamı altındaki verilerin daha kararlı ve güvenilir olduğunu, bu nedenle ana sonuçların 4G ağı altındaki verilere atıfta bulunduğunu göstermiştir.
QUIC'in avantajları çok açıktır. Daha az öğe (12 öğe) olsa bile, HTTP'ye göre% 9, HTTP2'ye göre% 42 ve HTTPS'ye kıyasla% 52 artabilir.
Daha fazla sayfa öğesi ile, QUIC'in avantajları daha da belirgindir, HTTP'den% 36 daha yüksek, HTTP2'den% 47 daha yüksek ve HTTPS'den% 64 daha yüksektir.
QUIC performans optimizasyonu
QUIC'in özellikleri nispeten gelişmiş olmasına rağmen, uygulanması çok karmaşıktır ve mühendislik uygulamasında optimizasyon için çok yer vardır. Örneğin, 0RTT başarı oranının nasıl iyileştirileceği, sunucunun CPU tüketiminin nasıl azaltılacağı ve bağlantı geçişi ve dinamik tıkanıklık kontrol algoritmalarının nasıl uygulanacağı.
0RTT başarı oranını artırın
Güvenli taşıma katmanı 0RTT'ye ulaşabilse de, avantajları çok açıktır. Ancak sorun şu ki, her bağlantı 0RTT'ye ulaşamaz. İstemcimiz ve sunucumuz için 0RTT'nin başarı oranını nasıl en üst düzeye çıkarabiliriz?
0RTT'nin gerçekleştirebileceği anahtar ServerConfig'dir. TLS oturumu devam ettirmenin anahtarının oturum kimliği veya oturum bileti olması gibi.
ServerConfig sunucuya ulaştıktan sonra, yerel belleği ServerConfig ID'ye göre ararız.Eğer bulursak verilerin güvenilir olduğunu düşünür ve 0RTT anlaşmasını tamamlayabiliriz.
Ancak iki sorun olacak:
Kimlik verileri işlemler arasında paylaşılamaz.
Birden çok sunucu arasında kimlik verileri paylaşılamaz.
Sorun açıklığa kavuşturulursa, mühendislik seviyesinin çok işlemli paylaşım ve dağıtılmış çok kümeli kimlik paylaşımını gerçekleştirmesi gerekir.
SeverConfig Önbellek kümesi
Stgw, ServerConfig Kimliği ve içeriği ürettiğinde, bu genel Önbellek kümesinde saklanacaktır. Kullanıcı el sıkışma isteği herhangi bir STGW makinesine düşer ve ilgili içerik 0RTT el sıkışmasını gerçekleştirmek için küresel Önbellek kümesinden bulunabilir.
Şifreleme performansının optimizasyonu
İmza hesaplama
QUIC'in 0RTT'ye ulaşmasının öncülü, ServerConfig içeriğinin imzalanması ve doğrulanmasında herhangi bir sorun olmamasıdır. ServerConfig, RSA imzası veya ECDSA imzası içerdiğinden, CPU kaynaklarımızı çok tüketir. Önceki test verilerine göre, RSA özel anahtar imza hesaplaması performansı% 90 oranında düşürecektir.
Nasıl optimize edilir? RSA veya ECDSA zaman uyumsuz proxy hesaplamasını kullanın. Ana fikir aynı zamanda üç noktadır:
Algoritma ayrımı. Bu işlemin yerel CPU kaynaklarını işgal etmesini önlemek için özel anahtar hesaplama bölümünü çıkarın.
Eşzamansız yürütme. Algoritma çıkarma ve yürütme eşzamansızdır ve üst katman hizmetinin bu hesaplama işleminin eşzamanlı olarak tamamlanmasını beklemesi gerekmez.
Paralel Hesaplama. Özel anahtar hesaplamasını tamamlamak için özel donanımla donatılmış özel bir anahtar hesaplama kümesi kullanıyoruz.
Mimari aşağıdaki şekilde gösterilmektedir:
İmza vekil hesaplaması
Simetrik şifrelemenin optimizasyonu
Asimetrik anahtar değişim algoritması ile karşılaştırıldığında, simetrik şifreleme algoritmasının performansı çok iyidir (1 ila 2 büyüklük sırası), ancak uygulama katmanı iletiminin içeriği büyükse, özellikle mobil terminal CPU hesaplama gücü zayıfsa, simetrik şifreleme algoritması Performans üzerindeki etkisi de göz ardı edilemez.
Tablo 1 Yaygın olarak kullanılan simetrik şifreleme algoritmalarının performans karşılaştırması
Nasıl optimize edilir? Açıkçası, asenkron proxy'yi geçmek imkansızdır. Sebebi:
Kullanıcı erişim hızını büyük ölçüde azaltacaktır. Uygulama katmanının her baytının simetrik olarak şifrelenmesi ve şifresinin çözülmesi gerektiğinden, eşzamansız uygulamanın kullanılması şifreleme ve şifre çözmenin gerçek zamanlı performansını ciddi şekilde azaltacaktır.
Herhangi bir senkronizasyon optimizasyon yöntemi var mı? Sahip olmak. SSL donanım hızlandırma kartına benzer şekilde, intel, AES algoritması için donanım hızlandırma uygular ve bunu CPU komutlarına entegre eder.
AES-NI talimatları
AES-NI, intel tarafından sunulan AES simetrik şifreleme algoritması için optimize edilmiş bir dizi talimattır ve hesaplama hızı, donanım hesaplamasıyla iyileştirilir.
AES-NI'nin performansı nasıl test edilir?
Ortam değişkenleri aracılığıyla
aes-ni: OPENSSL_ia32cap = "~ 0x200000200000000" openssl hızı -elapsed -evp aes-128-gcm veya crypto / evp / e_aes.c # tanımla AESNI_CAPABLE (OPENSSL_ia32cap_P (1 < < (57-32))) Ayarları yapın.
Aesni'nin performans artışı 4,3 W'tan 5,1 W'a yaklaşık% 20'dir.
AES simetrik şifreleme ve şifre çözme için openssl API'yi tek başına kullanmanız gerekirse, AES-NI komutunun varsayılan olarak etkinleştirilmesi için aes evp API'sini kullanmak en iyisidir.
chacha20-poli1305
chacha20-poly1305, Dan Bernstein tarafından icat edilen ve Google tarafından başlatılan kimlik doğrulamalı simetrik bir şifreleme algoritmasıdır. Bunlar arasında, chacha20 simetrik şifreleme algoritmasına, poly1305 ise kimlik doğrulama algoritmasına atıfta bulunur. Bu algoritma, ARM yongaları gibi AES donanım hızlandırması olmayan mobil platformların tamamlayıcısıdır.
Google tarafından yayınlanan verilere göre, chacha20-poly1305, şifreleme ve şifre çözme performansını% 30'dan fazla artırarak mobil terminal güç tüketiminden tasarruf sağlayabilir. Elbette, cep telefonu AES-NI komutlarını destekliyorsa, chacha20'nin hiçbir avantajı yoktur.
Openssl resmi olarak 1.1.0 sürümünde chacha20-poly1305'i destekler.
Bağlantı Geçişinin Uygulanması
STGW sunucusu bunu nasıl uygular? Aynı kimliğe sahip QUIC isteklerinin aynı CLB7 katmanlı kümeye düşmesini sağlamak için CLB dört katmanlı yönlendirme düzeyinde kimliğe dayalı karma oluşturma için bir yük dengeleme algoritması uyguladık. CLB7'de, kimliğe dayalı olarak işlemeye öncelik vereceğiz.
Simgeler aşağıdaki gibidir:
QUIC bağlantı geçişi
Yukarıdaki şekilde gösterildiği gibi, müşteri hizmete erişmek için başlangıçta 4G mobil ağı kullandı, kaynak IP'nin IP1 olduğu varsayılır ve tüm erişim süreci mavi çizgilerle işaretlenir.
Kullanıcı WIFI ağına girdiğinde, kaynak IP'si IP1'den IP2'ye değişir ve tüm erişim süreci yeşil bir çizgi ile işaretlenir. Bağlı CLB4 değişebileceğinden, ancak CLB kümesinin tamamı QUIC Bağlantı Kimliği planlamasını tek tip olarak kullandığından, QUIC bağlantı kimliği değişmediği sürece, istek aynı CLB7 katman makinesine programlanabilir.
Aynı CLB7, aynı Akış ve Bağlantı işleme içeriğini kaydeder ve isteği aynı hizmet RS makinesine göndermeye devam edebilir.
Tüm ağ ve IP anahtarlama süreci boyunca, kullanıcılar ve hizmetler için bir algı oluşmaz.
Dinamik akış kontrolü ve tıkanıklık kontrolü
STGW, bağlantı ve akış seviyelerinde farklı sayıda pencere ayarlar.
En önemli şey, akış kontrolü yoluyla iletim hızını sınırlayabilmemiz ve yetersiz bellek veya yukarı akış işleme performansı sorunları olduğunda hizmet kullanılabilirliğini sağlayabilmemizdir.
Performans istatistikleri
STGW, QUIC'in çevrimiçi kullanımı üzerine, 0RTT el sıkışma başarı oranı, el sıkışma süresi, şifre paketi kullanım dağıtımı, QUIC protokol sürümü, eşzamanlı akış sayısı vb. Dahil olmak üzere birçok değişken istatistik ve analiz gerçekleştirmiştir.
Bu istatistiksel değişkenler, protokol optimizasyonumuz için daha rafine veri desteği sağlayabilir.
QUIC çevrimiçi gri tonlamalı veriler
QUIC şu anda STGW üzerinde çalışıyor. Birkaç önemli Tencent alanında (QQ sarı elmas sayfası ve oyun sayfası dahil) gri tonlamalı deneyler yaptık.
Qzone QUIC sayfası
Yukarıdaki şekilde gösterildiği gibi, şekildeki kırmızı okla gösterilen yeşil logo, sayfanın QUIC protokolünü kullandığını gösterir.
Gri tonlama denemesinin etkisi de çok açıktır. Hızlı isteğin ilk bayt süresi (rspStart) http2'ye kıyasla ortalama 326 ms azaltılır ve performans yaklaşık% 25 oranında iyileştirilir; bu, daha önce gönderilebilen 0RTT ve 1RTT el sıkışma süresinden kaynaklanmaktadır. istek.
Ek olarak, hızlı istek yayınlanma süresi (reqStart), h2'ye kıyasla ortalama 250 ms kısalır; ayrıca, quic'in sayfa yüklemesini isteme süresi (loadEnd) ortalama 2 saniye kısalır.Tüm sayfanın karmaşıklığı nedeniyle, diğer birçok kaynağın yüklenmesi engellenerek genel yükleme tamamlama süresinin karşılaştırılmasıyla sonuçlanır Uzunluk yaklaşık 9 saniyedir ve performans iyileştirme oranı yaklaşık% 22'dir.
Yukarıdaki verilerde sadece referans olması için iki sorun vardır:
Sayfalarımızın tamamı QUIC protokolüne dönüştürülmediğinden, performans verileri daha da iyileştirilmelidir.
Her işletmenin sayfa bileşimi farklıdır ve iyileştirilmiş performans verileri de farklı olacaktır.
CLB-QUIC-DEMO
Yukarıda belirtilen QUIC uygulamaları ve optimizasyonlarının tümü sunucuya yöneliktir. Geliştiricilerin istemcide QUIC'in kullanımını daha iyi anlamalarını kolaylaştırmak için, yalnızca referans olarak Android istemcisinin bir DEMO'sunu sunuyoruz.
DEMO, github'da açık kaynaklı olup, adres aşağıdaki gibidir:
https://github.com/tencentyun/clb-quic-demo
DEMO'nun temel amacı iki yönlüdür:
İstemci tarafında QUIC'in kullanımını kısaca açıklayın.
Basitçe HTTP2 ve QUIC arasındaki performans farkını karşılaştırın.
Bir kullanıcı QUIC protokolünü kullanmak isterse, istemci bazı değişiklikler yapabilir ve sunucu doğrudan Tencent Cloud CLB yük dengeleyiciyi kullanabilir.
Daha önce belirtildiği gibi, CLB protokol hesaplama performansı, erişim hızı ve güvenlik performansı açısından birçok optimizasyon yapmıştır.
sonuç olarak
QUIC protokolü çok karmaşıktır çünkü çok fazla şey yapar:
İletim güvenilirliği elde etmek için, temel olarak sıra numarası, yeniden iletim, tıkanıklık kontrolü, akış kontrolü vb. Dahil olmak üzere tüm TCP protokolünün işlevlerini uygular ve geliştirir.
İletim güvenliğini sağlamak için, sertifika sıkıştırma, el sıkışma mesajları, ORTT vb. Dahil olmak üzere TLS protokolünü tamamen yeniden yapılandırmıştır. TLS1.3 protokolü gelecekte benimsenebilse de, aslında TLS1.3'ün geliştirilmesini destekleyen QUIC'tir.
İletimin eşzamanlılığını gerçekleştirmek için, çoklama, akış kontrolü vb. Dahil olmak üzere HTTP2'nin özelliklerinin çoğunu gerçekleştirmiştir.
Çok karmaşık olmasına rağmen, ortaya çıkan bir protokol olarak QUIC, çok güçlü bir canlılık ve geniş beklentiler göstermiştir.
Şu anda, Google'ın yurtiçinde ve yurtdışında geniş ölçekte benimsemesine ek olarak, birkaç başka İnternet şirketi onu kullanıyor. STGW, Tencent'in güvenli bulut ağ geçidi olarak, endüstrinin gelişmiş standart protokolleri için destek ve optimizasyon sağlama sorumluluğuna ve yükümlülüğüne sahibiz. Aynı zamanda Tencent Cloud, QUIC protokolünü destekleyen ilk yerel bulut satıcısıdır, çünkü bu protokol, müşterinin erişim hızını ve son kullanıcı deneyimini etkili bir şekilde iyileştirebilir.
Quic protokolünün sadece sunucu tarafında desteğini gerçekleştirip QUIC protokolünün performansını optimize etmekle kalmadık, aynı zamanda kendi deneyimlerimizin bir kısmını paylaşarak ve daha güvenli ve daha hızlı bir İnternet dünyası inşa ederek QUIC protokolünün gelişimini teşvik etmeyi umuyoruz.
Let's'Quic, Web'i Daha Hızlı Hale Getirin.
yazar hakkındaLuo Cheng, Tencent'te kıdemli Ar-Ge mühendisi. Şu anda, esas olarak Tencent stgw (Tencent Secure Cloud Gateway) ile ilgili çalışmalardan ve Tencent dahili ve Tencent genel bulutunun genel tanıtımından, hibrit bulutun yedi katmanlı yük dengelemesinden ve tam site HTTPS erişiminden sorumludur. 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.
13-14 Ocak 2018'de AICon, Pekin'de görkemli bir şekilde açılacak. InfoQ China ekibi, herkes için makine öğrenimi alanındaki en son gelişmeleri sıraladı ve Google, Amazon, Snap, Etsy, BAT, 360, Xiaomi, Jingdong'dan kişileri davet etti 40'tan fazla şirket AI teknik liderinin pratik deneyimlerini paylaşmak için gelmesini bekleyin. 2018'de en çok beklenen yapay zeka ve makine öğrenimi teknolojisi şöleni ile tanışın, arabaya binin!
Konferans için 10 günlük geri sayım şu anda devam ediyor ve " Orijinali okuyun "Daha fazla bilgi edinin! Herhangi bir sorunuz varsa, lütfen bilet yöneticisi Doubao ile iletişime geçin, Tel: 18514549229, WeChat: 18514549229, QQ: 209463896
