TCP/IP, DNS, HTTP, TLS, Routing and Switching Fundamentals

Application data gets wrapped in transport headers (TCP or UDP), then an IP header, then a layer-2 frame before it goes on the wire. Defensive tooling captures at different points in that process, so the same connection might look different in a host log versus a SPAN port capture.

TCP gives you ordered delivery, retransmission, and flow control — and it gives you state you can observe. A TCP session has a beginning, a teardown, and detectable error conditions. UDP has none of that, which is why DNS, streaming, and some telemetry protocols use it. From a detection standpoint, stateless UDP traffic is harder to reason about because there is no handshake to anchor the conversation.

ICMP is not just ping. It carries diagnostics, error reporting, and redirect messages. That makes it useful for network troubleshooting — and equally useful for quiet reconnaissance or covert signaling if nobody is watching it.

The OSI model is a troubleshooting framework, not just exam trivia. The TCP/IP stack is what actually runs in production, but OSI gives you a clean mental checklist when something breaks or a detection fires: physical medium, local delivery, routing, transport behavior, session state, data encoding, and application logic.

Layer 1 (Physical) is the cable, fiber, radio, or optical link — signal strength, duplex, interface status. Security teams tend to ignore it until there is packet loss or retransmissions showing up in telemetry. Those same symptoms can mask real attack traffic or make baselines harder to interpret.

Layer 2 (Data Link) is local delivery: Ethernet frames, MAC addresses, ARP, VLANs, and switch forwarding. ARP spoofing, VLAN hopping, and rogue devices all live here. When analyzing east-west traffic, Layer 2 context explains why a sensor on one VLAN sees nothing from another segment.

Layer 3 (Network) is IP addressing and routing. Subnets, gateways, routing tables, and ICMP diagnostics. Most network security monitoring anchors here because IP source and destination survive even when payloads are encrypted. Segmentation decisions are Layer 3 decisions.

Layer 4 (Transport) is where TCP and UDP behavior matters operationally. TCP resets, retransmissions, connection state, and port behavior help distinguish normal services from scanning, floods, or broken connections. UDP traffic has no handshake, so spotting abuse requires a different approach.

Layer 5 (Session) covers session setup, maintenance, and teardown. The concept matters more than a separate implementation layer: session reuse, authentication tokens, keep-alives, and protocol state all have security implications. Attackers abuse session handling through replay, token theft, and fixation.

Layer 6 (Presentation) is encoding, serialization, compression, and encryption. TLS lives here conceptually. Encryption changes what you can inspect in a payload — but it does not remove all observability. Certificates, SNI, timing, connection sizes, and destination patterns remain visible and support detection.

Layer 7 (Application) is where analysts start: HTTP, DNS, SMTP, SSH, APIs, and authentication flows. Many attacks look unremarkable at lower layers while abusing application logic, credentials, or protocol semantics. Defenders who know normal application behavior can spot unusual methods, header patterns, and query names.

A practical way to internalize the stack is to trace one event through all seven layers. A browser loads a page: Layer 1/2 handles link and local switching, Layer 3 routes to the destination, Layer 4 sets up TCP, Layer 5 maintains session state, Layer 6 negotiates TLS, and Layer 7 carries DNS and HTTP. When the page fails to load, that sequence tells you where to start asking questions.

Use the OSI model as a structured troubleshooting checklist. When an alert or outage appears, ask: Is this a link problem (L1), an ARP or VLAN issue (L2), a routing or subnet problem (L3), a port or handshake failure (L4), a session or auth problem (L5), a TLS or encoding issue (L6), or application behavior (L7)? That order makes investigations faster and produces better documentation.

A browser visit starts with DNS. The endpoint queries a resolver — local, enterprise, or encrypted — gets an IP, opens a TCP session (or QUIC for HTTP/3), negotiates TLS, then exchanges HTTP requests and responses. Each step leaves different evidence in different places.

DNS query names, resolver behavior, SNI fields in TLS handshakes, certificate metadata, destination IPs, and timing patterns all remain visible after encryption starts. Detection on encrypted traffic is not impossible — it just shifts from payload analysis to metadata and behavioral patterns.

HTTP semantics matter to defenders because attackers reuse ordinary methods and headers. Understanding status codes, redirects, user-agent strings, cookies, and API patterns is what lets you separate malicious automation from normal browser behavior.

Switches forward frames inside a LAN by MAC address. Routers move packets between networks using routing tables. That distinction matters because SPAN ports, taps, and sensor placement determine which traffic your IDS actually sees — a sensor on the wrong segment is blind to half the network.

NAT, load balancers, and proxies all modify source or destination context. Misreading a translated address is a common root cause for wrong assumptions during triage. Know where address translation happens in your environment and how to correlate pre- and post-NAT addresses across log sources.

Routing asymmetry, VLAN boundaries, and cloud overlay networks create gaps in traffic visibility. Before making conclusions from captured traffic, ask where it was collected and what paths a sensor on that point could never observe.