स्ट्रीमिंग प्रदर्शन केवल एक वीडियो-प्लेयर की चिंता नहीं है। सॉफ़्टवेयर अवशेष, मॉडल वज़न, बैकअप, ऑडियो लाइब्रेरी और बड़े API निर्यात सभी उन्हीं मूलभूत सिद्धांतों पर निर्भर करते हैं: बाइट्स को तेजी से स्थानांतरित करें, सही पेलोड बनाए रखें, बैकप्रेशर का सम्मान करें, और जब एक क्लाइंट डिस्कनेक्ट हो जाए तो साफ़-सुथरा रुकें।
Webship उन आवश्यकताओं को HTTP/1.1, HTTP/2, HTTP/3, सीधे फ़ाइल वितरण, रिवर्स प्रॉक्सी, और WebTransport के माध्यम से एक परिवहन समस्या के रूप में मानता है। तेज़ पथ केवल तब उपयोगी होता है जब यह फ़्रेमिंग, रद्दीकरण, ट्रेलर, सुरक्षा निरीक्षण, और सीमित स्मृति को बनाए रखता है।
100 एमबी स्ट्रीमिंग क्षमता मापी गई
Webship 1.3.1 डेबियन क्षमता रन को 100 MB फिक्स्चर के साथ मापा गया माध्य पेलोड थ्रूपुट। हर स्वीकार किया गया नमूना सटीक 99,943,778-बाइट प्रतिक्रिया बॉडी और शून्य ग्राहक, प्रोटोकॉल, प्रॉक्सी, मुख्य-पृष्ठ-दोष, और HTTP/3 पैकेट-हानि त्रुटियों की आवश्यकता थी।
| Webship मोड | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | सीधे फ़ाइल वितरण | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | टीएलएस टर्मिनेशन के साथ रिवर्स प्रॉक्सी | 3,585.7 मीबाई/से | 3,355.0 मीबाई/से | 1,938.6 मीबाई/से | | टीएलएस पास-थ्रू के साथ रिवर्स प्रॉक्सी | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
रिकॉर्ड की गई तुलना में, Webship ने हर मापी गई प्रोटोकॉल के लिए उच्चतम डायरेक्ट और TLS-terminated माध्यांक उत्पन्न किया। पूर्ण मैट्रिक्स में Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, और Bun [बेंचमार्क पृष्ठ](/benchmarks) पर शामिल हैं।
ये संख्याएँ बेंचमार्क होस्ट पर क्षमता को मापती हैं। वे किसी भी मनमाने इंटरनेट पथ के लिए कोई वादा नहीं हैं। भंडारण विलंब समय, नेटवर्क बैंडविड्थ, राउंड-ट्रिप समय, पैकेट हानि, TLS नीति, समानांतरता, और मूल व्यवहार अभी भी वास्तविक डिलीवरी गति को निर्धारित करते हैं।
एक बाइनरी, तीन परिवहन रणनीतियाँ
एक बड़े उत्तर को छोटे HTML दस्तावेज़ जैसी नीति से लाभ नहीं होता। Webship सामान्य अनुरोध पथ को सुरक्षित रखता है और केवल प्रमाणित बड़े उत्तर को प्रोत्साहित करता है।
HTTP/1.1: फ़ाइल के चारों ओर कम संक्रमण
लिनक्स पर, Webship रिस्पॉन्स हेड और फ़ाइल पेलोड को एक सर्वश्रेष्ठ प्रयास TCP कॉर्क इंटरवल के अंदर रखता है। एक बार जब एक बड़ा TLS रिस्पॉन्स बल्क पाथ के लिए योग्य हो जाता है, तो डायरेक्ट फ़ाइल डिलीवरी Rustls रिकॉर्ड्स से ऑडिटेड वन-वे कर्नेल TLS में स्थानांतरित हो सकती है और एप्लिकेशन बफ़र के माध्यम से पेलोड को कॉपी किए बिना sendfile का उपयोग कर सकती है।
कनेक्शन अभी भी यूज़रस्पेस TLS में शुरू होता है। छोटे उत्तर वहीं रहते हैं। Webship kTLS संक्रमण केवल तब अनुरोधित करता है जब कम से कम 1 MiB के उत्तर शरीर से यह साबित हो कि कनेक्शन थोक डेटा ले जा रहा है।
HTTP/2: फ्लो कंट्रोल को तोड़े बिना बैचिंग
HTTP/2 मल्टिप्लेक्सिंग अनियंत्रित बफरिंग को महंगा बनाता है। Webship स्ट्रीम और कनेक्शन फ्लो-कंट्रोल सीमाओं को बनाए रखते हुए लेखन को बैच करता है। उच्च-सहसंयोजन स्ट्रीमिंग के लिए, 128 KiB TLS write बफर दो 64 KiB DATA फ्रेम रख सकता है, जबकि कनेक्शन भेजने का बजट स्पष्ट और सीमित रहता है।
एक पहले से तैयार अपस्ट्रीम बॉडी फ्रेम को हाइपर फ्रेमिंग, ट्रेलरों, रद्दीकरण, निरीक्षण, या बैकप्रेशर को बायपास किए बिना प्रीफेच किया जा सकता है। इससे अवॉयडेबल शेड्यूलर राउंड कम हो जाता है जबकि प्रोटोकॉल अनुबंध को अक्षुण्ण रखा जाता है।
HTTP/3: kTLS के बजाय QUIC पेसींग
HTTP/3 कभी भी TCP kTLS पथ का उपयोग नहीं करता। Webship ट्रांसपोर्ट-सचेत QUIC पैसिंग, सीमित डाटाग्राम पैकेटाइजेशन, DPLPMTUD, और प्रति-रीएक्टर टाइमर-चालित माइक्रोबैचिंग लागू करता है। बड़े HTTP/3 प्रतिक्रिया और स्वीकार किए गए WebTransport सत्र BBR का चयन कर सकते हैं बिना सामान्य ट्रैफ़िक द्वारा उपयोग की जाने वाली CUBIC नीति को बदले।
केंद्रित HTTP/3 स्थिरता योग्यता में सात स्वीकृत नमूनों का उपयोग किया गया। TLS-समाप्त स्ट्रीमिंग ने 2.12% परिवर्तन गुणांक के साथ 1,938.6 MiB/सेकंड का माध्य उपलब्ध कराया। TLS पास-थ्रू ने 1,748.5 MiB/सेकंड 1.65% परिवर्तन गुणांक के साथ प्रदान किया। दोनों श्रृंखलाओं में शारीरिक अखंडता, क्लाइंट, प्रोटोकॉल, और पैकेट-हानि त्रुटियां शून्य थीं।
सीधी डिलीवरी या रिवर्स प्रॉक्सी?
जब Webship तैनात फ़ाइल ट्री का मालिक हो तो सीधे डिलीवरी का उपयोग करें। यह मूल हॉप को हटा देता है और सबसे कुशल स्थैतिक-फ़ाइल पथ सक्षम करता है।
एक न्यूनतम बहु-प्रोटोकॉल साइट इस प्रकार दिखती है:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"जब Webship को पथ द्वारा रूट करना हो, WAF या API शील्ड जांच लागू करनी हो, बॉडी लिमिट लागू करनी हो, फॉरवर्डिंग हेडर जोड़ने हों, या HTTP फील्ड का अवलोकन करना हो, तब रिवर्स-प्रॉक्सी TLS टर्मिनेशन का उपयोग करें:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]जब मूल को एप्लिकेशन के प्लेनटेक्स्ट और सक्रिय सत्र कुंजियों को बनाए रखना हो तो tls_termination = false सेट करें। पास-थ्रू एन्क्रिप्टेड HTTP फ़ील्ड को निरीक्षण नहीं कर सकता। इसलिए TCP पास-थ्रू ClientHello SNI द्वारा मार्गदर्शित करता है, जबकि HTTP/3 पास-थ्रू के लिए एक साझा UDP मूल की आवश्यकता होती है।
तुमने बल्क स्ट्रीमिंग को स्पष्ट रूप से ट्यून किया
उच्च-संकर्षण HTTP/2 TLS स्ट्रीमिंग के लिए, Webship इन प्रक्रिया-बंधन सेटिंग्स का दस्तावेजीकरण करता है:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"ऊपर किया गया कनेक्शन बजट 256 सक्रिय स्ट्रीम के लिए 128 KiB का क्रेडिट प्रदान करता है। इसे एक क्षमता निर्णय के रूप में मानें, सार्वभौमिक डिफ़ॉल्ट के रूप में नहीं। इसे बढ़ाने से पहले अपनी उम्मीद की गई समानांतरता के साथ मेमोरी, विलंबता और थ्रूपुट को मापें।
लिनक्स पर, कर्नेल TLS और BBR मॉड्यूल लोड करें और Webship सेवा खाते को BBR चुनने की अनुमति दें। Webship तब विफल हो जाता है जब इसका आवश्यक कर्नेल कैपेबिलिटी उपलब्ध नहीं होता, इसलिए एक डिप्लॉयमेंट बिना इसके चलते हुए अनजाने में ऑप्टिमाइज़्ड पथ का दावा नहीं कर सकता। अन्य ऑपरेटिंग सिस्टम अपने प्लेटफ़ॉर्म के लिए दस्तावेजीकृत पोर्टेबल Rustls और कंजेशन-कंट्रोल पथ बनाए रखते हैं।
WebTransport एक अलग स्ट्रीमिंग आकार है
WebTransport सुरक्षित सत्र के माध्यम से विश्वसनीय स्ट्रीम और अविश्वसनीय डाटाग्राम को संयोजित करता है। यह TCP kTLS का उपयोग नहीं करता है। Webship का बंधित डायग्नोस्टिक एंडपॉइंट मूलों को मान्य करता है और सत्र, स्ट्रीम, कैप्सूल, डाटाग्राम, बाइट और निष्क्रिय समय की सीमाओं को लागू करता है।
1.3.1 क्षमता रन में, डायरेक्ट WebTransport भरोसेमंद स्ट्रीम के लिए 1,018.1 MiB/s और डाटाग्राम के लिए 1,038.9 MiB/s तक पहुंचा। TLS पास-थ्रू क्रमशः 548.6 MiB/s और 629.7 MiB/s तक पहुंचा। दोनों मोड्स ने सभी पांच नमूनों को शून्य अस्वीकृत नमूनों, शून्य खोए हुए डाटाग्राम, और शून्य क्लाइंट मेजर फॉल्ट्स के साथ पास कर दिया।
नए WebTransport क्लाइंट्स के लिए HTTP/3 को प्राथमिकता दें। पुरानी एक्सपायर्ड-ड्राफ्ट सेटिंग्स के साथ संगतता के लिए HTTP/2 पथ मौजूद है।
उत्पादन ट्रैफ़िक से पहले क्या जांचना है
- सिर्फ एक छोटी कृत्रिम प्रतिक्रिया नहीं, बल्कि जिस मीडिया या आर्टिफैक्ट के आकार आप परोसेंगे उसका सटीक परीक्षण करें।
- सर्वर पर प्रतिक्रिया की लंबाई और सामग्री सार जांचें।
- व्यायाम रद्द करना, सीमा अनुरोध, धीमे पाठक, और मूल आंशिक-संपन्न व्यवहार।
- CPU, मेमोरी, सॉकेट त्रुटियों, पुनःप्रेषण, और टेल लेटेंसी के साथ लगातार थ्रूपुट को मापें।
- प्रत्यक्ष, TLS-समाप्त और पास-थ्रू मोड को अलग-अलग सत्यापित करें; उनके सुरक्षा और रूटिंग सीमाएँ अलग-अलग हैं।
- सामान्य प्रोडक्शन ट्रैफिक के लिए इंस्ट्रूमेंटेशन को बंद रखें, फिर जांच करते समय सीमित डायग्नोस्टिक्स को जानबूझकर सक्षम करें।
- कर्नेल, कंटेनर, या systemd सैंडबॉक्स में बदलाव के बाद Linux kTLS और BBR प्रीफ्लाइट को पुनः जाँचें।
जब पूरे मार्ग का सहयोग किया जाए तो स्ट्रीमिंग तेज़ होती है। Webship का डिज़ाइन थोक-डेटा अनुकूलन को प्रोटोकॉल-विशिष्ट रखता है जबकि एक संचालन मॉडल और एक सटीकता मान बनाए रखता है।
पूरा [Webship 1.3.1 दस्तावेज़](/docs/1.3.1) पढ़ें, [बेंचमार्क पद्धति और प्रतिस्पर्धी मैट्रिक्स](/benchmarks) की जांच करें, या [डाउनलोड](/downloads) से हस्ताक्षरित बिल्ड डाउनलोड करें।