15 Most Frequent Network Protocol Interview Questions: TCP/IP, HTTP, and DNS Complete Coverage
Covers 15 high-frequency network protocol interview questions on TCP, HTTP, DNS, and more, each with exam focus and answer direction to help you fully prepare for network protocol interviews.
Background
I used to underestimate network protocol questions. I thought memorizing TCP's three-way handshake and four-way teardown would be enough, but when interviewers asked "why three and not two" or "what to do about too many TIME_WAITs," I was stumped. After organizing all the high-frequency network protocol questions, I found the patterns are quite fixed — the key is understanding the "why" behind each protocol's design, not rote memorization. These 15 questions are the most frequently encountered in my interview experience.
I. TCP (5 Questions)
1. Three-Way Handshake and Four-Way Teardown Process?
Exam Focus: TCP connection management
Three-way handshake: Client sends SYN → Server replies SYN+ACK → Client sends ACK. Why three? Because three handshakes ensure both parties can confirm each other's sending and receiving capabilities. Two handshakes cannot confirm the server's sending capability and the client's receiving capability. Four-way teardown: Active side sends FIN → Passive side replies ACK → Passive side sends FIN → Active side replies ACK. Why four? Because TCP is full-duplex — the passive side may still have data to send after receiving FIN, so ACK and FIN are sent separately. Interviewers love to follow up on these "whys."
2. TCP Congestion Control Mechanism?
Exam Focus: Flow regulation algorithms
Four phases: Slow Start (cwnd grows exponentially from 1), Congestion Avoidance (cwnd grows linearly), Fast Retransmit (retransmit immediately upon receiving 3 duplicate ACKs without waiting for timeout), Fast Recovery (cwnd halves instead of dropping to 1). Key concept: slow start threshold ssthresh — when cwnd exceeds ssthresh, it enters the congestion avoidance phase. Follow-up: Do you know BBR? BBR is a bandwidth and RTT-based congestion control that doesn't rely on packet loss like traditional algorithms, performing better in high-speed long-fat networks.
3. TCP Flow Control Mechanism?
Exam Focus: Receiver-side rate control
Flow control is implemented through sliding windows. The receiver carries the window size (rwnd) in ACKs to inform the sender how much more data it can receive. Zero window problem: when the receiver's window is 0, the sender stops sending but starts a persist timer to periodically send zero window probe packets, preventing deadlock. Silly window syndrome: when the receiver's buffer is nearly full and only frees small amounts of space, the sender sends small amounts of data each time, resulting in extremely low efficiency. Solutions: Nagle algorithm (sender accumulates enough data before sending) and Clark solution (receiver waits until buffer has sufficient space before notifying).
4. What is TIME_WAIT? Why Is It Needed? What If There Are Too Many?
Exam Focus: Connection closing details
TIME_WAIT is the state entered by the active closer after sending the final ACK, lasting 2MSL (Maximum Segment Lifetime). Reasons for existence: first, ensure the last ACK reaches the passive side (if lost, the passive side will retransmit FIN, and the active side can retransmit ACK); second, ensure all packets from this connection disappear from the network, avoiding impact on new connections. Solutions for too many TIME_WAITs: enable tcp_tw_reuse (allow TIME_WAIT connections for new TCP connections); adjust tcp_max_tw_buckets; use long connections instead of short ones. Note: tcp_tw_recycle has issues in NAT environments and is not recommended.
5. TCP Packet Adhesion Problem?
Exam Focus: Application-layer protocol design
Strictly speaking, TCP doesn't have a "packet adhesion" problem because TCP is a byte-stream protocol with no message boundary concept. The so-called adhesion is an application-layer issue — data sent continuously by the sender is read all at once by the receiver. Solutions: fixed-length messages (each message has a fixed length, padded if shorter); special delimiters (like HTTP's \r\n\r\n); length field in message header (most common, like TLV format). Follow-up: Does UDP have this problem? No, because UDP is message-oriented and each UDP packet has clear boundaries.
II. HTTP (5 Questions)
6. Differences Between HTTP/1.1, HTTP/2, and HTTP/3?
Exam Focus: HTTP protocol evolution
HTTP/1.1: persistent connections (Keep-Alive), pipelining (but has head-of-line blocking), Host header for virtual hosts. HTTP/2: binary framing, multiplexing (parallel requests on one connection, solving HTTP-layer head-of-line blocking), header compression (HPACK), server push. HTTP/3: based on QUIC (UDP) replacing TCP, solving TCP-layer head-of-line blocking; 0-RTT connection establishment; connection migration (based on Connection ID instead of 4-tuple). Follow-up: Does HTTP/2 still have head-of-line blocking? Not at the HTTP layer, but yes at the TCP layer — one lost TCP packet blocks all streams.
7. HTTPS Principles?
Exam Focus: Secure communication mechanism
HTTPS = HTTP + TLS. TLS handshake: Client sends Client Hello (supported TLS versions and cipher suites) → Server replies Server Hello + certificate → Client verifies certificate (CA signature chain) → Client generates pre-master secret, encrypts with server's public key and sends → Both derive session key from pre-master secret → Subsequent communication uses symmetric encryption. Follow-up: Why not use only asymmetric encryption? Because asymmetric encryption has poor performance — it's only used for key exchange, while data transmission uses symmetric encryption. TLS 1.3 simplifies the handshake, supporting 1-RTT and even 0-RTT.
8. Common HTTP Status Codes?
Exam Focus: Protocol semantics understanding
200 OK; 301 Permanent Redirect (browser caches it); 302 Temporary Redirect; 304 Not Modified (cache hit); 400 Bad Request; 401 Unauthorized; 403 Forbidden; 404 Not Found; 500 Internal Server Error; 502 Bad Gateway; 503 Service Unavailable; 504 Gateway Timeout. Common question: Difference between 301 and 302? 301 is permanent redirect, search engines update their index; 302 is temporary, search engines keep the original URL. Also: Difference between 502 and 504? 502 means the upstream service returned an invalid response; 504 means the upstream service timed out with no response.
9. HTTP Caching Strategy?
Exam Focus: Cache mechanism design
Strong cache: Expires (HTTP/1.0, absolute time) and Cache-Control (HTTP/1.1, max-age relative time) — if hit, no request to server. Negotiated cache: Last-Modified/If-Modified-Since (based on modification time) and ETag/If-None-Match (based on content hash) — if hit, returns 304. Priority: Cache-Control > Expires > ETag > Last-Modified. Follow-up: How to choose between ETag and Last-Modified? ETag is more precise (won't false-positive when file content unchanged but modification time changed), but ETag computation has performance overhead. Generally, static resources use strong caching + filename hash, HTML uses negotiated caching.
10. Difference Between Cookie and Session?
Exam Focus: Session management mechanism
Cookies are stored on the client, Sessions on the server. Sessions are associated through the SessionID in Cookies (or via URL rewriting). Cookies have a size limit (4KB); Sessions are theoretically unlimited but consume server memory. Security: Cookies can be modified and stolen by the client; Sessions are more secure but need to handle sharing in distributed scenarios (typically using Redis for Session storage). Token approach (JWT) is another option: stateless, suitable for distributed systems, but cannot be proactively invalidated. Follow-up: Cookie's SameSite attribute? Strict (completely block third-party cookies), Lax (carry when navigating to the target site), None (allow but requires Secure).
III. DNS (2 Questions)
11. DNS Resolution Process?
Exam Focus: Domain name resolution mechanism
Browser cache → OS cache → Local DNS server → Root name server → Top-level domain server → Authoritative name server. Specific process: Local DNS checks cache first; if not found, queries the root name server which returns the corresponding top-level domain server address; Local DNS then queries the top-level domain server to get the authoritative name server address; finally queries the authoritative name server for the IP. This process combines recursive and iterative approaches: client to local DNS is recursive, local DNS to each level of name servers is iterative. Follow-up: Does DNS use TCP or UDP? UDP by default, but zone transfers (master-slave sync) use TCP.
12. What is DNS Hijacking? How to Prevent?
Exam Focus: Security awareness
DNS hijacking is when attackers tamper with DNS responses, resolving domain names to malicious IPs. Common scenarios: ISP hijacking (injecting ads), man-in-the-middle attacks, DNS server compromise. Prevention: use HTTPDNS (bypassing traditional DNS, requesting IP directly from HTTP interface); DNS over HTTPS (DoH) or DNS over TLS (DoT) to encrypt DNS queries; DNSSEC to verify response authenticity; use trusted DNS servers (like 8.8.8.8, 1.1.1.1). I've used HTTPDNS in projects — it works particularly well on mobile, avoiding ISP hijacking issues.
IV. Others (3 Questions)
13. CDN Principles?
Exam Focus: Content Delivery Network
CDN deploys edge nodes globally, caching origin content at nodes closest to users. When a user requests, DNS resolves the domain to the nearest CDN node (based on Anycast or DNS smart resolution); if the CDN node has a cache, it returns directly; otherwise, it fetches from the origin and caches it. Key concepts: origin fetch rate (lower cache hit rate means more origin fetches), caching strategy (different TTLs for different resources), preheating (proactively pushing content to CDN nodes). Follow-up: Difference between CDN and reverse proxy? CDN is a distributed caching network deployed globally; reverse proxy is typically centrally deployed. CDN emphasizes "nearest access."
14. WebSocket Principles?
Exam Focus: Full-duplex communication
WebSocket establishes a connection through an HTTP upgrade handshake: client sends Upgrade: websocket request, server responds with 101 Switching Protocols, then switches to WebSocket protocol for full-duplex communication. Compared to HTTP polling, WebSocket requires only one handshake, with minimal subsequent communication overhead (frame header 2-10 bytes). Use cases: instant messaging, real-time data push, online collaboration. Follow-up: Difference between WebSocket and SSE? SSE is server-to-client one-way push based on HTTP, simpler; WebSocket is bidirectional communication, more powerful but more complex to implement.
15. Cross-Origin Solutions?
Exam Focus: Browser security policy
Same-origin policy: same protocol + domain + port is considered same-origin. Cross-origin solutions: CORS (most standard, server sets Access-Control-Allow-Origin and other response headers); JSONP (only supports GET, leverages script tag not being restricted by same-origin); proxy server (webpack-dev-server or nginx proxy in development); postMessage (cross-window communication). CORS distinguishes simple and non-simple requests — non-simple requests send an OPTIONS preflight first. Follow-up: How to handle cross-origin Cookies? Set withCredentials + server-side Access-Control-Allow-Credentials + Allow-Origin cannot be *.
Key Takeaways
The core of network protocol interviews is understanding "why it's designed this way," not memorizing processes. Why three-way handshake, why TIME_WAIT exists, why HTTP/2 needs multiplexing — these designs are all driven by specific problems. I recommend using packet capture tools (Wireshark) to actually observe TCP handshakes/teardowns and HTTP request/response flows. With intuitive understanding, theory becomes much easier. Also, network protocols are often tested combined with real scenarios, like "too many TIME_WAITs with short connections" or "how to design a push system" — these require connecting multiple knowledge points.
FAQ
Q: Do I need to read RFCs for network protocol interviews?
No need to read RFCs cover to cover, but understanding key RFC points (like RFC 2616/7540/9000) is a big plus.
Q: How to choose between TCP and UDP?
Use TCP for reliable transmission, UDP for low latency or broadcast. Modern solutions can use QUIC (reliable transmission over UDP).
Q: What's the focus for HTTPS interviews?
TLS handshake process, certificate verification chain, symmetric/asymmetric encryption coordination, and TLS 1.3 improvements.