OpenVPN TCP-യിൽ: rto_min ക്യൂവിന്റെ തലയിലെ തടയൽ പരിഹരിക്കുന്നില്ല

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

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

രോഗലക്ഷണം: എല്ലാം ഒരേ സമയം നിൽക്കുന്നു

രണ്ട് ഉൾ കണക്ഷനുകൾ ഒരുമിച്ച് കുടുങ്ങുന്നതാണ് സൂചന. വേഗം കുറഞ്ഞ ഡൗൺലോഡും വേഗം കുറഞ്ഞ ഷെല്ലും വെവ്വേറെ സീക്വൻസ് നമ്പറുകളും വെവ്വേറെ തിരക്ക് അവസ്ഥയും ഉള്ള വെവ്വേറെ TCP സംഭാഷണങ്ങളാണ്, അതിനാൽ ഒന്നിലെ തകരാർ മറ്റൊന്നിനെ തൊടരുത്. അവ ഒരേ താളത്തിൽ നിൽക്കുമ്പോൾ, അവയുടെ മുകളിൽ എന്തോ അവയുടെ ബൈറ്റുകൾ ക്രമീകരിക്കുന്നു.

ആ എന്തോ ടണലിന്റെ ഗതാഗത പാളിയാണ്. TCP മോഡിൽ, OpenVPN പൊതിഞ്ഞ പാക്കറ്റുകൾ ഒരൊറ്റ TCP കണക്ഷനിൽ പിയറിലേക്ക് എഴുതുന്നു, TCP-യുടെ കരാർ ഒരൊറ്റ ബൈറ്റ് സ്ട്രീം ക്രമത്തിൽ എത്തിക്കുകയാണ്. പിന്നീടുള്ള ബൈറ്റുകൾ നഷ്ടമായവയ്ക്ക് മുൻപ് അപ്ലിക്കേഷന് നൽകുന്നില്ല, അവ ഏത് ഉൾ സംഭാഷണത്തിൽപ്പെട്ടതായാലും.

രോഗലക്ഷണം എന്ത് പറയുന്നില്ല എന്ന് ശ്രദ്ധിക്കുക. പാത തകർന്നിരിക്കുന്നു, സെർവർ അധിക ഭാരത്തിലാണ്, അല്ലെങ്കിൽ എൻക്രിപ്ഷൻ മന്ദഗതിയിലാണ് എന്ന് അത് പറയുന്നില്ല. അവ മറ്റ് രൂപങ്ങൾ സൃഷ്ടിക്കുന്നു: സമാനമായ കുറഞ്ഞ ത്രൂപുട്ട്, സമയപരിധികൾ, അല്ലെങ്കിൽ ഒരു ദിശയെ മാത്രം ബാധിക്കുന്ന പരാജയങ്ങൾ. നഷ്ടമായ സെഗ്മെന്റ് വീണ്ടും അയക്കുമ്പോൾ അവസാനിക്കുന്ന പങ്കിട്ട ഇടവേള കൃത്യമായി ഒരു ക്രമ പ്രഭാവമാണ്.

ഒരു പുറം ബൈറ്റ് സ്ട്രീം, പല ഉൾ സംഭാഷണങ്ങൾ

ടണൽ ഒരേ സമയം ഒരു ഡൗൺലോഡും ഒരു ഷെല്ലും വഹിക്കുന്നതായി സങ്കൽപ്പിക്കുക. പുറം കണക്ഷന്റെ ഒരു സെഗ്മെന്റ് നഷ്ടമാകുന്നു. അടുത്ത സെഗ്മെന്റുകൾ സ്വീകരിക്കുന്ന ഹോസ്റ്റിൽ എത്താം, സ്വീകരിക്കുന്ന TCP സ്റ്റാക്ക് അവ സ്ഥിരീകരിക്കും, പക്ഷേ വിടവ് നിറയുന്നതുവരെ അവ മുകളിലേക്ക് നൽകാൻ കഴിയില്ല. അതിനാൽ OpenVPN-ന് ഷെല്ലിനായി വായിക്കാൻ ഒന്നുമില്ല, ഷെല്ലിന്റെ സ്വന്തം ബൈറ്റുകൾ വളരെ മുൻപേ എത്തിയിരുന്നെങ്കിലും.

ഇത് ഒരു കണക്ഷനുള്ളിൽ ക്യൂവിന്റെ തലയിലെ തടയലാണ്, രണ്ട് അപ്ലിക്കേഷനുകളും ഒരു ഉൾ കണക്ഷൻ പങ്കിടണമെന്ന് അത് ആവശ്യപ്പെടുന്നില്ല. അവ പുറം കണക്ഷൻ പങ്കിടുന്നു, അത് മതി.

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

ഇവയൊന്നും തകർച്ചയ്ക്ക് ഉറപ്പ് നൽകുന്നില്ല. ചെറിയ റൗണ്ട് ട്രിപ്പുകളും വിശാലമായ ക്യൂകളും ഉള്ള വൃത്തിയുള്ള പാതയിൽ ഈ ക്രമീകരണം വർഷങ്ങളോളം പൂർണ്ണമായി ഉപയോഗയോഗ്യമായിരിക്കാം. നഷ്ടം, കാലതാമസം, ക്യൂ ആഴം എന്നിവ ഒരുമിച്ച് വരുമ്പോൾ പരാജയം പ്രത്യക്ഷപ്പെടുന്നു, അതുകൊണ്ടാണ് റിപ്പോർട്ടുകൾ നന്നായി സജ്ജീകരിച്ച ഓഫീസുകൾക്ക് ചുറ്റുമല്ല, തിരക്കേറിയ അപ്ലിങ്കുകൾക്കും മൊബൈൽ ലിങ്കുകൾക്കും ചുറ്റും കൂടുന്നത്.

നീളമുള്ള ഉൾ ടൈമർ എന്തുകൊണ്ട് സഹായിക്കാൻ കഴിയില്ല

ഒരു പാതയിൽ rto_min ഉപയോഗിച്ച് കുറഞ്ഞ പുനർസംപ്രേഷണ സമയപരിധി ഉയർത്തുന്നത്, ആ പാത ഉപയോഗിക്കുന്ന പ്രാദേശികമായി ഉണ്ടാകുന്ന TCP ട്രാഫിക്കിനുള്ള ടൈമർ അധിഷ്ഠിത പുനർസംപ്രേഷണം വൈകിപ്പിക്കുന്നു. ഇത് യഥാർത്ഥ ഫലമുള്ള യഥാർത്ഥ നോബ് ആണ്, ഒന്നാം ക്രമ പ്രശ്നത്തിന് പകരം രണ്ടാം ക്രമ പ്രശ്നം കൈകാര്യം ചെയ്യുന്നു.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

അത് ചെയ്യാൻ കഴിയാത്തത്: പുറം ബൈറ്റുകൾ ക്രമത്തിന് പുറത്ത് വിടുക, നഷ്ടമായ സെഗ്മെന്റ് വേഗത്തിൽ വീണ്ടെടുക്കുക, അല്ലെങ്കിൽ ദൂര സെർവറിനെ അതേ ടൈമർ സ്വീകരിക്കാൻ പ്രേരിപ്പിക്കുക. സ്വീകരിക്കുന്ന സ്റ്റാക്ക് ഇപ്പോഴും ക്രമത്തിൽ നൽകുന്നു, ദൂര അറ്റത്തെ അയക്കുന്നയാൾ ഇപ്പോഴും സ്വന്തം റൗണ്ട് ട്രിപ്പ് അളവുകൾ ഉപയോഗിക്കുന്നു.

ഇത് മറ്റെല്ലാ നഷ്ട വീണ്ടെടുക്കൽ സംവിധാനങ്ങളും ഓഫ് ചെയ്യുന്നില്ല. യഥാർത്ഥ നഷ്ടത്തിന് ടൈമർ അധിഷ്ഠിത വീണ്ടെടുക്കൽ ആവശ്യമുള്ളിടത്ത്, വലിയ കുറഞ്ഞത് അപ്ലിക്കേഷനെ പ്രവർത്തിക്കുന്നതിന് മുൻപ് കൂടുതൽ കാത്തിരിക്കാൻ പ്രേരിപ്പിക്കുന്നു, ഇത് കാലതാമസത്തോട് സംവേദനക്ഷമമായ സെഷന് ആവശ്യമായതിന്റെ നേർവിപരീതമാണ്.

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

tcp-nodelay എന്ത് ചെയ്യുന്നു, എന്ത് ചെയ്യുന്നില്ല

ഗതാഗത സോക്കറ്റിൽ Nagle ശൈലിയിലുള്ള ബഫറിംഗ് ഓഫ് ചെയ്യുന്ന ടണൽ ഓപ്ഷന് ഒരു ഇടുങ്ങിയ ഉദ്ദേശ്യമുണ്ട്: ചെറിയ എഴുത്തുകൾ അയക്കുന്നതിന് മുൻപ് കൂടുതൽ ഡാറ്റയ്ക്കായി കാത്തിരിക്കുന്നത് തടയുക. ഇത് സംവേദനാത്മക ട്രാഫിക്കിന് മറ്റു കാര്യങ്ങളിൽ ആരോഗ്യകരമായ പാതയിൽ അധിക കാലതാമസം ഒഴിവാക്കാൻ സഹായിക്കുന്നു.

ഇത് ഗതാഗതത്തെ ക്രമരഹിതമാക്കുന്നില്ല, നഷ്ടമായ സെഗ്മെന്റിന് ശേഷമുള്ള വീണ്ടെടുക്കൽ ചുരുക്കുന്നുമില്ല. പുനർസംപ്രേഷണ സമയപരിധിക്കായി നിൽക്കുന്ന ഷെൽ ആ ഓപ്ഷൻ ഓണായിരിക്കുമ്പോഴും നിൽക്കും, കാരണം ഓപ്ഷൻ ക്രമ നിയമത്തെ ഒരിക്കലും തൊട്ടിട്ടില്ല.

രണ്ടിനെയും കൂട്ടിക്കലർത്തുന്നത് എളുപ്പമാണ്, കാരണം രണ്ടിനെയും കാലതാമസ പരിഹാരങ്ങളായി വിവരിക്കുന്നു. ഒന്ന് ബഫറിംഗ് കൊണ്ടുവന്ന കൃത്രിമ കാത്തിരിപ്പ് നീക്കുന്നു, മറ്റൊന്നിന് ഗതാഗതം എന്ത് ഉറപ്പുനൽകുന്നു എന്നത് മാറ്റേണ്ടിവരും, ഒരു സോക്കറ്റ് ഓപ്ഷനും അത് ചെയ്യുന്നില്ല.

ഗതാഗത പാളികളെ നീതിപൂർവ്വം താരതമ്യം ചെയ്യുന്നതെങ്ങനെ

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

ത്രൂപുട്ട് സംഖ്യയ്ക്ക് പകരം പങ്കിട്ട ഇടവേള ശ്രദ്ധിക്കുക. പുറം നഷ്ടത്തിനിടയിൽ പല ഉൾ അപ്ലിക്കേഷനുകളും ഒരുമിച്ച് കുടുങ്ങുന്നതാണ് ക്യൂവിന്റെ തലയിലെ തടയൽ തിരിച്ചറിയുന്ന നിരീക്ഷണം; സ്പീഡ് ടെസ്റ്റിന്റെ ഒരു കുറഞ്ഞ സംഖ്യ അത് ചെയ്യുന്നില്ല.

ടണൽ ഇന്റർഫേസിലും ഭൗതിക ഇന്റർഫേസിലും അധികാരപ്പെട്ട ക്യാപ്ചറുകൾ രണ്ട് പാളികളെ വ്യക്തമായി വേർതിരിക്കുന്നു, കാരണം ഉൾ, പുറം പുനർസംപ്രേഷണങ്ങൾ വെവ്വേറെ ക്രമ മേഖലകളുള്ള വെവ്വേറെ കണക്ഷനുകളിൽപ്പെടുന്നു. പുറം സ്ട്രീം വിടവ് കാണിക്കുമ്പോൾ ഉൾ പുനർസംപ്രേഷണങ്ങൾ കാണുന്നതാണ് നേരിട്ടുള്ള തെളിവ്.

UDP-യിലേക്ക് മാറുന്നത് അധിക വിശ്വസനീയ സ്ട്രീം നീക്കി, ഉൾ TCP തന്റെ സ്വന്തം വീണ്ടെടുക്കൽ ചെയ്യാൻ അനുവദിക്കുന്നു. ഇത് പൂജ്യം നഷ്ടമോ കുറഞ്ഞ കാലതാമസമോ ഉറപ്പുനൽകുന്നില്ല, നിറഞ്ഞ അപ്ലിങ്ക്, അമിത വലിപ്പമുള്ള ക്യൂകൾ അല്ലെങ്കിൽ MTU പ്രശ്നം ഇപ്പോഴും പരിഹരിക്കേണ്ടിവരും. ടണലിന് പുറത്തുള്ള ട്രാഫിക് ടണലിന്റെ ക്രമ വിടവിന് പിന്നിൽ ഒരിക്കലും തടഞ്ഞുനിർത്തപ്പെടുന്നില്ല, രണ്ട് പാതകളും ഒരേ തിരക്കേറിയ ലിങ്ക് പങ്കിടുമ്പോൾ അത് ഇപ്പോഴും ബാധിക്കപ്പെടാം, ആ പങ്കിട്ട തടസ്സം ഇതിൽ മടക്കിവയ്ക്കാതെ സ്വന്തം അന്വേഷണത്തിന് അർഹമാണ്.