İki yukarı bağlantı ama tek tünel: yedekleme, dengeleme veya birleştirme
Arıza anında geçiş, akış başına dengeleme ve tek akışı birleştirme üç farklı vaattir. İki varsayılan yol size ilkini verir, diğer ikisini vermez.
İki internet hattı bir VPN'i daha erişilebilir yapabilir ve bazı iş yükleri için daha hızlı hale getirebilir, ancak bunlardan hangisinin olacağına mekanizma karar verir. İki varsayılan rotası olan bir yönlendirici birleştirilmiş değildir ve binlerce iç bağlantı taşıyan bir tünel hâlâ tek bir dış akıştır. Vaadi önce adlandırmak, bir tasarım ile pahalı bir hayal kırıklığı arasındaki farktır. Aşağıdaki tablo seçenekleri her birinin uzak uçta neye ihtiyaç duyduğuna ve bir bağlantı kaybının bir aktarıma ne yaptığına göre ayırır.
Üç vaat ve yalnızca biri bir ortak gerektirir
Arıza anında geçiş, tercih edilen bağlantı kaybolduğunda bir yolu erişilebilir tutar. Akış hash'i ile dengeleme bağımsız akışları iki yukarı bağlantıya yayar. Tek akışı birleştirme, bir aktarımın iki bağlantıyı aynı anda kullanmasını sağlar. Bunlar farklı gereksinimleri olan farklı ürünlerdir ve yalnızca sonuncusu yönlendiricinizin dışındaki bir şeyin işbirliğine ihtiyaç duyar.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
O tablodaki hiçbir şey ikinci bir hat satın almak için gerekçe değildir. Yaptığı şey, bir geçiş tasarımının birleştirme gibi değerlendirilmesini önlemektir.
Bir tünel yönlendiriciye neden tek akış gibi görünür
Yükü dengeleyen bir yönlendirici kaynak ve hedef adresleri bağlantı noktalarıyla birlikte hash'ler ve ardından tüm akışı hash'in gösterdiği yere gönderir. Bir VPN tüneli yönlendiricinin bakış açısından böyle tek bir akıştır, içinde ne çalışırsa çalışsın. İç bağlantılar hiçbir zaman hash kararına ulaşmaz, çünkü dış başlık yolu zaten belirlemiştir. Bu yüzden ikinci bir yukarı bağlantı birçok kullanıcı için toplam kapasiteyi ikiye katlayabilir ve tek bir kullanıcının büyük aktarımında hiçbir şeyi değiştirmez.
İki ayrı tünel size iki aday verebilir, ancak yine de trafiği atayan ve yanıtları isteği taşıyan yolda tutan bilinçli bir politikaya ihtiyaçları vardır. Asimetrik yönlendirme, o adımın atlanmasının olağan sonucudur. Asgari olan, akışı, tercih edilen bağlantıyı ve yedek bağlantıyı adlandıran bir politikadır.
Ethernet birleştirme ilgisiz sağlayıcıları aşmaz, çünkü uzak ucun birleştirme protokolüne katılması gerekir. İki internet servis sağlayıcısı arasında birleştirme, işbirliği yapan bir uç nokta yoksa bir araştırma projesidir.
Çok yollu TCP'nin iki uçta gerektirdiği şey
Linux'un Multipath TCP belgeleri tek bir bağlantıya ait birkaç alt akışı açıklar. Bir uçtaki çekirdek desteği tek başına hiçbir şeyi değiştirmez, çünkü karşı tarafın da bu alt akışları kabul etmesi gerekir. Uzak taraftaki bir vekil sunucu diğer yaygın düzenlemedir ve kendi kapasitesi ve kullanılabilirliği olan, planlanması gereken bir bileşen haline gelir. Aynı mantık WireGuard için kolay bir yanıtı dışlar, çünkü taşıması UDP'dir: MPTCP TCP alt akışlarını büyütür ve tasarımda başka bir şey olmadan o tüneli birleştiremez.
Çekirdek özelliğinin açık olup olmadığını etrafında tasarım yapmadan önce kontrol edin, çünkü birçok dağıtım onu kapalı olarak gönderir. Bu üç komut bunu bir dakikada yanıtlar.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show
Broşürden değil, iş yükünden seçin
İş yükü çok sayıda bağımsız oturum ise, akış hash'i ile dengeleme uzak ucun işbirliği olmadan kapasite ekleyebilir. Tek bir büyük aktarım ise yalnızca bir birleştirme tasarımı yardımcı olur ve o tasarımın işbirliği yapan bir ortağa ihtiyacı vardır. Gereksinim, bağlantı öldüğünde işin devam etmesi ise yanıt geçiştir ve tek bir aktarımın verimi önemsizdir.
Gereksinimi içinde fiil olan tek bir cümleyle yazın: bir yedek iki kat daha hızlı bitiyor veya düşen bir bağlantı bir oturumu bitirmiyor. Belirsiz hedefler kimsenin kabul edemeyeceği veya reddedemeyeceği tasarımlar üretir. Ardından uzak ucun ne olabileceğine karar verin, çünkü en ucuz seçenek genellikle orada yeni hiçbir şey gerektirmeyendir. Bu kısıt, ilk toplantıdan önce broşürdeki iddiaların çoğunu ortadan kaldırır.
Üç vaadi gereksinim belgesinde ayrı tutun. Üçünü de iddia eden bir tasarım genellikle birini teslim eder ve diğerlerini sessizce varsayar. Sonraki bölüm hangisinin gerçekten teslim edildiğini sınar.
Bir aktarımı ve çoğunu test edin, sonra bir bağlantıyı çekin
Tek bir sürekli aktarımı aynı hedefe giden birkaç paralel aktarımla karşılaştırın ve her biri için kayıp, gecikme ve bağlantı başına kullanımı kaydedin. Yalnızca paralel oturumlarda kazanç varsa bu akış dağıtımına işaret eder, tek akış birleştirmesine değil. Bir yukarı bağlantının kaybını ayrı test edin, çünkü iki bağlantı çalışırken kapasite kurulmuş bir oturum için geçiş hakkında hiçbir şey söylemez. Her testten önce ve sonra rotayı, soketi ve yeniden gönderim sayaçlarını kaydedin.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5
Tek aktarım hâlâ bir yukarı bağlantı kullanıyorsa tasarım tam olarak akış hash'inin ima ettiğini yapıyordur. Paralel aktarımlar ikisine de yayılıyorsa dengeleme çalışıyor ve birleştirme çalışmıyordur. Tasarımın üç vaatten hangisini gerçekten tuttuğunu kaydedin ve bir sonraki kapasite konuşması satıcı iddiasıyla değil kanıtla başlar.