Popüler bilim: QUIC protokol ilke analizi
Yazar Luo Cheng
Düzenle Xiaozhi
Bu makale esas olarak QUIC protokolünün arka planını ve temel özelliklerini tanıtmaktadır.
Ö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 HTTP2 ç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 standart hale getirilmektedir.
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 kullanmak için tam olarak tanıtmaya istekli misiniz?
QUIC'e genel bakış
Quic'in tam adı hızlı udp internet bağlantısıdır, "Hızlı UDP İnternet Bağlantısı" (kısaca "Hızlı" İngilizce'ye benzer), birden çok eşzamanlı iletim için udp kullanmak üzere Google tarafından önerilen bir protokoldür.
Quic, yaygın olarak kullanılan http2 + tcp + tls protokolüne göre aşağıdaki avantajlara sahiptir:
TCP üç yönlü el sıkışma ve TLS el sıkışma süresini azaltın.
Geliştirilmiş tıkanıklık kontrolü.
Hat başı tarafından engellenen çoğullamadan kaçının.
Bağlantı geçişi.
İleri artıklık hatası düzeltmesi.
Neden QUIC'e ihtiyacınız var
1990'larda İnternetin başlangıcından günümüze, çoğu İnternet trafiği aktarımı yalnızca birkaç ağ protokolü kullanır. Yönlendirme için IPv4'ü, bağlantı düzeyinde akış kontrolü için TCP'yi, iletim güvenliği için SSL / TLS protokolünü, alan adı çözümlemesi için DNS'yi ve uygulama veri aktarımı için HTTP'yi kullanın.
Geçtiğimiz 30 yılda, bu anlaşmaların gelişimi çok yavaştı. TCP esas olarak tıkanıklık kontrol algoritmasının iyileştirilmesidir, SSL / TLS temelde yerinde kalır, birkaç küçük sürümdeki değişiklikler esas olarak şifre paketlerinin yükseltilmesidir, TLS1.3 bir sıçrama-ileriye dönük değişikliktir, ancak bugün itibariyle resmi olarak yayınlanmamıştır. . IPv4 büyük bir ilerleme kaydetmiş olsa da, IPv6 ve DNS'nin güvenli bir DNSSEC eklediğini fark etti, ancak IPv6 gibi dağıtım ilerlemesi yavaş.
Mobil İnternetin hızlı gelişimi ve Nesnelerin İnternetinin kademeli olarak yükselmesiyle birlikte, ağ etkileşim senaryoları gittikçe daha bol hale geliyor, ağ iletiminin içeriği de artıyor ve kullanıcıların ağ aktarım verimliliği ve WEB yanıt hızı için daha yüksek gereksinimleri var.
Bir yandan uzun bir geçmişi olan ve yaygın olarak kullanılan eski bir protokoldür, diğer yandan kullanıcının kullanım senaryoları iletim performansı için gittikçe artan gereksinimlere sahiptir. Aşağıdaki uzun süredir devam eden sorunlar ve çelişkiler giderek daha belirgin hale geldi.
Anlaşmanın uzun tarihi, ara ekipmanın sağlamlığına yol açmıştır.
İşletim sisteminin uygulanmasına güvenmek, protokolün kendisinin katılığına yol açar.
Bir bağlantı kurmak için el sıkışma gecikmesi büyük.
Hattın başı bloke edildi.
Alt bölümlerde kısa bir açıklama:
Ara ekipmanın sertliği
TCP protokolü çok uzun süredir kullanılmış ve çok güvenilir olabilir. Güvenlik duvarları, NAT ağ geçitleri, doğrultucular vb. Dahil birçok ara cihazımızın bazı geleneksel eylemleri vardır.
Örneğin, bazı güvenlik duvarları yalnızca 80 ve 443'ün geçişine izin verir, diğer bağlantı noktalarına izin vermez. NAT ağ geçidi, ağ adresini çevirirken taşıma katmanının başlığını yeniden yazar; bu, her iki tarafın da yeni taşıma formatını kullanmasını engelleyebilir. Doğrultucular ve ara aracılar bazen güvenlik amacıyla tanımadıkları bazı seçenek alanlarını siler.
TCP protokolü başlangıçta bağlantı noktalarının, seçeneklerin ve özelliklerin eklenmesini ve değiştirilmesini destekledi. Bununla birlikte, TCP protokolü ve iyi bilinen bağlantı noktaları ve seçenekleri kullanmanın uzun geçmişi nedeniyle, ara cihazlar zaten bu söylenmemiş kurallara güvenmiştir, bu nedenle bu içeriklerin değiştirilmesi, ara bağlantılar tarafından kolayca engellenebilir ve başarısız olabilir.
Ve bu müdahaleler, TCP protokolündeki birçok optimizasyonun temkinli ve zor olmasına da neden oldu.
İşletim sisteminin uygulanmasına güvenmek katı bir anlaşmaya yol açar
TCP, işletim sistemi tarafından çekirdek batı yığın düzeyinde uygulanır ve uygulamalar yalnızca kullanılabilir ve doğrudan değiştirilemez. Uygulamanın güncelleme yinelemesi çok hızlı ve basit olmasına rağmen. Ancak TCP'nin yinelemesi çok yavaştır, çünkü işletim sistemi yükseltmesi zahmetlidir.
Artık mobil terminaller daha popüler olduğu için, bazı mobil kullanıcılar için işletim sistemlerinin yükseltilmesi birkaç yıl daha gecikebilir. PC tarafı sistem yükseltmesi daha da ciddi bir şekilde gecikiyor.Windows XP, neredeyse 20 yıldır olmasına rağmen hala çok sayıda kullanıcı tarafından kullanılıyor.
Sunucu sistemi, kullanıcı yükseltmelerine dayanmaz, ancak işletim sistemi yükseltmesi, temeldeki yazılımın ve çalışma zamanının güncellenmesini içerdiğinden, aynı zamanda tutucu ve yavaştır.
Bu, TCP'nin daha iyi özellik güncellemelerine sahip olsa bile, onu hızlı bir şekilde tanıtmanın zor olduğu anlamına gelir. Örneğin, TCP Hızlı Açma. 2013 yılında önerilmiş olmasına rağmen, Windows'un birçok sürümü hala desteklemiyor.
Bir bağlantı kurmak için el sıkışma gecikmesi büyük
İletim için HTTP1.0 / 1.1 veya HTTPS, HTTP2, TCP kullanılır. HTTPS ve HTTP2'nin de güvenli iletim için TLS protokolünü kullanması gerekir. İki el sıkışma gecikmesi var:
1. Üç yönlü TCP el sıkışmasının neden olduğu TCP bağlantısı kurulumundaki gecikme.
2. TLS tam anlaşmasının kurulması için en az 2 RTT gerekir ve basitleştirilmiş anlaşma 1 RTT anlaşması gecikmesi gerektirir.
Çoğu kısa bağlantı senaryosu için, böyle bir el sıkışma gecikmesinin büyük bir etkisi vardır ve ortadan kaldırılamaz.
Satır başı engelleme
Satır başı engelleme, esas olarak TCP protokolünün güvenilirlik mekanizması ile ortaya çıkar. TCP, veri sırasını tanımlamak için sıra numaralarını kullanır ve verilerin sırayla işlenmesi gerekir.Eğer önceki veriler kaybolursa, son veriler gelse bile, işleme için uygulama katmanını bilgilendirmez.
Buna ek olarak, TLS protokolü, verileri kayda göre işlediğinden, TLS protokol seviyesinde de bir satır engelleme başlığına sahiptir.Bir kayıtta veri kaybolursa, tüm kayıt doğru şekilde işlenmeyecektir.
Özetle, TCP ve TLS1.2'den önceki protokollerde yapısal sorunlar vardır. Mevcut TCP ve TLS protokollerinin üzerine yeni bir uygulama katmanı protokolü uygulamaya devam ederseniz, bu işletim sistemine, ara cihazlara ve kullanıcıya bağlı olacaktır. yanında olmak. Kurulum maliyeti çok yüksek ve direnç çok yüksek.
Bu nedenle, QUIC protokolü UDP'yi seçmiştir çünkü UDP'nin kendisi bağlantı kavramına sahip değildir ve bağlantı kurulumunun el sıkışma gecikmesini optimize eden üç yönlü el sıkışma gerektirmez.Aynı zamanda, TCP'nin güvenilirliğini, TLS'nin güvenliğini ve HTTP2'nin uygulama düzeyinde eşzamanlılığını gerçekleştirir. Yalnızca kullanıcı tarafındaki ve sunucu tarafındaki uygulamaların, işletim sistemi ve ara cihazların sınırlamalarını tamamen ortadan kaldıran QUIC protokolünü desteklemesi gerekir.
QUIC temel özellikleri
Düşük bağlantı kurma gecikmesi
0RTT Jianlian'ın QUIC'in HTTP2'ye göre en büyük performans avantajı olduğu söylenebilir. Peki 0RTT Jianlian nedir? Bunun iki anlamı var.
0RTT taşıma katmanı bir bağlantı kurabilir.
Şifreleme katmanı 0RTT, şifreli bir bağlantı kurabilir.
Şekil 1 HTTPS ve QUIC bağlantı süreci
Örneğin, yukarıdaki şeklin sol tarafında, 3 RTT gerektiren HTTPS'nin eksiksiz bir el sıkışma oluşturma süreci vardır. Oturum Devam Ettirme için bile en az 2 RTT gereklidir.
QUIC ne olacak? UDP'ye dayandığından ve 0RTT güvenli el sıkışmasını gerçekleştirdiğinden, çoğu durumda veri göndermek için yalnızca 0 RTT gerekir.İleri şifrelemeye göre, 0RTT'nin başarı oranı benzerdir. TLS'nin Sesison Biletinden çok daha yüksektir.
İyileştirilmiş tıkanıklık kontrolü
TCP tıkanıklık kontrolü aslında dört algoritma içerir: yavaş başlatma, tıkanıklıktan kaçınma, hızlı yeniden iletim ve hızlı kurtarma.
QUIC protokolü şu anda varsayılan olarak TCP protokolünün Kübik tıkanıklık kontrol algoritmasını kullanır ve ayrıca CubicBytes, Reno, RenoBytes, BBR ve PCC gibi tıkanıklık kontrol algoritmalarını destekler.
Tıkanıklık algoritmasının bakış açısından, QUIC yalnızca TCP protokolüne göre yeniden uygulanır.Peki QUIC protokolünün iyileştirmeleri nelerdir? Ana noktalar aşağıdaki gibidir:
Takılabilir
Takılabilir nedir? Etkilemek, değiştirmek ve durdurmak çok esnektir. Aşağıdaki yönlerden yansıtıldı:
Uygulama düzeyinde, bir işletim sistemine veya çekirdek desteğine ihtiyaç duymadan farklı tıkanıklık kontrol algoritmaları uygulanabilir. Bu bir adımdır, çünkü geleneksel TCP tıkanıklığı kontrolü, kontrol efektlerini elde etmek için uçtan uca bir ağ protokol yığını tarafından desteklenmelidir. Çekirdeğin ve işletim sisteminin dağıtım maliyeti çok yüksek ve yükseltme döngüsü çok uzun.Bu, günümüzün hızlı ürün yinelemesinde ve ağın patlayıcı büyümesindeki talebi karşılamak için elbette yeterli değil.
Tek bir uygulamanın farklı bağlantıları bile farklı tıkanıklık kontrol yapılandırmalarını destekleyebilir. Sunucu bile olsa kullanıcının ağ ortamı çok farklıdır.Büyük veri ve yapay zeka işleme ile birlikte her kullanıcı için farklı ama daha doğru ve etkili tıkanıklık kontrolü sağlayabiliriz. Örneğin BBR uygundur ve Cubic uygundur.
Uygulama, kesinti ve yükseltme olmaksızın tıkanıklık kontrolünün değiştirilmesini gerçekleştirebilir.Sadece sunucu tarafında yapılandırmayı değiştirmemiz ve yeniden yüklememiz gerekir. Tıkanıklık kontrol anahtarı hizmeti hiç durdurmadan gerçekleştirilebilir.
STGW, konfigürasyon seviyesinde optimize edilmiştir.Farklı hizmetler, farklı ağ standartları ve hatta farklı RTT'ler için farklı tıkanıklık kontrol algoritmaları kullanabiliriz.
Monoton olarak artan Paket Numarası
Güvenilirliği sağlamak için TCP, mesajların sırayla gelişini onaylamak için bayt sıra numarasına göre Sıra Numarası ve Onay kullanır.
QUIC aynı zamanda güvenilir bir protokoldür.TCP'nin sıra numarası yerine Paket Numarası kullanır ve her bir Paket Numarası kesin bir şekilde artırılır.Yani, Paket N kaybolsa bile, yeniden iletilen Paket N'nin Paket Numarası artık N değildir ve N'den büyük bir değerdir. TCP'ye gelince, yeniden iletilen bölümün sıra numarası ve orijinal bölümün sıra numarası değişmeden kalır.Tcp yeniden iletiminin belirsizliği tam da bu özellik nedeniyle ortaya çıkar.
Şekil 2 Tcp yeniden iletim belirsizliği
Yukarıdaki şekilde gösterildiği gibi, RTO zaman aşımı olayı meydana geldikten sonra, müşteri bir yeniden iletim başlatır ve ardından Ack verilerini alır. Seri numarası aynı olduğundan, bu Ack verisi orijinal talebe verilen yanıt mı yoksa yeniden iletim talebine verilen yanıt mı? Yargılamak zor.
Orijinal talebe yanıt olarak sayılırsa, ancak aslında yeniden iletim talebine verilen yanıtsa (yukarıdaki şekilde solda), örneklenen RTT artacaktır. Bir yeniden iletim isteğine yanıt olarak sayılırsa, ancak aslında orijinal isteğe bir yanıtsa, örneklenen RTT'nin çok küçük olmasına neden olmak kolaydır.
Quic yeniden iletilen Paket ve orijinal Paketin Pakcet Numarası kesinlikle arttığından, bu sorun kolayca çözülebilir.
Şekil 3 Hızlı yeniden iletim belirsiz değil
Yukarıdaki şekilde gösterildiği gibi, RTO oluştuktan sonra, doğru RTT hesaplaması yeniden iletilen Paket Numarasına göre belirlenebilir. Ack Paket Numarası N + M ise, örnek RTT yeniden iletim talebine göre hesaplanır. Pakcet Ack Numarası N ise, örnekleme RTT'si orijinal istek zamanına göre hesaplanır ve belirsizlik yoktur.
Ancak, yalnızca kesin olarak artan Paket Numarasına güvenmek, kesinlikle verilerin sırasını ve güvenilirliğini garanti edemez. QUIC, bir Akış Dengeleme kavramı sunar.
Yani, bir Akış birden fazla Paket aracılığıyla iletilebilir ve Paket Numarası kesinlikle artırılır ve hiçbir bağımlılığı yoktur. Ancak Paketteki Yük bir Akış ise, uygulama verilerinin sırasını sağlamak için Akışın Ofsetine güvenmesi gerekir. Hata gibi! Referans kaynağı bulunamadı. Gösterildiği gibi, gönderici art arda Pakcet N ve Pakcet N + 1 gönderir ve Akışın Ofseti sırasıyla x ve x + y'dir.
Paket N'nin kaybolduğunu varsayarsak, bir yeniden iletim başlatın. Yeniden iletilen Paket Numarası N + 2'dir, ancak Akışının Ofseti hala x'dir. Bu şekilde, Paket N + 2 daha sonra gelse bile, Akış x ve Akış x + y sırayla düzenlenir ve işlenmek üzere başvuruya teslim edilir.
Şekil 4 Akış Dengesi düzeni garanti eder
Yeniden başlamaya izin verilmez
Reneging nedir? Yani alıcı, alınan ve SACK seçeneğine bildirilen içeriği atar. TCP protokolü bu davranışı teşvik etmez, ancak protokol seviyesi bu tür davranışlara izin verir. Ana neden, Arabellek taşması ve yetersiz bellek gibi sunucu kaynaklarının sınırlı olmasıdır.
Yeniden gönderme, verilerin yeniden iletiminde büyük parazite neden olacaktır. Çünkü Sack, alındığını belirtti, ancak alan taraf aslında verileri atıyor.
QUIC, protokol düzeyinde geri dönmeyi yasaklar.Bir paket Onaylandığı sürece, doğru şekilde alınması gerektiği düşünülür ve bu parazit azaltılır.
Daha fazla Ack bloğu
TCP'nin Sack seçeneği, gönderene, alınan sürekli segmentin aralığını bildirebilir, böylece gönderici, seçici yeniden iletim gerçekleştirebilir.
TCP başlığının maksimum 60 bayt olması ve standart başlık 20 bayt yer kapladığından, Tcp Seçeneğinin maksimum uzunluğu yalnızca 40 bayttır, artı Tcp Zaman Damgası seçeneği 10 bayt kaplar, bu nedenle yalnızca Sack seçeneği kalır. 30 bayt.
Her Sack Bloğunun uzunluğu 8 artı Sack Opsiyonunun başlığında 2 bayttır, bu da Tcp Sack Opsiyonunun sadece 3 bloğa kadar sağlayabileceği anlamına gelir.
Ancak, Quic Ack Frame aynı anda 256 Ack Block sağlayabilir.Görece yüksek paket kaybı oranına sahip bir ağda, daha fazla Sack Block, ağ kurtarma hızını artırabilir ve yeniden iletim miktarını azaltabilir.
Ack Gecikme süresi
Tcp'nin Zaman Damgası seçeneğiyle ilgili bir sorun var.Sadece gönderenin zaman damgasını yansıtıyor, ancak alıcı tarafın segmenti aldığı andan Ack gönderdiği ana kadar geçen süreyi hesaplamıyor. Bu süre kısaca Ack Delay olarak adlandırılabilir.
Bu, RTT hesaplama hatalarına yol açacaktır. Aşağıda gösterildiği gibi:
TCP'nin RTT hesaplamasının şu şekilde olduğu düşünülebilir:
Quic şu şekilde hesaplar:
Elbette, RTT'nin spesifik hesaplanması o kadar basit değil, örneklenmesi ve geçmiş değerlere göre düzgün bir şekilde hesaplanması gerekiyor.Aşağıdaki formüle bakın.
Akış ve bağlantı seviyelerine dayalı akış kontrolü
QUIC'in akış denetimi, HTTP2'ye benzer, yani Bağlantı ve Akış seviyelerinde iki akış denetimi sağlar. Neden iki tür akış kontrolüne ihtiyacınız var? Esas olarak QUIC çoğullamayı desteklediği için.
Akış, bir HTTP isteği olarak düşünülebilir.
Bağlantı, bir TCP bağlantısına benzer olabilir. Çoğullama, bir Connetion üzerinde birden fazla Akış olacağı anlamına gelir. Hem tek bir Akışı hem de tüm Akışların genel kontrolünü kontrol etmek gerekir.
QUIC'in akış kontrolü sağlama ilkesi nispeten basittir:
Karşı uca, window_update çerçevesi aracılığıyla alabileceği bayt sayısını söyleyin, böylece gönderen bu miktardan daha fazla veri göndermez.
Eşdüzeyine akış denetimi engellendiği için veri gönderemediğini söylemek için BlockFrame'i kullanın.
QUIC'in akış kontrolü TCP'den biraz farklıdır.Güvenilirliği sağlamak için, sağa kaydırıldığında pencerenin sol kenarının uzunluğu, onaylanan baytların sayısına bağlıdır. Ortada bir paket kaybı varsa, daha büyük sıra numarasına sahip bir segment alınsa bile, pencere bu sıra numarasını aşamaz.
Ancak QUIC farklıdır Bazı paketler daha önce alınmamış olsa bile, kayması sadece alınan maksimum ofset baytlarına bağlıdır.
Şekil 5 Quic Akış Kontrolü
Akış için:
Bağlantı için:
Benzer şekilde 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.
Hat başı engelleme olmadan çoklama
QUIC'in çoğullaması HTTP2'ye benzer. Bir QUIC bağlantısı üzerinden aynı anda birden fazla HTTP isteği (akış) gönderilebilir. Ancak QUIC'in çoğullamasının HTTP2'ye göre büyük bir avantajı vardır.
QUIC, bir bağlantıdaki birden çok akış arasında bağımlılığa sahip değildir. Bu şekilde, eğer akım2 bir udp paketini kaybederse, bu sadece akım2'nin işlenmesini etkileyecektir. Akış2 öncesi ve sonrası akışların işlenmesini etkilemeyecektir.
Bu aynı zamanda hat başı engellemesinin etkisini büyük ölçüde hafifletir veya hatta ortadan kaldırır.
Çoklama, bir TCP bağlantısı üzerinden aynı anda birden çok istek gönderebilen HTTP2'nin en güçlü özelliğidir. Ancak, aşağıdaki şekilde gösterildiği gibi, hat engellemenin başı olan TCP sorununu da daha da kötüleştirdi:
Şekil 6 HTTP2 üstbilgisini engelleme
HTTP2, bir TCP bağlantısı üzerinden aynı anda 4 akış gönderir. Stream1 doğru bir şekilde geldi ve uygulama katmanı tarafından okundu. Ancak Stream2'nin üçüncü tcp segmenti kaybolur.Verilerin güvenilirliğini sağlamak için, Stream3 ve Stream4'ün tüm verileri şu anda ulaşmış olmasına rağmen, TCP'nin göndericideki üçüncü segmenti bir sonraki verileri okuması için uygulama katmanına bildirmesi için yeniden iletmesi gerekir. Alıcı taraf engellendi, ancak hepsi engellendi.
Sadece bu değil, HTTP2 TLS kullanımını zorunlu kıldığı için, TLS protokol seviyesinde bir satır başı engelleme de vardır.
Şekil 7 TLS satır başı blokajı
Kayıt, TLS protokolü işlemenin en küçük birimidir ve maksimum sayı 16K'yı geçemez. Nginx gibi bazı sunucuların varsayılan boyutu 16K'dır. Bir kaydın şifrelenmeden ve şifresi çözülmeden önce bir veri tutarlılığı kontrolünden geçmesi gerektiğinden, bir bayt kaybedilse bile 16K'lık bir kayıt, alınan 15.99K verinin eksik olduğu için işlenemez olmasına neden olur.
Öyleyse neden QUIC çoğullama yukarıdaki sorunlardan kaçınabilir?
QUIC'in en temel iletim birimi, MTU'nun boyutunu aşmayan Paket'tir. Tüm şifreleme ve kimlik doğrulama süreci Pakete dayanır ve birden fazla Paketi kapsamaz. Bu şekilde, TLS protokolünün hat başı engellemesinden kaçınılabilir.
Akışlar birbirinden bağımsızdır. Örneğin, Stream2 bir Pakcet'i kaybederse, Stream3 ve Stream4'ü etkilemeyecektir. TCP hat başı engellemesi yoktur.
Şekil 8 QUIC çoğullamada hat başı engelleme sorunu yoktur
Elbette, tüm QUIC verileri satır başı engellemesinden etkilenmeyecektir.Örneğin, QUIC şu anda Hpack sıkıştırma algoritmasını kullanmaktadır. Algoritmanın sınırlandırması nedeniyle, bir başlık verisi kaybolduğunda, satır başı engellemeyle karşılaşabilir.
Genel olarak konuşursak, QUIC video gibi büyük miktarda veri ilettiğinde, hat başı engellemesinden etkilenmez.
Şifrelenmiş ve kimliği doğrulanmış mesajlar
TCP protokol başlığı herhangi bir şifreleme ve kimlik doğrulamasına tabi tutulmamıştır, bu nedenle iletim sırasında ara ağ aygıtları tarafından tahrif edilmesi, enjekte edilmesi ve gizlice dinlenmesi kolaydır. Seri numarasını ve kayan pencereyi değiştirmek gibi. Bu davranışlar, performans optimizasyonundan kaynaklanıyor olabilir veya aktif saldırılar olabilir.
Ancak QUIC paketinin dişlere kadar silahlandığı söylenebilir. PUBLIC_RESET ve CHLO gibi tek tek mesajlar dışında, tüm mesaj başlıkları doğrulanır ve mesaj gövdeleri şifrelenir.
Bu şekilde, QUIC mesajında herhangi bir değişiklik yapıldığı sürece, alıcı taraf bunu zamanında keşfederek güvenlik riskini etkili bir şekilde azaltabilir.
Aşağıdaki şekilde gösterildiği gibi kırmızı kısım, kimlik doğrulamalı Akış Çerçevesinin mesaj başlığıdır. Yeşil kısım, tamamı şifrelenmiş mesaj içeriğidir.
Bağlantı geçişi
Bir TCP bağlantısı, dört grupla tanımlanır (kaynak IP, kaynak bağlantı noktası, hedef IP, hedef bağlantı noktası). Bağlantı geçişi nedir? Yani, unsurlardan herhangi biri değiştiğinde, bu bağlantı hala korunur ve iş mantığı kesintisiz tutulabilir. Tabii ki, buradaki asıl endişe, istemcinin değişmesidir, çünkü istemci kontrol edilemez ve ağ ortamı sık sık değişir ve sunucunun IP'si ve bağlantı noktası genellikle sabittir.
Örneğin, cep telefonunuzu WIFI ve 4G mobil ağlar arasında geçiş yapmak için kullandığınızda, müşterinin IP'si kesinlikle değişecektir ve sunucuyla TCP bağlantısını yeniden kurmanız gerekir.
Örneğin, genel bir NAT çıkışı kullandığınızda, bazı bağlantı yarışmalarının bağlantı noktasını yeniden kurması gerekir, bu da istemcinin bağlantı noktasının değişmesine neden olur ve TCP bağlantısının da yeniden kurulması gerekir.
TCP bağlantı değişikliklerine yanıt olarak, MPTCP'nin aslında bir çözümü vardır, ancak MPTCP işletim sistemi ve ağ protokol yığınının desteğini gerektirdiğinden, dağıtım direnci çok büyüktür ve şu anda uygulanamaz.
Dolayısıyla, TCP bağlantıları açısından bu sorun çözülemez.
QUIC, bağlantı geçişini nasıl başarır? Çok basit, herhangi bir QUIC bağlantısı artık IP ve bağlantı noktası dört katı tarafından tanımlanmıyor, kimlik olarak 64 bit rasgele bir sayıdır, böylece IP veya bağlantı noktası değişse bile, kimlik değişmediği sürece bağlantı kalır Korunduğunda, üst düzey iş mantığı değişiklikleri algılayamaz, kesintiye uğramaz ve yeniden bağlanmaya gerek kalmaz.
Bu kimlik müşteri tarafından rastgele oluşturulduğundan ve 64 bit uzunluğa sahip olduğundan, çarpışma olasılığı çok düşüktür.
Diğer önemli noktalar
Buna ek olarak, QUIC ayrıca ileri artıklık hatası düzeltmesi uygulayabilir El sıkışma mesajları gibi önemli paketler kaybolduğunda, el sıkışma mesajları fazlalık bilgilere göre geri yüklenebilir.
QUIC ayrıca sertifika sıkıştırmasını gerçekleştirebilir, sertifika aktarım miktarını azaltabilir ve paket başlığını doğrulayabilir.
Yer kısıtlamaları nedeniyle, bu makale onu ayrıntılı olarak tanıtmayacaktır.İlgilenenler dokümantasyon, dokümantasyon ve dokümantasyona başvurabilir.
Referans ipuçları
. https://www.chromium.org/quic
. https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit
E. Rescorla, "Taşıma Katmanı Güvenliği (TLS) Protokol Sürümü 1.3", draft-ietf-tls-tls13-21, https://tools.ietf.org/html/draft-ietf-tls-tls13-21, 03 Temmuz 2017
. Adam Langley, Wan-Teh Chang, "QUIC Crypto", https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit, 20161206
. https://www.multipath-tcp.org/
Ha, S., Rhee, I. ve L. Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", ACM SIGOPS Operating System Review, 2008.
M. Belshe, BitGo, R. Peon, "Hypertext Transfer Protocol Version 2 (HTTP / 2)", RFC 7540, Mayıs 2015
. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", rfc2018, https://tools.ietf.org/html/rfc2018, Ekim 1996
V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", rfc6298, https://tools.ietf.org/html/rfc6298, Haziran 2011
R. Peon, H. Ruellan, "HPACK: HTTP / 2 için Başlık Sıkıştırma", RFC7541, Mayıs 2015
M. Scharf, Alcatel-Lucent Bell Labs, S. Kiesel, "TCP ve SCTP'de Hat Başı Engellemenin Nicelendirilmesi", https://tools.ietf.org/id/draft-scharf-tcpm-reordering-00 .html, 15 Temmuz 2013
. Ilya Grigorik, "TLS Kayıt Boyutunu Optimize Etme ve Gecikme Gecikmesi", https://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/, 24 Ekim 2013
J. Salowey, H. Zhou, P. Eronen, H. Tschofenig, "Sunucu Tarafı Durumu Olmadan Taşıma Katmanı Güvenliği (TLS) Oturum Devam Ettirme", RFC5077, Ocak 2008
. Dierks, T. ve E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487 / RFC5246, Ağustos 2008, < > .
. Shirey, R., "İnternet Güvenliği Sözlüğü, Sürüm 2", FYI, RFC 4949, Ağustos 2007
Luo Cheng, "HTTPS Performans Optimizasyonu", Şubat 2017
Postel, J., "İletim Kontrol Protokolü", STD 7, RFC793, Eylül 1981.
J. Postel, "Kullanıcı Datagram Protokolü", RFC768, Ağustos 1980
. Q. Dang, S. Santesson, K. Moriarty, D. Brown.T. Polk, "İnternet X.509 Açık Anahtar Altyapısı: DSA ve ECDSA için Ek Algoritmalar ve Tanımlayıcılar", RFC5758, Ocak 2010
Bassham, L., Polk, W. ve R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, Nisan 2002
. D.Cooper, S.Santesson, S.Farrell, S. Boeyen, R. Housley, W.Polk, "Internet X.509 Genel Anahtar Altyapı Sertifikası ve Sertifika İptal Listesi (CRL) Profili", RFC5280, Mayıs 2008
. M. Allman, V. Paxson, E. Blanton, "TCP Tıkanıklık Kontrolü", RFC5681, Eylül 2009
. Robbie Shade, "QUIC'de akış kontrolü", https://docs.google.com/document/d/1F2YfdDXKpy20WVKJueEf4abn_LVZHhMUMS5gX6Pgjl4/edit#, Mayıs, 2016,
. ianswett, "QUIC fec v1", https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit#heading=h.xgjl2srtytjt, 2016-02-19
. D.Borman, B.Braden, V.Jacobson, R.Scheffenegger, Ed. "Yüksek Performans için TCP Uzantıları", rfc7323, https://tools.ietf.org/html/rfc7323, Eylül 2014
. Luo Cheng, "WEB hızlandırma, anlaşma önce", https://zhuanlan.zhihu.com/p/27938635, temmuz, 2017
yazar hakkındaLuo Cheng, Tencent'te kıdemli Ar-Ge mühendisi. Şu anda, esas olarak Tencent stgw (Tencent Güvenli Bulut Ağ Geçidi) ile ilgili işlerden 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.
