ഫോർവേഡ് പ്രോക്സി TCP സെഗ്മെന്റ് അതിരുകൾ സൂക്ഷിക്കുന്നില്ല

Squid കടന്നുപോയതിന് ശേഷം ഒരു HTTP പ്രതികരണം ക്യാപ്ചർ ചെയ്ത നിരവധി TCP സെഗ്മെന്റുകളിൽ കാണുന്നു എന്ന് കരുതുക. അത് സാധാരണ TCP സ്വഭാവമാകാം, പ്രതികരണം തെറ്റായി വിഭജിച്ചു എന്നതിന് തെളിവല്ല.

ഫോർവേഡ് പ്രോക്സിക്ക് സാധാരണയായി രണ്ട് കണക്ഷനുകൾ ഉണ്ട്:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

ഓരോ കണക്ഷനും അതിന്റേതായ TCP അവസ്ഥ, ക്രമ നമ്പറുകൾ, പാക്കറ്റൈസേഷൻ എന്നിവ ഉണ്ട്. പ്രോക്സിക്ക് ഒരു കണക്ഷനിൽ നിന്ന് ഡാറ്റ വായിച്ച് മറ്റൊന്നിലേക്ക് എഴുതാം, യഥാർത്ഥ സെഗ്മെന്റ് വലുപ്പങ്ങൾ സൂക്ഷിക്കാതെ. ബഫറിംഗ്, അയയ്ക്കുന്ന സമയം, തിരക്ക്, പാതയുടെ വലുപ്പപരിധികൾ എന്നിവ മറ്റൊരു ഗ്രൂപ്പിംഗ് സൃഷ്ടിക്കാം.

വേർതിരിച്ച് സൂക്ഷിക്കേണ്ട മൂന്ന് അതിരുകൾ

ഒരു വായനയിൽ ഒരു ഹെഡറിന്റെ ഭാഗം, മുഴുവൻ ഹെഡറും ബോഡി ബൈറ്റുകളും, അല്ലെങ്കിൽ ഒന്നിലധികം ആപ്ലിക്കേഷൻ തല അതിരുകൾ കടക്കുന്ന ഡാറ്റ ഉണ്ടാകാം. TCP “HTTP പ്രതികരണത്തിന്റെ അവസാനം” വിജയകരമായ വായനയുടെ അവസാനവുമായി ബന്ധിപ്പിക്കുന്നില്ല.

അതിനാൽ HTTP/1.1 പാഴ്സർ ഹെഡറുകൾ ശേഖരിച്ച് ബാധകമായ ബോഡി-ഫ്രെയിമിംഗ് നിയമങ്ങൾ പ്രയോഗിക്കുന്നു, അവയിൽ നീളം, ട്രാൻസ്ഫർ കോഡിംഗ്, അനുവദനീയമായ കണക്ഷൻ അടയ്ക്കൽ എന്നിവ ഉൾപ്പെടുന്നു. HTTP/2 ഫ്രെയിം സ്വയം TCP സെഗ്മെന്റുകൾ കടക്കാൻ കഴിയുന്ന ഒരു പ്രോട്ടോക്കോൾ ഘടനയാണ്; അത് നെറ്റ്വർക്ക് പാക്കറ്റിന്റെ മറ്റൊരു പേരല്ല.

വിജയകരമായ CONNECT ടണൽ ടണലിലെ ബൈറ്റ് സ്ട്രീം സൂക്ഷിക്കുന്നു, എന്നാൽ ഇപ്പോഴും രണ്ട് TCP കാലുകൾ ഉപയോഗിക്കുന്നു. പ്രോക്സി ടണലിനുള്ളിലെ ബൈറ്റുകൾ മാറ്റിയിട്ടില്ലെങ്കിലും അതിന്റെ സെഗ്മെന്റ് അതിരുകൾ വ്യത്യാസപ്പെടാം.

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