4.3.24
HTTP ek request–response text protocol hai jo TCP ke upar chalta hai. Isse socho jaise ek polite, structured letter bhejna: tum kehte ho kya action chahiye (the method), kis resource par (the URL path), kaise baat karoge (headers + version), phir shayad ek body bhi attach karo.
Server reply karta hai ek status code ke saath (kaam hua ya nahi?), apne headers ke saath, aur ek body ke saath.
HTTP/1.1 ka sabse bada upgrade 1.0 ke upar persistent connection hai: har ek file ke baad TCP pipe band mat karo — usse khula rakho aur reuse karo.
KYA problem hai: Browsers aur servers ko ek common language chahiye web resources (HTML, images, JSON) maangne aur deliver karne ke liye. Ek agreed format ke bina, har site alag tarah se baat karti.
1.1 kyun 1.0 se behtar hai: HTTP/1.0 mein, har request ne ek naya TCP connection khola, ek exchange kiya, phir band ho gaya. 30 images wala ek page = 30 TCP handshakes (har ek mein ek full round-trip + slow-start ka cost). Yeh brutally slow hai. HTTP/1.1 isko fix karta hai persistent connections aur pipelining se, saath hi mandatory Host header se (taaki ek IP kaafi saari sites serve kar sake = virtual hosting).
Hum message format ko requirements se DERIVE karte hain, yaad nahi karte.
Humein ek action verb + target + version chahiye → yeh hai start line .
Humein metadata chahiye (length, type, cookies…) → header lines Name: Value.
Humein ek separator chahiye taaki parser ko pata chale ki headers khatam hue → ek blank line (CRLF CRLF) .
Optional mein ek payload → body .
Worked example Ek raw GET requestGET /index.html HTTP/1.1\r\n
Host: example.com\r\n
User-Agent: curl/8.0\r\n
Accept: text/html\r\n
\r\n
Host line kyun?mandatory hai — ek server IP kaafi saare domains host kar sakta hai, isliye server ko pata hona chahiye ki tum kaun si site maang rahe ho.
Final empty \r\n kyun? Yeh signal karta hai "headers khatam" — GET mein koi body nahi hoti, isliye message wahan khatam hota hai.
Worked example Ek raw responseHTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Length: 13\r\n
\r\n
Hello, world!
Content-Length: 13 kyun?persistent connection par socket khula rehta hai, isliye client "connection closed" use karke yeh nahi jan sakta ki body khatam hui. Length header (ya chunked encoding) bata deta hai ki exactly kitne bytes padhne hain. Yahi persistence ka dil hai.
Definition Common methods
GET — ek resource retrieve karo. Safe (koi side effects nahi) & idempotent .HEAD — GET jaisa but sirf headers, koi body nahi . Size/freshness check karne ke liye use hota hai.POST — data submit karo; create/process karo. Idempotent nahi , safe nahi .PUT — URL par resource ko body se replace karo. Idempotent .DELETE — resource ko remove karo. Idempotent .OPTIONS — poochho ki kaun se methods/capabilities allowed hain.PATCH — partial update karo.
Intuition Idempotent vs SafeSafe = server state nahi badalta (tum ise prefetch kar sakte ho). Idempotent = isse N baar karna tumhe wahi final state mein rakhta hai jaise ek baar karne se. PUT "set X=5" bar bar karne par bhi X=5 rehta hai (idempotent). POST "append order" bar bar karne se kaafi saare orders ban jaate hain (idempotent nahi). Isliye browsers POST resubmit karne se pehle warn karte hain lekin GET ko freely retry karte hain.
Pehla digit class batata hai — yahi 80/20 hai jo tumhe pakka yaad karna hai:
Class
Meaning
Examples
1xxInformational
100 Continue
2xxSuccess
200 OK, 201 Created, 204 No Content
3xxRedirection
301 Moved Permanently, 304 Not Modified
4xxClient error400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xxServer error500 Internal Server Error, 503 Service Unavailable
Intuition Split ke liye Mnemonic4xx = "tumne gadbad ki", 5xx = "maine gadbad ki". Agar yaad rahe ki kaun si side galti par hai, tum 80% HTTP issues turant debug kar sakte ho.
Host: — target domain (required 1.1 mein).Content-Type: — body ka MIME type (text/html, application/json).Content-Length: — body ka size bytes mein (persistent connection framing ke liye zaroori).Transfer-Encoding: chunked — body ko stream karo bina total length jaane.Connection: keep-alive / close — control karo ki TCP socket persist kare ya nahi.Cache-Control, ETag, If-None-Match, Last-Modified — caching/conditional requests.Cookie: / Set-Cookie: — ek stateless protocol par session state.
Ek TCP connection kholne ka cost hai ek 3-way handshake = 1 round-trip (RTT) kuch bhi bhejna shuru karne se pehle, saath mein TCP slow-start bandwidth dhire dhire badhata hai. Isliye ek connection ko kaafi saari requests ke liye reuse karna us cost ko amortize karta hai. HTTP/1.1 mein, keep-alive default hai ; tum sirf Connection: close add karte ho opt out karne ke liye.
WHY framing matters: Agar socket kabhi band nahi hota, "body woh sab hai jo EOF se pehle aata hai" ab kaam nahi karta. Isliye har response ko apni length Content-Length ke zariye ZAROOR declare karni chahiye ya Transfer-Encoding: chunked use karna chahiye. Iske bina, client ko nahi pata ki ek response kahan khatam hota hai aur agla kahan shuru hota hai.
Pipelining (agla request bhejna pehle reply aane se pehle) isko aur kam karta hai ∼ 2 RTT head-of-line blocking ka shikar hota hai (pehli slow response ke wajah se peeche ki saari responses ruk jaati hain usi connection par) — yahi exactly woh flaw hai jo HTTP/2 multiplexing baad mein solve karta hai.
Recall Forecast-then-VerifyFormula padhne se pehle: andaza lagao — kya connection khula rakhna zyada time bachata hai jab RTT bada ho ya chhota? Verify karo: saving = ( R − 1 ) ⋅ RTT ke saath scale karta hai — high-latency links (mobile, satellite) par zyada. Tumhara intuition ki "slow networks sabse zyada faayda uthate hain" bilkul sahi hai.
Common mistake "GET requests mein body nahi ho sakti, isliye inhe safely retry kiya ja sakta hai."Kyun sahi lagta hai: GET mein aam taur par koi body nahi hoti aur yeh read-only hota hai. GET safe hone ki asli wajah semantic contract (koi side effects nahi) hai, body ki absence nahi. Fix: Safety meaning ke baare mein hai, message shape ke baare mein nahi. Ek server jo GET par state mutate karta hai woh broken hai, spec nahi.
Connection: keep-alive HTTP/1.1 mein socket khula rakhne ke liye zaroori hai."
Kyun sahi lagta hai: Tum ise 1.0 examples mein dekhte ho. Fix: 1.1 mein persistence default hai — tum sirf Connection: close bhejte ho end karne ke liye. Keep-alive header ek 1.0 relic hai.
Common mistake "404 ka matlab hai server crash ho gaya."Kyun sahi lagta hai: Yeh ek "error" hai. Fix: 4xx = client error. 404 ka matlab hai server theek hai lekin joh resource tumne maanga woh exist nahi karta. Server crashes 5xx hote hain.
Common mistake "Persistent connections par client socket band hone tak padhta rehta hai."Kyun sahi lagta hai: Exactly aise hi HTTP/1.0 mein kaam hota tha. Fix: Persistence ke saath socket band nahi hota, isliye body end dhundne ke liye tumhe ZAROOR Content-Length ya chunked encoding use karni chahiye.
HTTP/1.1 ne kya cheez default bana di jo HTTP/1.0 ne nahi ki? Persistent (keep-alive) TCP connections — ek socket ko kaafi saari requests ke liye reuse karo.
HTTP/1.1 mein kaun sa header mandatory ho gaya aur kyun? Host: — virtual hosting support karne ke liye (ek IP par kaafi saare domains).
Status code ka pehla digit tumhe kya batata hai? Class: 1xx info, 2xx success, 3xx redirect, 4xx client error, 5xx server error.
Safe aur idempotent mein kya farq hai? Safe = koi server state change nahi; idempotent = N calls = 1 call jaisa same final state.
Kya POST idempotent hai? Nahi — ise repeat karne se duplicate resources ban sakte hain.
Ek persistent connection ko Content-Length ya chunked encoding kyun CHAHIYE? Socket kabhi band nahi hota, isliye client EOF use karke yeh nahi jan sakta ki body kahan khatam hoti hai.
HTTP/1.1 pipelining mein head-of-line blocking kya hai? Ek slow pehli response usi connection par peeche ki saari queued responses ko rok deti hai.
404 vs 500 — kaun galat hai? 404 = client (resource nahi mila); 500 = server (internal error).
HTTP/1.1 mein persistence se OPT OUT kaise karte ho? Connection: close bhejo.
HTTP message mein header section kahan khatam hota hai? Ek blank line (CRLF CRLF) se.
R resources fetch karne mein 1.0 vs 1.1 mein roughly kitne RTTs lagte hain (toy model)? 1.0 ≈ 2R·RTT; 1.1 ≈ (R+1)·RTT.
Recall Feynman: 12-saal ke bachche ko explain karoSocho tum kisi counter par khaana order kar rahe ho. Tum apna order chillate ho (method + kya chahiye ), cook ek number chillata hai jiska matlab hai "ho gaya!", "yeh nahi hai!", ya "maine kitchen jala diya!" (status code ). Purana HTTP/1.0 tumhe har ek item ke liye counter tak poora jaana padta tha — bahut thakane wala. HTTP/1.1 kehta hai: counter par hi raho aur order karte raho (persistent connection ). Lekin ab cook ko batana padega "yeh dish 13 chamach bhari hai" (Content-Length ) taaki tumhe pata chale ki ek dish kahan khatam hoti hai aur agli kahan shuru hoti hai, kyunki tum line kabhi nahi chhodte.
"Verb, Version, Vacancy" ek request line ke liye: V erb (GET), resource, V ersion (HTTP/1.1) — phir ek V acancy (blank line) body se pehle.
Status classes ke liye: 1 In, 2 Great, 3 Go-elsewhere, 4 You-flubbed, 5 I-flubbed.
TCP three-way handshake — woh cost jo persistent connections amortize karte hain.TCP slow start — kyun ek warmed-up connection reuse karna faster hai.HTTP-2 multiplexing — 1.1 pipelining ka head-of-line blocking fix karta hai.TLS handshake — aur bhi zyada RTTs add karta hai, isliye HTTPS ke liye persistence aur important hai.DNS resolution — pehle HTTP request se pehle hota hai.Caching, ETag and conditional GET — 304 Not Modified use karta hai.Virtual hosting — mandatory Host header se enable hota hai.
new TCP per request = slow
mandatory for virtual hosting
tells client bytes to read
HTTP 1.1 request-response
