साधारण इंजीनियरों के लिए HTTPS गाइड

 (devonperoutky.super.site)
6 पॉइंट द्वारा GN⁺ 2024-05-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इंटरनेट संचार ऐसी संरचना है जिसमें पैकेट को कई layers मिलकर process करती हैं, और layered protocols की वजह से developers को transport, routing और security की implementation details खुद handle नहीं करनी पड़तीं
  • HTTP request browser द्वारा message बनाने से शुरू होकर DNS lookup, TCP 3-way handshake, routers से गुजरना और server response तक पहुंचने वाला step-by-step flow follow करती है
  • basic HTTP में headers और body plain text में आते-जाते हैं, इसलिए eavesdropping और server impersonation के प्रति vulnerable होता है; इस limitation को दूर करने के लिए security layer जोड़ी जाती है
  • HTTPS, HTTP में TLS encryption और verification जोड़ता है; TLS handshake version, cipher suite, certificate और key exchange की जानकारी पर सहमति बनाकर symmetric session key बनाने की process है
  • TLS 1.3 RSA और कमजोर cipher suites/parameters को हटाकर choices कम करता है, जिससे पुराने तरीकों की तुलना में अधिक सरल, तेज और सुरक्षित handshake बनता है

इंटरनेट संचार को देखने का layered model

  • इंटरनेट आपस में जुड़े computer networks का network है, और “Internet” का शाब्दिक अर्थ “networks के बीच” है
  • यह packet switching वाली mesh network की तरह काम करता है, और packet delivery या arrival time की guarantee न देने वाली best-effort delivery संरचना है
  • retry, ordering guarantee, duplicate removal और security जैसे काम कई abstraction layers पीछे से संभालती हैं, इसलिए इंटरनेट smooth तरीके से चलता हुआ दिखता है
  • हर layer एक खास function देती है, और अलग-अलग protocols उस function को implement कर सकते हैं
    • इस modularization की वजह से एक layer का protocol बदलने पर भी दूसरी layers के protocols पर असर न पड़े, ऐसा संभव होता है

Network layers की भूमिकाएं

  • Application layer application-specific logic handle करती है; communication unit message होता है और HTTP इसका प्रमुख उदाहरण है
  • Security layer encryption और authentication देती है; communication unit record होता है और TLS इसका उदाहरण है
  • Transport layer reliable data transport की जिम्मेदार होती है; TCP segment या UDP datagram का उपयोग करती है और port number से पहचानी जाती है
  • Network layer इंटरनेट के across packets को route करती है; identifier के रूप में IP address का उपयोग करती है
  • Link layer physical medium के करीब का communication manage करती है; frame का उपयोग करती है और MAC address से पहचानी जाती है
  • Physical layer devices के बीच bits को physically transmit करती है; optical fiber या Ethernet cable इसके उदाहरण हैं

HTTP request का flow

  • 1. client request बनाता है

    • process Application layer में शुरू होती है, और client आमतौर पर web browser होता है
    • HTTP text-based protocol है, इसलिए data plain text में transmit होता है
    • HTTP request की पहली line में आमतौर पर HTTP method, requested resource और protocol version होता है
      • HTTP method: GET, POST आदि
      • requested resource: उदाहरण के लिए /index.html
      • protocol version
    • बाकी HTTP message में key: value format के headers और optional body शामिल होते हैं
    GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

  • 2. DNS lookup

    • DNS इंसानों द्वारा पढ़े जा सकने वाले domain name www.example.com को 93.184.216.34 जैसे IP address में बदलता है
    • client DNS server से query करके domain name को IP address में resolve करता है
    • यह process कई resolvers से गुजरते हुए अंत में authoritative server तक पहुंचती है
    • Stub resolver client machine पर होता है और request को उपयुक्त recursive resolver तक forward करता है
    • Recursive resolver stub resolver की request लेकर authoritative server से query करता है, और अक्सर result को cache करता है
    • ISP आमतौर पर recursive resolver provide करता है, और Google DNS 8.8.8.8 जैसे public resolvers भी इस्तेमाल किए जा सकते हैं
    • Authoritative server के पास A, MX, CNAME जैसे actual DNS records होते हैं, और यह domain name data का अंतिम source होता है

  • 3. TCP handshake

    • server IP address मिल जाने पर client Transport layer में HTTP transport की तैयारी करता है
    • transport layer के मुख्य protocols TCP और UDP हैं
    • TCP connection-oriented protocol है, और applications के बीच data delivery की reliability, ordering और error checking guarantee करता है
    • UDP connectionless protocol है; यह delivery, ordering और error checking guarantee नहीं करता, लेकिन तेज होता है और overhead कम होता है
    • 2024 तक TCP इंटरनेट data transport management का प्रमुख protocol है, और UDP मुख्यतः streaming या video calls जैसे real-time applications में इस्तेमाल होता है जहां low latency महत्वपूर्ण है और कुछ packet loss स्वीकार्य हो सकता है
    • HTTP के standard port यानी port 80 पर TCP connection शुरू होता है और 3-step handshake से गुजरता है
      • SYN: client connection request के लिए SYN packet भेजता है
      • SYN-ACK: server SYN-ACK packet से request approve करता है
      • ACK: client ACK packet भेजता है और reliable connection establish हो जाता है

  • 4. HTTP request transmit करना

    • TCP connection तैयार होने पर client actual HTTP request भेजता है
    • चूंकि HTTP text-based protocol है, request headers और body, अगर body हो, तो plain text में transmit होते हैं

packets server तक कैसे पहुंचते हैं

  • client जब request भेजता है, तो data packets सीधे server तक नहीं जाते; वे कई network devices और routers से गुजरते हुए server network gateway तक पहुंचने का रास्ता ढूंढते हैं
  • इसके बाद Link layer local segment में transmission संभालती है

  • text के इंटरनेट पार जाने के चरण

    • client device HTTP request data को TCP segment में encapsulate करता है, और फिर उसे IP packet में wrap करता है
    • wired connection हो तो उसे Ethernet frame जैसे Link layer frame में एक बार और encapsulate किया जाता है
    • frame local network के जरिए client के router तक transmit होता है
    • local router frame receive करता है, Link layer header हटाता है और IP packet process करता है
    • router destination IP address देखकर अगला hop तय करता है
    • packet एक या अधिक intermediate routers से गुजरते हुए अगले network तक forward होता है, और हर router अगला hop तय करके forward करने की process दोहराता है
    • packet आखिरकार उस router तक पहुंचता है जो destination server वाले ही network में होता है
    • यह router final routing decision लेकर packet को server से संबंधित local device तक भेजता है
    • server का router local network segment के जरिए packet को server तक forward करता है
    • Link layer सुनिश्चित करती है कि frame server के network interface तक सही तरह पहुंचे
    • server frame receive करता है, IP packet extract करता है, फिर encapsulated TCP segment process करके original HTTP request reconstruct करता है
    • इंटरनेट के across packets भेजने वाली Network layer process domain name resolution या TCP handshake जैसे पिछले steps में भी इस्तेमाल होती है

server response और browser rendering

  • server HTTP request process करने के बाद client को HTTP response भेजता है
  • response में इस्तेमाल हो रहा HTTP version, 200·404 जैसे status codes, response headers, और requested page का HTML या JSON data जैसी body शामिल होती है
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456

    Example Page

    Hello, world!
  • client HTTP response receive करके process करता है
  • browser HTML parse करके screen पर content render करता है
  • अगर response में images, CSS, JavaScript जैसे additional resources हों, तो browser वही process follow करते हुए additional HTTP requests भेजता है

HTTP की security problems और HTTPS

  • basic HTTP में बिल्कुल भी security नहीं होती
  • connection सुनने वाला व्यक्ति exchanged data का 100% देख सकता है
  • अगर कोई server बनकर pretend करे, तो client sensitive information गलत target को भेज सकता है
  • HTTPS, HTTP में encryption और verification जोड़ता है
  • HTTP communication को secure बनाने के कई तरीके हैं, लेकिन अभी आमतौर पर इस्तेमाल होने वाली implementation TLS है
  • TLS client और server को एक-दूसरे की identity verify करने और payload को ऐसे encrypt करने देता है जिसे दोनों sides decrypt कर सकें
  • HTTPS request का flow ऊपर देखे गए HTTP request flow जैसा ही है, लेकिन Application layer और Transport layer के बीच Security layer जुड़ जाती है
    • TLS handshake में आमतौर पर TCP का उपयोग होता है

TLS handshake किन चीजों पर सहमति बनाता है

  • TLS handshake वह process है जिसमें client और server communication के लिए इस्तेमाल होने वाले कई elements पर सहमति बनाते हैं
  • सहमति के targets में message verification, compression और encryption के लिए algorithms का collection शामिल होता है
  • algorithms के इस collection को cipher suite कहा जाता है
    • सख्ती से देखें तो compression algorithm को छोड़कर बाकी हिस्सा cipher suite है, लेकिन इस लेख में पूरे collection को cipher suite कहा गया है
  • example components ये हैं
    • Compression algorithm: wire पर data compress करने का तरीका; Gzip और Brotli इसके examples हैं, और अभी मुख्यतः Brotli इस्तेमाल होता है
    • Key exchange algorithm: public channel पर encryption keys को safely exchange करने का तरीका; ECDHE-RSA और ECDHE-ECDSA examples हैं, और अभी मुख्यतः ECDHE इस्तेमाल होता है
    • Authentication algorithm: handshake के दौरान parties की identity authenticate करने का तरीका; RSA और ECDSA examples हैं, RSA widely used है और ECDSA भी popular हो रहा है
    • Symmetric encryption algorithm: client और server के बीच data encrypt करने का तरीका; AES-128-GCM और AES-256-GCM examples हैं, और AES-GCM strong security और efficiency देता है
    • MAC algorithm: message की integrity और authenticity guarantee करने का तरीका; HMAC-SHA256 और HMAC-SHA384 examples हैं, और HMAC-SHA256 तथा modern cipher suites का GCM mode इस्तेमाल होता है
  • client और server cipher suite पर सहमत होते हैं, और random seeds व SSL certificate information exchange करके message encryption और verification के लिए symmetric key बना सकते हैं
  • TLS handshake के material का source Cloudflare है

पुराने TLS handshake के चरण

  • Client Hello

    • client अपने supported cipher suites, supported TLS version और Client Random नाम के random number वाला TCP message server को भेजता है

  • Server Hello

    • server चुना हुआ TLS version, selected cipher suite algorithms और Server Random वाला TCP message भेजकर response देता है

  • Certificate Verification

    • client Certificate Authority के जरिए server का SSL certificate verify करता है और server की public key प्राप्त करता है

  • Premaster Secret Generation

    • client premaster secret बनाता है, उसे server की public key से encrypt करके server को भेजता है

  • Decryption

    • server private key का उपयोग करके premaster secret decrypt करता है

  • Session Key Creation

    • client और server Client Random, Server Random और premaster secret का उपयोग करके session key बनाते हैं

  • Client Ready

    • client session key से encrypted finished message भेजता है

  • Server Ready

    • server session key से encrypted finished message भेजता है

  • Secure HTTP Communication

    • इसके बाद दोनों sides session key का उपयोग करके secure symmetric encryption के साथ communicate करती हैं

TLS 1.3 में क्या बदला

  • ऊपर बताया गया TLS handshake मूल TLS versions की process है, और latest TLS 1.3 के हिसाब से पुराना तरीका है
  • TLS 1.3 और ऊपर security reasons से RSA और कई cipher suites support नहीं करते
  • latest versions choices को काफी कम करते हैं, जिससे वे ज्यादा simple, ज्यादा secure और ज्यादा fast हैं
  • TLS 1.3 में भी core concepts बने रहते हैं
    • handshake के जरिए compression method, server authentication और key exchange पर सहमति बनती है
    • TCP के जरिए exchange होने वाले packet data को protect करने के लिए symmetric encryption key generate होती है
  • TLS 1.3 attack-prone cipher suites और parameters को support नहीं करता, और handshake को छोटा करके ज्यादा तेज और secure handshake बनाता है

  • TLS 1.3 handshake के basic steps

    • Client hello: client protocol version, Client Random और cipher suite list भेजता है
      • TLS 1.3 में unsafe cipher suites का support हटा दिया गया है, इसलिए possible cipher suites की संख्या काफी घट गई है
      • Client hello में premaster secret calculation के लिए parameters भी शामिल होते हैं
      • client मानता है कि उसे server का preferred key exchange method पता है, और reduced cipher suite list की वजह से ऐसा होने की संभावना अधिक है
      • यह structure TLS 1.0, 1.1, 1.2 handshakes की तुलना में overall length घटाता है
    • Server generates master secret: server के पास Client Random, client parameters और cipher suite आ चुके होते हैं, और वह Server Random खुद generate कर सकता है, इसलिए master secret बना सकता है
    • Server hello and Finished: Server hello में server certificate, digital signature, Server Random और selected cipher suite शामिल होते हैं
      • server के पास पहले से master secret होता है, इसलिए वह Finished message भी साथ में भेजता है
    • Final steps and client Finished: client signature और certificate verify करता है, master secret generate करता है, फिर Finished message भेजता है
    • Secure symmetric encryption achieved: इसके बाद secure symmetric encryption establish हो जाती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-27
Hacker News टिप्पणियाँ

  • एक non-expert के तौर पर मेरी जिज्ञासा है: जब किसी खास वेबसाइट या पूरे इंटरनेट तक access नहीं हो पाता, तो यह पता लगाना इतना मुश्किल क्यों होता है कि समस्या किस हिस्से में आई है
    अक्सर साफ़ नहीं होता कि मेरे local machine की network settings में error है, router तक Wi‑Fi connection की दिक्कत है, router और ISP के बीच cable problem है, ISP का बड़ा outage है, या जिस website को खोलना है वही down है
    मैंने यह धुंधली-सी explanation सुनी है कि requests non-deterministic paths से route होती हैं, लेकिन वह बहुत convincing नहीं लगती. अगर path में कोई link टूट जाए, तो आख़िरी सही link पीछे की तरफ़ यह क्यों नहीं बता सकता कि “तुम्हारा message यहाँ तक आ गया था, लेकिन अगले step पर भेजने में fail हो गया”

    • अगर working principle पता हो तो ठीक-ठीक यह जाना जा सकता है कि क्या fail हुआ, लेकिन user के लिए उपयोगी explanation देने वाला diagnostic tool बनाना लगभग असंभव है
      configurations हर जगह अलग होती हैं, यह पता नहीं होता कि कौन-सी configuration जानबूझकर की गई है, और common causes के आधार पर assumption लगाकर अगर बिल्कुल गलत जवाब दे दिया जाए तो यह risky है
      उदाहरण के लिए अगर DNS server भी respond नहीं कर रहा और target host भी respond नहीं कर रहा, तो आप कह सकते हैं कि router configuration error है या ISP outage है; लेकिन असली कारण यह हो सकता है कि VPN client ने local routing table और DNS server बदल दिए और exit करते समय उन्हें वापस restore नहीं कर पाया. सवाल यह है कि diagnostic tool कैसे जाने कि यह temporary change है या permanent setting
    • अगर ICMP को network में आने की अनुमति है, तो जिस host ने packet को आगे forward नहीं कर पाया उससे Destination Unreachable response मिलने की संभावना काफ़ी होती है
      applications ICMP messages तब तक नहीं देख पातीं जब तक socket को वैसे configure न किया गया हो. ऐसी चीज़ों को “temporary” error माना जाता है, और Linux में इसे IP_RECVERR socket option से set किया जाता है
      layer 7 पर काम करते समय इस layer की errors collect करने की बहुत value नहीं होती. ऊपर दिखने वाली Destination Unreachable error वैसे भी उस failure-handling logic में fit होगी जो आपके पास पहले से होगा, और इस case में दूसरी layers unreachable destination के लिए retry करती हैं, इसलिए शायद यह timeout जैसा दिखेगा
      TCP layer ICMP errors को कैसे handle करती है, इसके लिए ये RFCs मददगार हैं: https://www.rfc-editor.org/rfc/rfc1122#page-103
      4.2.3.9 में कहा गया है कि Unreachable message एक soft error condition है, इसलिए TCP को connection abort नहीं करना चाहिए, बल्कि information application को provide करनी चाहिए. TCP इसे ERROR_REPORT routine के ज़रिए application layer तक भेज सकता है, या message को record करके केवल तब application को report कर सकता है जब TCP connection timeout हो
      TCP attack vector के रूप में ICMP का अध्ययन करने के लिए stacks कैसे interact करते हैं, इस पर ज़्यादा detail देने वाला document भी है: https://www.rfc-editor.org/rfc/rfc5927
    • browser उस समय किए जा रहे काम के सबसे नज़दीकी error को report करता है. अगर host नहीं मिला, तो इसका मतलब लगभग यह है कि DNS server तक पहुँचा गया और उस server ने जवाब दिया कि उस name के लिए कोई address नहीं है
      अगर DNS server तक ही नहीं पहुँचा जा सकता, तो user और उस server के बीच किसी network error की बात है. आम तौर पर steps खुद run करके diagnose किया जाता है. DNS server address पर ping होता है या नहीं, उस DNS server से उस host को resolve किया जा सकता है या नहीं, और दूसरे DNS server पर क्या होता है—ये check किए जाते हैं. company policy की वजह से कोई खास name exclude भी हो सकता है
      अगर और गहराई में जाना हो तो ping, traceroute, dig जैसे command-line tools उपयोगी होते हैं
    • ऐसी problems का बड़ा हिस्सा troubleshooting के समय destination तक MTR run करके हर hop की details देखने से solve किया जाता रहा है
      MTR real-time में लगातार चलने वाले ping + traceroute जैसा है, और हर hop अलग से दिखता है
      Xfinity network में कोई node dead होने का पहली बार पता लगाते समय भी, उसी MTR में कम से कम मेरे network से modem तक सब ठीक दिख रहा था, इसलिए यह consistent था. ISP से आगे किसी hop पर latency सैकड़ों ms बढ़ने को MTR जितना साफ़ दिखाने वाले tools मैंने ज़्यादा नहीं देखे
      यह हर problem solve नहीं करता, लेकिन hop-by-hop latency देता है, इसलिए check करने लायक है
    • आप किससे verify करना चाहते हैं, यह अहम है. web browser URL access नहीं कर पा रहा हो, फिर भी वह exact cause इसलिए नहीं बताता क्योंकि diagnosis गलत हो सकता है और ज़्यादातर users confuse हो जाएंगे
      “problem यहाँ है” कहने के लिए operating system, hardware और network कैसे configured हैं, इस बारे में assumptions चाहिए
      website access करते समय पहले DNS से web server का IP address लेना होता है, लेकिन browser DNS IP कहाँ से पाता है, यही पहले से complex है. इसे browser, operating system, router, modem में set किया जा सकता है; और अगर set न हो तो router जिस DHCP server से connected है, उससे मिलता है. वह ISP का DHCP server भी हो सकता है, या organization के अंदर कोई दूसरा router भी
      अगर DNS अजीब लगे तो यह जानना आसान है कि IP गलत है, लेकिन वह IP कहाँ से आया यह बताना मुश्किल है. SSL में भी server certificate गलत हो सकता है या मेरे computer का certificate गलत हो सकता है

  • इससे related हो सकता है: TLSv1.2 और TLSv1.3 के लिए byte-by-byte detail में follow करने वाले interactive examples भी हैं
    अगर आप TLS और सीखना चाहते हैं, तो यह मेरी बेहद पसंदीदा resource है और मैं strongly recommend करता हूँ
    [0]: https://tls12.xargs.org/
    [1]: https://tls13.xargs.org/

  • उत्सुकता है कि क्या इस नज़रिए से लिखे गए और उदाहरण हैं। दक्षता के स्तर से अलग, मुझे ऐसे लेख पसंद हैं जो “किसी औसत-से इंजीनियर को समझा रहे हों” की तरह खोलकर समझाते हैं
    इससे वे टुकड़े नए सिरे से सीखने को मिलते हैं जो पूरी तरह स्पष्ट नहीं थे, या दूसरों को समझाते समय इस्तेमाल करने के लिए और उदाहरण मिल जाते हैं, इसलिए कुल मिलाकर यह बहुत उपयोगी होता है

  • “क्लाइंट premaster secret बनाकर उसे सर्वर की public key से encrypt करता है और फिर सर्वर को भेजता है” वाली व्याख्या बहुत पहले से सच नहीं रही

    • नीचे “यहाँ सीखी गई सारी बातें झूठ हैं” लिखा है
      साथ में यह भी जोड़ा गया है कि अभी बताया गया प्रोसेस आधुनिक TLS 1.3 की तुलना में पुराने TLS के शुरुआती versions का प्रोसेस है

  • “मौजूदा TLS versions (>1.3) सुरक्षा कारणों से RSA और कई cipher suites को support नहीं करते” यह बात key exchange वाले हिस्से में सही है। क्योंकि RSA forward secrecy नहीं देता
    signatures में RSA अभी भी इस्तेमाल होता है, और शायद x509 certificates में सबसे ज्यादा फैला हुआ प्रकार है
    जहां तक मुझे पता है, Safari ने भी कुछ समय पहले RSA signatures के लिए 2048-bit key requirement बढ़ाई थी

  • यह लेख किसी असली HTTPS explainer को AI द्वारा summarize किया गया हो ऐसा पढ़ा जाता है। शब्द बिना context के आ जाते हैं
    certificate क्या है, chain of trust कैसे काम करती है—यह समझाए बिना पाठक से public-key cryptography जानने की उम्मीद की गई है। OSI की 7 layers में से 6 समझाते हुए भी उस शब्द को खुद नहीं कहा गया, और presentation layer छूट गई है
    हाँ, शीर्षक में ही mediocre तो कहा गया है

    • निष्पक्षता से कहें तो session layer भी नहीं डाली गई थी
      लेखन मेरी ताकत नहीं है, इसलिए आलोचना को खुशी से स्वीकार करता हूँ। मेरा लेख “खराब है” से “क्या यह AI है?” तक पहुँचा है, यह प्रगति है
      मैं सोच रहा था कि explanation कहाँ रोकूँ, और public-key cryptography को मुझे ऐसी अच्छी सीमा लगी जिसे कहीं और बेहतर समझाया जा सकता है। OSI की कई layers के साथ भी यही था
      यह मानता हूँ कि certificates और शायद पूरी chain of trust को कवर करना चाहिए था

  • SHA256(client_hello_random + server_hello_random + curve_info + public_key) की signature verification दिखाने वाला code नहीं मिल पा रहा
    theory पता है, लेकिन implement करने पर कुछ न कुछ समस्या आ जाती है। अगर कोई toy program link हो जो दिखाए कि असल में यह कैसे किया जाता है, तो अच्छा होगा

  • उम्मीद है कि “server के SSL certificate में private key होती है” जैसी अभिव्यक्ति सच में नहीं है। फिर भी शीर्षक “Mediocre Engineer” तो है
    TLS <1.3 भी उस तरह काम नहीं करता जैसा लेख में बताया गया है, और फिर उसमें 1.3 के नए elements मिलाने की कोशिश की गई है। DNS वाला हिस्सा recursive resolver समझाता है, लेकिन client ऐसा नहीं करता, वह शायद stub resolver से बात करेगा
    “Internet Layer”, यह संकेत कि brotli TLS compression या cipher suites में व्यापक रूप से इस्तेमाल होने वाला algorithm है, “मौजूदा TLS version (>1.3) RSA support नहीं करता” जैसी गलतियाँ लगातार आती हैं
    ऐसे blog spam की वजह से कभी-कभी लगता है कि downvote होना चाहिए। ad इतना परेशान करने वाला नहीं कि flag किया जाए, लेकिन स्तर कम है। शायद मुझे ही कोई कम mediocre लेख लिखकर HN के front page पर डालना चाहिए। अगर मैं $300K salary कमा रहा होता तो शायद समय ज्यादा होता

  • लेख की सामग्री कुल मिलाकर थोड़ी पुरानी है। आजकल web requests के 30% HTTP/3 हैं और CORS भी है, लेकिन publish date नहीं है

    • क्या मतलब है कि 30% requests CORS हैं? यह काफी हद तक इस पर निर्भर करेगा कि आप किस तरह का development करते हैं
      मैं आम तौर पर enterprise networks के अंदर deploy होने वाले SaaS systems develop करता हूँ, और CORS requests लगभग 0% के करीब होती हैं। HTTP/3 भी ऐसा ही है