Simulating Large Data Transmission with Redis

To analyze TCP behavior with large payloads, a Java client can be used to push data significantly exceeding the typical MTU size into a Redis instance. The following example generates a string payload of approximately 38KB and sends it to the server.

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;

public class RedisDataSender {
    private static final String SERVER_HOST = "192.168.1.100";
    private static final int SERVER_PORT = 6379;

    public static void main(String[] args) {
        try (JedisPool pool = new JedisPool(SERVER_HOST, SERVER_PORT);
             Jedis client = pool.getResource()) {
            
            StringBuilder payloadBuilder = new StringBuilder();
            for (int i = 0; i < 10000; i++) {
                payloadBuilder.append(i);
            }
            
            String largePayload = payloadBuilder.toString();
            System.out.println("Payload size: " + largePayload.getBytes().length + " bytes");

            client.set("large_data_key", largePayload);
        }
    }
}

Upon executing this code, a packet capture on the Redis server might display unexpected results. Instead of seeing numerous small frames limited by the 1500-byte MTU, the capture could show large segments, potentially exceeding 14,000 bytes or more.

Analyzing the Network Capture Anomaly

Running tcpdump on the server interface reveals that the transmitted data sizes far exceed the Ethernet MTU of 1500 bytes. While the link layer strictly enforces the MTU, the capture suggests that single transmissions are handling data blocks ten times the limit. This discrepancy arises not from a violation of network standards, but from optimization techniques implemented in modern Network Interface Cards (NICs) and drivers.

Understanding TCP Offloading: TSO and GRO

The underlying reason for observing packets larger than the MTU lies in TCP offloading features, specifically TSO and GRO. These mechanisms are enabled by default in most Linux distributions to improve network throughput and reduce CPU utilization.

TCP Segmentation Offload (TSO)

TSO allows the operating system's TCP stack to pass a large chunk of data to the network hardware without segmenting it into MSS-sized packets. The NIC hardware takes responsibility for breaking the large buffer into smaller frames compliant with the MTU. This significantly reduces the CPU overhead required for protocol processing on the sender side.

Generic Receive Offload (GRO)

GRO operates on the receiving end. It enables the NIC driver to aggregate multiple incoming TCP segments that belong to the same stream into a single, larger packet before passing them to the upper layers of the network stack. This reduces the number of packets the kernel must process, thereby saving CPU cycles. Since packet capture tools like tcpdump often hook into the stack after this aggregation has occurred, they display these merged, large packets rather than the original MTU-sized frames.

Verifying MTU Compliance

To observe the actual transmission size on the wire, GRO can be disabled on the network interface.

ethtool -K eth0 gro off

After disabling GRO, the packet capture will accurately reflect the physical transmission characteristics. The output will then show standard Ethernet frames, each carrying a payload close to the 1500-byte MTU limit, confirming that the data is indeed being segmented correctly at the link layer.