AWS பொறியாளர், தாமதச் சிக்கல்களைச் சரிசெய்ய, Nagle ஐ TCP_NODELAY உடன் மாற்ற பரிந்துரைக்கிறார்

லினக்ஸில் தாமதம்

சில நாட்களுக்கு முன்பு, மார்க் ப்ரூக்கர், AWS பொறியாளர், பிரச்சினைகளை விமர்சித்து உரையாற்றினார் சிறிய செய்திகளை மாற்றுவதில் செயல்திறன் சிக்கலை நீங்கள் எப்போதும் சமாளிக்க வேண்டியிருக்கும் Nagle அல்காரிதத்தைப் பயன்படுத்தும் போது.

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

இருப்பினும் மார்க் குறிப்பிடுகிறார் "தாமத சிக்கல்கள் சரி செய்யப்பட்டன விரைவாக இந்த எளிய சாக்கெட் விருப்பத்தை இயக்கு » TCP_NODELAY, TCP/IP அடுக்கில் உள்ள இயல்புநிலை விருப்பம் நாகல் அல்காரிதம் என்பதால் இது இயக்கப்படவில்லை.

இன் வழிமுறை நாக்லே, RFC896 இல் வடிவமைக்கப்பட்டது ஜான் நாகல் மூலம் 1984 இல், TCP நெட்வொர்க்குகளில் தரவு பரிமாற்றத்தில் செயல்திறனை நிவர்த்தி செய்வதை நோக்கமாகக் கொண்டது. ட்ராஃபிக்கைக் குறைக்க சிறிய செய்திகளைச் சேர்க்க இது அனுமதிக்கிறது, முன்பு அனுப்பப்பட்ட தரவின் ரசீது உறுதிப்படுத்தப்படும் வரை புதிய TCP பிரிவுகளை அனுப்புவதை நிறுத்தி வைக்கிறது. எடுத்துக்காட்டாக, திரட்டலைப் பயன்படுத்தாமல், 1 பைட்டை அனுப்புவது TCP மற்றும் IP பாக்கெட் தலைப்புகளுடன் கூடுதலாக 40 பைட்டுகளை அனுப்புகிறது. நவீன நிலைமைகளின் கீழ், Nagle அல்காரிதத்தின் பயன்பாடு தாமதங்களில் குறிப்பிடத்தக்க அதிகரிப்புக்கு காரணமாகிறது, இது ஊடாடும் மற்றும் விநியோகிக்கப்பட்ட பயன்பாடுகளுக்கு ஏற்றுக்கொள்ள முடியாதது.

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

இது தவிர, TCP_NODELAY ஐப் பயன்படுத்துவதற்கு மார்க் மூன்று முக்கிய காரணங்களைக் குறிப்பிட்டுள்ளார் இயல்புநிலையாக, Nagle க்கு பதிலாக, இது முடக்கப்படுவதை பரிந்துரைக்கிறது:

  1. "தாமதமான ACK" தேர்வுமுறையுடன் இணக்கமின்மை: Nagle இன் வழிமுறையானது "தாமதமான ACK" மூலோபாயத்துடன் முரண்படுகிறது, அங்கு ACK பதில் உடனடியாக அனுப்பப்படாது, ஆனால் மறுமொழி தரவு பெறப்பட்ட பிறகு. பிரச்சனை என்னவென்றால், Nagle இன் அல்காரிதத்தில், ACK பாக்கெட்டின் வருகையானது ஒருங்கிணைக்கப்பட்ட தரவை அனுப்புவதற்கான சமிக்ஞையாகும். ACK பாக்கெட் பெறப்படவில்லை என்றால், காத்திருப்பு நேரம் முடிந்ததும் அனுப்புதல் செய்யப்படுகிறது. இது ஒரு சுழற்சியை உருவாக்குகிறது ACK பாக்கெட் ஒரு சமிக்ஞையாக வேலை செய்யாது, ஏனெனில் அனுப்புநரின் பக்கத்தில் அதன் குவிப்பு காரணமாக மறுபக்கம் தரவைப் பெறவில்லை, மேலும் ACK பாக்கெட்டைப் பெறாததால் அனுப்புபவர் நேரம் முடிவதற்குள் அதை அனுப்பவில்லை.
  2. நாகல் அல்காரிதம் RFC வயது: Nagle அல்காரிதத்திற்கான RFC 1984 இல் ஏற்றுக்கொள்ளப்பட்டது மற்றும் நவீன அதிவேக நெட்வொர்க்குகள் மற்றும் தரவு மையங்களில் உள்ள சேவையகங்களுக்காக வடிவமைக்கப்படவில்லை, இது பதிலளிக்கும் சிக்கல்களை உருவாக்குகிறது. நவீன நெட்வொர்க்குகளில், கோரிக்கையை அனுப்புவதற்கும் பதிலைப் பெறுவதற்கும் இடையே உள்ள தாமதம் (RTT) மிகக் குறைவு, இந்த குறுகிய கால இடைவெளியில் நவீன சேவையகங்கள் மிகப்பெரிய அளவிலான வேலையைச் செய்ய அனுமதிக்கிறது.
  3. தரவு அனுப்பும் முறையில் மாற்றங்கள்: நவீன விநியோகிக்கப்பட்ட பயன்பாடுகள் இனி தனிப்பட்ட பைட் தரவுகளை அனுப்பாது, மேலும் சிறிய தரவுத் திரட்டல் பொதுவாக பயன்பாட்டு மட்டத்தில் செயல்படுத்தப்படுகிறது. பேலோட் அளவு குறைவாக இருந்தாலும், வரிசைப்படுத்தலைப் பயன்படுத்திய பிறகு, JSON APIகளைப் பயன்படுத்தி, TLS குறியாக்கத்தைப் பயன்படுத்தி அனுப்பிய பிறகு அனுப்பப்படும் தகவலின் உண்மையான அளவு கணிசமாக அதிகரிக்கிறது. எனவே, Nagle இன் வழிமுறையை முடக்குவதன் மூலம் மேம்படுத்தப்பட்ட செயல்திறன் மற்றும் பதிலளிக்கக்கூடிய தன்மையுடன் ஒப்பிடும்போது 40 பைட்டுகளைச் சேமிப்பது குறைவான தொடர்புடையதாகிறது.

அதனால்தான் ப்ரூக்கர் Nagle அல்காரிதத்தை முடக்க அழைப்பு விடுத்துள்ளார் முன்னிருப்பாக. நெட்வொர்க் சாக்கெட்டுகளுக்கான TCP_NODELAY விருப்பத்தை setsockopt அழைப்பைப் பயன்படுத்தி அமைப்பதன் மூலம் இதை அடைய முடியும், இது நீண்ட காலமாக Node.js மற்றும் curl போன்ற திட்டங்களில் செய்யப்படுகிறது.

இறுதியாக, நீங்கள் அதைப் பற்றி மேலும் தெரிந்து கொள்ள ஆர்வமாக இருந்தால், நீங்கள் விவரங்களைப் பார்க்கலாம் பின்வரும் இணைப்பு.


உங்கள் கருத்தை தெரிவிக்கவும்

உங்கள் மின்னஞ்சல் முகவரி வெளியிடப்பட்ட முடியாது. தேவையான புலங்கள் குறிக்கப்பட்டிருக்கும் *

*

*

  1. தரவுக்கு பொறுப்பு: மிகுவல் ஏஞ்சல் கேடன்
  2. தரவின் நோக்கம்: கட்டுப்பாட்டு ஸ்பேம், கருத்து மேலாண்மை.
  3. சட்டபூர்வமாக்கல்: உங்கள் ஒப்புதல்
  4. தரவின் தொடர்பு: சட்டபூர்வமான கடமையால் தவிர மூன்றாம் தரப்பினருக்கு தரவு தெரிவிக்கப்படாது.
  5. தரவு சேமிப்பு: ஆக்சென்டஸ் நெட்வொர்க்குகள் (EU) வழங்கிய தரவுத்தளம்
  6. உரிமைகள்: எந்த நேரத்திலும் உங்கள் தகவல்களை நீங்கள் கட்டுப்படுத்தலாம், மீட்டெடுக்கலாம் மற்றும் நீக்கலாம்.