కాఫీ షాప్ WiFi ద్వారా రెండు గిగాబైట్ల వీడియోను అప్లోడ్ చేయడం అనేది ఒక ఆశావాద ప్రయత్నం మాత్రమే. ప్రోగ్రెస్ బార్ డెబ్బై శాతం వరకు నెమ్మదిగా వెళ్లడం మీరు చూస్తుండగా, కనెక్షన్ సరిగ్గా ఉండదు. అప్లోడ్ విఫలమవుతుంది. మీరు మళ్ళీ ప్రయత్నించినప్పుడు, సర్వర్ కొత్త ఫైల్ను ఆశిస్తుంది. మీరు సున్నా నుండి ప్రారంభించాల్సి వస్తుంది. యూజర్-జనరేటెడ్ వీడియోలను హ్యాండిల్ చేసే అప్లికేషన్ను నిర్మిస్తున్న ఎవరికైనా, ఇది కేవలం అరుదైన సందర్భం కాదు. ఇది ఒక సాధారణ సమస్య. ఈ సమస్యను పరిష్కరించడానికే ప్రత్యేకంగా tus ప్రోటోకాల్ రూపొందించబడింది. ఇది సాధారణ HTTP పై నడిచే ఒక ఓపెన్ స్టాండర్డ్ మరియు అప్లోడ్లకు ఒక 'మెమరీ'ని ఇస్తుంది. నెట్వర్క్ మళ్ళీ అందుబాటులోకి వచ్చినప్పుడు, ఫైల్ ట్రాన్స్ఫర్ సరిగ్గా ఎక్కడ ఆగిపోయిందో అక్కడి నుండే కొనసాగుతుంది.
సాధారణ అప్లోడ్లు ఎందుకు విఫలమవుతాయి
సాధారణ మల్టీపార్ట్ ఫైల్ అప్లోడ్లు మొత్తం పేలోడ్ను ఒకే లావాదేవీగా పరిగణిస్తాయి. బ్రౌజర్ లేదా యాప్ ఒక TCP కనెక్షన్ను ఓపెన్ చేసి, బైట్లను స్ట్రీమ్ చేస్తుంది మరియు చివరలో 200 OK కోసం ఎదురుచూస్తుంది. యూజర్ LTE నుండి WiFiకి మారినందున లేదా లాప్టాప్ స్లీప్ మోడ్లోకి వెళ్ళినందున కనెక్షన్ రీసెట్ అయితే, ఏ బైట్లు సురక్షితంగా వచ్చాయో తెలుసుకోవడానికి సర్వర్కు మార్గం ఉండదు. చాలా ఫ్రేమ్వర్క్లు ఆ పాక్షిక డేటాను పారేస్తాయి. దీనివల్ల యూజర్కు ఫామ్ విఫలమై, అసహనం కలుగుతుంది. వీడియో ఫైల్ల విషయంలో ఈ సమస్య మరింత తీవ్రంగా ఉంటుంది, ఎందుకంటే అవి పెద్దవిగా ఉంటాయి, తరచుగా అస్థిరమైన నెట్వర్క్లలో మొబైల్ పరికరాల నుండి అప్లోడ్ చేయబడతాయి మరియు ఫైల్ మొత్తం పూర్తయ్యే వరకు ప్రాసెస్ చేయలేని ఫార్మాట్లలో ఎన్కోడ్ చేయబడి ఉంటాయి.
Tus ఆటను ఎలా మారుస్తుంది
Tus అప్లోడ్ను ఒకేసారి ఇచ్చే డెలివరీలా కాకుండా, ఒక 'stateful conversation' లాగా మళ్ళీ ఆలోచిస్తుంది. ఫైల్ను ఒకేసారి నిరంతర బైట్ల రూపంలో పంపే బదులు, క్లయింట్ పేలోడ్ను చిన్న చిన్న భాగాలుగా (chunks) విభజిస్తుంది. అంతకంటే ముఖ్యంగా, సర్వర్ ఇప్పటివరకు అందుకున్న బైట్ల ఖచ్చితమైన సంఖ్యను (offset) గుర్తుంచుకుంటుంది. ఈ స్టేట్ పర్సిస్టెన్స్ (state persistence) వల్లనే మళ్ళీ ప్రారంభించడం (resumption) సాధ్యమవుతుంది. ఈ ప్రోటోకాల్ ఉద్దేశపూర్వకంగానే సరళంగా ఉంటుంది. దీనికి WebSockets, gRPC లేదా ప్రొప్రైటరీ SDKలు అవసరం లేదు. ఇది మీకు ఇప్పటికే తెలిసిన HTTP మెథడ్స్ను ఉపయోగిస్తుంది.
మళ్ళీ ప్రారంభించడానికి (Resumption) తోడ్పడే మూడు రిక్వెస్ట్లు
ప్రతి tus అప్లోడ్ ఒక క్రమబద్ధమైన ప్రక్రియను అనుసరిస్తుంది.
మొదట, క్లయింట్ తెలిసిన tus ఎండ్పాయింట్కు POST రిక్వెస్ట్ను పంపుతుంది. హెడర్లు ఫైల్ను వివరిస్తాయి. Upload-Length హెడర్ బైట్లలో ఫైల్ యొక్క తుది పరిమాణాన్ని తెలియజేస్తుంది, మరియు ఫైల్ పేరు లేదా కంటెంట్ టైప్ వంటి ఐచ్ఛిక మెటాడేటా Upload-Metadata హెడర్లో కామాతో వేరు చేయబడిన base64-encoded కీ-వాల్యూ జంటల జాబితాగా ప్రయాణిస్తుంది. సర్వర్ ఒక ఖాళీ అప్లోడ్ రిసోర్స్ను సృష్టించి, 201 Created స్టేటస్తో పాటు ఒక ప్రత్యేక URLని సూచించే Location హెడర్తో స్పందిస్తుంది. ఈ URL అప్లోడ్ ప్రక్రియ అంతా కొనసాగేంత వరకు దాని చిరునామాగా ఉంటుంది.
తర్వాత PATCH రిక్వెస్ట్ వస్తుంది. క్లయింట్ ఆ ప్రత్యేక URLకి రా డేటా (raw binary data) యొక్క చంక్స్ను పంపుతుంది. పేలోడ్తో పాటు రెండు కీలకమైన హెడర్లు ఉంటాయి. Content-Type తప్పనిసరిగా application/offset+octet-stream అయి ఉండాలి, మరియు Upload-Offset ఈ చంక్ ప్రారంభమయ్యే బైట్ పొజిషన్తో సరిపోలాలి. సర్వర్ ఆ ఆఫ్సెట్ తన రికార్డులతో సరిపోలుతుందో లేదో తనిఖీ చేస్తుంది. ఒకవేళ సరిపోలకపోతే, డేటా పాడైపోకుండా ఉండటానికి సర్వర్ 409 Conflictని తిరిగి పంపుతుంది. అంతా సరిగ్గా ఉంటే, సర్వర్ ఆ బైట్లను జోడించి, తన అంతర్గత ఆఫ్సెట్ను అప్డేట్ చేస్తుంది మరియు కొత్త Upload-Offsetతో పాటు 204 No Content రెస్పాన్స్ను అందిస్తుంది. చంక్ సైజును మార్చుకోవచ్చు (configurable), కానీ సాధారణంగా కొన్ని వందల కిలోబైట్ల నుండి కొన్ని మెగాబైట్ల మధ్య ఉంటుంది. చిన్న చంక్లు ఎక్కువ HTTP ఓవర్హెడ్ను కలిగిస్తాయి కానీ లోపాల నుండి త్వరగా కోలుకుంటాయి. పెద్ద చంక్లు రౌండ్ ట్రిప్లను తగ్గిస్తాయి కానీ అవి మధ్యలో విఫలమైతే ఎక్కువ బ్యాండ్విడ్త్ను వృథా చేస్తాయి.
చివరగా, HEAD రిక్వెస్ట్. ఇది ఒక సేఫ్టీ నెట్. ఒకవేళ PATCH ఒక చంక్ మధ్యలో విఫలమైతే, ఉదాహరణకు ఐదు మెగాబైట్ల ముక్కలో మూడు మెగాబైట్ల తర్వాత కనెక్షన్ కట్ అయితే, క్లయింట్ మళ్ళీ నెట్వర్క్ యాక్సెస్ పొందినప్పుడు అప్లోడ్ URLకి HEAD రిక్వెస్ట్ను పంపుతుంది. సర్వర్ ప్రస్తుత Upload-Offsetతో సమాధానం ఇస్తుంది. క్లయింట్ పోల్చి చూస్తుంది