कॉफी शॉपच्या WiFi वर दोन-गीगाबाइटचा व्हिडिओ अपलोड करणे म्हणजे केवळ आशावाद आहे. तुम्ही प्रोग्रेस बार सत्तर टक्क्यांपर्यंत पोहोचताना पाहता आणि मग कनेक्शन खंडित होते. अपलोड अयशस्वी होते. जेव्हा तुम्ही पुन्हा प्रयत्न करता, तेव्हा सर्व्हर नवीन फाईलची अपेक्षा करतो. तुम्हाला शून्यापासून सुरुवात करावी लागते. युजर-जनरेटेड व्हिडिओ हाताळणारे ॲप्लिकेशन बनवणाऱ्या कोणासाठीही ही केवळ एक अपवादात्मक घटना (edge case) नाही, तर ती एक सामान्य बाब आहे. tus प्रोटोकॉल खास याच समस्येवर मात करण्यासाठी बनवला गेला आहे. हा एक ओपन स्टँडर्ड आहे जो सामान्य HTTP वर चालतो आणि अपलोडला 'मेमरी' देतो. जेव्हा नेटवर्क पुन्हा सुरू होते, तेव्हा फाईल ट्रान्सफर जिथे थांबली होती तिथूनच पुन्हा सुरू होते.
स्टँडर्ड अपलोड्स का अयशस्वी होतात
स्टँडर्ड मल्टिपार्ट फाईल अपलोड्स संपूर्ण पेलोडकडे एका सिंगल ट्रान्झॅक्शनप्रमाणे पाहतात. ब्राउझर किंवा ॲप एक TCP कनेक्शन उघडते, बाइट्स स्ट्रीम करते आणि शेवटी 200 OK ची अपेक्षा करते. जर युजरने LTE वरून WiFi वर स्विच केल्यामुळे किंवा लॅपटॉप स्लीप मोडमध्ये गेल्यामुळे कनेक्शन रिसेट झाले, तर सर्व्हरला कोणते बाइट्स सुरक्षितपणे पोहोचले हे समजण्याचे कोणतेही साधन नसते. बहुतेक फ्रेमवर्क्स अर्धवट डेटा सहजपणे काढून टाकतात. युजरला फक्त एक अयशस्वी फॉर्म आणि खराब मूड उरतो. व्हिडिओ फाईल्समुळे ही समस्या अधिक गंभीर होते कारण त्या मोठ्या असतात, अनेकदा अस्थिर नेटवर्कवर मोबाईल उपकरणांवरून अपलोड केल्या जातात आणि अनेकदा अशा फॉरमॅटमध्ये एनकोड केलेल्या असतात ज्यावर संपूर्ण फाईल उपलब्ध होईपर्यंत प्रक्रिया करता येत नाही.
Tus गेम कसा बदलतो
Tus अपलोडला एका 'वन-शॉट डिलिव्हरी' ऐवजी 'स्टेटफुल कन्वर्सेशन' (stateful conversation) म्हणून पुन्हा विचार करते. फाईल बाइट्सच्या एका अखंड प्रवाहाने पाठवण्याऐवजी, क्लायंट पेलोडला लहान तुकड्यांमध्ये (chunks) विभागतो. महत्त्वाचे म्हणजे, सर्व्हर 'ऑफसेट' (offset) लक्षात ठेवतो, म्हणजेच आतापर्यंत प्राप्त झालेल्या बाइट्सची नेमकी संख्या. ही 'स्टेट पर्सिस्टन्स' (state persistence) मुळेच पुन्हा सुरू करणे (resumption) शक्य होते. हा प्रोटोकॉल हेतुपुरस्सर सोपा ठेवला आहे. यासाठी WebSockets, gRPC किंवा प्रोप्रायटरी SDKs ची आवश्यकता नाही. तो तुम्ही आधीच ओळखत असलेल्या HTTP मेथड्सचा वापर करतो.
रिझ्युमेशनला सक्षम करणाऱ्या तीन विनंत्या
प्रत्येक tus अपलोड एका ठराविक क्रमाने चालते.
प्रथम, क्लायंट एका ज्ञात tus एंडपॉइंटला POST विनंती (request) पाठवतो. हेडर्स फाईलचे वर्णन करतात. Upload-Length हेडर बाइट्समधील अंतिम आकार दर्शवते, आणि फाईलचे नाव किंवा कंटेंट टाईप सारखी पर्यायी मेटाडेटा Upload-Metadata हेडरमध्ये base64-encoded की-व्हॅल्यू जोड्यांच्या स्वल्पविराम-विभक्त सूचीमध्ये पाठवली जाते. सर्व्हर एक रिकामी अपलोड रिसोर्स तयार करतो आणि 201 Created स्टेटससह एका युनिक URL कडे निर्देश करणाऱ्या Location हेडरसह प्रतिसाद देतो. हे URL अपलोडच्या उर्वरित आयुष्यासाठी त्याचा पत्ता असते.
त्यानंतर PATCH विनंती येते. क्लायंट त्या युनिक URL वर रॉ बायनरी डेटाचे तुकडे (chunks) पाठवतो. पेलोडसोबत दोन महत्त्वाचे हेडर्स असतात. Content-Type हे application/offset+octet-stream असणे आवश्यक आहे आणि Upload-Offset हे ज्या बाइट पोझिशनपासून हा तुकडा सुरू होतो त्याशी जुळले पाहिजे. सर्व्हर ऑफसेट त्याच्या स्वतःच्या रेकॉर्डशी जुळतो की नाही याची पडताळणी करतो. जर ते जुळले नाही, तर सर्व्हर 409 Conflict परत करतो, ज्यामुळे डेटा करप्ट होण्यापासून संरक्षण मिळते. जर सर्व काही व्यवस्थित असेल, तर सर्व्हर बाइट्स जोडतो, त्याचा अंतर्गत ऑफसेट अपडेट करतो आणि नवीन Upload-Offset सोबत 204 No Content प्रतिसाद देतो. चंकचा आकार कॉन्फिगर करण्यायोग्य आहे, परंतु सामान्यतः तो काही शेकडो किलोबाइट्स ते काही मेगाबाइट्सच्या दरम्यान असतो. लहान चंक्समुळे अधिक HTTP ओव्हरहेड निर्माण होतो परंतु त्रुटींमधून वेगाने रिकव्हर होतो. मोठे चंक्स राउंड ट्रिप्स कमी करतात परंतु जर ते मध्येच अयशस्वी झाले तर अधिक बँडविड्थ वाया घालवतात.
शेवटी, HEAD विनंती. ही एक सुरक्षा जाळी (safety net) आहे. जर एखादा PATCH चंकच्या मध्येच अयशस्वी झाला, समजा पाच-मेगाबाइटच्या स्लाईसपैकी तीन मेगाबाइट नंतर, आणि कनेक्शन तुटले, तर जेव्हा क्लायंटला नेटवर्क प्रवेश पुन्हा मिळतो, तेव्हा तो अपलोड URL वर HEAD विनंती पाठवतो. सर्व्हर सध्याच्या Upload-Offset सह उत्तर देतो. क्लायंट तुलना करतो