HTTP/1.1, HTTP/2, અને HTTP/3 વચ્ચે શું તફાવત છે?

Question

IT Interview Practice · Accepted Answer

ત્રણેય એ જ HTTP semantics (methods, headers, status codes) આપે છે પણ *કેવી રીતે* તેઓ wire પર bytes ખસેડે છે તેમાં અલગ છે — દરેક 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 મોકલે છે; browsers આની આસપાસ host દીઠ ~6 parallel connections ખોલીને કામ કરે છે, અને text headers uncompressed મોકલાય છે. **HTTP/2** **multiplexing** ઉમેરે છે — એક જ connection પર ઘણા સમવર્તી **streams** — વત્તા binary framing, header compression (HPACK), અને server push. પણ કારણ કે તે હજુ TCP પર ચાલે છે, એક જ lost packet retransmit થાય ત્યાં સુધી *દરેક* stream ને block કરે છે: HOL blocking માત્ર HTTP layer થી નીચે TCP પર ખસ્યું.

**HTTP/3** તેને **QUIC** પર ચલાવીને ઉકેલે છે, જે **UDP** પર બનેલો નવો transport છે. QUIC streams ને પોતે અમલમાં મૂકે છે, તેથી એક stream પર loss બીજાઓને ઠપ કરતું નથી. તે ઝડપી connection setup માટે transport અને TLS handshakes ને પણ merge કરે છે (1-RTT, resume પર ઘણી વાર 0-RTT), અને **connection migration** ને support કરે છે જેથી network ફેરફાર (Wi-Fi → cellular) માં session ટકી રહે.

## આ શા માટે મહત્વનું છે

આ એક પ્રિય middle-level પ્રશ્ન છે કારણ કે જવાબ *સમસ્યા → ઠીક → નવી સમસ્યા → ઠીક* ની વાર્તા છે, જે બરાબર એ રીતે છે જે રીતે એક મજબૂત engineer વિકસતી systems વિશે વિચારે છે. Interviewers જે મુખ્ય સૂઝ શોધે છે તે **બે સ્તરે head-of-line blocking** સમજવાની છે: HTTP/2 એ તેને application layer પર ઉકેલી પણ હજુ TCP હેઠળ ફસાયેલું હતું, અને HTTP/3 એ કામ પૂરું કરવા transport ને જ બદલવો પડ્યો. તે વ્યાવહારિક પણ છે: આ જાણવું connection reuse, domains ને હજુ shard કરવા કે નહીં, અને તમારા CDN પર HTTP/3 સક્ષમ કરવાથી શું મળે તે વિશેના વાસ્તવિક નિર્ણયોને દોરે છે.

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો