Networking Fundamentals Every Developer Should Understand

Why Developers Need Networking Knowledge

You do not need to be a network engineer, but you do need to understand the basics. When your API is slow, is it the code or the network? When a connection times out, is it DNS, a firewall, or the server? When you are designing a system that spans multiple cloud regions, how does latency affect your architecture?

Networking knowledge turns "it is broken and I have no idea why" into "the connection is timing out at the TCP handshake, probably a firewall rule."

---

The Layered Model

Network communication works in layers. Each layer handles a specific concern:

Application Layer (HTTP, HTTPS, WebSocket, FTP) — what your code interacts with. "Send this JSON to that URL."

Transport Layer (TCP, UDP) — ensures data arrives correctly (TCP) or quickly (UDP). TCP guarantees delivery and ordering. UDP is faster but does not guarantee either.

Network Layer (IP) — addresses and routes packets across the internet. Every device has an IP address (like 192.168.1.100 for IPv4 or a longer hex string for IPv6).

Link Layer (Ethernet, WiFi) — the physical connection. Cables, radio signals, switches.

You mostly work at the application layer, but understanding the layers below helps immensely when debugging.

---

DNS: The Internet's Phone Book

When you type api.bloomberg.com, your computer needs to convert that name to an IP address. DNS (Domain Name System) handles this translation.

Your code calls api.bloomberg.com
    → Browser/OS checks local cache
    → Asks your ISP's DNS resolver
    → Resolver queries root servers → .com servers → bloomberg.com servers
    → Returns: 199.47.218.XX
    → Your code connects to that IP

This lookup typically takes 20-100ms the first time and is cached afterward. DNS issues — misconfigured records, propagation delays, cache poisoning — are a common source of hard-to-diagnose production problems.

Useful DNS Commands

# Look up a domain's IP address
nslookup api.example.com
dig api.example.com

# Check which DNS server is being used
dig api.example.com +trace

# See all DNS records for a domain
dig example.com ANY

---

TCP: Reliable Communication

Most financial applications use TCP because data correctness is critical. A missing byte in a trade message is not acceptable.

TCP establishes a connection with a three-way handshake:

Client → Server: SYN (I want to connect)
Server → Client: SYN-ACK (OK, I acknowledge)
Client → Server: ACK (Great, connection established)

This takes one network round trip. For a connection between London and New York, that is about 70ms just for the handshake — before any data is sent. This is why connection pooling (reusing connections) matters for performance.

TCP also handles:

• Ordering — packets that arrive out of order are reassembled correctly
• Retransmission — lost packets are automatically resent
• Flow control — the sender slows down if the receiver cannot keep up
• Congestion control — the sender slows down if the network is congested

When TCP Is Too Slow

For ultra-low-latency trading, TCP's overhead (handshakes, acknowledgements, retransmissions) can be too much. Some high-frequency trading systems use UDP multicast for market data — accepting the risk of occasional dropped packets in exchange for lower latency. See our network latency guide for more on this.

---

HTTP and HTTPS

HTTP is the protocol that powers the web and most REST APIs. It is a request-response protocol built on top of TCP.

GET /api/v1/prices?symbol=AAPL HTTP/1.1
Host: api.example.com
Authorization: Bearer abc123
Accept: application/json

---

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 142

{"symbol": "AAPL", "price": 150.25, "timestamp": "2024-01-15T14:30:00Z"}

HTTPS adds encryption (TLS/SSL) on top of HTTP. All modern APIs use HTTPS — the data is encrypted in transit so intermediaries cannot read or modify it.

HTTP/2 and HTTP/3

HTTP/2 adds multiplexing (multiple requests over a single connection) and header compression. HTTP/3 replaces TCP with QUIC (a UDP-based protocol) for even lower latency. Most modern APIs benefit from HTTP/2 automatically.

---

Firewalls and Security Groups

Firewalls control which network traffic is allowed. In cloud environments, these are typically called security groups (AWS) or network security groups (Azure).

# Typical security group for a web API
Inbound:
  Allow TCP port 443 (HTTPS) from 0.0.0.0/0    → Public access
  Allow TCP port 22 (SSH) from 10.0.0.0/8       → Internal access only

Outbound:
  Allow all traffic                               → Server can reach external services

# Typical security group for a database
Inbound:
  Allow TCP port 5432 (PostgreSQL) from sg-api    → Only the API can connect
  Deny all other inbound traffic

Outbound:
  Deny all                                        → Database should not initiate connections

The principle of least privilege applies: only allow the specific traffic that is needed. A database should never be accessible from the internet.

---

Ports: What They Are and Why They Matter

An IP address identifies a machine. A port identifies a specific service on that machine. Think of it as an apartment number in a building.

Common ports:

• 80 — HTTP
• 443 — HTTPS
• 22 — SSH
• 5432 — PostgreSQL
• 3306 — MySQL
• 6379 — Redis
• 8080/8000 — Common for development servers

When you see localhost:8000, that means "this machine, port 8000." When your API documentation says "connect to api.example.com:443," it means HTTPS on the standard port.

---

Practical Debugging

When something network-related is not working:

# Can you reach the host at all?
ping api.example.com

# Is the specific port open?
telnet api.example.com 443
nc -zv api.example.com 443

# Trace the network path
traceroute api.example.com

# See what connections your machine has open
netstat -an | grep ESTABLISHED

# Make an HTTP request and see headers
curl -v https://api.example.com/health

These commands are your first tools when diagnosing connection problems. For a deeper dive into performance, see network speeds and latency and for protecting your network, security and authentication.