Top 28 TCP/IP Interview Questions & Answers (2026)

Last Updated: June 2026 | Level: Beginner to Advanced | Format: Q&A with Packet Diagrams and Protocol Details

TCP/IP is the foundation of the internet and one of the most tested topics in computer networks interviews. Candidates report that TCP handshake, flow control, and TCP vs UDP appear at both service companies (TCS, Infosys) and product companies (Flipkart, Swiggy, PhonePe) in backend SDE and networking rounds. Based on public preparation resources and candidate-reported interview accounts, congestion control algorithms and connection teardown sequences are frequently asked at senior SDE rounds.

---

Table of Contents

1. TCP/IP Stack and Basics (Q1-Q8)
2. TCP Connection Management (Q9-Q16)
3. TCP Flow and Congestion Control (Q17-Q22)
4. UDP and Protocol Comparisons (Q23-Q28)

---

TCP/IP Stack and Basics

Q1. What is the TCP/IP model? What are its layers? Easy

The TCP/IP model (also called the Internet model) is a practical network architecture with 4 layers:

Layer	Name	Protocols	Function
4	Application	HTTP, FTP, SMTP, DNS, SSH, DHCP	User-facing services, application data
3	Transport	TCP, UDP	End-to-end data delivery, multiplexing via ports
2	Internet (Network)	IP, ICMP, ARP	Logical addressing, routing between networks
1	Network Access (Link)	Ethernet, Wi-Fi (802.11), PPP	Physical transmission on local network

Data encapsulation (going down the stack):

Application: data
  + Transport header (TCP/UDP) -> segment
    + Network header (IP) -> packet
      + Link header (Ethernet) -> frame
        -> Physical bits

TCP/IP vs OSI: TCP/IP has 4 layers; OSI has 7 (separates Application into Application+Presentation+Session, and Network Access into Data Link+Physical). In practice, TCP/IP is used.

---

Q2. What is the role of IP in the TCP/IP stack? Easy

IP (Internet Protocol) operates at the Network layer and provides:

1. Logical addressing: Each device has an IP address (IPv4: 32-bit, IPv6: 128-bit).
2. Routing: IP packets are routed hop-by-hop from source to destination across multiple networks.
3. Fragmentation and reassembly: IP fragments large packets to fit the MTU (Maximum Transmission Unit) of each network segment.
4. Connectionless delivery: IP provides best-effort, connectionless delivery. No guarantee of order, delivery, or error-free transmission (TCP adds reliability on top).

IPv4 header key fields:

Version (4 bits) | IHL (4 bits) | DSCP/ToS (8 bits) | Total Length (16 bits)
Identification (16 bits)       | Flags (3 bits) | Fragment Offset (13 bits)
TTL (8 bits) | Protocol (8 bits) | Header Checksum (16 bits)
Source IP Address (32 bits)
Destination IP Address (32 bits)

TTL (Time to Live): Decremented by 1 at each router hop. When TTL reaches 0, packet is discarded and ICMP Time Exceeded sent back. Prevents infinite routing loops.

---

Q3. What is the difference between IPv4 and IPv6? Easy

Aspect	IPv4	IPv6
Address size	32 bits (4.3 billion addresses)	128 bits (340 undecillion addresses)
Address notation	192.168.1.1 (decimal, dots)	2001:db8::1 (hex, colons)
Header size	20-60 bytes (variable)	40 bytes (fixed)
Fragmentation	By routers and hosts	Only by source host
Checksum	Yes (header checksum)	No (moved to transport layer)
ARP	Uses ARP for MAC resolution	Uses NDP (Neighbor Discovery Protocol)
NAT	Widely used (address shortage)	Not needed (vast address space)
Security	Optional (IPSec optional)	IPSec mandatory in design (not always enforced)

IPv6 address shortening rules:

Full: 2001:0db8:0000:0000:0000:0000:0000:0001
Omit leading zeros: 2001:db8:0:0:0:0:0:1
Replace consecutive zero groups with ::  : 2001:db8::1

---

Q4. What is a port number? What are the well-known port ranges? Easy

A port number is a 16-bit number (0-65535) that identifies a specific application/service on a host. Combined with an IP address, it forms a socket that uniquely identifies an endpoint.

Port ranges:

Range	Name	Description
0-1023	Well-known ports	Assigned by IANA to standard services
1024-49151	Registered ports	Used by specific applications (non-root)
49152-65535	Ephemeral (dynamic) ports	Assigned by OS for client-side connections

Well-known port examples:

Port	Protocol	Service
21	TCP	FTP (control)
22	TCP	SSH
23	TCP	Telnet
25	TCP	SMTP
53	UDP/TCP	DNS
80	TCP	HTTP
110	TCP	POP3
143	TCP	IMAP
443	TCP	HTTPS
3306	TCP	MySQL
5432	TCP	PostgreSQL
6379	TCP	Redis
27017	TCP	MongoDB

---

Q5. What is a socket? What is a socket pair? Medium

A socket is the combination of an IP address and a port number that identifies one endpoint of a network connection.

Socket = IP address + Port
Example: 192.168.1.5:45231 (client ephemeral port)
         104.21.0.1:443    (server HTTPS port)

A socket pair (4-tuple) uniquely identifies a TCP connection:

{source IP, source port, destination IP, destination port}
Example: {192.168.1.5, 45231, 104.21.0.1, 443}

The OS uses this 4-tuple to demultiplex incoming packets to the correct connection. This is why a server can handle millions of simultaneous connections on port 80: each connection has a different (source IP, source port) combination.

Socket types:

• SOCK_STREAM: TCP (reliable, ordered, connected).
• SOCK_DGRAM: UDP (datagram, connectionless).
• SOCK_RAW: Raw IP (bypasses transport layer; used by ping, traceroute).

---

Q6. What is the MTU? What is IP fragmentation? Medium

MTU (Maximum Transmission Unit): The largest IP packet size that a network link can transmit in one frame.

• Ethernet: 1500 bytes
• Wi-Fi: 2304 bytes (but usually matches Ethernet)
• PPPoE (broadband): 1492 bytes (8-byte PPPoE header)
• IPv6 minimum: 1280 bytes

IP fragmentation (IPv4): When a packet exceeds the MTU of a link:

1. The router (IPv4) or source host (IPv6) fragments the packet.
2. Each fragment gets the same IP ID, with Fragment Offset and More Fragments flag.
3. The destination reassembles fragments.

Fragmentation fields in IPv4 header:

Flags (3 bits):
  Bit 0: Reserved (0)
  Bit 1: DF (Don't Fragment) -- if set and fragmentation needed, drop packet + ICMP error
  Bit 2: MF (More Fragments) -- 1 if more fragments follow, 0 for last fragment

Fragment Offset (13 bits): position of this fragment in 8-byte units

Path MTU Discovery (PMTUD): Sender sets DF=1, sends maximum-size packet. If a router needs to fragment, it drops the packet and sends ICMP "Fragmentation Needed" back. Sender reduces packet size. Avoids fragmentation by fitting within path MTU.

---

Q7. What is ARP (Address Resolution Protocol)? Easy

ARP resolves an IP address to its MAC (physical/hardware) address on the local network.

Why needed: IP routing delivers packets between networks using IP addresses. But within a local network (LAN), actual delivery is done by MAC addresses in Ethernet frames. ARP bridges this gap.

ARP process:

Host A (IP: 192.168.1.5, MAC: AA:BB:CC:DD:EE:FF) wants to send to
Host B (IP: 192.168.1.10, MAC: ?)

1. A checks ARP cache. No entry for 192.168.1.10.
2. A broadcasts ARP Request:
   "Who has IP 192.168.1.10? Tell 192.168.1.5"
   (Sent to broadcast MAC FF:FF:FF:FF:FF:FF)
3. All hosts receive the broadcast. Only B with 192.168.1.10 replies.
4. B unicasts ARP Reply:
   "192.168.1.10 is at 11:22:33:44:55:66"
5. A caches (192.168.1.10 -> 11:22:33:44:55:66) in ARP table.
6. A sends Ethernet frame with destination MAC 11:22:33:44:55:66.

ARP cache: OS caches ARP replies for a short time (typically 20-60 seconds) to avoid repeated broadcasts.

ARP Poisoning (Security): An attacker sends fake ARP replies, associating their MAC with another host's IP. This is a man-in-the-middle attack vector on local networks.

---

Q8. What is ICMP? What is it used for? Easy

ICMP (Internet Control Message Protocol) is a companion to IP that provides error messages and network diagnostic functionality.

Key ICMP message types:

Type	Name	Use
0	Echo Reply	Response to ping
3	Destination Unreachable	Host/port/network unreachable
5	Redirect	Better route available
8	Echo Request	Ping
11	Time Exceeded	TTL = 0 (used by traceroute)
12	Parameter Problem	Bad IP header

ping: Sends ICMP Echo Request, receives ICMP Echo Reply. Measures round-trip time.

ping 8.8.8.8
PING 8.8.8.8: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=12.3 ms

traceroute: Sends packets with increasing TTL (1, 2, 3...). When TTL expires at each router, router sends ICMP Time Exceeded back. Traceroute maps the path.

ICMP does not use TCP or UDP: ICMP is a separate protocol layered directly on IP.

---

TCP Connection Management

Q9. Explain the TCP three-way handshake. Easy

The TCP three-way handshake establishes a connection before data transfer.

Client                        Server
  |                              |
  |------ SYN (seq=x) -------->  |  Client sends SYN (synchronize), proposes ISN x
  |                              |
  |  <---- SYN-ACK ----------   |  Server acknowledges (ack=x+1) and sends its own SYN (seq=y)
  |       (seq=y, ack=x+1)       |
  |                              |
  |------ ACK (ack=y+1) ------> |  Client acknowledges server's SYN
  |                              |
  |<====== DATA TRANSFER =======>|  Connection established

Steps explained:

1. SYN: Client sends a segment with SYN flag set and its Initial Sequence Number (ISN x). "I want to connect, my first byte will be sequence x."
2. SYN-ACK: Server accepts, sends ISN y and acknowledges client's SYN (ack=x+1 means "I received up to x, send me x+1 next"). "OK, I'm also connecting, my first byte is y."
3. ACK: Client acknowledges server's SYN (ack=y+1). "I received your y, send me y+1 next." Connection established.

Why ISN is random: Using a random ISN prevents old stale segments from a previous connection being mistakenly accepted by a new connection with the same 4-tuple.

---

Q10. What happens during TCP connection teardown (four-way handshake)? Medium

TCP connection teardown requires FOUR messages because each side closes independently.

Client                        Server
  |                              |
  |------ FIN (seq=u) -------->  |  Client says: done sending
  |                              |
  |  <---- ACK (ack=u+1) -----  |  Server ACKs the FIN
  |     (Server may still send data here -- half-closed state)
  |                              |
  |  <---- FIN (seq=v) --------  |  Server also done sending
  |                              |
  |------ ACK (ack=v+1) ------> |  Client ACKs server's FIN
  |                              |
  |  [Client waits 2*MSL in TIME_WAIT state]

Why four messages? FIN closes one direction of the connection. The other direction can still be open (half-duplex close). Server may have more data to send after receiving client's FIN. So server's FIN is separate.

TIME_WAIT state: After sending the final ACK, client waits 2MSL (Maximum Segment Lifetime, typically 230s = 60s). This ensures:

1. The final ACK reaches the server (if lost, server retransmits FIN; client can re-ACK).
2. All old segments from this connection expire so they cannot confuse a new connection with the same 4-tuple.

---

Q11. What TCP states exist? Describe the state machine. Hard

Key TCP states:

State	Description
CLOSED	No connection
LISTEN	Server waiting for incoming connections
SYN_SENT	Client sent SYN, waiting for SYN-ACK
SYN_RECEIVED	Server received SYN, sent SYN-ACK, waiting for ACK
ESTABLISHED	Connection established, data transfer possible
FIN_WAIT_1	Sent FIN, waiting for ACK
FIN_WAIT_2	Received ACK of own FIN, waiting for remote FIN
TIME_WAIT	Received remote FIN, sent ACK, waiting 2*MSL
CLOSE_WAIT	Received FIN, sent ACK, waiting for local close
LAST_ACK	Sent FIN (after CLOSE_WAIT), waiting for final ACK

Simplified state diagram:

CLOSED -> LISTEN (server calls listen())
CLOSED -> SYN_SENT (client calls connect())
SYN_SENT -> ESTABLISHED (received SYN-ACK, sent ACK)
ESTABLISHED -> FIN_WAIT_1 (local close called)
FIN_WAIT_1 -> TIME_WAIT (received FIN and ACK simultaneously = simultaneous close)
FIN_WAIT_1 -> FIN_WAIT_2 (received ACK of FIN)
FIN_WAIT_2 -> TIME_WAIT (received FIN, sent ACK)
TIME_WAIT -> CLOSED (2*MSL timer expires)

---

Q12. What is TCP sequence numbering and acknowledgment? Medium

Sequence numbers track the byte offset of each segment in the data stream.

ISN (Initial Sequence Number): randomly chosen at connection start (e.g., 1000)
First byte sent: sequence 1001 (ISN+1)
If 1000 bytes sent: sequence 1001-2000

ACK number: the NEXT byte the receiver expects.
If receiver has received bytes up to 2000: ACK = 2001

Cumulative ACK: TCP uses cumulative ACKs. ACK=2001 means "I have received everything up to and including 2000. Send me 2001 next."

Selective ACK (SACK): Extension to cumulative ACK. Allows receiver to indicate which non-contiguous segments it has received.

Sender sends: 1, 2, 3, 4, 5 (segments, 1 = 1 KB each)
Segment 2 is lost.
Receiver has: 1, 3, 4, 5.

Without SACK: ACK=2001 (only up to segment 1, must retransmit 2,3,4,5)
With SACK: ACK=2001, SACK blocks [3001-6000] (have 3,4,5 but missing 2)
Sender retransmits only segment 2.

---

Q13. What is TCP reliability? How does retransmission work? Medium

TCP provides reliability through:

1. Checksums: Each segment has a checksum. Corrupt segments are discarded.
2. Sequence numbers: Detect missing, out-of-order, or duplicate segments.
3. Acknowledgments: Confirm receipt of data.
4. Retransmission: Re-send unacknowledged segments.

Retransmission Timeout (RTO):

RTT (Round-Trip Time): measured for each ACK received.
SRTT (Smoothed RTT): SRTT = (1-alpha)*SRTT + alpha*RTT  (alpha=0.125)
RTTVAR (RTT variance): tracks variation in RTT.
RTO = SRTT + 4*RTTVAR   (per RFC 6298)

Minimum RTO: 1 second (originally; lower in practice for fast networks).

When a segment is sent, a retransmission timer starts. If no ACK received before RTO expires, the segment is retransmitted. Each retransmission doubles the RTO (exponential backoff).

Fast Retransmit: If the sender receives 3 duplicate ACKs for the same sequence number, it assumes that segment is lost and retransmits immediately without waiting for RTO.

Receiver: got 1, ACK=2. Got 3, ACK=2 (duplicate). Got 4, ACK=2 (duplicate). Got 5, ACK=2 (duplicate).
Sender: 3 duplicate ACKs for byte 2 -> fast retransmit segment 2 immediately.

---

Q14. What is a SYN flood attack? How is it mitigated? Hard

SYN flood is a Denial of Service (DoS) attack exploiting the TCP three-way handshake.

Attack mechanics:

Attacker sends many SYN packets with spoofed source IPs.
Server replies SYN-ACK to each (entering SYN_RECEIVED state).
Server allocates a buffer for each half-open connection.
Attacker never sends ACK to complete handshakes.
Server's SYN queue fills up. Legitimate connections are rejected.

Mitigation:

1. SYN cookies: Server does NOT allocate state for SYN_RECEIVED. Instead:

   • Encodes connection info into ISN using a cryptographic hash.
   • When ACK arrives, recomputes hash and validates.
   • Only allocates state for legitimate three-way handshakes.
   • Spoofed SYNs generate no stored state.

2. Rate limiting: Limit SYN packets per second from a single IP.

3. Firewall rules: Block spoofed source IP addresses (ingress filtering).

4. Increase SYN queue size: Larger backlog queue absorbs more half-open connections before legitimate ones are affected.

---

Q15. What is the TCP sliding window? Medium

The sliding window is the core mechanism behind TCP flow control. It allows the sender to transmit multiple unacknowledged segments simultaneously (pipelining), without waiting for each ACK.

Sender can have up to WINDOW SIZE bytes unacknowledged at any time.

Example: window = 4KB, MSS = 1KB (4 segments at once)

Initial:                    [Sent+Unacked=0]
Send 1KB (seq 1):          [1 unacked]
Send 2KB (seq 2):          [2 unacked]
Send 3KB (seq 3):          [3 unacked]
Send 4KB (seq 4):          [4 unacked, window full]
WAIT...
ACK for seq 1 received:    window slides, can send seq 5
Send 5KB (seq 5):          [2,3,4,5 unacked]

Window management:

• Receiver advertises its receive window (rwnd) in each ACK: how much buffer space it has left.
• Sender's effective window = min(cwnd, rwnd) where cwnd is the congestion window.
• As buffer fills up, rwnd shrinks. When buffer is full, rwnd=0 (zero window: sender must pause).

---

Q16. What is a TCP keepalive? Medium

TCP keepalive is a mechanism to detect dead connections and maintain connections through idle periods.

The problem: If no data is sent for a long time (hours), the underlying network may silently drop the connection (NAT timeout, firewall, idle detection). One side thinks the connection is active; the other side has closed it. The next data send fails with an error.

Keepalive mechanism: After a connection is idle for tcp_keepalive_time (default: 2 hours on Linux), the OS sends a small keepalive probe (ACK with old sequence number).

• If ACK received: connection is alive.
• If no response after tcp_keepalive_probes retries (every tcp_keepalive_intvl): connection declared dead, reset.

Linux sysctl values:

net.ipv4.tcp_keepalive_time    = 7200  (2 hours before first probe)
net.ipv4.tcp_keepalive_intvl   = 75    (75 seconds between probes)
net.ipv4.tcp_keepalive_probes  = 9     (9 probes before giving up)

Application-level keepalive: Many applications (databases, HTTP/2, WebSocket) implement their own keepalive (PING frames) at a shorter interval than 2 hours. This is separate from TCP keepalive.

---

TCP Flow and Congestion Control

Q17. What is TCP flow control? How does the receive window work? Medium

Flow control prevents the sender from overwhelming the receiver's buffer.

Mechanism: The receiver advertises its available buffer space in the Window field of every ACK. This is the rwnd (receiver window).

Receiver buffer: 16KB total
Receiver has consumed 10KB, buffered 4KB:
  Available buffer = 16 - 4 = 12KB -> advertises rwnd=12288

Sender limits unacknowledged data to rwnd.

Receiver gets overwhelmed (buffer almost full):
  Available buffer = 2KB -> rwnd = 2048

Receiver's buffer is full:
  rwnd = 0 (ZERO WINDOW, sender must STOP sending data)

Receiver drains buffer, free space available:
  Sends Window Update: rwnd = 8192 (sender can resume)

Silly Window Syndrome: If receiver consistently advertises tiny windows (receives slowly), sender sends many tiny segments (overhead). Solutions: Nagle's algorithm (sender) and delayed ACK / minimum window (receiver).

---

Q18. What is TCP congestion control? Hard

Congestion control prevents the sender from overwhelming the network (routers/links between sender and receiver).

TCP uses a congestion window (cwnd) maintained by the sender. The sender transmits at rate = min(cwnd, rwnd) / RTT.

Four algorithms (TCP Reno):

1. Slow Start:

Initially: cwnd = 1 MSS (Maximum Segment Size, typically 1460 bytes)
Each ACK received: cwnd += 1 MSS (doubles each RTT!)
Growth: 1, 2, 4, 8, 16, ... (exponential)
Stop when cwnd >= ssthresh (slow start threshold)

2. Congestion Avoidance:

When cwnd >= ssthresh:
  Each RTT: cwnd += 1 MSS (linear growth, ~1 MSS per RTT)
Growth: ssthresh, ssthresh+1, ssthresh+2, ...

3. Fast Retransmit + Fast Recovery (on 3 duplicate ACKs):

ssthresh = cwnd / 2
cwnd = ssthresh + 3 MSS (account for 3 duplicates = 3 received segments)
Retransmit lost segment
Enter Fast Recovery: for each duplicate ACK: cwnd += 1 MSS
On new ACK (loss resolved): cwnd = ssthresh, enter Congestion Avoidance

4. Timeout (severe congestion):

ssthresh = cwnd / 2
cwnd = 1 MSS
Restart Slow Start (from scratch)

Throughput diagram:

cwnd
 ^     *
 |    * *
 |   *   *    *
 |  *     *  * *
 | *       **   *
 |*              *
 +-----------------> time
 Slow  CA  loss  CA
 Start

---

Q19. What is the difference between TCP Tahoe, Reno, and CUBIC? Hard

Feature	TCP Tahoe	TCP Reno	TCP CUBIC
On timeout	cwnd=1, ssthresh=cwnd/2	cwnd=1, ssthresh=cwnd/2	Same
On 3 dup ACKs	cwnd=1, ssthresh=cwnd/2	Fast Recovery: cwnd=ssthresh+3	Same fast recovery but cubic growth
Growth	Slow start then AIMD	Slow start then AIMD with fast recovery	Cubic function of time since last congestion
Default in	Early TCP implementations	Linux (before 2.6.19)	Linux (since 2.6.19), default today

CUBIC: cwnd grows as a cubic function of time since the last congestion event. Scales better on high-bandwidth, high-latency (BDP = Bandwidth-Delay Product) networks.

CUBIC: cwnd = C * (t - K)^3 + Wmax
  Where:
  C = scaling constant
  t = time since last congestion
  K = time at which cwnd would have reached Wmax
  Wmax = cwnd at last congestion event

CUBIC is less aggressive at low bandwidth but much more aggressive at high bandwidth (gigabit+ links with high RTT), which is why it is the default on Linux.

---

Q20. What is the Nagle algorithm? Hard

Nagle's Algorithm reduces network congestion by coalescing small data segments into fewer, larger segments.

Problem without Nagle: An application calling write() with 1 byte at a time would send 1-byte TCP segments with 40 bytes of TCP+IP header overhead. This is 4000% overhead ("small packet problem").

Nagle's rule: Delay sending a small packet if:

1. There is already an unacknowledged segment in flight (data sent but not ACKed), AND
2. The amount of data to send is less than one MSS.

Wait until either:

• ACK arrives for in-flight segment, OR
• Enough data accumulates to fill an MSS.

When Nagle hurts: Interactive applications (SSH, telnet, gaming) where each keystroke must be sent immediately. The delay of Nagle waiting for ACK before sending the next byte adds significant latency.

Disable Nagle: TCP_NODELAY socket option.

int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));

Most databases, Redis clients, and real-time applications disable Nagle.

---

Q21. What is bandwidth-delay product (BDP)? Hard

Bandwidth-Delay Product (BDP) is the amount of data that can be "in flight" (unacknowledged) in a network pipe at any time.

BDP = Bandwidth (bytes/sec) * RTT (seconds)

Example:
100 Mbps link, RTT = 100ms
BDP = (100 * 10^6 / 8) bytes/sec * 0.1 sec = 1,250,000 bytes = 1.25 MB

This means the sender can have 1.25MB of unacknowledged data in flight
to fully utilize the link.

Significance for TCP:

• TCP's window size must be at least BDP to fully utilize the link.
• If cwnd or rwnd is smaller than BDP, the sender will stall waiting for ACKs, underutilizing the link.
• Default TCP buffer sizes (typically 64KB-256KB) are too small for high-BDP links (e.g., trans-continental gigabit). Must increase socket buffers.

Linux buffer tuning:

# Max TCP receive/send buffer sizes
sysctl -w net.core.rmem_max=134217728    # 128 MB
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"

---

Q22. What is TCP TIME_WAIT and why is it a problem in production? Hard

TIME_WAIT is the state after closing a connection where the socket waits for 2*MSL before being released.

Why it exists (correct behavior):

1. Ensures the final ACK reaches the server.
2. Prevents stale segments from polluting new connections with the same 4-tuple.

Production problem: Short-lived connections (microservices, REST APIs) generate many connections. After closing, TIME_WAIT accumulates. Each TIME_WAIT socket occupies a local port for 60 seconds.

Client port range: 49152-65535 = 16383 ports
At 1000 requests/second (closing 1000 connections/second):
TIME_WAIT sockets after 60 seconds: 60 * 1000 = 60,000
Available ports: 16383. Port exhaustion!

Solutions:

1. Connection pooling: Reuse connections (HTTP Keep-Alive, database connection pool). Avoids closing connections after each request.

2. tcp_tw_reuse (Linux): Allow reusing TIME_WAIT sockets for new outgoing connections if the new connection's timestamp is newer.

sysctl -w net.ipv4.tcp_tw_reuse=1

3. SO_REUSEADDR: Allows binding to a port in TIME_WAIT (for servers restarting quickly).

4. Increase ephemeral port range:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"

---

UDP and Protocol Comparisons

Q23. What is UDP? When is it preferred over TCP? Easy

UDP (User Datagram Protocol) is a connectionless transport protocol. It sends datagrams without establishing a connection, without guaranteeing delivery, order, or error recovery.

UDP header (8 bytes, very minimal):

Source Port (16 bits) | Destination Port (16 bits)
Length (16 bits)      | Checksum (16 bits)
Data...

TCP vs UDP comparison:

Aspect	TCP	UDP
Connection	Connection-oriented (3-way handshake)	Connectionless
Reliability	Guaranteed delivery (retransmission)	No guarantee
Ordering	Ordered delivery	No ordering
Flow control	Yes (sliding window)	No
Congestion control	Yes (CUBIC, etc.)	No
Overhead	~20 bytes header + connection state	8 bytes header only
Latency	Higher (connection setup, ACKs)	Lower
Use cases	HTTP, HTTPS, SMTP, FTP, SSH	DNS, VoIP, video streaming, gaming, DHCP

When UDP is better:

• Real-time applications where latency matters more than reliability (VoIP: a delayed packet is useless; just play silence).
• Applications that implement their own reliability (QUIC, game state sync with custom loss recovery).
• Broadcast/multicast (UDP supports, TCP does not).
• Simple request-response (DNS: a query is one UDP datagram; faster than TCP handshake).

---

Q24. How does DNS use UDP? When does it switch to TCP? Medium

DNS over UDP:

• A DNS query and response each fit in a single UDP datagram (usually < 512 bytes for simple queries).
• No connection setup needed. Client sends query, server sends response. Fast.
• Default: DNS uses UDP on port 53.

When DNS switches to TCP:

1. Response too large for UDP: If the DNS response exceeds 512 bytes (or the EDNS0 negotiated size), the server sends a truncated response with TC (Truncated) bit set. Client retries with TCP.
2. Zone transfers (AXFR): DNS zone transfer (entire domain's records from primary to secondary nameserver) uses TCP (large amount of data, reliability needed).
3. DNSSEC: Signed records are much larger, often requiring TCP.
4. DNS over TLS (DoT): Always TCP (port 853) for encrypted DNS.
5. DNS over HTTPS (DoH): Uses HTTPS (TCP port 443).

---

Q25. What is QUIC? How does it improve on TCP? Hard

QUIC (Quick UDP Internet Connections) is a transport protocol by Google (now an IETF standard) that runs on top of UDP, combining TCP's reliability with lower latency.

Problems QUIC solves:

1. Head-of-line blocking in TCP: HTTP/2 multiplexes streams over one TCP connection. If one packet is lost, all streams are blocked waiting for retransmission. QUIC streams are independent: a lost packet only blocks its own stream.

2. TCP connection setup latency: TCP 3-way handshake + TLS 1.3 handshake = 2 RTTs before data. QUIC+TLS 1.3 = 1 RTT (or 0-RTT for reconnections).

3. NAT rebinding / IP migration: TCP connections are identified by 4-tuple. If client's IP changes (mobile switching from Wi-Fi to cellular), the TCP connection breaks. QUIC uses a Connection ID independent of IP, allowing migration.

QUIC properties:

• Built on UDP (bypasses OS TCP stack, easier to update).
• Built-in TLS 1.3 encryption (security not optional).
• Multiplexed streams with independent flow control.
• Forward Error Correction (optional).

Where it is used: HTTP/3 (QUIC is the transport for HTTP/3). Deployed by Google, Cloudflare, Facebook (Meta). Chrome uses QUIC by default.

---

Q26. What is the difference between HTTP/1.1, HTTP/2, and HTTP/3? Medium

Feature	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC (UDP)
Multiplexing	No (one request per connection, or pipelining with issues)	Yes (multiple streams per connection)	Yes (QUIC streams)
Header compression	No	HPACK compression	QPACK compression
TLS	Optional	Required (in practice)	Required (built into QUIC)
Server push	No	Yes (push resources proactively)	Yes
Head-of-line blocking	Yes (TCP + HTTP)	HTTP-level solved, TCP-level remains	Solved (QUIC streams independent)
Persistent connections	Yes (Keep-Alive)	Yes (multiplexed, more efficient)	Yes
Year	1997	2015	2022 (RFC 9114)

---

Q27. What is the difference between connection-oriented and connectionless protocols? Easy

Aspect	Connection-Oriented	Connectionless
Setup	Must establish connection before data (TCP handshake)	No setup; send data immediately
State	Maintains connection state at both ends	No state
Reliability	Built-in (retransmission, ordering)	None (application must handle)
Overhead	Higher (connection setup + teardown)	Lower
Use case	Long-lived sessions (HTTP, SSH, database connections)	Short queries, real-time data (DNS, VoIP)
Analogies	Phone call (establish, talk, hang up)	Postal letter (no connection, just send)

Examples:

• Connection-oriented: TCP, X.25, ATM, SCTP.
• Connectionless: UDP, IP, Ethernet.

---

Q28. What is a TCP RST packet? When is it sent? Medium

A TCP RST (Reset) packet abruptly terminates a connection, as opposed to the graceful FIN-based teardown.

When RST is sent:

Scenario	Who sends RST
Port not listening: Client connects to a port with no server	Server's OS sends RST immediately
Half-open detection: One side rebooted, other sends data to the dead connection	The rebooted side has no connection state; sends RST
Abort: Application calls close() with SO_LINGER timeout=0	Sender's OS sends RST instead of FIN
Invalid state: Received segment with unexpected sequence number	Receiver sends RST
Firewall: Firewall actively rejects a connection	Firewall sends RST to both sides

Effect of receiving RST: Connection is immediately destroyed. No CLOSE_WAIT, no TIME_WAIT. The application receives an error (ECONNRESET on Linux: "Connection reset by peer").

RST vs FIN:

• FIN: "I'm done sending. You can still send." Graceful.
• RST: "This connection is terminated NOW." Abrupt. No half-closed state. No TIME_WAIT.

---

FAQ

Q: Why does TCP have a minimum RTO of 1 second? RFC 6298 sets the minimum RTO at 1 second. This prevents aggressive retransmission that would worsen network congestion. Some modern stacks allow lower minimums (200ms) for low-latency internal networks.

Q: What is the difference between a TCP segment and an IP packet? A TCP segment is the PDU (Protocol Data Unit) at the Transport layer (header + data). An IP packet is the PDU at the Network layer (IP header + TCP segment). When transmitted, the IP packet is encapsulated in an Ethernet frame.

Q: What is the significance of the sequence number wrapping? TCP sequence numbers are 32-bit, wrapping at 2^32 bytes (~4.3GB). On high-speed networks (multi-gigabit), wrap-around can happen quickly. The PAWS (Protection Against Wrapped Sequences) extension uses TCP timestamps to disambiguate old from new segments after wrap-around.

---

Related PapersAdda guides:

• Computer Networks Freshers Guide
• OSI Model Interview Questions 2026
• HTTP HTTPS DNS Questions 2026
• Subnetting Interview Questions 2026
• System Design Interview 2026