// The 7 Layers of the OSI Model (top to bottom):

// Layer 7 — Application
// What users interact with. Provides network services to applications.
// Protocols: HTTP, HTTPS, FTP, SMTP, DNS, SNMP, SSH, Telnet
// Example: Your browser making an HTTP request to a web server

// Layer 6 — Presentation
// Data formatting, encryption, compression.
// Translates data between application and network formats.
// Protocols: SSL/TLS, JPEG, GIF, ASCII, MPEG
// Example: TLS encrypting your HTTPS connection

// Layer 5 — Session
// Manages sessions (connections) between applications.
// Handles session establishment, maintenance, and teardown.
// Protocols: NetBIOS, RPC, PPTP
// Example: Keeping your login session alive on a web app

// Layer 4 — Transport
// End-to-end communication, reliability, flow control.
// Segments data, handles retransmission and ordering.
// Protocols: TCP (reliable), UDP (fast, unreliable)
// Example: TCP ensuring all packets of a file download arrive in order

// Layer 3 — Network
// Logical addressing and routing between networks.
// Determines the best path for data to travel.
// Protocols: IP, ICMP, OSPF, BGP, ARP
// Example: A router forwarding packets based on destination IP address

// Layer 2 — Data Link
// Physical addressing (MAC), error detection, frame delivery.
// Handles communication within the same network segment.
// Protocols: Ethernet, Wi-Fi (802.11), PPP, ARP (also here)
// Example: A switch forwarding frames based on MAC address

// Layer 1 — Physical
// Raw bit transmission over physical media.
// Cables, connectors, voltages, signal encoding.
// Examples: Ethernet cables (Cat5e/Cat6), fiber optic, Wi-Fi radio waves
// Example: Electrical signals traveling through a copper cable

// TCP (Transmission Control Protocol)
// - Connection-oriented (3-way handshake: SYN → SYN-ACK → ACK)
// - Reliable: guarantees delivery, ordering, error checking
// - Flow control and congestion control
// - Slower due to overhead
// - Used when data integrity matters

// TCP use cases and ports:
// HTTP/HTTPS  — port 80/443  (web browsing)
// FTP         — port 20/21   (file transfer)
// SSH         — port 22      (secure remote access)
// SMTP        — port 25/587  (sending email)
// MySQL       — port 3306    (database queries)

// UDP (User Datagram Protocol)
// - Connectionless (no handshake)
// - Unreliable: no delivery guarantee, no ordering
// - No flow control or congestion control
// - Faster, lower latency
// - Used when speed matters more than reliability

// UDP use cases and ports:
// DNS         — port 53      (name resolution — small, fast queries)
// DHCP        — port 67/68   (IP address assignment)
// TFTP        — port 69      (trivial file transfer)
// SNMP        — port 161     (network monitoring)
// VoIP/RTP    — various      (voice/video calls)
// Online gaming — various    (real-time game state updates)
// Video streaming — various  (live streams, buffered video)

// Key insight: DNS uses UDP for queries (fast, small packets)
// but falls back to TCP for zone transfers (large, must be reliable)
// This is a common follow-up question.

// What happens when you type "https://example.com" and press Enter:

// Step 1: DNS Resolution
// Browser checks its cache → OS cache → router cache → ISP DNS
// If not cached, recursive DNS query:
//   Local DNS → Root server (.com) → TLD server → Authoritative server
//   Returns IP address: 93.184.216.34

// Step 2: TCP 3-Way Handshake
// Client → Server: SYN (seq=100)
// Server → Client: SYN-ACK (seq=300, ack=101)
// Client → Server: ACK (seq=101, ack=301)
// TCP connection is now established on port 443 (HTTPS)

// Step 3: TLS Handshake (for HTTPS)
// Client sends: supported cipher suites, TLS version
// Server sends: chosen cipher suite, SSL certificate
// Client verifies certificate with Certificate Authority (CA)
// Both sides generate session keys for symmetric encryption
// Secure channel is now established

// Step 4: HTTP Request
// Client sends: GET / HTTP/1.1
// Headers: Host: example.com, User-Agent, Accept, Cookies

// Step 5: Server Processing
// Web server (Nginx/Apache) receives request
// Routes to application server → queries database if needed
// Generates HTML response

// Step 6: HTTP Response
// Server sends: HTTP/1.1 200 OK
// Headers: Content-Type: text/html, Content-Length, Cache-Control
// Body: HTML content

// Step 7: Browser Rendering
// Parses HTML → builds DOM tree
// Fetches CSS, JS, images (parallel requests)
// Renders the page on screen

// Step 8: TCP Connection Close (or keep-alive)
// FIN → ACK → FIN → ACK (4-way teardown)
// Or connection stays open for subsequent requests (HTTP/1.1 keep-alive)

// OSI Model (7 layers)          TCP/IP Model (4 layers)
// ─────────────────────         ─────────────────────────
// 7. Application    ─┐
// 6. Presentation    ├──────→  4. Application
// 5. Session        ─┘            (HTTP, FTP, DNS, SSH, SMTP)
//
// 4. Transport      ──────→   3. Transport
//                                 (TCP, UDP)
//
// 3. Network        ──────→   2. Internet
//                                 (IP, ICMP, ARP)
//
// 2. Data Link      ─┐
// 1. Physical        ├──────→  1. Network Access
//                    ─┘           (Ethernet, Wi-Fi, PPP)

// Key differences:
// OSI: 7 layers, theoretical, developed by ISO
// TCP/IP: 4 layers, practical, developed by DARPA/DoD
//
// OSI separates Application/Presentation/Session
// TCP/IP combines them into one Application layer
//
// OSI separates Data Link and Physical
// TCP/IP combines them into Network Access layer
//
// TCP/IP is what the internet actually runs on
// OSI is used as a teaching and troubleshooting framework
//
// Interview tip: Say "OSI is the reference model for understanding,
// TCP/IP is the implementation model the internet uses."
// Then explain how the layers map to each other.

// SWITCH (Layer 2 — Data Link)
// - Forwards frames based on MAC addresses
// - Operates within a single network (LAN)
// - Maintains a MAC address table (CAM table)
// - Learns MAC addresses by examining source of incoming frames
// - Reduces collisions by creating separate collision domains per port
// - Does NOT understand IP addresses (basic switches)
// - Example: Connecting 48 computers in the same office floor

// ROUTER (Layer 3 — Network)
// - Forwards packets based on IP addresses
// - Connects different networks together
// - Maintains a routing table (static routes + dynamic protocols)
// - Performs NAT (Network Address Translation)
// - Creates separate broadcast domains
// - Makes forwarding decisions based on destination IP
// - Example: Connecting your office LAN to the internet

// Layer 3 Switch (hybrid):
// - A switch that can also route (has routing capabilities)
// - Faster than a traditional router for inter-VLAN routing
// - Common in enterprise networks
// - Example: Cisco Catalyst 3750, Juniper EX4300

// Key distinction:
// Switch = same network, MAC addresses, Layer 2
// Router = different networks, IP addresses, Layer 3
// Layer 3 switch = does both, common in modern enterprise networks

// Subnetting Example: 192.168.1.0/24 → split into /26 subnets

// /24 = 255.255.255.0   → 256 addresses, 254 usable hosts
// /26 = 255.255.255.192 → 64 addresses per subnet, 62 usable hosts

// How: /26 means 26 network bits, 6 host bits
// 2^6 = 64 addresses per subnet
// 64 - 2 = 62 usable hosts (subtract network + broadcast)
// 256 / 64 = 4 subnets

// The 4 subnets:
// Subnet 1: 192.168.1.0/26
//   Network:   192.168.1.0
//   First host: 192.168.1.1
//   Last host:  192.168.1.62
//   Broadcast:  192.168.1.63

// Subnet 2: 192.168.1.64/26
//   Network:   192.168.1.64
//   First host: 192.168.1.65
//   Last host:  192.168.1.126
//   Broadcast:  192.168.1.127

// Subnet 3: 192.168.1.128/26
//   Network:   192.168.1.128
//   First host: 192.168.1.129
//   Last host:  192.168.1.190
//   Broadcast:  192.168.1.191

// Subnet 4: 192.168.1.192/26
//   Network:   192.168.1.192
//   First host: 192.168.1.193
//   Last host:  192.168.1.254
//   Broadcast:  192.168.1.255

// Quick reference — common subnet sizes:
// /24 = 256 addresses (254 hosts)
// /25 = 128 addresses (126 hosts)
// /26 = 64 addresses  (62 hosts)
// /27 = 32 addresses  (30 hosts)
// /28 = 16 addresses  (14 hosts)
// /30 = 4 addresses   (2 hosts — point-to-point links)

// VLAN (Virtual Local Area Network)
// Logically segments a physical switch into multiple broadcast domains

// Without VLANs:
// All 48 ports on a switch = 1 broadcast domain
// Every broadcast reaches every device
// No security separation between departments
// ARP storms affect the entire network

// With VLANs:
// VLAN 10 (Engineering) — ports 1-16
// VLAN 20 (Finance)     — ports 17-32
// VLAN 30 (HR)          — ports 33-48
// Each VLAN is a separate broadcast domain
// Broadcasts in VLAN 10 do NOT reach VLAN 20

// Benefits:
// 1. Security: Finance traffic isolated from Engineering
// 2. Performance: Smaller broadcast domains = less noise
// 3. Flexibility: Move users between VLANs without rewiring
// 4. Cost: One physical switch acts as multiple logical switches

// Trunk ports vs Access ports:
// Access port: belongs to ONE VLAN (connects to end devices)
// Trunk port: carries MULTIPLE VLANs (connects switches together)
// Trunk uses 802.1Q tagging to identify which VLAN a frame belongs to

// Inter-VLAN routing:
// VLANs cannot communicate by default (that is the point)
// To allow communication: use a Layer 3 switch or router
// "Router on a stick" — single router interface with sub-interfaces
// Each sub-interface handles one VLAN

// Example Cisco config:
// switch(config)# vlan 10
// switch(config-vlan)# name Engineering
// switch(config)# interface fa0/1
// switch(config-if)# switchport mode access
// switch(config-if)# switchport access vlan 10

// HTTP (HyperText Transfer Protocol)
// - Port 80
// - Data sent in plaintext
// - No encryption, no authentication
// - Anyone on the network can intercept and read traffic
// - Vulnerable to man-in-the-middle (MITM) attacks

// HTTPS (HTTP Secure)
// - Port 443
// - Data encrypted using TLS (Transport Layer Security)
// - Server identity verified via SSL/TLS certificate
// - Protects against eavesdropping and tampering

// How HTTPS works (TLS Handshake):
// 1. Client sends: "Hello, I support these cipher suites"
//    (e.g., TLS_AES_256_GCM_SHA384)
// 2. Server sends: "Let's use this cipher suite" + SSL certificate
// 3. Client verifies certificate:
//    - Is it signed by a trusted Certificate Authority (CA)?
//    - Is the domain name correct?
//    - Is it expired?
// 4. Key exchange: Both sides agree on a symmetric session key
//    (using RSA or Diffie-Hellman key exchange)
// 5. All subsequent data is encrypted with the session key

// TLS versions:
// TLS 1.0, 1.1 — deprecated (insecure)
// TLS 1.2 — widely used, still secure
// TLS 1.3 — latest, faster handshake, stronger security

// Interview tip: Mention that HTTPS uses asymmetric encryption
// for the handshake (key exchange) and symmetric encryption
// for the actual data transfer (faster). This shows depth.

// DNS (Domain Name System) — translates domain names to IP addresses
// Port 53 (UDP for queries, TCP for zone transfers)

// DNS Resolution Process for "www.example.com":

// Step 1: Check local caches (fast path)
// Browser cache → OS cache (hosts file) → Router cache
// If found, return IP immediately — no network query needed

// Step 2: Query the Recursive DNS Resolver (usually your ISP)
// Client asks: "What is the IP for www.example.com?"
// Recursive resolver does the heavy lifting

// Step 3: Recursive resolver queries Root DNS Servers
// Root server says: "I don't know, but .com is handled by these TLD servers"
// (13 root server clusters worldwide: a.root-servers.net through m.root-servers.net)

// Step 4: Query the TLD (Top-Level Domain) Server
// .com TLD server says: "example.com is handled by ns1.example.com"
// Returns the authoritative nameserver for example.com

// Step 5: Query the Authoritative DNS Server
// ns1.example.com says: "www.example.com = 93.184.216.34"
// This is the definitive answer

// Step 6: Response cached at every level
// Recursive resolver caches it (TTL: e.g., 3600 seconds)
// OS caches it, browser caches it
// Next query for same domain is instant

// Recursive vs Iterative:
// Recursive: Client asks resolver, resolver does ALL the work
// Iterative: Resolver asks each server, gets referrals, follows them

// DNS Record Types:
// A     — maps domain to IPv4 address
// AAAA  — maps domain to IPv6 address
// CNAME — alias (www.example.com → example.com)
// MX    — mail server for the domain
// NS    — authoritative nameserver
// TXT   — text records (SPF, DKIM for email verification)
// PTR   — reverse DNS (IP → domain name)

// Firewall — controls network traffic based on security rules

// Type 1: Packet Filtering Firewall (Layer 3/4)
// - Examines each packet individually
// - Filters based on: source IP, destination IP, port, protocol
// - Stateless — does not track connection state
// - Fast but limited (cannot inspect application data)
// - Example rule: ALLOW TCP from 10.0.0.0/24 to any port 443
//                 DENY all from any to any (default deny)

// Type 2: Stateful Inspection Firewall (Layer 3/4)
// - Tracks the state of active connections
// - Knows if a packet is part of an established connection
// - More secure than packet filtering
// - Example: Allows return traffic for connections YOU initiated
//   but blocks unsolicited inbound connections
// - Cisco ASA, pfSense, iptables with conntrack

// Type 3: Application Layer Firewall / WAF (Layer 7)
// - Inspects the actual content of packets
// - Can filter based on HTTP headers, URLs, SQL queries
// - Blocks SQL injection, XSS, and other application attacks
// - Slower (deep packet inspection) but most thorough
// - Examples: AWS WAF, Cloudflare WAF, ModSecurity

// Next-Generation Firewall (NGFW):
// Combines all three + intrusion prevention (IPS)
// + deep packet inspection + application awareness
// Examples: Palo Alto PA series, Fortinet FortiGate, Cisco Firepower

// Firewall placement:
// Perimeter firewall — between internet and internal network
// Internal firewall — between network segments (e.g., DMZ)
// Host-based firewall — on individual servers (iptables, Windows Firewall)

// Interview tip: Always mention "default deny" policy
// — block everything, then explicitly allow what is needed.
// This is the fundamental principle of firewall security.

// Systematic troubleshooting: bottom-up approach

// Step 1: Check physical connectivity (Layer 1)
// Is the cable plugged in? Is the Wi-Fi connected?
// Check link lights on the NIC and switch port
$ ip link show          # Linux — check interface status
$ ipconfig              # Windows — check adapter status

// Step 2: Check IP configuration (Layer 3)
$ ipconfig /all         # Windows — check IP, subnet, gateway, DNS
$ ip addr show          # Linux — check IP address
// Verify: Does the machine have a valid IP? (not 169.254.x.x / APIPA)
// Is the subnet mask correct? Is the default gateway set?

// Step 3: Ping the default gateway
$ ping 192.168.1.1      # Can you reach your own router?
// If this fails: local network issue (cable, switch, VLAN)

// Step 4: Ping an external IP (bypass DNS)
$ ping 8.8.8.8          # Google's public DNS
// If gateway works but this fails: routing issue upstream

// Step 5: Check DNS resolution
$ nslookup example.com  # Does DNS resolve the domain?
$ dig example.com       # Linux — more detailed DNS query
// If ping 8.8.8.8 works but nslookup fails: DNS issue
// Try: nslookup example.com 8.8.8.8 (use different DNS server)

// Step 6: Check the specific port/service
$ telnet example.com 443   # Can you reach port 443?
$ curl -I https://example.com  # Does HTTP respond?
// If DNS works but connection fails: firewall blocking the port

// Step 7: Check firewall rules
$ iptables -L -n        # Linux — list firewall rules
$ netsh advfirewall show allprofiles  # Windows
// Check both local firewall and network firewall

// Step 8: Check application logs
// If everything above works, the issue is application-level
// Check web server logs, proxy logs, load balancer health

// PING — tests reachability and measures round-trip time
// Uses ICMP Echo Request / Echo Reply
$ ping 8.8.8.8
// PING 8.8.8.8: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms
//               64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.8 ms
// Tells you: Host is reachable, latency is ~12ms, TTL is 118

// What ping tells you:
// - Is the host alive and responding?
// - What is the round-trip latency?
// - Is there packet loss? (X% packet loss)
// - TTL value (hints at number of hops)

// TRACEROUTE — shows the path packets take to reach a destination
// Uses incrementing TTL values to discover each hop
$ traceroute 8.8.8.8        # Linux/Mac
$ tracert 8.8.8.8           # Windows
//  1  192.168.1.1      1.2 ms   (your router)
//  2  10.0.0.1         5.4 ms   (ISP gateway)
//  3  72.14.215.85    12.1 ms   (ISP backbone)
//  4  8.8.8.8         12.5 ms   (destination)

// How traceroute works:
// Sends packet with TTL=1 → first router decrements to 0 → sends back ICMP Time Exceeded
// Sends packet with TTL=2 → second router responds
// Repeats until destination is reached

// What traceroute tells you:
// - The exact path packets take
// - Where latency increases (which hop is slow)
// - Where packets are being dropped (*** = no response)
// - If traffic is being routed through unexpected paths

// When to use which:
// Ping first: "Is the destination reachable at all?"
// Traceroute second: "Where along the path is the problem?"

// Method 1: telnet (quick test for a single port)
$ telnet example.com 443
// Connected to example.com → port is OPEN
// Connection refused → port is CLOSED (service not running)
// Connection timed out → port is FILTERED (firewall blocking)

// Method 2: netcat / nc (more flexible than telnet)
$ nc -zv example.com 443
// Connection to example.com 443 port [tcp/https] succeeded!
// -z = scan mode (don't send data)
// -v = verbose output

// Method 3: nmap (comprehensive port scanning)
$ nmap -p 443 example.com
// PORT    STATE    SERVICE
// 443/tcp open     https
//
// States: open, closed, filtered (firewall), open|filtered
$ nmap -p 1-1000 example.com    # Scan port range
$ nmap -sV -p 443 example.com   # Detect service version

// Method 4: ss / netstat (check ports on LOCAL machine)
$ ss -tlnp                # Linux — show listening TCP ports
$ netstat -tlnp           # Linux (older) — same thing
$ netstat -an | findstr LISTENING  # Windows
// Shows which ports are open and which process is listening

// Method 5: curl (for HTTP/HTTPS services)
$ curl -I https://example.com:443
// Returns HTTP headers if the web service is running
// Connection refused = port closed or service down

// Method 6: PowerShell (Windows)
$ Test-NetConnection example.com -Port 443
// TcpTestSucceeded: True/False

// Interview tip: Start with telnet or nc for quick checks,
// use nmap for comprehensive scanning, use ss/netstat
// for checking what is listening on the local machine.

// Network Design: 200-person office, 3 departments
// Departments: Engineering (80), Sales (70), Finance (50)

// Step 1: IP Addressing Scheme
// Use 10.10.0.0/16 private range (plenty of room to grow)
// VLAN 10 — Engineering: 10.10.10.0/25 (126 hosts, room for growth)
// VLAN 20 — Sales:       10.10.20.0/25 (126 hosts)
// VLAN 30 — Finance:     10.10.30.0/26 (62 hosts)
// VLAN 99 — Management:  10.10.99.0/28 (14 hosts — network devices)

// Step 2: Network Equipment
// Core: 2x Layer 3 switches (redundant — HSRP/VRRP for failover)
// Access: 6x 48-port Layer 2 switches (2 per department)
// Firewall: 1x NGFW at the perimeter (Palo Alto / FortiGate)
// Router: 1x edge router connecting to ISP (or firewall does this)
// Wireless: 10-15 access points (1 per ~15 users, on separate VLAN)

// Step 3: VLANs and Segmentation
// Each department on its own VLAN (broadcast domain isolation)
// Guest Wi-Fi on VLAN 40 (isolated from internal network)
// Server VLAN 50 for internal servers
// Trunk links between access switches and core switches

// Step 4: Security
// Firewall rules: Finance VLAN cannot be accessed from Sales
// ACLs on Layer 3 switches for inter-VLAN traffic control
// 802.1X port authentication (prevent unauthorized devices)
// Guest Wi-Fi isolated — internet only, no internal access

// Step 5: Redundancy
// Dual uplinks from access to core switches (link aggregation)
// Dual core switches with HSRP/VRRP (gateway redundancy)
// Dual ISP connections if budget allows (BGP or static failover)
// UPS for all network equipment

// Step 6: Services
// DHCP server: assigns IPs per VLAN (DHCP relay on core switch)
// DNS server: internal DNS for company resources
// NTP server: time synchronization for all devices
// SNMP/Syslog: centralized monitoring and logging

// Diagnosing slow network performance — structured approach

// Step 1: Define the scope
// Is it one user, one department, or the entire network?
// Is it one application or all traffic?
// When did it start? What changed? (new device, config change, update)

// Step 2: Check bandwidth utilization
$ iftop                    # Linux — real-time bandwidth per connection
$ bmon                     # Linux — bandwidth monitor
// Check switch/router interface utilization via SNMP/dashboard
// If uplink is at 95% utilization → bandwidth bottleneck
// Solution: upgrade link, implement QoS, find the bandwidth hog

// Step 3: Check for packet loss and latency
$ ping -c 100 8.8.8.8     # Send 100 pings, check for loss
$ mtr 8.8.8.8             # Combines ping + traceroute (continuous)
// >1% packet loss = problem
// Latency spikes at a specific hop = congestion at that point

// Step 4: Check for broadcast storms / loops
// Symptoms: all traffic slow, high CPU on switches
$ show interfaces counters  # Cisco — check for excessive broadcasts
// Look for: broadcast storms, spanning tree issues, duplicate IPs
// Solution: verify STP is running, check for loops, check VLAN config

// Step 5: Check DNS performance
$ time nslookup example.com
// If DNS resolution takes >100ms, it slows every web request
// Solution: check DNS server health, add caching, use faster DNS

// Step 6: Check for duplex mismatch
$ ethtool eth0             # Linux — check speed/duplex
// Auto-negotiation failures cause half-duplex on gigabit links
// Symptoms: slow transfer, high collision count, CRC errors
// Solution: hard-set speed and duplex on both ends

// Step 7: Check application-level issues
// Is the server CPU/memory maxed out?
// Is the database slow? Is the application making too many requests?
// Use Wireshark to capture and analyze traffic patterns
// Look for: TCP retransmissions, window size issues, connection resets

// Step 8: Check QoS and traffic shaping
// Is VoIP or video traffic consuming all bandwidth?
// Are backup jobs running during business hours?
// Solution: implement QoS policies to prioritize critical traffic