બે અપલિંક પણ એક ટનલ: ફેલઓવર, સંતુલન કે બોન્ડિંગ
ફેલઓવર, પ્રતિ-ફ્લો સંતુલન અને એક જ ફ્લોનું એકત્રીકરણ એ ત્રણ અલગ વચનો છે. બે ડિફોલ્ટ રૂટ તમને પ્રથમ આપે છે, બાકીના બે નહીં.
બે ઇન્ટરનેટ લાઇન VPN ને વધુ ઉપલબ્ધ બનાવી શકે છે, અને કેટલાક કાર્યભાર માટે તેને ઝડપી પણ બનાવી શકે છે, પરંતુ કઈ બાબત બનશે તે મિકેનિઝમ નક્કી કરે છે. બે ડિફોલ્ટ રૂટ ધરાવતું રાઉટર બોન્ડેડ નથી, અને હજારો આંતરિક જોડાણો વહન કરતી ટનલ હજી પણ એક બાહ્ય ફ્લો છે. વચનને પહેલા નામ આપવું એ ડિઝાઇન અને ખર્ચાળ નિરાશા વચ્ચેનો ફરક છે. નીચેનું કોષ્ટક વિકલ્પોને એ અનુસાર અલગ પાડે છે કે દરેકને દૂરના છેડે શું જોઈએ છે અને લિંક ગઈ ત્યારે ટ્રાન્સફર સાથે શું થાય છે.
ત્રણ વચનો, અને ફક્ત એકને ભાગીદાર જોઈએ
ફેલઓવર પસંદગીની લિંક ગયા પછી પણ માર્ગ ઉપલબ્ધ રાખે છે. ફ્લો-હેશ સંતુલન સ્વતંત્ર ફ્લોને બંને અપલિંક પર ફેલાવે છે. એક-ફ્લો એકત્રીકરણ એક ટ્રાન્સફરને એક સાથે બંને લિંક વાપરવા દે છે. આ અલગ જરૂરિયાતોવાળા અલગ ઉત્પાદનો છે, અને ફક્ત છેલ્લાને તમારા રાઉટરની બહારની કોઈ વસ્તુના સહયોગની જરૂર છે.
| 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 |
તે કોષ્ટકમાં કંઈ પણ બીજી લાઇન ખરીદવાનું કારણ નથી. તે જે કરે છે તે એ છે કે ફેલઓવર ડિઝાઇનને બોન્ડિંગ ગણીને મૂલ્યાંકન કરવાથી રોકે છે.
રાઉટરને ટનલ એક જ ફ્લો કેમ લાગે છે
લોડ સંતુલિત કરતું રાઉટર સ્રોત અને લક્ષ્ય સરનામાંને પોર્ટ સાથે હેશ કરે છે અને પછી આખો ફ્લો જ્યાં હેશ દર્શાવે છે ત્યાં મોકલે છે. રાઉટરની દૃષ્ટિએ VPN ટનલ એવો જ એક ફ્લો છે, અંદર શું ચાલે તે ગમે તે હોય. આંતરિક જોડાણો ક્યારેય હેશના નિર્ણય સુધી પહોંચતા નથી, કારણ કે બાહ્ય હેડર પહેલેથી માર્ગ નક્કી કરી ચૂક્યું છે. તેથી જ બીજી અપલિંક ઘણા વપરાશકર્તાઓ માટે કુલ ક્ષમતા બમણી કરી શકે છે અને એક વપરાશકર્તાના મોટા ટ્રાન્સફરમાં કંઈ બદલતી નથી.
બે અલગ ટનલ તમને બે ઉમેદવાર આપી શકે છે, પરંતુ તેમને હજી પણ એક જાણી જોઈને બનાવેલી નીતિની જરૂર છે જે ટ્રાફિક સોંપે અને વિનંતી લઈ ગયેલા માર્ગ પર જ જવાબો રાખે. એ પગલું છોડી દેવાનું સામાન્ય પરિણામ અસમમિત રાઉટિંગ છે. ફ્લો, પસંદગીની લિંક અને બેકઅપ લિંકનાં નામ આપતી નીતિ એ ન્યૂનતમ છે.
ઇથરનેટ બોન્ડિંગ અસંબંધિત પ્રદાતાઓ સુધી પહોંચતું નથી, કારણ કે દૂરના છેડે એકત્રીકરણ પ્રોટોકોલમાં ભાગ લેવો પડે છે. સહયોગી અંતિમ બિંદુ ન હોય તો બે ISP વચ્ચેનું બોન્ડિંગ સંશોધન પ્રોજેક્ટ છે.
મલ્ટિપાથ TCP ને બંને છેડે શું જોઈએ
Linux નું Multipath TCP દસ્તાવેજીકરણ એક જોડાણ સાથે જોડાયેલા અનેક સબફ્લોનું વર્ણન કરે છે. એક છેડે કર્નલ સપોર્ટ પોતાના આપ કંઈ બદલતું નથી, કારણ કે સાથીને પણ એ સબફ્લો સ્વીકારવા પડે છે. દૂરના છેડે પ્રોક્સી બીજી સામાન્ય ગોઠવણ છે, અને તે પોતાની ક્ષમતા અને ઉપલબ્ધતા સાથેનું ઘટક બની જાય છે જેની યોજના કરવી પડે. એ જ તર્ક WireGuard માટે સહેલો જવાબ બાકાત કરે છે, જેનું પરિવહન UDP છે: MPTCP TCP સબફ્લો વધારે છે અને ડિઝાઇનમાં બીજું કંઈ વિના એ ટનલનું એકત્રીકરણ કરી શકતું નથી.
કર્નલ સુવિધા ચાલુ છે કે નહીં તે તેની આસપાસ ડિઝાઇન કરતા પહેલા તપાસો, કારણ કે ઘણા વિતરણો તેને બંધ સ્થિતિમાં આપે છે. આ ત્રણ આદેશો એક મિનિટમાં તેનો જવાબ આપે છે.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showબ્રોશર નહીં, કાર્યભાર પ્રમાણે પસંદ કરો
જો કાર્યભાર ઘણા સ્વતંત્ર સત્રો હોય, તો ફ્લો-હેશ સંતુલન દૂરના છેડાના સહયોગ વિના ક્ષમતા ઉમેરી શકે છે. જો એક મોટું ટ્રાન્સફર હોય, તો ફક્ત એકત્રીકરણની ડિઝાઇન જ મદદ કરશે, અને તે ડિઝાઇનને સહયોગી સાથી જોઈએ. જો જરૂરિયાત એ હોય કે લિંક મરે ત્યારે પણ કામ ચાલુ રહે, તો જવાબ ફેલઓવર છે અને એક ટ્રાન્સફરનું થ્રુપુટ અપ્રસ્તુત છે.
જરૂરિયાતને ક્રિયાપદવાળા એક વાક્યમાં લખો: એક બેકઅપ બમણું ઝડપી પૂરું થાય છે, અથવા પડી ગયેલી લિંક સત્ર સમાપ્ત કરતી નથી. અસ્પષ્ટ લક્ષ્યો એવી ડિઝાઇન પેદા કરે છે જેને કોઈ સ્વીકારી કે નકારી શકતું નથી. પછી નક્કી કરો કે દૂરનો છેડો શું હોઈ શકે, કારણ કે સૌથી સસ્તો વિકલ્પ ઘણી વાર એ હોય છે જે ત્યાં કંઈ નવું માગતો નથી. એ મર્યાદા પ્રથમ બેઠક પહેલા જ બ્રોશરના મોટા ભાગના દાવા દૂર કરે છે.
જરૂરિયાત દસ્તાવેજમાં ત્રણેય વચનો અલગ રાખો. ત્રણેયનો દાવો કરતી ડિઝાઇન સામાન્ય રીતે એક આપે છે અને બાકીનાં ચૂપચાપ ધારી લે છે. આગળનો વિભાગ કયું ખરેખર અપાય છે તે ચકાસે છે.
એક ટ્રાન્સફર અને ઘણાં ચકાસો, પછી એક લિંક ખેંચો
એક સતત ટ્રાન્સફરને એ જ લક્ષ્ય પરનાં અનેક સમાંતર ટ્રાન્સફર સાથે સરખાવો, અને દરેક માટે નુકસાન, વિલંબ અને પ્રતિ-લિંક વપરાશ નોંધો. ફક્ત સમાંતર સત્રોમાં લાભ થાય તો તે ફ્લો વિતરણ તરફ સંકેત કરે છે, એક-ફ્લો એકત્રીકરણ તરફ નહીં. એક અપલિંકનું નુકસાન અલગથી ચકાસો, કારણ કે બંને લિંક ચાલુ હોય ત્યારની ક્ષમતા સ્થાપિત સત્ર માટે ફેલઓવર વિશે કંઈ કહેતી નથી. દરેક પરીક્ષણ પહેલાં અને પછી માર્ગ, સોકેટ અને ફરી-મોકલવાના કાઉન્ટર કેપ્ચર કરો.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5જ્યારે એક જ ટ્રાન્સફર હજી પણ એક અપલિંક વાપરે છે, ત્યારે ડિઝાઇન બરાબર એ જ કરે છે જે ફ્લો હેશ સૂચવે છે. જ્યારે સમાંતર ટ્રાન્સફર બંને પર ફેલાય છે, ત્યારે સંતુલન કામ કરે છે અને એકત્રીકરણ નહીં. ડિઝાઇન ત્રણમાંથી કયું વચન ખરેખર પાળે છે તે નોંધો, અને આગલી ક્ષમતાની વાતચીત વિક્રેતાના દાવા નહીં, પુરાવા સાથે શરૂ થશે.