Networking Fundamentals — OSI, TCP/IP, and Why Layers Actually Matter

Manish Garg
Manish Garg Associate of (ISC)² · RingSafe
Apr 19, 2026
12 min read
Read as

Last updated: May 1, 2026

OSI is a teaching model. TCP/IP is what actually runs on the wire. Most “OSI questions” in interviews are really about how data physically moves between two computers — frames, packets, segments, sockets. This module gives you the working mental model: the four layers that matter (link, internet, transport, application), what each one carries, where attackers and defenders operate, and the encapsulation trick that makes the whole Internet possible. Stop memorising acronyms. Start reading the wire.

Almost every security course in India still teaches OSI as if you will be quizzed on whether SSL is “Layer 5 or Layer 6.” You will not. What you actually need is a working mental model: when you click a link, what physically happens between your laptop and a server in Mumbai? This module answers that, builds the layered model from the ground up, and shows where each class of attack — ARP poisoning, IP spoofing, port scans, TLS downgrade, HTTP smuggling — lives. By the end you will be able to look at any Wireshark capture and instantly say which layer matters for the question you are asking.

The two models — OSI vs TCP/IP, and what you actually use

The OSI model has seven layers; the TCP/IP model has four. Practitioners use the TCP/IP model because it matches the actual code paths in net/ in the Linux kernel. The OSI model survives because it provides convenient labels (Layer 2 / Layer 7) when comparing devices. Memorise this mapping: OSI Layers 1-2 = TCP/IP Link (Ethernet, Wi-Fi, MAC addresses); OSI 3 = TCP/IP Internet (IP, ICMP, routing); OSI 4 = TCP/IP Transport (TCP, UDP, ports); OSI 5-7 = TCP/IP Application (HTTP, DNS, TLS, SMTP). The “session” and “presentation” layers do not really exist on the wire — they were a 1980s ISO standardisation exercise, never implemented at scale. When a vendor says “Layer 7 firewall” they mean an application-aware firewall that parses HTTP. When they say “Layer 4 load balancer” they mean it routes by TCP/UDP port without looking at content. Tattoo this on your forearm.

Encapsulation — the matryoshka doll of every packet

Every byte you send walks down the layers, growing a header at each step, then walks back up at the receiver. Type https://ringsafe.in in your browser and the HTTP request becomes: HTTP body → wrapped in TLS record → wrapped in TCP segment with src port 54321 + dst port 443 → wrapped in IP packet with src/dst IP → wrapped in Ethernet frame with src/dst MAC. The wire literally carries that nested structure. The router strips the Ethernet frame, looks at the IP header to make a routing decision, rewraps in a new Ethernet frame for the next hop, and forwards.

Why this matters for securityeach layer can attack or defend a different scope. Layer 2 attacks (ARP poisoning, MAC flooding) work only on the local broadcast domain. Layer 3 attacks (IP spoofing, route hijacks) work anywhere the routing table reaches. Layer 7 attacks (SQL injection, XSS) ride inside the application payload and only matter once the bytes reach an app. A defender who only watches Layer 7 misses ARP poisoning. A defender who only does ACLs at Layer 3 misses HTTP smuggling.

Layer 2 — Ethernet, MAC addresses, switches

Ethernet frames are the smallest unit on a typical LAN. A frame has a source MAC, destination MAC, EtherType (0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP), and a payload. MAC addresses are 48 bits, written as aa:bb:cc:dd:ee:ff; the first 24 bits identify the vendor (use wireshark -G ethers or IEEE OUI registry to decode). Switches learn which MAC lives on which port and forward only to that port — that is the entire point of a switch versus a hub. Two pivotal facts:

1switches use ARP to map IPs to MACs, and ARP is unauthenticated by design — anyone on the LAN can claim to be the gateway, which is the basis of every Layer 2 MITM attack.
2VLANs partition a physical switch into multiple logical broadcast domains, tagging frames with a 12-bit VLAN ID (802.1Q). VLAN hopping (double-tagging, switch spoofing) is how attackers escape an “isolated” VLAN. Both are covered deeply in M3 (Protocols) and M12 (Segmentation).

Layer 3 — IP, routing, the Internet

IP packets carry source IP, destination IP, TTL (time-to-live, decremented each hop, prevents infinite loops), and a protocol number identifying the next header (6 = TCP, 17 = UDP, 1 = ICMP). Routing decisions happen here: the router looks at the destination IP, performs a longest-prefix match against its routing table, and forwards the packet to the next-hop. Memorise the special IPv4 ranges every defender must know: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are RFC 1918 private; 127.0.0.0/8 is loopback; 169.254.0.0/16 is link-local APIPA (and used by AWS/Azure for instance metadata — see M3). ICMP rides on IP and is the diagnostic protocol — ping, traceroute, “destination unreachable”, “fragmentation needed”. Defenders should never blanket-block ICMP at the perimeter; the right answer is to permit Type 3 (Destination Unreachable) and Type 11 (Time Exceeded) so Path MTU Discovery and traceroute work. Blocking ICMP entirely is a 2005-era misconception that breaks legitimate network operations and gains nothing — attackers tunnel C2 over DNS or HTTPS anyway.

Layer 4 — TCP, UDP, ports, sockets

A port is a 16-bit number identifying a service on a host. Sockets are the four-tuple (srcIP, srcPort, dstIP, dstPort) that uniquely identifies a connection. TCP gives you ordering, reliability, congestion control, and the famous three-way handshake (SYN → SYN-ACK → ACK). UDP gives you “send and forget” — used for DNS, NTP, QUIC, video streaming, and most modern protocols where the application handles reliability itself. The TCP three-way handshake is also the basis of every port scanner: send SYN, get SYN-ACK = port open; send SYN, get RST = port closed; send SYN, get nothing = filtered (firewall dropped). That is literally how Nmap works.

Importantin 2026 increasingly traffic is QUIC (HTTP/3), which runs over UDP/443 and looks completely opaque to a Layer 4 firewall — it encrypts much of what would have been TCP/TLS metadata. Modern enterprise firewalls need QUIC-aware decryption or they go blind to web traffic.

Layer 7 — applications, the messy top of the stack

This is where users live: HTTP/HTTPS, DNS, SMTP, IMAP, SSH, RDP, SMB, and a thousand more. Each protocol has its own grammar and its own bugs. HTTP request smuggling, SQL injection, SSRF, deserialisation — all are Layer 7 issues. A modern application firewall (WAF) parses Layer 7 to understand context: “this URL parameter looks like a SQL injection.” A Layer 4 firewall would see only “TCP traffic to port 443” and pass it through. The choice between WAF and L4 ACL depends on what you are defending: APIs and websites need L7 inspection; database traffic and inter-server RPC are usually best handled by L4 + mTLS.

One subtle pointTLS encrypts Layer 7. So a WAF must either terminate TLS itself (and re-encrypt to the backend) or sit inside the TLS-terminated network segment. There is no “magic packet inspection” that breaks encryption — anyone selling that is selling you a TLS-MITM appliance with all its operational hazards.

Reading a packet — applying the model

Open Wireshark, click a single HTTPS packet, and you will see five collapsible sections in the dissector pane: Frame metadata (capture time, length); Ethernet II (src + dst MAC, EtherType); Internet Protocol Version 4 (src + dst IP, TTL, protocol); Transmission Control Protocol (src + dst port, flags, seq + ack numbers); Transport Layer Security (record type, version, ciphersuite). Five layers, every packet, always in that order. Once this clicks, you will never be confused about whether something is “a network problem or an app problem” again — you will know which layer to look at and what evidence each layer can give you. Module 2 (Wireshark) goes deep on capture and analysis; Module 3 (Protocols) dissects the most important Layer 4-7 protocols line by line.

A walk through one connection — what really happens when you load a page

You type https://ringsafe.in and press enter. The browser asks the OS resolver for the A or AAAA record; the resolver checks its cache, then queries the recursive resolver (your ISP, 1.1.1.1, or your corporate DNS); the recursive walks down the DNS hierarchy if it does not have a cached answer. The browser receives an IP and opens a TCP connection — three packets — to port 443. On top of that TCP connection, TLS 1.3 negotiates: ClientHello with SNI ringsafe.in, ServerHello with the chosen suite and key share, then encrypted certificate, transcript signature, finished. Now HTTP/2 (or HTTP/3 if QUIC was advertised in the HTTPS DNS record) flows: GET /, headers, body. The server responds; the browser parses HTML, discovers references to images, JS, CSS; opens additional streams; the page renders.

Every step has a security implicationthe DNS query reveals where you are going (DoH/DoT addresses this); the TCP handshake reveals you are alive (port-scan reconnaissance); the TLS ClientHello SNI reveals the destination even encrypted (ECH addresses this); HTTP cookies authenticate; the rendered DOM is where XSS lives. A senior security engineer reads this entire chain instinctively for every connection that matters.

Networking commands — the muscle memory you must build

Linuxip addr for interfaces, ip route for routes, ip neigh for ARP/ND cache, ss -tnlp for listening sockets with PIDs, ss -tnap for all connections, tcpdump -ni any for any-interface capture, nslookup / dig +trace for DNS, mtr for combined ping+traceroute, nmap -sV target for service detection.

Windowsipconfig /all, netstat -ano, route print, arp -a, nslookup, Test-NetConnection, Get-NetTCPConnection.

macOSifconfig, netstat -an, scutil --dns, route -n get default. The first time these are awkward; by the hundredth use they fly. The mistake people make is reaching for the GUI — every modern OS has a great GUI, every modern OS’s GUI hides exactly the field you need. Force yourself to use the CLI for a month and your debugging speed doubles.

Reading and re-reading the layers — a learning loop that works

A self-paced learning loop that turns this module into durable knowledge: Week 1 — install Wireshark, capture five minutes of your laptop’s normal traffic, identify Ethernet, IP, TCP/UDP, application headers in any three packets. Week 2 — write a one-paragraph “story of a packet” for one HTTPS connection: who sent SYN, who replied, what cipher, what hostname. Week 3 — set up a basic homelab (two VMs with networking) and use ip route, ping, traceroute to map paths between them. Week 4 — break something deliberately (block ICMP, change MTU) and observe what fails. Week 5 — capture a TLS handshake on your own server and identify SNI, ALPN, cipher choice. By week 5 the four-layer model is muscle memory and you can engage with any networking topic without translation overhead.

For Indian self-learnersthis loop costs nothing — your laptop and home Wi-Fi are sufficient. Pair with the practitioner roadmap on RingSafe Academy for a structured progression into VAPT, blue-team, or cloud security tracks.

Diagrams

Encapsulation — what the wire actually carries
Application data:    [ HTTP GET /index.html  Host: ringsafe.in ]
                                         |
                          + TLS record header (Type, Version, Length)
                                         |
                          + TCP header (SrcPort 54321  DstPort 443  SYN/ACK/...)
                                         |
                          + IP header  (SrcIP 10.0.0.5  DstIP 14.99.x.x  TTL 64)
                                         |
                          + Ethernet header (SrcMAC ..  DstMAC ..  EtherType 0x0800)
                                         |
                                       [ ON THE WIRE ]

Every hop strips the Ethernet header, makes a routing decision
based on the IP header, and re-wraps for the next hop. The TCP
segment, TLS record, and HTTP body travel end-to-end unchanged.
OSI vs TCP/IP — the only mapping you need
  OSI                       TCP/IP            Examples
  ───────────────────────────────────────────────────────────────
  7 Application  ─┐
  6 Presentation  ├─►  Application       HTTP, DNS, TLS, SSH, SMB
  5 Session      ─┘
  4 Transport     ──►  Transport         TCP, UDP, QUIC
  3 Network       ──►  Internet          IP, ICMP, IPsec
  2 Data link    ─┐
  1 Physical      ├─►  Link              Ethernet, Wi-Fi, ARP
                 ─┘

References & deeper reading

FAQ

Do I really need to memorise the OSI 7 layers?

You need the four-layer TCP/IP model cold and the OSI mapping at recall speed (Layer 2 = link, Layer 3 = IP, Layer 4 = TCP/UDP, Layer 7 = app). Beyond that, the “session” and “presentation” layers are an academic relic. Interview questions like “what layer is TLS?” really mean “between TCP and HTTP” — answer that, not 5/6/7.

Why does TCP have a three-way handshake instead of two-way?

A three-way handshake confirms both sides agreed on initial sequence numbers. With only two messages, the second one could be a replayed old packet from a previous connection — TCP would not be able to tell. The third ACK confirms freshness. This is also why SYN floods work: the server allocates state on receiving SYN and waits for an ACK that never comes.

Where does TLS sit — Layer 4 or Layer 7?

TLS sits between TCP and the application. Strictly it is “Layer 5/6 in OSI terms” but practitioners call it “Layer 7 adjacent” because it shares all the application concerns (cert validation, SNI, ALPN). Wireshark dissects it as a separate protocol layer in its own pane. The right framing: TLS is a session-establishment protocol on top of TCP, transparent to the application above it.

Why do I need this if I just want to do web app security?

Because every HTTP request rides on top of TCP, IP, and Ethernet — and one in ten “web bugs” turns out to be a network or transport bug pretending to be a web bug. HTTP request smuggling, TLS confusion, SNI bypasses, IP-based access controls bypassed by header injection — all of those need network fluency to spot.

Should I learn IPv6 alongside IPv4?

Yes — Module 7 covers it. IPv6 is now mandatory at most Indian ISPs (Jio, Airtel) and every reasonable enterprise has dual-stack networks. Many “missing acl” findings come from teams who configured IPv4 firewalls and forgot IPv6 was also enabled, leaving a parallel attack surface unguarded.

What is the difference between TCP/IP and the Internet?

TCP/IP is the protocol family — IP, TCP, UDP, ICMP. The Internet is the global interconnected network of networks that runs TCP/IP. You can run TCP/IP on a private network (your home Wi-Fi) without it being “the Internet”. You cannot run “the Internet” without TCP/IP.

Why do all networking books start with the OSI model if it is outdated?

Pedagogical convenience. The OSI model is a clean teaching abstraction — seven labelled layers with neat boundaries. The TCP/IP model is what runs but the boundaries are messier (TLS does not fit cleanly anywhere). Most authors teach OSI to set up the language, then explain that real implementations are TCP/IP.


⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.

Want this for your team?

Custom team training + practitioner advisory

Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.

Book team training call Replies in 4 working hrs · India-only · Senior consultants