Top 10 TCP/UDP Interview Questions Every Network Ops Engineer Must Know

Q1: What is the core difference between TCP and UDP and how to choose?

TCP and UDP both operate at the transport layer (Layer 4). TCP is "a phone call" – connection‑oriented, reliable, with three‑way handshake, acknowledgments, retransmission, flow and congestion control, ensuring no loss, duplication, or reordering, but with higher overhead (header ≥20 bytes) and latency. UDP is "a text message" – connection‑less, unreliable, header only 8 bytes, very low latency. Use TCP for HTTP/HTTPS, FTP, SSH, SMTP, database connections where data loss is unacceptable. Use UDP for DNS queries, video streaming, VoIP, online gaming, telemetry where low latency outweighs occasional loss.

Q2: Why does TCP require a three‑way handshake?

The three‑step process ensures both sides agree on initial sequence numbers and that the connection is not a stale request. Steps:

Client → SYN=1, seq=x (request to establish connection)

Server → SYN=1, ACK=1, seq=y, ack=x+1 (acknowledge request and provide its own sequence)

Client → ACK=1, seq=x+1, ack=y+1 (confirm server's sequence, connection established)

Two handshakes cannot prevent half‑open connections caused by delayed SYNs, leading to resource waste. A fourth handshake adds no benefit and only increases latency.

Q3: Why must the client wait 2 MSL after the final ACK in TCP’s four‑way termination?

After sending the last ACK, the client enters TIME_WAIT for 2 MSL (Maximum Segment Lifetime; Linux default 60 s, so 2 MSL = 120 s). This ensures the final ACK reaches the server (retransmission handling) and that all packets from the closed connection expire, preventing “old” packets from affecting new connections with the same 4‑tuple.

Large numbers of TIME_WAIT sockets can exhaust ports, causing "Cannot assign requested address". Adjusting net.ipv4.tcp_tw_reuse=1 can reuse ports, but enabling tcp_tw_recycle is discouraged in NAT environments.

Q4: How does TCP guarantee reliable transmission and what happens on packet loss?

TCP uses five mechanisms:

Checksum : Sender computes checksum over header and data; receiver verifies and discards mismatched packets without ACK.

Sequence numbers + ACK : Each byte is numbered; receiver acknowledges the highest contiguous byte, allowing out‑of‑order buffering.

Timeout retransmission (RTO) : Sender starts a timer; if ACK not received before timeout (typically 1.5–2 × RTT), the segment is retransmitted.

Fast retransmit : Receiver sends three duplicate ACKs for out‑of‑order data; sender retransmits missing segment immediately.

Selective acknowledgment (SACK) : Receiver informs sender which non‑contiguous blocks were received, so only missing segments are resent.

Q5: Are TCP flow control and congestion control the same?

No. Flow control manages the receiver side, preventing the sender from overwhelming the receiver’s buffer via the sliding‑window mechanism (end‑to‑end). Congestion control manages the network, preventing the sender from saturating the network using algorithms such as slow start, congestion avoidance, fast recovery, and congestion detection, based on the congestion window (global).

One‑sentence distinction: flow control watches the receiver’s “face”, congestion control watches the network’s “face”.

Q6: What are TCP sticky‑packet and packet‑splitting issues and how to solve them?

Because TCP is a byte‑stream protocol, it does not preserve message boundaries. Sticky packets occur when two small messages are coalesced into one segment; the receiver reads both at once. Packet splitting occurs when a large message exceeds the MSS (typically 1460 bytes) and is broken into multiple segments, requiring multiple reads.

Application‑layer solutions:

Fixed‑length framing (e.g., 128 bytes per message, pad if shorter).

Special character delimiters (e.g., CRLF in HTTP).

Length field prefix (common in Redis protocol, Protobuf).

For troubleshooting, capture traffic with tcpdump -i eth0 port 8080 -w capture.pcap and analyze with Wireshark.

Q7: What is a SYN Flood attack and how to detect and mitigate it?

Attackers send massive forged SYN packets without completing the handshake, causing the server to allocate TCB resources for each half‑open connection, eventually exhausting resources.

Detection example: ss -tan state syn-recv | wc -l If the SYN‑RECV count spikes to thousands, a flood is likely.

Mitigation measures:

Enable SYN cookies ( net.ipv4.tcp_syncookies=1) to avoid allocating TCBs until a valid ACK arrives.

Increase net.ipv4.tcp_max_syn_backlog (e.g., 4096) and reduce net.ipv4.tcp_synack_retries to 1.

Use firewall or CDN rate‑limiting (e.g., iptables SYN rate limit) or cloud DDoS protection.

Q8: Common commands to view TCP connection states

Essential Linux tools:

ss (recommended) ss -tan | head -20 Displays all TCP connections. ss -tan state established | wc -l Counts established connections. ss -s Shows a summary of connection states. ss -tan dst :80 | wc -l Counts connections to port 80.

netstat (legacy)

netstat -tanp | grep ESTABLISHED | wc -l

netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c

tcpdump (packet capture)

tcpdump -i eth0 -nn port 8080 -w /tmp/capture.pcap

State meanings:

ESTABLISHED : Normal active connection.

TIME_WAIT : Waiting 2 MSL after active close.

SYN_RECV : Half‑open connections; high count may indicate attack.

CLOSE_WAIT : Remote closed, local not yet closed (often a bug).

FIN_WAIT_1/2 : Active close waiting for remote FIN.

Q9: Why does CLOSE_WAIT appear frequently and how to troubleshoot?

CLOSE_WAIT indicates the remote side has sent FIN, the local side ACKed it, but the application has not called close(). The root cause is usually application bugs such as:

Thread exits without closing its socket.

Exception paths missing close() calls.

Improper connection‑pool configuration leaving idle sockets unreclaimed.

Investigation steps:

Count sockets: ss -tan state close-wait | wc -l Identify process: ss -tanp state close-wait Inspect file descriptors: ls -l /proc/PID/fd | grep socket Review source code for missing close handling or pool misconfiguration.

Temporary relief: reduce net.ipv4.tcp_fin_timeout (default 60 s), but the real fix is correcting the application.

Q10: What is TCP Keep‑Alive and how does it differ from HTTP Keep‑Alive?

TCP Keep‑Alive works at the transport layer to probe whether the peer is still reachable. After a configurable idle period, the kernel sends keep‑alive probes; if several probes go unanswered, the connection is considered dead and closed. Linux defaults: net.ipv4.tcp_keepalive_time = 7200 (2 h idle before first probe) net.ipv4.tcp_keepalive_intvl = 75 (interval between probes) net.ipv4.tcp_keepalive_probes = 9 (max probes)

Thus it takes roughly 2 h + 75 × 9 s ≈ 2 h 11 min to declare a dead connection.

HTTP Keep‑Alive operates at the application layer (Layer 7) to reuse a TCP connection for multiple HTTP requests, avoiding repeated handshakes. HTTP/1.1 enables it by default; HTTP/1.0 requires the Connection: keep-alive header.

One‑sentence distinction: TCP Keep‑Alive asks "are you still alive?", while HTTP Keep‑Alive says "let's keep using this channel, no more handshakes".

Summary

TCP/UDP fundamentals are essential for network operations interviews, testing both conceptual understanding and troubleshooting skills. Master the theory layer (packet format, handshakes, sliding window, congestion control), the tool layer (ss, netstat, tcpdump), and the practice layer (optimizing TIME_WAIT, diagnosing CLOSE_WAIT, defending against SYN Flood).