मैं वेब अनुप्रयोगों को निर्मित कर रहा हूँ जब से.

यह एक प्रोटोकॉल ट्युटोरियल नहीं है।

अविश्वसनीय पाइपों पर HTTP/1.0: राज्यहीन पाठ

वह दुनिया जो इसे बनाती है

एचटीपीटी0 एक ऐसी दुनिया के लिए तैयार किया गया था जो अब अस्तित्व में नहीं है।

• डायलप कनेक्शन पर 28.8kbps
• पृष्ठ दस्तावेज थे - पाठ
• उपयोक्ताओं ने क्लिक किया और प्रतीक्षा की - तत्काल प्रतिक्रिया नहीं थी
• सर्वर महंगे थे विश्वविद्यालयों और कंपनियों

इस दुनिया में एमएसके0 bottleneck था बैंडविड्थएक 50KB पृष्ठ को डायलॉप पर डाउनलोड करने के लिए 15 सेकंड लग गया।

क्या HTTP/1.0 के लिए अनुकूलित किया गया है

• सरलता (टेलनेट के साथ डिबगैबल है
• राज्यहीनता (सर्वर नहीं करता है
• मानव-पाठ्यता (पाठ प्रोटोकॉल
• एक अनुरोध, एक प्रतिक्रिया, कनेक्शन बंद

GET /index.html HTTP/1.0
Host: example.com

HTTP/1.0 200 OK
Content-Type: text/html

<html>...

सरल. Elegant. | | 1996. के लिए उपयुक्त और दस्तावेज पुनःप्राप्ति से परे किसी भी वस्तु के लिए पूरी तरह अनुपयोगी

उस दबाव ने उसे तोड़ दिया

तब वेब बदल गया

द्वारा 1998, पृष्ठ केवल दस्तावेज़ नहीं थे।

प्रत्येक एकल अनुरोध की आवश्यकता

1. टीसीपी हैंडशेक आरटीटी
2. निवेदन/पहली बाइट आरटीटी
3. प्राप्त प्रतिक्रिया
4. कनेक्शन बंद
5. प्रत्येक छवि के लिए दोहराएँ

संसाधनों के साथ एक पृष्ठ का अर्थ था 20 टीसीपी हैंडशेक सिर्फ हाथ हिलाना किसी भी अंतरित सामग्री से पहले

एचटीटीपी के आधारभूत आकलन

समय सस्ता था

1996, में यह था. बैंडविड्थ bottleneck था . By \1999, बैण्डविड्ण्ड सुधार कर रहा था लेकिन लंबितता थी और अचानक उन दौरों का महत्व था

HTTP को दस्तावेजों के लिए तैयार किया गया था

एचटीटीपी

वह दुनिया जो इसे बनाती है

HTTP /1.1 वेब के विस्फोट के साथ ही 1997, में आ गया था। . dotcom उछाल शुरू हो रहा था।

दबाव स्पष्ट था कनेक्शन. लेकिन पूरी तरह से एचटीटीपी को पुनः डिजाइन करना एक विकल्प नहीं था

क्या बदल गया

• स्थायी कनेक्शन (Connection: keep-alive डिफ़ॉल्ट से) - टीसीपी कनेक्शन का पुनः उपयोग करें
• संकुचित अंतरण एनकोडिंग (stream प्रतिक्रियाओं बिना आकार जानने के पहले
• होस्ट हेडर (वर्चुअल होस्टिंग
• कैशिंग अर्थशास्त्र (Cache-Control, ETagशर्तात्मक अनुरोध
• पिपलीनिंग बिना प्रतिक्रियाओं की प्रतीक्षा के बहुविध अनुरोध भेजें

क्या नहीं बदला

• अभी भी अनुक्रमिक प्रतिक्रियाएँ (पीपलाइनिंग के साथ भी
• अभी भी पाठ हेडर (प्रत्येक अनुरोध पर दोहराया जाता है
• प्रति कनेक्शन में एक बार भी एक प्रतिक्रिया

GET /page.html HTTP/1.1
Host: example.com
Connection: keep-alive

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: max-age=3600

...

क्यों यह क्रमबद्ध करता है

HTTP/1.1 वास्तव में निष्पादन समस्या को हल नहीं करता है

पाइपलाइनिंग एक असफलता थी एक कनेक्शन पर कई अनुरोध भेजने की अनुमति प्रदान करता है

• प्रतिक्रियाओं को वापस आना था क्रमबद्ध (
• एक slow response blocked everything behind it
• बुगि प्रॉक्सी ने पाइपलाइन के अनुरोधों को खंडित किया
• अधिकांश ब्राउज़र इसे पूरी तरह से अक्षम कर देते हैं

तो ब्राउज़रों ने धोखा दिया

• खोलें प्रति होस्ट समांतर कनेक्शन 6 ब्राउज़र सीमा
• उपयोग करें डोमेन शैडिंग (static1.example.com, static2.example.comकनेक्शनों को गुणा करने के लिए )
• स्प्रिट शीट छवियों को जोड़ने के लिए
• CSS/JS बंडलिंग अनुरोधों को कम करने के लिए
• सीडीएन विलंब को कम करने के लिए

इनमें से कोई भी प्रोटोकॉल डिजाइन के रूप में काम करने वाला नहीं था

एचटीपी (HTTP)

क्यों यह फिर भी जीवित रहा?

HTTP/1.1 काम करता है पर्याप्त रूप से पंद्रह वर्षों के लिए

• ब्रॉडबैंड आ गया के बजाय हाथhakes 20ms
• Moore के कानून ने मदद की सर्वर एक ब्राउज़र पर छह कनेक्शनों को 2005. द्वारा संभाल सकते हैं
• सीडीएन्स ने समस्या को छिपाया किनारे सर्वर 20ms दूर के बजाय 200ms.
• डेस्कटॉप प्रधान तारी कनेक्शन

प्रोटोकॉल अभी भी टूटा था

वास्तविक लागत

प्रति होस्ट इन छह कनेक्शनों को मुक्त नहीं था

• प्रत्येक कनेक्शन का अर्थ था एक और TCP हाथhake
• प्रत्येक कनेक्शन बैंडविड्थ के लिए प्रतियोगिता
• सर्वरों को अधिक समवर्ती कनेक्शन बनाए रखना था
• शीर्ष-of-लाइन ब्लॉकिंग अभी TCP में खिसका है एक कनेक्शन पर पैकेट खोता है

एचटीटीपी के युग में वेब तेजी से बढ़ गया।

• नेटवर्क तेज हो गए
• कैचिंग स्मार्ट हो गया
• सीडीएनों का अवशोषित विलंब
• ब्राउज़र समांतरता में बेहतर हो गया

हम एक दस्तावेज पुनःप्राप्ति प्रोटोकॉल पर एक अनुप्रयोग प्लेटफार्म बना रहे थे

असुविधाजनक सत्य जिसे कोई स्वीकार नहीं करता

द्वारा 2010, वेब निष्पादन HTTP स्वयं के विरुद्ध एक निरंतर संघर्ष था

इस युग के सबसे अच्छे तरीके कहानी बताते हैं

• अपने सभी जावास्क्रिप्ट को एक फ़ाइल में सम्मिलित करें
• अपने सभी छवियों को एक साथ फैलाएँ
• इनलाइन क्रिटिकल सीएसएस
• अनुरोधों से बचने के लिए डेटा यूआरआई का उपयोग करें
• अधिक कनेक्शन खोलने के लिए डोमेन खार्ड
• स्क्रिप्ट पृष्ठ के नीचे रखें

इनमें से हर एक के लिए एक समाधान है

मैं स्प्रेट जेनेरेटर जैसे इन छोटे उपकरणों में से कई बना दिया।

ब्राउज़र HTTP सुधार के कारण अधिक तेजी से नहीं थे एचटीटीपी के आसपास काम किया.

प्रति होस्ट छह कनेक्शन एक विशेषता नहीं है

मैंने विकासकर्ताओं को आस्तियों को बांडल करने के लिए वर्षों तक सिखाया। प्रोटोकॉल हानि नियंत्रण.

"HTTP सरल है।

• ब्राउज़र कनेक्शन प्रबंधन
• सीडीएन किनारा तर्क
• औज़ार कंकाटेनेशन बनाएँ
• सर्वर कनेक्शन पूलिंग

HTTP/1.1 काम करता था क्योंकि सब कुछ चारों ओर मुआवज़े के लिए अधिक समय काम किया।

अगर आप HTTP के एक चित्र को कभी नहीं देखा है जो लैटेनसी दिखाता है

HTTP/2: हमने गलत परत को ठीक कर दिया

वह दुनिया जो इसे बनाती है

के द्वारा 2010, वेब फिर से रूपांतरित हो गया था

मोबाइल हुआ मोबाइल वेब ट्रैफिक विस्फोट कर रहा था। अचानक उपयोगकर्ता तारित ब्रॉडबैंड पर नहीं थे।

2. वेब अनुप्रयोगों के बदले वेब पृष्ठ जीमेल. गूगल मैप्स. फेसबूकM SK2 ट्विटर. ये बिना लिंक के दस्तावेज़ नहीं थे। यह ऐसे अनुप्रयोग थे जिन्हें दर्जनों या सैकड़ों संसाधनों की आवश्यकता थी।

गूगल ने इस पीड़ा को तीव्र रूप से महसूस किया।

SPDY

SPDY (pronounced

एसडीपीवाई ने क्या प्रस्तुत किया

• द्विआधारी फ्रेमिंग पाठ विश्लेषण के बजाय
• बहुplexed स्ट्रीम एक ही TCP कनेक्शन पर
• शीर्षिका संकुचन HTTP के लिए HPACK में परिष्कृत
• सर्वर push सक्रिय संसाधन वितरण के लिए
• स्ट्रीम प्राथमिकता निर्धारण महत्वपूर्ण संसाधनों को पहले लोड करने के लिए

गूगल ने Chrome और उनके अपने सेवाओं में SPDY को लागू किया।

के लिए पथ

SPDY ने सिद्ध किया कि सिद्धांत काम कर रहे हैं. IETF ने ध्यान दिया और HTTP के लिए आरंभ बिंदु के रूप में SPDY का प्रयोग किया।

गूगल ने SPDY को 2016 एक बार एचटीपीटी /2 पर्याप्त रूप से अपनाया गया था \ . \ मिशन पूरा हुआ : \ वे \ ' \ के द्वारा पहली बार जहाज़ भेजकर और बाद में मानकीकरण करके वेब को आगे लाने के लिए बाध्य किया

HTTP को क्या बदला है ( SPDY पर बनाना

• द्विआधारी फ्रेमिंग अधिक कुशल पद वर्णन
• बहुसंक्रमण (multiple requests/responses interleaved on one connection
• शीर्षिका संकुचन (HPACK
• सर्वर push स्रोतों को ग्राहक पूछने से पहले भेजें
• एकल कनेक्शन प्रति मूल अधिक कनेक्शन विस्फोट नहीं

┌──────────────────────────────────────────┐
│           Single TCP Connection          │
├──────────────────────────────────────────┤
│ Stream 1: GET /page.html                 │
│ Stream 3: GET /style.css                 │
│ Stream 5: GET /app.js                    │
│ Stream 7: GET /logo.png                  │
│ (all interleaved, no ordering required)  │
└──────────────────────────────────────────┘

यह है क्या HTTP पाईपलाइनिंग होना चाहिए था

सही नेटवर्क पर क्यों यह काम करता है

HTTP/2 था ब्रॉडबैंड वेब के लिए आदर्शऔर जब इसे मानक बनाया गया तो विकसित देशों में ब्रॉडबैंड ubiquitous था

क्या सुधारा गया

• हल्का लोड के तहत लटेनसी (एक कनेक्शन, एक अनुरोध पर ऊपरी हस्तचाप नहीं
• कम कनेक्शन (सेवल सर्वर ओवरहेड
• बेहतर बैंडविड्थ उपयोग (नहीं कृत्रिम कनेक्शन सीमाएं
• हेडर संकुचन (कुकी जैसे दोहरा हेडर अब लागत बैंडविड्थ नहीं है
• कोई और कनेक्टेनेशन नहीं है/spriting की जरूरत है ( बहुत से छोटे फ़ाइलें अब ठीक हैं

कम पैकेट हानि के साथ तारी कनेक्शन पर उपयोगकर्ताओं के लिए, HTTP/2 एक वास्तविक सुधार था।

उस दबाव ने उसे तोड़ दिया

लेकिन दुनिया पहले ही आगे बढ़ गई थी। मोबाइल अब वेब ट्रैफिक का बहुमत था

और मोबाइल नेटवर्क एक मूलभूत गुण है कि ब्रॉडबैंड नहीं पैकेट हानि आम और अप्रत्याशित है।.

टीसीपी गारंटी in-order deliveryयदि पैकेट 47 खो दिया जाता है तो

┌──────────────────────────────────────────┐
│              TCP Receive Buffer          │
├──────────────────────────────────────────┤
│ [pkt 45][pkt 46][  ?  ][pkt 48][pkt 49]  │
│                   ↑                       │
│         Waiting for packet 47             │
│                                          │
│ Stream 1 data: BLOCKED                   │
│ Stream 3 data: BLOCKED                   │
│ Stream 5 data: BLOCKED (has pkt 48-49)   │
│ Stream 7 data: BLOCKED                   │
└──────────────────────────────────────────┘

एचटीटीपी/2 समाधान शीर्ष-ofM SK2 अनुप्रयोग परत पर लाइन ब्लॉकिंग

एक खो गया पैकेट सभी धाराओं को रोकता है एक स्वच्छ तारी कनेक्शन पर पैकेट हानि दुर्लभ है एकल कनेक्शन (डिज़ाइन के अनुसार), एक खो गया पैकेट अब ब्लॉक्स सब कुछ सिर्फ छह कनेक्शनों में से एक के बजाय

निष्पादन

• तारित, कम हानि: Excellent
• मोबाइल, मध्यम हानिकभी-कभी बदतर HTTP से अधिक
• उच्च लाटेंसी, कोई नुकसान: विनाशकारी

व्यंग्यः एचटीटीपीः एमएसके1; वेबः एम्सके2; मल्टीप्लेक्सिंग समस्या को ठीक करने के लिए किया गया था।

क्यों HTTP/2 तेजी से चला गया (until it didn

आरंभिक HTTP déployments showed real improvements:

• कम कनेक्शन का अर्थ था तेजी से आरंभिक लोड (TLS एक बार हाथhake
• शीर्षिका संकुचन शीर्ष पर कम किया गया
• एक ही मूल पर आस्तियों के लिए मल्टीप्लेक्सिंग ने अच्छा काम किया

मैं उन सभी उपकरणों के लिए बना 1.1? HTTP के साथ सब गायब हो गया था/2,\ अचानक बंडिंग एक बुरी बात थी.\HTTP\ /2'\s बहुलकरण एक ही मूल पर आस्तियों के लिए बहुत अच्छा था,\ लेकिन यह नहीं था'\cross के साथ मदद नहीं करता है-\origin निवेदनों\msks7\ हम उन \mskg8\webpack को इस साइट पर बंड करने के लिए नए उपकरणों का निर्माण करना था उदाहरण के लिए\mskk9\

लेकिन पूंछ लंबवत एक अलग कहानी बताई मध्यस्थ बेहतर हो गया

मैंने अपने सीडीएन के माध्यम से HTTP को सक्षम एक क्लाइंट ने यह प्रत्यक्ष रूप से देखा और मोबाइल पी. एम. एस. सी. 2 की लंबितता को देखा बढ़ना द्वारा 40%. Dashboards ने डेस्कटॉप पर सुधार दिखाया।

जब एचटीटीपी कार्य करता है, तो यह सुंदर रूप से काम करता है. जब एक पैकेट सबसे खराब समय में मोबाइल कनेक्शन पर गिरता है, तब सब कुछ जम जाता है.

मूल समस्या

HTTP/2 मानता है TCP काफी अच्छा था

ब्रॉडबैंड के लिए यह था।

HTTP/3: FineM SK1 We'll Move Down the Stack

वह दुनिया जो इसे बनाती है

द्वारा 2015, साक्ष्य स्पष्ट था टीसीपी समस्या थी.

Google ने QUIC को प्रयोगात्मक रूप से चलाया था जब से 2012. वे डेटा प्राप्त कर रहे थे. मोबाइल नेटवर्कों परM SK2 हानिकारक WiFi , और उच्चMSC4 लेटेंसी कनेक्शन्सMスク5 एचटीपीटीMST6 TCP के ऊपर विफलता की थी ऐसे तरीके से जो नहीं हो सकाMSL7 परिवहन परत को बदले बिना निश्चित नहीं किया जा सकता

लेकिन आप केवल TCP को ठीक कर सकते हैं. ." यह ऑपरेटिंग सिस्टम के कर्नेलों में लागू होता है.. यह प्रत्येक राउटर में बनाया जाता है.

तो गूगल ने कुछ साहसी किया उन्होंने यूडीपी के ऊपर एक नया परिवहन प्रोटोकॉल बनाया.

QUIC: प्रोटोकॉल जो TCP को बदलता है

QUIC ( मूल रूप से |" |Quick UDP Internet Connections | ", | अब सिर्फ QUIC) | एक परिवहन प्रोटोकॉल है जो यूडीपी पर चलता है लेकिन टीसीपी प्रदान करता है उपयोगकर्ता स्थान में विश्वसनीयता लागू करें, जहाँ आप तेजी से पुनरावृत्ति कर सकते हैं.

क्यों यूडीपी एक संस्था के रूप में

यूडीपी जानबूझकर न्यूनतम है।

यह "dumbness" ठीक है कि QUIC की जरूरत है।

• कर्नेल परिवर्तनों के बिना लागू करें यह सिर्फ एक लाइब्रेरी है
• जल्दी दोहराएँ - Chrome अद्यतन नए QUIC संस्करणों को निरंतर भेजते हैं
• अधिकांश फायरवालों से गुजरें UDP पोर्ट सामान्यतः काम करता है
• अपनी स्वयं की गड़बड़ी नियंत्रण क्रियान्वयन - टीसीपी के साथ stuck नहीं है

QUIC क्या अलग करता है

कनेक्शन आईडी विशेष रूप से चतुर है।

के लिए पथ

जिस तरह SPDY ने HTTP को लाया था, उसी प्रकार Google के QUIC प्रयोग HTTP को भी लाया है।

मानकित QUIC Google से कुछ विवरणों में भिन्न है

एचटीटीपी0 है HTTP पर QUIC. यह स्वीकार करता है कि हम HTTP को ठीक करने के लिए HTTP के नीचे जाना आवश्यक था

क्या हो गया है HTTP/3

• UDP पर QUIC टीसीपी नहीं
• स्ट्रीम---स्तर हानि वसूली loss packet only stops its stream
• तेज कनेक्शन सेटअप आरटीटी पुनरारंभ संभव है
• डिफ़ॉल्ट से एनक्रिप्शन QUIC में विनिर्मित (TLS
• कनेक्शन माइग्रेशन आईपी पता परिवर्तनों को बचाता है

┌──────────────────────────────────────────┐
│              QUIC Connection             │
├──────────────────────────────────────────┤
│ Stream 1: [pkt][pkt][pkt] ← flowing      │
│ Stream 3: [pkt][ ? ][pkt] ← waiting      │
│ Stream 5: [pkt][pkt][pkt] ← flowing      │
│ Stream 7: [pkt][pkt]      ← flowing      │
│                                          │
│ Lost packet only affects Stream 3        │
└──────────────────────────────────────────┘

क्या एक ही रहा है

• HTTP अर्थशास्त्र (GET
• कैशिंग तर्क
• रेस्ट पैटर्न
• अनुप्रयोग परत पर सब कुछ

HTTP didn’t change

क्यों QUIC महत्वपूर्ण है (Details)

क्विक टीसीपी एमएसके0 की विश्वसनीयता गारंटी लागू करता है प्रति धारा, एक कनेक्शन के लिए नहीं

टीसीपी का वायदा प्रत्येक बाइट क्रम में आ जाता है वायदा "हर बाइट इस धारा में क्रम में आ जाता है

यह भिन्नता है कि क्यों एचटीटीपी

स्ट्रीम स्वतंत्रता

QUIC में प्रत्येक एचटीटीपी निवेदन को एक ही स्ट्रीम प्राप्त होती है।

QUIC Connection
├── Stream 1: GET /index.html     [packets 1, 2, 3]
├── Stream 3: GET /style.css      [packets 4, 5]     ← packet 5 lost
├── Stream 5: GET /app.js         [packets 6, 7, 8]
└── Stream 7: GET /logo.png       [packets 9, 10]

Packet 5 is retransmitted. Only Stream 3 waits.
Streams 1, 5, 7 continue unaffected.

यह HTTP के साथ तुलना करें/2 TCP पर : उन सभी धाराओं का एक TCP बाइट अनुक्रम साझा करता है

कनेक्शन माइग्रेशन

TCP द्वारा कनेक्शनों को पहचानता है एक 4-tuple: स्रोत आईपी | , | स्रोत पोर्ट |, | गंतव्य आईपी

Phone on WiFi → walks out of range → switches to cellular
TCP: Source IP changed. Connection dead. Full reconnect.
QUIC: Connection ID unchanged. Streams continue seamlessly.

यह महत्वपूर्ण है क्योंकि मोबाइल उपयोगकर्ता निरंतर नेटवर्क स्विच करें. अपने घर से बाहर निकलें

आरटीटी पुनः आरंभ

पारंपरिक TCP + डेटा भेजने से पहले TLS को कई दौरों की आवश्यकता होती है

1. TCP SYN/
2. TLS हैंडशेक (1-2 RTT
3. अंततः: अपने HTTP अनुरोध भेजें

QUIC ट्रांसपोर्ट और क्रिप्टो हैंडशेक को संयोजित करता है. पहला कनेक्शन लेता है | 1 | RTT

First visit:    Client ──[handshake]──> Server ──[response]──> Client (1 RTT)
Return visit:   Client ──[data]──────────────────[response]──> Client (0 RTT)

परन्तु अधिकतर पृष्ठ लोड के लिए यह एक महत्वपूर्ण लटेनसी जीत है

प्रथम नागरिक के रूप में एनक्रिप्शन

TCP में डिजाइन किया गया था 1970s. एनक्रिप्शन बाद में TLS के माध्यम से बोल्ट किया गया है

• TCP हेडर सादा पाठ हैं (anyone can see port numbers
• मिडलबॉक्स ( और TCP ट्रैफिक का निरीक्षण और परिमार्जन कर सकते हैं
• एनक्रिप्शन वैकल्पिक है, अक्सर कनेक्शन सेटअप के बाद बातचीत की जाती है

QUIC आरंभ से लगभग हर चीज़ को एन्क्रिप्ट करता है. पैकेट संख्या भी एनक्रिप्ट की जाती हैं।

TCP packet:   [IP header][TCP header (plaintext)][TLS encrypted payload]
QUIC packet:  [IP header][UDP header][QUIC header (mostly encrypted)][encrypted payload]

द वर्ल्ड जो इसे ज़रूरी है

एचटीटीपी

• मोबाइल: वेब ट्रैफिक का आधा से अधिक मोबाइल है
• अविश्वसनीय नेटवर्क: WiFiM SK1 सेल्युलर, भीड़ग्रस्त सार्वजनिक नेटवर्क
• वैश्विक उपयोगकर्ता: दूरस्थ सर्वर से उच्च लाटेसी कनेक्शन
• गोपनीयता की अपेक्षाएंएनक्रिप्शन अनिवार्य है

प्रोटोकॉल अंततः नेटवर्क वास्तविकता से मेल खाता है

प्रगति की लागत

HTTP

• यूडीपी अक्सर अवरोधित होता है कॉर्पोरेट फायरवाल्स द्वारा (HTTP के लिए वापसी
• अधिक सीपीयू के लिए QUIC ' \Userspace \implementation \ ( \not in the kernel like TCP , \although this gap is closing with kernel bypass and optimized stacks \
• नई डिबगिंग औज़ार (tcpdump एनक्रिप्टेड UDP को दिखाता है
• मिडलबॉक्स हस्तक्षेप (कुछ नेटवर्क UDP अप्रत्याशित रूप से मंद कर रहे हैं

लेकिन मोबाइल के लिए पहला अनुप्रयोग-,-अविश्वसनीय नेटवर्क-, और लंबितता-MSC3-संवेदनशील सेवाएँ-M SK4-HTTP–/3 पहला संस्करण है जो वास्तव में नेटवर्कों के व्यवहार से मिल जाता है

सभी संस्करणों में वास्तविक पाठ

हर एचटीटीपी संस्करण परिवर्तन हुआ क्योंकि प्रोटोकॉल से अधिक तेजी से परिवेश बदल गया.

संस्करण | | | Era || | Environment _ | | Assumption |---------|-----|-------------|------------|--------------| एचटीपी (HTTP) एचटीटीपी टीसीपी काफी विश्वसनीय है HTTP/3|2022+|Mobile-first,Global|Nothing is reliable

पैटर्न स्पष्ट है

1. प्रोटोकॉल मौजूदा वातावरण के लिए डिजाइन किया गया है
2. परिवेश परिवर्तन ( प्रोटोकॉलों से अनुकूलित होने की अपेक्षा जल्दी
3. वर्कराउंड्स संचयन करता है (CDNs
4. नया प्रोटोकॉल वास्तविकता को स्वीकार करता है
5. दोहराएँ (R)

प्रोटोकॉल नेटवर्क से अधिक निकट धकेल दिया जाता है

अन्य अवलोकन

• एक झूठ है हम स्वयं को रात में सोने के लिए कह रहे हैं।
• अधिकांश प्रदर्शन जीतें से आई थीं उपचारप्रोटोकॉल शुद्धता नहीं है
• "simple" बात चल रही थी।
• समय निर्धारण संबंधी मामले HTTP/2 यदि यह \2005.\ में पहुँचा होता तो पूर्ण हो जाता था \ 2015,\ द्वारा मोबाइल ने पहले से ही खेल को बदल दिया था | .\ प्रोटोकॉल कल हल कर रहा था

क्या ' से नहीं बदला है

यहाँ ''' एक असंतोषपूर्ण भाग है '.' प्रोटोकॉल विकास के तीस वर्षों के बावजूद ':'

अनुरोध अभी भी असफल है नेटवर्क विभाजन. सर्वर क्रैश. समय समाप्ति हो जाती है

नेटवर्क अभी भी है 200 ठीक नहीं है, ' इसका मतलब यह नहीं है कि प्रतिक्रिया सही है।

कैश अभी भी अप्रचलित डेटा को सेवा प्रदान करता है Cache-Control एक अनुरोध है, एक कमांड नहीं है

क्लाइंट अभी भी खराब तरीके से पुनः प्रयास करते हैं उपयोक्ता बटन क्लिक करता है

विकासकर्ता अभी भी idempotency को गलत समझते हैं GET सुरक्षित होना चाहिए।

// This is still your problem, regardless of HTTP version
public async Task<Result> CreateOrderAsync(Order order)
{
    // What happens if this times out?
    // Did the server receive it?
    // Did it process it?
    // Will the client retry?
    // Will you create duplicate orders?
    
    // HTTP/3 doesn't save you here.
    // Idempotency keys do.
}

अगर आप यह नहीं समझते

मैंने वास्तव में क्या सीखा

सभी इन प्रोटोकॉल संस्करणों में वेब अनुप्रयोग बनाने के बाद

प्रोटोकॉल आपकी विश्वसनीयता परत नहीं है

एचटीटीपी आपको अनुरोध देता है।

2. लाटेन्सी दुश्मन है

अधिकतर निष्पादन समस्याएं गोल हैं

प्रत्येक "best practice

डोमेन छेद HTTP के लिए अनिवार्य था।

वास्तविक नेटवर्क पर मापन

स्थानीय होस्ट पर बैंचमार्क कुछ भी नहीं साबित करते. आपके उपयोगकर्ता मोबाइल नेटवर्क पर हैं, होटल WiFiM SK2 और संतृप्त कॉफी शॉप कनेक्शन्स

5. बोरिंग भाग सबसे अधिक महत्वपूर्ण हैं

समय समाप्ति. RetriesM SK1 सर्किट ब्रेकर्स. निर्वहनताMSC3 कनेक्शन पूलिंग . इन अस्पष्ट विवरणों से यह पता चलता है कि क्या आपका सिस्टम लोड के तहत काम करता है

निष्कर्ष

HTTP didn'it faster because it got smarter. It got faster since we finally admitted नेटवर्क समस्या थी.

प्रत्येक संस्करण अपने समय के लिए सही था

• HTTP/1.0 डायलप दस्तावेज पुनःप्राप्ति के लिए पूर्ण था
• HTTP/1.1 ब्रॉडबैंड वेब अनुप्रयोगों के लिए पूर्ण था
• HTTP/2 कम ±- ±loss तारी कनेक्शन के लिए आदर्श था
• HTTP/3 मोबाइल के लिए बनाया गया है

गलती यह सोच रही थी कि इनमें से कोई स्थायी समाधान थे

एचटीटीपी संस्करण उपभोक्ता अर्थ में अद्यतन नहीं हैं

और फिर भी

• अनुरोध असफल
• नेटवर्क झुठलाएँ
• कैशिंग कठिन है
• स्थायित्व सम्बन्धी मामले

प्रोटोकॉल विकसित हुआ

असफलताओं से बचने वाली प्रणालियों का निर्माण

एचटीटीपी के तीस वर्ष

आगे पढ़ने

• आरएफसी 9114:HTTP - आधिकारिक विनिर्देशन
• आरएफसी 9000: QUIC - परिवहन प्रोटोकॉल
• HTTP/2 समझा गया - Daniel Stenberg
• उच्च निष्पादन ब्राउज़र नेटवर्किंग Ilya Grigorik