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