શું નાનું VPN MTU ઝડપી છે? વાસ્તવિક પુરાવાની તુલના કરો
નીચું MTU માર્ગની મર્યાદાને ટાળી શકે અને તેમ છતાં થ્રુપુટનો ખર્ચ કરે. ફેરફાર રાખતા પહેલાં વાસ્તવિક મર્યાદા, પેકેટનો ઓવરહેડ અને કામનો ભાર સરખાવો.
ટનલ મોટા ટ્રાન્સફર છોડી દે છે પણ પિંગ પસાર કરે છે, તેથી સલાહ ઝડપથી આવે છે: MTU ઘટાડો. સુધારો ક્યારેક કામ કરે છે, અને પછી તે દરેક નેટવર્ક પરના દરેક પ્રોફાઇલ પર લાગુ થાય છે. તે જ બિંદુએ લક્ષિત સમારકામ કાયમી કાર્યક્ષમતા-કર બની જાય છે. જે સરખામણી કરવાની છે તે માર્ગની વાસ્તવિક મર્યાદા અને તેની નીચે દરેક પેકેટ નાનું કરવાના ખર્ચ વચ્ચેની છે.
MTU ઘટાડતા ખરેખર શું સંકોચાય છે
દરેક પેકેટ તમારા ડેટા પહેલાં હેડર વહન કરે છે. 1500 બાઇટના ઇથરનેટ માર્ગ પર, IPv4 અને TCP 40 બાઇટ વાપરે છે અને પેલોડ માટે 1460 છોડે છે; એન્કેપ્સ્યુલેશન ઉપર બહારના IP, UDP અને ટનલ હેડર ઉમેરે છે, તેથી આંતરિક પેલોડ બજેટ ફરી ઘટે છે. ઇન્ટરફેસનું MTU ઘટાડવું તે બજેટને જાણી જોઈને નાનું કરે છે.
ખર્ચ બાઇટની સંખ્યા સાથે નહીં, પેકેટની સંખ્યા સાથે પ્રમાણસર છે. એ જ ફાઇલ વધુ પેકેટમાં વહેંચાય તો વધુ વિક્ષેપ, વધુ રૂટિંગ નિર્ણય અને માર્ગ પરના દરેક ઉપકરણ પર વધુ પેકેટ-દીઠ પ્રોસેસિંગ જોઈએ. જે રાઉટર પહેલેથી સેકન્ડ-દીઠ પેકેટ મર્યાદાની નજીક છે, ત્યાં તે રાઉન્ડિંગ ભૂલ નહીં, વાસ્તવિક ધીમાપણું છે. ટ્રાન્સફર પોતે સફળ થાય ત્યારે પણ ખર્ચ દેખાય છે.
તેથી જ નાનું MTU મર્યાદાની આસપાસનો વળતો રસ્તો છે, સામાન્ય ઓપ્ટિમાઇઝેશન નહીં. તે મોટી ફ્રેમ વહન કરી શકે નહીં તેવા માર્ગ સામે વિશ્વસનીયતા ખરીદે છે, અને જે પેકેટને ઘટાડાની જરૂર ન હતી તે દરેક પર ઓવરહેડ વસૂલે છે.
ક્યારે નાનું MTU યોગ્ય સુધારો છે
ઉત્તમ લક્ષણ ચોક્કસ છે: TCP હેન્ડશેક પૂરો થાય છે, નાના પ્રતિભાવ આવે છે, અને મોટું ડાઉનલોડ અટકી જાય અથવા રીસેટ થાય છે. 1472 બાઇટ પર ન-ફ્રેગમેન્ટ બિટ સાથેનું પિંગ નિષ્ફળ જાય છે જ્યારે 1400 બાઇટનું પિંગ સફળ થાય છે, જે એવા માર્ગ તરફ ઇશારો કરે છે જે પૂર્ણ-માપનું પેકેટ વહન કરી શકતો નથી અને પ્રેષકને નાનું કરવા કહેતો ICMP સંદેશ પહોંચાડતો નથી.
માર્ગના MTUની શોધ તે ICMP ફ્રેગમેન્ટેશન-જરૂરી સંદેશાઓ પર આધાર રાખે છે. જ્યારે ફાયરવોલ તેમને ફેંકી દે છે, ત્યારે પ્રેષક મોટું પેકેટ ફરી ફરી પ્રયત્ન કરે છે અને કનેક્શન અટકેલું લાગે છે. ટનલની બાજુ પર MTU ઘટાડવું પુનરાવર્તન ટાળે છે, અને તે તે નેટવર્ક માટે કાયદેસર સમારકામ છે.
એક્સેસ ટેક્નોલોજીઓ પણ પોતાની મર્યાદા મૂકે છે: PPPoE સામાન્ય રીતે 1492 પર મર્યાદિત થાય છે, કેટલાક મોબાઇલ અને DSL માર્ગ નીચા હોય છે, અને નેસ્ટેડ ટનલ ઓવરહેડ બે વાર બાદ કરે છે. માર્ગદર્શિકામાંથી સંખ્યા નકલ કરવાને બદલે વાસ્તવિક માર્ગ માપો, અને યાદ રાખો કે IPv6 તેને વહન કરતી કોઈપણ લિંક પર ઓછામાં ઓછું 1280 બાઇટ MTU માગે છે, જેમ RFC 8200 નિર્દિષ્ટ કરે છે.
એક બદલતા પહેલાં ત્રણ નિયંત્રણો સરખાવો
MTU, MSS અને ફ્રેગમેન્ટેશન વિવિધ સ્તરોના વિવિધ નિયંત્રણો છે, અને ખોટું બદલવાથી લક્ષણ તેની જગ્યાએ જ રહે છે.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS મર્યાદિત કરવું ઘણી વાર સૌથી ઓછું આક્રમક સમારકામ છે, કારણ કે તે ફક્ત TCP પર અસર કરે છે અને ઇન્ટરફેસને બીજા ટ્રાફિક માટે મુક્ત રાખે છે. નીચું ઇન્ટરફેસ MTU વધુ વિશાળ અને વિચારવામાં સરળ છે, તેથી તે ગ્રાહક રાઉટરોમાં સામાન્ય છે, પરંતુ તે એક પ્રોટોકોલની સમસ્યાનું બિલ દરેક પ્રોટોકોલને કરે છે.
ન-ફ્રેગમેન્ટ વર્તન બંધ કરવું ફ્રેગમેન્ટેશનને મંજૂરી આપીને લક્ષણ છુપાવે છે, અને તે સામાન્ય રીતે વિલંબને વધુ ખરાબ કરે છે જ્યારે સાચું માપ શોધી શકે તેવો પ્રતિસાદ તોડે છે. કાયમી ઉકેલ તરીકે તેનાથી બચો.
એક સંખ્યાને બદલે વેપાર-બંધારણ માપો
ન-ફ્રેગમેન્ટ પ્રોબ વડે માર્ગની મર્યાદા શોધો, ઊંચાઈથી શરૂ કરો અને જવાબ ન આવે ત્યાં સુધી નીચે ઉતરો:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10પછી બંને સેટિંગ્સ પર વાસ્તવિક કાર્ય સરખાવો: એ જ ફાઇલ ટ્રાન્સફર, એ જ એન્ડપોઇન્ટ અને એ જ નેટવર્ક. પૂર્ણ થવાનો સમય અને પુનઃપ્રેષણ નોંધો, ઉદાહરણ તરીકે nstat -az TcpRetransSegs વડે, અને જો ટનલ નાના રાઉટર પર પૂરી થાય તો ઉપકરણનું CPU જુઓ. ટૂંકી કૃત્રિમ થ્રુપુટ કસોટી એ અટકી જવાનું ચૂકી શકે છે જે થોડા મેગાબાઇટ પછી જ દેખાય છે.
ઘટાડા પછી પેકેટ કાઉન્ટર વધશે, કારણ કે એ જ ટ્રાન્સફર હવે વધુ પેકેટ વાપરે છે. તે અપેક્ષિત છે અને ઊંચા થ્રુપુટનો પુરાવો નથી. પૂર્ણ થયેલ એપ્લિકેશન ડેટા, પુનઃપ્રેષણની સંખ્યા અને પ્રતિભાવક્ષમતા સરખાવો, ફક્ત પેકેટ દર નહીં.
ફેરફાર તબક્કાવાર દાખલ કરો અને તેને મર્યાદિત રાખો
મૂળ મૂલ્ય નોંધો, એક નિયંત્રણ બદલો, અને તેને કાયમી બનાવતા પહેલાં માપનું પુનરાવર્તન કરો. જો પુરાવો લાભ ન દર્શાવે, તો અગાઉનું મૂલ્ય તે જ ઇન્ટરફેસ આદેશ વડે પુનઃસ્થાપિત કરો જે તમે તેને સેટ કરવા વાપર્યો હતો:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500પરિણામને તે જ નેટવર્ક સુધી મર્યાદિત રાખો જેને તેની જરૂર હતી. હોટેલ Wi-Fi, મોબાઇલ હોટસ્પોટ અને ઓફિસ LAN પર કામ કરવું પડે તેવી પ્રોફાઇલને તેમાંથી કોઈને જરૂરી હોય તે સૌથી નીચું મૂલ્ય વારસામાં ન મળવું જોઈએ, સિવાય કે ક્લાઇન્ટ માર્ગ શોધી શકતું ન હોય.
સાચું મૂલ્ય એ માર્ગ પર ટકી રહેતું સૌથી મોટું MTU છે, લક્ષણ દૂર કરતું સૌથી નાનું નહીં. માર્ગ, પ્રોબનું પરિણામ અને રોલબેક દસ્તાવેજ કરો, અને એક્સેસ નેટવર્ક બદલાય ત્યારે સેટિંગ ફરી તપાસો.