Network

TCP gets heavier the more you talk about it, while UDP is often reduced to “connectionless, unreliable”. That is not wrong, but it is too thin. What really matters in engineering is not which features UDP lacks, but why it deliberately does not do them, and what gets pushed back onto the application or a higher-layer protocol when it does not.

When a page loads slowly, an API times out, or packet capture shows retransmissions and duplicate acknowledgements, the problem is often not HTTP itself. It is the transport connection beneath it. TCP is usually summarized as a “reliable transport protocol,” but the real engineering judgment comes from how it turns an unreliable network path into a usable byte stream through connection state, acknowledgement, retransmission, windows, and in-order delivery.

TCP’s cost is here too. It solved the reliable transport problem for the open Internet, but it also carried later Web performance constraints, weak-network behavior, and multiplexing limits down below the application layer. The reasons HTTP/2 gets stuck behind packet loss and QUIC wants to redesign transport again are both in TCP’s behavior model.

You change an A record in production, but browsers keep reaching the old address. The authoritative server already returns the new value, yet users in different regions still see different answers. Packet captures clearly ask for www.example.com, but the first few hops do not return an IP directly.

The hard part of DNS is not record types. It is the model behind them: DNS is never a real-time global lookup table. It is a resolution system held together by hierarchical delegation, recursive resolution, and TTL-based caching.

When a new device plugs into the network, it usually does not know which IP address to use, who the gateway and DNS servers are, or whether the network is willing to hand out an address for a long time. The network, on the other hand, wants it online quickly, ideally without manual configuration, while still keeping control over address assignment, reclamation, and policy changes.

DHCP exists to handle exactly that. It looks like “automatic IP assignment,” but the real job is initial control-plane allocation: let the terminal join with almost no preconfiguration, while the network keeps the power to push parameters, reclaim addresses, and adjust policy later.