എല്ലാവർക്കും ഹലോ, യുഡിപിയിൽ നിന്ന് ടിസിപി പ്രോട്ടോക്കോൾ എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്ന് ഇന്ന് ഞാൻ നിങ്ങളോട് പറയും. നെറ്റ്‌വർക്ക് നോഡുകളിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷൻ പ്രോസസുകൾക്കിടയിൽ ഡാറ്റ കൈമാറാൻ, IP-യിലേക്കുള്ള ശ്രേണിയിൽ അടുത്തതായി ട്രാൻസ്പോർട്ട് ലെയർ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നു. ഇന്റർനെറ്റ് വഴി ഒരു കമ്പ്യൂട്ടറിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ലഭിക്കുന്ന ഒരു ഡാറ്റാ പാക്കറ്റ് ഒരു ഹാൻഡ്‌ലർ പ്രോസസ്സിലേക്ക് മാറ്റണം, കൃത്യമായി ഒരു പ്രത്യേക ആവശ്യത്തിനായി. ഗതാഗത പാളിയാണ് ഇതിന്റെ ഉത്തരവാദിത്തം ഏറ്റെടുക്കുന്നത്. ഈ തലത്തിൽ രണ്ട് പ്രധാന പ്രോട്ടോക്കോളുകൾ ഉണ്ട് - TCP, UDP.

ടിസിപിയും യുഡിപിയും എന്താണ് അർത്ഥമാക്കുന്നത്?

ടിസിപി- TCP/IP നെറ്റ്‌വർക്കുകളിലെ ഡാറ്റാ കൈമാറ്റത്തിനുള്ള ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ, ഇത് പ്രാഥമികമായി നെറ്റ്‌വർക്കിലേക്ക് ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നു.

യു.ഡി.പി- ഒരു IP നെറ്റ്‌വർക്കിൽ ഒരു കണക്ഷൻ സ്ഥാപിക്കേണ്ട ആവശ്യമില്ലാതെ ഡാറ്റാഗ്രാം സന്ദേശങ്ങൾ കൈമാറുന്ന ഒരു ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ.

ഒഎസ്ഐ അല്ലെങ്കിൽ ടിസിപി/ഐപി മോഡലിന്റെ ട്രാൻസ്പോർട്ട് ലെയറിലാണ് രണ്ട് പ്രോട്ടോക്കോളുകളും പ്രവർത്തിക്കുന്നത്, അവ എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്ന് മനസ്സിലാക്കുന്നത് വളരെ പ്രധാനമാണ്.

TCP, UDP പ്രോട്ടോക്കോളുകൾ തമ്മിലുള്ള വ്യത്യാസം

TCP, UDP പ്രോട്ടോക്കോളുകൾ തമ്മിലുള്ള വ്യത്യാസം "ഡെലിവറി ഗ്യാരന്റി" എന്ന് വിളിക്കപ്പെടുന്നതാണ്. ഡാറ്റാ പാക്കറ്റ് ഡെലിവറി ചെയ്ത ക്ലയന്റിൽ നിന്നുള്ള ഒരു പ്രതികരണം, ഡെലിവറി സ്ഥിരീകരണം എന്നിവ ടിസിപിക്ക് ആവശ്യമാണ്, ഇതിനായി മുൻകൂട്ടി സ്ഥാപിതമായ ഒരു കണക്ഷൻ ആവശ്യമാണ്. കൂടാതെ, ടിസിപി പ്രോട്ടോക്കോൾ വിശ്വസനീയമായി കണക്കാക്കപ്പെടുന്നു, അതേസമയം യുഡിപിക്ക് "വിശ്വസനീയമല്ലാത്ത ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ" എന്ന പേര് പോലും ലഭിച്ചു. TCP ഡാറ്റാ നഷ്ടം, ഡ്യൂപ്ലിക്കേഷൻ, പാക്കറ്റുകളുടെ മിശ്രിതം, കാലതാമസം എന്നിവ ഇല്ലാതാക്കുന്നു. യുഡിപി ഇതെല്ലാം അനുവദിക്കുന്നു, പ്രവർത്തിക്കാൻ ഒരു കണക്ഷൻ ആവശ്യമില്ല. യു‌ഡി‌പി വഴി ഡാറ്റ സ്വീകരിക്കുന്ന പ്രക്രിയകൾ‌ നഷ്‌ടങ്ങൾ‌ ഉണ്ടായാൽ‌പ്പോലും അവർ‌ക്ക് ലഭിക്കുന്ന കാര്യങ്ങളുമായി പൊരുത്തപ്പെടണം. TCP കണക്ഷന്റെ തിരക്ക് നിയന്ത്രിക്കുന്നു, UDP സ്വീകരിച്ച ഡാറ്റാഗ്രാമുകളുടെ സമഗ്രതയല്ലാതെ മറ്റൊന്നും നിയന്ത്രിക്കുന്നില്ല.

മറുവശത്ത്, അത്തരം നോൺ-സെലക്ടിവിറ്റിയും നിയന്ത്രണത്തിന്റെ അഭാവവും കാരണം, യുഡിപി ഡാറ്റ പാക്കറ്റുകൾ (ഡാറ്റാഗ്രാമുകൾ) വളരെ വേഗത്തിൽ നൽകുന്നു, അതിനാൽ ഉയർന്ന ത്രൂപുട്ടിനും ഫാസ്റ്റ് എക്സ്ചേഞ്ചിനുമായി രൂപകൽപ്പന ചെയ്ത ആപ്ലിക്കേഷനുകൾക്ക്, യുഡിപിയെ ഒപ്റ്റിമൽ പ്രോട്ടോക്കോൾ ആയി കണക്കാക്കാം. നെറ്റ്‌വർക്ക്, ബ്രൗസർ ഗെയിമുകൾ, വീഡിയോ കമ്മ്യൂണിക്കേഷനുള്ള (അല്ലെങ്കിൽ വോയ്‌സ്) സ്ട്രീമിംഗ് വീഡിയോ കാണൽ പ്രോഗ്രാമുകളും ആപ്ലിക്കേഷനുകളും ഇതിൽ ഉൾപ്പെടുന്നു: ഒരു പാക്കേജിന്റെ നഷ്ടം, പൂർണ്ണമായോ ഭാഗികമായോ, ഒന്നും മാറ്റില്ല, അഭ്യർത്ഥന ആവർത്തിക്കേണ്ട ആവശ്യമില്ല, പക്ഷേ ഡൗൺലോഡ് വളരെ വേഗതയുള്ളതാണ്. TCP പ്രോട്ടോക്കോൾ, കൂടുതൽ വിശ്വസനീയമായതിനാൽ, ഇമെയിൽ പ്രോഗ്രാമുകളിൽ പോലും വിജയകരമായി ഉപയോഗിക്കുന്നു, ട്രാഫിക് മാത്രമല്ല, സന്ദേശത്തിന്റെ ദൈർഘ്യവും ട്രാഫിക് എക്സ്ചേഞ്ചിന്റെ വേഗതയും നിയന്ത്രിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ടിസിപിയും യുഡിപിയും തമ്മിലുള്ള പ്രധാന വ്യത്യാസങ്ങൾ നോക്കാം.

1. മാറ്റമില്ലാത്ത രൂപത്തിലും ക്രമത്തിലും നഷ്‌ടമില്ലാതെയും ഡാറ്റ പാക്കറ്റുകളുടെ ഡെലിവറിക്ക് TCP ഗ്യാരണ്ടി നൽകുന്നു, UDP ഒന്നും ഉറപ്പുനൽകുന്നില്ല.
2. പാക്കറ്റുകൾ കൈമാറുന്നതിനനുസരിച്ച് ടിസിപി നമ്പർ നൽകുന്നു, എന്നാൽ യുഡിപി അങ്ങനെയല്ല.
3. TCP പൂർണ്ണ ഡ്യുപ്ലെക്സ് മോഡിൽ പ്രവർത്തിക്കുന്നു, ഒരു പാക്കറ്റിൽ നിങ്ങൾക്ക് വിവരങ്ങൾ അയയ്ക്കാനും മുമ്പത്തെ പാക്കറ്റിന്റെ രസീത് സ്ഥിരീകരിക്കാനും കഴിയും.
4. ടിസിപിക്ക് മുൻകൂട്ടി സ്ഥാപിതമായ ഒരു കണക്ഷൻ ആവശ്യമാണ്, യുഡിപിക്ക് ഒരു കണക്ഷൻ ആവശ്യമില്ല, ഇത് ഒരു ഡാറ്റ സ്ട്രീം മാത്രമാണ്.
5. UDP ഉയർന്ന ഡാറ്റാ ട്രാൻസ്ഫർ നിരക്കുകൾ നൽകുന്നു.
6. TCP കൂടുതൽ വിശ്വസനീയവും ഡാറ്റാ കൈമാറ്റ പ്രക്രിയയെ നിയന്ത്രിക്കുന്നതുമാണ്.
7. സ്ട്രീമിംഗ് വീഡിയോ, വീഡിയോഫോണി, ടെലിഫോണി, നെറ്റ്‌വർക്ക് ഗെയിമുകൾ എന്നിവ കളിക്കുന്ന പ്രോഗ്രാമുകൾക്ക് UDP അഭികാമ്യമാണ്.
8. UPD-യിൽ ഡാറ്റ വീണ്ടെടുക്കൽ പ്രവർത്തനങ്ങൾ അടങ്ങിയിട്ടില്ല

UDP ആപ്ലിക്കേഷനുകളുടെ ഉദാഹരണങ്ങളിൽ ഉൾപ്പെടുന്നു, ഉദാഹരണത്തിന്, വിശ്വാസ്യത ആവശ്യമില്ലാത്ത DNS സോണുകൾ സജീവ ഡയറക്ടറിയിലേക്ക് മാറ്റുന്നത്. മിക്കപ്പോഴും അവർ അഭിമുഖങ്ങളിൽ അത്തരം ചോദ്യങ്ങൾ ചോദിക്കാൻ ഇഷ്ടപ്പെടുന്നു, അതിനാൽ ടിസിപിയും യുഡിപിയും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ അറിയേണ്ടത് വളരെ പ്രധാനമാണ്.

TCP, UDP തലക്കെട്ടുകൾ

രണ്ട് ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോളുകളുടെ തലക്കെട്ടുകൾ എങ്ങനെയുണ്ടെന്ന് നോക്കാം, കാരണം ഇവിടെയും വ്യത്യാസങ്ങൾ അടിസ്ഥാനപരമാണ്.

UDP തലക്കെട്ട്

• 16-ബിറ്റ് സോഴ്സ് പോർട്ട് > UDP-യുടെ ഉറവിട പോർട്ട് വ്യക്തമാക്കുന്നത് ഓപ്ഷണൽ ആണ്. ഈ ഫീൽഡ് ഉപയോഗിക്കുകയാണെങ്കിൽ, സ്വീകർത്താവിന് ഈ പോർട്ടിലേക്ക് ഒരു പ്രതികരണം അയയ്ക്കാൻ കഴിയും.
• 16 ബിറ്റ് ഡെസ്റ്റിനേഷൻ പോർട്ട് > ഡെസ്റ്റിനേഷൻ പോർട്ട് നമ്പർ
• 16-ബിറ്റ് UDP ദൈർഘ്യം > തലക്കെട്ടും ഡാറ്റയും ഉൾപ്പെടെ സന്ദേശത്തിന്റെ ദൈർഘ്യം.
• വെരിഫിക്കേഷനായി 16 ബിറ്റ് ചെക്ക്‌സം > ഹെഡറും ഡാറ്റ ചെക്ക്‌സും

TCP തലക്കെട്ട്

• 16 ബിറ്റ് സോഴ്സ് പോർട്ട് > സോഴ്സ് പോർട്ട് നമ്പർ
• 16 ബിറ്റ് ഡെസ്റ്റിനേഷൻ പോർട്ട് > ഡെസ്റ്റിനേഷൻ പോർട്ട് നമ്പർ
• 32 ബിറ്റ് സീക്വൻസ് നമ്പർ > സീക്വൻസ് നമ്പർ ഉറവിടം ജനറേറ്റ് ചെയ്യുകയും ലക്ഷ്യസ്ഥാനം യഥാർത്ഥ സന്ദേശം സൃഷ്ടിക്കുന്നതിനും ഉറവിടത്തിലേക്ക് ഒരു അംഗീകാരം അയയ്ക്കുന്നതിനും പാക്കറ്റുകൾ പുനഃക്രമീകരിക്കുന്നതിനും ഉപയോഗിക്കുന്നു.
• 32-ബിറ്റ് അക്നോളജ്‌മെന്റ് നമ്പർ > കൺട്രോൾ ഫീൽഡിന്റെ ACK ബിറ്റ് സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ ഫീൽഡിൽ അടുത്ത പ്രതീക്ഷിക്കുന്ന സീക്വൻസ് നമ്പർ അടങ്ങിയിരിക്കുന്നു.
• 4 ബിറ്റ് ഹെഡർ ദൈർഘ്യം > ഡാറ്റ പാക്കറ്റിന്റെ ആരംഭത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ.
• കരുതൽ > ഭാവിയിലെ ഉപയോഗത്തിനായി കരുതിവച്ചിരിക്കുന്നു.
• 16-ബിറ്റ് ചെക്ക്സം > ഹെഡറും ഡാറ്റ ചെക്ക്സും; പാക്കറ്റ് കേടായിട്ടുണ്ടോ എന്ന് ഇത് നിർണ്ണയിക്കുന്നു.
• 16-ബിറ്റ് അടിയന്തിര സൂചകം > ഈ ഫീൽഡിൽ, ടാർഗെറ്റ് ഉപകരണത്തിന് ഡാറ്റയുടെ അടിയന്തിരതയെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുന്നു.
• ഓപ്‌ഷനുകൾ > ആവശ്യാനുസരണം വ്യക്തമാക്കാൻ കഴിയുന്ന ഓപ്‌ഷണൽ മൂല്യങ്ങൾ.

ട്രാഫിക് സംരക്ഷിക്കാൻ വിൻഡോ വലുപ്പം നിങ്ങളെ അനുവദിക്കുന്നു, അതിന്റെ മൂല്യം 1 ആയിരിക്കുമ്പോൾ നമുക്ക് പരിഗണിക്കാം, തുടർന്ന് അയച്ച ഓരോ പ്രതികരണത്തിനും അയച്ചയാൾ സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുന്നു, പൂർണ്ണമായും യുക്തിസഹമല്ല.

വിൻഡോ വലുപ്പം 3 ഉള്ളതിനാൽ, അയച്ചയാൾ ഇതിനകം 3 ഫ്രെയിമുകൾ അയച്ചു, കൂടാതെ 4 മുതൽ കാത്തിരിക്കുന്നു, അതായത് മൂന്ന് ഫ്രെയിമുകളും +1 ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്നു.

tcp, udp പ്രോട്ടോക്കോളുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് ഇപ്പോൾ ഒരു ധാരണയുണ്ടെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

ഉപയോക്തൃ ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ - UDP

UDP പ്രോട്ടോക്കോൾ TCP/IP പ്രോട്ടോക്കോൾ സ്റ്റാക്കിൽ ഉപയോഗിക്കുന്ന രണ്ട് ട്രാൻസ്പോർട്ട് ലെയർ പ്രോട്ടോക്കോളുകളിൽ ഒന്നാണ്. ആപ്ലിക്കേഷൻ ലെയർ പ്രോട്ടോക്കോളുകൾ ഐപിയിലേക്ക് പരിവർത്തനം ചെയ്യുന്നതുമായി ബന്ധപ്പെട്ട കുറഞ്ഞ ഓവർഹെഡുള്ള നെറ്റ്‌വർക്കിലൂടെ സന്ദേശങ്ങൾ കൈമാറാൻ ഒരു ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിനെ UDP അനുവദിക്കുന്നു. എന്നിരുന്നാലും, സന്ദേശം അതിന്റെ ലക്ഷ്യസ്ഥാനത്തേക്ക് കൈമാറിയെന്ന് സ്ഥിരീകരിക്കുന്നതിന് ആപ്ലിക്കേഷൻ പ്രോഗ്രാം തന്നെ ശ്രദ്ധിക്കണം. UDP ഡാറ്റഗ്രാം (സന്ദേശം) തലക്കെട്ട് ചിത്രം 2.10-ൽ കാണിച്ചിരിക്കുന്നത് പോലെയാണ്.

അരി. 2.10 UDP സന്ദേശ തലക്കെട്ട് ഘടന

UDP പ്രോട്ടോക്കോൾ ഡാറ്റ യൂണിറ്റിനെ UDP പാക്കറ്റ് അല്ലെങ്കിൽ ഉപയോക്തൃ ഡാറ്റാഗ്രാം എന്ന് വിളിക്കുന്നു. ഒരു യുഡിപി പാക്കറ്റിൽ ഒരു ഹെഡറും ആപ്ലിക്കേഷൻ ലെയർ പാക്കറ്റ് അടങ്ങുന്ന ഒരു ഡാറ്റ ഫീൽഡും അടങ്ങിയിരിക്കുന്നു. തലക്കെട്ടിന് ലളിതമായ ഒരു ഫോർമാറ്റുണ്ട് കൂടാതെ നാല് രണ്ട്-ബൈറ്റ് ഫീൽഡുകൾ അടങ്ങിയിരിക്കുന്നു:

UDP ഉറവിട പോർട്ട് - അയയ്ക്കൽ പ്രക്രിയയുടെ പോർട്ട് നമ്പർ,

UDP ഡെസ്റ്റിനേഷൻ പോർട്ട് - സ്വീകർത്താവിന്റെ പ്രക്രിയയുടെ പോർട്ട് നമ്പർ,

UDP സന്ദേശ ദൈർഘ്യം - UDP പാക്കറ്റിന്റെ ദൈർഘ്യം ബൈറ്റുകളിൽ,

UDP ചെക്ക്സം - UDP പാക്കറ്റിന്റെ ചെക്ക്സം

UDP പാക്കറ്റിന്റെ എല്ലാ ഫീൽഡുകളും പൂരിപ്പിക്കേണ്ടതില്ല. അയച്ച ഡാറ്റഗ്രാം ഒരു പ്രതികരണം പ്രതീക്ഷിക്കുന്നില്ലെങ്കിൽ, അയച്ചയാളുടെ വിലാസത്തിന് പകരം പൂജ്യങ്ങൾ സ്ഥാപിക്കാം. നിങ്ങൾക്ക് ചെക്ക്സം കണക്കാക്കുന്നത് നിരസിക്കാം, പക്ഷേ ഡാറ്റ ഫീൽഡ് അവഗണിച്ച് ഐപി പാക്കറ്റ് ഹെഡറിനായി മാത്രമാണ് ഐപി പ്രോട്ടോക്കോൾ ചെക്ക്സം കണക്കാക്കുന്നത്.

ഹെഡറിലെ പോർട്ടുകൾ, ആപ്ലിക്കേഷനുകളിൽ നിന്നുള്ള സന്ദേശങ്ങൾ ശേഖരിക്കാനും പ്രോട്ടോക്കോൾ ലെയറിലേക്ക് അയയ്ക്കാനും അനുവദിക്കുന്ന ഒരു മൾട്ടിപ്ലക്‌സർ ആയി UDP പ്രോട്ടോക്കോളിനെ നിർവചിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ആപ്ലിക്കേഷൻ ഒരു പ്രത്യേക പോർട്ട് ഉപയോഗിക്കുന്നു. നെറ്റ്‌വർക്കിലൂടെ ആശയവിനിമയം നടത്തുന്ന ആപ്ലിക്കേഷനുകൾ വ്യത്യസ്ത പോർട്ടുകൾ ഉപയോഗിച്ചേക്കാം, അത് പാക്കറ്റ് ഹെഡറിൽ പ്രതിഫലിക്കുന്നു. മൊത്തത്തിൽ, 216 വ്യത്യസ്ത പോർട്ടുകൾ നിർവചിക്കാം. ആദ്യത്തെ 256 പോർട്ടുകൾ "അറിയപ്പെടുന്ന സേവനങ്ങൾ" എന്ന് വിളിക്കപ്പെടുന്നവയ്ക്ക് അസൈൻ ചെയ്‌തിരിക്കുന്നു, ഉദാഹരണത്തിന്, DNS സേവനത്തിന് നൽകിയിട്ടുള്ള UDP പോർട്ട് 53 ഉൾപ്പെടുന്നു.

ഫീൽഡ് നീളംസന്ദേശത്തിന്റെ ആകെ ദൈർഘ്യം നിർണ്ണയിക്കുന്നു. ഫീൽഡ് ചെക്ക്സംഡാറ്റയുടെ സമഗ്രത നിയന്ത്രിക്കാൻ സഹായിക്കുന്നു. UDP പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്ന ഒരു ആപ്ലിക്കേഷൻ, ചെക്ക്‌സം, ലെങ്ത്ത് ഫീൽഡുകൾ വിശകലനം ചെയ്തുകൊണ്ട് ഡാറ്റ സമഗ്രത ശ്രദ്ധിക്കണം. കൂടാതെ, യു‌ഡി‌പി വഴി ഡാറ്റ കൈമാറ്റം ചെയ്യുമ്പോൾ, സ്വീകർത്താവിന് ഡാറ്റ കൈമാറുന്നത് നിരീക്ഷിക്കാൻ ആപ്ലിക്കേഷൻ പ്രോഗ്രാം തന്നെ ശ്രദ്ധിക്കണം. ആപ്ലിക്കേഷൻ പ്രോഗ്രാമുകൾക്കിടയിൽ ഡെലിവറി സ്ഥിരീകരണങ്ങൾ കൈമാറുന്നതിലൂടെ ഇത് സാധാരണയായി നേടാനാകും.

BIND ഡൊമെയ്ൻ നെയിം സേവനവും NFS ഡിസ്ട്രിബ്യൂട്ടഡ് ഫയൽ സിസ്റ്റവുമാണ് ഏറ്റവും അറിയപ്പെടുന്ന UDP അടിസ്ഥാനമാക്കിയുള്ള സേവനങ്ങൾ. ട്രേസറൂട്ട് ഉദാഹരണത്തിലേക്ക് മടങ്ങുമ്പോൾ, ഈ പ്രോഗ്രാം UDP ഗതാഗതവും ഉപയോഗിക്കുന്നു. യഥാർത്ഥത്തിൽ, ഇത് നെറ്റ്‌വർക്കിലേക്ക് അയയ്‌ക്കുന്നത് UDP സന്ദേശമാണ്, പക്ഷേ ഇത് സേവനമില്ലാത്ത ഒരു പോർട്ട് ഉപയോഗിക്കുന്നു, അതിനാലാണ് ഒരു ICMP പാക്കറ്റ് ജനറേറ്റുചെയ്യുന്നത്, ഇത് പാക്കറ്റ് ഒടുവിൽ എത്തുമ്പോൾ സ്വീകരിക്കുന്ന മെഷീനിലെ സേവനത്തിന്റെ അഭാവം കണ്ടെത്തുന്നു. ലക്ഷ്യസ്ഥാന യന്ത്രം.

ട്രാൻസ്ഫർ കൺട്രോൾ പ്രോട്ടോക്കോൾ - ടിസിപി

നെറ്റ്‌വർക്കിലൂടെയുള്ള ഡാറ്റാ ട്രാൻസ്മിഷന്റെ ഗുണനിലവാരം നിരീക്ഷിക്കുന്നത് ഒരു അപ്ലിക്കേഷന് പ്രധാനമാണെങ്കിൽ, ഈ സാഹചര്യത്തിൽ TCP പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു. ഈ പ്രോട്ടോക്കോളിനെ വിശ്വസനീയമായ, കണക്ഷൻ-ഓറിയന്റഡ്, ഫ്ലോ-ഓറിയന്റഡ് പ്രോട്ടോക്കോൾ എന്നും വിളിക്കുന്നു. പ്രോട്ടോക്കോളിന്റെ ഈ പ്രോപ്പർട്ടികൾ ചർച്ച ചെയ്യുന്നതിനുമുമ്പ്, നെറ്റ്‌വർക്കിലൂടെ കൈമാറുന്ന ഡാറ്റാഗ്രാമിന്റെ ഫോർമാറ്റ് നമുക്ക് പരിഗണിക്കാം (ചിത്രം 2.11). ഈ ഘടന അനുസരിച്ച്, യുഡിപി പോലെ ടിസിപിക്കും തുറമുഖങ്ങളുണ്ട്. ആദ്യത്തെ 256 പോർട്ടുകൾ WKS-നും 256 മുതൽ 1024 വരെയുള്ള പോർട്ടുകൾ Unix സേവനങ്ങൾക്കുമാണ് നൽകിയിരിക്കുന്നത്, ബാക്കിയുള്ളവ നിങ്ങളുടെ വിവേചനാധികാരത്തിൽ ഉപയോഗിക്കാവുന്നതാണ്. വയലിൽ ക്രമസംഖ്യമുഴുവൻ സന്ദേശവും ഉൾക്കൊള്ളുന്ന പാക്കറ്റുകളുടെ ക്രമത്തിലാണ് പാക്കറ്റ് നമ്പർ നിർവചിച്ചിരിക്കുന്നത്, തുടർന്ന് ഒരു അംഗീകാര ഫീൽഡ് വിജ്ഞാന സംഖ്യമറ്റ് നിയന്ത്രണ വിവരങ്ങളും.

അരി. 2.11 TCP പാക്കറ്റ് ഘടന

സോഴ്സ് പോർട്ട് (സോഴ്സ് പോർട്ട്) 2 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, അയയ്ക്കൽ പ്രക്രിയയെ തിരിച്ചറിയുന്നു;

ഡെസ്റ്റിനേഷൻ പോർട്ട് (DESTINATION പോർട്ട്) 2 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, സ്വീകർത്താവിന്റെ പ്രക്രിയയെ തിരിച്ചറിയുന്നു;

സീക്വൻസ് നമ്പർ (സീക്വൻസ് നമ്പർ) 4 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, അയച്ച ഡാറ്റയുടെ സ്ട്രീമുമായി ബന്ധപ്പെട്ട സെഗ്മെന്റിന്റെ ഓഫ്സെറ്റ് നിർണ്ണയിക്കുന്ന ബൈറ്റ് നമ്പർ സൂചിപ്പിക്കുന്നു;

സ്ഥിരീകരിച്ച നമ്പർ (അക്‌നൗലെഡ്‌ജ് നമ്പർ) 4 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, ലഭിച്ച സെഗ്‌മെന്റിലെ പരമാവധി ബൈറ്റ് നമ്പർ അടങ്ങിയിരിക്കുന്നു, ഒന്നായി വർദ്ധിപ്പിച്ചു; ഈ മൂല്യമാണ് രസീതായി ഉപയോഗിക്കുന്നത്;

ശീർഷക ദൈർഘ്യം (HLEN) 4 ബിറ്റുകൾ നീളമുള്ളതും 32-ബിറ്റ് വാക്കുകളിൽ അളക്കുന്ന TCP സെഗ്‌മെന്റ് ഹെഡറിന്റെ ദൈർഘ്യത്തെ സൂചിപ്പിക്കുന്നു. തലക്കെട്ടിന്റെ ദൈർഘ്യം നിശ്ചയിച്ചിട്ടില്ല കൂടാതെ ഓപ്ഷനുകൾ ഫീൽഡിൽ സജ്ജീകരിച്ചിരിക്കുന്ന മൂല്യങ്ങളെ ആശ്രയിച്ച് വ്യത്യാസപ്പെടാം;

റിസർവ് (റിസർവ്ഡ്) 6 ബിറ്റുകൾ ഉൾക്കൊള്ളുന്നു, ഫീൽഡ് പിന്നീടുള്ള ഉപയോഗത്തിനായി നീക്കിവച്ചിരിക്കുന്നു;

കോഡ് ബിറ്റുകൾ (കോഡ് ബിറ്റുകൾ) 6 ബിറ്റുകൾ ഉൾക്കൊള്ളുന്നു, ഈ ഫീൽഡിന്റെ അനുബന്ധ ബിറ്റുകൾ ഒന്നായി സജ്ജീകരിച്ചുകൊണ്ട് വ്യക്തമാക്കിയ ഒരു സെഗ്‌മെന്റിന്റെ തരത്തെക്കുറിച്ചുള്ള സേവന വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

URG - അടിയന്തിര സന്ദേശം;

ACK - സ്വീകരിച്ച സെഗ്മെന്റിനുള്ള രസീത്;

PSH - ബഫർ പൂരിപ്പിക്കുന്നതിന് കാത്തിരിക്കാതെ ഒരു സന്ദേശം അയയ്‌ക്കാനുള്ള അഭ്യർത്ഥന;

RST - കണക്ഷൻ പുനഃസ്ഥാപിക്കാനുള്ള അഭ്യർത്ഥന;

SYN - ഒരു കണക്ഷൻ സ്ഥാപിക്കുമ്പോൾ ട്രാൻസ്മിറ്റ് ചെയ്ത ഡാറ്റയുടെ കൗണ്ടറുകൾ സമന്വയിപ്പിക്കാൻ ഉപയോഗിക്കുന്ന സന്ദേശം;

ട്രാൻസ്മിറ്റ് ചെയ്ത ഡാറ്റ സ്ട്രീമിലെ അവസാന ബൈറ്റിൽ ട്രാൻസ്മിറ്റിംഗ് സൈഡ് എത്തിയിരിക്കുന്നു എന്നതിന്റെ സൂചനയാണ് FIN.

ഒരു വിൻഡോ (WINDOW) 2 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, വിൻഡോ വലുപ്പത്തിന്റെ പ്രഖ്യാപിത മൂല്യം ബൈറ്റുകളിൽ അടങ്ങിയിരിക്കുന്നു;

ചെക്ക്സം (CHECKSUM) 2 ബൈറ്റുകൾ എടുക്കുന്നു, ഓരോ സെഗ്മെന്റിലും കണക്കാക്കുന്നു;

അടിയന്തിര പോയിന്റർ (URGENT POINTER) 2 ബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു, URG കോഡ് ബിറ്റുമായി സംയോജിച്ച് ഉപയോഗിക്കുന്നു, ബഫർ ഓവർഫ്ലോ ഉണ്ടായിരുന്നിട്ടും, അടിയന്തിരമായി സ്വീകരിക്കേണ്ട ഡാറ്റയുടെ അവസാനം സൂചിപ്പിക്കുന്നു;

ഓപ്‌ഷനുകൾ - ഈ ഫീൽഡിന് വേരിയബിൾ ദൈർഘ്യമുണ്ട്, മൊത്തത്തിൽ ഇല്ലായിരിക്കാം, പരമാവധി ഫീൽഡ് വലുപ്പം 3 ബൈറ്റുകളാണ്; സഹായ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, പരമാവധി സെഗ്മെന്റ് വലുപ്പം തിരഞ്ഞെടുക്കുമ്പോൾ;

പാഡിംഗ്, ഒരു വേരിയബിൾ-ലെംഗ്ത്ത് പാഡിംഗാണ്, ഹെഡർ വലുപ്പം 32-ബിറ്റ് വാക്കുകളുടെ ഒരു പൂർണ്ണസംഖ്യയിലേക്ക് കൊണ്ടുവരാൻ ഉപയോഗിക്കുന്ന ഒരു ഡമ്മി ഫീൽഡ് ആണ്.

ഒരു നിശ്ചിത സമയത്തിനുള്ളിൽ സ്വീകർത്താവിൽ നിന്ന് അത് വിജയകരമായി ലഭിച്ചുവെന്ന് സ്ഥിരീകരണം ലഭിക്കുന്നില്ലെങ്കിൽ, ഡാറ്റ ഉറവിടം അത് അയയ്ക്കുന്നത് ആവർത്തിക്കുന്നു എന്ന വസ്തുതയിലാണ് ടിസിപിയുടെ വിശ്വാസ്യത. ഈ മെക്കാനിസത്തെ വിളിക്കുന്നു പുനഃസംപ്രേഷണത്തോടുകൂടിയ നല്ല അവബോധം (PAR). ഞങ്ങൾ മുമ്പ് നിർവചിച്ചതുപോലെ, TCP പദങ്ങളിലെ ട്രാൻസ്മിഷൻ യൂണിറ്റിനെ (ഡാറ്റ പാക്കറ്റ്, സന്ദേശം മുതലായവ) ഒരു സെഗ്മെന്റ് എന്ന് വിളിക്കുന്നു. TCP തലക്കെട്ടിൽ ഒരു ചെക്ക്സം ഫീൽഡ് ഉണ്ട്. ട്രാൻസ്മിഷൻ സമയത്ത് ഡാറ്റ കേടായെങ്കിൽ, ഐപി പാക്കറ്റുകളിൽ നിന്ന് ടിസിപി സെഗ്‌മെന്റുകളെ വേർതിരിക്കുന്ന മൊഡ്യൂളിന് ചെക്ക്സം ഉപയോഗിച്ച് ഇത് നിർണ്ണയിക്കാനാകും. കേടായ പാക്കറ്റ് നശിച്ചു, ഉറവിടത്തിലേക്ക് ഒന്നും അയയ്ക്കുന്നില്ല. ഡാറ്റ കേടായില്ലെങ്കിൽ, അത് ആപ്ലിക്കേഷൻ സന്ദേശ അസംബ്ലിയിലേക്ക് കൈമാറുകയും ഉറവിടത്തിലേക്ക് ഒരു അംഗീകാരം അയയ്ക്കുകയും ചെയ്യും.

ഒരു ഡാറ്റ സെഗ്‌മെന്റ് അയയ്‌ക്കുന്നതിന് മുമ്പ്, ഉറവിടവും ലക്ഷ്യസ്ഥാനവും TCP മൊഡ്യൂളുകൾ നിയന്ത്രണ വിവരങ്ങൾ കൈമാറുന്നു എന്ന വസ്തുതയാണ് കണക്ഷൻ ഓറിയന്റേഷൻ നിർണ്ണയിക്കുന്നത്. ഈ കൈമാറ്റം എന്ന് വിളിക്കുന്നു ഹസ്തദാനം(അക്ഷരാർത്ഥത്തിൽ "ഹസ്തദാനം"). TCP ത്രീ-ഫേസ് ഹാൻഡ്-ഷേക്ക് ഉപയോഗിക്കുന്നു:

സിൻക്രൊണൈസ് സീക്വൻസ് നമ്പറുകൾ (SYN) ഫ്ലാഗ് ഉള്ള ഒരു പാക്കറ്റ് അയച്ചുകൊണ്ട് ഉറവിടം ലക്ഷ്യസ്ഥാനവുമായി ഒരു ബന്ധം സ്ഥാപിക്കുന്നു. ക്രമത്തിലെ നമ്പർ ആപ്ലിക്കേഷൻ സന്ദേശത്തിലെ പാക്കറ്റ് നമ്പർ തിരിച്ചറിയുന്നു. ഇത് 0 അല്ലെങ്കിൽ ഒന്നായിരിക്കണമെന്നില്ല. എന്നാൽ മറ്റെല്ലാ നമ്പറുകളും ഇത് ഒരു അടിസ്ഥാനമായി ഉപയോഗിക്കും, ഇത് പാക്കറ്റുകൾ ശരിയായ ക്രമത്തിൽ ശേഖരിക്കാൻ അനുവദിക്കും;

സ്വീകർത്താവ് SYN രസീത് അക്‌നോളജ്‌മെന്റ് ഫീൽഡിലെ ഒരു നമ്പർ ഉപയോഗിച്ച് പ്രതികരിക്കുന്നു, അത് ഉറവിടം സജ്ജീകരിച്ച നമ്പറുമായി പൊരുത്തപ്പെടുന്നു. കൂടാതെ, "നമ്പർ ഇൻ സീക്വൻസ്" ഫീൽഡ് ഉറവിടം ആവശ്യപ്പെട്ട സംഖ്യയും സൂചിപ്പിക്കാം;

ഡെസ്റ്റിനേഷൻ സെഗ്‌മെന്റ് സ്വീകരിച്ചതായി ഉറവിടം സ്ഥിരീകരിക്കുകയും ഡാറ്റയുടെ ആദ്യ ഭാഗം അയയ്ക്കുകയും ചെയ്യുന്നു.

ഗ്രാഫിക്കലി ഈ പ്രക്രിയ ചിത്രം 2.12 ൽ അവതരിപ്പിച്ചിരിക്കുന്നു.

അരി. 2.12 ഒരു TCP കണക്ഷൻ സ്ഥാപിക്കുന്നു

കണക്ഷൻ സ്ഥാപിച്ച ശേഷം, ഉറവിടം സ്വീകർത്താവിന് ഡാറ്റ അയയ്‌ക്കുകയും അത് ലഭിച്ചതായി അവനിൽ നിന്നുള്ള സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുകയും തുടർന്ന് സന്ദേശം അവസാനിക്കുന്നതുവരെ ഡാറ്റ വീണ്ടും അയയ്ക്കുകയും ചെയ്യുന്നു. ഫ്ലാഗ്സ് ഫീൽഡിൽ FIN ബിറ്റ് സജ്ജീകരിക്കുമ്പോൾ സന്ദേശം അവസാനിക്കുന്നു, അതായത് "കൂടുതൽ ഡാറ്റ ഇല്ല" എന്നാണ്.

പാക്കറ്റുകളല്ല, ട്രാൻസ്മിറ്റ് ചെയ്ത ബൈറ്റുകൾ എണ്ണുന്നതിനുള്ള ആരംഭ നമ്പർ SYN നിർണ്ണയിക്കുന്നു എന്ന വസ്തുതയാണ് പ്രോട്ടോക്കോളിന്റെ സ്ട്രീമിംഗ് സ്വഭാവം നിർണ്ണയിക്കുന്നത്. ഇതിനർത്ഥം SYN 0 ആയി സജ്ജീകരിക്കുകയും 200 ബൈറ്റുകൾ ട്രാൻസ്മിറ്റ് ചെയ്യുകയും ചെയ്താൽ, അടുത്ത പാക്കറ്റിൽ സെറ്റ് ചെയ്ത നമ്പർ 2 അല്ല, 201 ആയിരിക്കും.

പ്രോട്ടോക്കോളിന്റെ സ്ട്രീമിംഗ് സ്വഭാവവും ഡാറ്റയുടെ രസീത് സ്ഥിരീകരിക്കേണ്ടതിന്റെ ആവശ്യകതയും ഡാറ്റ കൈമാറ്റ വേഗതയുടെ പ്രശ്‌നത്തിന് കാരണമാകുമെന്ന് വ്യക്തമാണ്. ഈ പ്രശ്നം പരിഹരിക്കാൻ, ഒരു "വിൻഡോ" - ഒരു ഫീൽഡ് - വിൻഡോ ഉപയോഗിക്കുക. വിൻഡോ ഉപയോഗിക്കുന്നതിനുള്ള ആശയം വളരെ ലളിതമാണ്: രസീതിന്റെ സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കാതെ ഡാറ്റ കൈമാറുക. ഇതിനർത്ഥം ഉറവിടം അതിന്റെ രസീതിന്റെ സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കാതെ വിൻഡോയ്ക്ക് തുല്യമായ ഒരു നിശ്ചിത തുക ഡാറ്റ കൈമാറുന്നു, അതിനുശേഷം അത് പ്രക്ഷേപണം നിർത്തി സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുന്നു എന്നാണ്. ട്രാൻസ്മിറ്റ് ചെയ്ത ഡാറ്റയുടെ ഒരു ഭാഗത്തിന് മാത്രമേ ഇതിന് സ്ഥിരീകരണം ലഭിക്കുകയുള്ളൂവെങ്കിൽ, അത് സ്ഥിരീകരിച്ചതിന് ശേഷമുള്ള നമ്പറിൽ നിന്ന് ഒരു പുതിയ ഭാഗം കൈമാറാൻ തുടങ്ങും. ഇത് ചിത്രം 2.13-ൽ ഗ്രാഫിക്കായി കാണിച്ചിരിക്കുന്നു.

അരി. 2.13 TCP ഡാറ്റ ട്രാൻസ്മിഷൻ സംവിധാനം

ഈ ഉദാഹരണത്തിൽ, വിൻഡോ 250 ബൈറ്റുകൾ വീതിയിൽ സജ്ജീകരിച്ചിരിക്കുന്നു. ഇതിനർത്ഥം നിലവിലെ സെഗ്‌മെന്റ് 250 ബൈറ്റുകളുടെ SYN ഓഫ്‌സെറ്റുള്ള ഒരു സെഗ്‌മെന്റാണെന്നാണ്. എന്നിരുന്നാലും, മുഴുവൻ വിൻഡോയും സംപ്രേഷണം ചെയ്തതിന് ശേഷം, ഉറവിട TCP മൊഡ്യൂളിന് ആദ്യത്തെ 100 ബൈറ്റുകൾ മാത്രം സ്വീകരിക്കുന്നതിനുള്ള ഒരു അംഗീകാരം ലഭിച്ചു. അതിനാൽ, കൈമാറ്റം 101 ബൈറ്റിൽ നിന്ന് ആരംഭിക്കും, 251 ൽ നിന്നല്ല.

അതിനാൽ, TCP പ്രോട്ടോക്കോളിന്റെ എല്ലാ അടിസ്ഥാന സവിശേഷതകളും ഞങ്ങൾ പരിശോധിച്ചു. ഡാറ്റാ എക്സ്ചേഞ്ചിനായി ടിസിപി ഉപയോഗിക്കുന്ന ഏറ്റവും പ്രശസ്തമായ ആപ്ലിക്കേഷനുകൾക്ക് പേരിടാൻ മാത്രമേ ഇത് ശേഷിക്കുന്നുള്ളൂ. ഇവ പ്രാഥമികമായി TELNET, FTP എന്നിവയും വേൾഡ് വൈഡ് വെബിന്റെ ഹൃദയമായ HTTP പ്രോട്ടോക്കോളും ആണ്.

പ്രോട്ടോക്കോളുകളെക്കുറിച്ചുള്ള സംഭാഷണം നമുക്ക് അൽപ്പം തടസ്സപ്പെടുത്താം, കൂടാതെ മുഴുവൻ ടിസിപി/ഐപി സിസ്റ്റത്തിന്റെയും ഐപി വിലാസങ്ങൾ പോലുള്ള ഒരു പ്രധാന ഘടകത്തിലേക്ക് ശ്രദ്ധ തിരിക്കാം.

UDP ഒരു ലളിതമായ പ്രോട്ടോക്കോൾ ആണ് കൂടാതെ ഒരു പ്രത്യേക സ്കോപ്പുമുണ്ട്. ഒന്നാമതായി, ഇവ ക്ലയന്റ്-സെർവർ ഇടപെടലുകളും മൾട്ടിമീഡിയയുമാണ്. എന്നിരുന്നാലും, മിക്ക ഇന്റർനെറ്റ് ആപ്ലിക്കേഷനുകൾക്കും വിശ്വസനീയവും സ്ഥിരവുമായ പ്രക്ഷേപണം ആവശ്യമാണ്. UDP ഈ ആവശ്യകതകൾ നിറവേറ്റുന്നില്ല, അതിനാൽ മറ്റൊരു പ്രോട്ടോക്കോൾ ആവശ്യമാണ്. ഈ പ്രോട്ടോക്കോളിനെ ടിസിപി എന്ന് വിളിക്കുന്നു, ഇത് ഇന്റർനെറ്റിന്റെ വർക്ക്ഹോഴ്സാണ്.

TCP അടിസ്ഥാനങ്ങൾ

വിശ്വസനീയമല്ലാത്ത ഇന്റർനെറ്റ് നെറ്റ്‌വർക്കിലൂടെ വിശ്വസനീയമായ എൻഡ്-ടു-എൻഡ് ബൈറ്റ് സ്ട്രീം നൽകാൻ ട്രാൻസ്മിഷൻ കൺട്രോൾ പ്രോട്ടോക്കോൾ (TCP) പ്രത്യേകം രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. പരസ്പരം ബന്ധിപ്പിച്ച നെറ്റ്‌വർക്ക് ഒരു സ്റ്റാൻഡ്-എലോൺ നെറ്റ്‌വർക്കിൽ നിന്ന് വ്യത്യസ്തമാണ്, അതിന്റെ വ്യത്യസ്ത വിഭാഗങ്ങൾക്ക് വളരെ വ്യത്യസ്തമായ ടോപ്പോളജികൾ, ബാൻഡ്‌വിഡ്‌ത്തുകൾ, ലേറ്റൻസി മൂല്യങ്ങൾ, പാക്കറ്റ് വലുപ്പങ്ങൾ, മറ്റ് പാരാമീറ്ററുകൾ എന്നിവ ഉണ്ടായിരിക്കാം. ടിസിപിയുടെ വികസനം ഇന്റർനെറ്റ് വർക്കിന്റെ സവിശേഷതകളുമായി പൊരുത്തപ്പെടാനും വിവിധ പ്രശ്‌നങ്ങളെ അഭിമുഖീകരിക്കാനും ഉള്ള പ്രോട്ടോക്കോളിന്റെ കഴിവിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു.

TCP പ്രോട്ടോക്കോൾ RFC 793-ൽ വിവരിച്ചിരിക്കുന്നു. കാലക്രമേണ, വിവിധ പിശകുകളും കൃത്യതയില്ലായ്മകളും കണ്ടെത്തി, ചില കാര്യങ്ങളിൽ ആവശ്യകതകൾ മാറ്റിയിട്ടുണ്ട്. ഈ വ്യക്തതകളുടെയും തിരുത്തലുകളുടെയും വിശദമായ വിവരണം RFC 1122-ൽ നൽകിയിരിക്കുന്നു. പ്രോട്ടോക്കോൾ വിപുലീകരണങ്ങൾ RFC 1323-ൽ നൽകിയിരിക്കുന്നു.

ടിസിപി പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്ന എല്ലാ മെഷീനുകൾക്കും ഒരു ടിസിപി ട്രാൻസ്പോർട്ട് എന്റിറ്റി ഉണ്ട്, അത് ഒന്നുകിൽ ലൈബ്രറി നടപടിക്രമമോ ഉപയോക്തൃ പ്രക്രിയയോ അല്ലെങ്കിൽ സിസ്റ്റം കേർണലിന്റെ ഭാഗമോ ആണ്. ഏത് സാഹചര്യത്തിലും, ട്രാൻസ്പോർട്ട് എന്റിറ്റി ടിസിപി ഫ്ലോകളും ഐപി ലെയറിലേക്കുള്ള ഇന്റർഫേസും നിയന്ത്രിക്കുന്നു. ടിസിപി എന്റിറ്റിക്ക് ലോക്കൽ പ്രോസസുകളിൽ നിന്ന് ഉപയോക്തൃ ഡാറ്റ സ്ട്രീമുകൾ ലഭിക്കുന്നു, അവയെ 64 കെബിയിൽ കൂടാത്ത ഭാഗങ്ങളായി വിഭജിക്കുന്നു (പ്രായോഗികമായി, ഈ നമ്പർ സാധാരണയായി 460 ബൈറ്റുകളുടെ ഡാറ്റയാണ്, ഇത് ഒരു ഇഥർനെറ്റ് ഫ്രെയിമിൽ ഐപി, ടിസിപി തലക്കെട്ടുകൾ എന്നിവ ഉപയോഗിച്ച് സ്ഥാപിക്കാൻ അനുവദിക്കുന്നു), അവയെ പ്രത്യേക IP ഡാറ്റാഗ്രാമുകളായി അയയ്ക്കുകയും ചെയ്യുന്നു. ടിസിപി ഡാറ്റയുള്ള ഐപി ഡാറ്റാഗ്രാമുകൾ മെഷീനിൽ എത്തുമ്പോൾ, അവ ടിസിപി എന്റിറ്റിയിലേക്ക് കൈമാറ്റം ചെയ്യപ്പെടുന്നു, അത് യഥാർത്ഥ ബൈറ്റ് സ്ട്രീം പുനർനിർമ്മിക്കുന്നു. ലാളിത്യത്തിനായി, ടിസിപി ട്രാൻസ്പോർട്ട് എന്റിറ്റി (സോഫ്റ്റ്‌വെയറിന്റെ ഒരു ഭാഗം) അല്ലെങ്കിൽ ടിസിപി പ്രോട്ടോക്കോൾ (നിയമങ്ങളുടെ ഒരു കൂട്ടം) എന്നിവയെ പരാമർശിക്കാൻ ഞങ്ങൾ ചിലപ്പോൾ "TCP" ഉപയോഗിക്കും. എന്താണ് ഉദ്ദേശിക്കുന്നതെന്ന് സന്ദർഭത്തിൽ നിന്ന് വ്യക്തമാകും. ഉദാഹരണത്തിന്, "ഉപയോക്താവ് TCP ഡാറ്റ കൈമാറുന്നു" എന്ന പദപ്രയോഗത്തിൽ TCP എന്ന ട്രാൻസ്പോർട്ട് എന്റിറ്റി സ്വാഭാവികമായും സൂചിപ്പിച്ചിരിക്കുന്നു.

ഡാറ്റാഗ്രാമുകളുടെ ശരിയായ ഡെലിവറിക്ക് IP ലെയർ ഉറപ്പുനൽകുന്നില്ല, അതിനാൽ TCP കാലഹരണപ്പെട്ട സമയപരിധി നിരീക്ഷിക്കുകയും ആവശ്യമെങ്കിൽ പാക്കറ്റുകൾ വീണ്ടും സംപ്രേക്ഷണം ചെയ്യുകയും വേണം. ചിലപ്പോൾ ഡാറ്റാഗ്രാമുകൾ തെറ്റായ ക്രമത്തിൽ എത്തുന്നു. അത്തരം ഡാറ്റാഗ്രാമുകളിൽ നിന്നുള്ള സന്ദേശങ്ങൾ വീണ്ടെടുക്കുന്നതിനുള്ള ഉത്തരവാദിത്തവും ടിസിപിക്കാണ്. അതിനാൽ, ഐപി നൽകാത്ത പല ഉപയോക്താക്കളും ആഗ്രഹിക്കുന്ന വിശ്വാസ്യത നൽകാൻ ടിസിപി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു.

TCP സേവന മോഡൽ

അയച്ചയാളും സ്വീകർത്താവും സൃഷ്‌ടിച്ച സോക്കറ്റുകൾ (സോക്കറ്റുകൾ അല്ലെങ്കിൽ എൻഡ്‌പോയിന്റുകൾ) അടിസ്ഥാനമാക്കിയുള്ളതാണ് TCP സേവനം. ബെർക്ക്‌ലി സോക്കറ്റ്‌സ് വിഭാഗത്തിൽ അവ ചർച്ച ചെയ്യപ്പെട്ടു. ഓരോ സോക്കറ്റിനും ഹോസ്റ്റിന്റെ IP വിലാസവും പോർട്ട് എന്ന് വിളിക്കപ്പെടുന്ന ഹോസ്റ്റിന് ലോക്കൽ ആയ 16-ബിറ്റ് നമ്പറും അടങ്ങുന്ന ഒരു നമ്പർ (വിലാസം) ഉണ്ട്. ടിസിപിയിലെ ഒരു പോർട്ടിനെ ടിഎസ്എപി വിലാസം എന്ന് വിളിക്കുന്നു. TCP സേവനം ആക്സസ് ചെയ്യുന്നതിന്, അയയ്ക്കുന്ന മെഷീനിലെ ഒരു സോക്കറ്റും സ്വീകർത്താവിന്റെ മെഷീനിലെ ഒരു സോക്കറ്റും തമ്മിൽ ഒരു കണക്ഷൻ വ്യക്തമായി സ്ഥാപിച്ചിരിക്കണം.

ഒരേസമയം ഒന്നിലധികം കണക്ഷനുകൾക്കായി ഒരു സോക്കറ്റ് ഉപയോഗിക്കാം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, രണ്ടോ അതിലധികമോ കണക്ഷനുകൾ ഒരേ സോക്കറ്റിൽ അവസാനിക്കും. കണക്ഷനുകളെ രണ്ടറ്റത്തും സോക്കറ്റ് ഐഡികൾ കൊണ്ട് വേർതിരിച്ചിരിക്കുന്നു - (സോക്കറ്റ്1, സോക്കറ്റ്2). വെർച്വൽ ചാനൽ നമ്പറുകളോ മറ്റ് ഐഡന്റിഫയറുകളോ ഉപയോഗിക്കുന്നില്ല.

ജനപ്രിയ പോർട്ടുകൾ എന്ന് വിളിക്കപ്പെടുന്ന 1024-ന് താഴെയുള്ള പോർട്ട് നമ്പറുകൾ സ്റ്റാൻഡേർഡ് സേവനങ്ങളാൽ റിസർവ് ചെയ്തിരിക്കുന്നു. ഉദാഹരണത്തിന്, FTP ഉപയോഗിച്ച് ഫയൽ ട്രാൻസ്ഫർ ചെയ്യുന്നതിനായി ഒരു ഹോസ്റ്റിലേക്ക് കണക്റ്റുചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഏതൊരു പ്രക്രിയയ്ക്കും ഡെസ്റ്റിനേഷൻ ഹോസ്റ്റിന്റെ പോർട്ട് 21-നെ ബന്ധപ്പെടാനും അതിലൂടെ അതിന്റെ FTP ഡെമണുമായി ബന്ധപ്പെടാനും കഴിയും. ജനപ്രിയ തുറമുഖങ്ങളുടെ ഒരു ലിസ്റ്റ് www.iana.org എന്ന വെബ്‌സൈറ്റിൽ നൽകിയിരിക്കുന്നു.

നമുക്ക് തീർച്ചയായും, ബൂട്ട് സമയത്ത് പോർട്ട് 21-ലേക്ക് FTP ഡെമൺ ബൈൻഡ് ചെയ്യാം, തുടർന്ന് ടെൽനെറ്റ് ഡെമൺ പോർട്ട് 23-ലേക്ക് ബൈൻഡ് ചെയ്യാം. എന്നിരുന്നാലും, അങ്ങനെ ചെയ്താൽ, ഡെമണുകളെ കുറിച്ചുള്ള വിവരങ്ങൾ ഉപയോഗിച്ച് നമുക്ക് മെമ്മറി പാഴാക്കുകയേയുള്ളൂ. , അവർ മിക്ക സമയത്തും വെറുതെയിരിക്കും. പകരം, UNIX-ൽ inetd എന്ന് വിളിക്കപ്പെടുന്ന ഒരൊറ്റ ഡെമൺ ഉപയോഗിക്കുന്നത് സാധാരണമാണ്, അത് ഒന്നിലധികം പോർട്ടുകളുമായി ആശയവിനിമയം നടത്തുകയും ആദ്യത്തെ ഇൻകമിംഗ് കണക്ഷനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു. ഇത് സംഭവിക്കുമ്പോൾ, inetd ഒരു പുതിയ പ്രോസസ്സ് സൃഷ്ടിക്കുകയും അഭ്യർത്ഥന കൈകാര്യം ചെയ്യാൻ ഉചിതമായ ഡെമൺ ആവശ്യപ്പെടുകയും ചെയ്യുന്നു. അങ്ങനെ, inetd മാത്രം നിരന്തരം സജീവമാണ്, മറ്റുള്ളവർക്ക് ജോലി ഉള്ളപ്പോൾ മാത്രമേ വിളിക്കൂ. Inetd-ന് ഒരു പ്രത്യേക കോൺഫിഗറേഷൻ ഫയൽ ഉണ്ട്, അതിൽ നിന്ന് പോർട്ട് അസൈൻമെന്റുകളെക്കുറിച്ച് പഠിക്കാനാകും. ഇതിനർത്ഥം സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർക്ക് സിസ്റ്റം കോൺഫിഗർ ചെയ്യാൻ കഴിയും, അങ്ങനെ സ്ഥിരമായ ഡെമണുകൾ ഏറ്റവും തിരക്കേറിയ പോർട്ടുകളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു (ഉദാഹരണത്തിന്, 80), ബാക്കിയുള്ളവയുമായി inetd ബന്ധപ്പെട്ടിരിക്കുന്നു.

ചില റിസർവ്ഡ് പോർട്ടുകൾ
	പ്രോട്ടോക്കോൾ	ഉപയോഗം
21	FTP	ഫയലുകൾ കൈമാറുന്നു
23	ടെൽനെറ്റ്	റിമോട്ട് ലോഗിൻ
25	SMTP	ഇമെയിൽ
69	TFTP	ഏറ്റവും ലളിതമായ ഫയൽ ട്രാൻസ്ഫർ പ്രോട്ടോക്കോൾ
79	വിരല്	ഉപയോക്തൃ വിവരങ്ങൾക്കായി തിരയുന്നു
80	HTTP	വേൾഡ് വൈഡ് വെബ്
110	POP-3	വിദൂര ഇമെയിൽ ആക്സസ്
119	എൻ.എൻ.ടി.പി	ന്യൂസ് ഗ്രൂപ്പുകൾ

എല്ലാ ടിസിപി കണക്ഷനുകളും ഫുൾ ഡ്യുപ്ലെക്സും പോയിന്റ് ടു പോയിന്റുമാണ്. ഫുൾ ഡ്യൂപ്ലെക്സ് എന്നാൽ ട്രാഫിക്കിന് ഒരേ സമയം എതിർദിശകളിലേക്ക് ഒഴുകാൻ കഴിയും എന്നാണ്. ഒരു പോയിന്റ്-ടു-പോയിന്റ് കണക്ഷൻ അർത്ഥമാക്കുന്നത് അതിന് രണ്ട് എൻഡ് പോയിന്റുകൾ ഉണ്ടെന്നാണ്. പ്രക്ഷേപണവും മൾട്ടികാസ്റ്റിംഗും TCP പിന്തുണയ്ക്കുന്നില്ല.

ഒരു TCP കണക്ഷൻ ഒരു ബൈറ്റ് സ്ട്രീം ആണ്, ഒരു സന്ദേശ സ്ട്രീം അല്ല. സന്ദേശങ്ങൾക്കിടയിലുള്ള അതിർത്തികൾ സംരക്ഷിക്കപ്പെട്ടിട്ടില്ല. ഉദാഹരണത്തിന്, ഒരു അയയ്ക്കൽ പ്രക്രിയ ഒരു ടിസിപി സ്ട്രീമിലേക്ക് നാല് 512-ബൈറ്റ് കഷണങ്ങൾ ഡാറ്റ എഴുതുകയാണെങ്കിൽ, ആ ഡാറ്റ സ്വീകരിക്കുന്ന പ്രക്രിയയിലേക്ക് നാല് 512-ബൈറ്റ് ചങ്കുകൾ, രണ്ട് 1024-ബൈറ്റ് ചങ്കുകൾ, ഒരു 2048-ബൈറ്റ് ചങ്ക് അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും ആയി ഡെലിവർ ചെയ്തേക്കാം. വേറെ. ഡാറ്റ എങ്ങനെയാണ് എഴുതിയതെന്ന് നിർണ്ണയിക്കാൻ സ്വീകർത്താവിന് ഒരു മാർഗവുമില്ല.

UNIX സിസ്റ്റത്തിലുള്ള ഫയലുകൾക്കും ഈ പ്രോപ്പർട്ടി ഉണ്ട്. ഈ ഫയൽ എങ്ങനെയാണ് എഴുതിയതെന്ന് റെയിൽ വായിക്കുന്ന പ്രോഗ്രാമിന് നിർണ്ണയിക്കാൻ കഴിയില്ല: ബ്ലോക്ക്-ബൈ-ബ്ലോക്ക്, ബൈറ്റ്-ബൈ-ബൈറ്റ് അല്ലെങ്കിൽ പൂർണ്ണമായും ഒരേസമയം. UNIX സിസ്റ്റം ഫയലുകൾ പോലെ, TCP പ്രോഗ്രാമുകൾക്ക് ബൈറ്റുകളുടെ അർത്ഥത്തെക്കുറിച്ച് യാതൊരു ആശയമോ ശ്രദ്ധയോ ഇല്ല. അവർക്ക് ഒരു ബൈറ്റ് ഒരു ബൈറ്റ് മാത്രമാണ്.

ടിസിപിക്ക് ഒരു ആപ്ലിക്കേഷനിൽ നിന്ന് ഡാറ്റ ലഭിച്ചുകഴിഞ്ഞാൽ, അത് ഒറ്റയടിക്ക് അയയ്‌ക്കാം അല്ലെങ്കിൽ അത് തിരഞ്ഞെടുക്കുന്നതുപോലെ ഒരു വലിയ ഭാഗം ഡാറ്റ ഒരേസമയം അയയ്ക്കാൻ ബഫർ ചെയ്യാം. എന്നിരുന്നാലും, ചിലപ്പോൾ ഒരു അപ്ലിക്കേഷന് ഉടൻ തന്നെ ഡാറ്റ അയയ്ക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ഒരു ഉപയോക്താവ് റിമോട്ട് മെഷീനിൽ ലോഗിൻ ചെയ്യുന്നു എന്ന് പറയാം. അവൻ ഒരു കമാൻഡ് നൽകി എന്റർ കീ അമർത്തിയാൽ, അടുത്ത ലൈൻ നൽകുന്നതുവരെ ബഫർ ചെയ്യുന്നതിനുപകരം, അവൻ നൽകുന്ന ലൈൻ ഉടൻ തന്നെ റിമോട്ട് മെഷീനിലേക്ക് ഡെലിവർ ചെയ്യുന്നത് പ്രധാനമാണ്. കാലതാമസമില്ലാതെ ഡാറ്റ കൈമാറാൻ നിർബന്ധിതമാക്കുന്നതിന്, ഒരു അപ്ലിക്കേഷന് പുഷ് ഫ്ലാഗ് സജ്ജീകരിക്കാനാകും.

ചില പഴയ ആപ്ലിക്കേഷനുകൾ ഒരു സന്ദേശ ഡിലിമിറ്ററായി പുഷ് ഫ്ലാഗ് ഉപയോഗിച്ചു. ഈ ട്രിക്ക് ചിലപ്പോൾ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, എല്ലാ TCP നടപ്പിലാക്കലുകളും സ്വീകരിക്കുന്ന ആപ്ലിക്കേഷനിലേക്ക് പുഷ് ഫ്ലാഗ് കൈമാറുന്നില്ല. കൂടാതെ, ആദ്യ പുഷ് പാക്കറ്റ് ലൈനിൽ അയയ്‌ക്കുന്നതിന് മുമ്പ് TCP എന്റിറ്റിക്ക് അത്തരം നിരവധി പാക്കറ്റുകൾ ലഭിക്കുകയാണെങ്കിൽ (അതായത്, ഔട്ട്‌പുട്ട് ലൈൻ തിരക്കിലാണ്), ഈ ഡാറ്റയെല്ലാം ഒരൊറ്റ ഡാറ്റാഗ്രാമായി അയയ്‌ക്കാൻ TCP എന്റിറ്റിക്ക് അവകാശമുണ്ട്, അവയെ പ്രത്യേക ഭാഗങ്ങളായി വിഭജിക്കുന്നില്ല.

എടുത്തുപറയേണ്ട TCP സേവനത്തിന്റെ അവസാനത്തെ സവിശേഷത അടിയന്തിര ഡാറ്റയാണ്. ഒരു പ്രോഗ്രാമുമായി സംവദിക്കുന്ന ഒരു ഉപയോക്താവ് സംവേദനാത്മകമായി Delete അല്ലെങ്കിൽ Ctrl-C അമർത്തുമ്പോൾ, അത് പുരോഗമിക്കുന്ന ഒരു റിമോട്ട് പ്രോസസ്സ് നിർത്തലാക്കുമ്പോൾ, അയയ്‌ക്കുന്ന ആപ്ലിക്കേഷൻ ഔട്ട്‌പുട്ട് ഡാറ്റ സ്ട്രീമിൽ വിവരങ്ങൾ നിയന്ത്രിക്കുകയും അത് അടിയന്തിര ഫ്ലാഗ് സഹിതം TCP സേവനത്തിലേക്ക് കൈമാറുകയും ചെയ്യുന്നു. ഈ ഫ്ലാഗ് ടിസിപി എന്റിറ്റിയെ ഡാറ്റ ശേഖരിക്കുന്നത് നിർത്തുകയും നെറ്റ്‌വർക്കിലേക്കുള്ള കണക്ഷനുള്ളതെന്തും ഉടൻ പുറത്തുവിടുകയും ചെയ്യുന്നു.

അടിയന്തിര ഡാറ്റ അതിന്റെ ലക്ഷ്യസ്ഥാനത്ത് എത്തുമ്പോൾ, സ്വീകരിക്കുന്ന ആപ്ലിക്കേഷൻ തടസ്സപ്പെടും (അതായത്, UNIX ടെർമിനോളജിയിൽ "സിഗ്നൽ"), അതിനുശേഷം ഇൻപുട്ട് സ്ട്രീമിൽ നിന്നുള്ള ഡാറ്റ വായിക്കാനും അവയ്ക്കിടയിൽ അടിയന്തിര ഡാറ്റ തിരയാനും കഴിയും. അടിയന്തര ഡാറ്റയുടെ അവസാനം അടയാളപ്പെടുത്തിയിരിക്കുന്നതിനാൽ അത് എവിടെയാണ് അവസാനിക്കുന്നതെന്ന് അപ്ലിക്കേഷന് തിരിച്ചറിയാനാകും. അടിയന്തിര ഡാറ്റയുടെ ആരംഭം അടയാളപ്പെടുത്തിയിട്ടില്ല. ആപ്ലിക്കേഷൻ അത് സ്വന്തമായി കണ്ടെത്തണം. ഈ സർക്യൂട്ട് ഒരു ക്രൂഡ് സിഗ്നലിംഗ് സംവിധാനം നൽകുന്നു, മറ്റെല്ലാം ആപ്ലിക്കേഷനിലേക്ക് വിട്ടുകൊടുക്കുന്നു.

TCP പ്രോട്ടോക്കോൾ

ഈ വിഭാഗം TCP പ്രോട്ടോക്കോൾ പൊതുവായി ചർച്ച ചെയ്യും. അടുത്ത വിഭാഗത്തിൽ, ഞങ്ങൾ പ്രോട്ടോക്കോൾ തലക്കെട്ട്, ഫീൽഡ് ബൈ ഫീൽഡ് ചർച്ച ചെയ്യും.

മുഴുവൻ പ്രോട്ടോക്കോൾ ഘടനയും നിർവചിക്കുന്ന TCP-യുടെ ഒരു പ്രധാന പ്രോപ്പർട്ടി ഒരു TCP കണക്ഷനിൽ, ഓരോ ബൈറ്റിനും അതിന്റേതായ 32-ബിറ്റ് സീക്വൻസ് നമ്പർ ഉണ്ട് എന്നതാണ്. ഇന്റർനെറ്റിന്റെ ആദ്യ വർഷങ്ങളിൽ, വാടകയ്‌ക്കെടുത്ത ലൈനുകളിൽ റൂട്ടറുകൾ തമ്മിലുള്ള അടിസ്ഥാന ഡാറ്റ കൈമാറ്റ വേഗത 56 Kbps ആയിരുന്നു. ഉയർന്ന വേഗതയിൽ ഡാറ്റ നിരന്തരം പമ്പ് ചെയ്യുന്ന ഒരു ഹോസ്റ്റിന്, സീക്വൻസ് നമ്പറുകൾ പൂർണ്ണമായി വരാൻ ഒരാഴ്ചയിലധികം എടുക്കും. നിലവിലെ വേഗതയിൽ, സീക്വൻസ് നമ്പറുകൾ വളരെ വേഗത്തിൽ തീർന്നുപോകും, ​​ഇത് പിന്നീട് കൂടുതൽ. അംഗീകാരത്തിനും സ്ലൈഡിംഗ് വിൻഡോ മെക്കാനിസത്തിനും പ്രത്യേക 32-ബിറ്റ് സീക്വൻസ് നമ്പറുകൾ ഉപയോഗിക്കുന്നു, അത് പിന്നീട് ചർച്ചചെയ്യും.

അയയ്‌ക്കുന്നതും സ്വീകരിക്കുന്നതുമായ ടിസിപി എന്റിറ്റികൾ സെഗ്‌മെന്റുകളുടെ രൂപത്തിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നു. ഒരു സെഗ്‌മെന്റിൽ ഒരു നിശ്ചിത 20-ബൈറ്റ് തലക്കെട്ട് (കൂടാതെ ഒരു ഓപ്‌ഷണൽ ഭാഗം) അടങ്ങിയിരിക്കുന്നു, അതിന് ശേഷം ഡാറ്റ ബൈറ്റുകൾ ഉണ്ടാകാം. സെഗ്‌മെന്റുകളുടെ വലുപ്പം നിർണ്ണയിക്കുന്നത് ടിസിപി സോഫ്‌റ്റ്‌വെയർ ആണ്. ഇതിന് നിരവധി റൈറ്റ് പ്രവർത്തനങ്ങളുടെ ഫലമായി ലഭിച്ച ഡാറ്റ ഒരു സെഗ്‌മെന്റിലേക്ക് സംയോജിപ്പിക്കാൻ കഴിയും, അല്ലെങ്കിൽ, ഒരു റൈറ്റിന്റെ ഫലം നിരവധി സെഗ്‌മെന്റുകളിൽ വിതരണം ചെയ്യാൻ കഴിയും. സെഗ്‌മെന്റുകളുടെ വലുപ്പം രണ്ട് പരിധികളാൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ആദ്യം, TCP തലക്കെട്ട് ഉൾപ്പെടെ ഓരോ സെഗ്‌മെന്റും IP പാക്കറ്റിന്റെ 65,515-ബൈറ്റ് പേലോഡ് ഫീൽഡിൽ യോജിക്കണം. രണ്ടാമതായി, ഓരോ നെറ്റ്‌വർക്കിനും പരമാവധി ട്രാൻസ്ഫർ യൂണിറ്റ് (MTU) ഉണ്ട്, ഓരോ സെഗ്‌മെന്റും MTU-ലേക്ക് യോജിച്ചിരിക്കണം. പ്രായോഗികമായി, പരമാവധി ട്രാൻസ്മിഷൻ യൂണിറ്റിന്റെ വലുപ്പം സാധാരണയായി 1500 ബൈറ്റുകൾ ആണ് (ഇത് ഇഥർനെറ്റ് പേലോഡ് ഫീൽഡിന്റെ വലുപ്പവുമായി പൊരുത്തപ്പെടുന്നു), അങ്ങനെ സെഗ്മെന്റ് വലുപ്പത്തിന്റെ ഉയർന്ന പരിധി നിർവചിക്കുന്നു.

TCP എന്റിറ്റികൾ ഉപയോഗിക്കുന്ന പ്രധാന പ്രോട്ടോക്കോൾ സ്ലൈഡിംഗ് വിൻഡോ പ്രോട്ടോക്കോൾ ആണ്. ഒരു സെഗ്മെന്റ് കൈമാറുമ്പോൾ, അയച്ചയാൾ ഒരു ടൈമർ ആരംഭിക്കുന്നു. സെഗ്‌മെന്റ് അതിന്റെ ലക്ഷ്യസ്ഥാനത്ത് എത്തുമ്പോൾ, സ്വീകരിക്കുന്ന ടിസിപി എന്റിറ്റി ഒരു സെഗ്‌മെന്റ് (അയയ്‌ക്കാൻ എന്തെങ്കിലും ഉണ്ടെങ്കിൽ ഡാറ്റ സഹിതം അല്ലെങ്കിൽ ഡാറ്റ ഇല്ലാതെ) നമ്പർ സഹിതം തിരികെ അയയ്‌ക്കുന്നു.

അടുത്ത പ്രതീക്ഷിക്കുന്ന സെഗ്‌മെന്റിന്റെ സീക്വൻസ് നമ്പറിന് തുല്യമായ അംഗീകാരം. അക്‌നോളജ്‌മെന്റ് കാലഹരണപ്പെടൽ കാലഹരണപ്പെടുകയാണെങ്കിൽ, അയച്ചയാൾ സെഗ്‌മെന്റ് വീണ്ടും അയയ്‌ക്കുന്നു.

ഈ പ്രോട്ടോക്കോൾ ലളിതമാണെന്ന് തോന്നുമെങ്കിലും, കൂടുതൽ വിശദമായി പരിശോധിക്കേണ്ട നിരവധി വിശദാംശങ്ങളുണ്ട്. സെഗ്‌മെന്റുകൾ തെറ്റായ ക്രമത്തിൽ എത്തിയേക്കാം. ഉദാഹരണത്തിന്, 3072 മുതൽ 4095 വരെയുള്ള ബൈറ്റുകൾ ഇതിനകം എത്തിയിരിക്കാം, പക്ഷേ 2048 മുതൽ 3071 വരെയുള്ള ബൈറ്റുകൾ ഇതുവരെ ലഭിച്ചിട്ടില്ലാത്തതിനാൽ അവയ്ക്കുള്ള ഒരു അംഗീകാരം അയയ്‌ക്കാനാവില്ല. കൂടാതെ, സെഗ്‌മെന്റുകൾ നെറ്റ്‌വർക്കിൽ വളരെക്കാലം നീണ്ടുനിന്നേക്കാം, അയയ്‌ക്കുന്നയാൾ കാലഹരണപ്പെടുകയും അവ വീണ്ടും കൈമാറുകയും ചെയ്യും. റീട്രാൻസ്മിറ്റ് ചെയ്ത സെഗ്‌മെന്റിൽ വ്യത്യസ്ത ശ്രേണിയിലുള്ള ശകലങ്ങൾ ഉൾപ്പെട്ടേക്കാം, അതിനാൽ ഇതിനകം ലഭിച്ച ബൈറ്റ് നമ്പറുകൾ കൃത്യമായി നിർണ്ണയിക്കാൻ വളരെ ശ്രദ്ധാപൂർവ്വമുള്ള അഡ്മിനിസ്ട്രേഷൻ ആവശ്യമാണ്. എന്നിരുന്നാലും, സ്ട്രീമിലെ ഓരോ ബൈറ്റും അതിന്റെ ഓഫ്‌സെറ്റ് ഉപയോഗിച്ച് അദ്വിതീയമായി തിരിച്ചറിയുന്നതിനാൽ, ഈ ടാസ്‌ക് സാധ്യമാണ്.

ഈ പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യാനും അവ കാര്യക്ഷമമായി പരിഹരിക്കാനും ടിസിപിക്ക് കഴിയണം. ടിസിപി സ്ട്രീമുകളുടെ പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന് വളരെയധികം പരിശ്രമിച്ചു. അടുത്ത വിഭാഗത്തിൽ, ടിസിപി പ്രോട്ടോക്കോളിന്റെ വിവിധ നിർവ്വഹണങ്ങളിൽ ഉപയോഗിക്കുന്ന നിരവധി അൽഗോരിതങ്ങൾ ഞങ്ങൾ ചർച്ച ചെയ്യും.

TCP സെഗ്മെന്റ് തലക്കെട്ട്

ഓരോ സെഗ്‌മെന്റും 20-ബൈറ്റ് ഫിക്‌സഡ് ഫോർമാറ്റ് ഹെഡറിൽ ആരംഭിക്കുന്നു. അതിനു ശേഷം അധിക ഫീൽഡുകൾ വന്നേക്കാം. അധിക ഫീൽഡുകൾക്ക് ശേഷം 65,535 - 20 - 20 = 65,495 ബൈറ്റുകൾ വരെ ഡാറ്റ ഉണ്ടായിരിക്കാം, ഇവിടെ ആദ്യത്തെ 20 ബൈറ്റുകൾ IP തലക്കെട്ടും രണ്ടാമത്തേത് TCP തലക്കെട്ടുമാണ്. സെഗ്‌മെന്റുകളിൽ ഡാറ്റ അടങ്ങിയിരിക്കണമെന്നില്ല. അംഗീകാരങ്ങൾ കൈമാറുന്നതിനും സന്ദേശങ്ങൾ നിയന്ത്രിക്കുന്നതിനും ഇത്തരം സെഗ്‌മെന്റുകൾ ഉപയോഗിക്കാറുണ്ട്.

TCP തലക്കെട്ട് ഫീൽഡ് ബൈ ഫീൽഡ് നോക്കാം. റിസീവർ പോർട്ട്, സോഴ്സ് പോർട്ട് ഫീൽഡുകൾ ലോക്കൽ കണക്ഷൻ എൻഡ് പോയിന്റുകളുടെ ഐഡന്റിഫയറുകളാണ്. ഹോസ്റ്റ് IP വിലാസത്തോടൊപ്പം പോർട്ട് നമ്പറും ഒരു അദ്വിതീയ 48-ബിറ്റ് എൻഡ്‌പോയിന്റ് ഐഡന്റിഫയർ രൂപപ്പെടുത്തുന്നു. ഉറവിടവും ലക്ഷ്യസ്ഥാനവുമായി ബന്ധപ്പെട്ട അത്തരം ഒരു ജോടി ഐഡന്റിഫയറുകൾ കണക്ഷനെ അദ്വിതീയമായി തിരിച്ചറിയുന്നു.

സീക്വൻസ് നമ്പറും സ്ഥിരീകരണ നമ്പർ ഫീൽഡുകളും അവയുടെ സാധാരണ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു. അക്‌നോളജ്‌മെന്റ് നമ്പർ ഫീൽഡ് സൂചിപ്പിക്കുന്നത് പ്രതീക്ഷിക്കുന്ന അടുത്ത ബൈറ്റിനെയാണ്, അവസാനം ലഭിച്ച ബൈറ്റിനെയല്ല. ഒരു TCP സ്ട്രീമിലെ ഡാറ്റയുടെ ഓരോ ബൈറ്റും അക്കമിട്ടിരിക്കുന്നതിനാൽ രണ്ടും 32-ബിറ്റ് ആണ്.

TCP തലക്കെട്ടിന്റെ നീളം ഫീൽഡിൽ TCP തലക്കെട്ടിന്റെ വലിപ്പം അടങ്ങിയിരിക്കുന്നു, 32-ബിറ്റ് വാക്കുകളിൽ പ്രകടിപ്പിക്കുന്നു. ഓപ്ഷണൽ ഫീൽഡ് ഫീൽഡും അതിനൊപ്പം മുഴുവൻ തലക്കെട്ടും വേരിയബിൾ ദൈർഘ്യമുള്ളതാകുമെന്നതിനാൽ ഈ വിവരങ്ങൾ ആവശ്യമാണ്. അടിസ്ഥാനപരമായി, ഈ ഫീൽഡ് സെഗ്‌മെന്റിന്റെ ആരംഭം മുതൽ ഡാറ്റാ ഫീൽഡിലേക്കുള്ള ഓഫ്‌സെറ്റ് വ്യക്തമാക്കുന്നു, ഇത് 32-ബിറ്റ് വാക്കുകളിൽ അളക്കുന്നു. ഇത് ശീർഷകത്തിന്റെ ദൈർഘ്യത്തിന് തുല്യമാണ്.

അടുത്തതായി ഒരു ഉപയോഗിക്കാത്ത 6-ബിറ്റ് ഫീൽഡ് വരുന്നു. കാൽനൂറ്റാണ്ടായി ഈ ഫീൽഡ് നിലനിൽക്കുന്നുവെന്നത് ടിസിപിയുടെ രൂപകല്പന എത്ര നന്നായി ചിന്തിച്ചിട്ടുണ്ടെന്നതിന്റെ തെളിവാണ്.

ഇതിന് ശേഷം ആറ് 1-ബിറ്റ് ഫ്ലാഗുകൾ വരുന്നു. അടിയന്തിര ഡാറ്റാ പോയിന്റർ ഫീൽഡ് ഉപയോഗിക്കുമ്പോൾ URG ബിറ്റ് 1 ആയി സജ്ജീകരിച്ചിരിക്കുന്നു, അതിൽ നിലവിലെ ബൈറ്റ് സീക്വൻസ് നമ്പറിൽ നിന്ന് അടിയന്തിര ഡാറ്റയുടെ സ്ഥാനത്തേക്കുള്ള ബൈറ്റ് ഓഫ്‌സെറ്റ് അടങ്ങിയിരിക്കുന്നു. ഇങ്ങനെയാണ് ടിസിപി തടസ്സ സന്ദേശങ്ങൾ നടപ്പിലാക്കുന്നത്. ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, തടസ്സത്തിന്റെ കാരണത്തിൽ താൽപ്പര്യമില്ലാതെ, സ്വീകർത്താവിന് ഉപയോക്തൃ സിഗ്നൽ ഡെലിവറി മാത്രമേ ടിസിപി പ്രോട്ടോക്കോൾ ഉറപ്പാക്കൂ.

ACK ബിറ്റ് 1 ആയി സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ, അക്നോളജ്‌മെന്റ് നമ്പർ ഫീൽഡിൽ അർത്ഥവത്തായ ഡാറ്റ അടങ്ങിയിരിക്കുന്നു. അല്ലെങ്കിൽ, ഈ സെഗ്‌മെന്റിൽ ഒരു അംഗീകാരം അടങ്ങിയിട്ടില്ല, കൂടാതെ അക്‌നോളജ്‌മെന്റ് നമ്പർ ഫീൽഡ് അവഗണിക്കുകയും ചെയ്യും.

PSH ബിറ്റ് അടിസ്ഥാനപരമായി ഒരു പുഷ് ഫ്ലാഗ് ആണ്, അത് പാക്കറ്റ് ലഭിച്ചയുടൻ ഡാറ്റ ആപ്ലിക്കേഷനിലേക്ക് തള്ളാൻ അയയ്ക്കുന്നയാളോട് പറയുന്നു, അത് നിറയുന്നത് വരെ ഒരു ബഫറിൽ സൂക്ഷിക്കുന്നതിനുപകരം. (കൂടുതൽ കാര്യക്ഷമതയ്ക്കായി സ്വീകർത്താവ് ബഫർ ചെയ്തേക്കാം.)

ഒരു ഹോസ്റ്റ് തകരാർ മൂലമോ മറ്റ് കാരണങ്ങളാലോ ഡെഡ്‌ലോക്ക് ആയ കണക്ഷന്റെ അവസ്ഥ പുനഃസജ്ജമാക്കാൻ RST ബിറ്റ് ഉപയോഗിക്കുന്നു. ഒരു അസാധുവായ സെഗ്‌മെന്റ് നിരസിക്കുന്നതിനും അല്ലെങ്കിൽ ഒരു കണക്ഷൻ സൃഷ്ടിക്കാനുള്ള ശ്രമത്തിനും ഇത് ഉപയോഗിക്കുന്നു. നിങ്ങൾക്ക് RST ബിറ്റ് സെറ്റ് ഉള്ള ഒരു സെഗ്മെന്റ് ലഭിക്കുകയാണെങ്കിൽ, ചില പ്രശ്നമുണ്ട്.

ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ SYN ബിറ്റ് ഉപയോഗിക്കുന്നു. ഒരു കണക്ഷൻ അഭ്യർത്ഥനയിൽ SYN ബിറ്റ് = 1 ഉം ACK ബിറ്റ് = 0 ഉം ഉണ്ട്, അതായത് അംഗീകാര ഫീൽഡ് ഉപയോഗിക്കുന്നില്ല എന്നാണ്. ഈ അഭ്യർത്ഥനയ്ക്കുള്ള പ്രതികരണത്തിൽ ഒരു അംഗീകാരം അടങ്ങിയിരിക്കുന്നു, അതിനാൽ ഈ ബിറ്റുകളുടെ മൂല്യങ്ങൾ ഇവയാണ്: SYN= 1, ACK- 1. അതിനാൽ, കണക്ഷൻ അഭ്യർത്ഥനയും കണക്ഷൻ അംഗീകരിച്ച സെഗ്‌മെന്റുകളും സൂചിപ്പിക്കാൻ SYN ബിറ്റ് ഉപയോഗിക്കുന്നു, കൂടാതെ ACK ബിറ്റ് ഉപയോഗിക്കുന്നു അവരെ പരസ്പരം വേർതിരിച്ചറിയാൻ.

കണക്ഷൻ അവസാനിപ്പിക്കാൻ FIN ബിറ്റ് ഉപയോഗിക്കുന്നു. അയച്ചയാൾക്ക് കൈമാറാൻ കൂടുതൽ ഡാറ്റയില്ലെന്ന് ഇത് സൂചിപ്പിക്കുന്നു. എന്നിരുന്നാലും, കണക്ഷൻ അവസാനിപ്പിച്ചതിന് ശേഷവും, പ്രക്രിയ അനിശ്ചിതമായി ഡാറ്റ സ്വീകരിക്കുന്നത് തുടരാം. FIN, SYN ബിറ്റുകൾ ഉള്ള സെഗ്‌മെന്റുകൾക്ക് അവ ശരിയായ ക്രമത്തിൽ നടപ്പിലാക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ സീക്വൻസ് നമ്പറുകളുണ്ട്.

ടിസിപി പ്രോട്ടോക്കോളിലെ ഫ്ലോ നിയന്ത്രണം വേരിയബിൾ വലുപ്പമുള്ള ഒരു സ്ലൈഡിംഗ് വിൻഡോ ഉപയോഗിച്ചാണ് നടത്തുന്നത്. അക്‌നോളജ്‌മെന്റ് ബൈറ്റിന് ശേഷം എത്ര ബൈറ്റുകൾ അയയ്ക്കാമെന്ന് വിൻഡോ സൈസ് ഫീൽഡ് പറയുന്നു. വിൻഡോ സൈസ് ഫീൽഡിന്റെ മൂല്യം പൂജ്യമായിരിക്കാം, അതിനർത്ഥം അക്നോളജ്‌മെന്റ് നമ്പർ-1 വരെയുള്ള എല്ലാ ബൈറ്റുകളും ലഭിച്ചു, എന്നാൽ സ്വീകർത്താവിന് നിലവിൽ ചില പ്രശ്‌നങ്ങൾ ഉള്ളതിനാൽ ശേഷിക്കുന്ന ബൈറ്റുകൾ ഇതുവരെ സ്വീകരിക്കാൻ കഴിയില്ല. അതേ അക്‌നോളജ്‌മെന്റ് നമ്പർ ഫീൽഡ് മൂല്യവും പൂജ്യമല്ലാത്ത വിൻഡോ സൈസ് ഫീൽഡ് മൂല്യവും ഉള്ള ഒരു സെഗ്‌മെന്റ് അയച്ചുകൊണ്ട് തുടർന്നുള്ള പ്രക്ഷേപണത്തിനുള്ള അനുമതി ലഭിക്കും.

ചില പ്രോട്ടോക്കോളുകളിൽ, ട്രാൻസ്മിഷൻ തുടരാനുള്ള അനുമതികളുമായി ഫ്രെയിം അക്നോളജ്മെന്റുകൾ ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ പ്രോട്ടോക്കോളുകളിൽ കർശനമായി ഉറപ്പിച്ച സ്ലൈഡിംഗ് വിൻഡോ വലുപ്പത്തിന്റെ അനന്തരഫലമാണ് ഈ ബന്ധം. TCP-യിൽ, ഡാറ്റ ട്രാൻസ്മിറ്റ് ചെയ്യുന്നതിനുള്ള അനുമതികളിൽ നിന്ന് അംഗീകാരങ്ങൾ വേർതിരിച്ചിരിക്കുന്നു. സാരാംശത്തിൽ, റിസീവർ ഇങ്ങനെ പറഞ്ഞേക്കാം, "എനിക്ക് k-ro വരെ ബൈറ്റുകൾ ലഭിച്ചു, പക്ഷേ ഇപ്പോൾ ഡാറ്റ സ്വീകരിക്കുന്നത് തുടരാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല." ഈ വിഭജനം (വേരിയബിൾ വലുപ്പത്തിന്റെ ഒരു സ്ലൈഡിംഗ് വിൻഡോ ആയി പ്രകടിപ്പിക്കുന്നു) പ്രോട്ടോക്കോളിന് അധിക വഴക്കം നൽകുന്നു. ഈ വശം ഞങ്ങൾ കൂടുതൽ വിശദമായി ചുവടെ ചർച്ച ചെയ്യും.

വിശ്വാസ്യത വർദ്ധിപ്പിക്കുന്നതിന് ചെക്ക്സം ഫീൽഡ് ഉപയോഗിക്കുന്നു. ഇതിൽ ഹെഡർ, ഡാറ്റ, സ്യൂഡോ-ഹെഡർ എന്നിവയുടെ ഒരു ചെക്ക്സം അടങ്ങിയിരിക്കുന്നു. കണക്കുകൂട്ടലുകൾ നടത്തുമ്പോൾ, ചെക്ക്സം ഫീൽഡ് പൂജ്യമായി സജ്ജീകരിച്ചിരിക്കുന്നു, കൂടാതെ ഡാറ്റാ ഫീൽഡ് അതിന്റെ നീളം ഒറ്റ സംഖ്യയാണെങ്കിൽ പൂജ്യം ബൈറ്റ് ഉപയോഗിച്ച് പാഡ് ചെയ്യുന്നു. ചെക്ക്സം അൽഗോരിതം എല്ലാ 16-ബിറ്റ് വാക്കുകളും രണ്ടിന്റെ പൂരകത്തിൽ ചേർക്കുന്നു, തുടർന്ന് മൊത്തത്തിലുള്ള പൂരകവും കണക്കാക്കുന്നു. ഫലമായി, സ്വീകർത്താവ് ചെക്ക്സം ഫീൽഡ് ഉൾപ്പെടെ മുഴുവൻ സെഗ്മെന്റും പരിശോധിക്കുമ്പോൾ, ഫലം 0 ആയിരിക്കണം.

കപട-ഹെഡറിൽ 32-ബിറ്റ് ഉറവിടവും ലക്ഷ്യസ്ഥാന ഐപി വിലാസങ്ങളും, ടിസിപി (6)-നുള്ള പ്രോട്ടോക്കോൾ നമ്പറും, ടിസിപി സെഗ്‌മെന്റിനുള്ള ബൈറ്റ് എണ്ണവും (ഹെഡർ ഉൾപ്പെടെ) അടങ്ങിയിരിക്കുന്നു. TCP ചെക്ക്‌സത്തിൽ ഒരു വ്യാജ-ഹെഡർ ഉൾപ്പെടുത്തുന്നത് തെറ്റായി വിതരണം ചെയ്ത പാക്കറ്റുകൾ കണ്ടെത്താൻ സഹായിക്കുന്നു, എന്നിരുന്നാലും ഇത് പ്രോട്ടോക്കോൾ ശ്രേണിയെ തകർക്കുന്നു, കാരണം ഇതിലെ IP വിലാസങ്ങൾ IP ലെയറാണ്, TCP ലെയറല്ല. ചെക്ക്‌സമിനായി UDP അതേ വ്യാജ തലക്കെട്ട് ഉപയോഗിക്കുന്നു.

ഓപ്‌ഷണൽ ഫീൽഡ് ഫീൽഡ് സ്റ്റാൻഡേർഡ് ഹെഡറിൽ ഉൾപ്പെടാത്ത അധിക കഴിവുകൾ നൽകുന്നു. ഈ ഫീൽഡുകളിലൊന്ന് ഉപയോഗിച്ച്, ഓരോ ഹോസ്റ്റിനും സ്വീകരിക്കാൻ കഴിയുന്ന പരമാവധി പേലോഡ് ഫീൽഡ് വലുപ്പം വ്യക്തമാക്കാൻ കഴിയും. ഉപയോഗിക്കുന്ന സെഗ്‌മെന്റുകളുടെ വലുപ്പം കൂടുന്തോറും കാര്യക്ഷമത വർദ്ധിക്കും, കാരണം ഇത് 20-ബൈറ്റ് തലക്കെട്ടുകളുടെ ഓവർഹെഡ് കുറയ്ക്കുന്നു, എന്നാൽ എല്ലാ ഹോസ്റ്റുകൾക്കും വളരെ വലിയ സെഗ്‌മെന്റുകൾ സ്വീകരിക്കാൻ കഴിയില്ല. കണക്ഷൻ സജ്ജീകരണ സമയത്ത് ഹോസ്റ്റുകൾക്ക് പരമാവധി പേലോഡ് ഫീൽഡ് വലുപ്പം പരസ്പരം ആശയവിനിമയം നടത്താനാകും. സ്ഥിരസ്ഥിതിയായി ഈ വലുപ്പം 536 ബൈറ്റുകളാണ്. എല്ലാ ഹോസ്റ്റുകളും 536 + 20 = 556 ബൈറ്റുകളുടെ TCP സെഗ്‌മെന്റുകൾ സ്വീകരിക്കേണ്ടതുണ്ട്. ഓരോ ദിശയ്ക്കും അതിന്റേതായ പരമാവധി പേലോഡ് ഫീൽഡ് വലുപ്പം ഉണ്ടായിരിക്കും.

ഉയർന്ന ട്രാൻസ്ഫർ നിരക്കുകളും കൂടാതെ/അല്ലെങ്കിൽ ഉയർന്ന ലേറ്റൻസിയും ഉള്ള ലൈനുകൾക്ക്, 64 KB വിൻഡോ വളരെ ചെറുതാണ്. അങ്ങനെ, ഒരു TZ ലൈനിന് (44.736 Mbit/s), ഒരു പൂർണ്ണ വിൻഡോ വെറും 12 ms-ൽ ലൈനിലേക്ക് കൈമാറാൻ കഴിയും. റൗണ്ട് ട്രിപ്പ് സമയം 50 എംഎസ് ആണെങ്കിൽ (ട്രാൻസ്കോണ്ടിനെന്റൽ ഒപ്റ്റിക്കൽ കേബിളിന് സാധാരണ), അയച്ചയാൾ ഒരു അംഗീകാരത്തിനായി കാത്തിരിക്കുന്ന സമയത്തിന്റെ 3/4. സാറ്റലൈറ്റ് വഴി ആശയവിനിമയം നടത്തുമ്പോൾ, സ്ഥിതി കൂടുതൽ മോശമാകും. ഒരു വലിയ വിൻഡോ വലുപ്പം കാര്യക്ഷമത വർദ്ധിപ്പിക്കും, എന്നാൽ 16-ബിറ്റ് വിൻഡോ സൈസ് ഫീൽഡ് ഇത് അനുവദിക്കുന്നില്ല. RFC 1323 ഒരു പുതിയ വിൻഡോ സ്കെയിൽ പാരാമീറ്റർ നിർദ്ദേശിച്ചു, ഒരു കണക്ഷൻ സ്ഥാപിക്കുമ്പോൾ രണ്ട് ഹോസ്റ്റുകൾ അംഗീകരിക്കുന്ന മൂല്യം. ഈ നമ്പർ വിൻഡോ സൈസ് ഫീൽഡ് ഇടതുവശത്തേക്ക് 14 ബിറ്റുകൾ വരെ മാറ്റാൻ അനുവദിക്കുന്നു, ഇത് വിൻഡോ വലുപ്പം 230 ബൈറ്റുകളായി (1 GB) വികസിപ്പിക്കാൻ അനുവദിക്കുന്നു. നിലവിൽ, മിക്ക TCP പ്രോട്ടോക്കോൾ നടപ്പിലാക്കലുകളും ഈ സവിശേഷതയെ പിന്തുണയ്ക്കുന്നു.

RFC 1106-ൽ നിർദ്ദേശിച്ചിട്ടുള്ളതും ഇപ്പോൾ വ്യാപകമായി ഉപയോഗിക്കുന്നതുമായ മറ്റൊരു ഓപ്ഷൻ, ബാക്ക്‌ട്രാക്കിംഗിന് പകരം സെലക്ടീവ് റീട്രി പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുക എന്നതാണ്. ലക്ഷ്യസ്ഥാനത്ത് ഒരു മോശം സെഗ്‌മെന്റും തുടർന്ന് ധാരാളം നല്ലവയും ലഭിക്കുകയാണെങ്കിൽ, ഒരു സാധാരണ TCP പ്രോട്ടോക്കോൾ കാലക്രമേണ കാലഹരണപ്പെടും. ശരിയായി ലഭിച്ചവ ഉൾപ്പെടെ, അംഗീകരിക്കപ്പെടാത്ത എല്ലാ സെഗ്‌മെന്റുകളും വീണ്ടും പ്രക്ഷേപണം ചെയ്യുക. RFC 1106, ഒരു സെഗ്‌മെന്റോ ഒന്നിലധികം സെഗ്‌മെന്റുകളോ അഭ്യർത്ഥിക്കാൻ സ്വീകർത്താവിനെ അനുവദിക്കുന്നതിന് നെഗറ്റീവ് അക്നോളജ്‌മെന്റുകൾ (NAK) ഉപയോഗിക്കാൻ നിർദ്ദേശിച്ചു. ഒരിക്കൽ ലഭിച്ചുകഴിഞ്ഞാൽ, സ്വീകരിക്കുന്ന കക്ഷിക്ക് ബഫറിൽ സംഭരിച്ചിരിക്കുന്ന എല്ലാ ഡാറ്റയും അംഗീകരിക്കാൻ കഴിയും, അങ്ങനെ വീണ്ടും കൈമാറ്റം ചെയ്യപ്പെടുന്ന ഡാറ്റയുടെ അളവ് കുറയുന്നു.

ആമുഖം

യു‌ഡി‌പി ഒരു ലളിതമായ ഡാറ്റാഗ്രാം-ഓറിയന്റഡ് ട്രാൻസ്‌പോർട്ട് ലെയർ പ്രോട്ടോക്കോൾ ആണ്: ഒരു പ്രോസസ്സ് ഒരു സമയം ഒരു യു‌ഡി‌പി ഡാറ്റാഗ്രാം നൽകുന്നു, അതിന്റെ ഫലമായി ഒരു ഐപി ഡാറ്റാഗ്രാം കൈമാറ്റം ചെയ്യപ്പെടുന്നു. ഇത് TCP പോലുള്ള ഫ്ലോ-ഓറിയന്റഡ് പ്രോട്ടോക്കോളുകൾക്ക് വിരുദ്ധമാണ്, ഇവിടെ ആപ്ലിക്കേഷൻ ഔട്ട്പുട്ട് ചെയ്യുന്ന ഡാറ്റയുടെ അളവിന് അയച്ച ഐപി ഡാറ്റാഗ്രാമുകളുടെ എണ്ണവുമായി ഫലത്തിൽ യാതൊരു ബന്ധവുമില്ല.

ചിത്രം 11.1 ഒരു യുഡിപി ഡാറ്റാഗ്രാം ഒരു ഐപി ഡാറ്റാഗ്രാമിലേക്ക് എൻക്യാപ്സുലേഷൻ കാണിക്കുന്നു.

ചിത്രം 11.1 UDP എൻക്യാപ്സുലേഷൻ.

ഔദ്യോഗിക UDP സ്പെസിഫിക്കേഷൻ RFC 768 [Postel 1980] ൽ നൽകിയിരിക്കുന്നു.

UDP ഒരു വിശ്വസനീയമല്ലാത്ത പ്രോട്ടോക്കോൾ ആണ്: ഇത് ഒരു ആപ്ലിക്കേഷൻ IP ലെയറിലേക്ക് എഴുതുന്ന ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്നു, എന്നാൽ അവ അന്തിമ ലക്ഷ്യസ്ഥാനത്ത് എത്തുമെന്ന് യാതൊരു ഉറപ്പുമില്ല. ഒരു വിശ്വാസ്യതയുടെ കാഴ്ചപ്പാടിൽ, UDP ഉപയോഗിക്കുന്നത് ഒഴിവാക്കാനും എല്ലായ്പ്പോഴും TCP പോലുള്ള വിശ്വസനീയമായ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കാനും നിങ്ങളെ പ്രലോഭിപ്പിച്ചേക്കാം. TCP-ൽ ഉൾപ്പെടുത്തിയ ശേഷം, ഞങ്ങൾ ഈ വിഷയത്തിലേക്ക് മടങ്ങുകയും UDP ഉപയോഗിക്കാവുന്ന തരത്തിലുള്ള ആപ്ലിക്കേഷനുകൾ നോക്കുകയും ചെയ്യും.

തത്ഫലമായുണ്ടാകുന്ന IP ഡാറ്റാഗ്രാമിന്റെ വലുപ്പത്തെക്കുറിച്ച് അപ്ലിക്കേഷനുകൾ വിഷമിക്കേണ്ടതില്ല. തന്നിരിക്കുന്ന നെറ്റ്‌വർക്കിന് MTU-യെക്കാൾ വലിപ്പം കൂടുതലാണെങ്കിൽ (അധ്യായം 2, വിഭാഗം കാണുക), IP ഡാറ്റാഗ്രാം വിഭജിക്കപ്പെടും. അയയ്‌ക്കുന്ന ഹോസ്റ്റ് കണക്‌റ്റ് ചെയ്‌തിരിക്കുന്ന ആദ്യത്തെ നെറ്റ്‌വർക്ക് ഒഴികെ, ഉറവിടത്തിൽ നിന്ന് ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള വഴിയിൽ ഒരു ഡാറ്റാഗ്രാം കടന്നുപോകുന്ന എല്ലാ നെറ്റ്‌വർക്കിനും ഇത് ബാധകമാണ്. (അധ്യായം 2-ലെ ഒരു വിഭാഗത്തിൽ ഗതാഗത MTU എന്ന ആശയം ഞങ്ങൾ നിർവചിച്ചു.) ഈ അധ്യായത്തിലെ ഒരു വിഭാഗത്തിൽ IP വിഘടനം കൂടുതൽ വിശദമായി ചർച്ച ചെയ്യും.

UDP തലക്കെട്ട്

UDP തലക്കെട്ടിലുള്ള ഫീൽഡുകൾ ചിത്രം 11.2 കാണിക്കുന്നു.

ചിത്രം 11.2 UDP തലക്കെട്ട്.

പോർട്ട് നമ്പറുകൾ അയയ്ക്കുന്നതും സ്വീകരിക്കുന്നതുമായ പ്രക്രിയകളെ സൂചിപ്പിക്കുന്നു. ടിസിപിയും യുഡിപിയും ഐപിയിൽ നിന്ന് വരുന്ന ഡാറ്റയെ ഡിമൾട്ടിപ്ലെക്‌സ് ചെയ്യാൻ ഡെസ്റ്റിനേഷൻ പോർട്ട് നമ്പർ ഉപയോഗിക്കുന്നതായി ഇത് കാണിക്കുന്നു. TCP, UDP എന്നിവയ്‌ക്കായുള്ള ഇൻകമിംഗ് IP ഡാറ്റാഗ്രാമുകൾ IP demultiplex ചെയ്യുന്നതിനാൽ (IP തലക്കെട്ടിലെ പ്രോട്ടോക്കോൾ മൂല്യം ഉപയോഗിച്ച്), TCP TCP പോർട്ട് നമ്പറുകളിലേക്കും UDP UDP പോർട്ട് നമ്പറുകളിലേക്കും നോക്കുന്നു. TCP പോർട്ട് നമ്പറുകൾ UDP പോർട്ട് നമ്പറുകളിൽ നിന്ന് സ്വതന്ത്രമാണ്.

ഈ സ്വാതന്ത്ര്യം ഉണ്ടായിരുന്നിട്ടും, ടിസിപിയും യുഡിപിയും ഒരു റിസർവ് ചെയ്ത സേവനം നൽകുന്നുവെങ്കിൽ, രണ്ട് ട്രാൻസ്പോർട്ട് ലെയറുകളിലും ഒരേ പോർട്ട് നമ്പർ തിരഞ്ഞെടുക്കും. ഇത് സൗകര്യത്തിനായാണ് ചെയ്യുന്നത്, പ്രോട്ടോക്കോൾ ആവശ്യകത എന്ന നിലയിലല്ല.

UDP ദൈർഘ്യമുള്ള ഫീൽഡിൽ UDP തലക്കെട്ടിന്റെയും UDP ഡാറ്റയുടെയും ബൈറ്റുകളിലെ ദൈർഘ്യം അടങ്ങിയിരിക്കുന്നു. ഈ ഫീൽഡിന്റെ ഏറ്റവും കുറഞ്ഞ മൂല്യം 8 ബൈറ്റുകളാണ്. (സീറോ ഡാറ്റ ലെങ്ത് ഉള്ള ഒരു യുഡിപി ഡാറ്റഗ്രാം അയച്ചാൽ മോശമായ ഒന്നും സംഭവിക്കില്ല.) യുഡിപി ദൈർഘ്യം പാരാമീറ്റർ അനാവശ്യമാണ്. ഒരു IP ഡാറ്റാഗ്രാമിൽ അതിന്റെ മൊത്തം ദൈർഘ്യം ബൈറ്റുകളിൽ അടങ്ങിയിരിക്കുന്നു, അതിനാൽ ഒരു UDP ഡാറ്റാഗ്രാമിന്റെ ദൈർഘ്യം IP തലക്കെട്ടിന്റെ നീളം മൈനസ് ആണ് (ഇത് ഹെഡർ ലെങ്ത് ഫീൽഡിൽ വ്യക്തമാക്കിയിരിക്കുന്നു).

UDP ചെക്ക്സം

UDP ചെക്ക്സം UDP തലക്കെട്ടും UDP ഡാറ്റയും ഉൾക്കൊള്ളുന്നു. ഐപി ഹെഡറിലെ ചെക്ക്സം ഐപി ഹെഡറിനെ മാത്രമേ ഉൾക്കൊള്ളുന്നുള്ളൂ എന്ന് ഓർക്കുക - ഇത് ഐപി ഡാറ്റാഗ്രാമിൽ അടങ്ങിയിരിക്കുന്ന ഡാറ്റയെ ഉൾക്കൊള്ളുന്നില്ല. യു‌ഡി‌പിയും ടി‌സി‌പിയും അവയുടെ തലക്കെട്ടുകളിൽ ചെക്ക്‌സം ഉൾക്കൊള്ളുന്നു, അത് ഹെഡറും ഡാറ്റയും ഉൾക്കൊള്ളുന്നു. യുഡിപിക്ക് ചെക്ക്സം ഓപ്ഷണലാണ്, എന്നാൽ ടിസിപിക്ക് ഇത് ആവശ്യമാണ്.

വ്യത്യാസങ്ങൾ ഉണ്ടെങ്കിലും (അധ്യായം 3, വിഭാഗം) ഐപി ഹെഡർ ചെക്ക്‌സം (ഓവർഫ്ലോ ഉള്ള 16-ബിറ്റ് പദങ്ങളുടെ ആകെത്തുക) പോലെ തന്നെ UDP ചെക്ക്‌സം കണക്കാക്കുന്നു. ആദ്യം, ഒരു യുഡിപി ഡാറ്റാഗ്രാമിൽ ഒറ്റസംഖ്യ ബൈറ്റുകൾ അടങ്ങിയിരിക്കാം, അതേസമയം ചെക്ക്സം കണക്കുകൂട്ടലിൽ 16-ബിറ്റ് വാക്കുകൾ ചേർക്കുന്നത് ഉൾപ്പെടുന്നു. ചെക്ക്സം കണക്കാക്കാൻ ആവശ്യമെങ്കിൽ ഇത് ഡാറ്റാഗ്രാമിന്റെ അവസാനം സീറോ പാഡിംഗ് ബൈറ്റുകൾ ചേർക്കുന്നു. (പാഡിംഗ് ബൈറ്റുകൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല.)

യു‌ഡി‌പിയിലും ടി‌സി‌പിയിലും, ചെക്ക്‌സം കണക്കാക്കുന്നതിനായി മാത്രം 12-ബൈറ്റ് കപട-ഹെഡറുകൾ (യു‌ഡി‌പി ഡാറ്റാഗ്രാമുകളിലും ടി‌സി‌പി സെഗ്‌മെന്റുകളിലും) ഉണ്ട്. സ്യൂഡോ-ഹെഡറുകളിൽ ഐപി തലക്കെട്ടിൽ നിന്നുള്ള ചില ഫീൽഡുകൾ അടങ്ങിയിരിക്കുന്നു. ഡാറ്റ അതിന്റെ ഉദ്ദേശിച്ച ലക്ഷ്യസ്ഥാനത്ത് എത്തിയിട്ടുണ്ടോ എന്ന് രണ്ടുതവണ പരിശോധിക്കുന്നതിനാണ് ഇതെല്ലാം ചെയ്യുന്നത് (ആ ഹോസ്റ്റിനെ അഭിസംബോധന ചെയ്യാത്ത ഡാറ്റാഗ്രാമുകൾ IP സ്വീകരിക്കില്ല, കൂടാതെ മറ്റൊരു മുകളിലെ ലെയറിനായി ഉദ്ദേശിച്ചിട്ടുള്ള UDP ഡാറ്റാഗ്രാമുകൾ ഫോർവേഡ് ചെയ്യാൻ കഴിയില്ല). ചിത്രം 11.3 കപട തലക്കെട്ടും UDP ഡാറ്റാഗ്രാമും കാണിക്കുന്നു.

ചിത്രം 11.3 UDP ചെക്ക്സം കണക്കാക്കാൻ ഉപയോഗിക്കുന്ന ഫീൽഡുകൾ.

ഈ ചിത്രത്തിൽ, വിചിത്ര ദൈർഘ്യമുള്ള ഒരു ഡാറ്റഗ്രാം ഞങ്ങൾ പ്രത്യേകം കാണിച്ചിട്ടുണ്ട്, ഈ സാഹചര്യത്തിൽ ചെക്ക്സം കണക്കാക്കാൻ ഒരു അധിക ബൈറ്റ് ആവശ്യമാണ്. ചെക്ക്സം കണക്കാക്കുമ്പോൾ UDP ഡാറ്റാഗ്രാം ദൈർഘ്യം രണ്ടുതവണ ദൃശ്യമാകുന്നു എന്നത് ശ്രദ്ധിക്കുക.

കണക്കാക്കിയ ചെക്ക്സം 0 ആണെങ്കിൽ, അത് എല്ലാ ബിറ്റുകളായി (65535) സംഭരിക്കും, ഈ മൂല്യങ്ങൾ വൺസ്-കോംപ്ലിമെന്റ് ഗണിതത്തിൽ തുല്യമാണ്. ട്രാൻസ്മിറ്റ് ചെയ്ത ചെക്ക്സം 0 ആണെങ്കിൽ, അയച്ചയാൾ ചെക്ക്സം കണക്കാക്കിയിട്ടില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്.

അയച്ചയാൾ ചെക്ക്സം കണക്കാക്കുകയും സ്വീകർത്താവ് ഒരു പിശക് ഉണ്ടെന്ന് നിർണ്ണയിക്കുകയും ചെയ്താൽ, യുഡിപി ഡാറ്റഗ്രാം നിശബ്ദമായി നശിപ്പിക്കപ്പെടും, കൂടാതെ ഒരു പിശക് സന്ദേശവും സൃഷ്ടിക്കപ്പെടുന്നില്ല. (ഐപി തലക്കെട്ട് ചെക്ക്‌സമിൽ ഐപി ലെയർ ഒരു പിശക് കണ്ടെത്തിയാൽ ഇതുതന്നെ സംഭവിക്കും.)

യു‌ഡി‌പി ചെക്ക്‌സം അയയ്‌ക്കുന്നയാൾ കണക്കാക്കുകയും സ്വീകർത്താവ് പരിശോധിച്ചുറപ്പിക്കുകയും ചെയ്യുന്നു. അയച്ചയാളും സ്വീകർത്താവും തമ്മിലുള്ള പാതയിൽ യുഡിപി തലക്കെട്ടിലോ ഡാറ്റയിലോ എന്തെങ്കിലും മാറ്റങ്ങൾ നിർണ്ണയിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

UDP ചെക്ക്സം ഒരു ഓപ്ഷണൽ പാരാമീറ്റർ ആണെങ്കിലും, അത് എപ്പോഴും കണക്കുകൂട്ടിയിരിക്കണം. 1980-കളുടെ അവസാനത്തിൽ, ചില കമ്പ്യൂട്ടർ നിർമ്മാതാക്കൾ UDP ഉപയോഗിക്കുന്ന നെറ്റ്‌വർക്ക് ഫയൽ സിസ്റ്റത്തിന്റെ (NFS) വേഗത വർദ്ധിപ്പിക്കുന്നതിന് സ്ഥിരസ്ഥിതിയായി UDP ചെക്ക്സം കണക്കുകൂട്ടൽ പ്രവർത്തനരഹിതമാക്കാൻ തുടങ്ങി. ഡാറ്റാഗ്രാം റൂട്ടറുകളിലൂടെ കടന്നുപോകുമ്പോൾ ഫ്രെയിം കറപ്ഷൻ നിർണ്ണയിക്കാൻ ഉപയോഗിക്കാവുന്ന ഡാറ്റ ലിങ്ക് ലെയറിലെ (ഇഥർനെറ്റ് അല്ലെങ്കിൽ ടോക്കൺ റിംഗ് ഫ്രെയിമുകൾ) ഫ്രെയിമുകൾക്കായി CRC കണക്കാക്കുന്ന ഒരൊറ്റ LAN-ൽ ഇത് സ്വീകാര്യമായേക്കാം. വിശ്വസിച്ചാലും ഇല്ലെങ്കിലും, അവരുടെ സോഫ്റ്റ്‌വെയറിലോ ഹാർഡ്‌വെയറിലോ ബഗുകളുള്ള റൂട്ടറുകൾ അവർ റൂട്ട് ചെയ്യുന്ന ഡാറ്റാഗ്രാമുകളിലെ ബിറ്റുകൾ മാറ്റുന്നു. ചെക്ക്സം ഓപ്‌ഷൻ പ്രവർത്തനരഹിതമാക്കിയാൽ യുഡിപി ഡാറ്റാഗ്രാമിൽ ഈ പിശകുകൾ കണ്ടെത്താനാകില്ല. ചില ലിങ്ക് ലെയർ പ്രോട്ടോക്കോളുകൾക്ക് (ഉദാ. SLIP) ലിങ്കിലെ ഡാറ്റയ്‌ക്കായി ഒരു തരത്തിലുള്ള ചെക്ക്‌സം കണക്കുകൂട്ടലും ഇല്ലെന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്.

UDP ചെക്ക്സം കണക്കുകൂട്ടൽ സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനക്ഷമമാക്കണമെന്ന് ഹോസ്റ്റ് ആവശ്യകതകൾ RFC ആവശ്യപ്പെടുന്നു. അയച്ചയാളാണ് (ലഭിച്ച ചെക്ക്സം പൂജ്യമല്ലെങ്കിൽ) കണക്കാക്കിയതാണെങ്കിൽ ലഭിച്ച ചെക്ക്സം പരിശോധിച്ചുറപ്പിക്കണമെന്നും അവർ ആവശ്യപ്പെടുന്നു. ചില നിർവ്വഹണങ്ങൾ ഇത് അവഗണിക്കുകയും ഔട്ട്ഗോയിംഗ് ചെക്ക്സം കണക്കാക്കുന്നതിനുള്ള ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ ലഭിച്ച ചെക്ക്സം പരിശോധിക്കുകയും ചെയ്യുന്നു.

tcpdump കമാൻഡിന്റെ ഔട്ട്പുട്ട്

ഒരു പ്രത്യേക സിസ്റ്റത്തിൽ UDP ചെക്ക്സം കണക്കുകൂട്ടൽ ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടോ എന്ന് നിർണ്ണയിക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്. സാധാരണഗതിയിൽ, സ്വീകരിച്ച UDP ഹെഡറിന്റെ ചെക്ക്സം ഫീൽഡിലേക്ക് അപ്ലിക്കേഷന് ആക്‌സസ് ഉണ്ടായിരിക്കില്ല. ഈ പ്രശ്നം പരിഹരിക്കാൻ, രചയിതാവ് tcpdump പ്രോഗ്രാമിലേക്ക് മറ്റൊരു ഓപ്ഷൻ ചേർത്തു, അതിനുശേഷം അത് സ്വീകരിച്ച UDP ചെക്ക്സം ഔട്ട്പുട്ട് ചെയ്യാൻ തുടങ്ങി. ലഭിച്ച മൂല്യം 0 ആണെങ്കിൽ, അയച്ചയാൾ ചെക്ക്സം കണക്കാക്കിയിട്ടില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്.

നമ്മുടെ നെറ്റ്‌വർക്കിലെ മൂന്ന് വ്യത്യസ്ത സിസ്റ്റങ്ങളിലേക്കുള്ള ഔട്ട്‌പുട്ട് ചിത്രം 11.4 കാണിക്കുന്നു. ഞങ്ങൾ സോക്ക്() പ്രോഗ്രാം പ്രവർത്തിപ്പിച്ചു, ഒരു സാധാരണ എക്കോ സെർവറിലേക്ക് 9 ബൈറ്റ് ഡാറ്റയുള്ള ഒരൊറ്റ യുഡിപി ഡാറ്റഗ്രാം അയച്ചു.

>

1 0.0 sun.1900 > gemini.echo: udp 9 (UDP cksum=6e90)
2 0.303755 (0.3038) gemini.echo > sun.1900: udp 9 (UDP cksum=0)

3 17.392480 (17.0887) sun.1904 > aix.echo: udp 9 (UDP cksum=6e3b)
4 17.614371 (0.2219) aix.echo > sun.1904: udp 9 (UDP cksum=6e3b)

5 32.092454 (14.4781) sun.1907 > solaris.echo: udp 9 (UDP cksum=6e74)
6 32.314378 (0.2219) solaris.echo > sun.1907: udp 9 (UDP cksum=6e74)

ചിത്രം 11.4 tcpdump-ൽ നിന്നുള്ള ഔട്ട്പുട്ട്, ഒരു പ്രത്യേക ഹോസ്റ്റിൽ UDP ചെക്ക്സം ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടോ എന്ന് നിർണ്ണയിക്കാൻ ഇത് ഉപയോഗിക്കാം.

മൂന്ന് സിസ്റ്റങ്ങളിൽ രണ്ടെണ്ണം UDP ചെക്ക്സം ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെന്ന് ഇവിടെ നിന്ന് നമുക്ക് കാണാൻ കഴിയും.

ഔട്ട്‌ഗോയിംഗ് ഡാറ്റാഗ്രാമിന് ഇൻകമിംഗ് ഡാറ്റാഗ്രാമിന്റെ അതേ ചെക്ക്സം ഉണ്ടെന്നും ശ്രദ്ധിക്കുക (ലൈനുകൾ 3, 4, 5, 6). ചിത്രം 11.3-ൽ, രണ്ട് പോർട്ട് നമ്പറുകൾ പോലെ രണ്ട് IP വിലാസങ്ങളും സ്വാപ്പ് ചെയ്തതായി നിങ്ങൾ ശ്രദ്ധിക്കും. ഡാറ്റ പ്രതിധ്വനിച്ചതിനാൽ കപട-ഹെഡറിലെയും യുഡിപി ഹെഡറിലെയും മറ്റ് ഫീൽഡുകൾ അതേപടി തുടർന്നു. യുഡിപി ചെക്ക്സം (ടിസിപി/ഐപി പ്രോട്ടോക്കോൾ കുടുംബത്തിലെ എല്ലാ ചെക്ക്സംസും) ഒരു ലളിതമായ 16-ബിറ്റ് തുകയാണെന്ന് ഇത് സ്ഥിരീകരിക്കുന്നു. അതിന്റെ സഹായത്തോടെ, രണ്ട് 16-ബിറ്റ് മൂല്യങ്ങളുടെ സ്ഥലങ്ങൾ മാറ്റുന്നത് ഉൾക്കൊള്ളുന്ന ഒരു പിശക് കണ്ടെത്തുന്നത് അസാധ്യമാണ്.

ചില സ്ഥിതിവിവരക്കണക്കുകൾ

40 ദിവസമായി പ്രവർത്തിക്കുന്ന NFS സെർവറിൽ ചെക്ക്‌സം പിശകുകൾ സംഭവിക്കുന്നതിനെക്കുറിച്ചുള്ള ചില സ്ഥിതിവിവരക്കണക്കുകൾ [Mogul 1992] നൽകുന്നു. ചിത്രം 11.5 സ്റ്റാറ്റിസ്റ്റിക്കൽ ഡാറ്റ കാണിക്കുന്നു.

	ചെക്ക്സമുകളിലെ പിശകുകളുടെ എണ്ണം	പാക്കേജുകളുടെ ഏകദേശ എണ്ണം
ഇഥർനെറ്റ്
ഐ.പി
യു.ഡി.പി
ടിസിപി

ചിത്രം 11.5 ചെക്ക്സം ഉപയോഗിച്ച് തിരിച്ചറിഞ്ഞ കേടായ പാക്കറ്റുകളുടെ സ്ഥിതിവിവരക്കണക്കുകൾ.

മറ്റ് പ്രോട്ടോക്കോളുകൾ ഇഥർനെറ്റും ഐപി ലെയറും ഉപയോഗിക്കുന്നതിനാൽ അവസാന നിര പാക്കറ്റുകളുടെ ഏകദേശ എണ്ണം കാണിക്കുന്നു. ഉദാഹരണത്തിന്, എല്ലാ ഇഥർനെറ്റ് ഫ്രെയിമുകളും IP ഡാറ്റാഗ്രാമുകൾ ഉപയോഗിക്കുന്നില്ല; ARP ഇഥർനെറ്റും ഉപയോഗിക്കുന്നു. ഐസിഎംപിയും ഐപി ഉപയോഗിക്കുന്നതിനാൽ എല്ലാ ഐപി ഡാറ്റാഗ്രാമുകളും യുഡിപിയോ ടിസിപിയോ ഉപയോഗിക്കുന്നില്ല.

UDP ചെക്ക്സം പിശകുകളേക്കാൾ കാര്യമായ കൂടുതൽ TCP ചെക്ക്സം പിശകുകൾ കണ്ടെത്തിയതായി ശ്രദ്ധിക്കുക. TCP സാധാരണയായി "ദീർഘ-ദൂര" കണക്ഷനുകൾ (നിരവധി റൂട്ടറുകൾ, പാലങ്ങൾ മുതലായവയിലൂടെ കടന്നുപോകുന്നു) സ്ഥാപിക്കുന്ന വസ്തുതയാണ് ഇതിന് കാരണം, UDP ട്രാഫിക് സാധാരണയായി പ്രാദേശികമാണ്.

അതിനാൽ, താഴത്തെ വരിയിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന പിശകുകൾ എല്ലായ്പ്പോഴും ഡാറ്റ ലിങ്ക് ലെയറുമായി (ഇഥർനെറ്റ്, ടോക്കൺ റിംഗ്) ബന്ധപ്പെട്ടതല്ല. ഡാറ്റ കൈമാറ്റം ചെയ്യുമ്പോൾ, നിങ്ങൾ എല്ലായ്പ്പോഴും അവസാന പോയിന്റുകളിൽ ചെക്ക്സം ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കണം. എന്നിരുന്നാലും, കൈമാറ്റം ചെയ്യപ്പെടുന്ന ഡാറ്റയ്ക്ക് എന്തെങ്കിലും മൂല്യമുണ്ടെങ്കിൽ, നിങ്ങൾ UDP അല്ലെങ്കിൽ TCP ചെക്ക്സം പൂർണ്ണമായും വിശ്വസിക്കരുത്, കാരണം ഇവ ലളിതമായ ചെക്ക്സമുകളായതിനാൽ സാധ്യമായ എല്ലാ പിശകുകളിൽ നിന്നും ഡാറ്റ പരിരക്ഷിക്കുമെന്ന് അവർക്ക് ഉറപ്പില്ല.

ലളിതമായ ഉദാഹരണം

ചില UDP ഡാറ്റാഗ്രാമുകൾ സൃഷ്ടിക്കാൻ ഞങ്ങൾ സോക്ക് പ്രോഗ്രാം ഉപയോഗിക്കും, അത് tcpdump ഉപയോഗിച്ച് ഞങ്ങൾ നോക്കും:

>ബിഎസ്ഡി % സോക്ക് -v -u -i -n4 svr4 നിരസിക്കുക
140.252.13.35.1108 മുതൽ 140.252.13.34.9 വരെ ബന്ധിപ്പിച്ചിരിക്കുന്നു

bsdi % സോക്ക് -v -u -i -n4 -w0 svr4 നിരസിക്കുക
140.252.13.35.1110 മുതൽ 140.252.13.34.9 വരെ ബന്ധിപ്പിച്ചിരിക്കുന്നു

പ്രോഗ്രാം ആരംഭിക്കുന്ന ആദ്യ സന്ദർഭത്തിൽ, ഡീബഗ് മോഡ് സജ്ജീകരിച്ചിരിക്കുന്നു ( -v), നിങ്ങൾക്ക് ചലനാത്മകമായി അസൈൻ ചെയ്‌ത പോർട്ടുകളുടെ നമ്പറുകൾ കാണാൻ കഴിയുമ്പോൾ, സ്ഥിരസ്ഥിതിയായി TCP-ക്ക് പകരം UDP (-u) സൂചിപ്പിക്കുന്നു, കൂടാതെ സോഴ്‌സ് മോഡ് സജ്ജീകരിച്ചിരിക്കുന്നു, ഓപ്ഷൻ ( -i), സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിൽ നിന്ന് വായിക്കുന്നതിനോ സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിലേക്ക് എഴുതുന്നതിനോ പകരം ഞങ്ങൾ ഡാറ്റ അയയ്ക്കും എന്നാണ് ഇതിനർത്ഥം. ഡെസ്റ്റിനേഷൻ ഹോസ്റ്റ് svr4-ലേക്ക് 4 ഡാറ്റാഗ്രാമുകൾ (1024 ന്റെ സ്ഥിരസ്ഥിതിക്ക് പകരം) ഔട്ട്പുട്ട് ചെയ്യാൻ -n4 ഓപ്ഷൻ പറയുന്നു. അദ്ധ്യായം 1-ലെ വിഭാഗത്തിൽ ഡിസ്‌കാർഡ് സേവനം വിവരിച്ചിരിക്കുന്നു. ഓരോ റെക്കോർഡിനും 1024 ബൈറ്റുകൾ എന്ന ഡിഫോൾട്ട് ഔട്ട്‌പുട്ട് വലുപ്പമാണ് ഞങ്ങൾ ഉപയോഗിക്കുന്നത്.

രണ്ടാം തവണ ഞങ്ങൾ പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കുമ്പോൾ, -w0 വ്യക്തമാക്കുന്നു, ഇത് പൂജ്യം നീളമുള്ള ഡാറ്റാഗ്രാമുകൾ നിർമ്മിക്കും. രണ്ട് ഉദാഹരണങ്ങൾക്കായി tcpdump കമാൻഡിന്റെ ഔട്ട്പുട്ട് ചിത്രം 11.6 കാണിക്കുന്നു.

>

1 0.0 bsdi.1108 > svr4. discard: udp 1024
2 0.002424 (0.0024) bsdi.1108 > svr4.discard: udp 1024
3 0.006210 (0.0038) bsdi.1108 > svr4.discard: udp 1024
4 0.010276 (0.0041) bsdi.1108 > svr4.discard: udp 1024

5 41.720114 (41.7098) bsdi.1110 > svr4. discard: udp 0
6 41.721072 (0.0010) bsdi.1110 > svr4. discard: udp 0
7 41.722094 (0.0010) bsdi.1110 > svr4. discard: udp 0
8 41.723070 (0.0010) bsdi.1110 > svr4. discard: udp 0

ചിത്രം 11.6 UDP ഡാറ്റാഗ്രാമുകൾ ഒരു ദിശയിലേക്ക് അയയ്ക്കുമ്പോൾ tcpdump കമാൻഡിന്റെ ഔട്ട്പുട്ട്.

ഔട്ട്‌പുട്ട് നാല് 1024-ബൈറ്റ് ഡാറ്റാഗ്രാമുകളും തുടർന്ന് നാല് സീറോ-ലെങ്ത് ഡാറ്റാഗ്രാമുകളും കാണിക്കുന്നു. ഓരോ ഡാറ്റാഗ്രാമും നിരവധി മില്ലിസെക്കൻഡുകളുടെ ഇടവേളയിൽ മുമ്പത്തേതിനെ പിന്തുടരുന്നു. (രണ്ടാമത്തെ കമാൻഡ് നൽകുന്നതിന് 41 സെക്കൻഡ് എടുത്തു.)

ആദ്യത്തെ ഡാറ്റാഗ്രാം അയയ്ക്കുന്നതിന് മുമ്പ്, അയച്ചയാളും സ്വീകർത്താവും തമ്മിൽ ഒരു ബന്ധവുമില്ല. (ടിസിപിയെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ചർച്ചയിൽ, ഡാറ്റയുടെ ആദ്യ ബൈറ്റ് അയയ്ക്കുന്നതിന് മുമ്പ് ഒരു കണക്ഷൻ സ്ഥാപിക്കണമെന്ന് ഞങ്ങൾ കാണിക്കുന്നു.) ഡാറ്റ സ്വീകരിക്കുമ്പോൾ റിസീവർ ഒരു അംഗീകാരം നൽകുന്നില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അയച്ചയാൾക്ക്, ഈ ഉദാഹരണത്തിൽ, റിമോട്ട് എൻഡിൽ ഡാറ്റ ലഭിച്ചിട്ടുണ്ടോ എന്ന് അറിയില്ല.

അവസാനമായി, നിങ്ങൾ പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കുമ്പോഴെല്ലാം UDP ഉറവിട പോർട്ട് നമ്പർ മാറുന്നത് ശ്രദ്ധിക്കുക. പോർട്ട് ആദ്യം 1108 ആയിരുന്നു, പിന്നീട് 1110. ചാപ്റ്റർ 1 വിഭാഗത്തിൽ, ക്ലയന്റുകൾ ഉപയോഗിക്കുന്ന ഡൈനാമിക് ആയി അസൈൻ ചെയ്‌ത പോർട്ട് നമ്പറുകൾ സാധാരണയായി 1024 മുതൽ 5000 വരെയാണ് എന്ന് ഞങ്ങൾ കാണിച്ചു.

ഐപി വിഘടനം

ചിത്രം 11.9 ഈ കേസിന്റെ ഐസിഎംപി ലഭ്യമല്ലാത്ത പിശക് ഫോർമാറ്റ് കാണിക്കുന്നു. രണ്ടാമത്തെ 32-ബിറ്റ് പദത്തിലെ 16-31 ബിറ്റുകൾക്ക് 0 ആയി സജ്ജീകരിക്കുന്നതിന് പകരം അടുത്ത ഹോപ്പ് MTU അടങ്ങിയിരിക്കാമെന്നതിനാൽ ഇത് കാണിച്ചിരിക്കുന്ന ഫോർമാറ്റിൽ നിന്ന് വ്യത്യസ്തമാണ്.

ചിത്രം 11.9 ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമായി വരുമ്പോൾ ICMP അൺറീച്ച് ചെയ്യാവുന്ന പിശക്, എന്നാൽ "ശകലം ചെയ്യരുത്" ബിറ്റ് സജ്ജീകരിച്ചിരിക്കുന്നു.

റൂട്ടർ ഈ പുതിയ ICMP പിശക് ഫോർമാറ്റിനെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, അടുത്ത ഹോപ്പ് MTU 0 ആയി സജ്ജീകരിച്ചിരിക്കുന്നു.

പുതിയ റൂട്ടർ ആവശ്യകതകൾ RFC [Almquist 1993] ഒരു ICMP ലഭ്യമല്ലാത്ത സന്ദേശം നൽകുമ്പോൾ ഒരു റൂട്ടർ ഈ പുതിയ ഫോം സൃഷ്ടിക്കണമെന്ന് വ്യക്തമാക്കുന്നു.

netb റൂട്ടറും ഹോസ്റ്റ് സൺസും തമ്മിലുള്ള ഒരു SLIP ഡയൽ-അപ്പ് ലിങ്കിന്റെ MTU നിർണ്ണയിക്കാൻ ശ്രമിക്കുന്നതിനിടയിൽ ഒരു ICMP പിശക് ലഭിച്ചപ്പോൾ ഞങ്ങൾ ചർച്ച ചെയ്യുന്ന പ്രശ്നം സംഭവിച്ചു. സൂര്യനിൽ നിന്ന് netb-ലേക്കുള്ള ഈ ലിങ്കിന്റെ MTU നമുക്ക് അറിയാം, കാരണം, ഒന്നാമതായി, ഹോസ്റ്റ് സൺ-ൽ SLIP കോൺഫിഗർ ചെയ്യുമ്പോൾ ഇത് വ്യക്തമാക്കുന്നു, രണ്ടാമതായി, ചാപ്റ്റർ 3-ന്റെ വിഭാഗത്തിൽ netstat കമാൻഡ് പ്രവർത്തിപ്പിച്ചപ്പോൾ MTU കണ്ടു. ഇപ്പോൾ നമുക്ക് നിർണ്ണയിക്കണം. മറ്റൊരു ദിശയിൽ MTU. (എസ്‌എൻ‌എം‌പി ഉപയോഗിച്ച് എം‌ടി‌യു എങ്ങനെ നിർണ്ണയിക്കാമെന്ന് ഇത് വിശദീകരിക്കുന്നു.) പോയിന്റ്-ടു-പോയിന്റ് ലിങ്കുകൾക്ക്, എം‌ടി‌യു രണ്ട് ദിശകളിലും ഒരേപോലെ ആയിരിക്കണമെന്നില്ല.

നിർണ്ണയിക്കാൻ ഇനിപ്പറയുന്ന സാങ്കേതികത ഉപയോഗിച്ചു. ഞങ്ങൾ ഹോസ്റ്റ് സോളാരിസിൽ നിന്ന് ഹോസ്റ്റ് ബിഎസ്ഡിയിലേക്ക് ഒരു പിംഗ് പ്രവർത്തിപ്പിച്ചു, പാക്കറ്റുകളിൽ വിഘടനം പ്രയോഗിക്കുന്നത് വരെ ഡാറ്റ പാക്കറ്റ് വലുപ്പം വർദ്ധിപ്പിച്ചു. പ്രക്രിയ ചിത്രം 11.10 ൽ കാണിച്ചിരിക്കുന്നു.

ചിത്രം 11.10 നെറ്റ്ബിനും സൂര്യനും ഇടയിലുള്ള SLIP ലിങ്കിന്റെ MTU നിർണ്ണയിക്കാൻ ഉപയോഗിച്ച സിസ്റ്റങ്ങൾ.

സൺ ഹോസ്റ്റിൽ tcpdump പ്രോഗ്രാം സമാരംഭിച്ചു, ഇത് SLIP ചാനലിൽ എങ്ങനെ വിഘടനം നടത്തുന്നുവെന്ന് കാണാൻ ഞങ്ങളെ അനുവദിച്ചു. ഫ്രാഗ്‌മെന്റേഷൻ ദൃശ്യമാകില്ല, പിംഗ് പാക്കറ്റിലെ ഡാറ്റാ വലുപ്പം 500 ബൈറ്റുകളിൽ നിന്ന് 600 ആയി വർദ്ധിക്കുന്നത് വരെ എല്ലാം ശരിയായിരുന്നു. ഇൻകമിംഗ് എക്കോ അഭ്യർത്ഥനകൾ ദൃശ്യമായിരുന്നു (ശകലങ്ങൾ ഇല്ലെന്നപോലെ), എന്നാൽ എക്കോ പ്രതികരണങ്ങൾ അപ്രത്യക്ഷമായി.

എന്താണ് സംഭവിക്കുന്നതെന്ന് നന്നായി മനസ്സിലാക്കാൻ, tcpdump bsdi-യിലും പ്രവർത്തിപ്പിച്ചു, അതിനുശേഷം എന്താണ് അയച്ചതെന്നും എന്താണ് സ്വീകരിക്കുന്നതെന്നും വ്യക്തമായി. ചിത്രം 11.11 ഔട്ട്പുട്ട് കാണിക്കുന്നു.

>

1 0.0 സോളാരിസ് >
2 0.000000 (0.0000) bsdi >
3 0.000000 (0.0000) സൂര്യൻ >
ഫ്രാഗ് ചെയ്യണം, mtu = 0 (DF)

4 0.738400 (0.7384) solaris > bsdi: icmp: echo request (DF)
5 0.748800 (0.0104) bsdi > solaris: icmp: echo reply (DF)
6 0.748800 (0.0000) സൂര്യൻ > bsdi: icmp: സോളാരിസ് ലഭ്യമല്ല -
ഫ്രാഗ് ചെയ്യണം, mtu = 0 (DF)

ചിത്രം 11.11 600 ബൈറ്റുകളുടെ ഐപി ഡാറ്റാഗ്രാം വലിപ്പമുള്ള സോളാരിസിൽ നിന്ന് പിങ്ങിൽ നിന്ന് ബിഎസ്ഡിയിലേക്ക് ടിസിപിഡംപ് പ്രോഗ്രാമിന്റെ ഔട്ട്പുട്ട്.

ആദ്യം, ഓരോ വരിയിലും (DF) എന്ന പദപ്രയോഗം അർത്ഥമാക്കുന്നത് IP തലക്കെട്ടിലെ "ശകലം ചെയ്യരുത്" ബിറ്റ് ഒന്നായി സജ്ജീകരിച്ചിരിക്കുന്നു എന്നാണ്. ഇതിനർത്ഥം സോളാരിസ് 2.2 സാധാരണയായി ട്രാൻസ്പോർട്ട് MTU നിർണ്ണയിക്കുന്നതിനുള്ള മെക്കാനിസത്തിന്റെ ഭാഗമായി ഈ ബിറ്റ് ഒന്നായി സജ്ജീകരിക്കുന്നു എന്നാണ്.

വിഘടനം കൂടാതെ ഡിഎഫ് ബിറ്റ് സെറ്റ് ഉപയോഗിച്ച് പിംഗ് നെറ്റ്‌ബിലൂടെ സൂര്യനിലേക്ക് പോകുന്നുവെന്ന് ലൈൻ 1 സൂചിപ്പിക്കുന്നു, അതിനാൽ SLIP ഹോസ്റ്റ് നെറ്റ്‌ബിന് നിർണായകമായ MTU വലുപ്പം ഇതുവരെ എത്തിയിട്ടില്ലെന്ന് നമുക്ക് നിഗമനം ചെയ്യാം.

കൂടാതെ, ഓരോ എക്കോ പ്രതികരണത്തിലേക്കും DF ഫ്ലാഗ് പകർത്തിയതായി ലൈൻ നമ്പർ 2-ൽ നിന്ന് ശ്രദ്ധിക്കുക. ഇതാണ് പ്രശ്‌നത്തിന് കാരണമായത്. എക്കോ റിപ്ലൈ, എക്കോ അഭ്യർത്ഥനയുടെ അതേ വലുപ്പമാണ് (വെറും 600 ബൈറ്റുകൾ), എന്നാൽ ഹോസ്റ്റ് സണ്ണിന്റെ ഔട്ട്‌ഗോയിംഗ് SLIP ഇന്റർഫേസിന്റെ MTU 552 ആണ്. എക്കോ മറുപടി വിഘടിച്ചിരിക്കണം, പക്ഷേ DF ഫ്ലാഗ് സജ്ജീകരിച്ചിരിക്കുന്നു. ഇത് സൂര്യന് ഒരു ICMP അൺറീച്ച് പിശക് സൃഷ്ടിക്കുകയും അത് bsdi ലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു (അത് നശിപ്പിക്കപ്പെടുന്നിടത്ത്).

അതുകൊണ്ടാണ് സോളാരിസിൽ നിന്നുള്ള പ്രതിധ്വനികൾ നമ്മൾ കണ്ടിട്ടില്ലാത്തത്. പ്രതികരണങ്ങൾ സൂര്യനിലൂടെ കടന്നുപോയില്ല. ചിത്രം 11.12 പാക്കറ്റുകൾ എടുക്കുന്ന പാത കാണിക്കുന്നു.

ചിത്രം 11.12 ഈ ഉദാഹരണത്തിനായുള്ള പാക്കറ്റ് എക്സ്ചേഞ്ച്.

അവസാനമായി, ചിത്രം 11.11 ലെ വരികൾ 3, 6 എന്നിവയിലെ mtu=0 എന്ന പദപ്രയോഗം സൂചിപ്പിക്കുന്നത്, ചിത്രം 11.9-ൽ കാണിച്ചിരിക്കുന്നതുപോലെ, ICMP അൺറീച്ചബിൾ സന്ദേശത്തിലെ ഔട്ട്‌ഗോയിംഗ് ഇന്റർഫേസിനായി സൂര്യൻ MTU തിരികെ നൽകുന്നില്ലെന്ന് സൂചിപ്പിക്കുന്നു. (അധ്യായം 25-ൽ, SNMP ഉപയോഗിച്ച് ഞങ്ങൾ ഈ പ്രശ്നം പരിഹരിക്കുകയും netb ഇന്റർഫേസിന്റെ SLIP MTU 1500 ആണെന്ന് ഉറപ്പാക്കുകയും ചെയ്യും.)

Traceroute ഉപയോഗിച്ച് ഗതാഗത MTU നിർണ്ണയിക്കുന്നു

ട്രാൻസ്പോർട്ട് MTU നിർണ്ണയിക്കുന്നതിനുള്ള പ്രവർത്തനത്തെ മിക്ക സിസ്റ്റങ്ങളും പിന്തുണയ്‌ക്കാത്തതിനാൽ, ഞങ്ങൾ traceroute() പ്രോഗ്രാം പരിഷ്‌ക്കരിക്കും, അതുവഴി ഗതാഗത MTU നിർണ്ണയിക്കാനാകും. ഡോണ്ട് ഫ്രാഗ്‌മെന്റ് ബിറ്റ് സെറ്റ് ഉള്ള ഒരു പാക്കറ്റ് ഞങ്ങൾ അയയ്‌ക്കും. ആദ്യം അയച്ച പാക്കറ്റിന്റെ വലുപ്പം ഔട്ട്‌ഗോയിംഗ് ഇന്റർഫേസിന്റെ MTU-ന് തുല്യമായിരിക്കും. ICMP "കാൻറ്റ് ഫ്രാഗ്‌മെന്റ്" പിശക് വരുമ്പോൾ, ഞങ്ങൾ പാക്കറ്റ് കുറയ്ക്കും. വലിപ്പം. ICMP പിശക് അയച്ച റൂട്ടർ, ICMP സന്ദേശത്തിൽ ഔട്ട്‌ഗോയിംഗ് ഇന്റർഫേസ് MTU ഉൾപ്പെടുന്ന ഒരു പുതിയ പതിപ്പിനെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, തത്ഫലമായുണ്ടാകുന്ന മൂല്യം ഞങ്ങൾ ഉപയോഗിക്കുന്നു; അല്ലെങ്കിൽ ഞങ്ങൾ അടുത്ത ചെറിയ MTU പരീക്ഷിക്കും. RFC 1191 [Mogul and Deering 1990] പരിമിതമായ എണ്ണം MTU മൂല്യങ്ങളുണ്ടെന്ന് പ്രസ്താവിക്കുന്നതുപോലെ, ഞങ്ങളുടെ പ്രോഗ്രാമിന് സാധ്യമായ മൂല്യങ്ങളുടെ ഒരു പട്ടികയുണ്ട്, അത് അടുത്ത ചെറിയ മൂല്യത്തിലേക്ക് നീങ്ങും.

SLIP ചാനലിന് 296 MTU ഉണ്ടെന്ന് അറിഞ്ഞുകൊണ്ട്, ആതിഥേയ സൂര്യനിൽ നിന്ന് ഹോസ്റ്റ് സ്ലിപ്പിലേക്ക് സമാനമായ ഒരു അൽഗോരിതം പരീക്ഷിക്കാം:

>

സൂര്യൻ% traceroute.pmtu സ്ലിപ്പ്

ഔട്ട്ഗോയിംഗ് MTU = 1500
1 bsdi (140.252.13.35) 15 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 1492 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 1006 പരീക്ഷിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 576 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 552 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 544 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 512 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 508 ശ്രമിക്കുന്നു
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, പുതിയ MTU = 296 ശ്രമിക്കുന്നു
2 സ്ലിപ്പ് (140.252.13.65) 377 ms 377 ms 377 ms

ഈ ഉദാഹരണത്തിൽ, bsdi റൂട്ടർ ICMP സന്ദേശത്തിൽ ഔട്ട്‌ഗോയിംഗ് ഇന്റർഫേസ് MTU തിരികെ നൽകിയില്ല, അതിനാൽ ഞങ്ങൾ അടുത്ത താഴ്ന്ന MTU മൂല്യത്തിലേക്ക് വീഴും. 2 ന്റെ TTL-ന്റെ ഔട്ട്‌പുട്ടിന്റെ ആദ്യ വരി bsdi എന്ന ഹോസ്റ്റ്നാമം റിപ്പോർട്ടുചെയ്യുന്നു, പക്ഷേ ഇത് ഒരു ICMP പിശകിൽ റൂട്ടർ തിരികെ നൽകിയതിനാലാണിത്. 2 ന്റെ TTL-ന്റെ ഔട്ട്‌പുട്ടിന്റെ അവസാന വരി ഞങ്ങൾ പ്രതീക്ഷിച്ചത് തന്നെയാണ്.

ഔട്ട്‌ഗോയിംഗ് ഇന്റർഫേസിന്റെ MTU ലഭിക്കുന്നതിന് bsdi-യിലെ ICMP കോഡ് പരിഷ്‌ക്കരിക്കുന്നത് എളുപ്പമാണ്. ഞങ്ങൾ ഇത് ചെയ്‌ത് ഞങ്ങളുടെ പ്രോഗ്രാമിലേക്ക് മടങ്ങുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഔട്ട്‌പുട്ട് ലഭിക്കും:

>

സൂര്യൻ% traceroute.pmtu സ്ലിപ്പ്
സ്ലിപ്പിലേക്ക് ട്രെയ്‌സറൗട്ട് (140.252.13.65), പരമാവധി 30 ഹോപ്‌സ്
ഔട്ട്ഗോയിംഗ് MTU = 1500
1 bsdi (140.252.13.35) 53 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്, DF സെറ്റ്, അടുത്ത ഹോപ്പ് MTU = 296
2 സ്ലിപ്പ് (140.252.13.65) 377 ms 378 ms 377 ms

എട്ട് വ്യത്യസ്ത MTU മൂല്യങ്ങൾ ഇവിടെ പരീക്ഷിക്കുന്നതിൽ അർത്ഥമില്ല; റൂട്ടർ ആവശ്യമുള്ള മൂല്യം റിപ്പോർട്ട് ചെയ്തു.

ലോക ഇന്റർനെറ്റ്

ലോകമെമ്പാടുമുള്ള വിവിധ ഹോസ്റ്റുകളിൽ ട്രേസറൂട്ടിന്റെ പരിഷ്കരിച്ച പതിപ്പ് നിരവധി തവണ പ്രവർത്തിപ്പിക്കപ്പെട്ടു. വിവിധ അറ്റ്ലാന്റിക്, ട്രാൻസ്പാസിഫിക് ചാനലുകൾ ഉപയോഗിച്ച് ഇത് 15 രാജ്യങ്ങളിൽ (അന്റാർട്ടിക്ക ഉൾപ്പെടെ) എത്തി. എന്നിരുന്നാലും, ഇത് ചെയ്യുന്നതിന് മുമ്പ്, ഞങ്ങളുടെ സബ്‌നെറ്റും നെറ്റ്‌ബി റൂട്ടറും (ചിത്രം 11.12) തമ്മിലുള്ള SLIP ഡയൽ-അപ്പ് ലിങ്കിന്റെ MTU ഞങ്ങൾ ഇഥർനെറ്റിലെ പോലെ തന്നെ 1500 ആയി വർദ്ധിപ്പിച്ചു.

18 തവണ പ്രോഗ്രാം റൺ ചെയ്‌തതിൽ, രണ്ട് സന്ദർഭങ്ങളിൽ മാത്രമാണ് ട്രാൻസ്‌പോർട്ട് MTU 1500-ൽ താഴെയുള്ളത്. ഒരു ട്രാൻസ്‌അറ്റ്‌ലാന്റിക് ലിങ്കിന് 572 MTU ഉണ്ടായിരുന്നു (RFC 1191-ൽ പോലും പട്ടികപ്പെടുത്തിയിട്ടില്ലാത്ത ഒരു വിചിത്രമായ മൂല്യം), റൂട്ടർ തിരികെ നൽകിയില്ല. പുതിയതിൽ ICMP പിശക്. ഫോർമാറ്റ്. ജപ്പാനിലെ രണ്ട് റൂട്ടറുകൾ തമ്മിലുള്ള മറ്റൊരു ലിങ്ക് 1500 ബൈറ്റ് ഫ്രെയിമുകൾ പ്രോസസ്സ് ചെയ്തില്ല, കൂടാതെ റൂട്ടർ പുതിയ ഫോർമാറ്റിൽ ICMP പിശക് നൽകിയില്ല. MTU 1006 ആയി കുറച്ചതിനുശേഷം, എല്ലാം പ്രവർത്തിച്ചു.

ഈ പരീക്ഷണങ്ങളിൽ നിന്ന് നമുക്ക് വരാൻ കഴിയുന്ന നിഗമനം, മിക്ക (എല്ലാം അല്ല) വൈഡ് ഏരിയ നെറ്റ്‌വർക്കുകൾക്ക് നിലവിൽ 512 ബൈറ്റുകളേക്കാൾ വലിയ പാക്കറ്റുകൾ കൈകാര്യം ചെയ്യാൻ കഴിയും എന്നതാണ്. ട്രാൻസ്പോർട്ട് MTU തിരയൽ സവിശേഷത ഉപയോഗിക്കുന്നത്, വലിയ MTU-കൾ ഉപയോഗിച്ച് കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കാൻ ആപ്ലിക്കേഷനുകളെ അനുവദിക്കുന്നു.

UDP ഉപയോഗിക്കുമ്പോൾ ഗതാഗത MTU നിർണ്ണയിക്കുന്നു

UDP ഉപയോഗിക്കുന്ന ഒരു ആപ്ലിക്കേഷനും ട്രാൻസ്പോർട്ട് MTU ഡിസ്കവറി മെക്കാനിസവും തമ്മിലുള്ള ഇടപെടൽ നോക്കാം. ചില ഇന്റർമീഡിയറ്റ് ചാനലുകൾക്ക് വളരെ വലുതായ ഒരു ഡാറ്റാഗ്രാം ഒരു ആപ്ലിക്കേഷൻ അയയ്‌ക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് നമ്മൾ കാണേണ്ടതുണ്ട്.

ഒരു ട്രാൻസ്പോർട്ട് MTU ഡിസ്കവറി മെക്കാനിസത്തെ പിന്തുണയ്ക്കുന്ന ഒരേയൊരു സിസ്റ്റം സോളാരിസ് 2.x ആയതിനാൽ, സ്ലിപ്പിലേക്ക് 650-ബൈറ്റ് ഡാറ്റാഗ്രാം അയയ്ക്കുന്നതിനുള്ള ഉറവിട ഹോസ്റ്റായി ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു. സ്ലിപ്പ് ഹോസ്റ്റ് 296 MTU ഉള്ള ഒരു SLIP ലിങ്കിന് പിന്നിലായതിനാൽ, "ശകലം ചെയ്യരുത്" ബിറ്റ് സെറ്റുള്ള 268 ബൈറ്റുകളേക്കാൾ (296 - 20 - 8) വലിപ്പമുള്ള ഏത് UDP ഡാറ്റാഗ്രാമും bsdi-യിൽ നിന്ന് ICMP "ശകലമാക്കാൻ കഴിയില്ല" എന്ന പിശകിന് കാരണമാകും. റൂട്ടർ. ചിത്രം 11.13 ചാനലുകളുടെ ടോപ്പോളജിയും എംടിയുവും കാണിക്കുന്നു.

ചിത്രം 11.13 UDP ഉപയോഗിച്ച് ഗതാഗത MTU നിർണ്ണയിക്കാൻ ഉപയോഗിക്കുന്ന സിസ്റ്റങ്ങൾ.

ഇനിപ്പറയുന്ന കമാൻഡ് 5-സെക്കൻഡ് ഇടവേളകളിൽ പത്ത് 650-ബൈറ്റ് UDP ഡാറ്റാഗ്രാമുകൾ സൃഷ്ടിക്കുന്നു:

>സോളാരിസ് % സോക്ക് -u -i -n10 -w650 -p5 സ്ലിപ്പ് നിരസിക്കുക

tcpdump കമാൻഡിന്റെ ഔട്ട്പുട്ട് ചിത്രം 11.14 കാണിക്കുന്നു. ഈ ഉദാഹരണം പ്രവർത്തിപ്പിക്കുമ്പോൾ, ICMP "ശകലമാക്കാൻ കഴിയില്ല" എന്ന പിശകിന്റെ ഭാഗമായി അടുത്ത-ഹോപ്പ് MTU തിരികെ നൽകാതിരിക്കാൻ bsdi റൂട്ടർ ക്രമീകരിച്ചു.

DF ബിറ്റ് സെറ്റ് (ലൈൻ 1) ഉപയോഗിച്ച് അയച്ച ആദ്യ ഡാറ്റഗ്രാം bsdi റൂട്ടറിൽ നിന്ന് പ്രതീക്ഷിക്കുന്ന പിശക് സൃഷ്ടിക്കുന്നു (ലൈൻ 2). രസകരമെന്നു പറയട്ടെ, DF ബിറ്റ് സെറ്റിനൊപ്പം അയച്ച അടുത്ത ഡാറ്റാഗ്രാം (ലൈൻ 3), അതേ ICMP പിശക് (ലൈൻ 4) സൃഷ്ടിക്കുന്നു. ഈ ഡാറ്റാഗ്രാം DF ബിറ്റ് ഓഫാക്കി അയയ്ക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിച്ചു.

5 വരിയിൽ, ഈ ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള ഡാറ്റാഗ്രാമുകൾ DF ബിറ്റ് സെറ്റിനൊപ്പം അയയ്‌ക്കേണ്ടതില്ലെന്ന് IP ഒടുവിൽ മനസ്സിലാക്കി, തുടർന്ന് സോഴ്‌സ് ഹോസ്റ്റിലെ ഡാറ്റാഗ്രാമുകൾ വിഘടിപ്പിക്കാൻ തുടങ്ങി. ഈ സ്വഭാവം മുമ്പത്തെ ഉദാഹരണങ്ങളിൽ കാണിച്ചതിൽ നിന്ന് വ്യത്യസ്തമാണ്, UDP-യിൽ നിന്ന് ലഭിച്ച ഡാറ്റാഗ്രാമുകൾ IP അയച്ചു, അതേസമയം ചെറിയ MTU-കളുള്ള റൂട്ടറുകൾ (ഈ സാഹചര്യത്തിൽ bsdi) വിഘടിപ്പിക്കാൻ അനുവദിച്ചു.

>

1 0.0 solaris.38196 > slip.discard: udp 650 (DF)
2 0.004218 (0.0042) bsdi > solaris: icmp:

3 4.980528 (4.9763) solaris.38196 > slip.discard: udp 650 (DF)
4 4.984503 (0.0040) bsdi > solaris: icmp:
സ്ലിപ്പ് ലഭ്യമല്ല - ഫ്രാഗ് ചെയ്യണം, mtu = 0 (DF)

5 9.870407 (4.8859) solaris.38196 > slip.discard: udp 650 (frag 47942:552@0+)
6 9.960056 (0.0896) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47942:106@552)

7 14.940338 (4.9803) solaris.38196 > slip.discard: udp 650 (DF)
8 14.944466 (0.0041) bsdi > solaris: icmp:
സ്ലിപ്പ് ലഭ്യമല്ല - ഫ്രാഗ് ചെയ്യണം, mtu = 0 (DF)

9 19.890015 (4.9455) solaris.38196 > slip.discard: udp 650 (frag 47944:552@0+)
10 19.950463 (0.0604) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47944:106@552)

11 24.870401 (4.9199) solaris.38196 > slip.discard: udp 650 (frag 47945:552@0+)
12 24.960038 (0.0896) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47945:106@552)

13 29.880182 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47946:552@0+)
14 29.940498 (0.0603) സോളാരിസ് > സ്ലിപ്പ്: (frag 47946:106@552)

15 34.860607 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47947:552@0+)
16 34.950051 (0.0894) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47947:106@552)

17 39.870216 (4.9202) solaris.38196 > slip.discard: udp 650 (frag 47948:552@0+)
18 39.930443 (0.0602) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47948:106@552)

19 44.940485 (5.0100) solaris.38196 > slip.discard: udp 650 (DF)
20 44.944432 (0.0039) bsdi > solaris: icmp:
സ്ലിപ്പ് ലഭ്യമല്ല - ഫ്രാഗ് ചെയ്യണം, mtu = 0 (DF)

ചിത്രം 11.14 UDP ഉപയോഗിച്ച് ഗതാഗത MTU നിർണ്ണയിക്കുന്നു.

ICMP "ശകലമാക്കാൻ കഴിയില്ല" എന്ന സന്ദേശത്തിൽ അടുത്ത ഹോപ്പ് MTU അടങ്ങിയിട്ടില്ലാത്തതിനാൽ, 576 MTU-ൽ എല്ലാവരും സന്തുഷ്ടരാണെന്ന് IP തീരുമാനിച്ചു എന്നാണ് ഇതിനർത്ഥം. ആദ്യ ശകലത്തിൽ (ലൈൻ 5) UDP ഡാറ്റയുടെ 544 ബൈറ്റുകൾ, 8 ബൈറ്റുകൾ എന്നിവ അടങ്ങിയിരിക്കുന്നു. യുഡിപി ഹെഡറിന്റെയും 20 ബൈറ്റുകളുടെ ഐപി ഹെഡറിന്റെയും മൊത്തം വലുപ്പം 572 ബൈറ്റുകളാണ്. രണ്ടാമത്തെ ശകലത്തിൽ (ലൈൻ 6) ശേഷിക്കുന്ന 106 ബൈറ്റുകളുടെ യുഡിപി ഡാറ്റയും 20-ബൈറ്റ് ഐപി ഹെഡറും അടങ്ങിയിരിക്കുന്നു.

നിർഭാഗ്യവശാൽ, അടുത്ത ഡാറ്റാഗ്രാം, ലൈൻ 7-ൽ DF ബിറ്റ് സെറ്റ് ഉണ്ട്, അതിനാൽ അത് bsdi നിരസിക്കുകയും ഒരു ICMP പിശക് നൽകുകയും ചെയ്യുന്നു. ഇവിടെ സംഭവിച്ചത് ഐപി ടൈമർ കാലഹരണപ്പെട്ടു, ഡിഎഫ് ബിറ്റ് റീസെറ്റ് ചെയ്തുകൊണ്ട് ട്രാൻസ്പോർട്ട് എംടിയു വർദ്ധിച്ചിട്ടുണ്ടോ എന്ന് പരിശോധിക്കാൻ ഐപിയോട് പറഞ്ഞു. 19, 20 വരികളിൽ ഇത് വീണ്ടും സംഭവിക്കുന്നത് ഞങ്ങൾ കാണും. DF ബിറ്റ് ഒന്നായി സജ്ജീകരിച്ചിരിക്കുന്ന 7, 19 വരികളിലെ സമയങ്ങളെ താരതമ്യം ചെയ്യുമ്പോൾ, ഓരോ 30 സെക്കൻഡിലും ട്രാൻസ്പോർട്ട് MTU വർദ്ധിക്കുന്നത് പരിശോധിക്കുന്നത് നമുക്ക് കാണാം.

ഈ 30 സെക്കൻഡ് ടൈമർ വളരെ ചെറുതാണ്. RFC 1191 ടൈമർ 10 മിനിറ്റായി സജ്ജമാക്കാൻ ശുപാർശ ചെയ്യുന്നു. ip_ire_pathmtu_interval പാരാമീറ്റർ (അനുബന്ധം E, വിഭാഗം) ഉപയോഗിച്ച് ടൈമർ മൂല്യം മാറ്റാവുന്നതാണ്. സോളാരിസ് 2.2-ൽ, ഒരൊറ്റ യുഡിപി ആപ്ലിക്കേഷനോ എല്ലാ യുഡിപി ആപ്ലിക്കേഷനുകൾക്കോ ​​വേണ്ടി ട്രാൻസ്പോർട്ട് എംടിയു കണ്ടെത്തൽ പ്രവർത്തനരഹിതമാക്കാൻ മാർഗമില്ല. ip_path_mtu_discovery പരാമീറ്റർ മാറ്റി മുഴുവൻ സിസ്റ്റത്തിനും മാത്രമേ ഇത് പ്രവർത്തനക്ഷമമാക്കാനോ പ്രവർത്തനരഹിതമാക്കാനോ കഴിയൂ. ഈ ഉദാഹരണത്തിൽ നിന്ന് നമുക്ക് കാണാൻ കഴിയുന്നത് പോലെ, UDP ആപ്ലിക്കേഷനുകൾ വിഘടിപ്പിക്കപ്പെടാൻ സാധ്യതയുള്ള ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുമ്പോൾ ട്രാൻസ്പോർട്ട് MTU കണ്ടെത്തൽ ഫീച്ചർ പ്രവർത്തനക്ഷമമാക്കുന്നത് ഡാറ്റാഗ്രാം ഉപേക്ഷിക്കപ്പെടുന്നതിന് ഇടയാക്കും.

സോളാരിസിലെ (576 ബൈറ്റുകൾ) ഐപി ലെയർ അംഗീകരിച്ച പരമാവധി ഡാറ്റാഗ്രാം വലുപ്പം തെറ്റാണ്. യഥാർത്ഥ MTU 296 ബൈറ്റുകൾ ആണെന്ന് ചിത്രം 11.13 ൽ നമ്മൾ കണ്ടു. ഇതിനർത്ഥം സോളാരിസ് ഉത്പാദിപ്പിക്കുന്ന ശകലങ്ങൾ bsdi-യിൽ വീണ്ടും വിഘടിക്കപ്പെടുന്നു എന്നാണ്. ആദ്യം എത്തുന്ന ഡാറ്റാഗ്രാം (ചിത്രം 11.14 ലെ വരികൾ 5 ഉം 6 ഉം) ലക്ഷ്യസ്ഥാന (സ്ലിപ്പ്) ഹോസ്റ്റിൽ ലഭിച്ച tcpdump ഔട്ട്പുട്ട് ചിത്രം 11.15 കാണിക്കുന്നു.

>

1 0.0 solaris.38196 > slip.discard: udp 650 (frag 47942:272@0+)
2 0.304513 (0.3045) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47942:272@272+)
3 0.334651 (0.0301) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47942:8@544+)
4 0.466642 (0.1320) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 47942:106@552)

ചിത്രം 11.15 സോളാരിസിൽ നിന്ന് സ്ലിപ്പ് ഹോസ്റ്റിൽ എത്തുന്ന ആദ്യത്തെ ഡാറ്റഗ്രാം.

ഈ ഉദാഹരണത്തിൽ, സോളാരിസ് ഹോസ്റ്റ് ഔട്ട്‌ഗോയിംഗ് ഡാറ്റാഗ്രാമുകളെ വിഘടിപ്പിക്കരുത്, പക്ഷേ DF ബിറ്റ് ഓഫ് ചെയ്യുകയും ചെറിയ MTU ഉള്ള റൂട്ടറിനെ ഫ്രാഗ്മെന്റേഷൻ നടത്താൻ അനുവദിക്കുകയും വേണം.

ഞങ്ങൾ ഇപ്പോൾ അതേ ഉദാഹരണം പ്രവർത്തിപ്പിക്കും, എന്നാൽ bsdi റൂട്ടറിന്റെ സ്വഭാവം മാറ്റുക, അതുവഴി ICMP "ശകലമാക്കാൻ കഴിയില്ല" എന്ന സന്ദേശത്തിലെ അടുത്ത ഹോപ്പ് MTU തിരികെ നൽകുന്നു. tcpdump ഔട്ട്പുട്ടിന്റെ ആദ്യ ആറ് വരികൾ ചിത്രം 11.16 കാണിക്കുന്നു.

>

1 0.0 solaris.37974 > slip.discard: udp 650 (DF)
2 0.004199 (0.0042) bsdi > solaris: icmp:

3 4.950193 (4.9460) solaris.37974 > slip.discard: udp 650 (DF)
4 4.954325 (0.0041) bsdi > solaris: icmp:
സ്ലിപ്പ് ലഭ്യമല്ല - ഫ്രാഗ് ചെയ്യണം, mtu = 296 (DF)

5 9.779855 (4.8255) solaris.37974 > slip.discard: udp 650 (frag 35278:272@0+)
6 9.930018 (0.1502) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 35278:272@272+)
7 9.990170 (0.0602) സോളാരിസ് > സ്ലിപ്പ്: (ഫ്രാഗ് 35278:114@544)

ചിത്രം 11.16 UDP ഉപയോഗിച്ച് ഗതാഗത MTU നിർണ്ണയിക്കുന്നു.

ആദ്യത്തെ രണ്ട് ഡാറ്റാഗ്രാമുകൾ ഡിഎഫ് ബിറ്റ് സെറ്റിനൊപ്പം അയച്ചതായും രണ്ടിനും ഐസിഎംപി പിശകുകൾ ലഭിച്ചതായും ഒരിക്കൽ കൂടി ഞങ്ങൾ കാണുന്നു. നിലവിൽ, ICMP പിശക് അടുത്ത ഫോർവേഡ് MTU യെ സൂചിപ്പിക്കുന്നു, അത് 296 ആണ്.

5, 6, 7 വരികളിൽ, ചിത്രം 11.14-ൽ ഉള്ളതുപോലെ സോഴ്സ് ഹോസ്റ്റ് ഫ്രാഗ്മെന്റേഷൻ നടത്തുന്നതായി കാണാം. അടുത്ത-ഹോപ്പ് MTU അറിയാമെങ്കിൽ, ചിത്രം 11.15-ൽ bsdi റൂട്ടർ സൃഷ്ടിക്കുന്ന നാല് ശകലങ്ങളുമായി താരതമ്യം ചെയ്യുമ്പോൾ, മൂന്ന് ശകലങ്ങൾ മാത്രമേ ജനറേറ്റ് ചെയ്യപ്പെടുകയുള്ളൂ.

യുഡിപിയും എആർപിയും തമ്മിലുള്ള ഇടപെടൽ

യു‌ഡി‌പി ഉപയോഗിച്ച്, യു‌ഡി‌പിയും ഒരു സാധാരണ എആർ‌പി നടപ്പിലാക്കലും തമ്മിലുള്ള വളരെ രസകരമായ ഒരു ഇടപെടൽ നമുക്ക് നോക്കാം.

8192 ബൈറ്റ് ഡാറ്റയുള്ള ഒരു UDP ഡാറ്റാഗ്രാം സൃഷ്ടിക്കാൻ ഞങ്ങൾ സോക്ക് പ്രോഗ്രാം ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ ആറ് ഇഥർനെറ്റ് ശകലങ്ങൾ സൃഷ്ടിക്കപ്പെടുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു (അധ്യായം 11 കാണുക). കൂടാതെ, പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ്, ARP കാഷെ ശൂന്യമാണെന്ന് ഞങ്ങൾ ഉറപ്പാക്കും, അതിനാൽ ആദ്യ ശകലം അയയ്ക്കുന്നതിന് മുമ്പ്, ഒരു ARP അഭ്യർത്ഥനയും പ്രതികരണവും കൈമാറണം.

>

bsdi % ആർപി -എ ARP കാഷെ ശൂന്യമാണോ എന്ന് പരിശോധിക്കുക
bsdi % sock -u -i -n1 -w8192 svr4 നിരസിക്കുക

ആദ്യ ഡാറ്റഗ്രാം ഒരു ARP അഭ്യർത്ഥന അയയ്‌ക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. IP ജനറേറ്റ് ചെയ്യുന്ന അടുത്ത അഞ്ച് ശകലങ്ങൾ tcpdump ഉപയോഗിച്ച് മാത്രം നമുക്ക് ഉത്തരം നൽകാൻ കഴിയുന്ന രണ്ട് ചോദ്യങ്ങൾ ഉന്നയിക്കുന്നു: ARP പ്രതികരണം ലഭിക്കുന്നതിന് മുമ്പ് ശേഷിക്കുന്ന ശകലങ്ങൾ അയയ്‌ക്കാൻ തയ്യാറാകുമോ, അങ്ങനെയെങ്കിൽ, ഈ കുറച്ച് പാക്കറ്റുകൾ ARP എന്തുചെയ്യും? ഒരു ARP പ്രതികരണത്തിനായി കാത്തിരിക്കുമ്പോൾ ഒരു നിർദ്ദിഷ്ട ലക്ഷ്യസ്ഥാനത്തേക്ക്? tcpdump പ്രോഗ്രാമിന്റെ ഔട്ട്പുട്ട് ചിത്രം 11.17 കാണിക്കുന്നു.

>

1 0.0 arp who-has svr4 ടെൽ bsdi
2 0.001234 (0.0012) arp who-has svr4 tell bsdi
3 0.001941 (0.0007) arp who-has svr4 tell bsdi
4 0.002775 (0.0008) arp who-has svr4 tell bsdi
5 0.003495 (0.0007) arp who-has svr4 ടെൽ bsdi
6 0.004319 (0.0008) arp who-has svr4 ടെൽ bsdi
7 0.008772 (0.0045) arp reply svr4 is- at 0:0:c0:c2:9b:26
8 0.009911 (0.0011) arp reply svr4 is- at 0:0:c0:c2:9b:26
9 0.011127 (0.0012) bsdi > svr4: (frag 10863:800@7400)
10 0.011255 (0.0001) arp reply svr4 is- at 0:0:c0:c2:9b:26
11 0.012562 (0.0013) arp reply svr4 is- at 0:0:c0:c2:9b:26
12 0.013458 (0.0009) arp reply svr4 is- at 0:0:c0:c2:9b:26
13 0.014526 (0.0011) arp reply svr4 is- at 0:0:c0:c2:9b:26
14 0.015583 (0.0011) arp reply svr4 is- at 0:0:c0:c2:9b:26

ചിത്രം 11.17 ഇഥർനെറ്റിലൂടെ 8192 ബൈറ്റ് യുഡിപി ഡാറ്റഗ്രാം അയയ്ക്കുമ്പോൾ പാക്കറ്റ് എക്സ്ചേഞ്ച്.

ഈ നിഗമനം തികച്ചും അപ്രതീക്ഷിതമാണ്. ആദ്യം, ആദ്യത്തെ ARP പ്രതികരണം ലഭിക്കുന്നതിന് മുമ്പ്, ആറ് ARP അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കപ്പെടുന്നു. നിങ്ങൾ ഊഹിക്കുന്നതുപോലെ, IP വേഗത്തിൽ ആറ് ശകലങ്ങൾ സൃഷ്ടിക്കുന്നു, ഓരോന്നിനും ഒരു ARP അഭ്യർത്ഥന അയയ്‌ക്കും.

തുടർന്ന്, ആദ്യത്തെ ARP പ്രതികരണം ലഭിക്കുമ്പോൾ (ലൈൻ 7), അവസാന ശകലം (ലൈൻ 9) മാത്രമേ അയയ്ക്കൂ! ഇതിനർത്ഥം ആദ്യത്തെ അഞ്ച് ശകലങ്ങൾ ഉപേക്ഷിച്ചു എന്നാണ്. വാസ്തവത്തിൽ, ഇത് സാധാരണ ARP പ്രവർത്തനത്തിന്റെ ഒരു ഉദാഹരണമാണ്. ഒരു ARP പ്രതികരണത്തിനായി കാത്തിരിക്കുമ്പോൾ, മിക്ക നടപ്പാക്കലുകളും ലക്ഷ്യസ്ഥാന ഹോസ്റ്റിലേക്ക് അയയ്‌ക്കേണ്ട അവസാന പാക്കറ്റ് മാത്രമേ കൈവശം വയ്ക്കൂ.

ഹോസ്റ്റ് ആവശ്യകതകൾ RFC-ന് ARP വെള്ളപ്പൊക്കം തടയാൻ നടപ്പിലാക്കലുകൾ ആവശ്യമാണ് (ഉയർന്ന ഫ്രീക്വൻസിയിൽ ഒരേ IP വിലാസത്തിനായി ആവർത്തിച്ച് ARP അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു). ശുപാർശ ചെയ്യുന്ന പരമാവധി ആവൃത്തി സെക്കൻഡിൽ ഒരു തവണയാണ്. 4.3 മില്ലിസെക്കൻഡിനുള്ളിൽ ആറ് ARP അഭ്യർത്ഥനകൾ ഇവിടെ കാണാം. ഹോസ്റ്റ് ആവശ്യകതകൾ RFC-ന് കുറഞ്ഞത് ഒരു പാക്കറ്റെങ്കിലും ARP സംഭരിക്കേണ്ടത് ആവശ്യമാണ്, അത് ഏറ്റവും പുതിയ പാക്കറ്റായിരിക്കണം. ഇതാണ് നമ്മൾ ഇവിടെ കണ്ടത്.

അടുത്ത വിശദീകരിക്കാനാകാത്ത അപാകത, svr4 ആറ് ARP മറുപടികളല്ല, ഏഴ് ARP മറുപടികളാണ് അയച്ചത്.

അവസാനമായി ശ്രദ്ധിക്കേണ്ട ഒരു കാര്യം, അവസാനത്തെ ARP പ്രതികരണത്തിന് ശേഷം tcpdump 5 മിനിറ്റ് കൂടി പ്രവർത്തിച്ചു, svr4 ഒരു ICMP "റീ അസംബ്ലി സമയത്ത് കവിഞ്ഞ സമയം" പിശക് തിരികെ അയക്കുന്നത് കാണാൻ കാത്തിരിക്കുന്നു. ICMP സന്ദേശം ഒരിക്കലും പ്രത്യക്ഷപ്പെട്ടില്ല. (ഞങ്ങൾ ഈ സന്ദേശത്തിന്റെ ഫോർമാറ്റ് ൽ കാണിച്ചിരിക്കുന്നു. 1-ലേക്ക് സജ്ജീകരിച്ചിരിക്കുന്ന കോഡ് ഫീൽഡ്, ഡാറ്റാഗ്രാം വീണ്ടും കൂട്ടിച്ചേർക്കുമ്പോൾ സമയം അതിക്രമിച്ചതായി സൂചിപ്പിക്കുന്നു.)

ആദ്യത്തെ ഡാറ്റാഗ്രാം ശകലം ദൃശ്യമാകുമ്പോൾ IP ലെയർ ഒരു ടൈമർ ആരംഭിക്കണം. ഇവിടെ, "ആദ്യം" എന്നാൽ, തന്നിരിക്കുന്ന ഡാറ്റാഗ്രാമിന് വേണ്ടി വരുന്ന ആദ്യത്തെ ശകലം എന്നാണ് അർത്ഥമാക്കുന്നത്, ആദ്യ ശകലം മാത്രമല്ല (0 ന്റെ ഒരു ശകലം ഓഫ്‌സെറ്റ് ഉള്ളത്). ഒരു സാധാരണ ടൈംഔട്ട് മൂല്യം 30 മുതൽ 60 സെക്കൻഡ് വരെയാണ്. ഈ ഡാറ്റാഗ്രാമിനുള്ള എല്ലാ ശകലങ്ങളും ടൈമർ കാലഹരണപ്പെടുന്നതിന് മുമ്പ് എത്തിയിട്ടില്ലെങ്കിൽ, എല്ലാ ശകലങ്ങളും ഉപേക്ഷിക്കപ്പെടും. ഇത് ചെയ്തില്ലെങ്കിൽ, ഒരിക്കലും വരാത്ത ശകലങ്ങൾ (നമ്മൾ ഈ ഉദാഹരണത്തിൽ കണ്ടതുപോലെ) സ്വീകരിക്കുന്ന ബഫർ ഓവർഫ്ലോക്ക് കാരണമാകും.

ICMP സന്ദേശം കാണാത്തതിന് രണ്ട് കാരണങ്ങളുണ്ട്. ആദ്യം, മിക്ക ബെർക്ക്‌ലി നടപ്പാക്കലുകളും ഒരിക്കലും ഈ പിശക് സൃഷ്ടിക്കുന്നില്ല! ഈ നിർവ്വഹണങ്ങൾ ഒരു ടൈമർ സജ്ജമാക്കുകയും ടൈമർ കാലഹരണപ്പെടുമ്പോൾ എല്ലാ ശകലങ്ങളും ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു, എന്നാൽ ICMP പിശക് സൃഷ്ടിക്കപ്പെടുന്നില്ല. രണ്ടാമതായി, ആദ്യത്തെ ശകലം - UDP തലക്കെട്ട് അടങ്ങുന്ന 0 ന് തുല്യമായ ഓഫ്‌സെറ്റുള്ള ശകലം ലഭിച്ചില്ല. (എആർപി ഇറക്കിയ അഞ്ച് പാക്കറ്റുകളിൽ ആദ്യത്തേതായിരുന്നു ഇത്.) ആദ്യ ശകലം ലഭിച്ചില്ലെങ്കിൽ നടപ്പാക്കലിന് ICMP പിശക് സൃഷ്ടിക്കേണ്ടതില്ല. കാരണം, ട്രാൻസ്പോർട്ട് ലെയർ ഹെഡർ ലഭ്യമല്ലാത്തതിനാൽ നിരസിച്ച ഡാറ്റാഗ്രാം ഏത് ഉപയോക്തൃ പ്രക്രിയയാണ് അയച്ചതെന്ന് ICMP പിശക് സിങ്കിന് പറയാൻ കഴിയില്ല. ഉയർന്ന ലെവൽ (ഒന്നുകിൽ ഒരു TCP ആപ്ലിക്കേഷൻ അല്ലെങ്കിൽ ഒരു UDP ആപ്ലിക്കേഷൻ) സമയം കഴിഞ്ഞു പ്രക്ഷേപണം ആവർത്തിക്കും.

ഈ വിഭാഗത്തിൽ, UDP-യും ARP-യും തമ്മിലുള്ള ആശയവിനിമയം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാൻ ഞങ്ങൾ IP ഫ്രാഗ്മെന്റേഷൻ ഉപയോഗിച്ചു. അയച്ചയാൾ ഒന്നിലധികം UDP ഡാറ്റാഗ്രാമുകൾ ദ്രുതഗതിയിൽ അയച്ചാൽ ഈ ഇടപെടൽ കാണാൻ കഴിയും. IP ഉപയോഗിച്ച് പാക്കറ്റുകൾ വേഗത്തിൽ ജനറേറ്റുചെയ്യുന്നതിനാൽ ഞങ്ങൾ ഫ്രാഗ്‌മെന്റേഷൻ ഉപയോഗിച്ചു, ഇത് ഒരു ഉപയോക്തൃ പ്രക്രിയ ഒന്നിലധികം പാക്കറ്റുകൾ സൃഷ്ടിക്കുന്നതിനേക്കാൾ വളരെ വേഗതയുള്ളതാണ്.

പരമാവധി UDP ഡാറ്റാഗ്രാം വലുപ്പം

സൈദ്ധാന്തികമായി, ഒരു IP ഡാറ്റാഗ്രാമിന്റെ പരമാവധി വലുപ്പം 65535 ബൈറ്റുകൾ ആകാം, ഇത് IP ഹെഡറിലെ 16-ബിറ്റ് മുഴുനീള ഫീൽഡ് കൊണ്ട് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു (കാണുക). IP ഹെഡർ ദൈർഘ്യം 20 ബൈറ്റുകളും UDP ഹെഡർ ദൈർഘ്യം 8 ബൈറ്റുകളും ഉള്ളതിനാൽ, UDP ഡാറ്റാഗ്രാം ഉപയോക്തൃ ഡാറ്റയ്ക്കായി പരമാവധി 65507 ബൈറ്റുകൾ നൽകുന്നു. എന്നിരുന്നാലും, മിക്ക നടപ്പാക്കലുകളും വളരെ ചെറിയ ഡാറ്റാഗ്രാമുകൾ ഉപയോഗിക്കുന്നു.

രണ്ട് നിയന്ത്രണങ്ങൾ സാധാരണയായി പ്രവർത്തിക്കുന്നു. ആദ്യം, ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിനെ അതിന്റെ പ്രോഗ്രാമിംഗ് ഇന്റർഫേസ് പരിമിതപ്പെടുത്തിയേക്കാം. സോക്കറ്റ്സ് API (അധ്യായം 1, വിഭാഗം) ഇൻപുട്ടിന്റെയും ഔട്ട്പുട്ട് ബഫറുകളുടെയും വലുപ്പം സജ്ജീകരിക്കുന്നതിന് ഒരു ആപ്ലിക്കേഷൻ വിളിക്കാവുന്ന ഒരു ഫംഗ്ഷൻ നൽകുന്നു. ഒരു UDP സോക്കറ്റിനായി, ഈ വലുപ്പം UDP-ന് വായിക്കാനും എഴുതാനും കഴിയുന്ന UDP ഡാറ്റാഗ്രാമിന്റെ പരമാവധി വലുപ്പവുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നു. നിലവിൽ, മിക്ക സിസ്റ്റങ്ങളും UDP ഡാറ്റാഗ്രാമിന്റെ സ്ഥിരസ്ഥിതി പരമാവധി വലുപ്പം നൽകുന്നു, അത് വായിക്കാനോ എഴുതാനോ കഴിയും, അതായത് 8192 ബൈറ്റുകൾ. (ഈ മൂല്യം 8192 ആയി സജ്ജീകരിച്ചിരിക്കുന്നു, കാരണം അതാണ് NFS സ്ഥിരസ്ഥിതിയായി വായിക്കുന്നതും എഴുതുന്നതും.)

ടിസിപി/ഐപി കേർണൽ നടപ്പാക്കലാണ് ഇനിപ്പറയുന്ന പരിമിതി നിർണ്ണയിക്കുന്നത്. ഒരു യുഡിപി ഡാറ്റാഗ്രാമിന്റെ വലുപ്പം 65535 ബൈറ്റുകളിൽ താഴെയായി പരിമിതപ്പെടുത്തുന്ന നടപ്പിലാക്കൽ സവിശേഷതകൾ (അല്ലെങ്കിൽ ബഗുകൾ) ഉണ്ടാകാം.

സോക്ക് പ്രോഗ്രാം ഉപയോഗിച്ച് രചയിതാവ് വ്യത്യസ്ത UDP ഡാറ്റാഗ്രാം വലുപ്പങ്ങൾ പരീക്ഷിച്ചു. SunOS 4.1.3-ന് കീഴിലുള്ള ലൂപ്പ്ബാക്ക് ഇന്റർഫേസ് ഉപയോഗിച്ച്, പരമാവധി UDP ഡാറ്റാഗ്രാം വലുപ്പം 32767 ബൈറ്റുകൾ ആയിരുന്നു. ഉയർന്ന മൂല്യം ഉപയോഗിക്കാൻ കഴിഞ്ഞില്ല. BSD/386-ൽ നിന്ന് SunOS 4.1.3-ലേക്ക് ഇഥർനെറ്റിലൂടെ കൈമാറ്റം ചെയ്യുമ്പോൾ, സൂര്യന് സ്വീകരിക്കാൻ കഴിയുന്ന ഒരു IP ഡാറ്റാഗ്രാമിന്റെ പരമാവധി വലുപ്പം 32786 ആയിരുന്നു (32758 ബൈറ്റ് ഉപയോക്തൃ ഡാറ്റയോടൊപ്പം). സോളാരിസ് 2.2-ലെ ലൂപ്പ്ബാക്ക് ഇന്റർഫേസ് ഉപയോഗിച്ച്, അയയ്‌ക്കാനും സ്വീകരിക്കാനും കഴിയുന്ന ഒരു IP ഡാറ്റാഗ്രാമിന്റെ പരമാവധി വലുപ്പം 65535 ബൈറ്റുകൾ ആയിരുന്നു. Solaris 2.2-ൽ നിന്ന് AIX 3.2.2-ലേക്ക് ട്രാൻസ്ഫർ ചെയ്യുമ്പോൾ, പരമാവധി 65535 ബൈറ്റുകളുള്ള ഒരു IP ഡാറ്റാഗ്രാം ട്രാൻസ്ഫർ ചെയ്യാൻ സാധിച്ചു.

ഡാറ്റഗ്രാം വെട്ടിച്ചുരുക്കൽ

ഐപിക്ക് ഒരു നിശ്ചിത വലുപ്പത്തിലുള്ള ഡാറ്റാഗ്രാമുകൾ അയയ്‌ക്കാനും സ്വീകരിക്കാനും കഴിയുമെന്നതിനാൽ സ്വീകരിക്കുന്ന ആപ്ലിക്കേഷൻ ആ വലുപ്പത്തിലുള്ള ഡാറ്റാഗ്രാമുകൾ വായിക്കാൻ തയ്യാറാണെന്ന് അർത്ഥമാക്കുന്നില്ല. ഒരു സമയം പ്രോസസ്സ് ചെയ്യേണ്ട പരമാവധി ബൈറ്റുകളുടെ എണ്ണം വ്യക്തമാക്കാൻ UDP API അപ്ലിക്കേഷനുകളെ അനുവദിക്കുന്നു. സ്വീകരിച്ച ഡാറ്റാഗ്രാം ആപ്ലിക്കേഷൻ സ്വീകരിക്കാൻ തയ്യാറുള്ള ഡാറ്റാഗ്രാമിനേക്കാൾ വലുതാണെങ്കിൽ എന്ത് സംഭവിക്കും?

നിർഭാഗ്യവശാൽ, ഉത്തരം പ്രോഗ്രാമിംഗ് ഇന്റർഫേസ്, നടപ്പിലാക്കൽ എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു.

ബെർക്ക്‌ലി സോക്കറ്റ് API-യുടെ പരമ്പരാഗത പതിപ്പുകൾ ഡാറ്റാഗ്രാമുകൾ വെട്ടിച്ചുരുക്കി, അനുയോജ്യമല്ലാത്ത എല്ലാ ഡാറ്റയും നിരസിക്കുന്നു. ആപ്ലിക്കേഷന് അറിയിപ്പ് ലഭിക്കുമോ എന്നത് പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു. (4.3 BSD Renoയ്ക്കും അതിനുശേഷമുള്ളവർക്കും ഒരു ഡാറ്റാഗ്രാം വെട്ടിച്ചുരുക്കിയതായി അപ്ലിക്കേഷനെ അറിയിക്കാനാകും.) SVR4-ന് കീഴിലുള്ള API സോക്കറ്റുകൾ (Solaris 2.x ഉൾപ്പെടെ) ഡാറ്റാഗ്രാമുകൾ വെട്ടിച്ചുരുക്കില്ല. അനുയോജ്യമല്ലാത്ത എല്ലാ ഡാറ്റയും തുടർച്ചയായി വായിക്കുന്നു. ഒന്നിലധികം റീഡ് സൈക്കിളുകളെ കുറിച്ച് അപ്ലിക്കേഷന് അറിയിപ്പ് ലഭിച്ചിട്ടില്ല കൂടാതെ ഒരൊറ്റ യുഡിപി ഡാറ്റഗ്രാം അയയ്‌ക്കും. TLI API-കൾ ഡാറ്റ നിരസിക്കുന്നില്ല. പകരം, ഒരേസമയം വായിക്കാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതൽ ഡാറ്റ ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്ന ഒരു ഫ്ലാഗ് തിരികെ നൽകുന്നു, അതിനാൽ ആപ്ലിക്കേഷൻ ശേഷിക്കുന്ന ഡാറ്റാഗ്രാം തുടർച്ചയായി വായിക്കാൻ തുടങ്ങുന്നു.

ഞങ്ങൾ TCP ചർച്ച ചെയ്യുമ്പോൾ, ഈ പ്രോട്ടോക്കോൾ യാതൊരു നിയന്ത്രണവുമില്ലാതെ ആപ്ലിക്കേഷനിലേക്ക് തുടർച്ചയായ ബൈറ്റ് സ്ട്രീമുകൾ നൽകുന്നതായി കാണാം. ആപ്ലിക്കേഷന് ആവശ്യമായ ഏത് വലുപ്പത്തിലുള്ള ഡാറ്റയും TCP നൽകുന്നു - കൂടാതെ ആ ഇന്റർഫേസിൽ ഡാറ്റയൊന്നും നഷ്‌ടമാകില്ല.

ICMP സോഴ്സ് സപ്രഷൻ പിശക്

UDP ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഒരു ICMP സോഴ്സ് ക്വഞ്ച് പിശക് സൃഷ്ടിക്കാൻ കഴിയും. ഒരു സിസ്റ്റത്തിന് (റൂട്ടർ അല്ലെങ്കിൽ ഹോസ്റ്റ്) ഡാറ്റാഗ്രാമുകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ വേഗത്തിൽ ഡാറ്റാഗ്രാമുകൾ ലഭിക്കുമ്പോൾ ഈ പിശക് സൃഷ്ടിക്കാൻ കഴിയും. "ആയിരിക്കാം" എന്ന പ്രയോഗം ശ്രദ്ധിക്കുക. ബഫറുകൾ നിറഞ്ഞിരിക്കുകയും ഡാറ്റാഗ്രാമുകൾ നിരസിക്കുകയും ചെയ്‌താലും സിസ്റ്റത്തിന് സോഴ്‌സ് സപ്രഷൻ അയയ്‌ക്കേണ്ട ആവശ്യമില്ല.

ചിത്രം 11.18 ഐസിഎംപി സോഴ്സ് സപ്രഷൻ പിശക് ഫോർമാറ്റ് കാണിക്കുന്നു. ഞങ്ങളുടെ ടെസ്റ്റ് നെറ്റ്‌വർക്കിൽ സമാനമായ ഒരു പിശക് സൃഷ്ടിക്കാൻ ഞങ്ങൾ അനുയോജ്യമായ സ്ഥാനത്താണ്. ഞങ്ങൾക്ക് bsdi-ൽ നിന്ന് റൂട്ടർ സൺ-ലേക്ക് ഇഥർനെറ്റിലേക്ക് ഡാറ്റാഗ്രാമുകൾ അയയ്‌ക്കാൻ കഴിയും, ഈ ഡാറ്റാഗ്രാമുകൾ ഒരു SLIP ചാനലിലൂടെ റൂട്ട് ചെയ്യണം. SLIP ചാനൽ ഇഥർനെറ്റിനേക്കാൾ ആയിരം മടങ്ങ് വേഗത കുറഞ്ഞതിനാൽ, നമുക്ക് ബഫർ എളുപ്പത്തിൽ ഓവർഫ്ലോ ചെയ്യാൻ കഴിയും. ഇനിപ്പറയുന്ന കമാൻഡ് ഹോസ്റ്റ് ബിഎസ്ഡിയിൽ നിന്ന് റൂട്ടർ സൺ വഴി സോളാരിസിലേക്ക് 100 1024 ബൈറ്റ് ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്നു. സ്റ്റാൻഡേർഡ് ഡിസ്കാർഡ് സേവനത്തിലേക്ക് ഞങ്ങൾ ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്നു, അവിടെ അവ അവഗണിക്കപ്പെടും:

>ബിഎസ്ഡി % sock -u -i -w1024 -n100 സോളാരിസ് നിരസിക്കുക

ചിത്രം 11.18 ICMP സോഴ്സ് സപ്രഷൻ പിശക്.

ഈ കമാൻഡിന് അനുയോജ്യമായ tcpdump ഔട്ട്പുട്ട് ചിത്രം 11.19 കാണിക്കുന്നു.

>

1 0.0 bsdi.1403 > solaris.discard: udp 1024
26 വരികൾ കാണിച്ചിട്ടില്ല
27 0.10 (0.00) bsdi.1403 > solaris.discard: udp 1024
28 0.11 (0.01) സൂര്യൻ > bsdi: icmp: source quench

29 0.11 (0.00) bsdi.1403 > solaris.discard: udp 1024
30 0.11 (0.00) സൂര്യൻ > bsdi: icmp: source quench
142 വരികൾ കാണിച്ചിട്ടില്ല
173 0.71 (0.06) bsdi.1403 > solaris.discard: udp 1024
174 0.71 (0.00) സൂര്യൻ > bsdi: icmp: source quench

ചിത്രം 11.19 റൂട്ടർ സൂര്യനിൽ നിന്നുള്ള ഐസിഎംപി ഉറവിടം അടിച്ചമർത്തൽ.

ഈ ഔട്ട്‌പുട്ടിൽ നിന്ന് ഞങ്ങൾ നിരവധി വരികൾ നീക്കം ചെയ്‌തു. ആദ്യത്തെ 26 ഡാറ്റാഗ്രാമുകൾ പിശകുകളില്ലാതെ ലഭിച്ചു: ആദ്യത്തേതിന്റെ ഔട്ട്പുട്ട് മാത്രമാണ് ഞങ്ങൾ കാണിച്ചത്. 27-മത്തെ ഡാറ്റാഗ്രാം മുതൽ, ഓരോ തവണയും ഒരു ഡാറ്റാഗ്രാം അയയ്‌ക്കുമ്പോൾ ഞങ്ങൾക്ക് ഒരു സോഴ്‌സ് സപ്രഷൻ പിശക് ലഭിക്കും. ആകെ 26+(74x2)=174 ലൈനുകൾ ഔട്ട്‌പുട്ട് ഉണ്ടായിരുന്നു.

അധ്യായം 2-ലെ ഞങ്ങളുടെ സീരിയൽ ലൈൻ ബാൻഡ്‌വിഡ്ത്ത് കണക്കുകൂട്ടലിൽ നിന്ന്, 9600 bps-ൽ 1024-ബൈറ്റ് ഡാറ്റാഗ്രാം ട്രാൻസ്മിറ്റ് ചെയ്യാൻ ഒരു സെക്കൻഡിൽ കൂടുതൽ സമയമെടുക്കുമെന്ന് നമുക്ക് കാണാൻ കഴിയും. (ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ഇത് കൂടുതൽ സമയമെടുക്കും, കാരണം 20+8+1024 ബൈറ്റുകളുടെ ഒരു ഡാറ്റഗ്രാം വിഭജിക്കപ്പെടും, കാരണം സൂര്യനിൽ നിന്ന് netb-ലേക്കുള്ള SLIP ലിങ്കിന്റെ MTU 552 ബൈറ്റുകളാണ്.) എന്നിരുന്നാലും, ചിത്രം 11.19-ൽ കാണിച്ചിരിക്കുന്ന സമയം മുതൽ, നമുക്ക് കാണാം. SLIP ചാനലിൽ ആദ്യത്തേത് അയയ്‌ക്കുന്നതിന് മുമ്പ് റൂട്ടർ സൺ എല്ലാ 100 ഡാറ്റാഗ്രാമുകളും ഒരു സെക്കൻഡിനുള്ളിൽ ലഭിച്ചു. അതിന്റെ പല ബഫറുകളും ഞങ്ങൾ ഉപയോഗിച്ചുവെന്നത് വ്യക്തമാണ്.

RFC 1009-ന് അതിന്റെ ബഫറുകൾ നിറയുമ്പോൾ സോഴ്‌സ് സപ്രഷൻ പിശകുകൾ സൃഷ്ടിക്കാൻ ഒരു റൂട്ടർ ആവശ്യമാണെങ്കിലും, പുതിയ റൂട്ടർ ആവശ്യകതകൾ RFC [Almquist 1993] ഇത് മാറ്റുകയും ഒരു റൂട്ടർ സോഴ്‌സ് സപ്രഷൻ പിശകുകൾ സൃഷ്ടിക്കരുതെന്ന് പറയുന്നു.

ഉദാഹരണത്തിൽ ശ്രദ്ധിക്കേണ്ട അടുത്ത കാര്യം, സോക്ക് പ്രോഗ്രാമിന് ഒരിക്കലും ഉറവിടം അടിച്ചമർത്തപ്പെട്ടതായി അറിയിപ്പുകൾ ലഭിച്ചിട്ടില്ല, അല്ലെങ്കിൽ അങ്ങനെ സംഭവിച്ചാൽ അത് അവഗണിച്ചു എന്നതാണ്. യു‌ഡി‌പി പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുമ്പോൾ ബിഎസ്‌ഡി നടപ്പിലാക്കലുകൾ സാധാരണയായി ലഭിച്ച ഉറവിട അടിച്ചമർത്തൽ സന്ദേശങ്ങളെ അവഗണിക്കുന്നുവെന്ന് ഇത് സൂചിപ്പിക്കുന്നു. (ടിസിപിയുടെ കാര്യത്തിൽ, ഒരു അറിയിപ്പ് ലഭിക്കുമ്പോൾ, ഉറവിടം അടിച്ചമർത്തൽ സൃഷ്ടിക്കപ്പെടുന്ന ഒരു കണക്ഷനിലെ ഡാറ്റാ ട്രാൻസ്മിഷൻ മന്ദഗതിയിലാകുന്നു. ഞങ്ങൾ ഇത് അദ്ധ്യായം 21-ന്റെ വിഭാഗത്തിൽ ചർച്ച ചെയ്യും.) ഡാറ്റ സൃഷ്ടിച്ച പ്രക്രിയയാണ് പ്രശ്നം സ്രോതസ്സ് അടിച്ചമർത്തൽ സന്ദേശം ലഭിക്കുമ്പോൾ, അടിച്ചമർത്തൽ ഉറവിടം ഇതിനകം പൂർത്തിയാക്കിയിരിക്കാം. തീർച്ചയായും, സോക്ക് പ്രോഗ്രാം എത്ര നേരം പ്രവർത്തിക്കുന്നുണ്ടെന്ന് കണക്കാക്കാൻ യുണിക്സ് ടൈം പ്രോഗ്രാം ഉപയോഗിക്കുകയാണെങ്കിൽ, അത് ഏകദേശം 0.5 സെക്കൻഡ് മാത്രമേ പ്രവർത്തിച്ചിട്ടുള്ളൂവെന്ന് ഞങ്ങൾ കണ്ടെത്തുന്നു. എന്നിരുന്നാലും, ആദ്യത്തെ ഡാറ്റാഗ്രാം അയച്ച് 0.71 സെക്കൻഡുകൾക്ക് ശേഷം, അതായത്, പ്രക്രിയയുടെ പ്രവർത്തനം നിർത്തിയതിന് ശേഷം ചില ഉറവിട സപ്രഷൻ സന്ദേശങ്ങൾ ലഭിച്ചതായി ചിത്രം 11.19-ൽ ഞങ്ങൾ കണ്ടു. ഞങ്ങളുടെ പ്രോഗ്രാം 100 ഡാറ്റാഗ്രാമുകൾ നിർമ്മിക്കുകയും പുറത്തുകടക്കുകയും ചെയ്താൽ എന്ത് സംഭവിക്കും. എല്ലാ 100 ഡാറ്റാഗ്രാമുകളും അയയ്‌ക്കില്ല - അവയിൽ ചിലത് ഔട്ട്‌പുട്ട് ക്യൂവിൽ ആയിരിക്കും.

UDP ഒരു വിശ്വസനീയമല്ലാത്ത പ്രോട്ടോക്കോൾ ആണെന്നും ഒഴുക്ക് നിയന്ത്രണത്തിന്റെ പ്രാധാന്യം കാണിക്കുന്നുവെന്നും ഈ ഉദാഹരണം തെളിയിക്കുന്നു. സോക്ക് പ്രോഗ്രാം നെറ്റ്‌വർക്കിലേക്ക് 100 ഡാറ്റാഗ്രാമുകൾ വിജയകരമായി അയച്ചെങ്കിലും 26 എണ്ണം മാത്രമേ ലക്ഷ്യസ്ഥാനത്ത് എത്തിയിട്ടുള്ളൂ. ശേഷിക്കുന്ന 74 എണ്ണം ഇന്റർമീഡിയറ്റ് റൂട്ടർ ഉപേക്ഷിച്ചതാകാനാണ് സാധ്യത. ആപ്ലിക്കേഷൻ ഏതെങ്കിലും തരത്തിലുള്ള അറിയിപ്പുകളെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, സ്വീകർത്താവ് ഡാറ്റ സ്വീകരിച്ചിട്ടുണ്ടോ എന്ന് അയച്ചയാൾക്ക് അറിയില്ല.

UDP സെർവർ

സെർവറിന്റെ രൂപകൽപ്പനയെയും നിർവഹണത്തെയും ബാധിക്കുന്ന UDP ഉപയോഗിക്കുന്നതിന് നിരവധി സവിശേഷതകൾ ഉണ്ട്. സെർവറുകൾ നടപ്പിലാക്കുന്നതിനേക്കാൾ സാധാരണയായി ക്ലയന്റുകളെ രൂപകൽപ്പന ചെയ്യുന്നതും നടപ്പിലാക്കുന്നതും എളുപ്പമാണ്. അതുകൊണ്ടാണ് ക്ലയന്റ് വികസനത്തേക്കാൾ സെർവർ വികസനം ഞങ്ങൾ ഇവിടെ ചർച്ച ചെയ്യുന്നത്. സെർവറുകൾ സാധാരണയായി ഓപ്പറേറ്റിംഗ് സിസ്റ്റവുമായി ഇടപഴകുന്നു, ഒരേ സമയം ഒന്നിലധികം ക്ലയന്റുകളിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ മിക്ക സെർവറുകളും ആവശ്യപ്പെടുന്നു.

സാധാരണയായി, ഒരു ക്ലയന്റ് ആരംഭിക്കുമ്പോൾ, അത് ഉടനടി ഒരു സെർവറിലേക്ക് ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നു. മറുവശത്ത്, സെർവറുകൾ ആരംഭിക്കുകയും തുടർന്ന് ഒരു ക്ലയന്റിൽനിന്ന് ഒരു അഭ്യർത്ഥന ലഭിക്കുന്നതിനായി കാത്തിരിക്കുമ്പോൾ ഉറങ്ങുകയും ചെയ്യുന്നു. UDP-യുടെ കാര്യത്തിൽ, ക്ലയന്റിൽനിന്ന് ഒരു ഡാറ്റഗ്രാം വരുമ്പോൾ സെർവർ "ഉണരുന്നു", ഈ ഡാറ്റാഗ്രാമിൽ ഏതെങ്കിലും രൂപത്തിൽ ഒരു അഭ്യർത്ഥന അടങ്ങിയിരിക്കാം.

ക്ലയന്റുകളുടെയും സെർവറുകളുടെയും പ്രോഗ്രാമിംഗ് വശങ്ങൾ ഞങ്ങൾ പരിഗണിക്കില്ല (അവൻ എല്ലാം കൂടുതൽ വിശദമായി വിവരിക്കുന്നു), എന്നാൽ UDP ഉപയോഗിക്കുന്ന ഒരു സെർവറിന്റെ രൂപകൽപ്പനയും നടപ്പിലാക്കലും ബാധിക്കുന്ന UDP പ്രോട്ടോക്കോളിന്റെ സവിശേഷതകൾ ഞങ്ങൾ പരിഗണിക്കും. (അധ്യായം 18-ലെ ഒരു വിഭാഗത്തിൽ TCP സെർവറിന്റെ വിശദാംശങ്ങൾ ഞങ്ങൾ ചർച്ച ചെയ്യും.) UDP നിർവ്വഹണങ്ങളെ ആശ്രയിച്ച് ഞങ്ങൾ ചില സവിശേഷതകൾ ചർച്ച ചെയ്യും, കൂടാതെ മിക്ക നടപ്പിലാക്കലുകൾക്കും പൊതുവായുള്ള സവിശേഷതകളും ഞങ്ങൾ പരിശോധിക്കും.

ക്ലയന്റ് ഐപി വിലാസവും പോർട്ട് നമ്പറും

ഒരു UDP ഡാറ്റഗ്രാം ക്ലയന്റിൽ നിന്ന് വരുന്നു. ഐപി തലക്കെട്ടിൽ ഉറവിടവും ലക്ഷ്യസ്ഥാന ഐപി വിലാസങ്ങളും അടങ്ങിയിരിക്കുന്നു, കൂടാതെ യുഡിപി തലക്കെട്ടിൽ ഉറവിടവും ലക്ഷ്യസ്ഥാന യുഡിപി പോർട്ട് നമ്പറുകളും അടങ്ങിയിരിക്കുന്നു. ഒരു ആപ്ലിക്കേഷന് UDP ഡാറ്റഗ്രാം ലഭിക്കുമ്പോൾ, ആരാണ് സന്ദേശം അയച്ചതെന്ന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പറയണം - ഉറവിട IP വിലാസവും പോർട്ട് നമ്പറും.

ഒന്നിലധികം ക്ലയന്റുകളെ കൈകാര്യം ചെയ്യാൻ ഒരു യുഡിപി സെർവറിനെ ഈ സ്വഭാവം അനുവദിക്കുന്നു. ഓരോ പ്രതികരണവും അഭ്യർത്ഥന അയച്ച ക്ലയന്റിലേക്ക് അയയ്ക്കുന്നു.

ലക്ഷ്യസ്ഥാന ഐപി വിലാസം

ചില ആപ്ലിക്കേഷനുകൾക്ക് ഡാറ്റാഗ്രാം ആർക്കാണ് ഉദ്ദേശിച്ചിട്ടുള്ളതെന്ന് അറിയേണ്ടതുണ്ട്, അതായത് ലക്ഷ്യസ്ഥാന ഐപി വിലാസം. ഉദാഹരണത്തിന്, ഒരു TFTP സെർവർ ഒരു പ്രക്ഷേപണ വിലാസത്തിലേക്ക് അയച്ച ഡാറ്റാഗ്രാമുകൾ അവഗണിക്കണമെന്ന് ഹോസ്റ്റ് ആവശ്യകതകൾ RFC വ്യക്തമാക്കുന്നു. (ഇൽ ബ്രോഡ്കാസ്റ്റ് അഡ്രസ്സിംഗും TFTP ൽ ഞങ്ങൾ വിവരിക്കും.)

ഇതിനർത്ഥം, ലഭിച്ച യുഡിപി ഡാറ്റാഗ്രാമിൽ നിന്ന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ലക്ഷ്യസ്ഥാന ഐപി വിലാസം ആപ്ലിക്കേഷനിലേക്ക് കൈമാറണം എന്നാണ്. നിർഭാഗ്യവശാൽ, എല്ലാ നടപ്പാക്കലുകളും ഈ സവിശേഷത നൽകുന്നില്ല.

IP_RECVDSTADDR ഓപ്ഷൻ ഉപയോഗിച്ച് സോക്കറ്റ്സ് API ഈ കഴിവ് നൽകുന്നു. വാചകത്തിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന സിസ്റ്റങ്ങളിൽ, BSD/386, 4.4BSD, AIX 3.2.2 എന്നിവ മാത്രമേ ഈ ഓപ്ഷനെ പിന്തുണയ്ക്കുന്നുള്ളൂ. SVR4, SunOS 4.x, Solaris 2.x എന്നിവ പിന്തുണയ്ക്കുന്നില്ല.

UDP ഇൻപുട്ട് ക്യൂ

അധ്യായം 1 വിഭാഗത്തിൽ, മിക്ക UDP സെർവറുകൾക്കും ഒരൊറ്റ UDP പോർട്ട് (മുൻപ് അറിയപ്പെടുന്ന സെർവർ പോർട്ടുകൾ) ഉപയോഗിച്ച് ക്ലയന്റുകൾക്ക് എല്ലാ അഭ്യർത്ഥനകളും നൽകാമെന്ന് ഞങ്ങൾ പറഞ്ഞു.

സാധാരണഗതിയിൽ, ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന ഓരോ UDP പോർട്ടുമായി ബന്ധപ്പെട്ട ഇൻപുട്ട് ക്യൂവിന്റെ വലുപ്പം പരിമിതമാണ്. വ്യത്യസ്ത ക്ലയന്റുകളിൽ നിന്ന് ഒരേ സമയം വരുന്ന അഭ്യർത്ഥനകൾ ഒരു UDP ക്യൂവിൽ യാന്ത്രികമായി ക്യൂവിലാണ് എന്നാണ് ഇതിനർത്ഥം. സ്വീകരിച്ച UDP ഡാറ്റാഗ്രാമുകൾ അവ ലഭിച്ച ക്രമത്തിൽ ആപ്ലിക്കേഷനിലേക്ക് (അത് അടുത്ത ഡാറ്റാഗ്രാം അഭ്യർത്ഥിക്കുമ്പോൾ) അയയ്ക്കും.

എന്നിരുന്നാലും, ക്യൂ നിറഞ്ഞാൽ, കേർണലിലെ UDP മൊഡ്യൂൾ ഇൻകമിംഗ് ഡാറ്റാഗ്രാമുകൾ നിരസിക്കാനുള്ള സാധ്യതയുണ്ട്. ഇനിപ്പറയുന്ന പരീക്ഷണത്തിലൂടെ നമുക്ക് ഇത് നിരീക്ഷിക്കാൻ കഴിയും. ഞങ്ങൾ ഞങ്ങളുടെ സോക്ക് പ്രോഗ്രാം bsdi ഹോസ്റ്റിൽ ആരംഭിക്കുന്നു, അങ്ങനെ UDP സെർവർ ആരംഭിക്കുന്നു:

>

bsdi % sock -s -u -v -E -R256 -r256 -P30 6666
140.252.13.33 മുതൽ 140.252.13.63 വരെ: 1111111111 സൂര്യനിൽ നിന്ന് പ്രക്ഷേപണ വിലാസത്തിലേക്ക്
140.252.13.34 മുതൽ 140.252.13.35 വരെ: 4444444444444 svr4 മുതൽ വ്യക്തിഗത വിലാസം വരെ

ഞങ്ങൾ ഇനിപ്പറയുന്ന ഫ്ലാഗുകൾ ഉപയോഗിച്ചു: -s, പ്രോഗ്രാം ഒരു സെർവറായി പ്രവർത്തിപ്പിക്കുന്നു, UDP-യ്‌ക്ക് -u, -v, ക്ലയന്റിന്റെ IP വിലാസം പ്രിന്റ് ചെയ്യുന്നു, കൂടാതെ -E ലക്ഷ്യസ്ഥാന IP വിലാസം പ്രിന്റ് ചെയ്യുന്നു (ഈ സാഹചര്യത്തിൽ സിസ്റ്റം അത് അനുവദിക്കുന്നു). കൂടാതെ, ഈ പോർട്ടിനായുള്ള യുഡിപി റിസീവ് ബഫർ 256 ബൈറ്റുകളായി ( -R) ഞങ്ങൾ സജ്ജീകരിച്ചു, അതോടൊപ്പം ഓരോ ആപ്ലിക്കേഷനും വായിക്കാൻ കഴിയുന്ന വലുപ്പം ( -r). ആദ്യത്തെ ഡാറ്റാഗ്രാം വായിക്കുന്നതിന് മുമ്പ് UDP പോർട്ട് ക്ലിയർ ചെയ്തതിന് ശേഷം 30 സെക്കൻഡ് കാത്തിരിക്കാൻ -P30 ഫ്ലാഗ് നിങ്ങളോട് പറയുന്നു. മറ്റ് രണ്ട് ഹോസ്റ്റുകളിൽ ക്ലയന്റുകൾ ആരംഭിക്കാനും കുറച്ച് ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കാനും സ്വീകരിക്കുന്ന ക്യൂ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാനും ഇത് ഞങ്ങൾക്ക് സമയം നൽകുന്നു.

സെർവർ ആരംഭിക്കുകയും 30 സെക്കൻഡ് താൽക്കാലികമായി നിർത്തുകയും ചെയ്‌ത ശേഷം, ഞങ്ങൾ ഹോസ്റ്റ് സണ്ണിൽ ഒരു ക്ലയന്റ് ആരംഭിക്കുകയും മൂന്ന് ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുകയും ചെയ്യുന്നു:

>

സൂര്യൻ% സോക്ക് -യു -വി 140.252.13.63 6666ഇഥർനെറ്റ് പ്രക്ഷേപണ വിലാസത്തിലേക്ക്
140.252.13.33.1252 മുതൽ 140.252.13.63.6666 വരെ ബന്ധിപ്പിച്ചിരിക്കുന്നു
1111111111 11 ബൈറ്റ് ഡാറ്റ (പുതിയ ലൈനിനൊപ്പം)
222222222 ഡാറ്റയുടെ 10 ബൈറ്റുകൾ (പുതിയ ലൈനിനൊപ്പം)
33333333333 12 ബൈറ്റ് ഡാറ്റ (പുതിയ ലൈനിനൊപ്പം)

ബ്രോഡ്കാസ്റ്റ് വിലാസമാണ് ലക്ഷ്യസ്ഥാന വിലാസം (140.252.13.63). തുടർന്ന് ഞങ്ങൾ svr4 ഹോസ്റ്റിൽ മറ്റൊരു ക്ലയന്റ് ആരംഭിക്കുകയും മൂന്ന് ഡാറ്റാഗ്രാമുകൾ കൂടി അയയ്ക്കുകയും ചെയ്തു:

>

svr4% സോക്ക് -യു -വി ബിഎസ്ഡി 6666
0.0.0.0.1042 മുതൽ 140.252.13.35.6666 വരെ ബന്ധിപ്പിച്ചിരിക്കുന്നു
4444444444444 14 ബൈറ്റ് ഡാറ്റ (പുതിയ ലൈനിനൊപ്പം)
555555555555555 16 ബൈറ്റ് ഡാറ്റ (പുതിയ ലൈനിനൊപ്പം)
66666666 ഡാറ്റയുടെ 9 ബൈറ്റുകൾ (പുതിയ ലൈനിനൊപ്പം)

നേരത്തെ bsdi-യിൽ കാണിച്ചിരിക്കുന്ന ഇന്ററാക്ടീവ് ഔട്ട്‌പുട്ടിൽ ആദ്യം ശ്രദ്ധിക്കേണ്ട കാര്യം, രണ്ട് ഡാറ്റാഗ്രാമുകൾ മാത്രമാണ് ആപ്ലിക്കേഷന് ലഭിച്ചത്: ആദ്യത്തേത് സൂര്യനിൽ നിന്ന്, എല്ലാം ഒന്നായിരുന്നു, ആദ്യത്തേത് svr4-ൽ നിന്ന്, അത് നാലും ആയിരുന്നു. ബാക്കിയുള്ള നാല് ഡാറ്റാഗ്രാമുകൾ ഉപേക്ഷിച്ചു.

ചിത്രം 11.20-ലെ tcpdump കമാൻഡ് ഔട്ട്‌പുട്ട് കാണിക്കുന്നത് ആറ് ഡാറ്റാഗ്രാമുകളും ഡെസ്റ്റിനേഷൻ ഹോസ്റ്റിലേക്ക് ഡെലിവർ ചെയ്തിട്ടുണ്ടെന്ന്. രണ്ട് ക്ലയന്റുകളിൽ നിന്ന് വിപരീത ക്രമത്തിൽ ഡാറ്റാഗ്രാമുകൾ എത്തി: ആദ്യം സൂര്യനിൽ നിന്നും പിന്നീട് svr4 ൽ നിന്നും അങ്ങനെ. സെർവർ ഉറങ്ങുന്ന 30 സെക്കൻഡ് കാലയളവിൽ, ആറെണ്ണവും ഏകദേശം 12 സെക്കൻഡിനുള്ളിൽ ഡെലിവർ ചെയ്യപ്പെട്ടതും നമുക്ക് ശ്രദ്ധിക്കാം.

>

1 0.0 sun.1252 > 140.252.13.63.6666: udp 11
2 2.499184 (2.4992) svr4.1042 > bsdi.6666: udp 14
3 4.959166 (2.4600) sun.1252 > 140.252.13.63.6666: udp 10
4 7.607149 (2.6480) svr4.1042 > bsdi.6666: udp 16
5 10.079059 (2.4719) sun.1252 > 140.252.13.63.6666: udp 12
6 12.415943 (2.3369) svr4.1042 > bsdi.6666: udp 9

രണ്ട് ക്ലയന്റുകൾ അയച്ച UDP ഡാറ്റാഗ്രാമുകൾക്കുള്ള ചിത്രം 11.20 tcpdump ഔട്ട്പുട്ട്.

-E ഓപ്ഷൻ ഉപയോഗിച്ച്, ഓരോ ഡാറ്റാഗ്രാമിന്റെയും ലക്ഷ്യസ്ഥാന ഐപി വിലാസം സെർവറിന് കണ്ടെത്താൻ കഴിയും എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. പ്രക്ഷേപണ വിലാസത്തിലേക്ക് അയച്ച ആദ്യത്തെ ലഭിച്ച ഡാറ്റാഗ്രാം ഉപയോഗിച്ച് എന്തുചെയ്യണമെന്ന് സെർവറിന് തിരഞ്ഞെടുക്കാനാകും.

ഈ ഉദാഹരണത്തിൽ, ചില സവിശേഷതകൾ കൂടി ശ്രദ്ധിക്കേണ്ടത് ആവശ്യമാണ്. ആദ്യം, ഇൻപുട്ട് ക്യൂ നിറഞ്ഞപ്പോൾ ആപ്ലിക്കേഷൻ റിപ്പോർട്ട് ചെയ്തില്ല. അധിക യുഡിപി ഡാറ്റാഗ്രാമുകൾ നിരസിച്ചു. ഡാറ്റാഗ്രാമുകൾ നിരസിക്കപ്പെട്ടുവെന്ന് അറിയിക്കാൻ ക്ലയന്റിലേക്ക് ഒന്നും തിരിച്ച് അയച്ചിട്ടില്ലെന്നും tcpdump ഔട്ട്‌പുട്ടിൽ ഞങ്ങൾ കാണുന്നു. ഒരു ICMP സോഴ്‌സ് സപ്രഷൻ സന്ദേശവുമായി സാമ്യമുള്ള ഒന്നും അയച്ചിട്ടില്ല, തീർത്തും ഒന്നുമില്ല. അവസാനമായി, UDP ഇൻപുട്ട് ക്യൂ പ്രവർത്തിക്കുന്നത് FIFO (ഫസ്റ്റ് ഇൻ, ഫസ്റ്റ് ഔട്ട്) അടിസ്ഥാനത്തിലാണെന്ന് ചൂണ്ടിക്കാണിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, അതേസമയം, ഈ അധ്യായത്തിന്റെ വിഭാഗത്തിൽ നമ്മൾ കണ്ടതുപോലെ, ARP ഇൻപുട്ട് ക്യൂ പ്രവർത്തിക്കുന്നത് LIFO (അവസാനം, ആദ്യം പുറത്ത്) അടിസ്ഥാനം.

പ്രാദേശിക ഐപി വിലാസ പരിമിതി

മിക്ക UDP സെർവറുകളും UDP എൻഡ് പോയിന്റുകൾ സൃഷ്ടിക്കുമ്പോൾ അവരുടെ IP വിലാസങ്ങൾക്കായി വൈൽഡ്കാർഡുകൾ ഉപയോഗിക്കുന്നു. സെർവർ പോർട്ടിനായി ഉദ്ദേശിച്ചിട്ടുള്ള ഇൻകമിംഗ് യുഡിപി ഡാറ്റാഗ്രാം ഏത് പ്രാദേശിക ഇന്റർഫേസും സ്വീകരിക്കും എന്നാണ് ഇതിനർത്ഥം. ഉദാഹരണത്തിന്, പോർട്ട് 7777-ൽ നമുക്ക് ഒരു UDP സെർവർ ആരംഭിക്കാം:

>സൂര്യൻ% സോക്ക്-യു-എസ് 7777

ഈ എൻഡ് പോയിന്റിന്റെ സ്റ്റാറ്റസ് കാണുന്നതിന് നമ്മൾ netstat കമാൻഡ് ഉപയോഗിക്കും:

>

സൂര്യൻ% netstat -a -n -f inet
സജീവ ഇന്റർനെറ്റ് കണക്ഷനുകൾ (സെർവറുകൾ ഉൾപ്പെടെ)
Proto Recv-Q അയയ്ക്കുക-Q പ്രാദേശിക വിലാസം വിദേശ വിലാസം (സംസ്ഥാനം)
udp 0 0 *.7777 *.*

ഈ ഔട്ട്‌പുട്ടിൽ, ഞങ്ങൾ നിരവധി വരികൾ നീക്കം ചെയ്യുകയും ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ളവ മാത്രം അവശേഷിക്കുകയും ചെയ്തു. എല്ലാ നെറ്റ്‌വർക്ക് എൻഡ് പോയിന്റുകളിലും The -a ഫ്ലാഗ് റിപ്പോർട്ട് ചെയ്യുന്നു. -n ഫ്ലാഗ് DNS ഉപയോഗിക്കുന്നതിനും വിലാസങ്ങൾ പേരുകളാക്കി മാറ്റുന്നതിനുപകരം ദശാംശ നൊട്ടേഷനിൽ IP വിലാസങ്ങൾ പ്രിന്റ് ചെയ്യുന്നു, കൂടാതെ സേവന നാമങ്ങൾക്ക് പകരം പോർട്ട് നമ്പറുകൾ പ്രിന്റ് ചെയ്യുന്നു. -f inet ഓപ്ഷൻ TCP, UDP എൻഡ് പോയിന്റുകൾ മാത്രമേ റിപ്പോർട്ട് ചെയ്യുന്നുള്ളൂ.

പ്രാദേശിക വിലാസം *.7777 എന്ന് അച്ചടിച്ചിരിക്കുന്നു, ഇവിടെ നക്ഷത്രചിഹ്നം അർത്ഥമാക്കുന്നത് ഏത് വിലാസവും പ്രാദേശിക IP വിലാസമായി പകരം വയ്ക്കാം എന്നാണ്.

സെർവർ അതിന്റെ എൻഡ്‌പോയിന്റ് സൃഷ്‌ടിക്കുമ്പോൾ, ഹോസ്റ്റിന്റെ പ്രാദേശിക ഐപി വിലാസങ്ങളിലൊന്ന്, അതിന്റെ പ്രക്ഷേപണ വിലാസങ്ങളിലൊന്ന് ഉൾപ്പെടെ, എൻഡ്‌പോയിന്റിന്റെ പ്രാദേശിക ഐപി വിലാസമായി അത് വ്യക്തമാക്കാൻ കഴിയും. ഈ സാഹചര്യത്തിൽ, ഡെസ്റ്റിനേഷൻ ഐപി വിലാസം നിർദ്ദിഷ്ട പ്രാദേശിക വിലാസവുമായി പൊരുത്തപ്പെടുന്നെങ്കിൽ മാത്രമേ ഇൻകമിംഗ് യുഡിപി ഡാറ്റഗ്രാം എൻഡ് പോയിന്റിലേക്ക് ട്രാൻസ്മിറ്റ് ചെയ്യപ്പെടുകയുള്ളൂ. സോക്ക് പ്രോഗ്രാം ഉപയോഗിച്ച്, പോർട്ട് നമ്പറിന് മുമ്പായി നിങ്ങൾക്ക് ഒരു IP വിലാസം വ്യക്തമാക്കാൻ കഴിയും, കൂടാതെ ഈ IP വിലാസം അവസാന പോയിന്റിന്റെ പ്രാദേശിക IP വിലാസമായി മാറുന്നു. ഉദാഹരണത്തിന്,

>സൂര്യൻ% sock -u -s 140.252.1.29 7777

SLIP ഇന്റർഫേസിൽ വരുന്ന ഡാറ്റാഗ്രാമുകളിൽ നിന്ന്, 140.252.1.29 എന്ന വിലാസമുള്ള ഡാറ്റാഗ്രാമുകൾ തിരഞ്ഞെടുക്കുന്നു. netstat കമാൻഡ് ഔട്ട്പുട്ട് ഇതുപോലെ കാണപ്പെടും:

>

udp 0 0 140.252.1.29.7777 *.*

ഇഥർനെറ്റ് വഴി 140.252.13.35 വിലാസമുള്ള ഹോസ്റ്റ് bsdi-ൽ നിന്ന് ഈ സെർവറിലേക്ക് ഒരു ഡാറ്റഗ്രാം അയയ്‌ക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, പോർട്ട് ലഭ്യമല്ലാത്തതിനെക്കുറിച്ചുള്ള ഒരു ICMP പിശക് തിരികെ നൽകും. സെർവർ ഒരിക്കലും ഈ ഡാറ്റഗ്രാം കാണില്ല. ചിത്രം 11.21 ഇത് കൂടുതൽ വിശദമായി കാണിക്കുന്നു.

>

1 0.0 bsdi.1723 > sun.7777: udp 13
2 0.000822 (0.0008) sun > bsdi: icmp: sun udp പോർട്ട് 7777 ലഭ്യമല്ല

ചിത്രം 11.21 സെർവറിന്റെ പ്രാദേശിക വിലാസത്തിന്റെ പൊരുത്തക്കേട് കാരണം UDP ഡാറ്റാഗ്രാം പ്രോസസ്സിംഗ് പരാജയം.

ഒരേ പോർട്ടിൽ മറ്റ് സെർവറുകൾ പ്രവർത്തിപ്പിക്കുന്നത് സാധ്യമാണ്, ഓരോന്നിനും അതിന്റേതായ പ്രാദേശിക ഐപി വിലാസമുണ്ട്. എന്നിരുന്നാലും, അതേ പോർട്ട് നമ്പർ വീണ്ടും ഉപയോഗിക്കാൻ ആപ്ലിക്കേഷൻ സിസ്റ്റത്തെ അനുവദിക്കണം.

സോക്കറ്റ് ഓപ്ഷൻ SO_REUSEADDR API-ൽ വ്യക്തമാക്കിയിരിക്കണം. -A ഓപ്ഷൻ ഉപയോഗിച്ച് ഞങ്ങളുടെ സോക്ക് പ്രോഗ്രാം ഇത് ചെയ്യുന്നു.

സൺ ഹോസ്റ്റിൽ നമുക്ക് ഒരേ UDP പോർട്ടിൽ അഞ്ച് വ്യത്യസ്ത സെർവറുകൾ ആരംഭിക്കാം (8888):

>

സൂര്യൻ% sock -u -s 140.252.1.29 8888 SLIP ചാനലിനായി
സൂര്യൻ% സോക്ക് -യു -എസ് -എ 140.252.13.33 8888ഇഥർനെറ്റിനായി
സൂര്യൻ% സോക്ക് -യു -എസ് -എ 127.0.0.1 8888ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിനായി
സൂര്യൻ% സോക്ക് -യു -എസ് -എ 140.252.13.63 8888ഇഥർനെറ്റ് പ്രക്ഷേപണ അഭ്യർത്ഥനകൾക്കായി
സൂര്യൻ% സോക്ക്-യു-എസ്-എ 8888മറ്റെല്ലാത്തിനും (IP വിലാസത്തിലെ മെറ്റാക്യാരാക്‌ടറുകൾ)

സെർവറുകളിൽ ആദ്യത്തേത് -A ഫ്ലാഗ് ഉപയോഗിച്ച് ആരംഭിക്കുമെന്ന് പ്രതീക്ഷിച്ചിരുന്നു, അത് അതേ പോർട്ട് നമ്പർ വീണ്ടും ഉപയോഗിക്കാമെന്ന് സിസ്റ്റത്തോട് പറയുന്നു. netstat കമാൻഡ് ഔട്ട്പുട്ട് ഇനിപ്പറയുന്ന അഞ്ച് സെർവറുകൾ കാണിക്കുന്നു:

>

Proto Recv-Q അയയ്ക്കുക-Q പ്രാദേശിക വിലാസം വിദേശ വിലാസം (സംസ്ഥാനം)
udp 0 0 *.8888 *.*
udp 0 0 140.252.13.63.8888 *.*
udp 0 0 127.0.0.1 8888 *.*
udp 0 0 140.252.13.33 8888 *.*
udp 0 0 140.252.1.29 8888 *.*

ഈ സാഹചര്യത്തിൽ, 140.252.1.255 എന്ന വിലാസത്തിനായി നിശ്ചയിച്ചിട്ടുള്ള ഡാറ്റാഗ്രാമുകൾ മാത്രമേ പ്രാദേശിക IP വിലാസമായി ഉപയോഗിക്കുന്ന വൈൽഡ്കാർഡ് പ്രതീകങ്ങളുള്ള സെർവറിനെ ബാധിക്കുകയുള്ളൂ, കാരണം മറ്റ് നാല് സെർവറുകൾ സാധ്യമായ എല്ലാ വിലാസങ്ങളും ഉൾക്കൊള്ളുന്നു.

ഐപി അഡ്രസ് സബ്സ്റ്റിറ്റ്യൂഷൻ ഉപയോഗിക്കുമ്പോൾ, ഒരു മുൻഗണനാ സംവിധാനം ഉപയോഗിക്കുന്നു. ഡെസ്റ്റിനേഷൻ IP വിലാസവുമായി പൊരുത്തപ്പെടുന്ന ഒരു നിർദ്ദിഷ്ട IP വിലാസമുള്ള ഒരു എൻഡ്‌പോയിന്റ് എല്ലായ്പ്പോഴും ഒരു വൈൽഡ് കാർഡ് വിലാസത്തിന് മുമ്പായി തിരഞ്ഞെടുക്കപ്പെടും. നിർദ്ദിഷ്‌ട വിലാസത്തിന് പൊരുത്തമൊന്നും കണ്ടെത്താത്തപ്പോൾ മാത്രമാണ് വൈൽഡ്കാർഡ് എൻഡ്‌പോയിന്റ് ഉപയോഗിക്കുന്നത്.

ബാഹ്യ ഐപി വിലാസങ്ങൾ പരിമിതപ്പെടുത്തുന്നു

നമ്മൾ നേരത്തെ കാണിച്ച netstat കമാൻഡിന്റെ എല്ലാ ഔട്ട്പുട്ടിലും, റിമോട്ട് IP വിലാസങ്ങളും റിമോട്ട് പോർട്ട് നമ്പറുകളും *.* ആയി കാണിക്കുന്നു. ഏതെങ്കിലും IP വിലാസത്തിൽ നിന്നും ഏത് പോർട്ട് നമ്പറിൽ നിന്നും ഇൻകമിംഗ് UDP ഡാറ്റാഗ്രാമുകൾ എൻഡ് പോയിന്റ് സ്വീകരിക്കും എന്നാണ് ഇതിനർത്ഥം. വിദൂര വിലാസങ്ങൾ നിയന്ത്രിക്കാൻ മിക്ക നിർവ്വഹണങ്ങളും UDP എൻഡ് പോയിന്റുകളെ അനുവദിക്കുന്നു.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നിർദ്ദിഷ്ട IP വിലാസത്തിൽ നിന്നും പോർട്ട് നമ്പറിൽ നിന്നും UDP ഡാറ്റാഗ്രാമുകൾ മാത്രമേ എൻഡ് പോയിന്റിന് സ്വീകരിക്കാൻ കഴിയൂ. വിദൂര IP വിലാസവും പോർട്ട് നമ്പറും വ്യക്തമാക്കുന്നതിന് ഞങ്ങളുടെ സോക്ക് പ്രോഗ്രാം -f ഓപ്ഷൻ ഉപയോഗിക്കുന്നു:

>സൂര്യൻ% sock -u -s -f 140.252.13.35.4444 5555

ഈ സാഹചര്യത്തിൽ, വിദൂര IP വിലാസം 140.252.13.35 ആയും (ഞങ്ങളുടെ ഹോസ്റ്റ് bsdi), റിമോട്ട് പോർട്ട് നമ്പർ 4444 ആയും സജ്ജീകരിച്ചിരിക്കുന്നു. മുൻകൂട്ടി അറിയപ്പെടുന്ന സെർവർ പോർട്ട് 5555 ആണ്. നമ്മൾ netstat പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, പ്രാദേശിക IP വിലാസം ഞങ്ങൾ കാണും. ഞങ്ങൾ നേരിട്ട് വ്യക്തമാക്കിയിട്ടില്ലെങ്കിലും, സജ്ജീകരിച്ചിരിക്കുന്നു:

>

Proto Recv-Q അയയ്ക്കുക-Q പ്രാദേശിക വിലാസം വിദേശ വിലാസം (സംസ്ഥാനം)
udp 0 0 140.252.13.33.5555 140.252.13.35.4444

ബെർക്ക്‌ലി സിസ്റ്റങ്ങളിൽ ഒരു റിമോട്ട് ഐപി വിലാസവും റിമോട്ട് പോർട്ട് നമ്പറും വ്യക്തമാക്കുന്നതിന്റെ ഒരു പാർശ്വഫലമാണിത്: റിമോട്ട് വിലാസം സജ്ജീകരിക്കുമ്പോൾ ഒരു പ്രാദേശിക ഐപി വിലാസം തിരഞ്ഞെടുത്തില്ലെങ്കിൽ, പ്രാദേശിക വിലാസം സ്വയമേവ തിരഞ്ഞെടുക്കപ്പെടും. നിർദ്ദിഷ്ട വിദൂര ഐപി വിലാസത്തിൽ എത്താൻ ഐപി റൂട്ടിംഗ് ഉപയോഗിച്ച് തിരഞ്ഞെടുത്ത ഇന്റർഫേസിന്റെ ഐപി വിലാസത്തിലേക്ക് പ്രാദേശിക ഐപി വിലാസം സജ്ജീകരിച്ചിരിക്കുന്നു. തീർച്ചയായും, ഈ ഉദാഹരണത്തിൽ, വിദൂര വിലാസവുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന ഇഥർനെറ്റിന്റെ സൂര്യന്റെ IP വിലാസം 140.252.13.33 ആണ്.

UDP സെർവറിന് സ്വയം സജ്ജമാക്കാൻ കഴിയുന്ന മൂന്ന് തരം വിലാസങ്ങളും പോർട്ടുകളും ചിത്രം 11.22 കാണിക്കുന്നു.

ചിത്രം 11.22 UDP സെർവറിനായുള്ള പ്രാദേശികവും വിദൂരവുമായ IP വിലാസങ്ങളും പോർട്ട് നമ്പറും വ്യക്തമാക്കുന്നു.

എല്ലാ സാഹചര്യങ്ങളിലും, lport എന്നത് സെർവറിന്റെ മുൻകൂട്ടി അറിയപ്പെടുന്ന പോർട്ട് ആണ്, കൂടാതെ ലോക്കൽ ഇന്റർഫേസിന്റെ IP വിലാസം ലോക്കൽ ഐപി ആയിരിക്കണം. ചിത്രം 11.22-ൽ മൂന്ന് വരികൾ ക്രമീകരിച്ചിരിക്കുന്ന ക്രമം, ഏത് ലോക്കൽ എൻഡ്‌പോയിന്റിന് ഇൻകമിംഗ് ഡാറ്റാഗ്രാം ലഭിച്ചുവെന്ന് നിർണ്ണയിക്കാൻ UDP മൊഡ്യൂൾ ശ്രമിക്കുന്ന ക്രമം കാണിക്കുന്നു. ഏറ്റവും നിയന്ത്രിത വിലാസം-ടു-പോർട്ട് അസ്സോസിയേഷൻ (ആദ്യ വരി) ആദ്യം തിരഞ്ഞെടുത്തു, കുറഞ്ഞ നിയന്ത്രണമുള്ളത് (ഐപി വിലാസവും പോർട്ട് നമ്പറും മെറ്റാക്യാരാക്റ്ററുകളായി വ്യക്തമാക്കിയിരിക്കുന്ന അവസാന വരി) അവസാനമായി തിരഞ്ഞെടുത്തു.

ഓരോ പോർട്ടിനും ഒന്നിലധികം സ്വീകരണം

RFC-യിൽ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിലും, മിക്ക നിർവ്വഹണങ്ങളും ഒരു പ്രാദേശിക വിലാസവും UDP പോർട്ട് നമ്പറുമായി ബന്ധപ്പെടുത്താൻ ഒരു സമയം ഒരു ആപ്ലിക്കേഷനെ മാത്രമേ അനുവദിക്കൂ. ഒരു യുഡിപി ഡാറ്റഗ്രാം അതിന്റെ ഐപി വിലാസത്തിലും പോർട്ട് നമ്പറിലും ഡെസ്റ്റിനേഷൻ ഹോസ്റ്റിൽ എത്തുമ്പോൾ, ഒരു കോപ്പി ഒരൊറ്റ എൻഡ് പോയിന്റിലേക്ക് ഡെലിവർ ചെയ്യപ്പെടും. എൻഡ്‌പോയിന്റിന്റെ ഐപി വിലാസം നേരത്തെ കാണിച്ചത് പോലെ വൈൽഡ്കാർഡുകളായി പ്രതിനിധീകരിക്കാം.

ഉദാഹരണത്തിന്, SunOS 4.1.3-ൽ ഞങ്ങൾ ഒരു സെർവർ പോർട്ട് 9999-ൽ വൈൽഡ് കാർഡുകളുടെ രൂപത്തിൽ ഒരു പ്രാദേശിക IP വിലാസം ഉപയോഗിച്ച് ആരംഭിച്ചു:

>സൂര്യൻ% സോക്ക്-യു-എസ് 9999

അതേ പ്രാദേശിക വൈൽഡ്കാർഡ് വിലാസവും അതേ പോർട്ടും ഉപയോഗിച്ച് ഞങ്ങൾ മറ്റൊരു സെർവർ ആരംഭിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ -A ഓപ്ഷൻ വ്യക്തമാക്കിയാലും അത് പ്രവർത്തിക്കില്ല:

>

സൂര്യൻ% സോക്ക്-യു-എസ് 9999ഇത് ഇങ്ങനെ സംഭവിക്കാൻ പാടില്ല
പ്രാദേശിക വിലാസം ബന്ധിപ്പിക്കാൻ കഴിയില്ല: വിലാസം ഇതിനകം ഉപയോഗത്തിലാണ്

സൂര്യൻ% സോക്ക്-യു-എസ്-എ 9999അതുകൊണ്ടാണ് ഞങ്ങൾ -A ഫ്ലാഗ് വ്യക്തമാക്കിയത്
പ്രാദേശിക വിലാസം ബന്ധിപ്പിക്കാൻ കഴിയില്ല: വിലാസം ഇതിനകം ഉപയോഗത്തിലാണ്

മൾട്ടികാസ്റ്റ് പിന്തുണയ്ക്കുന്ന സിസ്റ്റങ്ങൾക്ക് (കാണുക), കാര്യങ്ങൾ വ്യത്യസ്തമാണ്. ഒന്നിലധികം എൻഡ്‌പോയിന്റുകൾക്ക് ഒരേ പ്രാദേശിക വിലാസവും UDP പോർട്ട് നമ്പറും ഉപയോഗിക്കാൻ കഴിയും, എന്നാൽ ഇത് അനുവദനീയമാണെന്ന് ആപ്ലിക്കേഷൻ API-യോട് പറയണം (-A ഫ്ലാഗ് SO_REUSEADDR സോക്കറ്റ് ഓപ്ഷൻ ഉപയോഗിക്കുന്നു).

മൾട്ടികാസ്റ്റിംഗിനെ പിന്തുണയ്ക്കുന്ന 4.4BSD, ഒരേ പോർട്ട് പങ്കിടാൻ ഒന്നിലധികം എൻഡ്‌പോയിന്റുകൾ അനുവദിക്കുന്നതിന് മറ്റൊരു സോക്കറ്റ് ഓപ്ഷൻ (SO_REUSEPORT) സജ്ജീകരിക്കാൻ ആപ്ലിക്കേഷന് ആവശ്യമാണ്. മാത്രമല്ല, ഈ പോർട്ട് ഉപയോഗിക്കുന്ന ആദ്യ എൻഡ് പോയിന്റ് ഉൾപ്പെടെ എല്ലാ എൻഡ് പോയിന്റും ഈ ഓപ്‌ഷൻ വ്യക്തമാക്കണം.

ഒരു യുഡിപി ഡാറ്റഗ്രാം അതിന്റെ ലക്ഷ്യസ്ഥാന ഐപി വിലാസത്തിൽ എത്തുമ്പോൾ, അത് ഒരു ബ്രോഡ്‌കാസ്റ്റ് അല്ലെങ്കിൽ മൾട്ടികാസ്റ്റ് വിലാസമാണ്, കൂടാതെ ആ ഐപി വിലാസവും പോർട്ട് നമ്പറുമായി ബന്ധപ്പെട്ട ഒന്നിലധികം എൻഡ്‌പോയിന്റുകൾ ഉണ്ടെങ്കിൽ, ഇൻകമിംഗ് ഡാറ്റാഗ്രാമിന്റെ ഒരു പകർപ്പ് ഓരോ എൻഡ്‌പോയിന്റിലേക്കും അയയ്ക്കും. (എൻഡ്‌പോയിന്റിന്റെ പ്രാദേശിക ഐപി വിലാസം വൈൽഡ്‌കാർഡുകളായി വ്യക്തമാക്കാം, അത് ഏത് ലക്ഷ്യസ്ഥാന ഐപി വിലാസവുമായി പൊരുത്തപ്പെടും.) എന്നിരുന്നാലും, എത്തിച്ചേരുന്ന ഐപി ഡാറ്റാഗ്രാമിന് ഒരു സ്വകാര്യ വിലാസമായ ഡെസ്റ്റിനേഷൻ ഐപി വിലാസമുണ്ടെങ്കിൽ, ഡാറ്റാഗ്രാമിന്റെ ഒരു പകർപ്പ് മാത്രമേ ഒരു എൻഡ്‌പോയിന്റിലേക്ക് കൈമാറുകയുള്ളൂ. വ്യക്തിഗത വിലാസ ഡാറ്റഗ്രാം ഏത് എൻഡ് പോയിന്റ് സ്വീകരിക്കുന്നു എന്നത് നടപ്പിലാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു.

ഹ്രസ്വമായ നിഗമനങ്ങൾ

UDP ഒരു ലളിതമായ പ്രോട്ടോക്കോൾ ആണ്. ഔദ്യോഗിക സ്പെസിഫിക്കേഷൻ RFC 768 [Postel 1980] മൂന്ന് പേജുകൾ മാത്രമാണ്. ഐപിക്ക് മുകളിലും പിന്നിലും ഉപയോക്തൃ പ്രോസസ്സുകൾക്ക് ഇത് നൽകുന്ന സേവനങ്ങൾ പോർട്ട് നമ്പറുകളും ഓപ്‌ഷണൽ ചെക്ക്‌സമ്മുകളുമാണ്. ചെക്ക്സം കണക്കുകൂട്ടലുകൾ അവലോകനം ചെയ്യുന്നതിനും വിഘടനം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണുന്നതിനും ഞങ്ങൾ UDP ഉപയോഗിച്ചു.

അടുത്തതായി ഞങ്ങൾ ICMP അൺറീച്ചബിൾ പിശക് പരിശോധിച്ചു, അത് പുതിയ ഗതാഗത MTU നിർണ്ണയിക്കൽ സവിശേഷതയുടെ ഭാഗമാണ് (അധ്യായം 2, വിഭാഗം കാണുക). Traceroute, UDP എന്നിവ ഉപയോഗിച്ച് ഗതാഗത MTU നിർണ്ണയിക്കുന്നത് ഞങ്ങൾ നോക്കി. യുഡിപിയും എആർപിയും തമ്മിലുള്ള ഇടപെടലിന്റെ പ്രക്രിയയും ചർച്ച ചെയ്യപ്പെടുന്നു.

പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ വേഗത്തിൽ IP ഡാറ്റാഗ്രാമുകൾ സ്വീകരിക്കുന്ന ഒരു സിസ്റ്റത്തിന് ഒരു ICMP സോഴ്‌സ് സപ്രഷൻ പിശക് അയയ്‌ക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ പരിശോധിച്ചുറപ്പിച്ചു. UDP ഉപയോഗിച്ച് ഈ ICMP പിശകുകൾ എളുപ്പത്തിൽ സൃഷ്ടിക്കാൻ സാധിക്കും.

വ്യായാമങ്ങൾ

1. ഈ അധ്യായത്തിന്റെ വിഭാഗത്തിൽ, 1473 ബൈറ്റുകളുടെ ഉപയോക്തൃ ഡാറ്റ വലുപ്പമുള്ള ഒരു UDP ഡാറ്റാഗ്രാം എഴുതി ഞങ്ങൾ ഇഥർനെറ്റിൽ വിഘടനത്തിന് കാരണമായി. IEEE 802 എൻക്യാപ്‌സുലേഷൻ ഉപയോഗിച്ചാൽ ഇഥർനെറ്റിൽ വിഘടനത്തിന് കാരണമാകുന്ന ഉപയോക്തൃ ഡാറ്റയുടെ ഏറ്റവും ചെറിയ വലിപ്പം എന്താണ് (അധ്യായം 2, വിഭാഗം)?
2. RFC 791 [Postel 1981a] വായിച്ച്, അവസാനത്തേത് ഒഴികെയുള്ള എല്ലാ ശകലങ്ങളും 8 ബൈറ്റുകളുടെ ദൈർഘ്യമുള്ള ഗുണിതങ്ങളായിരിക്കണം എന്തുകൊണ്ടെന്ന് എന്നോട് പറയുക.
3. ഉപയോക്തൃ ഡാറ്റയുടെ 8192 ബൈറ്റുകളുള്ള ഒരു ഇഥർനെറ്റും UDP ഡാറ്റാഗ്രാമും സങ്കൽപ്പിക്കുക. എത്ര ശകലങ്ങൾ കൈമാറും, ഓരോ ശകലത്തിന്റെയും ഓഫ്‌സെറ്റ് ദൈർഘ്യം എത്രയായിരിക്കും?
4. മുമ്പത്തെ ഉദാഹരണം തുടരുമ്പോൾ, ഈ ഡാറ്റാഗ്രാമുകൾ 552 MTU ഉള്ള ഒരു SLIP ചാനലിലേക്ക് മാറ്റുമെന്ന് സങ്കൽപ്പിക്കുക. ഓരോ ശകലത്തിലെയും ഡാറ്റയുടെ അളവ് (IP തലക്കെട്ട് ഒഴികെ എല്ലാം) 8 ബൈറ്റുകളുടെ ഗുണിതമായിരിക്കണം എന്ന് നിങ്ങൾ ഓർക്കേണ്ടതുണ്ട്. എത്ര ശകലങ്ങൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നു, ഓരോ ശകലത്തിന്റെയും ഓഫ്‌സെറ്റും നീളവും എത്രയാണ്?
5. UDP ഉപയോഗിക്കുന്ന ഒരു ആപ്ലിക്കേഷൻ 4 ഭാഗങ്ങളായി വിഭജിച്ച ഒരു ഡാറ്റാഗ്രാം അയയ്ക്കുന്നു. 3 ഉം 4 ഉം ശകലങ്ങൾ നഷ്ടപ്പെട്ടപ്പോൾ 1 ഉം 2 ഉം ലക്ഷ്യസ്ഥാനത്ത് എത്തിയെന്ന് സങ്കൽപ്പിക്കുക. ആപ്ലിക്കേഷൻ സമയം കഴിഞ്ഞു, 10 സെക്കൻഡിനു ശേഷം, UDP ഡാറ്റാഗ്രാം വീണ്ടും സംപ്രേക്ഷണം ചെയ്യുന്നു. ഈ ഡാറ്റാഗ്രാം ആദ്യത്തെ ട്രാൻസ്മിഷന്റെ അതേ രീതിയിൽ തന്നെ വിഘടിച്ചിരിക്കുന്നു (ഒരേ ഓഫ്സെറ്റും അതേ നീളവും). ഇപ്പോൾ 1 ഉം 2 ഉം ശകലങ്ങൾ നഷ്ടപ്പെട്ടതായി സങ്കൽപ്പിക്കുക, എന്നാൽ 3 ഉം 4 ഉം ശകലങ്ങൾ ലക്ഷ്യസ്ഥാനത്ത് എത്തുന്നു. റിസീവിംഗ് ഹോസ്റ്റിലെ റീഅസെംബ്ലി ടൈമർ 60 സെക്കൻഡായി സജ്ജീകരിച്ചിരിക്കുന്നു, അതിനാൽ 3 ഉം 4 ഉം ശകലങ്ങൾ അന്തിമ ലക്ഷ്യസ്ഥാനത്ത് എത്തിയപ്പോൾ, ആദ്യ സംപ്രേഷണത്തിൽ നിന്നുള്ള 1 ഉം 2 ഉം ശകലങ്ങൾ ഇതുവരെ നിരസിച്ചിട്ടില്ല. സ്വീകർത്താവിന് ഈ നാല് ശകലങ്ങളിൽ നിന്ന് ഒരു ഐപി ഡാറ്റാഗ്രാം കൂട്ടിച്ചേർക്കാനാകുമോ?
6. ചിത്രം 11.15 ലെ ശകലങ്ങൾ യഥാർത്ഥത്തിൽ ചിത്രം 11.14 ലെ 5, 6 വരികളുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് നിങ്ങൾക്ക് എങ്ങനെ അറിയാനാകും?
), ഹാർഡ് ആൻഡ് ലൂസ് സോഴ്സ് റൂട്ടിംഗ് (അധ്യായം 8, വിഭാഗം). വിഘടന സമയത്ത് ഈ ഓപ്ഷനുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുമെന്ന് നിങ്ങൾ കരുതുന്നു? നിങ്ങളുടെ ഉത്തരം RFC 791-മായി താരതമ്യം ചെയ്യുക.
7. ഇൻകമിംഗ് ഐപി ഡാറ്റാഗ്രാമുകൾ ഡെസ്റ്റിനേഷൻ യുഡിപി പോർട്ട് നമ്പറിനെ അടിസ്ഥാനമാക്കി ഡീമൾട്ടിപ്ലെക്‌സ് ചെയ്യപ്പെടുമെന്ന് ഞങ്ങൾ പറഞ്ഞു. അതു ശരിയാണോ?

ഡാറ്റയുടെ വിശ്വാസ്യത, ക്രമപ്പെടുത്തൽ, അല്ലെങ്കിൽ സമഗ്രത എന്നിവ ഉറപ്പാക്കാൻ പരോക്ഷമായ ഹാൻഡ്‌ഷേക്കുകളൊന്നുമില്ലാതെ, ലളിതമായ ഒരു ട്രാൻസ്മിഷൻ മോഡൽ UDP ഉപയോഗിക്കുന്നു. അങ്ങനെ, UDP ഒരു വിശ്വസനീയമല്ലാത്ത സേവനം നൽകുന്നു, കൂടാതെ ഡാറ്റാഗ്രാമുകൾ ക്രമം തെറ്റിയേക്കാം, തനിപ്പകർപ്പാക്കാം അല്ലെങ്കിൽ ഒരു തുമ്പും കൂടാതെ അപ്രത്യക്ഷമാകാം. പിശക് പരിശോധനയും തിരുത്തലും ഒന്നുകിൽ ആവശ്യമില്ല അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ നടപ്പിലാക്കണം എന്ന് UDP സൂചിപ്പിക്കുന്നു. ടൈം-സെൻസിറ്റീവ് ആപ്ലിക്കേഷനുകൾ പലപ്പോഴും UDP ഉപയോഗിക്കുന്നു, കാരണം പാക്കറ്റുകൾ വൈകുന്നതിനെക്കാൾ പാക്കറ്റുകൾ ഡ്രോപ്പ് ചെയ്യുന്നതാണ് നല്ലത്, ഇത് തത്സമയ സിസ്റ്റങ്ങളിൽ സാധ്യമാകില്ല. നെറ്റ്‌വർക്ക് ഇന്റർഫേസ് ലെയറിലെ പിശകുകൾ തിരുത്തേണ്ടത് ആവശ്യമാണെങ്കിൽ, ഈ ആവശ്യത്തിനായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന TCP അല്ലെങ്കിൽ SCTP അപ്ലിക്കേഷന് ഉപയോഗിക്കാം.

ഒരു സ്‌റ്റേറ്റ്‌ലെസ് പ്രോട്ടോക്കോൾ എന്ന നിലയിൽ യുഡിപിയുടെ സ്വഭാവം, ഡിഎൻഎസ്, ഐപിടിവി, വോയ്‌സ് ഓവർ ഐപി, ഐപി ടണലിംഗ് പ്രോട്ടോക്കോളുകൾ, കൂടാതെ നിരവധി ഓൺലൈൻ ഗെയിമുകൾ പോലുള്ള സ്‌ട്രീമിംഗ് മീഡിയ ആപ്ലിക്കേഷനുകളായ നിരവധി ക്ലയന്റുകളിൽ നിന്നുള്ള ചെറിയ അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുന്ന സെർവറുകൾക്കും ഉപയോഗപ്രദമാണ്.

സേവന തുറമുഖങ്ങൾ

UDP അപ്പർ-ലെയർ പ്രോട്ടോക്കോളിലേക്ക് സന്ദേശ ഡെലിവറി ഗ്യാരണ്ടികളൊന്നും നൽകുന്നില്ല, അയച്ച സന്ദേശങ്ങളുടെ അവസ്ഥ സംഭരിക്കുന്നില്ല. ഇക്കാരണത്താൽ, യുഡിപിയെ ചിലപ്പോൾ വിശ്വസനീയമല്ലാത്ത ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ എന്ന് വിളിക്കുന്നു.

ചെക്ക്‌സം കണക്കാക്കുന്നതിന് മുമ്പ്, UDP സന്ദേശം അവസാനം പൂജ്യം ബിറ്റുകൾ ഉപയോഗിച്ച് 16 ബിറ്റുകളുടെ ഗുണിത നീളത്തിലേക്ക് പാഡ് ചെയ്യുന്നു (സ്യൂഡോ-ഹെഡറും അധിക സീറോ ബിറ്റുകളും സന്ദേശത്തിനൊപ്പം അയയ്‌ക്കില്ല). ചെക്ക്സം കണക്കുകൂട്ടൽ സമയത്ത് UDP തലക്കെട്ടിലെ ചെക്ക്സം ഫീൽഡ് അയച്ചുസന്ദേശങ്ങൾ അസാധുവായി സ്വീകരിക്കുന്നു.

ചെക്ക്സം കണക്കാക്കാൻ, കപട തലക്കെട്ടും UDP സന്ദേശവും വാക്കുകളായി വിഭജിക്കുന്നു (1 വാക്ക് = 2 ബൈറ്റുകൾ (ഒക്ടറ്റുകൾ) = 16 ബിറ്റുകൾ). അപ്പോൾ ബിറ്റ്‌വൈസ് പൂരകത്തോടുകൂടിയ എല്ലാ പദങ്ങളുടെയും ആകെത്തുകയുടെ ബിറ്റ്‌വൈസ് കോംപ്ലിമെന്റ് കണക്കാക്കുന്നു. ഫലം യു‌ഡി‌പി ഹെഡറിലെ അനുബന്ധ ഫീൽഡിലേക്ക് എഴുതിയിരിക്കുന്നു.

പൂജ്യത്തിന്റെ ഒരു ചെക്ക്സം മൂല്യം കരുതിവച്ചിരിക്കുന്നു, ഡാറ്റാഗ്രാമിന് ഒരു ചെക്ക്സം ഇല്ല എന്നാണ് അർത്ഥമാക്കുന്നത്. കണക്കാക്കിയ ചെക്ക്സം പൂജ്യത്തിന് തുല്യമാണെങ്കിൽ, ഫീൽഡ് ബൈനറി യൂണിറ്റുകൾ കൊണ്ട് നിറഞ്ഞിരിക്കുന്നു.

ഒരു സന്ദേശം ലഭിക്കുമ്പോൾ, സ്വീകർത്താവ് ചെക്ക്സം വീണ്ടും കണക്കാക്കുന്നു (ചെക്ക്സം ഫീൽഡ് കണക്കിലെടുത്ത്), ഫലം പതിനാറ് ഒന്നിന്റെ (അതായത്, 0xffff) ബൈനറി സംഖ്യയാണെങ്കിൽ, ചെക്ക്സം ഒത്തുചേർന്നതായി കണക്കാക്കുന്നു. തുക ചേർത്തില്ലെങ്കിൽ (പ്രക്ഷേപണ സമയത്ത് ഡാറ്റ കേടായി), ഡാറ്റാഗ്രാം നശിപ്പിക്കപ്പെടും.

ചെക്ക്സം കണക്കുകൂട്ടൽ ഉദാഹരണം

ഉദാഹരണത്തിന്, നമുക്ക് നിരവധി 16-ബിറ്റ് വാക്കുകളുടെ ചെക്ക്സം കണക്കാക്കാം: 0x398a, 0xf802, 0x14b2, 0xc281. ബിറ്റ്വൈസ് കോംപ്ലിമെന്റ് ഉപയോഗിച്ച് അവയുടെ തുക കണ്ടെത്തുക.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
തത്ഫലമായുണ്ടാകുന്ന ഫലത്തിന്റെ ബിറ്റ്വൈസ് കോംപ്ലിമെന്റ് ഞങ്ങൾ ഇപ്പോൾ കണ്ടെത്തുന്നു:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e അല്ലെങ്കിൽ, അല്ലെങ്കിൽ - 0xffff − 0x08c1 = 0xf73e . ഇതാണ് ആവശ്യമുള്ള ചെക്ക്സം.

ചെക്ക്സം കണക്കാക്കുമ്പോൾ, ഒരു യഥാർത്ഥ IPv6 തലക്കെട്ട് അനുകരിക്കുന്ന ഒരു വ്യാജ തലക്കെട്ട് വീണ്ടും ഉപയോഗിക്കുന്നു:

ബിറ്റുകൾ	0 – 7								8 – 15								16 – 23								24 – 31
0	ഉറവിട വിലാസം
32
64
96
128	സ്വീകർത്താവിന്റെ വിലാസം
160
192
224
256	UDP ദൈർഘ്യം
288	പൂജ്യങ്ങൾ																								അടുത്ത തലക്കെട്ട്
320	ഉറവിട തുറമുഖം																ലക്ഷ്യസ്ഥാന തുറമുഖം
352	നീളം																തുക പരിശോധിക്കുക
384+	ഡാറ്റ

ഉറവിട വിലാസം IPv6 തലക്കെട്ടിലുള്ളത് തന്നെയാണ്. സ്വീകർത്താവിന്റെ വിലാസം - അന്തിമ സ്വീകർത്താവ്; IPv6 പാക്കറ്റിൽ ഒരു റൂട്ടിംഗ് ഹെഡർ ഇല്ലെങ്കിൽ, ഇത് IPv6 തലക്കെട്ടിൽ നിന്നുള്ള ലക്ഷ്യസ്ഥാന വിലാസമായിരിക്കും, അല്ലാത്തപക്ഷം, ആരംഭ നോഡിൽ, ഇത് റൂട്ടിംഗ് ഹെഡറിന്റെ അവസാന ഘടകത്തിന്റെ വിലാസവും സ്വീകരിക്കുന്ന നോഡിലും ആയിരിക്കും, IPv6- തലക്കെട്ടിൽ നിന്നുള്ള ലക്ഷ്യസ്ഥാന വിലാസം. അടുത്ത തലക്കെട്ട് മൂല്യം പ്രോട്ടോക്കോൾ മൂല്യത്തിന് തുല്യമാണ് - UDP-യുടെ 17. UDP ദൈർഘ്യം - UDP തലക്കെട്ടിന്റെയും ഡാറ്റയുടെയും ദൈർഘ്യം.

വിശ്വാസ്യതയും ഓവർലോഡ് പ്രശ്നങ്ങൾക്കുള്ള പരിഹാരങ്ങളും

വിശ്വാസ്യത കുറവായതിനാൽ, UDP ആപ്ലിക്കേഷനുകൾ ചില നഷ്ടങ്ങൾ, പിശകുകൾ, ഡ്യൂപ്ലിക്കേഷൻ എന്നിവയ്ക്കായി തയ്യാറാക്കേണ്ടതുണ്ട്. അവയിൽ ചിലത് (ഉദാഹരണത്തിന്, TFTP) ആപ്ലിക്കേഷൻ തലത്തിൽ പ്രാഥമിക വിശ്വാസ്യത മെക്കാനിസങ്ങൾ ഓപ്ഷണലായി ചേർക്കാൻ കഴിയും.

എന്നാൽ മിക്കപ്പോഴും, അത്തരം മെക്കാനിസങ്ങൾ UDP ആപ്ലിക്കേഷനുകൾ ഉപയോഗിക്കുന്നില്ല, മാത്രമല്ല അവയിൽ ഇടപെടുകയും ചെയ്യുന്നു. സ്ട്രീമിംഗ് മീഡിയ, തത്സമയ മൾട്ടിപ്ലെയർ ഗെയിമിംഗ്, VoIP എന്നിവ പലപ്പോഴും UDP പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകളുടെ ഉദാഹരണങ്ങളാണ്. ഈ പ്രത്യേക ആപ്ലിക്കേഷനുകളിൽ, പാക്കറ്റ് നഷ്ടം സാധാരണയായി ഒരു വലിയ പ്രശ്നമല്ല. ആപ്ലിക്കേഷന് ഉയർന്ന നിലവാരത്തിലുള്ള വിശ്വാസ്യത ആവശ്യമാണെങ്കിൽ, മറ്റൊരു പ്രോട്ടോക്കോൾ (TCP) അല്ലെങ്കിൽ മായ്ക്കൽ കോഡുകൾ ഉപയോഗിക്കാം.

ടിസിപിയിൽ നിന്ന് വ്യത്യസ്തമായി, യുഡിപി അടിസ്ഥാനമാക്കിയുള്ള ആപ്ലിക്കേഷനുകൾക്ക് നല്ല തിരക്ക് നിയന്ത്രണവും ഒഴിവാക്കൽ സംവിധാനങ്ങളും ഉണ്ടായിരിക്കണമെന്നില്ല എന്നതാണ് ഒരു വലിയ പ്രശ്നം. ലഭ്യമായ ബാൻഡ്‌വിഡ്‌ത്തിന്റെ ഗണ്യമായ ഭാഗം ഉപയോഗിക്കുന്ന കൺജഷൻ-സെൻസിറ്റീവ് യുഡിപി ആപ്ലിക്കേഷനുകൾക്ക് ഇന്റർനെറ്റ് സ്ഥിരതയിൽ വിട്ടുവീഴ്ച ചെയ്യാനാകും.

അനിയന്ത്രിതമായ, ഉയർന്ന വേഗതയുള്ള ലോഡുകൾക്കിടയിലുള്ള തിരക്കിന്റെ സാധ്യതകൾ കുറയ്ക്കുന്നതിനാണ് നെറ്റ്‌വർക്ക് മെക്കാനിസങ്ങൾ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. പാക്കറ്റ് ക്യൂകളും ഡ്രോപ്പ് ടെക്നിക്കുകളും ഉപയോഗിക്കുന്ന റൂട്ടറുകൾ പോലുള്ള നെറ്റ്‌വർക്ക് ഘടകങ്ങൾ പലപ്പോഴും അമിതമായ യുഡിപി ട്രാഫിക്കിനെ മന്ദഗതിയിലാക്കാൻ ലഭ്യമായ ഒരേയൊരു ടൂളാണ്. സ്ട്രീമിംഗ് മീഡിയ പോലുള്ള ഉയർന്ന വേഗതയുള്ള UDP സ്ട്രീമുകൾക്കായുള്ള തിരക്ക് നിരീക്ഷിക്കാൻ എൻഡ് ഹോസ്റ്റിലേക്ക് മെക്കാനിസങ്ങൾ ചേർത്ത് ഈ സാധ്യതയുള്ള പ്രശ്നത്തിനുള്ള ഭാഗിക പരിഹാരമായാണ് DCCP (ഡാറ്റാഗ്രാം കൺജഷൻ കൺട്രോൾ പ്രോട്ടോക്കോൾ) രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

അപേക്ഷകൾ

ഡിഎൻഎസ് (അഭ്യർത്ഥനകൾ വേഗമേറിയതും ഒരു അഭ്യർത്ഥനയെ തുടർന്ന് ഒരൊറ്റ പ്രതികരണ പാക്കറ്റും ഉണ്ടായിരിക്കണം), സിമ്പിൾ നെറ്റ്‌വർക്ക് മാനേജ്മെന്റ് പ്രോട്ടോക്കോൾ (എസ്എൻഎംപി), റൂട്ടിംഗ് ഇൻഫർമേഷൻ പ്രോട്ടോക്കോൾ (ആർഐപി), ഡൈനാമിക് ഹോസ്റ്റ് കോൺഫിഗറേഷൻ (ഡിഎച്ച്സിപി) ഉൾപ്പെടെ നിരവധി പ്രധാന ഇന്റർനെറ്റ് ആപ്ലിക്കേഷനുകൾ യുഡിപി ഉപയോഗിക്കുന്നു. .

വോയ്‌സ്, വീഡിയോ ട്രാഫിക്ക് സാധാരണയായി UDP ഉപയോഗിച്ചാണ് കൊണ്ടുപോകുന്നത്. തത്സമയ വീഡിയോ, ഓഡിയോ സ്ട്രീമിംഗ് പ്രോട്ടോക്കോളുകൾ ക്രമരഹിതമായ പാക്കറ്റ് നഷ്ടങ്ങൾ കൈകാര്യം ചെയ്യാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നതിനാൽ നഷ്ടപ്പെട്ട പാക്കറ്റുകൾ വീണ്ടും സംപ്രേക്ഷണം ചെയ്യുമ്പോൾ വലിയ കാലതാമസം അനുഭവപ്പെടുന്നതിന് പകരം ഗുണനിലവാരം ചെറുതായി കുറയുന്നു. ടിസിപിയും യുഡിപിയും ഒരേ നെറ്റ്‌വർക്കിൽ പ്രവർത്തിക്കുന്നതിനാൽ, ഈ തത്സമയ ആപ്ലിക്കേഷനുകളിൽ നിന്നുള്ള യുഡിപി ട്രാഫിക്കിലെ സമീപകാല വർദ്ധനവ് ഡാറ്റാബേസ് അല്ലെങ്കിൽ അക്കൗണ്ടിംഗ് സിസ്റ്റങ്ങൾ പോലുള്ള ടിസിപി ആപ്ലിക്കേഷനുകളുടെ പ്രകടനത്തെ തടസ്സപ്പെടുത്തുന്നതായി പല കമ്പനികളും ശ്രദ്ധിച്ചിട്ടുണ്ട്. ബിസിനസ്സും തത്സമയ ആപ്ലിക്കേഷനുകളും കമ്പനികൾക്ക് പ്രധാനമായതിനാൽ, പ്രശ്‌നങ്ങൾക്ക് ഗുണനിലവാരമുള്ള പരിഹാരങ്ങൾ വികസിപ്പിക്കുന്നത് ചിലർ മുൻ‌ഗണനയായി കാണുന്നു.

UDP, TCP എന്നിവയുടെ താരതമ്യം

TCP ഒരു കണക്ഷൻ-ഓറിയന്റഡ് പ്രോട്ടോക്കോൾ ആണ്, അതായത് രണ്ട് ഹോസ്റ്റുകൾക്കിടയിൽ ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നതിന് ഒരു "ഹാൻഡ്ഷേക്ക്" ആവശ്യമാണ്. കണക്ഷൻ സ്ഥാപിച്ചുകഴിഞ്ഞാൽ, ഉപയോക്താക്കൾക്ക് രണ്ട് ദിശകളിലേക്കും ഡാറ്റ അയയ്ക്കാൻ കഴിയും.

• വിശ്വാസ്യത- TCP സന്ദേശങ്ങൾ സ്വീകരിക്കൽ, പുനഃസംപ്രേക്ഷണം, സമയപരിധി എന്നിവ കൈകാര്യം ചെയ്യുന്നു. സന്ദേശം കൈമാറാൻ നിരവധി ശ്രമങ്ങൾ നടക്കുന്നുണ്ട്. വഴിയിൽ ഇത് നഷ്ടപ്പെട്ടാൽ, സെർവർ നഷ്ടപ്പെട്ട ഭാഗം വീണ്ടും അഭ്യർത്ഥിക്കും. ടിസിപിയിൽ ഡാറ്റ നഷ്‌ടപ്പെടുകയോ (ഒന്നിലധികം ടൈംഔട്ടുകളുടെ കാര്യത്തിൽ) തകർന്ന കണക്ഷനുകളോ ഇല്ല.

• ചിട്ട- രണ്ട് സന്ദേശങ്ങൾ തുടർച്ചയായി അയച്ചാൽ, ആദ്യ സന്ദേശം ആദ്യം സ്വീകർത്താവിന്റെ അപേക്ഷയിൽ എത്തും. ഡാറ്റയുടെ ഭാഗങ്ങൾ തെറ്റായ ക്രമത്തിലാണ് വരുന്നതെങ്കിൽ, എല്ലാ ഡാറ്റയും ഓർഡർ ചെയ്ത് ആപ്ലിക്കേഷനിലേക്ക് അയയ്‌ക്കുന്നതുവരെ TCP ഔട്ട്-ഓഫ്-ഓർഡർ ഡാറ്റ ഒരു ബഫറിലേക്ക് അയയ്ക്കുന്നു.

• ഭാരം- ഡാറ്റ അയയ്‌ക്കുന്നതിന് മുമ്പ് ഒരു സോക്കറ്റ് കണക്ഷൻ സ്ഥാപിക്കാൻ ടിസിപിക്ക് മൂന്ന് പാക്കറ്റുകൾ ആവശ്യമാണ്. TCP വിശ്വാസ്യതയും തിരക്കും നിരീക്ഷിക്കുന്നു.

• ത്രെഡിംഗ്- ഡാറ്റ ബൈറ്റുകളുടെ ഒരു സ്ട്രീം ആയി വായിക്കുന്നു, സന്ദേശ അതിരുകൾക്കോ ​​സെഗ്‌മെന്റുകൾക്കോ ​​പ്രത്യേക പദവികളൊന്നും കൈമാറില്ല.

യു‌ഡി‌പി ലളിതവും സന്ദേശ അധിഷ്‌ഠിതവും കണക്ഷനില്ലാത്തതുമായ ഒരു പ്രോട്ടോക്കോൾ ആണ്. ഇത്തരത്തിലുള്ള പ്രോട്ടോക്കോളുകൾ രണ്ട് ഹോസ്റ്റുകൾക്കിടയിൽ ഒരു സമർപ്പിത ബന്ധം സ്ഥാപിക്കുന്നില്ല. സ്വീകർത്താവിന്റെ സന്നദ്ധതയോ അവസ്ഥയോ പരിശോധിക്കാതെ ഒരു ഉറവിടത്തിൽ നിന്ന് ഒരു സ്വീകർത്താവിലേക്ക് വിവരങ്ങൾ ഒരു ദിശയിലേക്ക് കൈമാറുന്നതിലൂടെ ആശയവിനിമയം കൈവരിക്കാനാകും. എന്നിരുന്നാലും, ടിസിപിയെക്കാൾ യുഡിപിയുടെ പ്രധാന നേട്ടം വോയ്‌സ് ഓവർ ഇൻറർനെറ്റ് പ്രോട്ടോക്കോൾ (VoIP) ആപ്ലിക്കേഷനുകളിലാണ്, അവിടെ ഏത് ഹാൻഡ്‌ഷെക്കും നല്ല ശബ്ദ ആശയവിനിമയത്തെ തടയും. VoIP-ൽ, അന്തിമ ഉപയോക്താക്കൾ തത്സമയം സന്ദേശ രസീതിന്റെ ഏതെങ്കിലും ആവശ്യമായ അംഗീകാരം നൽകുമെന്ന് പ്രതീക്ഷിക്കുന്നു.

• വിശ്വസനീയമല്ല- ഒരു സന്ദേശം അയയ്‌ക്കുമ്പോൾ, അത് ലക്ഷ്യസ്ഥാനത്ത് എത്തുമോ എന്ന് അറിയില്ല - അത് വഴിയിൽ നഷ്ടപ്പെട്ടേക്കാം. സ്ഥിരീകരണം, പുനഃസംപ്രേക്ഷണം, കാലഹരണപ്പെടൽ തുടങ്ങിയ ആശയങ്ങളൊന്നുമില്ല.

• ക്രമക്കേട്- ഒരേ സ്വീകർത്താവിന് രണ്ട് സന്ദേശങ്ങൾ അയച്ചാൽ, അവർ ലക്ഷ്യം കൈവരിക്കുന്ന ക്രമം പ്രവചിക്കാൻ കഴിയില്ല.

• ലഘുത്വം- സന്ദേശങ്ങളുടെ ക്രമം, കണക്ഷനുകളുടെ ട്രാക്കിംഗ് തുടങ്ങിയവയില്ല. ഇത് ഐപിയിൽ രൂപകൽപ്പന ചെയ്ത ഒരു ചെറിയ ട്രാൻസ്പോർട്ട് ലെയറാണ്.

• ഡാറ്റാഗ്രാമുകൾ- പാക്കറ്റുകൾ വ്യക്തിഗതമായി അയയ്‌ക്കുകയും അവ വന്നാൽ മാത്രമേ സമഗ്രത പരിശോധിക്കുകയും ചെയ്യും. പാക്കറ്റുകൾക്ക് ചില അതിരുകൾ ഉണ്ട്, അത് ഒരിക്കൽ സ്വീകരിച്ചുകഴിഞ്ഞാൽ, അത് സ്വീകരിക്കുന്ന സോക്കറ്റിലെ ഒരു റീഡ് ഓപ്പറേഷൻ സന്ദേശം യഥാർത്ഥത്തിൽ അയച്ചതുപോലെ തന്നെ സൃഷ്ടിക്കും.

• ഓവർലോഡ് നിയന്ത്രണമില്ല- UDP തന്നെ തിരക്ക് ഒഴിവാക്കുന്നില്ല. ഉയർന്ന ബാൻഡ്‌വിഡ്ത്ത് ആപ്ലിക്കേഷനുകൾ ആപ്ലിക്കേഷൻ-ലെവൽ നിയന്ത്രണങ്ങൾ നടപ്പിലാക്കുന്നില്ലെങ്കിൽ തിരക്ക് കുറയാൻ സാധ്യതയുണ്ട്.

RFC ലിങ്കുകൾ

• RFC 768 - ഉപയോക്തൃ ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ
• RFC 2460 – ഇന്റർനെറ്റ് പ്രോട്ടോക്കോൾ സ്പെസിഫിക്കേഷൻ പതിപ്പ് 6 (IPv6)
• RFC 2675 - IPv6 ജംബോഗ്രാമുകൾ
• RFC 4113 - UDP-യുടെ മാനേജ്മെന്റ് ഇൻഫർമേഷൻ ബേസ്
• RFC 5405 - ആപ്ലിക്കേഷൻ ഡിസൈനർമാർക്കുള്ള യൂണികാസ്റ്റ് UDP ഉപയോഗ മാർഗ്ഗനിർദ്ദേശങ്ങൾ

ഇതും കാണുക

ലിങ്കുകൾ

• കുറോസ്, ജെ.എഫ്. റോസ്, കെ.ഡബ്ല്യു. (2010). കമ്പ്യൂട്ടർ നെറ്റ്‌വർക്കിംഗ്: ഒരു ടോപ്പ്-ഡൗൺ അപ്രോച്ച് (5-ആം പതിപ്പ്). ബോസ്റ്റൺ, എംഎ: പിയേഴ്സൺ എഡ്യൂക്കേഷൻ. ISBN 978-0-13-136548-3.
• ഫൊറൂസാൻ, ബി.എ. (2000). TCP/IP: പ്രോട്ടോക്കോൾ സ്യൂട്ട്, 1st ed. ന്യൂഡൽഹി, ഇന്ത്യ: ടാറ്റ മക്‌ഗ്രോ-ഹിൽ പബ്ലിഷിംഗ് കമ്പനി ലിമിറ്റഡ്.
• [ഇമെയിൽ പരിരക്ഷിതം]. "UDP പ്രോട്ടോക്കോൾ അവലോകനം". IPv6.com. ശേഖരിച്ചത് ഓഗസ്റ്റ് 17, 2011
• ക്ലാർക്ക്, എം.പി. (2003). ഡാറ്റ നെറ്റ്‌വർക്കുകൾ ഐപിയും ഇന്റർനെറ്റും, ഒന്നാം പതിപ്പ്. വെസ്റ്റ് സസെക്സ്, ഇംഗ്ലണ്ട്: ജോൺ വൈലി ആൻഡ് സൺസ് ലിമിറ്റഡ്.
• പോസ്റ്റൽ, ജെ. (ഓഗസ്റ്റ് 1980). RFC 768: ഉപയോക്തൃ ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ. ഇന്റർനെറ്റ് എഞ്ചിനീയറിംഗ് ടാസ്ക് ഫോഴ്സ്. http://tools.ietf.org/html/rfc768-ൽ നിന്ന് വീണ്ടെടുത്തു
• ഡീറിംഗ് എസ്. & ഹിൻഡൻ ആർ. (ഡിസംബർ 1998). RFC 2460: ഇന്റർനെറ്റ് പ്രോട്ടോക്കോൾ, പതിപ്പ് 6 (IPv6) സ്പെസിഫിക്കേഷൻ. ഇന്റർനെറ്റ് എഞ്ചിനീയറിംഗ് ടാസ്ക് ഫോഴ്സ്. http://tools.ietf.org/html/rfc2460 ൽ നിന്ന് വീണ്ടെടുത്തു
• "ഡാറ്റ ആപ്ലിക്കേഷനുകളിൽ UDP യുടെ സ്വാധീനം". networkperformancedaily.com. ശേഖരിച്ചത് ഓഗസ്റ്റ് 17, 2011
• ഡി. കോമർ. TCP/IP ഉപയോഗിച്ച് ഇന്റർനെറ്റ് വർക്കിംഗ്. അധ്യായം 11. UDP പ്രോട്ടോക്കോൾ.

OSI മോഡലിന്റെ ലെവലുകൾ അനുസരിച്ച് അടിസ്ഥാന TCP/IP പ്രോട്ടോക്കോളുകൾ (TCP, UDP പോർട്ടുകളുടെ പട്ടിക)
ശാരീരികം
നാളി