TCP/IP Fundamentals for DevOps

By Kokil Thapa | Last reviewed: September 2026

You cannot debug a deployment timeout, a flaky load balancer, or a firewall rule without TCP/IP fundamentals for DevOps. Every HTTPS request, SSH session, database connection, and health check rides the same stack. On real client projects I maintain with Linux system administration and Deployer 7 releases, most "app bugs" turn out to be routing, DNS, or port issues. This guide maps the stack to commands you will run on Ubuntu servers today.

What is the TCP/IP model and why does DevOps need it?

The TCP/IP model is a four-layer reference for how data moves across networks. It is simpler than the seven-layer OSI model, but both describe the same reality. DevOps work sits mostly at layers three and four, with constant overlap into DNS and HTTP at layer seven.

Think of each layer as a contract. Lower layers deliver frames and routes. Upper layers deliver reliable byte streams or fire-and-forget datagrams. When a Laravel queue worker cannot reach Redis, you peel the onion from application down to IP.

Layer responsibilities you will touch daily

• Link (L2): MAC addresses, switches, VLAN tags. Relevant when containers share a bridge or when cloud ENIs attach to subnets.
• Internet (L3): IP addressing, routing, ICMP ping and traceroute. Core to VPC design and cloud networking fundamentals.
• Transport (L4): TCP and UDP, port numbers, connection state. Load balancers and reverse proxies terminate here.
• Application (L7): HTTP, TLS, DNS queries. Your app health checks and API gateways live here.

The IETF defines TCP in RFC 9293, which obsoletes the classic RFC 793. You do not need to memorise every flag, but you should know what SYN, ACK, FIN, and RST mean when you read a packet capture.

How do IP addresses and subnetting work in production?

Every host on an IP network needs a unique address within its routable scope. IPv4 uses 32-bit dotted decimal notation like 192.168.10.25. IPv6 uses 128-bit hex groups like 2001:db8::1. Private ranges—10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16—are not routed on the public internet.

CIDR notation tells you how many bits belong to the network prefix. A /24 subnet has 256 addresses; typically 254 are usable after network and broadcast reservations. On Ubuntu servers I configure static addressing with Netplan, as covered in our guide on configuring a static IP on Ubuntu with Netplan.

Quick subnet math for DevOps

A /24 mask is 255.255.255.0. The network address is the first IP. The broadcast is the last. Everything between is assignable to hosts, load balancers, or database nodes.

# Example /24 split for a small production VPC
Network:   10.20.30.0/24
Gateway:   10.20.30.1      (router or cloud .1)
Web tier:  10.20.30.10–49
App tier:  10.20.30.50–99
DB tier:   10.20.30.100–149
Reserved:  10.20.30.200–254

Splitting tiers by subnet block is a cheap security win. You write firewall rules that allow port 3306 only from the app subnet to the DB subnet. That pattern appears on every Laravel production deployment I have shipped with separate web and database hosts.

Loopback, link-local, and NAT

127.0.0.1 is the loopback interface. Services bound to 127.0.0.1 accept local connections only. Binding to 0.0.0.0 listens on all interfaces—a common misconfiguration that exposes Redis or MySQL to the world.

NAT translates private addresses to a public IP at your router or cloud NAT gateway. Outbound connections work. Inbound connections need explicit port forwarding or a load balancer. This is why you cannot SSH to a laptop behind home NAT without port mapping or a VPN.

What is the difference between TCP and UDP for DevOps?

TCP is connection-oriented and reliable. It guarantees ordered delivery, retransmits lost segments, and manages flow control. UDP is connectionless. It sends datagrams with no delivery guarantee and no built-in ordering.

Most DevOps traffic is TCP. HTTP, HTTPS, SSH, PostgreSQL, MySQL, and Redis (by default) all use TCP. UDP shows up in DNS queries, DHCP, NTP, QUIC/HTTP3, and some monitoring protocols.

Ports and socket pairs

A socket is identified by protocol, source IP, source port, destination IP, and destination port. Well-known ports below 1024 require root on Linux. Ephemeral ports above 32768 are assigned automatically for outbound connections.

# Common ports you will firewall or health-check
22    SSH
80    HTTP
443   HTTPS
3306  MySQL
5432  PostgreSQL
6379  Redis
8080  Alternate HTTP / proxies

When a deploy fails with "connection refused," the target host received the packet but nothing listens on that port. "Connection timed out" usually means a firewall or routing drop along the path. "No route to host" means the kernel has no path to the destination network.

How do you troubleshoot TCP/IP connectivity on Linux?

Linux gives you a solid toolkit. Start at layer three with ping and traceroute. Move to layer four with ss and nc. Capture packets with tcpdump when logs are not enough. This workflow matches what I use during production support and maintenance on Ubuntu 22/24 servers.

Essential commands

1. Check interfaces and routes: ip addr and ip route
2. Test reachability: ping -c 4 db.internal
3. Trace path: traceroute api.example.com or mtr -rw api.example.com
4. List listeners: ss -tlnp
5. Test a port: nc -zv db.internal 5432
6. Capture traffic: sudo tcpdump -i any host db.internal and port 5432 -w capture.pcap

The ss command replaces legacy netstat on modern Linux. It reads directly from kernel socket tables and runs faster under load. See the ss(8) man page for filter syntax.

Firewall and connection tracking

UFW on Ubuntu wraps iptables/nftables rules. A rule like ufw allow 443/tcp permits inbound HTTPS. Outbound traffic is allowed by default. Stateful firewalls track connection state—return traffic for an established TCP session passes even without an explicit inbound rule.

# Allow web and SSH; deny everything else inbound
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Half-open SYN floods exhaust the SYN backlog queue. You will see many SYN_RECV states in ss -tan. Mitigations include SYN cookies and tuning net.ipv4.tcp_max_syn_backlog. These topics appear often in Linux interview questions for DevOps.

How does DNS fit into the TCP/IP stack for deployments?

DNS resolves human names to IP addresses. Most queries use UDP port 53 for speed. Large responses or zone transfers fall back to TCP. Every deploy that changes an A record, CNAME, or TTL depends on understanding this behaviour.

TTL controls cache lifetime. A TTL of 300 seconds means resolvers may serve stale data for five minutes after you change a record. Lower TTL before migration, then raise it after cutover. I follow this pattern on every domain and hosting migration.

DNS records DevOps engineers touch

• A / AAAA: Hostname to IPv4 or IPv6 address.
• CNAME: Alias to another hostname. Cannot coexist with other records on the same name.
• MX: Mail routing priority and target.
• TXT: SPF, DKIM, domain verification tokens.
• SRV: Service discovery with port and priority—used by some internal tools.

# Query DNS from a production host
dig +short app.example.com A
dig +trace example.com
dig @8.8.8.8 staging.example.com AAAA

# Test resolution inside a container
docker exec -it myapp dig db.internal

Split-horizon DNS serves different answers inside a VPC versus on the public internet. Your app may resolve db.internal to a private IP while external users never see that record. Cloud providers implement this with Route 53 private zones, Azure Private DNS, or internal BIND servers.

How do load balancers and proxies use TCP/IP in DevOps?

Reverse proxies like Nginx and Envoy terminate TCP connections from clients. They may open separate upstream TCP connections to backend servers. This is why you see twice the connection count during traffic spikes. Understanding this split prevents misreading ss output during incidents.

Layer 4 load balancers route by IP and port only. Layer 7 load balancers inspect HTTP headers, cookies, or paths. AWS ALB operates at L7. NLB operates at L4. The choice affects health checks, TLS termination, and sticky sessions. Our Envoy proxy fundamentals article goes deeper on modern proxy behaviour.

TLS and TCP together

TLS runs inside TCP. The client completes the three-way handshake first. Then ClientHello begins the TLS negotiation. A certificate mismatch or expired cert fails at the TLS layer even when TCP and routing work fine. Test with:

openssl s_client -connect app.example.com:443 -servername app.example.com

Keepalive timers prevent idle TCP connections from being dropped by middleboxes. Nginx proxy_read_timeout and Linux net.ipv4.tcp_keepalive_time interact with long-polling and WebSocket workloads. Tune both sides when connections drop silently after idle periods.

Monitoring and observability hooks

Prometheus exporters scrape HTTP over TCP. Blackbox exporters probe TCP connect time and TLS validity. Knowing which layer failed—DNS, TCP connect, TLS, or HTTP status—cuts mean time to recovery sharply. Pair network basics with our guide on Prometheus metrics and monitoring fundamentals.

Container networking adds virtual bridges and overlay networks. Kubernetes Services map cluster IPs to pod endpoints through kube-proxy iptables or IPVS rules. The packets still obey TCP/IP; the indirection just adds NAT and DNAT hops. Service meshes like Istio inject sidecar proxies that capture L4/L7 traffic—see Istio service mesh fundamentals for the application-layer extension.

MTU and fragmentation gotchas

MTU is the largest IP packet size on a link, typically 1500 bytes on Ethernet. VPN tunnels and cloud overlays often use lower effective MTU. Oversized packets fragment or drop with DF (Don't Fragment) set, causing mysterious "works for small requests, fails for large JSON" bugs.

# Discover path MTU with ping (Linux)
ping -M do -s 1472 db.internal   # 1472 + 28 header = 1500
# Reduce until packets pass, then adjust interface MTU or MSS clamp

I have hit this on VPN links between a Kathmandu office and a Singapore EC2 instance. The fix was MSS clamping on the tunnel interface, not application code changes.

Putting it together in CI/CD and deploy pipelines

Your pipeline runner must reach GitLab, Docker registries, and production SSH targets over TCP. A runner behind strict egress rules needs outbound 443 to the registry and outbound 22 or custom SSH ports to deploy hosts. GitLab CI jobs that curl internal APIs fail when DNS inside the runner container cannot resolve private zone names.

On sister sites I deploy with Deployer 7 and GitLab CI—Notary Kathmandu shares that pipeline pattern. A broken SSH route or stale DNS after an IP change blocks the entire release. Network literacy saves hours of blaming Composer or PHP-FPM opcache first.

For structured log parsing of connection errors, a regex tester helps you build patterns that match timeout and refused strings across Nginx, PHP-FPM, and application logs. Combine that with Bash scripting patterns for DevOps to automate post-deploy connectivity checks.

If you are building skills systematically, the DevOps roadmap for 2026 and DevOps engineer skills roadmap place networking alongside Linux and CI/CD. Interview prep? Review AWS DevOps interview questions—many focus on VPC, security groups, and TCP health checks.

Performance tuning also depends on TCP window sizes, congestion control algorithms, and buffer limits. Before chasing application code, check ss -ti for retransmits and RTT on hot connections. Our testing and optimization service often starts with network baselines, not frontend bundles.

Enterprise apps with microservices multiply east-west traffic inside a VPC. Security groups become your primary L4 firewall. Each service needs explicit allow rules. Document port matrices early. Custom software projects from our custom software development practice include this matrix in the architecture doc before the first sprint ends.

Read more about the practitioner behind these notes on about me, or browse the full home page for related guides. Client proof lives in the portfolio—every listed project runs on the same TCP/IP rules described here.

Key Takeaways

• Map every outage to a layer: routing (L3), port/listener (L4), or HTTP/TLS/DNS (L7) before changing application code.
• Memorise the difference between "connection refused," "timeout," and "no route to host"—each points to a different fix.
• Use ip, ss, dig, and tcpdump as your default Linux quartet; they answer 90% of production network questions.
• Plan subnet tiers and security group rules together; treat DNS TTL as part of your migration runbook.
• Load balancers and proxies create multiple TCP connections per request—debug upstream and downstream separately.
• Check MTU and TLS when small requests work but large payloads or HTTPS handshakes fail intermittently.

People Also Ask

What OSI layer does TCP operate at?

TCP lives at layer four—the transport layer. It provides reliable, ordered byte streams between applications identified by port numbers. IP at layer three handles addressing and routing. Together they deliver data across the internet.

Why do DevOps engineers need to understand subnetting?

Subnetting defines which hosts can talk directly and which need a router. Cloud VPCs, Kubernetes pod CIDRs, and firewall rules all use CIDR notation. Wrong subnet sizing forces painful redesigns when you outgrow a /24.

Is HTTP TCP or UDP?

HTTP/1.1 and HTTP/2 run over TCP, usually on port 443 with TLS. HTTP/3 uses QUIC, which runs over UDP. Most production DevOps tooling and health checks still assume TCP-based HTTP today.

What is the fastest way to check if a port is open on Linux?

Run nc -zv hostname port or ss -tlnp | grep :port on the server itself. From a remote host, nc -zv tests the full path including firewalls. Combine with tcpdump if the result surprises you.

Build reliable infrastructure on solid networking

TCP/IP fundamentals for DevOps are not academic trivia. They are the language of every timeout log, security group rule, and failed deploy you will face in 2026. Start with layers, practice the Linux commands on a home lab, and trace one real incident end to end. When you want help auditing VPC layout, hardening firewalls, or fixing production connectivity on Ubuntu, contact us or explore Linux system administration in Nepal for hands-on support.