OpenVPN TCP પર: rto_min કતારની શરૂઆતની અડચણ દૂર કરતું નથી

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

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

લક્ષણ: બધું એકસાથે અટકે છે

બે આંતરિક કનેક્શન એકસાથે અટકવા એ જ સુરાગ છે. ધીમું ડાઉનલોડ અને ધીમું શેલ અલગ ક્રમ-સંખ્યાઓ અને અલગ ભીડ-સ્થિતિ ધરાવતી અલગ TCP વાતચીતો છે, તેથી એકમાંની ખામી બીજને અડવી ન જોઈએ. જ્યારે તે એક જ લયમાં અટકે છે, ત્યારે તેમની ઉપર કંઈક તેમના બાઇટને ગોઠવે છે.

એ કંઈક ટનલનું પરિવહન સ્તર છે. TCP મોડમાં OpenVPN એન્કેપ્સ્યુલેટેડ પેકેટને સાથી તરફના એક જ TCP કનેક્શનમાં લખે છે, અને TCPનો કરાર એક જ બાઇટ પ્રવાહની ક્રમિક ડિલિવરી છે. પછીના બાઇટ ખૂટતા બાઇટ પહેલાં એપ્લિકેશનને આપવામાં આવતા નથી, તે કોઈ પણ આંતરિક વાતચીતના હોય.

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

એક બાહ્ય બાઇટ પ્રવાહ, ઘણી આંતરિક વાતચીતો

ટનલ એક સાથે ડાઉનલોડ અને શેલ વહન કરે છે એવી કલ્પના કરો. બાહ્ય કનેક્શનનો એક સેગમેન્ટ ખોવાય છે. પછીના સેગમેન્ટ સ્વીકારક હોસ્ટ સુધી પહોંચી શકે છે, અને સ્વીકારક TCP સ્ટેક તેમને સ્વીકારશે, પણ ખાલી જગ્યા ભરાય ત્યાં સુધી તેમને ઉપર આપી શકતું નથી. તેથી OpenVPN પાસે શેલ માટે વાંચવા જેવું કંઈ નથી, શેલના પોતાના બાઇટ ઘણા સમય પહેલા આવ્યા હોવા છતાં.

આ એક કનેક્શનની અંદર કતારની શરૂઆતની અડચણ છે, અને તે માટે બે એપ્લિકેશનને આંતરિક કનેક્શન વહેંચવાની જરૂર નથી. તે બાહ્ય કનેક્શન વહેંચે છે, અને તે પૂરતું છે.

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

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

લાંબો આંતરિક ટાઇમર કેમ મદદ કરી શકતો નથી

માર્ગ પર rto_min થી ન્યૂનતમ ફરી-મોકલવાની સમયમર્યાદા વધારવાથી તે માર્ગ વાપરતા સ્થાનિક રીતે ઉત્પન્ન થયેલા TCP ટ્રાફિક માટે ટાઇમર-આધારિત ફરી-મોકલવું મોકૂફ રહે છે. તે અસલી અસર ધરાવતું અસલી નોબ છે, અને તે પહેલા ક્રમને બદલે બીજા ક્રમની સમસ્યા સંભાળે છે.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

જે તે કરી શકતું નથી તે છે બાહ્ય બાઇટને ક્રમની બહાર મુક્ત કરવા, ખૂટતા સેગમેન્ટને ઝડપથી પુનઃપ્રાપ્ત કરવા, અથવા દૂરના એપ્લિકેશન સર્વરને એ જ ટાઇમર અપનાવવા મજબૂર કરવા. સ્વીકારક સ્ટેક હજી ક્રમમાં પહોંચાડે છે, અને દૂરના છેડાનો મોકલનાર હજી પોતાના ગોળ-પ્રવાસ માપન વાપરે છે.

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

બાર સેકન્ડનું સ્થિર તળિયું આ વિષયની સલાહમાં એમ દેખાય છે જાણે TCP ટનલનું અસ્તિત્વ તેને સૂચવે. RFC 6298 માં વર્ણવેલ ફરી-મોકલવાનો ટાઇમર માપેલા ગોળ-પ્રવાસ સમયમાંથી ઘાતાંકીય પીછેહઠ સાથે લેવાય છે, તેથી સ્થિર તળિયું ચોક્કસ માર્ગ માટે નીતિની પસંદગી છે, પ્રોટોકોલની જરૂરિયાત નહીં. વ્યાપકપણે લાગુ કરવામાં આવે તો તે લક્ષણને છુપાવે છે અને સાથે સાથે તે માર્ગ આવરી લેતા દરેક પ્રવાહની પુનઃપ્રાપ્તિ બદલે છે.

tcp-nodelay શું કરે છે અને શું નથી કરતું

પરિવહન સોકેટ પર Nagle શૈલીનું બફરિંગ બંધ કરતા ટનલ વિકલ્પનો હેતુ સાંકડો છે: તે નાના લેખનને મોકલતા પહેલા વધુ ડેટાની રાહ જોવાથી રોકે છે. એ ઇન્ટરેક્ટિવ ટ્રાફિકને બાકીના સ્વસ્થ માર્ગ પર વધારાના વિલંબથી બચવામાં મદદ કરે છે.

તે પરિવહનને અક્રમિક બનાવતું નથી, અને ખોવાયેલા સેગમેન્ટ પછીની પુનઃપ્રાપ્તિ ટૂંકી કરતું નથી. ફરી-મોકલવાની સમયમર્યાદા માટે અટકતું શેલ એ વિકલ્પ ચાલુ હોવા છતાં અટકશે, કારણ કે વિકલ્પે ક્રમનો નિયમ ક્યારેય અડ્યો નથી.

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

પરિવહનની ન્યાયી સરખામણી કેવી રીતે કરવી

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

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

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

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