Introduction

Networked applications communicate through a collection of protocols rather than one single protocol. Each protocol handles a different responsibility, such as identifying hosts, routing packets, transporting application data or interpreting messages.

The term TCP/IP commonly refers to the broader Internet protocol suite. Two important transport protocols within this suite are:

• TCP, or Transmission Control Protocol, which provides a connection-oriented, reliable and ordered byte stream.
• UDP, or User Datagram Protocol, which provides a minimal datagram-based transport without guaranteed delivery, duplicate protection or ordering.

Both TCP and UDP use IP for communication between network endpoints. The transport protocol determines how applications identify communication endpoints and what delivery behaviour the application receives.

In your System Design curriculum, TCP/IP and UDP is Topic 3.1 under Networking and Web Request Lifecycle. The module progresses through DNS, routing, TLS, HTTP, cookies, sessions and real-time communication after establishing transport foundations.

Prerequisites

The TCP/IP Layer Model

The TCP/IP model organizes communication responsibilities into layers. Different references can present slightly different names or boundaries, but the following four-layer model is commonly used.

Encapsulation

Encapsulation occurs when each layer adds information required for its responsibility.

Application message
        |
        v
+-------------------------------+
| TCP or UDP header | Data      |
+-------------------------------+
        |
        v
+-------------------------------------------+
| IP header | Transport header | Data       |
+-------------------------------------------+
        |
        v
+--------------------------------------------------------+
| Link header | IP packet | Link trailer                 |
+--------------------------------------------------------+

At the receiving endpoint, the layers interpret and remove the relevant control information before delivering the application data.

Internet Protocol

Internet Protocol provides packet addressing and forwarding between network endpoints. Each IP packet includes source and destination address information used during delivery.

IP is responsible for:

• Logical network addressing
• Packet forwarding
• Routing across interconnected networks
• Packet lifetime control
• Identifying the encapsulated upper-layer protocol

IP itself does not provide TCP-style guaranteed delivery, application message ordering or duplicate suppression.

IPv4 and IPv6

Network Prefixes

Classless Inter-Domain Routing notation identifies an address and the number of leading bits in the network prefix.

192.0.2.0/24

Address:
192.0.2.0

Prefix length:
24 bits

Remaining address bits:
32 - 24 = 8 bits

The number of address bit patterns within an IPv4 prefix is:

\[ Address\ Patterns = 2^{32 - Prefix\ Length} \]

For a /24 prefix:

\[ 2^{32 - 24} = 2^8 = 256 \]

Not every address pattern is necessarily available for assignment. Actual usage depends on the address type, network design and platform rules.

Packet Forwarding

A host examines the destination address and selects an applicable route. If the destination is not locally reachable, the packet is normally sent toward a router or next hop.

Application Host
       |
       | Destination IP packet
       v
Local Routing Decision
       |
       +--> Local network destination
       |
       +--> Default or selected gateway
                    |
                    v
                 Router
                    |
                    v
              Additional Routes
                    |
                    v
             Destination Network

Routers normally make forwarding decisions based on destination network prefixes. The complete route can involve several independently managed networks.

Ports

TCP and UDP use port numbers to identify application communication endpoints on a host.

IP address:
Identifies the network endpoint.

Port:
Identifies an application endpoint
within the transport protocol context.

A network conversation is commonly identified using:

Source IP address
Source port
Destination IP address
Destination port
Transport protocol

TCP port 8080 and UDP port 8080 are separate transport endpoints because the transport protocol is part of the identity.

What Is TCP?

Transmission Control Protocol provides a reliable, ordered, connection- oriented byte-stream service between application endpoints.

TCP provides mechanisms for:

• Connection establishment
• Ordered byte delivery
• Detection of missing data
• Retransmission
• Duplicate handling
• Flow control
• Congestion control
• Orderly connection closure

TCP Connection Establishment

A TCP connection is established through an exchange that synchronizes connection state between the endpoints.

Client                                  Server
  |                                        |
  | SYN                                    |
  |--------------------------------------->|
  |                                        |
  | SYN + ACK                              |
  |<---------------------------------------|
  |                                        |
  | ACK                                    |
  |--------------------------------------->|
  |                                        |
  | Connection established                 |
  |                                        |

The exchange helps establish:

• Reachability for the connection attempt
• Initial sequence-number state
• Transport options supported by the endpoints
• Connection-specific state in both protocol stacks

TCP Sequence Numbers

TCP identifies byte positions using sequence numbers. Sequence information allows the receiver to place bytes in order and detect missing or duplicated stream ranges.

Sent byte ranges:

1000 - 1499
1500 - 1999
2000 - 2499


Arrival order:

2000 - 2499
1000 - 1499
1500 - 1999


Application delivery:

1000 - 1499
1500 - 1999
2000 - 2499

The receiver normally delivers bytes to the application according to the ordered stream contract.

TCP Acknowledgements and Retransmission

Acknowledgements communicate receiving progress. When required data is not acknowledged according to TCP's algorithms, the sender can retransmit it.

Sender                                  Receiver
  |                                        |
  | Data range                             |
  |--------------------------------------->|
  |                                        |
  | Acknowledgement                        |
  |<---------------------------------------|

Retransmission improves reliable delivery, but waiting for missing data can increase completion latency.

TCP Flow Control

Flow control prevents a sender from overwhelming the receiving endpoint's available receive capacity.

Sender
  |
  | Data
  v
Receiver Network Buffer
  |
  | Application reads bytes
  v
Receiving Application

The receiver communicates available stream capacity. The sender limits unacknowledged data according to applicable TCP control state.

TCP Congestion Control

Congestion control limits traffic injected into the network according to observed conditions.

Flow control and congestion control address different limits:

TCP Does Not Preserve Messages

Application sender:

send("HELLO")
send("WORLD")


Application receiver can observe:

recv() -> "HELLOWORLD"

or:

recv() -> "HEL"
recv() -> "LOWOR"
recv() -> "LD"

The application protocol must define message boundaries through a length prefix, delimiter, fixed-size format or another framing strategy.

TCP Connection Closure

TCP supports independent closure of each communication direction.

Endpoint A                              Endpoint B
    |                                       |
    | FIN                                   |
    |-------------------------------------->|
    |                                       |
    | ACK                                   |
    |<--------------------------------------|
    |                                       |
    | FIN                                   |
    |<--------------------------------------|
    |                                       |
    | ACK                                   |
    |-------------------------------------->|

Actual closure behaviour can vary based on simultaneous closure, resets, errors and application use of half-close.

What Is UDP?

User Datagram Protocol provides a minimal message-oriented transport over IP. UDP allows an application to send independent datagrams to another application endpoint.

UDP does not inherently guarantee:

• Delivery
• Ordering
• Duplicate protection
• Retransmission
• Connection establishment
• TCP-style flow control
• TCP-style congestion control

UDP applications must add any required reliability, ordering, congestion handling or duplicate protection through the application protocol or another protocol layered above UDP.

UDP Header

The UDP header contains four fields:

• Source port
• Destination port
• Length
• Checksum

+----------------------+----------------------+
| Source Port          | Destination Port     |
+----------------------+----------------------+
| Length               | Checksum             |
+----------------------+----------------------+
| Datagram Payload                            |
+---------------------------------------------+

The UDP length includes the header and data. The minimum UDP length is eight octets because the UDP header itself occupies eight octets.

UDP Preserves Datagram Boundaries

Unlike a TCP byte stream, UDP presents separately sent datagrams as individual datagrams to the receiving application, subject to delivery and receive-buffer limitations.

Sender:

Datagram A
Datagram B
Datagram C


Receiver can observe:

Datagram B
Datagram A

Datagram C may be lost.

A datagram may also be received more than once
or discarded when it cannot be accepted.

The precise behaviour depends on the network path, operating systems and application protocol.

TCP vs UDP

Choosing TCP or UDP

Choose a transport based on application requirements rather than the rule that one protocol is always faster or better.

Latency Considerations

End-to-end transport latency can include:

\[ L_{total} = L_{setup} + L_{transmission} + L_{propagation} + L_{queueing} + L_{retransmission} + L_{application} \]

TCP connection setup can add an initial exchange before application data is sent. UDP does not require that TCP-style setup, but a UDP application can introduce its own handshakes or security exchanges.

Packet loss can increase TCP stream completion time because missing data must be recovered before later bytes can be delivered in order. A UDP application may ignore obsolete missing data or implement its own recovery, depending on requirements.

Maximum Transmission Unit

The Maximum Transmission Unit, commonly abbreviated as MTU, limits the size of an IP packet that can be transferred over a link without link-specific subdivision or additional handling.

Applications should avoid assuming that one large application message maps to one network packet.

Application message
        |
        v
Transport processing
        |
        v
One or more IP packets
        |
        v
One or more link frames

Protocol headers reduce the space available for application data within a packet of a given size.

IP Fragmentation

Oversized IP packets can require fragmentation or can be rejected depending on the IP version, path and packet-handling policy.

Fragmentation introduces concerns such as:

• Additional packet-processing work
• Loss of one fragment preventing reassembly of the original packet
• Middlebox and firewall behaviour
• Reassembly resource consumption
• Datagram-size limits

UDP applications should follow applicable message-size and path-MTU guidance rather than routinely sending the largest possible datagrams.

TCP and UDP Do Not Provide Encryption

TCP and UDP do not by themselves provide application authentication, confidentiality or protection against application-level tampering.

Security can be provided by protocols layered above or around transport:

• TLS over a reliable stream transport
• Datagram-oriented security mechanisms
• Application message authentication
• Authenticated encryption within the application protocol

Security design must define identity, certificate or key management, replay protection, protocol negotiation and failure behaviour.

Retries and Duplicate Effects

Transport reliability does not make a business operation execute exactly once.

Client sends create-order request.

Server creates the order.

Response is lost before the client observes it.

Client retries.

Without idempotency:
A second order can be created.

With idempotency:
The server recognizes the repeated operation
and returns the original result.

Application-level idempotency is required when retries can repeat a non-idempotent business operation.

TCP Server Socket Flow

socket()
   |
   v
bind()
   |
   v
listen()
   |
   v
accept()
   |
   v
recv() and send()
   |
   v
close()

UDP Socket Flow

Server:

socket()
   |
   v
bind()
   |
   v
recvfrom()
   |
   v
sendto()


Client:

socket()
   |
   v
sendto()
   |
   v
recvfrom()

A UDP socket can also use connect() to establish a default peer and filter communication according to socket semantics, but this does not create a TCP connection or add TCP delivery guarantees.

Minimal POSIX UDP Echo Server

The following educational server receives one UDP datagram and sends the same bytes back to the sender.

#define _POSIX_C_SOURCE 200809L

#include <arpa/inet.h>
#include <errno.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

enum
{
    SERVER_PORT = 8080,
    BUFFER_CAPACITY = 4096
};

int main(void)
{
    int server =
        socket(
            AF_INET,
            SOCK_DGRAM,
            0
        );

    if (server == -1) {
        perror(
            "socket"
        );

        return EXIT_FAILURE;
    }

    struct sockaddr_in address;

    memset(
        &address,
        0,
        sizeof address
    );

    address.sin_family =
        AF_INET;

    address.sin_addr.s_addr =
        htonl(INADDR_ANY);

    address.sin_port =
        htons(SERVER_PORT);

    if (bind(
            server,
            (const struct sockaddr *)
                &address,
            sizeof address) == -1) {

        perror(
            "bind"
        );

        close(server);

        return EXIT_FAILURE;
    }

    unsigned char buffer[
        BUFFER_CAPACITY
    ];

    struct sockaddr_in client;
    socklen_t client_size =
        sizeof client;

    ssize_t amount;

    do {
        amount =
            recvfrom(
                server,
                buffer,
                sizeof buffer,
                0,
                (struct sockaddr *)
                    &client,
                &client_size
            );
    } while (
        amount == -1 &&
        errno == EINTR
    );

    if (amount == -1) {
        perror(
            "recvfrom"
        );

        close(server);

        return EXIT_FAILURE;
    }

    ssize_t sent;

    do {
        sent =
            sendto(
                server,
                buffer,
                (size_t)amount,
                0,
                (const struct sockaddr *)
                    &client,
                client_size
            );
    } while (
        sent == -1 &&
        errno == EINTR
    );

    if (sent == -1) {
        perror(
            "sendto"
        );

        close(server);

        return EXIT_FAILURE;
    }

    if (sent != amount) {
        fprintf(
            stderr,
            "The datagram was not sent completely.\n"
        );

        close(server);

        return EXIT_FAILURE;
    }

    if (close(server) == -1) {
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

Compile

cc -std=c17 -Wall -Wextra -Wpedantic udp_echo_server.c -o udp_echo_server

A production UDP service requires datagram-size limits, sender validation, rate controls, congestion handling, authentication where required, duplicate policy, timeouts and observability.

Minimal POSIX UDP Echo Client

#define _POSIX_C_SOURCE 200809L

#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

enum
{
    SERVER_PORT = 8080
};

int main(void)
{
    int client =
        socket(
            AF_INET,
            SOCK_DGRAM,
            0
        );

    if (client == -1) {
        perror(
            "socket"
        );

        return EXIT_FAILURE;
    }

    struct sockaddr_in server;

    memset(
        &server,
        0,
        sizeof server
    );

    server.sin_family =
        AF_INET;

    server.sin_port =
        htons(SERVER_PORT);

    if (inet_pton(
            AF_INET,
            "127.0.0.1",
            &server.sin_addr) != 1) {

        fprintf(
            stderr,
            "Invalid server address.\n"
        );

        close(client);

        return EXIT_FAILURE;
    }

    const char message[] =
        "Hello through UDP.";

    ssize_t sent =
        sendto(
            client,
            message,
            sizeof message - 1,
            0,
            (const struct sockaddr *)
                &server,
            sizeof server
        );

    if (sent == -1) {
        perror(
            "sendto"
        );

        close(client);

        return EXIT_FAILURE;
    }

    unsigned char response[4096];

    ssize_t received =
        recvfrom(
            client,
            response,
            sizeof response,
            0,
            NULL,
            NULL
        );

    if (received == -1) {
        perror(
            "recvfrom"
        );

        close(client);

        return EXIT_FAILURE;
    }

    if (write(
            STDOUT_FILENO,
            response,
            (size_t)received) == -1) {

        close(client);

        return EXIT_FAILURE;
    }

    if (write(
            STDOUT_FILENO,
            "\n",
            1) == -1) {

        close(client);

        return EXIT_FAILURE;
    }

    if (close(client) == -1) {
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

This example can wait indefinitely when the response datagram is lost. Production code must apply a timeout, retry and duplicate-handling policy appropriate to the operation.

UDP Amplification Risk

A UDP service can receive a datagram containing a source address that does not represent the actual sender when source-address spoofing is possible along the path.

A service that sends a much larger response than the request can be abused to direct traffic toward another destination.

Small spoofed request
        |
        v
UDP service
        |
        v
Large response sent to forged source address

Defensive design can include:

• Request and response size controls
• Rate limiting
• Authentication or address validation before large responses
• Minimal responses to unverified clients
• Monitoring unusual request and response ratios

Important Transport Metrics

Linux Observation Commands

Display Addresses

ip address show

Display Routes

ip route show

Determine the Route to a Destination

ip route get 203.0.113.10

Display Listening TCP Sockets

ss -ltnp

Display UDP Sockets

ss -lunp

Display Established TCP Connections

ss -tn state established

Test Basic Reachability

ping -c 4 203.0.113.10

Observe the Network Path

tracepath 203.0.113.10

Capture TCP Packets

sudo tcpdump -i any -nn tcp port 8080

Capture UDP Datagrams

sudo tcpdump -i any -nn udp port 8080

Replace example destinations and ports with approved test values. Packet capture can expose sensitive payloads, addresses and credentials, so use authorized environments and appropriate filters.

Wireshark Filters

Wireshark can decode packet captures and display protocol fields.

tcp

udp

ip.addr == 203.0.113.10

tcp.port == 8080

udp.port == 8080

tcp.flags.syn == 1

tcp.analysis.retransmission

Filter availability and interpretation depend on the installed Wireshark version and captured protocols.

Common TCP/IP and UDP Mistakes

Recommended Test Cases

TCP/IP and UDP Best Practices

Practice Exercise

Compare a TCP echo service and a UDP echo service under controlled network conditions.

Tasks

1. Build a length-prefixed TCP echo service.
2. Build a bounded UDP echo service.
3. Capture the TCP connection-establishment exchange.
4. Confirm that TCP application messages can be split across reads.
5. Confirm that UDP preserves individual datagram boundaries.
6. Introduce controlled packet loss in a test environment.
7. Observe TCP retransmission behaviour.
8. Observe the UDP application's loss behaviour.
9. Add an application timeout to both clients.
10. Add a duplicate identifier to the UDP protocol.
11. Measure latency and completed requests.
12. Document which transport better satisfies each test requirement.

Comparison Template

Frequently Asked Questions