Technical Deep Dive: TCP Ping vs ICMP Ping – Handshake Timing Analysis and Packet Size Configuration


4 views

TCP ping and traceroute operate fundamentally differently from their ICMP counterparts by leveraging the TCP protocol stack. When performing a TCP ping, the measurement primarily consists of:

  • The full TCP three-way handshake duration (SYN → SYN-ACK → ACK)
  • Optional FIN/RST exchange timing when closing the connection
  • Application-layer response time if probing specific services (e.g., HTTP)

Unlike ICMP echo requests where packet size can be directly specified in the payload, TCP ping implementations handle this differently:

// Example TCP ping implementation in Python
import socket
import time

def tcp_ping(host, port=80, timeout=5):
    try:
        start = time.time()
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(timeout)
        sock.connect((host, port))
        sock.shutdown(socket.SHUT_RDWR)
        end = time.time()
        return end - start
    except Exception as e:
        return None

While you can't directly set TCP packet sizes like ICMP payloads, you can influence segment size through:

  • TCP MSS (Maximum Segment Size) negotiation during handshake
  • Application-layer payload injection after connection establishment
  • Socket buffer size configurations

TCP traceroute works by sending TCP SYN packets with increasing TTL values:

# Linux TCP traceroute example
traceroute -T -p 80 example.com

# Windows equivalent (using PowerShell)
Test-NetConnection -TraceRoute -Port 80 -ComputerName example.com

TCP-based connectivity testing is particularly useful for:

  • Firewall-friendly network diagnostics (SYN packets often permitted when ICMP is blocked)
  • Service-specific latency measurement (e.g., web server response times)
  • Path MTU discovery in TCP-heavy environments

Important metrics to track include:

Metric TCP Ping ICMP Ping
Handshake Time
Packet Loss
Path Integrity

TCP ping operates differently from traditional ICMP ping by leveraging the TCP three-way handshake process to measure network latency. Instead of sending ICMP echo requests, it initiates a TCP connection to a specified port (typically port 80 for HTTP or 443 for HTTPS).

# Python TCP ping example using socket
import socket
import time

def tcp_ping(host, port=80, timeout=2):
    try:
        start = time.time()
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(timeout)
        s.connect((host, port))
        s.close()
        return (time.time() - start) * 1000  # Convert to milliseconds
    except Exception as e:
        return None

While ICMP ping measures round-trip time for simple echo requests/replies, TCP ping specifically measures:

  • SYN packet transmission time
  • SYN-ACK response time
  • Final ACK completion time

This makes TCP ping particularly useful for measuring service availability and latency for actual TCP-based applications.

TCP traceroute works by sending TCP SYN packets with increasing TTL values, similar to how traditional traceroute operates but using TCP instead of ICMP or UDP.

# Linux command for TCP traceroute
traceroute -T -p 80 example.com
# Windows equivalent (using PowerShell)
Test-NetConnection example.com -TraceRoute -Port 80

Unlike ICMP ping where you can explicitly set packet size (e.g., ping -s 1000 example.com), TCP ping doesn't directly allow packet size specification since:

  • TCP handshake packets have fixed sizes
  • Data transmission only occurs after connection establishment

However, you can simulate size testing by sending data after connection:

# Python example with data transmission
def tcp_ping_with_size(host, port=80, size=1024, timeout=2):
    try:
        data = b'X' * size
        start = time.time()
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(timeout)
        s.connect((host, port))
        s.sendall(data)
        s.close()
        return (time.time() - start) * 1000
    except Exception as e:
        return None

TCP ping/traceroute is particularly valuable when:

  • ICMP is blocked by firewalls
  • Testing specific service availability (HTTP, HTTPS, etc.)
  • Measuring real-world application performance rather than network layer metrics
  • Troubleshooting NAT or firewall issues

The main limitation is that it requires an open TCP port to test against, unlike ICMP which works at the network layer.