TCP/IP Fundamentals
Volume 2 — Networking Foundations
Most of the debugging you'll ever do — a CORS error, an API timeout, a database connection that works locally but not from Azure, a certificate warning — traces back to something in this chapter. This is the foundation the rest of Volume 2 (DNS, SSL/TLS, VPNs, load balancers) builds on.
1. The OSI Model vs. the TCP/IP Model
The OSI model is the theoretical, 7-layer way of describing network communication. TCP/IP (what the internet actually runs on) collapses it into 4 practical layers. You'll hear both — here's how they map:
| OSI Layer | OSI Name | TCP/IP Layer | What lives here |
|---|---|---|---|
| 7 | Application | Application | HTTP, HTTPS, DNS, SMTP — the protocols your app actually speaks |
| 6 | Presentation | Application | TLS/encryption, data formatting |
| 5 | Session | Application | Session management |
| 4 | Transport | Transport | TCP, UDP — ports, reliability, ordering |
| 3 | Network | Internet | IP addresses, routing |
| 2 | Data Link | Network Access | MAC addresses, switches |
| 1 | Physical | Network Access | Cables, wifi signals, actual bits on the wire |
In day-to-day debugging you'll mostly live at the Application and Transport layers: is the DNS name resolving, is the port open, did the TLS handshake succeed, did the HTTP request get a response. The lower layers matter mostly when connectivity is broken at a more fundamental level (no network at all, VPN down).
2. IP Addresses
An IP address identifies a device on a network — like a mailing address for data.
IPv4 — four numbers 0–255, separated by dots:
192.168.1.42
IPv6 — designed to solve IPv4's limited address space (roughly 4.3 billion addresses, which the internet has now exhausted), written as eight groups of hex digits:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
You'll work with IPv4 far more often day to day, but Azure resources increasingly support IPv6 alongside it, and it's worth being able to recognize one when you see it in logs or configuration.
Public vs. private addresses
Certain IPv4 ranges are reserved for private networks and are never routable on the public internet:
| Range | Common use |
|---|---|
10.0.0.0 – 10.255.255.255 | Large private networks — this is the range Azure VNets typically use |
172.16.0.0 – 172.31.255.255 | Private networks, often Docker's default range |
192.168.0.0 – 192.168.255.255 | Home/small office networks |
127.0.0.0 – 127.255.255.255 | Loopback — 127.0.0.1 is always "this machine" |
This is why your laptop and an Azure VM can both have the address 10.0.0.4 without conflict — they're private addresses meaningful only inside their own network. Public-facing services (like api.roundtrips.app) resolve to a public IP address that's globally unique.
3. Subnetting and CIDR Notation
CIDR (Classless Inter-Domain Routing) notation describes both an IP address and how many bits of it are "fixed" (the network portion) vs. flexible (the host portion), written as address/prefix-length.
10.0.0.0/24
The /24 means the first 24 bits are the fixed network portion, leaving 8 bits (2^8 = 256 addresses, 254 usable) for individual hosts on that subnet.
| CIDR | Total addresses | Usable hosts | Common use |
|---|---|---|---|
/32 | 1 | 1 | A single specific host |
/29 | 8 | 6 | A tiny subnet, e.g. a small VNet subnet |
/24 | 256 | 254 | A typical subnet size |
/16 | 65,536 | 65,534 | A typical whole VNet address space |
/8 | 16,777,216 | 16,777,214 | An entire large private range |
("Usable" is 2 less than total because the first address identifies the network itself and the last is the broadcast address — neither is assignable to a host.)
Why this matters practically: when you set up an Azure VNet with address space 10.0.0.0/16 and carve out a subnet 10.0.1.0/24 for App Services and another 10.0.2.0/24 for a database, CIDR notation is how you're describing "this subnet gets these 254 addresses, that one gets a different 254" without them overlapping.
4. Ports
A port identifies which service on a given IP address a connection is meant for — the IP gets you to the right machine, the port gets you to the right application on it.
| Port | Protocol/Service |
|---|---|
| 22 | SSH |
| 53 | DNS |
| 80 | HTTP |
| 443 | HTTPS |
| 1433 | SQL Server / Azure SQL |
| 5432 | PostgreSQL |
| 3306 | MySQL |
| 6379 | Redis |
| 5672 | RabbitMQ (AMQP) |
Ports 0–1023 are "well-known" ports, conventionally reserved for standard services (the ones above). Ports above 1024 are free for applications to use as needed — including the temporary, randomly-assigned "ephemeral" ports your machine uses as the source port for outbound connections (you connect from some ephemeral port on your laptop to port 443 on a server).
curl -I https://api.roundtrips.app:443 # explicit port, though :443 is the default for https:// and can be omitted
5. TCP vs. UDP
Both are transport-layer protocols, but with opposite trade-offs:
| TCP | UDP | |
|---|---|---|
| Connection | Connection-oriented (handshake first) | Connectionless (just send) |
| Reliability | Guaranteed delivery, retransmits lost packets | No guarantee — lost packets stay lost |
| Ordering | Guaranteed in-order delivery | No ordering guarantee |
| Speed | Slower (overhead from guarantees) | Faster (no overhead) |
| Typical use | HTTP/HTTPS, database connections, SSH — anything where correctness matters more than raw speed | DNS queries, video/voice streaming, gaming — anything where a dropped packet is better than a delayed one |
The TCP three-way handshake — what happens before any TCP data flows at all:
This handshake happens for every new TCP connection — including every fresh HTTPS request that isn't reusing an existing connection — before a single byte of your actual request is sent. It's also why a firewall silently dropping SYN packets (rather than actively rejecting them) makes a connection hang rather than fail immediately — the client just keeps waiting for a SYN-ACK that will never come.
6. NAT (Network Address Translation)
NAT is what lets many devices on a private network share one public IP address. Your home router does this constantly: every device on your home wifi has a private 192.168.x.x address, but to the outside internet, all of their traffic appears to come from your one public IP.
Azure VNets work the same way by default — resources with only private IPs reach the internet outbound through NAT (Azure's default outbound access, or an explicit NAT Gateway resource for more control), without needing individually assigned public IPs.
7. Routing
A routing table is how a device decides which direction to send a packet based on its destination address. Every device — your laptop, a router, an Azure VM — has one.
# View your machine's routing table
netstat -rn # macOS
ip route # Linux
The default gateway is the "if nothing more specific matches, send it here" entry — typically your router (at home) or the VNet's default route (in Azure), which then forwards it further toward its destination.
8. How This Maps to Azure Networking
| Concept in this chapter | Azure equivalent |
|---|---|
| A private network / subnet | Virtual Network (VNet) and its subnets |
| Which traffic is allowed in/out | Network Security Group (NSG) rules |
| NAT for outbound internet access | Default outbound access, or an explicit NAT Gateway |
| Public IP for a service | Public IP resource, or the default public endpoint on App Service |
| Routing between subnets/VNets | Route tables, VNet peering |
A concrete example: Azure SQL restricted to only accept connections from your App Service's outbound IPs is a firewall rule operating at the IP-address level described in Section 2 — this is why an App Service's outbound IP changing (which can happen on scale operations) can suddenly break a database connection that was working fine the day before, with no code changes involved.
9. Practical Developer Workflows
Check what public IP your machine is currently using (useful when configuring a firewall allow-rule):
curl -4 ifconfig.me
Confirm a specific port is actually reachable (not just that the host resolves):
nc -zv api.roundtrips.app 443
Trace the network path to a host — useful when something is slow or unreachable and you need to know where along the route it's failing:
traceroute api.roundtrips.app # macOS/Linux
10. Troubleshooting Playbook
| Symptom | Likely layer/cause | What to check |
|---|---|---|
| Connection hangs, never times out cleanly | Firewall silently dropping SYN packets | Compare against a host you know is reachable; check NSG rules if it's an Azure resource |
| Connection actively refused, fails immediately | Nothing listening on that port, or an active reject rule | Confirm the service is actually running and bound to the expected port |
| Works from your laptop, fails from Azure App Service | Different outbound IP, different NSG/firewall context | Check the target's firewall for App Service's specific outbound IPs, not just your local IP |
| Intermittent connectivity, sometimes works | Outbound IP changed after a scale event, or NAT port exhaustion under load | Check App Service's current outbound IPs; consider a NAT Gateway for high-volume outbound scenarios |
| "No route to host" | Routing table has no path to the destination | ip route / netstat -rn; confirm VNet peering or gateway configuration if it's a private Azure resource |
| Works over HTTP, fails over HTTPS only | Almost always a TLS/certificate issue, not a TCP/IP one | See the SSL/TLS Explained chapter — the TCP connection itself is likely fine |
| Can reach an IP directly but not by hostname | DNS issue, not a TCP/IP issue | See the DNS Deep Dive chapter |
11. Quick Reference
| Category | Item | Detail |
|---|---|---|
| Private ranges | 10.0.0.0/8 | Large private networks, common in Azure VNets |
| Private ranges | 192.168.0.0/16 | Home/office networks |
| Loopback | 127.0.0.1 | Always means "this machine" |
| CIDR | /24 | 256 addresses, 254 usable — a typical subnet |
| CIDR | /16 | 65,536 addresses — a typical whole VNet |
| Ports | 443 | HTTPS |
| Ports | 1433 | Azure SQL / SQL Server |
| Protocol | TCP | Reliable, ordered — HTTP(S), databases, SSH |
| Protocol | UDP | Fast, no guarantees — DNS, streaming |
| Handshake | SYN → SYN-ACK → ACK | Required before any TCP data flows |
| Command | nc -zv host port | Test whether a specific port is reachable |
| Command | traceroute host | Show the network path to a destination |
| Command | curl -4 ifconfig.me | Show your current public IP |
Part of the Traxs Engineering Handbook — Volume 2: Networking Foundations. Companion chapters in this volume: DNS Deep Dive, SSL/TLS Explained, VPN Fundamentals, Network Troubleshooting, Load Balancers & Reverse Proxies.