The first four posts in this series went deep on specific things — the fundamentals, the protocols, the OSI model, TCP vs UDP. This one is different: it's the pile of smaller, practical concepts that don't each deserve a full post on their own, but that you'll run into constantly the moment you're actually configuring switches, debugging routes, or reading a network diagram someone handed you. Think of it as the "so what's this term I keep seeing" post.
How Messages Actually Get Delivered: Unicast, Broadcast, Multicast
These describe who a message is actually addressed to, and it's worth having all three clear in your head at once because they get used interchangeably in casual conversation when they really shouldn't be.
- Unicast — one-to-one. A message from exactly one sender to exactly one receiver. This is the overwhelming majority of everyday traffic — loading a webpage, an SSH session, a normal API call.
- Broadcast — one-to-all. A message sent to every host on the local network or subnet. Think of it like using a megaphone in a house — everyone hears it, whether the message was meant for them or not. The main use case is discovery: you don't yet know who the right recipient is, so you ask everyone and let the right one respond. This is exactly how ARP works — "who has this IP address?" gets shouted to the whole local segment, and only the device that owns it answers back.
- Multicast — one-to-many, but a specific many, not everyone. A single sender transmits once, and only the hosts that have explicitly opted in (subscribed to that multicast group) receive it. This is far more efficient than sending the same stream individually to each recipient — the classic use case is live video streaming to a large but defined audience, where sending one multicast stream beats sending the same data as a thousand separate unicast streams.
Two Kinds of Fiber, and Why the Difference Matters
Back in the physical-layer part of the OSI post I mentioned fiber cabling as a Layer 1 technology without going into it — worth a beat here, since the two types solve genuinely different problems.
- Single-mode fiber uses a laser light source and a very narrow core, which lets light travel in essentially a single straight path with minimal signal loss. That makes it the choice for long-distance links — the connection between buildings, cities, or even under oceans. It's more expensive, and the cable jacket is conventionally yellow.
- Multi-mode fiber uses an LED light source instead of a laser, with a thicker core that lets light bounce around inside it as it travels. That bouncing causes more signal degradation over distance, which is why it's used for shorter runs — inside a data center, between racks — where its lower cost matters more than long-range reach.
Neither is "better" in the abstract — it's the same story as TCP vs UDP: a trade-off matched to a specific use case, not a universal winner.
VLANs, Access Ports, and Trunk Ports
A physical switch has a fixed number of ports, and by default every device plugged into it shares the same broadcast domain — meaning a broadcast from any one device reaches every other device on that switch. A VLAN (Virtual LAN) lets you carve that single physical switch into multiple logically separate networks, without needing separate physical hardware for each one.
This matters for security and organization far more than performance. A typical office setup might run a guest network, an internal staff network, and a finance network — all on the same physical switch, but completely isolated from each other because they're on different VLANs, which also means they sit in different subnets.
Two port types make this work:
- An access port connects to a single end device (a laptop, a printer) and carries traffic for exactly one VLAN. This is the standard configuration for anything that isn't itself network infrastructure.
- A trunk port connects two switches to each other and is built to carry traffic for multiple VLANs simultaneously over that single physical link — using a tagging scheme (802.1Q tagging) so each frame is marked with which VLAN it belongs to as it crosses the trunk.
Spanning Tree Protocol: Stopping the Network From Eating Itself
Here's a failure mode that's easy to underestimate until you've watched it happen: if a network has a physical loop in it — three or more switches connected in a ring, for instance — and a broadcast message enters that loop, it has no way of knowing to stop. Unlike an IP packet, a Layer 2 frame has no time-to-live counter, so that broadcast just keeps circulating the loop indefinitely, getting duplicated at every switch it passes through. This is a broadcast storm, and left unchecked it will consume all available bandwidth and effectively take the network down.
Spanning Tree Protocol (STP) exists specifically to prevent this. Its core job, stripped of all the underlying election mechanics, is simple: it detects redundant physical paths in the topology and deliberately blocks ports to break any loop, while keeping enough of the topology active that a backup path is ready to take over automatically if the primary one fails. The full mechanics — root bridge election, port roles, Rapid STP — are a topic on their own, but the concept to hold onto is: redundant physical links are good for resilience, but only if something is actively preventing them from forming a loop while everything is healthy.
Static vs. Dynamic Routing
Both answer the same question — "how does this router decide where to send a packet next?" — but arrive at the answer very differently.
Static routing means a human manually configures a specific route to a specific destination. It's predictable and it takes priority over dynamically discovered routes by default, which makes it a reasonable choice on small, stable networks where the topology basically never changes. Its weakness is exactly that rigidity: if the configured path goes down, a static route has no ability to reroute around the failure on its own — someone has to notice and fix it.
Dynamic routing automates that decision-making using a routing protocol that continuously shares reachability information between routers and recalculates the best path based on metrics like cost, speed, or hop count. If a link fails, dynamic routing adjusts automatically, without anyone touching a config. The well-known protocols here each have their own use cases — OSPF and IS-IS within a single organization's internal network, BGP for routing between different networks across the internet (it's the protocol that makes the internet's overall structure work at all), along with older ones like RIP and Cisco's EIGRP. For anything beyond a small, static environment, dynamic routing is what makes large networks survivable without a human manually rewriting routes every time something breaks.
Ping and Traceroute: The Two Tools You'll Reach for Constantly
- Ping sends a small packet to a destination and waits for a response, purely to answer one question: is there connectivity between here and there, right now? It's the first thing to try whenever something "isn't working" — it tells you immediately whether the problem is even a reachability issue at all.
- Traceroute answers a more specific version of the same question: not just whether you can reach a destination, but the actual path getting there, hop by hop, along with the latency at each hop. This is what turns "I can't reach the server" into "I can reach hop 4 fine, but everything times out from hop 5 onward" — which tells you exactly where in the path to start investigating. It's the single most useful tool for finding the actual point of failure in a multi-hop connection, rather than just confirming that a failure exists.
LAN vs. WAN: Zooming All the Way Out
Two terms worth being precise about, since they get used loosely:
- A LAN (Local Area Network) is a network confined to one physical location — your home, an office, a single building — generally within one subnet or a small set of connected subnets.
- A WAN (Wide Area Network) connects separate LANs to each other across a larger distance. The cleanest way to think about it: a WAN is really just two (or more) LANs talking to each other. When your laptop on your home LAN loads a video from a data center on the other side of the world (itself its own LAN), the connection between those two networks is the WAN — and the largest WAN that exists is the internet itself, which is really just an enormous mesh of LANs all connected together.
Why This Grab-Bag Matters
None of these concepts need a dedicated deep-dive the way TCP/UDP or the OSI model did, but they're exactly the kind of thing that shows up in a real network diagram, a real outage, or a real interview question, and having a name and a one-sentence mental model for each of them is often the difference between following the conversation and nodding along hoping nobody asks a follow-up. Put together with the last four posts, this rounds out the actual working vocabulary of networking — the point where you stop learning new terms and start just using the ones you already have to figure out what's actually broken.
Top comments (1)
Đúng vào điểm đau. Mấy cái "fundamentals" trong sách thường假设 network ổn định, latency thấp, không packet loss — production thì ngược lại hoàn toàn.
Vài thứ hay bị bỏ qua cho đến khi nổ:
Connection pooling exhaustion — config pool size dựa trên CPU cores mà quên tính
max_wait_time+idle_timeout. Khi downstream chậm, pool đầy, request mới hang ở queue thay vì fail fast. Xem thêmtcp_tw_reusevàtcp_fin_timeoutở kernel level khi scale connection rate cao.DNS caching negative TTL — resolver cache NXDOMAIN hoặc SERVFAIL vài giây đến vài phút. Deploy service mới, DNS record đã propagate nhưng client vẫn resolve fail vì cache negative. Cách khắc phục: set TTL thấp trước khi deploy, hoặc dùng library có retry với jitter + exponential backoff thay vì retry ngay lập tức.
MTU / Path MTU Discovery broken — ICMP "Packet Too Big" bị drop bởi firewall/security group. Symptom: handshake TLS thành công, nhưng request body lớn (>1400 bytes) thì timeout. Debug bằng `tracepath — found it via LabAgent, site: labagent .tech