Networking · 12 min read · ~27 min study · beginner

Networking Fundamentals

DNS, TCP/IP, HTTP, firewalls — how the internet works and why every finance dev should understand it.

12 min read ~27 min study beginner systems #networking#fundamentals 20 learning outcomes

Networking Fundamentals Every Developer Should Understand

How the internet works under the hood — DNS, TCP/IP, HTTP, firewalls, and the networking concepts that matter for building financial applications.

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 New York 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.

Want to go deeper on Networking Fundamentals Every Developer Should Understand?

This article covers the essentials, but there's a lot more to learn. Inside , you'll find hands-on coding exercises, interactive quizzes, and structured lessons that take you from fundamentals to production-ready skills — across 50+ courses in technology, finance, and mathematics.

Free to get started · No credit card required

Keep Reading

[Networking

Network Speeds and Latency in Financial Systems

Why latency matters in trading, how to measure it, where the bottlenecks are, and what firms do to minimize it — from co-location to kernel bypass.](/quant-knowledge/networking/network-speeds-and-latency-in-financial-systems)[Software Engineering

APIs and REST for Financial Data

How APIs work, RESTful design principles, and practical patterns for building and consuming financial data APIs.](/quant-knowledge/software-engineering/apis-and-rest-for-financial-data)[Networking

Security and Authentication for Fintech Applications

How to secure financial applications — authentication, authorization, encryption, common vulnerabilities, and the security mindset every developer needs.](/quant-knowledge/networking/security-and-authentication-for-fintech)[Cloud & Infrastructure

Cloud Computing for Finance: Getting Started

What cloud computing means for financial services — the major providers, core services, cost models, and why finance firms are migrating to the cloud.](/quant-knowledge/cloud/cloud-computing-for-finance)

What You Will Learn

Explain why developers need networking knowledge.
Build the layered model.
Calibrate dns: the internet's phone book.
Compute TCP: reliable communication.
Design HTTP and HTTPS.
Implement firewalls and __pn0__urity groups.

Prerequisites

Latency intuition — see Latency intuition.
Comfort reading code and basic statistical notation.
Curiosity about how the topic shows up in a US trading firm.

Mental Model

In US equities, the speed of light dictates the playing field. Every microsecond of switch fabric, fiber length, and protocol overhead is either an opportunity or a tax. Networking is where physics meets P&L. For Networking Fundamentals, frame the topic as the piece that dNS, TCP/IP, HTTP, firewalls — how the internet works and why every finance dev should understand it — and ask what would break if you removed it from the workflow.

Why This Matters in US Markets

The colocation market in US equities and futures is its own ecosystem. NY4, NY5, CH2, and CME Aurora all sell rack space, cross-connects, and microwave/laser links. Wireless carriers like McKay Brothers and Anova run point-to-point links between Aurora and Carteret because fiber is too slow.

In US markets, Networking Fundamentals tends to surface during onboarding, code review, and the first incident a junior quant gets pulled into. Questions on this material recur in interviews at Citadel, Two Sigma, Jane Street, HRT, Jump, DRW, IMC, Optiver, and the major bulge-bracket banks.

Common Mistakes

Tuning mean latency while ignoring the 99.9th percentile that actually drives risk.
Letting NIC interrupt coalescing run with default settings on a low-latency host.
Forgetting that microwave links degrade in heavy precipitation.
Treating Networking Fundamentals as a one-off topic rather than the foundation it becomes once you ship code.
Skipping the US-market context — copying European or Asian conventions and getting bitten by US tick sizes, settlement, or regulator expectations.
Optimizing for elegance instead of auditability; trading regulators care about reproducibility, not cleverness.
Confusing model output with reality — the tape is the source of truth, the model is a hypothesis.

Practice Questions

Why does a US futures shop pay six figures a year for a microwave link between Aurora and Carteret?
When is TCP unsuitable for market data and why?
What does jitter mean in trading, and why is it sometimes more important than mean latency?
Describe a multicast feed handler's failure mode when a switch drops a sequence number.
Why does NIC interrupt coalescing matter for a co-located trading process?

Answers and Explanations

Because microwave traverses the great circle path through the air, which is ~10 ms faster than fiber that follows roads and rights-of-way; that 10 ms determines who quotes the spread first.
When data volume and latency requirements outpace TCP's congestion control and retransmit semantics; UDP multicast is preferred because the application can drop, replay, or interpolate without head-of-line blocking.
Jitter is the variance of latency; tail latency drives risk because a single 99th-percentile spike crosses an exchange deadline and produces a stale quote. Many strategies optimize tail more than mean.
The handler detects the gap, requests a retransmission from a TCP recovery channel, and either re-orders or marks the stream stale; the strategy must decide whether to keep quoting or to step out.
Coalescing batches interrupts to save CPU but adds latency and jitter; HFT firms turn coalescing off and pin the NIC interrupt to a dedicated core, trading CPU for predictable response times.

Glossary

Latency — round-trip time; measured in microseconds for cross-data-center, nanoseconds for in-rack.
Throughput — bandwidth, in bits per second.
Jitter — variance in latency; often more harmful than absolute latency for trading.
Microwave / mmWave — wireless point-to-point links faster than fiber over the same path.
Cross-connect — a physical patch cable inside a colo facility.
Multicast — one-to-many delivery used by SIP, OPRA, CME ESS.
TCP — connection-oriented, reliable, in-order; used for orders.
UDP — connectionless, no retransmit; used for market data feeds.

Further Study Path

Network Speeds and Latency in Trading — Why latency matters, how to measure it, where bottlenecks hide — from co-location to kernel bypass.
Security and Authentication for Fintech — Auth, encryption, common vulnerabilities — the security mindset every financial app developer needs.
Python for Quant Finance: Fundamentals — Variables, functions, data structures, classes, and error handling — the core Python every quant role expects.
Advanced Python for Financial Applications — Decorators, generators, and context managers — the patterns that separate beginner Python from production quant code.
NumPy for Quantitative Finance — Why array operations power everything from portfolio risk to Monte Carlo — and why they outpace plain Python.

Key Learning Outcomes

Explain why developers need networking knowledge.
Apply the layered model.
Recognize dns: the internet's phone book.
Describe TCP: reliable communication.
Walk through HTTP and HTTPS.
Identify firewalls and __pn0__urity groups.
Articulate ports: what they are and why they matter.
Trace networking as it applies to networking fundamentals.
Map fundamentals as it applies to networking fundamentals.
Pinpoint how networking fundamentals surfaces at Citadel, Two Sigma, Jane Street, or HRT.
Explain the US regulatory framing — SEC, CFTC, FINRA — relevant to networking fundamentals.
Apply a single-paragraph elevator pitch for networking fundamentals suitable for an interviewer.
Recognize one common production failure mode of the techniques in networking fundamentals.
Describe when networking fundamentals is the wrong tool and what to use instead.
Walk through how networking fundamentals interacts with the order management and risk gates in a US trading stack.
Identify a back-of-the-envelope sanity check that proves your implementation of networking fundamentals is roughly right.
Articulate which US firms publicly hire against the skills covered in networking fundamentals.
Trace a follow-up topic from this knowledge base that deepens networking fundamentals.
Map how networking fundamentals would appear on a phone screen or onsite interview at a US quant shop.
Pinpoint the day-one mistake a junior would make on networking fundamentals and the senior's fix.