TCP/IP & Network Protocols: The Stack, TCP vs UDP & Ports

Q: What's the difference between TCP and UDP?

TCP is connection-based and reliable: it performs a handshake to establish a connection, guarantees that all data arrives complete and in the correct order (retransmitting anything lost), and is used by the web, APIs, email, and file transfer — anywhere correctness matters. UDP is connectionless and best-effort: it sends packets with no handshake, no delivery guarantee, and no ordering, making it faster and lower-overhead — ideal for real-time media, gaming, and small queries like DNS where speed matters more than perfect delivery and occasional loss is acceptable. The tradeoff is reliability

Q: What's the difference between an IP address and a port?

An IP address identifies a machine on the network (e.g. 93.184.216.34), and routing uses it to deliver packets to the right host across the internet. A port identifies which application or service on that machine should handle the data (e.g. 443 for HTTPS, 22 for SSH, 53 for DNS). Together they pinpoint a specific service: 93.184.216.34:443 means "the HTTPS service on that host." This distinction matters constantly in practice — connection problems can be a wrong/unreachable IP (host issue) or nothing listening on the expected port (service issue), and firewalls control access by port.

Q: Do I need to understand TCP/IP to build web apps?

Not to write basic apps — frameworks abstract it away, and you can build for a long time thinking only in HTTP requests. But understanding TCP/IP becomes valuable the moment you debug real problems: diagnosing latency and connection issues, configuring firewalls and ports, understanding why some real-time features use UDP, reasoning about load balancing and TLS, or grasping why HTTP/3 exists. It's foundational knowledge that turns mysterious networking errors into understandable ones. You don't need to implement the stack, but knowing how it works pays off whenever the abstractions leak.

TCP/IP & Network Protocols

TCP/IP is the protocol stack that makes the internet work — the agreed-upon rules by which billions of devices address each other and exchange data reliably across an unreliable global network. Every higher-level protocol you use (HTTP, DNS, email, WebSockets) runs on top of it. You don't need to implement TCP/IP to build applications, but understanding its layers — especially the IP addressing that routes data and the TCP vs UDP choice for transporting it — is what lets you reason about latency, connection issues, ports, and why some protocols behave the way they do.

The organizing idea is layering: networking is split into layers, each handling one concern and building on the one below. An application sends data through the transport layer (TCP or UDP), which hands it to the internet layer (IP) for addressing and routing, down to the physical wire — and the reverse on the way up. This separation is why you can write a web app without thinking about packets, while the layers underneath quietly handle getting bytes from one machine to another.

TL;DR

TCP/IP is the layered protocol stack of the internet — everything else runs on it.
IP addresses and routes packets between machines; ports identify the app on a machine.
TCP = reliable, ordered, connection-based; UDP = fast, connectionless, best-effort.
Higher protocols (HTTP, DNS) sit on top of this foundation.

Quick Example

An address + port identifies which app on which machine:

The Layered Model

Networking is organized into layers, each solving one problem:

Data flows down the stack on the sender (each layer wraps the data) and up on the receiver (each layer unwraps it). This is the TCP/IP model; the OSI model is a related 7-layer teaching framework.

IP & Ports

IP address — identifies a machine on the network. IPv4 (93.184.216.34) is running out of addresses; IPv6 (2606:2800:220:1:...) provides vastly more. IP handles routing — getting a packet across networks to the right host — but is itself unreliable (packets can be lost, duplicated, or arrive out of order).
Port — identifies which application/service on the host (HTTP 80, HTTPS 443, DNS 53, SSH 22). An IP + port together pinpoint a specific service: 93.184.216.34:443.

TCP vs UDP

The two transport protocols make opposite tradeoffs:

TCP establishes a connection (the three-way handshake), guarantees that data arrives complete and in order (retransmitting losses), and is what HTTP (1.1/2) and most applications use. The reliability costs latency.
UDP just fires packets with no handshake or guarantees — faster and lower-overhead, ideal when speed matters more than perfect delivery (live video, voice, gaming) or for small one-shot queries (DNS). HTTP/3 uses QUIC, built on UDP.

Best Practices

Default to TCP for application data that must arrive complete and ordered (almost everything).
Use UDP only when low latency beats reliability (real-time media, gaming) or for tiny stateless queries.
Understand ports — firewalls, services, and conflicts all hinge on them.
Plan for IPv6 — it's increasingly required.
Don't reinvent reliability over UDP unless you have a specific reason (QUIC already did it well).

Common Mistakes

Choosing UDP and then needing reliability

Confusing IP (host) with port (service)

FAQ

What's the difference between TCP and UDP?

TCP is connection-based and reliable: it performs a handshake to establish a connection, guarantees that all data arrives complete and in the correct order (retransmitting anything lost), and is used by the web, APIs, email, and file transfer — anywhere correctness matters. UDP is connectionless and best-effort: it sends packets with no handshake, no delivery guarantee, and no ordering, making it faster and lower-overhead — ideal for real-time media, gaming, and small queries like DNS where speed matters more than perfect delivery and occasional loss is acceptable. The tradeoff is reliability (TCP) versus low latency (UDP).

What are the network layers and why do they matter?

Networking is split into layers, each handling one concern: the application layer is what your app speaks (HTTP, DNS), the transport layer delivers data between hosts (TCP/UDP), the internet layer addresses and routes packets (IP), and the link layer handles physical transmission (Ethernet, Wi-Fi). Layering matters because it separates concerns — you can write a web app at the application layer without thinking about packets or routing, because the layers below handle those reliably. It also lets each layer evolve independently (e.g. HTTP/3 swapping TCP for QUIC) without rewriting everything above it.

What's the difference between an IP address and a port?

An IP address identifies a machine on the network (e.g. 93.184.216.34), and routing uses it to deliver packets to the right host across the internet. A port identifies which application or service on that machine should handle the data (e.g. 443 for HTTPS, 22 for SSH, 53 for DNS). Together they pinpoint a specific service: 93.184.216.34:443 means "the HTTPS service on that host." This distinction matters constantly in practice — connection problems can be a wrong/unreachable IP (host issue) or nothing listening on the expected port (service issue), and firewalls control access by port.

Do I need to understand TCP/IP to build web apps?

Not to write basic apps — frameworks abstract it away, and you can build for a long time thinking only in HTTP requests. But understanding TCP/IP becomes valuable the moment you debug real problems: diagnosing latency and connection issues, configuring firewalls and ports, understanding why some real-time features use UDP, reasoning about load balancing and TLS, or grasping why HTTP/3 exists. It's foundational knowledge that turns mysterious networking errors into understandable ones. You don't need to implement the stack, but knowing how it works pays off whenever the abstractions leak.