1. TCP vs UDP: A Quick Recap

2. Reason 1: No Connection Overhead for Single Messages

TCP requires a 3-way handshake to set up a connection and a 4-way handshake to tear it down. For a single short request-response, this is wasteful.

A UDP server can receive requests from multiple clients and reply to them without setting up any connection. This makes UDP ideal when you are sending a single short message and expecting a single short reply.

3. Reason 2: Lower Latency for Request-Response

For a single request-response exchange, the best-case timing is:

Where:

• RTT = Round-Trip Time — time for a packet to go from client to server and back
• SPT = Server Processing Time — time the server takes to compute the response

UDP saves exactly one full RTT per request-response exchange. On intercontinental links where RTT can be 200–500 ms, this matters a lot.

Real Example: DNS

DNS uses UDP for exactly this reason. When your browser looks up google.com, it sends a single UDP packet to a DNS server and gets a single UDP packet back. No handshake, no teardown. The entire lookup can complete in one round trip.

/* Conceptual: What DNS does with UDP */

/* Client side */
sendto(udp_sock, dns_query, query_len, 0,
       (struct sockaddr *)&dns_server, sizeof(dns_server));

recvfrom(udp_sock, dns_response, sizeof(dns_response), 0,
         (struct sockaddr *)&server_addr, &addrlen);

/* No connect(), no close(), no handshake.
   Single packet each way. Done. */

4. Reason 3: Broadcast and Multicast Support

TCP is a point-to-point protocol — it connects exactly two endpoints. UDP supports both broadcast and multicast:

#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

/* Example: sending a UDP broadcast */
int send_broadcast(void)
{
    int sock;
    struct sockaddr_in dest;
    int broadcastEnable = 1;
    const char *msg = "Hello everyone on this network!";

    sock = socket(AF_INET, SOCK_DGRAM, 0);

    /* Must enable broadcast permission on the socket */
    setsockopt(sock, SOL_SOCKET, SO_BROADCAST,
               &broadcastEnable, sizeof(broadcastEnable));

    memset(&dest, 0, sizeof(dest));
    dest.sin_family      = AF_INET;
    dest.sin_port        = htons(9999);
    dest.sin_addr.s_addr = htonl(INADDR_BROADCAST); /* 255.255.255.255 */

    sendto(sock, msg, strlen(msg), 0,
           (struct sockaddr *)&dest, sizeof(dest));

    /* TCP cannot do this at all */
    return 0;
}

5. Reason 4: Streaming Media Does Not Need Reliability

For applications like video calls, audio streaming, or live gaming, the requirements are completely different from file transfer:

The key insight: TCP’s retransmission introduces unpredictable delay. For real-time media, a short gap in the stream is acceptable. An unexpected 500 ms freeze while TCP waits for a retransmit is not.

Applications like WebRTC, VoIP, and online games use UDP and implement their own lightweight recovery strategies at the application level — sequence numbers to detect loss, but no blocking retransmit.

6. When NOT to Use UDP

Protocols like QUIC (used by HTTP/3) are built on UDP but implement their own congestion control, reliability, and multiplexing. These are multi-year engineering efforts by large teams. Do not attempt this for a typical application.

Decision Guide

7. Code: Simple UDP Echo Server vs TCP Echo Server

UDP Echo Server (simpler, no connection management)

#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <stdio.h>

#define PORT 9000
#define BUFSIZE 1024

int main(void)
{
    int sock;
    struct sockaddr_in server_addr, client_addr;
    socklen_t client_len = sizeof(client_addr);
    char buf[BUFSIZE];
    ssize_t n;

    sock = socket(AF_INET, SOCK_DGRAM, 0);  /* UDP socket */

    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family      = AF_INET;
    server_addr.sin_port        = htons(PORT);
    server_addr.sin_addr.s_addr = INADDR_ANY;

    bind(sock, (struct sockaddr *)&server_addr, sizeof(server_addr));

    printf("UDP echo server waiting on port %d\n", PORT);

    /*
     * No listen(), no accept(), no connection tracking.
     * One loop can serve requests from MANY different clients.
     */
    for (;;) {
        n = recvfrom(sock, buf, BUFSIZE, 0,
                     (struct sockaddr *)&client_addr, &client_len);
        if (n < 0) { perror("recvfrom"); continue; }

        /* Echo back to the same client */
        sendto(sock, buf, n, 0,
               (struct sockaddr *)&client_addr, client_len);
    }

    return 0;
}

/*
 * TCP echo server for comparison:
 *   - Needs accept() loop
 *   - Needs separate handling per client (fork/thread/select)
 *   - More complex state management
 *   - But: reliable, ordered, stream-based
 */

Interview Questions