How Packets Actually Travel Across the Internet: TCP/IP Handshakes, MTU Fragmentation & mtr Diagnostics Illustrated

The Physical Reality of the Internet: Beyond the “Cloud” Abstraction

Software engineers spend their careers working high up in the OSI model. We write TypeScript, debug GraphQL resolvers, configure Docker containers, and reason about JSON payloads. The underlying network is treated as an infinite, frictionless black box where bits teleport instantaneously between client and server.

Until one day, a client in a specific corporate office reports that your website hangs on a blank screen for 30 seconds before timing out. Or an API endpoint returns instant responses for small JSON queries, but completely freezes when a payload exceeds 1,400 bytes.

THE MYSTERIOUS “BULK DATA FREEZE” BUG

• Client Browser SYN (64 Bytes) → Server (OK)
• Client Browser → SYN-ACK (64 Bytes) Server (OK)
• Client Browser ACK (64 Bytes) → Server (OK)
• Client Browser GET /api/v1/users (Small Request) → Server (OK)
• Client Browser → HTTP 200 OK: Tiny JSON (300 Bytes) Server (OK)
• Client Browser GET /api/v1/reports/pdf (Large Transfer) → Server
• Server Transmits 1500-Byte Frame (DF Flag Set) → Intermediate Router
• Router Drops Frame! (Tunnel MTU = 1420)
• Router Sends ICMP “Fragmentation Needed” → Blocked by Firewall!
• Result: Connection silently freezes forever! Both ends wait in silence.

To solve these mission-critical outages, you must understand how packets actually travel across the physical Internet: how the TCP three-way handshake establishes state, how Maximum Transmission Units (MTU) govern packet sizing, and how Path MTU Discovery black holes choke modern encrypted web traffic.

At our engineering firm, we design high-performance websites and provide technical consulting that optimize system performance down to the raw TCP/IP stack on Debian GNU/Linux.

The TCP/IP Three-Way Handshake: Mechanics and Round-Trip Latency

Before a browser can send a single byte of HTTP data or negotiate a TLS 1.3 session, it must establish a reliable state machine with the target server via the TCP Three-Way Handshake.

THE TCP THREE-WAY HANDSHAKE PROTOCOL

• Client (e.g., 198.51.100.12)
• Server (e.g., 203.0.113.80)
• SYN (Seq = 1000, MSS = 1460, SACK = Permitted) → State: SYN-RCVD
• SYN-ACK (Seq = 5000, Ack = 1001, MSS = 1460)
• State: ESTABLISHED
• ACK (Seq = 1001, Ack = 5001) → State: ESTABLISHED
• HANDSHAKE COMPLETE (1 Full RTT Incurred)
• Application Data / TLS Client Hello

Breaking Down the Exchange:

1. SYN (Synchronize): The client generates a random 32-bit Initial Sequence Number (e.g., Seq = 1000) and transmits TCP options: its Maximum Segment Size (MSS = 1460), Window Scale factor, and Selective Acknowledgment (SACK) support.
2. SYN-ACK (Synchronize-Acknowledge): The server allocates memory in its TCP connection backlog, generates its own Initial Sequence Number (Seq = 5000), and acknowledges the client by incrementing the sequence number (Ack = 1001).
3. ACK (Acknowledge): The client acknowledges the server’s sequence number (Ack = 5001). Both sockets transition to ESTABLISHED.

This exchange requires one full Round-Trip Time (RTT). If your server is hosted in Frankfurt and your visitor is browsing from Lisbon with a 45ms RTT, the client must wait 45ms just to establish the TCP socket, followed by another 45ms for TLS negotiation, before the first HTTP byte is exchanged. This physical latency is why leveraging edge distribution and anycast networks like Cloudflare is essential for global performance.

MTU vs. MSS: The Mathematical Anatomy of an Ethernet Frame

Every physical network link has a hardware limit on the size of a single packet frame. This boundary is the Maximum Transmission Unit (MTU).

On standard Ethernet networks, the MTU is 1,500 bytes.

ETHERNET FRAME PACKET BREAKDOWN Total Ethernet Frame MTU: 1,500 Bytes

• IPv4 Header (20 Bytes)
• TCP Header (20 Bytes)
• TCP Payload Data (Maximum Segment Size) (1,460 Bytes - MSS)

When encapsulation protocols are added—such as WireGuard VPN tunnels, PPPoE broadband connections, VXLAN overlays in cloud datacenters, or IPSec tunnels—the available MTU shrinks:

• Standard Ethernet: 1,500 bytes (MSS = 1,460 bytes)
• PPPoE DSL Connections: 1,492 bytes (MSS = 1,452 bytes)
• WireGuard VPN Tunnel: 1,420 bytes (MSS = 1,380 bytes)
• AWS / Cloud Overlay VXLAN: 1,450 bytes (MSS = 1,410 bytes)

If a server transmits a 1,500-byte frame into a WireGuard tunnel with an MTU of 1,420 bytes, the router must either fragment the packet into two separate IP packets or drop it. Because modern web servers set the Don’t Fragment (DF) bit on all TCP packets to prevent inefficient CPU fragmentation, the intermediate router drops the packet and relies on Path MTU Discovery (PMTUD).

The PMTUD Black Hole Disaster & MSS Clamping Fix

When an intermediate router drops a packet that exceeds its MTU, it generates an ICMP message: Type 3, Code 4 (Destination Unreachable, Fragmentation Needed and DF set). The sender’s operating system reads this ICMP packet and immediately lowers its TCP MSS for that specific connection.

The disaster occurs when an intermediate firewall administrator blindly blocks all ICMP traffic under the mistaken belief that “blocking ping makes the network more secure.”

THE ICMP BLACK HOLE DISASTER PATTERN

• Web Server (MTU 1500) → [Packet: 1500B] → Router (Tunnel MTU 1420)
• Packet DROPPED!
• Web Server → [BLOCKED BY FIREWALL!] → ICMP Fragmentation Needed
• Result: The web server retransmits the 1500B packet 5 times, waits for ACK, and eventually drops the connection with ETIMEDOUT. The client sees a blank screen!

The Production Fix: TCP MSS Clamping

If you manage Linux routers, VPN gateways, or edge firewalls, you can cure PMTUD black holes permanently using nftables or iptables to clamp the MSS during the initial SYN handshake:

# Clamp TCP MSS to the path MTU automatically using nftables
nft add table ip filter
nft add chain ip filter forward { type filter hook forward priority 0 \; }
nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu

# Or using legacy iptables on Debian routers:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

This kernel rule intercepts the initial SYN packet in flight and dynamically rewrites the advertised MSS so neither client nor server ever attempts to transmit a packet larger than the tunnel MTU.

Diagnosing Network Degradation with mtr (My Traceroute)

When users report packet loss, erratic latency, or broken connections, standard ping and traceroute are inadequate. ping cannot isolate where along the path packet loss occurs, and traceroute samples each router only three times, missing intermittent micro-burst drops.

The ultimate Linux network diagnostic utility is mtr (My Traceroute), an open-source tool maintained on GitHub.

Running a Robust Diagnostic Probe

Install and execute mtr in report mode over 100 consecutive cycles:

# Install mtr on Debian / Ubuntu
apt update && apt install -y mtr-tiny

# Run 100 probes with raw numerical IP resolution
mtr --report --report-cycles 100 --no-dns 203.0.113.80

INTERPRETING AN MTR PRODUCTION REPORT

• Host: 1. 192.168.1.1 • 2. 10.0.0.1 • 3. 195.23.0.45 • 4. 84.16.12.9 • 5. 130.117.0.22 • 6. 198.51.100.1 • 7. 203.0.113.80
• Loss% Snt Last Avg Best Wrst StDev: 0.0% 100 0.8 0.9 0.6 2.1 0.3 • 0.0% 100 4.2 4.5 3.9 8.1 0.7 • 0.0% 100 12.1 12.4 11.8 16.5 1.1 • 65.0% 100 14.2 14.5 13.9 19.2 1.4 → (ICMP Rate Limited) • 0.0% 100 22.4 22.8 22.1 28.9 1.2 • 0.0% 100 24.1 24.5 23.8 31.2 1.5 • 0.0% 100 24.3 24.6 24.0 30.5 1.3

How to Read the Diagnostic Data Correctly:

• Notice Hop 4: It displays 65.0% Loss%. An amateur administrator might assume Hop 4 is failing. But observe Hop 5, 6, and 7: the final destination shows 0.0% packet loss! Hop 4 is simply rate-limiting its own ICMP generation on the router’s control plane while forwarding transit traffic at line rate.
• Genuine Packet Loss: If Hop 4 showed 20% loss, and that 20% loss persisted across Hops 5, 6, and 7, then Hop 4 is suffering true hardware or link congestion that is degrading production traffic.

Mastering these low-level TCP/IP mechanics enables engineering teams to solve elusive production bugs that masquerade as application failures. Backed by our robust managed hosting infrastructure, your services stay responsive, properly MTU-sized, and rock-solid across every network route.

Alongside our operational work at Webxtek Studio, we apply these exact architectural standards across specialized sectors including devops & cloud architecture specialists and cloud computing & iaas providers. Whether you are modernizing core workflows through high-performance websites and technical consulting before you build, connecting sector-specific requirements to disciplined execution is what turns technical theory into compounding commercial advantage.