HTTP/1.1, HTTP/2, र HTTP/3 बीच के फरक छ?

Question

IT Interview Practice · Accepted Answer

तीनैले उही HTTP semantics (method, header, status code) दिन्छन् तर तिनी *कसरी* byte लाई तारमा सार्छन् भन्नेमा फरक छन् — प्रत्येक version ले अघिल्लोको एउटा bottleneck सुधार्छ। मूल विषय **head-of-line (HOL) blocking हटाउनु** हो, जहाँ एउटा अड्किएको request ले अरूलाई रोक्छ।

```text
HTTP/1.1  over TCP     one request at a time per connection
  conn ──[req A]──[req B]──[req C]──▶   B waits for A (HOL blocking at HTTP layer)

HTTP/2    over TCP     many streams multiplexed on ONE connection
  conn ══[A|B|C interleaved]══▶        but a lost TCP packet stalls ALL streams
                                       (HOL blocking moves down to TCP)

HTTP/3    over QUIC (UDP)   independent streams, per-stream delivery
  conn ══[A][B][C]══▶                  a lost packet stalls only its own stream
```

**HTTP/1.1** ले एक connection मा एक पटक एउटा request पठाउँछ; browser ले प्रति host ~6 समानान्तर connection खोलेर यसलाई पन्छाउँछ, र text header हरू बिना compress पठाइन्छन्। **HTTP/2** ले **multiplexing** थप्छ — एउटै connection मा धेरै समकालीन **stream** — साथै binary framing, header compression (HPACK), र server push। तर यो अझै TCP मा चल्ने हुनाले, एउटै हराएको packet ले retransmit नहुँदासम्म *हरेक* stream रोक्छ: HOL blocking केवल HTTP तहबाट TCP मा झर्यो।

**HTTP/3** ले त्यो **QUIC** मा चलेर समाधान गर्छ, जुन **UDP** माथि बनेको नयाँ transport हो। QUIC ले आफैं stream लागू गर्छ, त्यसैले एउटा stream मा हराइले अरूलाई रोक्दैन। यसले transport र TLS handshake पनि मिलाउँछ (1-RTT, resume मा प्रायः 0-RTT) ताकि connection सेटअप छिटो होस्, र **connection migration** समर्थन गर्छ ताकि network परिवर्तन (Wi-Fi → cellular) पछि पनि session बाँचोस्।

## यो किन महत्त्वपूर्ण छ

यो मनपर्ने middle-स्तरको प्रश्न हो किनभने जवाफ *समस्या → सुधार → नयाँ समस्या → सुधार* को कथा हो, जुन ठ्याक्कै एउटा बलियो इन्जिनियरले विकसित हुँदै गरेका सिस्टमबारे तर्क गर्ने तरिका हो। Interviewer ले खोज्ने मुख्य अन्तर्दृष्टि **दुई तहमा head-of-line blocking** बुझ्नु हो: HTTP/2 ले यसलाई application तहमा समाधान गर्यो तर अझै TCP मुनि अड्किएको थियो, र HTTP/3 ले काम टुंग्याउन transport नै बदल्नुपर्यो। यो व्यावहारिक पनि छ: यो थाहा पाउनाले connection पुनःप्रयोग, अझै domain shard गर्ने कि नगर्ने, र CDN मा HTTP/3 सक्षम गरेर के पाइन्छ भन्ने वास्तविक निर्णयलाई मार्गदर्शन गर्छ।

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू