tcpdump 64 KB பாக்கெட்டுகளைக் காட்டுகிறது: offload மற்றும் பிடிப்பு புள்ளி

ஹோஸ்ட்டில் பிடிப்பது 1420 MTU கொண்ட இடைமுகத்தில் 64 KB பாக்கெட்டைக் காட்டலாம், வெளிப்படையான முடிவு சுரங்கப்பாதை அதன் அளவு வரம்பை புறக்கணித்தது என்பதே. அந்த முடிவு பொதுவாக தவறானது. ஹோஸ்ட்டில் உள்ள பிடிப்பு புள்ளிகள் செயலாக்க பாதையின் உள்ளே உள்ளன, அங்கு பிரிவாக்கம், ஒருங்கிணைப்பு மற்றும் checksum வேலை இன்னும் நடந்திருக்காமல் இருக்கலாம். பாக்கெட்டின் அளவைப் படிப்பதற்கு முன் பார்வையாளரின் நிலையைப் படியுங்கள்.

எங்கு பிடிக்கிறீர்கள் என்பது நீங்கள் பார்ப்பதை மாற்றுகிறது

டிரான்ஸ்மிட் offload ஸ்டேக்கிற்கு பெரிய அலகை பிணைய சாதனத்திற்கு வழங்க அனுமதிக்கிறது, அது பின்னர் அதை கம்பி அளவு துண்டுகளாக வெட்டுகிறது. ரிசீவ் ஒருங்கிணைப்பு உள்நோக்கிய பாதையில் எதிர்மாறாக செய்கிறது, ஹோஸ்ட் பக்க பார்வையாளர் அவற்றைப் பார்க்கும் முன் பிரிவுகளை இணைக்கிறது. எனவே பிடிப்பு அந்த புள்ளியில் ஹோஸ்ட்டின் உள் பார்வையைப் பதிவு செய்கிறது, இணைப்பில் உள்ள பிரேம்கள் அவசியமில்லை. இரண்டு வழிமுறைகளும் சாதனம் மற்றும் பாதையைப் பொறுத்தது.

ethtool -k eth0 | grep -E 'tso|gso|gro'

அளவை குறையாகக் கருதும் முன் இரண்டாவது புள்ளியில் பிடியுங்கள், சிறந்தது ஒரு சுயாதீன ரிசீவர் அல்லது கண்ணாடி. பெரிய அலகு அனுப்பும் ஹோஸ்ட்டில் மட்டும் தோன்றினால், கம்பி அதை ஒருபோதும் சுமந்திருக்காது. இரண்டு கவனிப்பு புள்ளிகள் ஒரு கோப்பை விட வலிமையானவை, குறிப்பாக கேள்வி இயந்திரத்திலிருந்து உண்மையில் என்ன வெளியேறியது என்பதாக இருக்கும்போது.

உள் மற்றும் வெளி இடைமுகங்களைப் பிரிக்கவும்

சுரங்கப்பாதை அதன் சொந்த இடைமுகத்தைச் சேர்க்கிறது, மேலும் வெளி மற்றும் உள் பார்வைகள் என்கேப்சுலேஷன் மற்றும் செயலாக்கத்தில் வேறுபடுகின்றன. சுரங்கப்பாதை சாதனத்தில் பிடிப்பது உள் பாக்கெட்டைக் காட்டுகிறது; இயற்பியல் அடாப்டரில் பிடிப்பது வெளி பாக்கெட்டைக் காட்டுகிறது. அளவு, முகவரிகள் மற்றும் checksum நிலை ஆகியவை எந்தக் குறையுடனும் தொடர்பில்லாத காரணங்களால் அவற்றுக்கிடையே வேறுபடலாம்.

எந்த இடைமுகம் எந்தக் கோப்பை உருவாக்கியது என்பதைப் பதிவு செய்யுங்கள். சுரங்கப்பாதை சாதனத்தில் காணப்படும் அளவு உள் பாக்கெட்டை விவரிக்கிறது, அடாப்டர் இறுதியில் அனுப்பிய பிரேமை அல்ல. இரண்டையும் ஒரே பகுப்பாய்வில் கலப்பதே சாதாரண என்கேப்சுலேஷன் வேறுபாட்டை மர்மமாக மாற்றும் வழி.

checksum எச்சரிக்கையும் நிலை சார்ந்தது

அனுப்பும் பக்கத்தின் பிடிப்பு வன்பொருள் நிரப்புவதற்கு முன் checksum புலத்தைக் காட்டலாம், இது எந்த ரிசீவரும் ஒருபோதும் பார்க்காத எச்சரிக்கையை உருவாக்குகிறது. இது சேதமடைந்த பாக்கெட்டை தொலை ஹோஸ்ட் நிராகரிப்பதிலிருந்து வேறுபட்ட சான்று. திசை மற்றும் பிடிப்பு புள்ளியே இரண்டில் எது உங்களிடம் உள்ளது என்பதைத் தீர்மானிக்கின்றன.

உண்மையான பரிமாற்றம் தோல்வியடையும்போது, ரிசீவரில் அல்லது பாதையின் மற்றொரு புள்ளியில் கவனிப்புகளை ஒப்பிடுங்கள். திசை, இடைமுகம் மற்றும் என்கேப்சுலேஷன் அடுக்கை பதிவுடன் வைத்திருங்கள், ஏனெனில் அவை இல்லாத திரைப்படத்தை பின்னர் விளக்க முடியாது.

offload-ஐ கட்டுப்படுத்தப்பட்ட சோதனையாக மட்டும் அணைக்கவும்

offload-ஐ அணைப்பது செயல்திறன் மற்றும் பாக்கெட் செயலாக்கத்தை மாற்றுகிறது, எனவே விசித்திரமான அளவு காட்சிக்கு இது முதல் பதிலளிப்பு அல்ல. நீங்கள் சோதித்தால், ஒரு அமைப்பை மாற்றி முதலில் அடிப்படை நிலையைப் பதிவு செய்யுங்கள். MTU, ஃபயர்வால் விதிகள் மற்றும் கிளையண்ட் சுயவிவரத்தையும் மாற்றும் ரன் முடிவை offload-க்கு காரணமாகக் கூற முடியாது. பின்னர் அமைப்பை மீட்டமைக்கவும்.

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

பெரிய பரிமாற்றத்தின் உண்மையான நிறுத்தம் பாதையின் MTU மற்றும் பயன்பாடு பெறும் பின்னூட்டம் பற்றிய தனி கேள்வி. ஹோஸ்ட்டின் ஒருங்கிணைந்த அலகு கீழ்நிலை அளவு வரம்பை நிரூபிக்கவோ மறுக்கவோ செய்யாது, குறைந்த CPU சதவீதம் offload-ஐ காரணமாக அடையாளம் காட்டாது.

பயனுள்ள முடிவு விளக்கப்பட்ட பிடிப்பு புள்ளி மற்றும் மீண்டும் உருவாக்கக்கூடிய பயன்பாட்டு கவனிப்பு. இவை பிரிக்கப்பட்டால், MTU மாற்றம் உள் இடையகத்தின் வடிவத்திற்குப் பதிலாக உண்மையான கட்டுப்பாட்டை இலக்காகக் கொள்ளலாம்.