जीआरपीसी के डायल विकल्प। चूँकि gRPC नीचे HTTP/2 का उपयोग करता है, इसलिए मैंने इस लेख को ऊपर उठाया, जो वर्णन करता है:

प्रवाह नियंत्रण विंडो केवल एक पूर्णांक मान से अधिक कुछ नहीं है जो रिसीवर की बफरिंग क्षमता को दर्शाता है। प्रत्येक प्रेषक प्रत्येक स्ट्रीम और समग्र कनेक्शन के लिए एक अलग प्रवाह नियंत्रण विंडो रखता है।

यदि यह विंडो आकार जीआरपीसी के बारे में बात कर रहा है और मैं इसे सही ढंग से समझता हूं। यह HTTP / 2 के लिए एक ही कनेक्शन के भीतर कई समवर्ती स्ट्रीम बनाए रखने के लिए है। मूल रूप से एक संख्या जो प्रेषक को विज्ञापित की जाती है कि रिसीवर कितना डेटा चाहता है कि प्रेषक आगे भेजे। नियंत्रण प्रवाह कारणों से, कनेक्शन अलग-अलग स्ट्रीम के डेटा को सीरियल में अलग-अलग विंडो के बीच रखता है।

मेरा प्रश्न है/हैं: क्या खिड़की सब कुछ है या कुछ भी नहीं? मतलब अगर मेरी विंडो का आकार n बाइट्स है, तो स्ट्रीम कम से कम n बाइट्स जमा होने तक कोई डेटा नहीं भेजेगी? अधिक सामान्यतः, यदि मैं केवल एक स्ट्रीम बनाए रखता हूं, तो मैं अपनी स्ट्रीम के प्रदर्शन को अधिकतम कैसे कर सकता हूं? मुझे लगता है कि एक बड़ा विंडो आकार ओवरहेड्स से बचने में मदद करेगा लेकिन डेटा हानि के जोखिम में वृद्धि करेगा?

1
bli00 14 नवम्बर 2020, 01:22

1 उत्तर

सबसे बढ़िया उत्तर

मतलब अगर मेरी विंडो का आकार n बाइट्स है, तो स्ट्रीम कम से कम n बाइट्स जमा होने तक कोई डेटा नहीं भेजेगी?

नहीं। प्रेषक n से कम या उसके बराबर बाइट भेज सकता है।

आम तौर पर, अगर मैं केवल एक स्ट्रीम बनाए रखता हूं तो मैं अपनी स्ट्रीम के प्रदर्शन को अधिकतम कैसे कर सकता हूं?

केवल एक स्ट्रीम के लिए, अधिकतम संभव मान 2^31-1 का उपयोग करें।
इसके अलावा, आप जल्द ही WINDOW_UPDATE फ्रेम भेजने के लिए रिसीवर को कॉन्फ़िगर करना चाहते हैं, ताकि प्रेषक के पास हमेशा एक बड़ी पर्याप्त प्रवाह नियंत्रण विंडो हो जो इसे कभी भी भेजना बंद न करे।

ध्यान देने वाली एक महत्वपूर्ण बात यह है कि मैक्स फ्लो कंट्रोल विंडो का विन्यास रिसीवर की मेमोरी क्षमता से संबंधित है।

चूंकि HTTP/2 बहुसंकेतन है, इसलिए कार्यान्वयन को तब तक डेटा पढ़ना जारी रखना चाहिए जब तक कि प्रवाह नियंत्रण विंडो समाप्त न हो जाए।
अधिकतम प्रवाह नियंत्रण विंडो, 2 GiB का उपयोग करने का अर्थ है कि रिसीवर को कम से कम 2 GiB डेटा तक बफर करने के लिए तैयार रहने की आवश्यकता है, जब तक कि एप्लिकेशन उस डेटा का उपभोग करने का निर्णय नहीं लेता है।

दूसरे शब्दों में: कार्यान्वयन द्वारा नेटवर्क से डेटा पढ़ना, और एप्लिकेशन द्वारा उस डेटा का उपभोग अलग-अलग गति से हो सकता है; यदि पढ़ना खपत से तेज है, तो कार्यान्वयन को डेटा को पढ़ना चाहिए और इसे तब तक जमा करना चाहिए जब तक कि एप्लिकेशन इसका उपभोग न कर सके।

जब एप्लिकेशन डेटा की खपत करता है, तो यह कार्यान्वयन को बताता है कि कितने बाइट्स की खपत हुई थी, और कार्यान्वयन प्रेषक को WINDOW_UPDATE फ्रेम भेज सकता है, प्रवाह नियंत्रण विंडो को फिर से बड़ा करने के लिए, ताकि प्रेषक भेजना जारी रख सके।

ध्यान दें कि कार्यान्वयन वास्तव में बैकप्रेशर लागू करना चाहते हैं, यानी प्रेषक को WINDOW_UPDATEs वापस भेजने से पहले डेटा का उपभोग करने के लिए एप्लिकेशन की प्रतीक्षा करें।
यदि कार्यान्वयन (गलत तरीके से) एप्लिकेशन को पास करने से पहले डेटा की खपत को स्वीकार करता है, तो यह मेमोरी ब्लो-अप के लिए खुला है, क्योंकि प्रेषक भेजना जारी रखेगा, लेकिन रिसीवर को इसे एक तरफ जमा करने के लिए मजबूर किया जाता है जब तक कि होस्ट मेमोरी रिसीवर समाप्त हो गया है (यह मानते हुए कि नेटवर्क से डेटा पढ़ने के लिए कार्यान्वयन की तुलना में डेटा का उपभोग करने के लिए एप्लिकेशन धीमा है)।

उपरोक्त को देखते हुए, अधिकतम प्रवाह नियंत्रण विंडो के लिए एकल कनेक्शन के लिए 2 GiB तक मेमोरी की आवश्यकता हो सकती है। १०२४ कनेक्शनों की कल्पना करें (एक सर्वर के लिए इतने अधिक नहीं), और आपको २ टीआईबी मेमोरी की आवश्यकता है।

यह भी विचार करें कि इतनी बड़ी प्रवाह नियंत्रण विंडो के लिए, प्रवाह नियंत्रण विंडो समाप्त होने से पहले आप TCP भीड़ (हेड ऑफ़ लाइन ब्लॉकिंग) से टकरा सकते हैं।
यदि ऐसा होता है, तो आप मूल रूप से टीसीपी कनेक्शन क्षमता पर वापस आ गए हैं, जिसका अर्थ है कि HTTP / 2 प्रवाह नियंत्रण सीमाएं कभी भी ट्रिगर नहीं होती हैं क्योंकि टीसीपी सीमाएं पहले ट्रिगर होती हैं (या आप अन्यथा बैंडविड्थ द्वारा सीमित हैं, आदि)।

एक और विचार यह है कि आप इससे बचना चाहते हैं कि प्रेषक प्रवाह नियंत्रण विंडो को समाप्त कर देता है और इसलिए उसे रोकना और भेजना बंद करना पड़ता है।

1 MiB की फ्लो कंट्रोल विंडो के लिए, आप 1 MiB डेटा प्राप्त नहीं करना चाहते हैं, इसका उपभोग करें और फिर 1 MiB का WINDOW_UPDATE वापस भेजें, क्योंकि अन्यथा क्लाइंट 1 MiB, स्टॉल, प्राप्त करेगा। WINDOW_UPDATE, एक और 1 MiB भेजें, फिर से स्टाल करें, आदि (यह भी देखें अपलोड करते समय मल्टीप्लेक्सिंग http2 सुविधा का उपयोग कैसे करें)।

ऐतिहासिक रूप से, छोटे प्रवाह नियंत्रण विंडो (जैसा कि 64 KiB के विनिर्देश में सुझाया गया है) ब्राउज़रों में सुपर-धीमे डाउनलोड का कारण बन रहे थे, जिससे उन्हें जल्दी से एहसास हुआ कि उन्हें सर्वरों को यह बताने की आवश्यकता है कि उनकी प्रवाह नियंत्रण विंडो काफी बड़ी थी ताकि सर्वर नहीं होगा डाउनलोड को रोकें। फिलहाल, फायरफॉक्स और क्रोम ने इसे 16 एमआईबी पर सेट किया है।

आप प्रेषक को WINDOW_UPDATEs खिलाना चाहते हैं ताकि वह कभी रुके नहीं।

यह एक संयोजन है कि एप्लिकेशन कितनी तेजी से प्राप्त डेटा का उपभोग करता है, आप WINDOW_UPDATE भेजने से पहले खपत बाइट्स की संख्या को कितना "संचित" करना चाहते हैं (WINDOW_UPDATE बहुत बार भेजने से बचने के लिए), और कैसे WINDOW_UPDATE को प्राप्तकर्ता से प्रेषक तक पहुंचने में काफी समय लगता है।

1
sbordet 18 नवम्बर 2020, 09:09