ഒരു കോഫി ഷോപ്പിലെ വൈഫൈ ഉപയോഗിച്ച് രണ്ട് ഗിഗാബൈറ്റ് വീഡിയോ അപ്ലോഡ് ചെയ്യുന്നത് ശുഭാപ്തിവിശ്വാസത്തിന്റെ ഒരു പരീക്ഷണം പോലെയാണ്. പ്രോഗ്രസ്സ് ബാർ എഴുപത് ശതമാനത്തിലേക്ക് നീങ്ങുന്നത് നിങ്ങൾ നോക്കിനിൽക്കുന്നു, പെട്ടെന്ന് കണക്ഷൻ തകരാറിലാകുന്നു. അപ്ലോഡ് പരാജയപ്പെടുന്നു. നിങ്ങൾ വീണ്ടും ശ്രമിക്കുമ്പോൾ, സെർവർ ഒരു പുതിയ ഫയൽ ആണ് പ്രതീക്ഷിക്കുന്നത്. നിങ്ങൾ പൂജ്യത്തിൽ നിന്ന് വീണ്ടും തുടങ്ങേണ്ടി വരുന്നു. ഉപയോക്താക്കൾ നിർമ്മിക്കുന്ന വീഡിയോകൾ കൈകാര്യം ചെയ്യുന്ന ഒരു ആപ്ലിക്കേഷൻ നിർമ്മിക്കുന്ന ആർക്കും ഇത് ഒരു അപൂർവ്വ സംഭവമല്ല. മറിച്ച് ഇതൊരു സാധാരണ കാര്യമാണ്. ഈ പ്രശ്നം പരിഹരിക്കാനാണ് പ്രത്യേകിച്ച് tus പ്രോട്ടോക്കോൾ നിർമ്മിച്ചിരിക്കുന്നത്. ഇത് സാധാരണ HTTP-യിൽ പ്രവർത്തിക്കുന്ന ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡാണ്, കൂടാതെ അപ്ലോഡുകൾക്ക് ഒരു 'മെമ്മറി' നൽകുകയും ചെയ്യുന്നു. നെറ്റ്വർക്ക് വീണ്ടെടുക്കുമ്പോൾ, ഫയൽ ട്രാൻസ്ഫർ എവിടെയാണോ നിർത്തിയിരുന്നത് അവിടെ നിന്ന് തന്നെ തുടരുന്നു.
എന്തുകൊണ്ടാണ് സാധാരണ അപ്ലോഡുകൾ പരാജയപ്പെടുന്നത്
സാധാരണ മൾട്ടിപാർട്ട് ഫയൽ അപ്ലോഡുകൾ മുഴുവൻ പേലോഡിനെയും (payload) ഒരു സിംഗിൾ ട്രാൻസാക്ഷനായിട്ടാണ് കണക്കാക്കുന്നത്. ബ്രൗസറോ ആപ്പോ ഒരു TCP കണക്ഷൻ തുറക്കുന്നു, ബൈറ്റുകൾ സ്ട്രീം ചെയ്യുന്നു, അവസാനം ഒരു 200 OK പ്രതീക്ഷിക്കുന്നു. ഉപയോക്താവ് LTE-യിൽ നിന്ന് വൈഫൈയിലേക്ക് മാറിയതുകൊണ്ടോ അല്ലെങ്കിൽ ലാപ്ടോപ്പ് സ്ലീപ്പ് മോഡിലേക്ക് പോയതുകൊണ്ടോ കണക്ഷൻ റീസെറ്റ് ചെയ്യപ്പെട്ടാൽ, ഏത് ബൈറ്റുകളാണ് സുരക്ഷിതമായി എത്തിയതെന്ന് അറിയാൻ സെർവറിന് കഴിയില്ല. മിക്ക ഫ്രെയിംവർക്കുകളും ഭാഗികമായ ഡാറ്റ വെറുതെ ഒഴിവാക്കുന്നു. പരാജയപ്പെട്ട ഒരു ഫോമും മോശം മാനസികാവസ്ഥയുമായി ഉപയോക്താവ് അവശേഷിക്കുന്നു. വീഡിയോ ഫയലുകൾ വലിയവയായതിനാലും, പലപ്പോഴും അസ്ഥിരമായ നെറ്റ്വർക്കുകളിൽ മൊബൈൽ ഉപകരണങ്ങളിൽ നിന്ന് അപ്ലോഡ് ചെയ്യുന്നതിനാലും, ഫയൽ പൂർണ്ണമായി ലഭിക്കുന്നത് വരെ പ്രോസസ്സ് ചെയ്യാൻ കഴിയാത്ത ഫോർമാറ്റുകളിൽ എൻകോഡ് ചെയ്തിരിക്കുന്നതിനാലും ഈ ബുദ്ധിമുട്ട് വർദ്ധിക്കുന്നു.
Tus എങ്ങനെയാണ് ഇതിനെ മാറ്റുന്നത്
അപ്ലോഡിനെ ഒരു ഒറ്റത്തവണ ഡെലിവറി എന്നതിലുപരി ഒരു stateful conversation ആയി tus പുനർചിന്തനം ചെയ്യുന്നു. ഒരു ഫയൽ തുടർച്ചയായ ബൈറ്റുകളുടെ ഒരു പ്രവാഹം പോലെ അയക്കുന്നതിന് പകരം, ക്ലയന്റ് പേലോഡിനെ ചെറിയ കഷണങ്ങളായി (chunks) തിരിക്കുന്നു. അതിലുപരിയായി, ഇതുവരെ എത്ര ബൈറ്റുകൾ സ്വീകരിച്ചു എന്ന കൃത്യമായ എണ്ണം (offset) സെർവർ ഓർത്തു വെക്കുന്നു. ഈ state persistence ആണ് അപ്ലോഡ് പുനരാരംഭിക്കുന്നത് സാധ്യമാക്കുന്നത്. ഈ പ്രോട്ടോക്കോൾ ബോധപൂർവ്വം ലളിതമായാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഇതിന് WebSockets, gRPC അല്ലെങ്കിൽ പ്രൊപ്രൈറ്ററി SDK-കൾ ആവശ്യമില്ല. നിങ്ങൾക്ക് നേരത്തെ അറിയാവുന്ന HTTP മെത്തേഡുകൾ തന്നെ ഇത് ഉപയോഗിക്കുന്നു.
അപ്ലോഡ് പുനരാരംഭിക്കാൻ സഹായിക്കുന്ന മൂന്ന് റിക്വസ്റ്റുകൾ
ഓരോ tus അപ്ലോഡും ഒരു നിശ്ചിത രീതി പിന്തുടരുന്നു.
ആദ്യം, ക്ലയന്റ് അറിയപ്പെടുന്ന ഒരു tus എൻഡ്പോയിന്റിലേക്ക് ഒരു POST റിക്വസ്റ്റ് അയക്കുന്നു. ഹെഡറുകൾ ഫയലിനെ വിവരിക്കുന്നു. Upload-Length ഹെഡർ ബൈറ്റുകളിലുള്ള ഫയലിന്റെ അവസാന വലിപ്പം രേഖപ്പെടുത്തുന്നു, കൂടാതെ ഫയൽ പേര് അല്ലെങ്കിൽ കണ്ടന്റ് ടൈപ്പ് പോലുള്ള ഓപ്ഷണൽ മെറ്റാഡാറ്റ Upload-Metadata ഹെഡറിൽ കോമ ഉപയോഗിച്ച് വേർതിരിച്ച base64-എൻകോഡ് ചെയ്ത കീ-വാല്യൂ ജോഡികളായി അയക്കുന്നു. സെർവർ ഒരു ശൂന്യമായ അപ്ലോഡ് റിസോഴ്സ് സൃഷ്ടിക്കുകയും, ഒരു തനതായ URL ചൂണ്ടിക്കാണിക്കുന്ന Location ഹെഡറിനൊപ്പം 201 Created സ്റ്റാറ്റസ് നൽകി മറുപടി നൽകുകയും ചെയ്യുന്നു. ഈ URL ആണ് അപ്ലോഡിന്റെ ബാക്കി സമയത്തേക്കുള്ള വിലാസം.
അടുത്തത് PATCH റിക്വസ്റ്റ് ആണ്. ക്ലയന്റ് ആ തനതായ URL-ലേക്ക് ബൈനറി ഡാറ്റയുടെ കഷണങ്ങൾ (chunks) അയക്കുന്നു. പേലോഡിനൊപ്പം രണ്ട് പ്രധാനപ്പെട്ട ഹെഡറുകൾ ഉണ്ടാകും. Content-Type എന്നത് application/offset+octet-stream ആയിരിക്കണം, കൂടാതെ Upload-Offset എന്നത് ഈ കഷണം തുടങ്ങുന്ന ബൈറ്റ് പൊസിഷനുമായി പൊരുത്തപ്പെടണം. ഓഫ്സെറ്റ് സെർവറിലെ റെക്കോർഡുകളുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് സെർവർ പരിശോധിക്കുന്നു. പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, ഡാറ്റാ തകരാറുകൾ ഒഴിവാക്കാൻ സെർവർ 409 Conflict നൽകുന്നു. എല്ലാം ശരിയാണെങ്കിൽ, സെർവർ ബൈറ്റുകൾ ചേർക്കുകയും അതിന്റെ ഇന്റേണൽ ഓഫ്സെറ്റ് പുതുക്കുകയും ചെയ്യുന്നു, കൂടാതെ പുതിയ Upload-Offset-നൊപ്പം 204 No Content മറുപടിയും നൽകുന്നു. ചങ്ക് സൈസ് (chunk size) മാറ്റം വരുത്താവുന്നതാണ്, എങ്കിലും സാധാരണയായി ഏതാനും നൂറ് കിലോബൈറ്റുകൾ മുതൽ ഏതാനും മെഗാബൈറ്റുകൾ വരെയാണ് ഉപയോഗിക്കാറുള്ളത്. ചെറിയ ചങ്കുകൾ കൂടുതൽ HTTP ഓവർഹെഡ് ഉണ്ടാക്കുമെങ്കിലും പിശകുകളിൽ നിന്ന് വേഗത്തിൽ വീണ്ടെടുക്കാൻ സഹായിക്കും. വലിയ ചങ്കുകൾ റൗണ്ട് ട്രിപ്പുകൾ കുറയ്ക്കുമെങ്കിലും, അവ പകുതിയിൽ വെച്ച് പരാജയപ്പെട്ടാൽ കൂടുതൽ ബാൻഡ്വിഡ്ത്ത് നഷ്ടപ്പെടും.
അവസാനമായി, HEAD റിക്വസ്റ്റ്. ഇതാണ് സുരക്ഷാ കവചം. ഒരു PATCH റിക്വസ്റ്റ് ഒരു ചങ്കിന്റെ പകുതിയിൽ വെച്ച് പരാജയപ്പെട്ടാൽ (ഉദാഹരണത്തിന് അഞ്ച് മെഗാബൈറ്റ് കഷണത്തിന്റെ മൂന്ന് മെഗാബൈറ്റ് കഴിഞ്ഞപ്പോൾ), കണക്ഷൻ വിച്ഛേദിക്കപ്പെടുന്നു. ക്ലയന്റിന് നെറ്റ്വർക്ക് ലഭിക്കുമ്പോൾ, അത് അപ്ലോഡ് URL-ലേക്ക് ഒരു HEAD റിക്വസ്റ്റ് അയക്കുന്നു. സെർവർ നിലവിലെ Upload-Offset നൽകി മറുപടി നൽകുന്നു. ക്ലയന്റ് താരതമ്യം ചെയ്യുന്നു