İki ana bilgisayar arasında birkaç dubleks kanala ihtiyacım var. Yalnızca bir TCP bağlantısı kurmanın birçok avantajı vardır. Fakat çoğullamanın bazı kaçınılmaz sorunlara yol açacağından şüpheliyim. Performansa zarar verecek mi yoksa gecikmeyi önemli ölçüde artıracak mı? Peki ya bellek kullanımı ve CPU kullanımı? Vermek istediğiniz herhangi bir öneri veya uyarı var mı?
Yanıtlar:
TLDR: TCP'nin üstünde birden fazla kanalı çoğaltırken (doğru yaparsanız) fark edebileceğiniz en büyük dezavantaj , kanallar arasındaki hat başı engellemesi nedeniyle artan bir gecikmedir .
Sonuç: Gecikmeyi umursamıyorsanız iyi olmalısınız.
Diğer yandan , tek bir TCP bağlantısı kullanmak “diğer akışlar ve daha uzun ömürlü bağlantılar ile daha az rekabet anlamına gelir ve bu da mevcut ağ kapasitesinin daha iyi kullanılmasına yol açar” .
Aynı TCP akışının üstünde birden çok kanalı çoğaltırsanız, kanallar satır başı engellemesine maruz kalabilir :
Aktarım protokolleri sıralı veya kısmi sıralı hizmet sunduğunda hat başı engelleme (HOL) oluşabilir: Segmentler kaybolursa, sonraki iletilerin alıcı kuyruğunda başarılı bir yeniden iletim beklemesi gerekir ve bu nedenle gecikir.
TCP'nin üzerinde birden fazla akışı çoğalttığınızda , kanallar arasında HOL elde edersiniz .
A kanalı TCP gönderme arabelleğini doldurduysa, B kanalının yeni verilerinin uzak uygulama katmanına etkili bir şekilde iletilebilmesi için tüm bu verilerin alınmasını beklemeniz gerekir.
Bkz "TCP üstündeki Multiplexing" TCP üstünde ve kanalları multiplexing'i ilgili daha fazla ayrıntı için hackernews üzerine tartışma .
Bunun tipik bir örneği SSH'dir. SSH çoklu kanalları çoğaltabilir (bkz ControlMaster. ControlPathVe ControlPersistOpenSSH'de). Bunu kullanmak yeni bir SSH oturumu (başlangıç gecikmesi) başlatma maliyetini azaltır, ancak bir kanalda yoğun aktarım genellikle diğer kanalların gecikmesini / etkileşimini artırır (birden fazla TCP akışı kullanıyorsanız gerçekleşmez): oturumlar ve aynı kanal üzerinden ağır bir dosya aktarımını tetiklemeye başlarsanız, oturumunuz çok daha az etkileşimli olmaya başlar.
HTTP / 2, HOL engellemesini düzeltmek için TCP üzerinden isteklerin / yanıtların çoğullamasını kullanır. Bu özellik HTTP / 2 ile ilgili birçok makale ve makalede tanıtılmıştır. HTTP / 2 RFC istemlerde:
HTTP / 1.1 istek boru hattı ekledi, ancak bu yalnızca kısmen istek eşzamanlılığını ele aldı ve hala satır başı engellemesinden muzdarip.
[...]
Ortaya çıkan protokol ağ için daha kolaydır, çünkü HTTP / 1.x ile karşılaştırıldığında daha az TCP bağlantısı kullanılabilir. Bu, diğer akışlar ve daha uzun ömürlü bağlantılar ile daha az rekabet anlamına gelir ve bu da mevcut ağ kapasitesinin daha iyi kullanılmasına yol açar.
Ancak tartışılmayan şey, HOL engellemesinin tamamen çözülmediğidir. TCP üzerinden HTTP / 2 hala acı çekiyor ) TCP düzeyinde HOL engellemesinden .
Bu QUIC ile ilgili bu LWN makalesinde tartışılmıştır :
HTTP / 2, tek bir bağlantıda yerleşik birden çok "akış" kullanarak bu sorunu çözmek için tasarlanmıştır . [...] yeni bir sorun yaratır: tek bir paketin kaybı, tüm akışların iletimini bir kerede durdurarak yeni gecikme sorunları yaratacaktır. Satır başı engelleme sorunundaki bu varyant TCP'nin kendisinde yerleşiktir ve HTTP düzeyinde daha fazla düzeltmeyle düzeltilemez.
Bu, SCTP'nin (çoklu akış) ayırt edici özelliklerinden biridir, aynı SCTP ilişkisinde birden fazla bağımsız akışa sahip olabilirsiniz ve her akış diğerlerini engellemez.
SCH üzerinden SSH - SSH'de çapraz kanal HOL engellemesini önlemek için SCTP kullanma etkisi için Çok Kanallı Protokolü SCTP'ye Uyarlayarak En İyileştirme konusuna bakın :
SCTP, satır başı engelleme olarak bilinen bir etkiyi azaltmak için yalnızca tek bir akıştaki mesajların sırasını korur. Bir mesaj kaybolursa, sonraki mesajlar, sırayı korumak için kaybolan mesaj tekrar iletilene kadar ertelenmelidir. Yalnızca aynı akıştaki iletilerin ertelenmesi gerektiğinden, bir kayıptan sonra etkilenen iletilerin sayısı azalır.
[...]
SSH kanallarını SCTP akışlarına eşleştirerek, çoklu akış avantajı hat başı engellemenin azaltılması olan SSH'ye sunulur .
SCTP'nin dağıtılması kolay değildir (işletim sistemi kullanılabilirliği, orta kutu etkileşimi vb. Nedeniyle). Bir olasılık kullanıcı alanında UDP üzerinden uygulamaktır .
Başka bir örnek, HTTP'yi UDP üzerinden çoğaltmak için kullanılan deneysel QUIC protokolüdür (çünkü TCP'nin üstüne birden çok akışı HTTP / 2 olarak çoğaltmak HOL engellemesinden muzdarip olduğu için ):
QUIC, TCP'ye kıyasla gecikmeyi azaltan yeni bir aktarımdır . Yüzeyde QUIC, UDP'de uygulanan TCP + TLS + HTTP / 2'ye çok benzer.
[...]
Hat blokajı olmadan çoklama
Google'ın QUIC protokolü: Web'i TCP'den UDP'ye taşımak, kanalları TCP'nin üstüne çoğaltırken QUIC ve HOL engellemesine iyi bir genel bakış sunar.
Yakın zamanda yapılan bir sunum , QUIC üzerinden HTTP'nin gecikmeyi geliştirdiğini, ancak HOL engelleme geliştirmesinin "daha küçük bir yarar" olduğunu iddia ediyor :
0-RTT, Gecikme süresinin% 50'sinden fazlası
[...]
Daha az zaman aşımı tabanlı yeniden iletim kuyruk gecikmesini artırır […]
Diğer, daha küçük faydalar, örneğin hat başı engelleme
QUIC, “UDP'de uygulanan TCP + TLS + HTTP / 2'ye çok benzer” olarak tanımlanırken, aslında HTTP / 2'den bağımsız olarak kullanılabilen ve ihtiyaçlarınıza uygun olabilecek genel amaçlı bir aktarım olduğunu unutmayın.
Not: HTTP / QUIC si HTTP / 3 olarak standartlaştırılacaktır .
ZeroMQ Rehberini okumanız gerektiğini söyleyebilirim , nedenleri ve dezavantajları ile verdiği desenler temel okuma.
Ancak, aksi takdirde, ağ kanalının uygulama verisi dağıtımından çıkarılmasıyla ilgili bir sorun yoktur. Gönderilen veri paketlerinin muxing ve demuxing (ve sürekli bir akışta veri akışı değil, burada paket tabanlı bir mimari tavsiye ederim) ve her iki ucunda arabellekleme almak zorunda kalacak.
Aksi halde çok az etki olmalı, verileri arabelleğe almak için daha fazla belleğe - ancak sadece biraz - ve paketleri kilitlemek ve ayrıştırmak için daha fazla kod kullanırken biraz daha fazla CPU'ya ihtiyacınız olabilir, ancak önemli bir şey yoktur. (büyük bir verim ve performans gerektiren bir uzman yazmıyorsanız kritiktir).
Evet, tam olarak bu prensibi kullanarak bir istemci-sunucu veritabanı sistemi oluşturdum.
Bir TCP bağlantısına çoğullayan kanalların her biri veri paketlerini gönderir, bunlar daha sonra diğer uçtaki ilgili alıcılara ayrılır.
Bağlantının bir garrulous kanalı tarafından takılması, gönderilmeye hazır verileri olan kanallar arasından hangi paketin aktarılacağı yuvarlak bobin seçimi yapan TCP bağlantı göndericisi tarafından yapılır.
Bir kanalın 1 GB'lık bir paket göndermeye karar vermesine ve diğer herkesi kilitlemesine karar vermek için gönderen, bir paketi parçalara ayırmayı ve başka bir kanala dönüş yapmadan önce yalnızca bir yığın göndermeyi seçebilir. Alıcı uçta, parçaların bir pakete yeniden birleştirilmesi, alıcı paketi görmeden önce yapılır.