HTTP - 1.1 — methods, status codes, headers, persistent connections: Visual walkthrough

4.3.24 · D2 · Coding › Computer Networks › HTTP - 1.1 — methods, status codes, headers, persistent conn

Step 1 — "One round-trip" ka matlab kya hota hai

KYA HAI. Kisi bhi HTTP baat se pehle, hum us ek unit par agree karte hain jise hum count karenge: round-trip time, jise $RTT$ likhte hain. Yeh woh time hai jitna ek signal ko client se server tak aur wapas jaane mein lagta hai.

YEH UNIT KYUN, seconds kyun nahi? Kyunki network par delay ko dominate karne wali cheez wire ki speed nahi hoti — yeh hoti hai ki do machines kitni door hain. Fibre mein light fixed hoti hai, isliye har "kuch pucho, jawab ka wait karo" ek poori there-and-back lagati hai. RTTs count karna poori story ko machine-independent banata hai: yeh fast desktop par bhi same kaam karta hai aur slow phone par bhi.

PICTURE. Client (left) ek pulse bhejta hai; server (right) ek wapas bhejta hai. Woh poora loop $1 RTT$ hai — neeche ki har cheez ke liye hamara ruler.

Figure — HTTP - 1.1 — methods, status codes, headers, persistent connections

Step 2 — HTTP se pehle chhupa hua cost: the handshake

KYA HAI. TCP woh reliable pipe hai jis par HTTP ride karta hai. Tum ek bhi HTTP byte tab tak nahi bhej sakte jab tak TCP connected nahi ho jaata, aur connect hone mein TCP three-way handshake lagta hai: SYN → SYN-ACK → ACK.

YEH EK RTT KYUN COSTA HAI. Arrows dekho: client ka SYN right jaata hai, server ka SYN-ACK wapas aata hai — yeh already there-and-back = $1 RTT$ ho gaya. Final ACK tumhare pehle real data ke saath ya thoda pehle travel karta hai, isliye hum handshake ko pure setup ka ek RTT count karte hain koi bhi web content move hone se pehle.

PICTURE. Red block dead time hai — tumne ek poora RTT pay kar diya aur abhi tak apne web page ke zero bytes mile hain. Uski height yaad rakho; har nayi connection ise dobara pay karta hai.

Step 3 — HTTP/1.0: har ek file par toll pay karo

KYA HAI. HTTP/1.0 mein har resource ka pattern yeh hai: connection kholo, ek request/response karo, close karo. Next file ke liye repeat karo.

YEH KYUN HURT KARTA HAI. Ek web page ek file nahi hoti — yeh HTML plus $R - 1$ images/scripts/styles hote hain, toh total $R$ resources. Har ek Step 2 ka red setup block aur ek request/response block repeat karta hai. Yeh hai $2$ RTTs per resource, $R$ baar stack kiya.

PICTURE. Staircase dekho: setup (red), fetch, close — phir poori cheez restart. Red toll $R$ baar alag-alag aata hai. Yeh visual repetition hi problem hai.

Step 4 — Idea: pipe ko khula rakho

KYA HAI. HTTP/1.1 ka move draw karne mein embarrassingly simple hai: handshake ek baar karo, phir request ke baad request usi same khuli pipe se bhejo bina close kiye.

YEH KYUN KAAM KARTA HAI. Setup toll (red) villain tha, aur yeh per connection charge hota tha. Agar hum ek connection kholein aur kabhi close na karein, toh red exactly ek baar pay karenge aur phir har extra resource sirf apna request/response loop leta hai.

PICTURE. Shuru mein ek red setup block, phir fetch blocks ki clean run — koi red restarts nahi. Step 3 ki tall staircase se iske chhoti height compare karo.

Step 5 — Saving read off karo

KYA HAI. Persistence ka payoff paane ke liye dono totals subtract karo.

SUBTRACT KYUN. Difference woh wasted time hai jo humne delete ki — red tolls ka stack jo hum ab nahi pay karte.

PICTURE. Dono bars side by side; unke tops ke beech red gap saving hai.

Step 6 — Persistence ki catch: ek body kahan khatam hoti hai?

KYA HAI. HTTP/1.0 mein client ko pata chalta tha ki response khatam hua kyunki server socket close karta tha — end-of-file hi end-of-body marker tha. 1.1 mein hum jaanbujhkar socket khula rakhte hain, toh woh marker chala gaya.

YEH EK REAL BUG KYUN HAI, NITPICK NAHI. Agar ek khuli pipe par do responses back-to-back aate hain aur koi length marker nahi hai, toh client nahi bata sakta ki reply #1 kahan khatam hoti hai aur reply #2 kahan shuru. Woh unhe ek saath jod dega ya forever hang karega ek EOF ka wait karte hue jo kabhi nahi aayega.

PICTURE. Ek pipe se do responses flow ho rahe hain. Bina boundary ke client ek confusing blob dekhta hai (top). Content-Length ke saath use pata hota hai exactly $N$ bytes padhne hain, phir fresh start (bottom).

Step 7 — Edge cases: jab saving shrink ya vanish ho jaaye

KYA HAI. Hum formula $saving = (R - 1) RTT$ ke corners check karte hain taaki koi scenario surprise na kare.

KYUN. Jis formula ko tum apne extremes par nahi toda, woh formula tumne abhi trust nahi kiya.

PICTURE. Teen columns: single-file page, huge page, aur pipelining trick — last par warning label ke saath.

$R = 1$ (ek resource): $saving = (1 - 1) RTT = 0$ . Jab sirf ek file ho toh persistence kuch nahi deta — pipe reuse karne ke liye koi doosri request hi nahi hai. Sahi aur unsurprising.
$R$ bada ho: saving $\to R \cdot RTT$ , toh persistence sabse zyada matter karta hai image-heavy pages par aur high-latency links par (mobile, satellite) — parent ke Forecast-then-Verify wala same conclusion.
Pipelining (agli request pehle reply aane se pehle fire karo): serial $R$ fetches ko $\sim 2 RTT$ tak push karta hai — lekin ek slow pehli reply ab sab ko uske peeche queue mein block kar deti hai. Yeh head-of-line blocking woh flaw hai jise HTTP-2 multiplexing baad mein fix karta hai independent streams ko ek doosre se aage jaane dekar.
Slow start abhi bhi apply hota hai: reused pipe par bhi, TCP slow start ka matlab hai ki early requests ek chhoti congestion window par ride karte hain; persistence grown window ko keep karta hai har baar reset karne ki bajaye — ek doosri, quieter win jo hamara RTT-only model ignore karta hai.

Recall

$R = 1$ degenerate case kyun hai? Persistence pehle file ke baad har file ka setup toll bachata hai ::: sirf ek file ke saath pehle ke baad kuch nahi hota, isliye $(R - 1) = 0$ saved.

Ek-picture summary

Poori story ek frame mein: HTTP/1.0 ka tall red staircase (har file par ek setup toll) versus HTTP/1.1 ka single toll aur uske baad clean fetches — unke beech red gap woh $(R - 1) RTT$ hai jo humne delete kiya, aur small print yeh hai ki har reply ab apni khud ki length carry karni chahiye.

Recall Feynman retelling — seedha bolo

Jab bhi do computers ek fresh connection kholte hain, woh ek full there-and-back sirf hello bolne mein waste karte hain (the handshake). Old HTTP ne har file se pehle hello bola, toh ek 30-image page ne hello 30 baar bola — 30 wasted round-trips. HTTP/1.1 hello ek baar bolta hai aur phir usi line par chatting jaari rakhta hai, toh sirf pehla hello waste hota hai: yeh pehle file ke baad har file ka ek round-trip bachata hai, jo $(R - 1)$ hai. Line khuli rakhne ki sirf ek price hai ki har reply ab apna length pehle bataye, kyunki "main done hun" signal karne ke liye koi hangup nahi karta.

Prev/parent: HTTP/1.1 topic note · Related: TCP three-way handshake · TCP slow start · HTTP-2 multiplexing · Caching, ETag and conditional GET