SSTP-യ്ക്കുള്ളിലെ TCP: വീണ്ടും സംപ്രേക്ഷണം രണ്ടുതവണ സംഭവിക്കുന്നത് എന്തുകൊണ്ട്

വാമൊഴി പ്രോട്ടോക്കോളിന് മുമ്പേ എത്തുന്നു. ചുറ്റും ചോദിച്ചാൽ SSTP ആണ് മെല്ലിനം, എന്തെങ്കിലും നിർബന്ധിച്ചില്ലെങ്കിൽ ഒഴിവാക്കുന്ന ഓപ്ഷൻ. ആ പ്രശസ്തി ഒരു തരം പാതയിലെ ഒരു പരാജയ മോഡിനെ മാത്രം വിവരിക്കുന്നു.

സംവിധാനം യഥാർത്ഥമാണ്. അത് സോപാധികവുമാണ്, അത് പ്രശസ്തി ഒരിക്കലും പരാമർശിക്കുന്നില്ല.

ഒരു പാതയിൽ രണ്ട് വിശ്വസനീയ സ്ട്രീമുകൾ

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

ഉൾ TCP ഒഴുക്കുകൾ അവയുടെ സ്വന്തം ക്രമവും തിരക്ക് നിയന്ത്രണവും നിലനിർത്തുന്നു. അവയ്ക്ക് പുറം പുനഃപ്രാപ്തി കാണാനാവില്ല, അതിനാൽ അവ ശ്രദ്ധിക്കുന്നത് സ്തംഭനം മാത്രമാണ്. പാത തിരക്കിലാണെന്ന് അവയോട് പറയുന്ന സിഗ്നലാണ് ആ സ്തംഭനം.

ഇപ്പോൾ രണ്ട് പാളികളും ഒരേസമയം പിന്നോട്ട് പോകുന്നു. അതാണ് മുഴുവൻ പരസ്പരപ്രവർത്തനം, അത് തുടങ്ങാൻ ഒരു നഷ്ടപ്പെട്ട സെഗ്മെന്റ് മതി.

ഫലം എവിടെ പ്രത്യക്ഷപ്പെടുന്നു, എവിടെ ഇല്ല

വൃത്തിയുള്ള പാതയിൽ പുറം സ്ട്രീം അപൂർവ്വമായി മാത്രം എന്തെങ്കിലും വീണ്ടെടുക്കുന്നു. പരസ്പരപ്രവർത്തനം ഒരിക്കലും സജീവമാകുന്നില്ല, SSTP ഇന്ററാക്ടീവ് ട്രാഫിക് നന്നായി കൊണ്ടുപോകുന്നു. പൊതുവായ വാദം കൃത്യം ഈ ഘട്ടത്തിൽ പരാജയപ്പെടുന്നു.

നഷ്ടമോ പുനഃക്രമീകരണമോ അടിസ്ഥാന പാതയിൽ എത്തുമ്പോഴാണ് ഫലം പ്രത്യക്ഷപ്പെടുന്നത്. തിരക്കുള്ള Wi-Fi ലിങ്കോ മാറുന്ന ലേറ്റൻസിയുള്ള മൊബൈൽ കണക്ഷനോ സാഹചര്യങ്ങൾ സൃഷ്ടിക്കുന്നു. തുടർന്ന് തടഞ്ഞ പുറം ക്യൂ ടണലിനുള്ളിൽ കാണാവുന്ന കാലതാമസമായി മാറുന്നു.

ജോലിഭാരത്തിനൊപ്പവും ഇത് വളരുന്നു. നിരവധി സമാന്തര ഒഴുക്കുകൾ ക്യൂ നിറയ്ക്കുകയും ക്യൂവിന്റെ തലയിലെ തടസ്സം വഷളാക്കുകയും ചെയ്യുന്നു. അതേ പാതയിലെ ഒരു ഇന്ററാക്ടീവ് സെഷൻ സ്വീകാര്യമായി തോന്നിയേക്കാം.

രോഗലക്ഷണം സാധാരണയായി എന്തല്ല

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

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

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

പ്രശ്നം നടക്കുമ്പോൾ തന്നെ അളവെടുപ്പ് നടത്തുക. ആരോഗ്യകരമായ ഒരു മിനിറ്റിൽ എടുത്ത ക്യാപ്ചർ മോശം മിനിറ്റിൽ പ്രവർത്തിക്കുന്ന ലൂപ്പിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

വിശ്വസിക്കാൻ യോഗ്യമായ ഒരു താരതമ്യം

മറ്റൊരു ട്രാൻസ്പോർട്ട് യഥാർത്ഥത്തിൽ ലഭ്യമാണെങ്കിൽ, നിയന്ത്രിത സാഹചര്യങ്ങളിൽ അതിനെ താരതമ്യം ചെയ്യുക. അതേ ഹോസ്റ്റ്, അതേ നെറ്റ്വർക്ക്, അതേ ലക്ഷ്യസ്ഥാനം, അതേ ജോലി. രണ്ട് റണ്ണുകളും ഒരേ പത്ത് മിനിറ്റിനുള്ളിൽ ആകണം, അപ്പോൾ പാതയുടെ സാഹചര്യങ്ങൾ ഒത്തുപോകും.

പോർട്ട് മാറ്റുന്നത് പ്രോട്ടോക്കോൾ മാറ്റുന്നില്ല. ബന്ധമില്ലാത്ത ഒരു പ്രൊഫൈൽ SSTP ക്ലയന്റിലേക്ക് ഇറക്കുമതി ചെയ്യുന്നത് ബദൽ ട്രാൻസ്പോർട്ട് സൃഷ്ടിക്കുന്നില്ല. സെർവർ രണ്ടാമത്തെ ഓപ്ഷൻ വാഗ്ദാനം ചെയ്യുമ്പോൾ മാത്രമാണ് താരതമ്യത്തിന് അർത്ഥമുള്ളത്.

TLS പരിശോധന എപ്പോഴും സജീവമായി നിലനിർത്തുക. പ്രകടനപരമായ ജോലി പരിശോധിക്കാത്ത സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കാനുള്ള കാരണമല്ല. അപ്ലിങ്ക് നിറഞ്ഞിരിക്കുമ്പോൾ സ്തംഭനങ്ങൾ പ്രധാനമായും പ്രത്യക്ഷപ്പെടുന്നെങ്കിൽ, പാളികളെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ക്യൂകൾ നോക്കുക.