Protocols and the OSI Model

Understanding network communication is foundational to building distributed systems. You don’t need to memorize every protocol — but you do need a working mental model of the layers and what protocols live at each one. That mental model is what lets you debug strange production problems and make informed architectural calls.

The OSI Model

The OSI (Open Systems Interconnection) model is the canonical way to teach networking. Seven layers, each with specific responsibilities, communicating only with adjacent layers.

The Real Model — TCP/IP

In practice, the TCP/IP model is what you’ll actually encounter. It collapses some OSI layers and matches modern Internet reality:

Application development mostly happens at the Application and Transport layers. The lower layers exist; you’ll touch them only when something is going badly wrong.

TCP vs. UDP

The choice of transport-layer protocol significantly affects system design and performance.

TCP wins for:

• Web traffic (HTTP/HTTPS).
• File transfer (FTP, SFTP).
• Email (SMTP, IMAP).
• Database connections.
• Anything where guaranteed delivery matters.

UDP wins for:

• Video streaming (some packet loss is acceptable).
• Online gaming (latency-sensitive).
• DNS queries (small payloads, simple retry logic).
• Live broadcasts.
• IoT sensor data (latest reading is what matters).

HTTP: The Application-Layer Workhorse

HTTP has gone through several major revisions, each addressing specific performance and compatibility problems. Understanding the differences matters because they affect how your services behave under load.

For internal service-to-service traffic on stable networks, HTTP/2 is the modern default. For client-facing traffic over the public Internet — especially mobile — HTTP/3 has the edge.

TLS: Encryption at the Transport Boundary

TLS (Transport Layer Security) encrypts data in transit. Modern TLS is TLS 1.2 or TLS 1.3 — older versions (SSL 2/3, TLS 1.0/1.1) are deprecated and insecure.

DNS: The Hidden Performance Layer

DNS resolves domain names to IPs. Often invisible — until it’s slow, broken, or being abused. Things to know:

• TTLs — DNS records are cached. Long TTLs mean clients use stale records longer; short TTLs mean more queries. Production load balancing often relies on TTL behavior.
• DNS-over-HTTPS / DNS-over-TLS — encrypted DNS resolution. Increasingly default on browsers and OSes.
• Anycast — same IP advertised from multiple locations; clients reach the closest one. How most large-scale CDNs and DNS providers work.

For SaaS apps, your platform’s choice of DNS provider (Route 53, Cloudflare, NS1) materially affects latency and reliability.

A Practical Mental Model

When you see a request flow like this:

Browser ──[TLS 1.3]──► CDN ──[HTTP/2]──► API Gateway ──[gRPC over HTTP/2]──► Service

The layers in play:

• Layer 7 (App): TLS, HTTP/2, gRPC.
• Layer 4 (Transport): TCP at every hop.
• Layer 3 (Network): IP routing across the public Internet, then within VPC.
• Layer 2/1: Whatever the wires and wireless are doing — usually invisible.

Knowing which layer is responsible for which property (encryption, ordering, routing) is what makes diagnosing weird latency or connectivity issues tractable.

Recap

• OSI is the textbook model. TCP/IP is what you actually use; collapses OSI’s top three into “Application.”
• TCP gives you reliability and ordering at the cost of latency. UDP gives you speed at the cost of guarantees.
• HTTP versions matter — HTTP/2 is the default for service-to-service, HTTP/3 wins on lossy networks.
• TLS 1.3 (with ACME / Let’s Encrypt) makes secure transport trivial. mTLS is how internal services authenticate each other.
• DNS is invisible until it isn’t. TTLs and anycast are the levers worth understanding.