बैकएंड इंटरव्यू: आप HTTP प्रायोरिटी शेड्यूलिंग कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और प्रयोज्यता

एक पेज एक ही समय में HTML, क्रिटिकल CSS, फ़ॉन्ट्स, इमेजेस और बैकग्राउंड डेटा का अनुरोध करता है। मोबाइल बैंडविड्थ सीमित है। टीम चाहती है कि क्रिटिकल रिसोर्स HTTP Priority के साथ पहले पूरे हों, लेकिन प्रॉक्सी ओवरराइड्स, स्टार्वेशन, एप्लिकेशन शेड्यूलिंग को बायपास करने वाले कैश हिट्स और पैकेट-लॉस रीट्रांसमिशन द्वारा क्रम बदलने को लेकर चिंतित है। वैलिडेशन सहित HTTP/1.1, HTTP/2 और HTTP/3 में सर्वर और प्रॉक्सी शेड्यूलिंग डिज़ाइन करें।

RFC 9218 एक वर्ज़न-इंडिपेंडेंट Priority हेडर और HTTP/2 तथा HTTP/3 के लिए री-प्रायोरिटाइजेशन फ़्रेम्स को परिभाषित करता है। यह प्राथमिकताओं (preferences) को संप्रेषित करता है, न कि डिलीवरी SLA को। एक मजबूत उत्तर सिग्नल्स, शेड्यूलर, कैश और ट्रांसपोर्ट को अलग करता है, और यह बताता है कि प्रत्येक लेयर क्या रिजेक्ट या रीराइट कर सकती है।

इंटरव्यूअर क्या टेस्ट कर रहा है

• यह जानना कि urgency 0 से 7 तक होती है, जिसमें छोटे मान अधिक जरूरी होते हैं और डिफ़ॉल्ट रिक्वेस्ट मान 3 होता है।
• यह समझाना कि समान urgency वाले रिसोर्सेज़ के लिए incremental समवर्तीता (concurrency) और पूरा होने के समय को कैसे बदलता है।
• HTTP/1.1 रिक्वेस्ट ऑर्डरिंग को HTTP/2 और HTTP/3 में मल्टीप्लेक्स्ड शेड्यूलिंग से अलग पहचानना।
• Priority को SLA के बजाय एक संकेत (hint) के रूप में मानना और प्रतिकूल या गलत क्लाइंट घोषणाओं को संभालना।
• कैश हिट्स, प्रॉक्सी री-प्रायोरिटाइजेशन, QUIC रीट्रांसमिशन, निष्पक्षता और क्रॉस-कनेक्शन प्रतिस्पर्धा पर विचार करना।
• यूज़र-एक्सपीरियंस और निष्पक्षता मेट्रिक्स के साथ एक रिवर्सीबल रोलआउट डिज़ाइन करना।

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

1. क्या लक्ष्य कम LCP, किसी एक API के लिए कम टेल लेटेंसी, या अधिक बैकग्राउंड थ्रूपुट है? प्रत्येक नीति और मेट्रिक्स को बदल देता है।
2. क्या रिसोर्स एक ही कनेक्शन, CDN नोड और कैश की पर हैं? सिंगल-कनेक्शन प्रायोरिटी की तुलना सीधे अलग-अलग कनेक्शन्स में नहीं की जा सकती।
3. किन रिसोर्सेज़ को इनक्रीमेंटली प्रोसेस किया जा सकता है? पूर्ण CSS, फ़ॉन्ट्स और गैर-चंकेबल कंप्रेस्ड ऑब्जेक्ट्स को केवल इसलिए विभाजित नहीं किया जाना चाहिए क्योंकि urgency अधिक है।
4. क्या प्रॉक्सी रिक्वेस्ट और रिस्पॉन्स हेडर्स तथा PRIORITY_UPDATE को फ़ॉरवर्ड करते हैं? क्या प्रत्येक हॉप HTTP/2 या HTTP/3 का उपयोग करता है?
5. क्या कोई टेनेंट, यूज़र या सिक्योरिटी बाउंड्रीज़ हैं जो कम मूल्य वाले अनुरोधों को सर्वोच्च प्राथमिकता का दावा करने से रोकती हैं?

30-सेकंड का उत्तर

मैं लक्ष्य को यूज़र-विज़िबल कंप्लीशन टाइम के रूप में परिभाषित करूँगा और डिफ़ॉल्ट के साथ रिसोर्सेज़ को वर्गीकृत करूँगा। क्लाइंट Priority हेडर एक इनपुट है; सर्वर रिसोर्स प्रकार, कैश स्थिति, कनेक्शन और निष्पक्षता का उपयोग करके इसकी पुनर्गणना करता है। 0 से 7 तक की Urgency सापेक्ष क्रम देती है, जबकि incremental उन रिस्पॉन्स के लिए है जिन्हें बाइट्स आते ही प्रोसेस किया जा सकता है। HTTP/1.1 कनेक्शन रिक्वेस्ट क्रम पर निर्भर करता है; HTTP/2 और HTTP/3 एक शेड्यूलर और, समर्थित होने पर, री-प्रायोरिटाइजेशन फ़्रेम का उपयोग करते हैं। कैश हिट्स, रीट्रांसमिशन और क्रॉस-कनेक्शन बैंडविड्थ को अलग से संभालने की आवश्यकता होती है। कैनरी में मैं LCP, क्रिटिकल-रिसोर्स कंप्लीशन, बैकग्राउंड टेल्स, स्टार्वेशन और बैंडविड्थ को ट्रैक करूँगा, और यदि गार्डरेल्स विफल होते हैं तो रीराइटिंग को अक्षम कर दूँगा।

चरण-दर-चरण गहन विश्लेषण

1. प्रोडक्ट लक्ष्यों को शेड्यूलिंग लक्ष्यों में बदलें

HTML, रेंडर-ब्लॉकिंग CSS और क्रिटिकल फ़ॉन्ट्स को जल्दी पूरा होना चाहिए। बड़ी इमेजेस कम जरूरी हो सकती हैं; एनालिटिक्स और प्रीफ़ेच को क्रिटिकल पाथ के साथ प्रतिस्पर्धा नहीं करनी चाहिए। बैकग्राउंड APIs को अभी भी अधिकतम प्रतीक्षा समय की आवश्यकता है। केवल यह कहने के बजाय कि क्रिटिकल अनुरोध पहले जाएं, प्रत्येक वर्ग को एक प्रतीक्षा सीमा और बैंडविड्थ शेयर दें।

2. दो Priority पैरामीटर्स को समझाएं

u तात्कालिकता (urgency) है: 0 सबसे अधिक और 7 सबसे कम है, जिसमें डिफ़ॉल्ट रिक्वेस्ट मान 3 है। i बताता है कि रिस्पॉन्स को इनक्रीमेंटली प्रोसेस किया जा सकता है। i के साथ, एक सर्वर समान-urgency वाले रिसोर्सेज़ के बीच बैंडविड्थ को विभाजित कर सकता है ताकि वे सभी जल्दी शुरू हो सकें, जबकि प्रत्येक बाद में पूरा हो सकता है। इसके बिना, उन ऑब्जेक्ट्स के लिए सीक्वेंशियल डिलीवरी आमतौर पर बेहतर होती है जिन्हें टुकड़ों में प्रोसेस नहीं किया जा सकता।

GET /style.css HTTP/1.1
Host: example.test
Priority: u=1

GET /hero.jpg HTTP/1.1
Host: example.test
Priority: u=4, i

सर्वर रिस्पॉन्स डाउनस्ट्रीम इंटरमीडियरी को प्राथमिकता संकेत भी भेज सकता है। रिस्पॉन्स हेडर को छोड़ने का मतलब है कि सर्वर ने क्लाइंट प्राथमिकता को नहीं बदला। अज्ञात पैरामीटर्स को अनदेखा किया जाना चाहिए; क्लाइंट मान कोई ऑथराइजेशन या बिलिंग क्रेडेंशियल नहीं है।

3. प्रोटोकॉल वर्ज़न के अनुसार सीमाएं चुनें

HTTP/1.1 में कोई अंतर्निहित मल्टीप्लेक्स्ड प्राथमिकता नहीं है; सर्वर का व्यवहार मुख्य रूप से कनेक्शन क्रम, कनेक्शन समवर्तीता और कतारों का पालन करता है। HTTP/2 और HTTP/3 एक मल्टीप्लेक्स्ड कनेक्शन पर बैंडविड्थ साझा करते हैं, इसलिए एक शेड्यूलर urgency और incremental का उपयोग करके अगले डेटा सेगमेंट का चयन कर सकता है। दोनों PRIORITY_UPDATE तंत्र के साथ मौजूदा अनुरोध की प्राथमिकता को बदल सकते हैं, लेकिन कार्यान्वयन तत्काल या सख्त निष्पादन का वादा नहीं करते हैं।

4. कैश और प्रॉक्सी को संभालें

कैश हिट मूल एप्लिकेशन शेड्यूलिंग तक पहुंचे बिना वापस आ सकता है। प्राथमिकता के प्रभावों को ट्रांसमिशन और कैश-फिल चरणों में रखें; एक सामान्य Priority हेडर को ऑब्जेक्ट ऑथराइजेशन को नहीं बदलना चाहिए या चुपचाप कैश की नहीं बनना चाहिए। एक प्रॉक्सी क्लाइंट कनेक्शन्स को संयोजित कर सकता है, विभिन्न बैकएंड कनेक्शन्स का उपयोग कर सकता है, या रिस्पॉन्स प्राथमिकता को रीराइट कर सकता है। प्रत्येक सीमा पर मूल मान, अंतिम मान और कारण रिकॉर्ड करें। कैश व्यवहार Cache-Control और Vary जैसे फ़ील्ड्स द्वारा नियंत्रित रहता है।

5. रीट्रांसमिशन और निष्पक्षता को संभालें

QUIC और TCP खोए हुए डेटा को फिर से ट्रांसमिट करते हैं। एक उच्च-urgency वाले नए ऑब्जेक्ट को स्वचालित रूप से कम-urgency वाले रीट्रांसमिशन से आगे नहीं निकलना चाहिए, क्योंकि रीट्रांसमिशन पहले से चल रहे रिस्पॉन्स को अनब्लॉक कर सकता है। RFC 9218 इस ट्रेड-ऑफ़ को ट्रांसपोर्ट और एप्लिकेशन पॉलिसी पर छोड़ता है। कनेक्शन्स के पार, एक कनेक्शन पर u=0 उच्चतम वैश्विक बैंडविड्थ की गारंटी नहीं दे सकता है। प्रति-कनेक्शन कोटा, एजिंग और अधिकतम लगातार सेंड बजट जोड़ें ताकि बैकग्राउंड का काम हमेशा के लिए स्टार्व न हो।

6. प्राथमिकता के दुरुपयोग और प्रसार त्रुटियों को रोकें

एक क्लाइंट प्रत्येक अनुरोध को u=0 लेबल कर सकता है, इसलिए सर्वर को रिसोर्स अनुमति सूची (allowlists), प्रमाणित पहचान, पेज चरण और इतिहास का उपयोग करके इसे ठीक करना चाहिए। अधिकतम urgency को सीमित करें, टेनेंट कोटा लागू करें, अज्ञात रिसोर्सेज़ के लिए डिफ़ॉल्ट पर वापस आएं, और ओवरराइड्स को रिकॉर्ड करें। प्रॉक्सी में, स्ट्रिंग्स को अंधाधुंध कॉपी करने के बजाय अर्थ को संरक्षित करें। एक हॉप जो सिग्नल को नहीं समझता है, उसे रिस्पॉन्स की शुद्धता को बदले बिना सुरक्षित रूप से इसे अनदेखा करना चाहिए।

7. कैनरी, फ़ॉलबैक और स्वीकृति

एक निश्चित पेज और कम जोखिम वाले CDN नोड्स से शुरुआत करें, कनेक्शन्स के एक अंश के लिए सर्वर रीराइटिंग को सक्षम करें। समान नेटवर्क, डिवाइस, कैश स्थिति और रिसोर्स सेट की तुलना करें। LCP, क्रिटिकल CSS कंप्लीशन, फ़ॉन्ट-ब्लॉकिंग समय, बैकग्राउंड p95 और p99, पहले बाइट का समय, डुप्लिकेट डाउनलोड, कनेक्शन उपयोग और अधिकतम लो-प्रायोरिटी प्रतीक्षा को मापें। सुधारों को त्रुटियों, बैंडविड्थ लागत और क्रॉस-टेनेंट निष्पक्षता के विरुद्ध तौला जाना चाहिए। शेड्यूलर का व्यवहार असामान्य होने पर तुरंत डिफ़ॉल्ट प्राथमिकताओं को पुनर्स्थापित करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं फ़र्स्ट-पेंट कंप्लीशन और बैकग्राउंड-रिक्वेस्ट लक्ष्यों को परिभाषित करूँगा, फिर HTML, रेंडर-ब्लॉकिंग CSS, फ़ॉन्ट्स, इनक्रीमेंटल मीडिया और बैकग्राउंड डेटा को वर्गीकृत करूँगा। क्लाइंट Priority हेडर केवल एक संकेत है। मैं रिसोर्स अनुमति सूची, पेज चरण, कैश स्थिति और टेनेंट कोटा का उपयोग करके इसे सही करूँगा: डिफ़ॉल्ट के रूप में urgency 3 का उपयोग करें, महत्वपूर्ण रिसोर्सेज़ के लिए मान कम करें, बैकग्राउंड कार्य के लिए इसे बढ़ाएं, और incremental का उपयोग केवल तभी करें जब उपभोक्ता आंशिक डेटा को प्रोसेस कर सके।

HTTP/1.1 ज्यादातर कनेक्शन और कतार क्रम पर निर्भर करता है। HTTP/2 और HTTP/3 एक मल्टीप्लेक्स्ड शेड्यूलर और वैकल्पिक री-प्रायोरिटाइजेशन फ़्रेम का उपयोग करते हैं। कैश हिट्स को ऑथराइजेशन या कैश कीज़ को नहीं बदलना चाहिए, और प्रॉक्सी को मूल और अंतिम प्राथमिकताओं को रिकॉर्ड करना चाहिए। रीट्रांसमिशन नए डेटा से स्वचालित रूप से नहीं हार सकता, इसलिए मैं कनेक्शन कोटा, एजिंग और लगातार सेंड कैप जोड़ूँगा। एक कैनरी LCP, क्रिटिकल कंप्लीशन, बैकग्राउंड टेल्स, बैंडविड्थ और लो-प्रायोरिटी प्रतीक्षा की तुलना करता है; खराब होते गार्डरेल्स सर्वर रीराइटिंग को अक्षम कर देते हैं।

सामान्य गलतियाँ

• Priority: u=0 को कंप्लीशन SLA मानना → कंजेशन, कैश स्थिति और रीट्रांसमिशन अभी भी मायने रखते हैं → मापने योग्य लक्ष्यों के साथ शेड्यूलर इनपुट के रूप में इसका उपयोग करें।
• incremental को "तेज़ी से समाप्त होता है" मानना → बैंडविड्थ साझा करने से प्रत्येक ऑब्जेक्ट के पूरा होने में देरी हो सकती है → इसका उपयोग केवल तभी करें जब आंशिक उपभोग का महत्व हो।
• क्लाइंट प्राथमिकता को कैश कीज़ या ऑथराइजेशन बदलने देना → कैश फ़्रेग्मेंटेशन या विशेषाधिकार संबंधी गलतियाँ होती हैं → कैश और अनुमति अनुबंधों को स्वतंत्र रखें।
• केवल एक HTTP/2 कनेक्शन का विश्लेषण करना → क्रॉस-कनेक्शन प्रतिस्पर्धा परिणामों को उलट सकती है → कनेक्शन, नोड, नेटवर्क और टेनेंट द्वारा वैलिडेशन को विभाजित करें।
• हाई-प्रायोरिटी रीट्रांसमिशन को हमेशा अन्य डेटा से आगे रहने देना → नए रिस्पॉन्स या बैकग्राउंड स्ट्रीम्स स्टार्व हो सकते हैं → रीट्रांसमिशन नीति, कोटा और एजिंग शामिल करें।
• केवल LCP पर ध्यान देना → बैकग्राउंड टेल्स और बैंडविड्थ लागत खराब हो सकती है → यूज़र, विश्वसनीयता, निष्पक्षता और लागत गार्डरेल्स एक साथ सेट करें।

फॉलो-अप्स और प्रतिक्रियाएं

क्या होगा यदि प्रत्येक क्लाइंट u=0 भेजता है?

इसे एक अविश्वसनीय संकेत के रूप में मानें। रिसोर्स प्रकार, पेज चरण, प्रमाणित पहचान और टेनेंट कोटा का उपयोग करके पुनर्गणना करें; असामान्य या अज्ञात अनुरोधों को डिफ़ॉल्ट पर लौटाएं और रिकॉर्ड करें कि उन्हें क्यों ओवरराइड किया गया था।

क्या incremental हमेशा अनुभव को बेहतर बनाता है?

नहीं। यह समान-urgency वाले रिस्पॉन्स के बीच बैंडविड्थ साझा करता है, जिससे कई पहले शुरू हो जाते हैं जबकि प्रत्येक बाद में समाप्त हो सकता है। इसका उपयोग तब करें जब उपभोक्ता आंशिक बाइट्स को प्रोसेस कर सके और वह स्टार्ट-टाइम लाभ मायने रखता हो।

क्या कैश हिट के लिए Priority आवश्यक है?

एक हिट आमतौर पर मूल एप्लिकेशन कतारों को बायपास करता है, लेकिन एक प्रॉक्सी अभी भी एक कनेक्शन पर ट्रांसमिशन शेड्यूल कर सकता है। Priority को ऑथराइजेशन में प्रवेश नहीं करना चाहिए या मनमाने ढंग से कैश की को नहीं बदलना चाहिए; हिट, फिल और सेंड चरणों को अलग से देखें।

क्या नुकसान के बाद रीट्रांसमिशन या उच्च-urgency वाले नए डेटा को पहले जाना चाहिए?

इसका कोई संदर्भ-मुक्त उत्तर नहीं है। रीट्रांसमिशन प्रगति पर चल रहे रिस्पॉन्स को अनब्लॉक कर सकता है, जबकि नया डेटा यूज़र के लिए अधिक महत्वपूर्ण हो सकता है। स्ट्रीम निर्भरता, इनक्रीमेंटल क्षमता, कंजेशन स्थिति और एक मापने योग्य अनुभव उद्देश्य को संयोजित करें।

क्या HTTP/1.1 समान प्राथमिकता लागू कर सकता है?

इसमें HTTP/2 के मल्टीप्लेक्स्ड प्राथमिकता ट्री का अभाव है। सर्वर कतारें, कनेक्शन समवर्तीता और रिसोर्स ऑर्डरिंग एक नीति का अनुमान लगा सकते हैं, लेकिन यह एक कार्यान्वयन रणनीति बनी हुई है जिसे हेड-ऑफ़-लाइन ब्लॉकिंग और कनेक्शन प्रतिस्पर्धा के लिए परीक्षण किया जाना चाहिए।

आप कैसे साबित करते हैं कि कम प्राथमिकता वाले काम को स्टार्वेशन नहीं हुआ है?

प्रत्येक अनुरोध के लिए कतार और प्रथम-भेजने का समय रिकॉर्ड करें, फिर रिसोर्स, कनेक्शन और टेनेंट द्वारा अधिकतम प्रतीक्षा और p99 की गणना करें। निरंतर उच्च-urgency लोड के तहत, सत्यापित करें कि एजिंग, कोटा या समय सीमाएं अभी भी कम प्राथमिकता वाले काम को सेवा प्राप्त करने की अनुमति देती हैं।