મોટા ડાઉનલોડ્સ વિરુદ્ધ VPN: વિનંતી પર જ પાથ પસંદ કરો

“મોટા ડાઉનલોડ્સને VPNની આસપાસ મોકલો અને નાના પ્રતિસાદ તેના પર રાખો” એ રાઉટિંગ નીતિ જેવું લાગે છે, પણ તે નથી. રાઉટર તે ક્ષણે ઉપલબ્ધ માહિતીથી નિર્ણય લે છે: સરનામાં, પોર્ટ, પ્રોટોકોલ, firewall ચિહ્નો, ઓળખાયેલ પ્રવાહ. પ્રતિસાદનું અંતિમ કદ તે સમૂહમાં નથી, કારણ કે તે હજી આવ્યું નથી, અને રાઉટર જ્યારે બાઇટ માપી શકે ત્યારે તે તેમને વહન કરી રહ્યું હોય છે. જો તમે કાર્ય પ્રમાણે માર્ગદર્શન ઈચ્છો છો, તો નિર્ણય એવા બિંદુ પર જવો જોઈએ જે કાર્યને જાણે છે, અને નીચેની ચેકલિસ્ટ બતાવે છે કે તમારી રચનામાં એવું બિંદુ છે કે નહીં.

રાઉટર પ્રતિસાદનું કદ કેમ માપી શકતું નથી

જે ક્ષણે પેકેટને માર્ગની જરૂર પડે છે, ત્યારે રાઉટરે પ્રવાહના વધુમાં વધુ પ્રથમ થોડા પેકેટ જોયા હોય છે. તે કહી શકે છે કે કોણ કોની સાથે વાત કરે છે, કયા પ્રોટોકોલ પર, કયા ચિહ્ન સાથે, અને અત્યાર સુધી કેટલા બાઇટ ગયા છે. અત્યાર સુધીના બાઇટ ભૂતકાળ વર્ણવે છે. પ્રતિસાદનું કદ એ હજી ન બનેલા પ્રતિસાદનો ગુણધર્મ છે, અને ટુકડાઓમાં કે સ્ટ્રીમિંગ પ્રતિસાદમાં તે કદાચ પહેલાથી ક્યારેય જાણી શકાય નહીં.

સ્વયં પ્રોટોકોલની મેટાડેટા પણ દેખાય તેનાથી નબળી છે. HTTP એવા પ્રતિસાદને મંજૂરી આપે છે જેની લંબાઈ શરીર પહેલાં જાહેર થતી નથી, અને એક વપરાશકર્તા-ક્રિયા ઘણી વિનંતીઓ પેદા કરી શકે છે જેમનો સંયુક્ત ખર્ચ કોઈ એક હેડર મૂલ્ય જેવો હોતો નથી. હેડરને કાર્યના કદ તરીકે લેવો એ રાઉટિંગ ભૂલ પહેલાં મોડેલિંગ ભૂલ છે.

ચકાસણી 1: શું એવું નિર્ણય-બિંદુ છે જે પાથ પસંદ કરી શકે?

જે ઘટક પસંદગી કરશે તેનું નામ આપો, અને પછી કહો કે પસંદગીની ક્ષણે તે શું જાણે છે. દસ્તાવેજીકૃત હોસ્ટ-સમૂહમાંથી લાવતું અપડેટર સ્થાનાંતરણ શરૂ થાય તે પહેલાં પોતાનો હેતુ જાણે છે. મેટાડેટા જોઈને પછી વિનંતી ખોલતી ડાઉનલોડ સેવા જોડાણ બનતા પહેલાં કાર્ય જાણે છે. સહયોગી proxy પોતાને રાઉટર દર્શાવ્યા વિના વિનંતી-સ્તરની નીતિ લાગુ કરી શકે છે અથવા પ્રતિસાદ કેશ કરી શકે છે.

જો જવાબ “ગેટવે” હોય, તો ચેકલિસ્ટ પહેલેથી નિષ્ફળ ગઈ છે. ગેટવે જાણીતા પ્રવાહોને લક્ષ્ય, ચિહ્ન કે ક્લાયન્ટ વિભાગ પ્રમાણે વર્ગીકૃત કરીને પ્રથમ પેકેટથી નિર્ધારિત માર્ગે મોકલી શકે છે, જે મંજૂર અપડેટર માટે ઘણી વખત પૂરતું હોય છે અને અજાણ્યા પ્રતિસાદ-કદ માટે કદી પૂરતું નથી.

ચકાસણી 2: મેટાડેટા ખરેખર તમને શું કહે છે?

એપ્લિકેશન-જાણકાર માર્ગદર્શન તેટલું જ સારું છે જેટલા સારા તે વાંચતા ક્ષેત્રો છે. HTTP નું અર્થવિજ્ઞાનમાં પ્રતિસાદ-લંબાઈના નિયમો એવા કિસ્સાઓને મંજૂરી આપે છે જ્યાં શરૂઆતમાં લંબાઈ ઉપલબ્ધ નથી, અને સામગ્રી-કોડિંગ સ્થાનાંતરિત બાઇટ-ગણતરીને રજૂઆતના કદથી અલગ બનાવે છે. તેથી હેડર થ્રેશોલ્ડ વટાવે ત્યારે પાથ બદલતી નીતિ અસંગત રીતે વર્તશે, અને મોટે ભાગે તે મોટા સ્થાનાંતરણોમાં જ જેને પકડવા માટે તે બનાવાઈ હતી.

એપ્લિકેશન મેટાડેટા જેને ટેકો આપી શકે તે કાર્ય વિશેનો નિર્ણય છે: આ વર્કફ્લો બલ્ક સિંક છે, આ ઇન્ટરેક્ટિવ છે, આ જાણીતા સ્રોતનું સોફ્ટવેર અપડેટ છે. તે ઉદ્દેશની ભાષામાં લખાયેલી નીતિ છે, અને પરીક્ષણ માટે પૂરતી સ્થિર છે. “આ પ્રતિસાદ ચાલીસ મેગાબાઇટ કરતાં મોટો હશે” એવી નીતિ નથી.

ચકાસણી 3: શું પ્રવાહ પહેલેથી જ છે?

પ્રવાહ માટે રાઉટિંગ જોડાણની ઓળખ બદલ્યા વિના બદલાઈ શકે છે, અને આ તફાવત સ્પષ્ટ રાખવા યોગ્ય છે. TCP જોડાણ તેના અંતિમ સરનામાં અને પોર્ટથી ઓળખાય છે, અને જો રાઉટિંગ કોષ્ટક તેમની નીચે બદલાય તો પેકેટ અલગ માર્ગ લઈ શકે છે. જે અદૃશ્ય રીતે બદલાઈ શકતું નથી તે નેટવર્ક સરનામાં-અનુવાદની સ્થિતિ છે: ટ્રાફિકને બીજા નિકાસ પર ખસેડવાથી સામાન્ય રીતે જાહેર સ્રોત ટ્યુપલ બદલાય છે, અને દૂરનો છેડો મેળ ખાતી સ્થિતિ વગર અલગ સાથી જોશે.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

તેથી વ્યવહારુ નિયમ એ છે કે જોડાણની વચ્ચે એક નિકાસથી બીજા પર ખસેડવું નવો સંબંધ છે, સ્થળાંતર નથી. જો રચના માંગે કે એ જ જોડાણ ચાલુ રહે, તો નિર્ણય પ્રથમ SYN પહેલાં લેવો પડ્યો હોત, અને પછી ઉમેરાયેલો કોઈ પેકેટ-નિયમ તેને ચોખ્ખી રીતે ફરી ન બનાવી શકે.

ચકાસણી 4: ખરી જરૂરિયાત વિલંબ છે, નિકાસ નહીં?

“બલ્ક ટ્રાફિક બીજે મોકલો” એવી ઘણી બધી વિનંતીઓ વાસ્તવમાં ફરિયાદો છે કે મોટું સ્થાનાંતરણ ઇન્ટરેક્ટિવ કામ ધીમું લાગે છે. તે શેડ્યુલિંગ સમસ્યા છે, અને તેનો શેડ્યુલિંગ જવાબ છે: હાલના પાથ પર ન્યાયી કતાર અથવા સમર્થિત બેન્ડવિડ્થ નીતિ બલ્ક પ્રવાહને ચેટ સંદેશને ભૂખ્યો રાખતું અટકાવે છે, બંનેમાંથી કોઈને ખસેડ્યા વિના.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

આમ લક્ષણને સંબોધવાથી નિકાસ-નિર્ણય ત્યાં જ રહે છે જ્યાં સુરક્ષા નીતિએ તેને મૂક્યો હતો, અને તે એક આદેશથી ઉલટાવી શકાય છે. આખા ટ્રાફિક-વર્ગ માટે નિકાસ બદલવો એ પ્રમાણીકરણ, લોગિંગ અને પ્રવેશ-નિયમોની અસરો સાથેનો નીતિ પરિવર્તન છે, તેથી વિલંબની ફરિયાદ માટે તે પહેલું સાધન ન હોવું જોઈએ.

જો જરૂરિયાત ખરેખર અલગ ઇન્ટરનેટ નિકાસ હોય, તો તે શબ્દોમાં કહો અને સમર્થિત સીમા પર અમલમાં મૂકો: મંજૂર વર્કફ્લોમાંથી નવું જોડાણ, અથવા એવી એપ્લિકેશન જે પસંદ કરેલા નિકાસ દ્વારા પોતાની વિનંતી ખોલે. પછી નોંધો કે કયા કાર્યો કયો નિકાસ વાપરે છે, જેથી આગલી વ્યક્તિએ તેને રાઉટિંગ કોષ્ટકમાંથી અનુમાન કરવું ન પડે.

ફેરફાર-નોંધમાં ચેકલિસ્ટ રાખો: નિર્ણય-બિંદુ, તેને ચલાવતું ક્ષેત્ર કે કાર્ય, પ્રવાહ પહેલેથી છે કે નહીં, અને માપેલું લક્ષણ વિલંબ હતું કે નિકાસ. ચાર પ્રશ્નો, અને ચારેયના જવાબ આપતી નીતિ એ છે જેને તમે સંભાળી શકો, માત્ર બચાવી નહીં.