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.20

1472 பைட் பேலோடு சுத்தமான 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 இன் பிரிவு-அளவு திருத்தத்தை ஒருபோதும் பெறுவதில்லை. டிக்கெட்டில் அசல் மதிப்புகளை வைத்திருங்கள், ஏனெனில் மீளமுடியாத பழுதுநீக்கம் நடக்கக் காத்திருக்கும் இரண்டாவது பிரச்சினை. அளவு சோதனை தேர்ச்சி பெற்றும் பதிவேற்றம் தொடர்ந்து நின்றால், கருங்குழியே காரணம் அல்ல, மாற்றத்தை விரிவுபடுத்துவதற்குப் பதிலாக விசாரணை முன்னேற வேண்டும்.