Top 26 HTTP, HTTPS, and DNS Interview Questions (2026)

Last Updated: June 2026 | Level: Beginner to Advanced | Format: Q&A with Request/Response Examples

HTTP, HTTPS, and DNS are the backbone of every web application. Candidates report these topics appearing in backend SDE, DevOps, and full-stack interviews at companies including Zomato, Swiggy, Razorpay, and Freshworks. Based on public preparation resources and candidate-reported accounts, "what happens when you type a URL" and HTTP status code scenarios appear in nearly every web backend interview.

---

Table of Contents

1. HTTP Fundamentals (Q1-Q10)
2. HTTPS and TLS (Q11-Q16)
3. DNS Deep Dive (Q17-Q22)
4. Caching and Performance (Q23-Q26)

---

HTTP Fundamentals

Q1. What is HTTP? What are its key characteristics? Easy

HTTP (HyperText Transfer Protocol) is the application-layer protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication on the web.

Key characteristics:

Property	Description
Client-server	Client (browser) requests; server responds
Stateless	Each request is independent; server retains no client state between requests
Request-response	One request generates one response
Text-based	HTTP/1.x headers are human-readable text
Connectionless (HTTP/1.0)	Original HTTP: new connection per request; HTTP/1.1 adds Keep-Alive

HTTP/1.1 persistent connections: The TCP connection is reused for multiple requests (unless Connection: close header is set). Reduces connection establishment overhead.

---

Q2. What are HTTP methods? Explain each. Easy

Method	Purpose	Request Body	Idempotent	Safe	Cacheable
GET	Retrieve resource	No	Yes	Yes	Yes
POST	Create resource, submit data	Yes	No	No	No (usually)
PUT	Replace entire resource	Yes	Yes	No	No
PATCH	Partial update	Yes	No	No	No
DELETE	Delete resource	No (optional)	Yes	No	No
HEAD	Like GET but no body (headers only)	No	Yes	Yes	Yes
OPTIONS	Get supported methods (CORS preflight)	No	Yes	Yes	No
TRACE	Diagnostic (echo request)	No	Yes	Yes	No

Idempotent: Calling the method N times produces the same result as calling it once. DELETE twice: second delete finds nothing (error), but state is same as after first delete.

Safe: Does not modify server state (GET, HEAD, OPTIONS, TRACE).

---

Q3. What are the important HTTP status codes? Easy

1xx Informational:

100 Continue    - Server ready, client should proceed with request body
101 Switching   - Protocol switch (e.g., HTTP -> WebSocket)

2xx Success:

200 OK          - Standard success
201 Created     - Resource created (POST/PUT response with Location header)
204 No Content  - Success with no body (DELETE response)
206 Partial     - Range request success

3xx Redirection:

301 Moved Permanently  - URL changed permanently (update bookmarks)
302 Found              - Temporary redirect (keep original URL)
304 Not Modified       - Cached version is valid (conditional GET)
307 Temporary Redirect - Like 302 but method preserved
308 Permanent Redirect - Like 301 but method preserved

4xx Client Error:

400 Bad Request        - Malformed request syntax
401 Unauthorized       - Authentication required
403 Forbidden          - Authenticated but no permission
404 Not Found          - Resource does not exist
405 Method Not Allowed - Method not supported for this resource
409 Conflict           - State conflict (duplicate create, version mismatch)
422 Unprocessable      - Semantic validation failed
429 Too Many Requests  - Rate limiting

5xx Server Error:

500 Internal Server Error - Generic server failure
502 Bad Gateway           - Upstream server failure (reverse proxy)
503 Service Unavailable   - Server overloaded or maintenance
504 Gateway Timeout       - Upstream server timeout

---

Q4. What are HTTP request and response headers? List the most important ones. Medium

Important Request Headers:

Header	Example	Meaning
Host	Host: www.example.com	Target host (required in HTTP/1.1)
Content-Type	Content-Type: application/json	MIME type of request body
Content-Length	Content-Length: 42	Body size in bytes
Authorization	Authorization: Bearer <token>	Authentication credentials
Accept	Accept: application/json, text/html	Acceptable response formats
Cookie	Cookie: session=abc123	Client cookies
Cache-Control	Cache-Control: no-cache	Caching directives
If-None-Match	If-None-Match: "abc123"	Conditional request (ETag)
If-Modified-Since	If-Modified-Since: Sat, 29 Oct 2026 00:00:00 GMT	Conditional request (time)
User-Agent	User-Agent: Mozilla/5.0...	Client identification

Important Response Headers:

Header	Example	Meaning
Content-Type	Content-Type: application/json; charset=utf-8	Response body MIME type
Cache-Control	Cache-Control: max-age=3600	Cache duration
ETag	ETag: "abc123"	Resource version token
Location	Location: /new-url	Redirect target
Set-Cookie	Set-Cookie: session=xyz; HttpOnly; Secure	Set browser cookie
Access-Control-Allow-Origin	Access-Control-Allow-Origin: *	CORS policy
Strict-Transport-Security	HSTS: max-age=31536000	Force HTTPS

---

Q5. What is REST? What are RESTful API constraints? Medium

REST (Representational State Transfer) is an architectural style for designing web APIs. A RESTful API uses HTTP methods and URIs to manipulate resources.

6 REST constraints (Fielding's dissertation):

1. Client-Server: Separation of UI and data storage concerns.
2. Stateless: No client session stored on server. Each request contains all needed info.
3. Cacheable: Responses must be labeled cacheable or non-cacheable.
4. Layered System: Client cannot tell if directly connected to server (may be proxy, LB, CDN).
5. Uniform Interface: Resources identified by URIs; manipulated via representations; self-descriptive messages; HATEOAS (links to related actions in responses).
6. Code on Demand (optional): Server can send executable code to client (JavaScript).

REST conventions:

GET    /users          -> list all users
GET    /users/42       -> get user 42
POST   /users          -> create new user
PUT    /users/42       -> replace user 42
PATCH  /users/42       -> partial update user 42
DELETE /users/42       -> delete user 42

---

Q6. What is the difference between GET and POST? Easy

Aspect	GET	POST
Data location	Query string in URL	Request body
Data visibility	Visible in URL, browser history, server logs	Hidden (but not encrypted without HTTPS)
Length limit	URL length limit (~2000 chars in browsers)	No practical limit
Idempotency	Idempotent (repeating gives same result)	Not idempotent
Caching	Cached by browsers/proxies	Not cached by default
Bookmarkable	Yes (URL contains query)	No (body not saved)
Use case	Data retrieval, search	Create/update operations, login, file upload

---

Q7. What is CORS? Why is it needed? Medium

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which cross-origin (different domain) requests are allowed.

Same-origin policy (the problem CORS solves): Browsers block JavaScript from making requests to a different origin (scheme + domain + port) than the page's origin.

Page at: https://myapp.com
Tries to fetch: https://api.other.com/data  <- BLOCKED by browser (different origin)

CORS preflight: For non-simple requests (PUT, DELETE, custom headers), browser first sends:

OPTIONS https://api.other.com/data
Origin: https://myapp.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Content-Type, Authorization

Server responds with what it allows:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 3600  (cache preflight for 1 hour)

Browser proceeds with the actual DELETE request only if response grants permission.

---

Q8. What is HTTP Keep-Alive vs connection: close? Easy

• Connection: keep-alive (HTTP/1.1 default): The TCP connection is reused for multiple HTTP requests. Reduces latency (no new TCP handshake per request).
• Connection: close: TCP connection closed after response. Forces new handshake for next request.

HTTP/2: Uses a single TCP connection with multiplexed streams. Keep-alive is effectively always on.

Pipeline: HTTP/1.1 pipelining allows multiple requests without waiting for responses, but head-of-line blocking (response must come in order) limits effectiveness. HTTP/2 solves this with independent streams.

---

Q9. What happens when you type a URL and press Enter? Medium

Complete flow:

1. URL Parsing: Browser parses the URL into scheme, host, path, query.
   https://www.example.com/products?id=42

2. DNS Resolution:
   Browser cache -> OS cache -> Recursive resolver -> Root -> TLD -> Authoritative
   Result: www.example.com = 93.184.216.34

3. TCP Connection: Browser opens TCP socket to 93.184.216.34:443
   Three-way handshake: SYN -> SYN-ACK -> ACK

4. TLS Handshake (HTTPS):
   ClientHello -> ServerHello + Certificate -> Certificate verify + Key exchange -> Finished
   Encrypted channel established.

5. HTTP Request:
   GET /products?id=42 HTTP/2
   Host: www.example.com
   Accept: text/html,application/xhtml+xml
   Cookie: session=xyz

6. Server Processing:
   DNS -> Load balancer -> Web server -> Application server -> Database
   Application returns JSON/HTML response.

7. HTTP Response:
   HTTP/2 200 OK
   Content-Type: text/html; charset=utf-8
   Cache-Control: max-age=3600
   [HTML body]

8. Browser Rendering:
   Parse HTML -> DOM tree
   Download CSS -> CSSOM
   Execute JavaScript
   Render page (DOM + CSSOM -> render tree -> layout -> paint)
   Fetch sub-resources (images, scripts, CSS) in parallel

---

Q10. What is WebSocket? How does it differ from HTTP? Medium

WebSocket is a full-duplex communication protocol over a single TCP connection, enabling real-time bidirectional communication.

HTTP vs WebSocket:

Aspect	HTTP	WebSocket
Communication	Request-response (client initiates)	Full-duplex (either side can send)
Connection	Per request (or Keep-Alive for multiple requests)	Persistent single connection
Overhead	Headers on every request	Minimal framing after handshake
Latency	Round trip per message	Low (connection already established)
Use case	REST APIs, web pages	Chat, live scores, stock tickers, gaming

WebSocket handshake (upgrade from HTTP):

Client:
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After the upgrade, the TCP connection is used for bidirectional WebSocket frames.

---

HTTPS and TLS

Q11. What is TLS? How does the TLS handshake work? Medium

TLS (Transport Layer Security) is the cryptographic protocol providing encryption, authentication, and integrity for HTTPS (and other protocols).

TLS 1.3 handshake (1 RTT):

Client -> Server:
  ClientHello:
    - TLS version: 1.3
    - Supported cipher suites: TLS_AES_256_GCM_SHA384, ...
    - Client random (32 bytes)
    - Key share (Diffie-Hellman public key for supported groups)

Server -> Client:
  ServerHello:
    - Selected cipher suite
    - Server random
    - Key share (DH public key) -> session keys derivable now
  {Certificate}: server's public key + identity
  {CertificateVerify}: signature proving possession of private key
  {Finished}: MAC of entire handshake

Client:
  Verify certificate against trusted CAs
  Derive session keys from DH exchange
  {Finished}: MAC of entire handshake

HTTP data now flows encrypted with symmetric session keys.

Why TLS 1.3 is faster: Removed non-PFS cipher suites. Client sends key share in first message (no extra round trip for key negotiation). 0-RTT available for session resumption.

---

Q12. What is a digital certificate? What does it contain? Medium

A digital certificate (X.509 certificate) is a document that binds a public key to an identity (domain name, organization).

Certificate contents:

Subject: CN=www.example.com, O=Example Inc, C=IN
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Valid From: 2026-01-01
Valid To: 2026-04-01
Public Key: RSA 2048-bit or ECC P-256 key
Subject Alternative Names (SAN): www.example.com, example.com
Signature Algorithm: SHA256withRSA
Certificate Signature: <Issuer's digital signature>

Certificate chain:

Root CA (self-signed, pre-installed in browsers)
  -> Intermediate CA (signed by Root CA)
    -> Server Certificate (signed by Intermediate CA)

Browsers trust certificates if the chain leads to a trusted Root CA.

Certificate Transparency (CT): All public certificates must be logged in public CT logs. Browsers check logs. Prevents mis-issuance of fraudulent certificates.

---

Q13. What is HSTS? Easy

HSTS (HTTP Strict Transport Security) is a web security mechanism that forces browsers to use HTTPS for all future connections to a domain.

Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

How it works:

1. First HTTPS visit: server sends HSTS header.
2. Browser records: "example.com must always use HTTPS for 365 days."
3. Future HTTP requests to example.com: browser internally redirects to HTTPS before connecting.
4. Protection: Even if user types http:// or clicks an HTTP link, the browser uses HTTPS automatically. Prevents SSL stripping attacks.

HSTS Preload: Domain submits to browser-maintained HSTS preload list. Browsers ship with the list. Even the first visit is HTTPS (no opportunity for initial HTTP redirect attack).

---

Q14. What is certificate pinning? Hard

Certificate pinning is a security technique where an application hardcodes the expected server certificate (or public key) and rejects connections if the certificate does not match, even if it is signed by a trusted CA.

Why it matters: If a CA is compromised or coerced, it could issue a fraudulent certificate for any domain. A browser would trust it. Certificate pinning prevents this by only accepting the specific known certificate.

HTTP Public Key Pinning (HPKP): Deprecated (misuse caused self-denial of service). Replaced by Certificate Transparency monitoring.

In mobile apps: Common in banking and fintech apps. The app bundle includes the server's public key hash. Network code validates hash on every connection.

// Android OkHttp example:
CertificatePinner pinner = new CertificatePinner.Builder()
    .add("api.mybank.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .build();
OkHttpClient client = new OkHttpClient.Builder()
    .certificatePinner(pinner)
    .build();

Risk: If the certificate changes (renewal with different key), the app rejects connections until updated. Requires careful rollout with backup pins.

---

Q15. What is the difference between symmetric and asymmetric encryption in TLS? Medium

Aspect	Symmetric	Asymmetric
Keys	Same key for encrypt and decrypt	Public key encrypts; private key decrypts (or vice versa)
Speed	Fast (AES: billions of bytes/sec on modern CPU)	Slow (RSA: thousands of operations/sec)
Key distribution	Problem: how to share the secret key securely?	Solved: public key can be shared openly
Used in TLS for	Bulk data encryption (session keys)	Handshake: authentication + session key establishment

TLS uses both:

1. Asymmetric (during handshake): Server's public key (from certificate) used in key exchange. Asymmetric operations authenticate the server and allow secure derivation of session keys.
2. Symmetric (during data transfer): Derived session keys (AES-256 or ChaCha20) encrypt actual HTTP data. Fast, efficient.

Key exchange: Diffie-Hellman (DH) in TLS 1.3 allows both sides to derive the same session key without ever transmitting it. Even if all traffic is recorded, future decryption is not possible (Perfect Forward Secrecy).

---

Q16. What is SNI (Server Name Indication)? Hard

SNI is a TLS extension that allows a client to specify the hostname it is trying to connect to at the beginning of the TLS handshake.

Problem without SNI: A single IP address hosts multiple HTTPS domains. Which certificate should the server present during TLS handshake (before HTTP request is read)?

SNI solution: Client includes the hostname in the TLS ClientHello message:

ClientHello:
  server_name: www.example.com

Server selects the correct certificate for that hostname and presents it. Enables virtual hosting of multiple HTTPS domains on a single IP.

Encrypted SNI (ESNI / ECH): SNI is currently sent in plaintext, revealing which site the client is connecting to (visible to network observers despite HTTPS). Encrypted Client Hello (ECH, RFC 8744) encrypts the SNI using the server's public key from DNS, hiding the target domain.

---

DNS Deep Dive

Q17. What is DNS TTL and how does it affect updates? Easy

DNS TTL (Time to Live) is the number of seconds a DNS record can be cached by resolvers before they must re-query the authoritative nameserver.

google.com. 300 IN A 142.250.195.14
                ^^^
                TTL = 300 seconds (5 minutes)

Effects of TTL:

• Low TTL (60-300s): Changes propagate quickly. Good before planned migrations. Higher load on authoritative nameservers.
• High TTL (3600-86400s): Cached widely, fewer queries to authoritative server. DNS changes take hours to propagate globally.

Best practice for migrations:

1. Lower TTL to 300s one week before the change.
2. Make the DNS change.
3. Old TTL expires in 5 minutes, all resolvers get new IP.
4. After migration stable, raise TTL back to 3600+.

---

Q18. What is a CNAME record? What are its limitations? Medium

CNAME (Canonical Name) is a DNS record that maps one domain name to another (alias to canonical name).

www.example.com  CNAME  example.com
blog.example.com CNAME  myblog.wordpress.com
api.example.com  CNAME  myapi.us-east-1.elb.amazonaws.com  (AWS ELB)

CNAME limitations:

1. Cannot coexist with other records: If example.com has a CNAME, it cannot have an MX, A, or NS record (conflicts at the DNS zone apex).
2. Zone apex restriction: You cannot use CNAME for the root domain (example.com). Only for subdomains (www.example.com, api.example.com).
3. Extra DNS lookup: Resolving a CNAME requires an additional DNS query to resolve the target name.

ALIAS / APEX CNAME workaround: Some DNS providers (Route 53, Cloudflare) offer ALIAS or ANAME records that behave like CNAME at the zone apex but are resolved server-side (no extra client lookup).

---

Q19. What is reverse DNS? Medium

Reverse DNS resolves an IP address to a domain name (opposite of normal DNS which resolves name to IP).

Implementation: The in-addr.arpa domain. For IP 192.0.2.50:

Reverse DNS query: 50.2.0.192.in-addr.arpa
Answer: mail.example.com  (PTR record)

PTR record:

50.2.0.192.in-addr.arpa. PTR mail.example.com.

Who sets it? The ISP or organization that owns the IP block sets PTR records. You cannot set PTR records unless you own the IP address (unlike A/CNAME records which anyone with the domain can set).

Use cases:

• Email spam filtering: Mail servers check that the sending IP's PTR record matches the domain in the email headers. No PTR = likely spam.
• Network troubleshooting: traceroute shows hostnames instead of IPs for hops with PTR records.
• Access control: Some services restrict access to IPs with valid PTR records.

---

Q20. What is DNSSEC? Hard

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that DNS responses are authentic and have not been tampered with.

The problem: Standard DNS has no authentication. An attacker can intercept DNS queries and return forged responses (DNS spoofing / cache poisoning). Client browser gets a fraudulent IP and connects to an attacker's server.

How DNSSEC works:

1. Domain owner signs all DNS records with a private key (ZSK: Zone Signing Key).
2. The ZSK's public key is published in a DNSKEY record.
3. A Key Signing Key (KSK) signs the DNSKEY record.
4. The parent zone (TLD) signs a DS record pointing to the child's KSK.
5. Chain of trust from root zone to domain.

Resolver validation:

1. Resolver gets an A record.
2. Gets the corresponding RRSIG signature.
3. Gets DNSKEY public key.
4. Verifies signature. If valid: record is authentic.
5. Validates the chain up to the root (root zone's key is pre-trusted in resolvers).

DNSSEC does NOT encrypt DNS data (addresses that with DNS-over-TLS or DNS-over-HTTPS). It only provides data origin authentication and integrity.

---

Q21. What is DNS load balancing? What are its limitations? Medium

DNS load balancing distributes traffic across multiple servers by returning different IP addresses for the same domain name.

Round-robin DNS:

api.example.com  A  10.0.0.1
api.example.com  A  10.0.0.2
api.example.com  A  10.0.0.3

Each DNS query rotates through the IPs. DNS resolvers return all IPs; client typically uses the first.

Limitations:

1. No health checking: DNS returns IPs regardless of server health. If server 10.0.0.2 goes down, DNS still returns it until the record is manually removed.
2. Caching: TTL means changes (like removing a failed server) take time to propagate.
3. Uneven distribution: Clients may cache one IP longer than another. Mobile users behind NAT may all get the same IP.
4. No session affinity: Each DNS lookup may return a different IP; user sessions can switch servers.

Better alternatives: Load balancers (Layer 4 or Layer 7) with health checks and session persistence. DNS is only for geographic routing or initial load distribution, not fine-grained LB.

---

Q22. What is GeoDNS and how is it used by CDNs? Hard

GeoDNS returns different DNS responses based on the geographic location of the DNS resolver (and by proxy, the user).

How it works:

1. DNS query arrives at authoritative nameserver.
2. Nameserver checks the requester's IP geolocation.
3. Returns the IP of the nearest/best server for that location.

User in Mumbai queries example.com:
  -> Resolver in Mumbai sends query
  -> Authoritative server sees: resolver = Mumbai
  -> Returns: 103.21.244.1 (CDN edge in Mumbai)

User in New York queries example.com:
  -> Resolver in New York sends query
  -> Authoritative server sees: resolver = New York
  -> Returns: 104.21.50.1 (CDN edge in New York)

CDN use (Cloudflare, AWS CloudFront, Akamai): CDN has hundreds of edge locations globally. GeoDNS routes users to the nearest edge PoP (Point of Presence), minimizing latency.

DNS Anycast: A single IP address is advertised from multiple network locations. BGP routing ensures traffic reaches the nearest location. Cloudflare's 1.1.1.1 DNS resolver uses anycast.

---

Caching and Performance

Q23. What are HTTP caching headers? Medium

Cache-Control:

Cache-Control: max-age=3600         -- Cache for 1 hour
Cache-Control: no-cache             -- Must revalidate before using cached copy
Cache-Control: no-store             -- Never cache (sensitive data)
Cache-Control: private              -- Only browser cache, not shared (CDN) caches
Cache-Control: public               -- Any cache can store
Cache-Control: s-maxage=86400       -- CDN/shared cache max age (overrides max-age for CDNs)
Cache-Control: must-revalidate      -- Must check with server when stale
Cache-Control: stale-while-revalidate=60  -- Serve stale up to 60s while revalidating async

ETag (Entity Tag):

Server response:   ETag: "abc123"
Next request:      If-None-Match: "abc123"
Server response:   304 Not Modified (if unchanged) or 200 OK with new content + new ETag

Last-Modified:

Server response:   Last-Modified: Mon, 01 Jun 2026 00:00:00 GMT
Next request:      If-Modified-Since: Mon, 01 Jun 2026 00:00:00 GMT
Server response:   304 Not Modified (if unchanged)

Expires (older):

Expires: Mon, 08 Jun 2026 12:00:00 GMT  -- Absolute expiry time (less preferred, timezone issues)

---

Q24. What is a CDN? How does it work? Medium

A CDN (Content Delivery Network) is a distributed network of servers that cache and serve content from locations geographically close to users.

How CDN works:

Without CDN:
User in Mumbai -> Origin server in US East -> 200ms round trip

With CDN (Cloudflare/Akamai):
User in Mumbai -> CDN edge in Mumbai
  If cached: served directly from edge -> ~5ms
  If not cached: edge fetches from origin US East (200ms) -> caches it
  Subsequent requests from Mumbai users -> served from edge (<5ms)

CDN benefits:

• Reduced latency (geographic proximity).
• Reduced origin load (edge handles popular requests).
• DDoS mitigation (distributed capacity absorbs attacks).
• SSL/TLS termination at edge (reduces origin compute).
• Automatic gzip/brotli compression.

CDN caching strategy:

• Static assets (images, CSS, JS): long TTL (1 year with content-hashed URLs).
• API responses: short TTL or no cache.
• HTML pages: short TTL or cache with stale-while-revalidate.

---

Q25. What is HTTP/2 and what problems does it solve? Medium

HTTP/2 (RFC 7540, 2015) addresses HTTP/1.1 performance problems:

Problem	HTTP/1.1	HTTP/2 solution
Head-of-line blocking	Only one response at a time per connection	Multiplexing: multiple streams on one connection
Multiple connections	Browsers open 6+ parallel connections per domain	One connection, multiple streams
Large headers	Repeated on every request (uncompressed)	HPACK header compression (60-90% reduction)
No prioritization	All requests equal	Stream prioritization (CSS > images)
No push	Client must request each resource	Server push: push JS/CSS without client request

Multiplexing:

HTTP/1.1 with pipelining:
Connection:  REQ1 -> REP1 -> REQ2 -> REP2 (sequential even with pipelining)

HTTP/2 multiplexed streams:
Connection:  Stream1.REQ -> Stream2.REQ -> Stream3.REQ
             Stream2.REP -> Stream1.REP -> Stream3.REP  (any order)

---

Q26. What is HTTP/3 and QUIC? Hard

HTTP/3 (RFC 9114, 2022) uses QUIC as the transport layer instead of TCP.

Remaining HTTP/2 problem: HTTP/2 solved application-level HOL blocking but TCP-level HOL blocking remains. If one TCP packet is lost, all HTTP/2 streams on that connection are blocked waiting for retransmission.

QUIC improvements:

• Runs over UDP (no TCP stack in OS required).
• Streams are independent at the transport level; one lost UDP packet only blocks its own QUIC stream.
• Built-in TLS 1.3 (1 RTT connection establishment, vs TCP+TLS = 2 RTTs).
• Connection migration: phone switching from Wi-Fi to 4G keeps connection alive (connection ID based, not 4-tuple based).
• 0-RTT session resumption for returning clients.

Adoption: Cloudflare, Google, and Meta report that HTTP/3 is used for a large share of their traffic where client and server both support it. Chrome negotiates QUIC using Alt-Svc response header.

---

FAQ

Q: What is the difference between 401 and 403 status codes? 401 Unauthorized means authentication is required (no valid credentials provided). 403 Forbidden means authentication succeeded (or is not needed) but the user lacks permission for this resource.

Q: What is the difference between a session cookie and a persistent cookie? Session cookies have no expiry; they are deleted when the browser closes. Persistent cookies have an explicit expiry date and persist across browser restarts.

Q: Why do browsers limit concurrent connections per domain to 6-8? Without a limit, a browser could open hundreds of connections to one server (server-side DoS). HTTP/2 effectively removes this limit by multiplexing many requests on one connection.

---

Related PapersAdda guides:

• TCP/IP Interview Questions 2026
• OSI Model Interview Questions 2026
• Subnetting Interview Questions 2026
• Computer Networks Interview Questions 2026
• System Design Interview 2026