TCP/IP for Developers: What You Actually Need to Know

Every HTTP request your application makes, every WebSocket connection your frontend opens, every database query your backend executes — all of it runs on TCP/IP. Most developers work at layers above TCP without needing to think about it. But when things go wrong — connection timeouts, TLS errors, slow API responses, port conflicts — the developer who understands TCP/IP diagnoses and fixes the problem in minutes. The developer who does not spends hours guessing.

Why Developers Need to Understand TCP/IP

You do not need to implement TCP. But you need to understand it at the level where you can answer these questions from first principles:

• Why does my API call time out after exactly 30 seconds? (TCP connection timeout settings)
• Why is the first request to my server slow and subsequent requests fast? (TCP three-way handshake cost, connection pooling)
• Why does my container fail to connect to the database? (Network policies, port exposure, DNS resolution in container networks)
• Why is HTTPS slower than HTTP in development? (TLS handshake overhead)
• How do WebSockets maintain a persistent connection? (Long-lived TCP connection with application-level keepalives)

The OSI Model at the Right Depth

The OSI model is a seven-layer framework for understanding network communication. As a developer, you operate primarily at layers 4–7 and need a working understanding of layers 1–3.

• Layer 1 — Physical: Electrical signals, fiber optics, radio waves. Hardware concern. You never touch this.
• Layer 2 — Data Link: MAC addresses, Ethernet frames, Wi-Fi. The layer that moves data between devices on the same local network. Relevant when troubleshooting ARP issues or VLAN configuration.
• Layer 3 — Network: IP addresses, routing, ICMP (ping). The layer that moves packets between networks. IP addressing, subnets, and routing decisions happen here.
• Layer 4 — Transport: TCP and UDP. Connection establishment, reliability, flow control, port numbers. This is where TCP's guarantees and overhead live.
• Layer 5–6 — Session/Presentation: These are largely theoretical in modern implementations. TLS sits between layers 4 and 7 in practice.
• Layer 7 — Application: HTTP, DNS, SMTP, WebSockets, gRPC. The protocols your application code directly uses.

The practical TCP/IP stack (which predates OSI) maps to: Network Interface (≈ OSI 1–2), Internet (≈ OSI 3), Transport (≈ OSI 4), Application (≈ OSI 5–7). This is a cleaner mental model for most software developers.

IP Addressing and Subnets

Every device on a network has an IP address. IPv4 addresses are 32-bit numbers written as four octets (192.168.1.100). IPv6 addresses are 128-bit numbers written as eight groups of hexadecimal digits.

Subnets divide the IP address space into smaller networks. CIDR notation (Classless Inter-Domain Routing) expresses a subnet as an IP address and a prefix length: 192.168.1.0/24 means the first 24 bits (192.168.1) are the network address, and the remaining 8 bits (0–255) are host addresses. This subnet contains 254 usable host addresses.

As a developer working with cloud infrastructure and containers, you encounter subnets in VPC (Virtual Private Cloud) configuration, Kubernetes networking (pod CIDR, service CIDR), and Docker bridge networks. Understanding CIDR notation lets you read infrastructure configuration without guessing.

Private address ranges (never routable on the public internet):

• 10.0.0.0/8 — commonly used for VPCs and corporate networks
• 172.16.0.0/12 — commonly used by Docker and container orchestration
• 192.168.0.0/16 — commonly used for home and small office networks

How a TCP Connection Works

A TCP connection is established through a three-way handshake, transmits data reliably with acknowledgments and retransmission, and is terminated through a four-way handshake.

Connection Establishment: Three-Way Handshake

1. SYN: Client sends a SYN packet with its initial sequence number (ISN): "I want to connect, I'll start counting at sequence number X."
2. SYN-ACK: Server responds with its own SYN and acknowledges the client's: "I received your SYN, I'll start at sequence number Y, and I acknowledge your X."
3. ACK: Client acknowledges the server's SYN: "I received your SYN-ACK." Connection is established.

This handshake takes one full round-trip time (RTT) before any application data can flow. A 50ms RTT between client and server means every new TCP connection adds 50ms of latency before the first byte of HTTP request can be sent. Connection pooling (reusing existing connections for multiple requests) and HTTP/2 multiplexing (sending multiple requests over a single connection) exist primarily to avoid paying this cost repeatedly.

Data Transfer and Reliability

TCP guarantees delivery through acknowledgments and retransmission. Every segment the receiver accepts generates an ACK back to the sender. If the sender does not receive an ACK within a timeout, it retransmits the segment. TCP also performs flow control (the receiver's buffer size limits how much data the sender can transmit before waiting for an ACK) and congestion control (the sender backs off when network congestion causes packet loss).

DNS: The Internet's Phone Book

Before a TCP connection can be established to api.example.com, the client must resolve the hostname to an IP address. This DNS resolution happens before every connection to a hostname you have not recently contacted.

The DNS resolution process:

1. Check local DNS cache — if the IP for this hostname is cached and not expired, use it immediately
2. Query the recursive resolver (configured in your OS network settings, often 8.8.8.8 or 1.1.1.1)
3. The recursive resolver checks its cache — if cached, returns immediately
4. If not cached, the recursive resolver queries the root nameservers, then the TLD nameservers (.com), then the authoritative nameserver for the specific domain
5. The IP is returned and cached at each layer based on the TTL (Time to Live) value

DNS failures or slow resolution are a common source of application latency and downtime that is often misdiagnosed as a server issue. If DNS resolution for your API endpoint takes 500ms, that adds 500ms to every request where the DNS cache has expired. Setting appropriate TTLs (not too long for services that need to change IPs quickly, not too short to cause constant re-resolution overhead) is an operational concern every developer should understand.

HTTP and HTTPS Over TCP

HTTP/1.1 opens a TCP connection, sends a request, receives a response, and can optionally reuse the connection (keep-alive). HTTP/2 multiplexes multiple requests over a single TCP connection. HTTP/3 moves from TCP to QUIC (UDP-based) to reduce connection establishment latency.

For HTTPS, a TLS handshake occurs after the TCP handshake and before any HTTP data is exchanged. TLS 1.3 (the current standard) requires one additional round trip on top of the TCP handshake. TLS session resumption allows subsequent connections from the same client to skip the full handshake. Total latency for a fresh HTTPS connection on TLS 1.3: 2 RTTs before the first byte of the HTTP request.

TCP vs UDP: When to Use Each

TCP: use when data integrity is required, when order matters, and when the application cannot handle lost packets. HTTP/HTTPS, database connections, file transfers, email, SSH — all use TCP.

UDP: use when speed matters more than guaranteed delivery, when the application can handle or recover from packet loss itself, or when connection overhead is too expensive. DNS queries (single request/response, easy to retry), video/audio streaming (a dropped frame is better than stalling), multiplayer games (position updates are more useful than retransmitting old ones), and VoIP all use UDP.

Debugging Network Issues

The four tools that handle 90% of network debugging scenarios:

# Test HTTP connectivity and see headers
curl -v https://api.example.com/health

# Check if a port is open (TCP connection test)
curl -v telnet://database-host:5432

# DNS lookup
dig api.example.com
dig @8.8.8.8 api.example.com  # force specific resolver

# Show active connections and listening ports
ss -tlnp   # Linux (modern)
netstat -tlnp  # older systems / macOS

# Trace route to destination
traceroute api.example.com

For deeper inspection, Wireshark captures and analyzes actual packet traffic. For TLS issues specifically, `openssl s_client -connect host:443` shows the full TLS handshake details including certificate chain, cipher suite, and protocol version.