TCP vs UDP interview questions, with answers

The questions, with answers

1. 1.What is the difference between TCP and UDP?

   In short: TCP is connection-oriented, reliable and ordered with flow and congestion control; UDP is connectionless, best-effort and lightweight.

   TCP sets up a connection with a handshake, then delivers a byte stream reliably and in order, retransmitting lost data, and it controls its sending rate with flow and congestion control. That costs a larger header, at least 20 bytes, and a round trip before data flows. UDP sends independent datagrams with an 8-byte header, no connection, no acknowledgements and no ordering, so it has lower latency and overhead but leaves reliability to the application. TCP suits web pages, file transfer and email; UDP suits real-time media, games and simple request-response exchanges.

2. 2.How does the TCP three-way handshake work?

   In short: The client sends SYN, the server replies SYN-ACK, and the client answers ACK, after which both sides may send data.

   The client sends a segment with the SYN flag and its initial sequence number. The server replies with a segment carrying both SYN and ACK: it acknowledges the client's sequence number and sends its own initial sequence number. The client then sends an ACK acknowledging the server's sequence number, and the connection is established on both sides. During the handshake the two sides also agree on options such as the maximum segment size, window scaling and selective acknowledgement. Initial sequence numbers are chosen unpredictably, which makes it hard for an attacker to inject segments into the connection.

3. 3.How does TCP guarantee reliable delivery?

   In short: With sequence numbers, acknowledgements, retransmission on timeout or duplicate ACKs, checksums and reordering at the receiver.

   TCP numbers every byte it sends. The receiver acknowledges the next byte it expects, so the sender knows what arrived. Anything not acknowledged within the retransmission timeout, computed from measured round-trip times, is resent, and repeated duplicate acknowledgements trigger a fast retransmission before the timer expires. A checksum on every segment detects corruption, and corrupted segments are discarded and later resent. The receiver buffers out-of-order segments and delivers bytes to the application strictly in order, discarding duplicates, so the application sees an exact copy of the stream.

4. 4.When should an application use UDP instead of TCP?

   In short: When low latency matters more than perfect delivery, when messages are small and independent, or when multicast is needed.

   UDP fits when late data is worthless: voice and video calls and online games prefer to skip a lost packet rather than wait for a retransmission that would stall everything behind it. It fits small request-response exchanges, where a whole TCP connection would cost more than the exchange itself, and broadcast or multicast, which TCP cannot do. Applications that need some reliability without TCP's behaviour build it themselves on UDP; QUIC, the transport under HTTP/3, does exactly that, adding encryption and independent streams in user space.

5. 5.What identifies a TCP connection?

   In short: The four-tuple of source IP address, source port, destination IP address and destination port.

   A TCP connection is identified by the combination of source address, source port, destination address and destination port, together with the protocol. That is why a web server can accept thousands of connections on port 443 at once: each client connection differs in its client address or port. A socket is the endpoint the operating system gives the program for one side of this pair. A listening socket waits for new connections, and accept() returns a new socket for each connection it receives, while the listening socket keeps listening.

6. 6.What is a SYN flood attack?

   In short: A flood of SYNs from spoofed addresses that fills the server's queue of half-open connections so real clients cannot connect.

   A server that receives a SYN allocates state for a half-open connection and replies with a SYN-ACK, then waits for the final ACK. An attacker sends huge numbers of SYNs, usually from spoofed addresses, and never completes the handshake, so the queue of half-open connections fills and legitimate clients are refused. SYN cookies defend against it: the server encodes the connection's details in its initial sequence number and keeps no state until a valid ACK returns. Larger backlogs, shorter timeouts and filtering upstream also help.

How the diagnostic asks it

One question from the Computer Networks bank, exactly as a sitting would show it. The bank has 4 on tcp & udp and 30 across Computer Networks.