MTU કાળો કૂવો: નાની વિનંતીઓ કેમ કામ કરે છે પણ અપલોડ અટકી જાય છે
નાની વિનંતીઓ પૂરી થાય છે જ્યારે મોટું અપલોડ કાયમ માટે લટકી રહે છે, અને મોકલનારને ક્યારેય ખબર પડતી નથી કે માર્ગ સાંકડો છે. જ્યાં તે તૂટે છે તે ચોક્કસ કદ માપો.
પૃષ્ઠ લોડ થાય છે, નાનો API કૉલ પાછો આવે છે, અને પછી ફાઇલ અપલોડ ક્લાયન્ટ હાર માને ત્યાં સુધી લટકી રહે છે. સર્વર લોગમાં કંઈ પણ આ સમજાવતું નથી, કારણ કે પેકેટો માર્ગની વચ્ચે ફેંકી દેવાયા હતા, કોઈ ઉપયોગી જવાબ પાછો મોકલ્યા વિના. એ પેટર્ન MTU કાળો કૂવો છે: મોકલનાર ધારે તેના કરતાં સાંકડી કડી, સાથે એ કહેવાનો શાંત ઇનકાર. જે કદ નિષ્ફળ જાય છે તે પુનરાવર્તિત છે, અને એ જ તેને નિદાનપાત્ર બનાવે છે.
કૂવાને કાળો શું બનાવે છે
દરેક કડીમાં મહત્તમ પ્રસારણ એકમ હોય છે, અને આગલા હોપની મર્યાદા કરતાં મોટું પેકેટ કાં તો ટુકડાઓમાં વિભાજિત કરવું પડે અથવા એ કહેતા ICMP સંદેશ સાથે નકારવું પડે. પાથ MTU શોધ એ સંદેશ પહોંચે અને તેનું પાલન થાય તેના પર આધાર રાખે છે. તેને ફિલ્ટર કરવાથી કે અવગણવાથી મોકલનાર એવું પેકેટ ફરી ફરી મોકલતો રહે છે જે ક્યારેય બેસી શકે નહીં.
એન્કેપ્સ્યુલેશન આને VPNની આસપાસ સામાન્ય બનાવે છે, કારણ કે ટનલ ભૌતિક કડી માટે પહેલેથી માપેલા પેકેટમાં બહારનું હેડર ઉમેરે છે. અંદરનું પેકેટ 1500 બાઇટ પર માન્ય છે અને એન્કેપ્સ્યુલેટેડ પેકેટ નથી, તેથી તે સીમા પર મરી જાય છે જ્યારે નાના પેકેટો પસાર થઈ જાય છે. પૂર્ણ થયેલો હેન્ડશેક અને કામ કરતું લોગિન પૃષ્ઠ ફક્ત એ સાબિત કરે છે કે નાના પેકેટો કામ કરે છે. એપ્લિકેશન જે સૌથી મોટું પેકેટ મોકલવા પ્રયત્ન કરે છે તે જ મહત્ત્વનું છે.
જ્યાં તે તૂટે છે તે કદ શોધો
ફ્રેગમેન્ટ ન કરવાની કસોટી સાથે પેલોડનું કદ દ્વિભાજ્ય રીતે શોધો, ટનલની એક બાજુના હોસ્ટથી બીજી બાજુના હોસ્ટ સુધી. જે સૌથી મોટું પેલોડ સફળ થાય છે તે તમારું વપરાયોગ્ય પાથ MTU માંથી હેડરનો ઓવરહેડ બાદ કરીને છે.
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.201472 બાઇટનું પેલોડ સ્વચ્છ 1500 બાઇટના Ethernet માર્ગ પર સફળ થાય છે, જ્યારે IPv4 અને ICMP હેડરોના 28 બાઇટ ઉમેરવામાં આવે છે. જ્યારે એ જ કસોટી ટનલ ચાલુ થયા પછી ફક્ત નાના પેલોડ પર સફળ થાય, ત્યારે તફાવત એન્કેપ્સ્યુલેશનનો ઓવરહેડ છે, અને ટનલની સીમા એ જ જગ્યા છે જ્યાં નકાર સંદેશ પેદા થવો જોઈતો હતો. જોડાણ પહેલાં અને પછી બંને સંખ્યાઓ નોંધો, કારણ કે એ જોડી જ પુરાવો છે. એપ્લિકેશન IPv6 વાપરે ત્યારે તેના માટે કસોટી પુનરાવર્તિત કરો, કારણ કે હેડર મોટું છે અને નિષ્ફળતાની મર્યાદા ખસે છે.
ટનલને દોષ આપતા પહેલાં પુરાવા વાંચો
દૂરસ્થ એપ્લિકેશનની ભૂલો, ભીડ અને સામાન્ય નુકસાન પણ અપલોડ અટકાવે છે, તેથી એક નિષ્ફળ સ્થાનાંતરણ કાળા કૂવાને ઓળખતું નથી. તેમને અલગ પાડે છે કદનો સંબંધ: 1200 બાઇટ પર પુનરાવર્તિત સફળતા અને 1400 બાઇટ પર પુનરાવર્તિત અટકાવ, એ જ દિશામાં, એ જ અંતિમ બિંદુ દ્વારા.
બંને છેડે કેપ્ચર દર્શાવે છે કે મોટા પેકેટો નીકળી જાય છે અને ક્યારેય પહોંચતા નથી, વચ્ચે કોઈ નકાર વિના. એ જ ક્ષણ છે જ્યારે સર્વરને બદલે સીમા ઉપકરણ તરફ જોવું જોઈએ, જે પોતાને ખરેખર મળતી દરેક વિનંતીનો જવાબ આપે છે. ભીડ પણ અટકાવે છે, પણ તે જુદા જુદા સમયે જુદા જુદા કદ અટકાવે છે, જે જુદી સહી છે.
બંને પરિવહન પર સુધારો ચકાસો
સમર્થિત સુધારો એ છે કે સીમાને સાચી મર્યાદા જણાવવા દેવી, અથવા ત્યાં TCPના મહત્તમ સેગમેન્ટ કદને ક્લેમ્પ કરવું જેથી કોઈ વધુ પડતું સેગમેન્ટ અજમાવવામાં ન આવે. નેટવર્ક પરનું દરેક MTU ઘટાડવું, અથવા ફાયરવોલ બંધ કરવું, લક્ષણને છુપાવે છે અને એવી ગોઠવણી છોડે છે જેના વિશે પછી કોઈ તર્ક કરી શકશે નહીં.
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20એ જ કદ કસોટીથી ચકાસો, પછી જે એપ્લિકેશન નિષ્ફળ ગઈ તેનાથી, અને બીજું પ્રોટોકોલ પણ તપાસો, કારણ કે UDP એપ્લિકેશનોને TCPનું સેગમેન્ટ-કદ સુધારણા ક્યારેય મળતું નથી. ટિકિટમાં મૂળ મૂલ્યો રાખો, કારણ કે જે સુધારો ઉલટાવી શકાતો નથી તે બનવાની રાહ જોતી બીજી સમસ્યા છે. જો કદ કસોટી પાસ થાય અને અપલોડ હજુ પણ અટકે, તો કાળો કૂવો કારણ નહોતો, અને તપાસ ફેરફારને વિસ્તારવાને બદલે આગળ વધવી જોઈએ.