When the receiving TCP gets a segment without errors, it sends a positive acknowledgement (ACK) back to the sender. This ACK tells the sender: “I received everything up to byte N. Send me byte N+1 next.”

If a segment arrives with errors (checksum fails), the receiver simply discards it silently. No negative ACK is sent. The sender detects this through a timeout.

The ACK number is cumulative: ACK=1001 means “I have received all bytes up to and including byte 1000.” This is also called a cumulative acknowledgement.

Every time TCP sends a segment, it starts a retransmission timer. If an ACK for that segment does not arrive before the timer expires, TCP assumes the segment was lost and retransmits it.

The key question is: how long should the timer be? Too short → unnecessary retransmissions (wastes bandwidth). Too long → slow recovery from real losses.

TCP solves this with a dynamic RTO (Retransmission Timeout). It continuously measures the Round Trip Time (RTT) — the time from sending a segment to receiving its ACK — and adjusts the RTO accordingly.

In a normal request-response protocol (like HTTP), after receiving a request, the server sends a response right away. TCP is smart: instead of sending a separate ACK packet, the server can piggyback the ACK onto the response data it is already sending.

The Delayed ACK technique: instead of sending an ACK immediately on receiving a segment, the receiver waits a short time (typically up to 200ms) to see if there is any outgoing data to send. If there is, the ACK rides along with that data. If not, the ACK is sent on its own after the delay.

Trade-off: Delayed ACK reduces the number of packets but adds a small delay. For interactive applications (like SSH), this can be noticeable. The TCP_NODELAY socket option (Nagle algorithm) can be used to disable this behavior.

The TCP_NODELAY socket option disables the Nagle algorithm, which is related to delayed ACK. When set, small segments are sent immediately rather than being buffered. This is important for real-time or low-latency applications.

/* tcp_nodelay_example.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>   /* for TCP_NODELAY */
#include <arpa/inet.h>

int main(void)
{
    int sockfd;
    int optval = 1;

    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd == -1) { perror("socket"); exit(EXIT_FAILURE); }

    /*
     * TCP_NODELAY: disables Nagle's algorithm
     * Without TCP_NODELAY: small writes may be buffered and batched together
     * With TCP_NODELAY: each write() sends a segment immediately
     *
     * Use when you need low latency (SSH, game servers, telemetry)
     * Avoid for bulk data transfer — Nagle reduces overhead there
     */
    if (setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY,
                   &optval, sizeof(optval)) == -1) {
        perror("setsockopt TCP_NODELAY");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    printf("TCP_NODELAY enabled — segments sent immediately\n");

    /* Check what value is set */
    socklen_t optlen = sizeof(optval);
    if (getsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY,
                   &optval, &optlen) == -1) {
        perror("getsockopt");
    } else {
        printf("TCP_NODELAY is currently: %s\n", optval ? "ON" : "OFF");
    }

    close(sockfd);
    return 0;
}

/* Checking RTO-related socket options */
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <unistd.h>

int main(void)
{
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    struct tcp_info info;
    socklen_t len = sizeof(info);

    if (getsockopt(sockfd, IPPROTO_TCP, TCP_INFO, &info, &len) == 0) {
        printf("RTT (smoothed): %u microseconds\n", info.tcpi_rtt);
        printf("RTT variance:   %u microseconds\n", info.tcpi_rttvar);
        printf("RTO:            %u microseconds\n", info.tcpi_rto);
        printf("Retransmits:    %u\n",               info.tcpi_retransmits);
    }

    close(sockfd);
    return 0;
}

Note: struct tcp_info and TCP_INFO are Linux-specific. They expose the TCP stack’s internal state for a socket — very useful for debugging network performance issues.