Networking

Overview A switch connects devices within a single network by forwarding traffic based on MAC addresses, while a router connects separate networks together by forwarding traffic based on IP addresses. Plugging a device into the wrong one is a common source of confusion — one expands a LAN, the other bridges LANs to each other or to the internet. Comparison Diagram SwitchRouterSingle broadcast domainSwitchPC1PC2PC3Forwards by MAC address10.0.1.0/24PCPCInternetWANRouterForwards by IP address, links networks Comparison Table Aspect Switch Router OSI layer Layer 2 (Data Link) Layer 3 (Network) Addressing used MAC addresses IP addresses Forwarding table MAC address table (CAM table), learned automatically Routing table, built via static routes or routing protocols Broadcast domain Devices share one broadcast domain (unless VLANs are configured) Separates traffic into distinct broadcast domains per interface Typical placement Connects devices within a single LAN segment Connects different networks together, e.g. LAN to LAN or LAN to WAN Unknown-destination handling Floods frame to all ports in the VLAN when MAC is unknown Drops or rejects packets with no matching route Built-in services Basic switching only, plus optional VLANs/QoS on managed models Often includes NAT, DHCP, firewall, and VPN functions Typical device Cisco Catalyst switch in a wiring closet Home router or edge router linking a LAN to an ISP Key Differences Switches forward traffic using MAC addresses at Layer 2, while routers forward using IP addresses at Layer 3. A switch keeps connected devices in one broadcast domain; a router splits traffic into separate domains. Switches flood frames to unknown destinations within a VLAN; routers simply drop packets they can’t route. Routers commonly bundle NAT and firewall features that switches don’t provide. Switches scale port count for a single network; routers scale the number of distinct networks a device can reach. When to Use Each Switch ...

Overview DHCP and DNS are both foundational network services, but they solve different problems in a device’s journey onto the network. DHCP automatically assigns a device its IP address and network configuration when it joins a subnet, while DNS translates human-readable domain names into the IP addresses needed to actually reach other hosts. Comparison Diagram DHCP DNS Client (no IP) DHCP Server DHCPDISCOVER leased IP + gateway local subnet, broadcast Client (has IP) DNS Resolver example.com? 93.184.216.34 global, hierarchical gives device an address gives a name an address Comparison Table Aspect DHCP DNS Primary purpose Assigns an IP address and network configuration to a device Translates a domain name into an IP address Triggered by A device connecting or booting onto the network An application needing to resolve a hostname Transport protocol UDP, ports 67 (server) and 68 (client) UDP or TCP, port 53 Discovery mechanism Client broadcasts DHCPDISCOVER on the local subnet Client sends a unicast query to a configured resolver address Data returned IP address, subnet mask, default gateway, DNS server list IP address (A/AAAA record) or other record types like MX, CNAME, TXT State and validity Lease with an expiration time that must be renewed Record with a TTL, cached locally then re-queried after expiry Scope Local network segment or subnet Global, hierarchical, distributed across the internet Key Differences DHCP assigns IP addresses to devices; DNS resolves domain names to those addresses. DHCP requests use broadcast discovery on the local subnet; DNS clients send unicast queries to a configured resolver. DHCP assignments are leases that expire and renew; DNS answers are cached per record TTL. DHCP typically hands out the DNS server addresses a client should use, linking the two protocols at boot time. When to Use Each DHCP ...

Overview IPv4 and IPv6 are the two versions of the Internet Protocol responsible for addressing and routing packets across networks. IPv4 relies on 32-bit addresses that ran out of unique combinations, while IPv6 was designed around 128-bit addresses to give every device a globally unique, non-NAT’d address. The distinction matters because it affects address exhaustion, header processing overhead, and whether NAT traversal is required for peer-to-peer connectivity. Comparison Diagram IPv4IPv61921681132 bits · dotted-decimal20010db885a3000000008a2e03707334128 bits · hex colon-notation~4.3 billion addresses~340 undecillion addressesRelative address length32 bits (IPv4)128 bits (IPv6) — 4x longerNAT dependencyIPv4: needs NAT (scarce space)IPv6: end-to-end, no NAT needed Comparison Table Aspect IPv4 IPv6 Address length & notation 32-bit, dotted-decimal (e.g. 192.168.1.1) 128-bit, hexadecimal colon-separated (e.g. 2001:0db8::7334) Address space size ~4.3 billion addresses ~340 undecillion addresses Address assignment Manual configuration or DHCP Stateless Address Autoconfiguration (SLAAC) or DHCPv6 Header structure Variable-length header with options field and checksum Fixed 40-byte header, no checksum, optional extension headers NAT requirement Commonly required due to address scarcity Not needed; supports true end-to-end addressing Broadcast/discovery Uses broadcast (e.g. ARP) for local discovery Broadcast eliminated; uses multicast Neighbor Discovery Built-in security IPsec is an optional add-on IPsec support is part of the core protocol spec Adoption & compatibility Universally supported, legacy infrastructure Growing adoption, requires dual-stack or tunneling for legacy interop Key Differences IPv6 addresses are 128-bit, four times longer than IPv4’s 32-bit addresses, resolving address exhaustion IPv6 removes the need for NAT, restoring true end-to-end connectivity between hosts IPv6 uses a simplified, fixed-length header that speeds up router processing compared to IPv4’s variable header IPv6 replaces ARP broadcasts with Neighbor Discovery multicast for local address resolution When to Use Each IPv4 ...

Overview HTTP and HTTPS are the same application-layer protocol for transferring web resources, but HTTPS wraps every request and response in a TLS tunnel before it touches the network. That single layer determines whether credentials, cookies, and page content travel as plaintext visible to anyone on the path, or as ciphertext only the two endpoints can read. Comparison Diagram HTTPClientServerGET /login?pwd=hunter2visible to anyone on pathHTTPSClientServerx8f#9a2$qL0e...TLS-encrypted, tamper-evident Comparison Table Aspect HTTP HTTPS Default port 80 443 Connection establishment Single TCP three-way handshake TCP handshake plus a TLS handshake to negotiate cipher and exchange keys Certificate requirement None X.509 certificate issued by a trusted CA (or self-signed) required Data encryption Plaintext — headers, cookies, and body sent unencrypted Encrypted end-to-end using TLS/SSL symmetric ciphers Data integrity No built-in tamper detection MAC/AEAD in TLS detects in-transit tampering Browser indicator “Not secure” warning in modern browsers Padlock icon; no warning shown Performance overhead Lower — no crypto or extra round trip Slightly higher handshake/CPU cost, largely offset by TLS 1.3 and session resumption Typical use case Local development, internal tools on trusted networks, legacy static content Any production site, especially logins, payments, and APIs handling sensitive data Key Differences HTTPS is HTTP tunneled through TLS, not a separate application protocol HTTP traffic is readable in plaintext by anyone with network access; HTTPS traffic is encrypted HTTPS requires a valid certificate from a trusted CA to establish trust Modern browsers flag HTTP sites as not secure, pushing HTTPS as the default TLS 1.3 has shrunk the historical HTTPS handshake cost to near parity with plain TCP When to Use Each HTTP ...

Overview TCP and UDP are the two core transport-layer protocols used to move data between hosts, but they trade reliability for speed in opposite directions. TCP prioritizes reliable delivery through handshakes, acknowledgments, and retransmission, while UDP prioritizes low-latency delivery by sending datagrams with no setup or delivery guarantees. Choosing between them shapes how an application handles packet loss, ordering, and throughput. Comparison Diagram TCPUDPClientServerSenderReceiverSYNSYN-ACKACKconnection establishedDataACKDataACKFIN / ACK teardownDatagramDatagramlost, no retryDatagramDatagramno ACKs, no ordering Comparison Table Aspect TCP UDP Connection setup Three-way handshake (SYN, SYN-ACK, ACK) establishes a stateful connection before any data moves No handshake — sender transmits datagrams immediately with no prior negotiation Delivery guarantee Guaranteed via sequence numbers and acknowledgments; lost segments are detected and resent Best-effort only; lost packets vanish silently with no notification to either side Ordering Segments are reassembled in the original order regardless of arrival sequence No ordering guarantee; packets are delivered to the application in whatever order they arrive Flow & congestion control Dynamic window sizing and congestion-avoidance algorithms throttle the sender to match network capacity None; the application sends at whatever rate it chooses, independent of network conditions Error handling Checksum plus automatic retransmission recovers corrupted or missing segments Checksum only; corrupted or missing packets are simply dropped, not recovered Overhead & latency Larger 20+ byte header and handshake/ACK round trips add processing and latency Minimal 8-byte header and no round trips keep per-packet overhead and latency low Connection teardown Explicit four-way FIN/ACK exchange formally closes the connection on both sides No connection state exists, so transmission simply stops with nothing to tear down Key Differences TCP is connection-oriented, requiring a handshake before data flows, while UDP is connectionless TCP guarantees reliable delivery through acknowledgments and retransmission; UDP offers none TCP performs congestion control to avoid overwhelming the network; UDP has no such mechanism UDP’s minimal header overhead gives it consistently lower latency than TCP TCP preserves packet ordering end-to-end; UDP delivers packets in whatever order they arrive When to Use Each TCP ...