Dy lidhje lart por një tunel: kalim, balancim apo bashkim
Kalimi në dështim, balancimi për çdo rrjedhë dhe bashkimi i një rrjedhe të vetme janë tre premtime të ndryshme. Dy rrugë të paracaktuara ju japin të parën, dhe jo dy të tjerat.
Dy linja interneti mund ta bëjnë një VPN më të disponueshme, dhe mund ta bëjnë më të shpejtë për disa ngarkesa pune, por mekanizmi vendos cila nga të dyja ndodh. Një ruter me dy rrugë të paracaktuara nuk është i bashkuar, dhe një tunel që mban mijëra lidhje të brendshme është ende një rrjedhë e vetme e jashtme. Emërtimi i premtimit së pari është dallimi midis një dizajni dhe një zhgënjimi të shtrenjtë. Tabela më poshtë i ndan opsionet sipas asaj që kërkon secili në skajin e largët dhe çfarë bën humbja e lidhjes me një transferim.
Tre premtime, dhe vetëm një ka nevojë për partner
Kalimi në dështim e mban një rrugë të disponueshme kur lidhja e preferuar zhduket. Balancimi sipas hash-it të rrjedhave i shpërndan rrjedhat e pavarura në të dy lidhjet lart. Bashkimi i një rrjedhe të vetme lejon një transferim të përdorë të dy lidhjet njëkohësisht. Këto janë produkte të ndryshme me kërkesa të ndryshme, dhe vetëm i fundit ka nevojë për bashkëpunimin e diçkaje jashtë ruterit tuaj.
| 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 |
Asgjë në atë tabelë nuk është arsye për të blerë një linjë të dytë. Ajo që bën është të parandalojë vlerësimin e një dizajni kalimi sikur të ishte bashkim.
Pse një tunel duket si një rrjedhë e vetme për ruterin
Një ruter që balancon ngarkesën bën hash të adresave të burimit dhe destinacionit bashkë me portat, pastaj dërgon të gjithë rrjedhën atje ku tregon hash-i. Një tunel VPN është një rrjedhë e tillë nga këndvështrimi i ruterit, çfarëdo që punon brenda tij. Lidhjet e brendshme nuk arrijnë kurrë në vendimin e hash-it, sepse kryetitulli i jashtëm tashmë ka vendosur rrugën. Kjo është arsyeja pse një lidhje e dytë lart mund të dyfishojë kapacitetin total për shumë përdorues dhe të mos ndryshojë asgjë në transferimin e madh të një përdoruesi.
Dy tunele të veçantë mund t'ju japin dy kandidatë, por atyre u duhet ende një politikë e qëllimshme që cakton trafikun dhe i mban përgjigjet në rrugën që mbajti kërkesën. Ushtrimi asimetrik është rezultati i zakonshëm i kapërcimit të atij hapi. Minimumi është një politikë që emërton rrjedhën, lidhjen e preferuar dhe lidhjen rezervë.
Bashkimi i Ethernet nuk kalon përtej ofruesve të palidhur, sepse skaji i largët duhet të marrë pjesë në protokollin e grumbullimit. Një bashkim përtej dy ISP-ve është projekt kërkimor nëse nuk ekziston një pikë fundore bashkëpunuese.
Çfarë kërkon TCP me shumë rrugë në të dy skajet
Dokumentacioni i Linux për Multipath TCP përshkruan disa nënrrjedha që i përkasin një lidhjeje. Mbështetja e kernelit në një skaj nuk ndryshon asgjë më vete, pasi edhe pala tjetër duhet t'i pranojë ato nënrrjedha. Një proxy në anën e largët është rregullimi tjetër i zakonshëm, dhe bëhet komponent me kapacitetin dhe disponueshmërinë e vet që duhen planifikuar. E njëjta logjikë përjashton një përgjigje të lehtë për WireGuard, transporti i të cilit është UDP: MPTCP rrit nënrrjedha TCP dhe nuk mund ta grumbullojë atë tunel pa diçka tjetër në dizajn.
Kontrolloni nëse funksioni i kernelit është aktivizuar përpara se të dizajnoni rreth tij, sepse shumë shpërndarje e ofrojnë të çaktivizuar. Këto tre komanda përgjigjen për këtë brenda një minute.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showZgjidhni sipas ngarkesës së punës, jo sipas broshurës
Nëse ngarkesa e punës është shumë sesione të pavarura, balancimi sipas hash-it mund të shtojë kapacitet pa bashkëpunim në skajin e largët. Nëse është një transferim i madh, vetëm një dizajn grumbullimi do të ndihmojë, dhe ai dizajn ka nevojë për një palë bashkëpunuese. Nëse kërkesa është që puna të vazhdojë kur një lidhje vdes, përgjigjja është kalimi dhe xhiroja e një transferimi të vetëm është e parëndësishme.
Shkruajeni kërkesën në një fjali me folje brenda: një kopje rezervë përfundon dy herë më shpejt, ose një lidhje e rënë nuk e përfundon një sesion. Objektivat e paqarta prodhojnë dizajne që askush nuk mund t'i pranojë ose t'i refuzojë. Pastaj vendosni çfarë mund të jetë skaji i largët, sepse opsioni më i lirë është shpesh ai që nuk kërkon asgjë të re atje. Ai kufizim eliminon shumicën e pretendimeve të broshurës përpara mbledhjes së parë.
Mbani tre premtimet të ndara në dokumentin e kërkesave. Një dizajn që pretendon të treja zakonisht jep një dhe supozon në heshtje të tjerat. Seksioni tjetër teston cila jepet në të vërtetë.
Testoni një transferim dhe shumë, pastaj hiqni një lidhje
Krahasoni një transferim të vazhdueshëm me disa transferime paralele drejt të njëjtit destinacion, dhe regjistroni humbjen, vonesën dhe përdorimin për çdo lidhje. Fitimi vetëm me sesione paralele tregon shpërndarje të rrjedhave, jo grumbullim të një rrjedhe. Testoni veçmas humbjen e një lidhjeje lart, sepse kapaciteti ndërsa të dy lidhjet punojnë nuk thotë asgjë për kalimin për një sesion të vendosur. Regjistroni rrugën, socket-in dhe numëruesit e ritransmetimit para dhe pas çdo testi.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Kur transferimi i vetëm përdor ende një lidhje lart, dizajni bën saktësisht atë që nënkupton një hash rrjedhe. Kur transferimet paralele shpërndahen në të dyja, balancimi punon dhe grumbullimi jo. Regjistroni cilën nga tre premtimet dizajni mban vërtet, dhe biseda e radhës për kapacitetin fillon me prova, jo me një pretendim furnizuesi.