Networking, from the cable to the cloud.

Protocols are layered agreements

No single protocol does everything. Opening a web page uses several at once, each solving one problem:

• HTTP decides what the browser asks for and what the server sends back.
• TCP makes sure those bytes arrive complete and in order.
• IP gets each piece from your network to the server's network, across many routers.
• Ethernet or Wi-Fi moves the piece across the one local link it is on right now.

Each protocol trusts the one below it to do its job and ignores the details. HTTP has no idea whether you are on Wi-Fi or a cable. That separation is why you can troubleshoot one layer at a time.

Packets, not streams

Data is cut into packets. On a normal Ethernet or Wi-Fi network a packet carries at most about 1,500 bytes, so a 3 MB photo becomes roughly two thousand packets. Each packet carries its own addressing, travels independently, and is reassembled at the far end.

This is called packet switching. Many conversations share the same links, taking turns packet by packet. If one packet is lost, only that packet is resent. The old telephone network did the opposite (a dedicated circuit for each call), which is why it wasted capacity whenever nobody was speaking.

Encapsulation: envelopes inside envelopes

As data goes down the stack on the sender, each layer adds its own header in front of what it received:

[ Ethernet hdr | IP hdr | TCP hdr | HTTP data ........ | FCS ]
  MAC → MAC     IP → IP  port → port  "GET /index.html"    checksum

The receiver peels the layers off in reverse. One detail worth remembering for interviews: at every router along the way, the outer Ethernet header is removed and a new one is written for the next link. The MAC addresses change at every hop; the IP addresses stay the same end to end (unless NAT rewrites them, covered in module 2).

Two models: OSI vocabulary, TCP/IP reality

The OSI model has seven layers: 1 Physical, 2 Data Link, 3 Network, 4 Transport, 5 Session, 6 Presentation, 7 Application. Hardly any software is built in those exact seven pieces, but the numbers are used as shorthand everywhere: "layer 2 issue" means switching/VLANs, "layer 3" means IP and routing, "layer 7 load balancer" means it understands HTTP.

The TCP/IP model is what actually runs: Link, Internet, Transport, Application. Layers 5–7 of OSI are folded into "application". Know the OSI numbers so you can speak the language; reason with the four TCP/IP layers.

The building blocks you will touch

• Endpoints / hosts: laptops, phones, servers, printers, IP phones, cameras.
• Switch: connects devices inside one local network (layer 2).
• Router: connects different networks together and picks paths between them (layer 3). A home "router" is usually a router, switch, Wi-Fi access point, firewall and DHCP server in one box.
• Access point: bridges Wi-Fi clients onto the wired network.
• Firewall: allows or blocks traffic based on rules.
• Servers and services: DHCP, DNS, web, file, identity.

Bits versus bytes

Network speeds are quoted in bits per second (Mbps). File sizes and download meters use bytes (MB/s). There are 8 bits in a byte, so a 100 Mbps connection tops out around 12 MB/s, and a bit lower after protocol overhead. A user who says "I pay for 100 and only get 11" is usually getting exactly what they pay for.

MAC addresses: the local name tag

A MAC address is 48 bits, written as six hex pairs: 3c:22:fb:9a:10:4e (Windows shows it as 3C-22-FB-9A-10-4E). The first half traditionally identifies the manufacturer. A MAC is only meaningful on the local network segment. Routers do not forward it beyond their own link.

Modern phones and Windows/macOS laptops can use a random (private) MAC per Wi-Fi network. It protects privacy but breaks anything keyed to a fixed MAC: DHCP reservations, MAC allowlists, some captive portals and NAC policies. If the second hex digit is 2, 6, A or E (for example a6:… or da:…), it is a locally assigned, likely randomized address.

IPv4 addresses and the subnet mask

An IPv4 address is 32 bits written as four numbers from 0 to 255: 10.10.20.57. The subnet mask splits it into a network part and a host part. /24 (= 255.255.255.0) means the first 24 bits are the network, so 10.10.20.57/24 lives on network 10.10.20.0, with hosts .1 to .254 and broadcast .255.

The device uses the mask for one decision: is the destination on my network (deliver directly) or not (send to the gateway)? Module 4 does the subnet math.

Ranges worth recognizing on sight

DHCP: four messages to get online

A new device has no address, so it broadcasts a Discover. A DHCP server answers with an Offer, the client sends a Request for that address, and the server confirms with an Acknowledge, often remembered as DORA. The ACK includes the lease length and options such as router (gateway), DNS servers and domain name.

Leases expire. A client tries to renew at about half the lease time, so a laptop that is on for days keeps the same address. Two things you will meet in offices:

• DHCP relay (often called an "IP helper"): DHCP Discover is a broadcast and stops at the router, so each VLAN's router interface forwards it to a central DHCP server. A missing relay on a new VLAN = every device gets 169.254.
• Reservations: the server always gives a given MAC the same IP, used for printers and some servers. Random MACs defeat them.

Default gateway, LAN and WAN

The default gateway is the router interface on your subnet, usually .1 or .254. Anything not local is handed to it. A wrong gateway produces a classic symptom: local printers and file shares work, nothing else does.

The LAN is the network you control: an office floor, a home, a campus. The WAN connects sites to each other and to the internet through ISPs, leased lines, SD-WAN or VPN tunnels. A WLAN is the Wi-Fi part of the LAN. The router at the edge is where LAN meets WAN, and usually where NAT and the firewall live.

NAT and PAT: many devices, one public address

Private addresses can't be used on the internet, so the edge router rewrites them. With PAT (port address translation, what home routers and most offices do), the router replaces the source 10.10.20.57:51544 with its public 203.0.113.7:40001, remembers the mapping, and reverses it when the reply arrives. Hundreds of devices share one public IP this way.

Consequences you will see: inbound connections need an explicit port forward; a "what is my IP" site shows the router's public address, not the laptop's; and with CGNAT (WAN address in 100.64.0.0/10) the ISP is doing another layer of NAT, so port forwarding at home cannot work.

IPv6 in two minutes

IPv6 addresses are 128 bits in hex: 2001:db8:4a1:20::57 (2001:db8::/32 is the documentation range). :: compresses a run of zeros. Every interface has a link-local fe80:: address, and most also get a global address automatically (SLAAC) or from DHCPv6. There is no NAT in typical IPv6 deployments and no ARP; Neighbor Discovery does that job.

Many networks are dual stack. A site that fails only over IPv6 while IPv4 works is a real (if uncommon) ticket. Comparing ping -4 and ping -6 separates them.

What is inside an Ethernet frame

| dest MAC | source MAC | [802.1Q tag] | EtherType | payload (≤1500 B) | FCS |
                                          0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP

The FCS is a checksum. If a frame arrives damaged, the receiver discards it silently. On a switch this shows up as CRC / input errors on the port, a strong hint of a bad cable, bad patch, or electrical interference.

How a switch decides where frames go

A switch reads the source MAC of every frame and records "this MAC is behind port 7" in its MAC address table (entries age out after a few minutes of silence). It then looks up the destination MAC:

• Known → send out that one port only.
• Unknown, or broadcast ff:ff:ff:ff:ff:ff → flood out every port in the same VLAN.

Old hubs repeated every frame to every port; switches don't, which is why you can't capture a colleague's traffic just by plugging into the same switch. Everything in one VLAN is one broadcast domain: broadcasts reach every device in it, and routers stop them.

ARP: finding a MAC for an IP

IP knows the destination IP; Ethernet needs a MAC. ARP bridges the gap. The laptop broadcasts "who has 10.0.0.1? tell 10.0.0.5". Only the owner answers, directly. The result is cached for a short time (see it with arp -a).

Two practical points. For anything off-subnet, the laptop ARPs for its gateway, not the remote server. And because ARP trusts whoever answers, a rogue device can claim the gateway's IP (ARP spoofing). Managed switches have protections like Dynamic ARP Inspection. IPv6 replaces ARP with Neighbor Discovery.

VLANs, access ports and trunks

A VLAN splits one physical switch into separate logical networks, each with its own subnet: for example VLAN 10 staff, 20 voice, 30 guest, 40 printers. Devices in different VLANs can only talk through a router or layer 3 switch, where firewall rules can be applied.

• An access port belongs to one VLAN; the PC has no idea VLANs exist.
• A trunk carries many VLANs between switches, access points and routers, marking each frame with an 802.1Q tag (VLAN ID 1–4094).
• A desk IP phone usually sits on a port with a voice VLAN: the phone tags its own traffic into voice, and the PC plugged into the phone's back port stays on the data VLAN.

Loops and spanning tree

Connect two switch ports together with a cable (or a user plugs both ends of a patch cable into the wall) and broadcasts circulate forever: a broadcast storm that can freeze a whole floor. Spanning Tree Protocol (STP) detects loops and blocks redundant ports. Classic STP makes a newly connected port wait around 30 seconds before forwarding, which is why switches set end-user ports to "PortFast" / edge mode. Without it, a PC can boot faster than the port comes up and get a 169.254 address.

Cabling and physical checks

• Copper Ethernet runs are limited to 100 m. Cat5e handles 1 Gbps; Cat6/6A for higher speeds.
• Gigabit uses all four pairs; 100 Mbps uses two. A cable with one damaged pair often links at 100 Mbps instead of 1 Gbps: a great clue when "the network is slow" for one desk.
• Speed/duplex should auto-negotiate on both ends. A mismatch (one side forced) causes errors and terrible throughput while ping still looks fine.
• PoE powers phones, access points and cameras over the cable. A phone that boots in one port but not another may be on a non-PoE port, or the switch has run out of PoE budget.

Wi-Fi essentials

Wi-Fi (802.11) is layer 1–2 over radio. The SSID is the network name; each access point radio has its own BSSID (a MAC). Clients choose and roam between APs themselves, which is why one laptop can "stick" to a distant AP.

• Bands: 2.4 GHz travels further through walls but is crowded (only channels 1, 6, 11 don't overlap); 5 GHz and 6 GHz (Wi-Fi 6E/7) are faster with shorter range.
• Signal (RSSI) is in negative dBm: about −50 is excellent, −67 is a common minimum target for voice and video, below −75 expect trouble. Noise and interference matter as much as raw signal.
• Security: WPA2/WPA3-Personal uses a shared passphrase; Enterprise uses 802.1X, where each user or device authenticates (password or certificate) to a RADIUS server. Enterprise Wi-Fi failures are often credentials, expired certificates, or a device not trusting the RADIUS server's certificate.
• Captive portals (hotels, guest Wi-Fi) give you an address but block traffic until you accept terms in a browser.

What an IP packet carries

The IP header holds source and destination addresses, a TTL (time to live, called hop limit in IPv6), the protocol inside (TCP = 6, UDP = 17, ICMP = 1), and fragmentation flags. IP is best effort: no guarantee of delivery or order. Reliability, if needed, comes from TCP above it.

Each router decrements TTL by one. If it reaches zero the packet is dropped and an ICMP "time exceeded" goes back to the sender. This stops packets looping forever, and traceroute is built on it.

Local or remote: the first decision

A host compares the destination with its own network using the mask. Example: laptop 10.1.4.20/22.

• A /22 mask is 255.255.252.0. The third-octet block size is 256 − 252 = 4, so networks start at 0, 4, 8, 12…
• 20's network is 10.1.4.0/22, covering 10.1.4.0 – 10.1.7.255.
• Destination 10.1.6.9: local, ARP for it directly. Destination 10.1.8.1: remote, send to the gateway.

If someone typed /24 instead, the laptop would think 10.1.6.9 is remote and send it to the gateway. Usually still works, oddly, but not always, which is what makes mask errors confusing.

Subnet math you can do in your head

Usable = total − 2 (the network address and the broadcast address). To find which block an address is in: block size = 256 − the interesting mask octet, then round down to a multiple of it. 192.168.5.77/26 → block 64 → network .64, broadcast .127, hosts .65–.126.

Routing tables and longest match

Every router (and your laptop) has a routing table: destination network → next hop or interface. Entries come from directly connected networks, static routes, and dynamic routing protocols. The default route 0.0.0.0/0 matches everything and is used when nothing more specific does.

When several routes match, the most specific (longest prefix) wins. A packet for 10.8.3.4 matches 0.0.0.0/0, 10.0.0.0/8 and 10.8.0.0/16; it goes via the /16. That rule is exactly how VPN clients steer company traffic into the tunnel while the rest goes out locally.

Inside organizations, routers share routes with protocols like OSPF; between ISPs, BGP carries the internet's routes. You won't configure them in a support role, but "a BGP issue at the provider" is a real explanation for a large regional outage.

ICMP: the network's error messages

• Echo request / reply (type 8 / 0): ping.
• Destination unreachable (type 3): with codes such as network unreachable, host unreachable, port unreachable, and fragmentation needed.
• Time exceeded (type 11): TTL hit zero; traceroute uses it.

Firewalls often drop ping, so no reply does not prove a host is down. Blocking all ICMP is a mistake: "fragmentation needed" messages drive Path MTU Discovery, and without them some connections hang on large packets (more in module 12).

VPNs: routing in disguise

When a VPN connects, it adds a virtual interface and routes. Full tunnel sends everything through the company. Split tunnel sends only company networks (say 10.0.0.0/8) through the tunnel and everything else directly.

A classic failure: the user's home network is 192.168.1.0/24 and the office file server is also in 192.168.1.0/24. The laptop treats the server as local and never sends it into the tunnel. Fix: company networks should avoid the common home ranges, or the VPN must push a more specific route.

Ports and the five-tuple

A port is a 16-bit number (0–65535). Servers listen on fixed, well-known ports; clients use a temporary ephemeral port picked by the OS (Windows uses 49152–65535 by default, Linux usually 32768–60999).

A connection is uniquely identified by five values: protocol, source IP, source port, destination IP, destination port. That's how one laptop can hold ten separate connections to the same server on 443: each has a different source port.

Ports worth knowing by heart

TCP: a reliable conversation

TCP opens with a three-way handshake: client sends SYN, server replies SYN-ACK, client sends ACK. Both sides now have starting sequence numbers.

• Sequence numbers and acknowledgements: every byte is numbered; the receiver says "I have everything up to byte N". Missing data is retransmitted.
• Flow control: the receiver advertises a window, how much it can accept right now, so a fast sender can't overwhelm a slow receiver.
• Congestion control: TCP starts slowly and speeds up until it sees loss or delay, then backs off. That's why one lossy Wi-Fi link makes downloads crawl, not just "lose a bit".
• Closing: each side sends FIN and the other acknowledges. A RST (reset) aborts a connection immediately.

Connection states you'll see in netstat: LISTEN, SYN_SENT (we asked, no answer yet), ESTABLISHED, TIME_WAIT (recently closed, normal), CLOSE_WAIT (the other side closed; our app hasn't. Lots of these means an app bug).

UDP: send and move on

UDP adds just ports, a length and a checksum to IP: no handshake, no acknowledgements, no retransmission, no ordering. If the application cares about loss, it handles it itself (DNS simply asks again after a timeout).

That's ideal when late data is useless: voice and video calls (RTP), online games, DNS lookups, DHCP, NTP, and QUIC, which rebuilds reliability on top of UDP for HTTP/3. A video call would rather skip 20 ms of audio than pause the whole conversation waiting for a resend.

Firewalls and NAT keep state

Stateful firewalls and NAT routers track connections. For TCP they see the handshake and the FIN. UDP has no "end", so the device keeps a mapping only for a timeout (often 30 s – a few minutes). When a VoIP phone stops sending keepalives and the mapping expires, incoming calls stop reaching it: one-way audio and "can call out but can't receive" tickets often trace back to this, or to SIP/NAT handling on the firewall.

Reading the error message

The namespace is a tree

Read a name from right to left: portal.corp.example.com. → the root (the invisible trailing dot) → the TLD com → the domain example.com → subdomains corp and portal. Each level can delegate the next level to other servers. Whoever runs example.com controls everything under it, without asking anyone.

Record types you'll meet

How a lookup actually happens

1. The application asks the OS. The OS checks its cache and the hosts file (C:\Windows\System32\drivers\etc\hosts, /etc/hosts).
2. If not found, the OS's stub resolver asks the DNS server it was configured with (from DHCP or VPN): a recursive resolver such as a domain controller, the router, the ISP, or a public service.
3. The recursive resolver, if it has nothing cached, walks the tree: asks a root server who handles .com, asks a .com server who handles example.com, asks that authoritative server for the actual record.
4. The answer comes back to the laptop, and every resolver along the way caches it for its TTL.

So "which DNS server am I using?" is always the first question: different resolvers can legitimately give different answers.

TTL, caching and "propagation"

Every record has a TTL in seconds. A resolver that cached portal → 203.0.113.10 with TTL 3600 will keep handing out that address for up to an hour, even if the record changed a minute later. That's what people call "DNS propagation": not a wave spreading, just caches expiring at different times. Admins lower the TTL a day before a planned migration to shorten this window.

Failures are cached too (negative caching). If someone looked up a name before it was created, that NXDOMAIN can stick for the zone's negative TTL.

Answers and what they mean

• NOERROR with an address: DNS worked. If the site still fails, look elsewhere.
• NXDOMAIN: the name doesn't exist (typo, record never created, wrong DNS suffix).
• NOERROR, no answer: the name exists but not that record type (e.g. no AAAA).
• SERVFAIL: the resolver couldn't get a valid answer: authoritative servers unreachable, or a DNSSEC validation failure.
• REFUSED / timeout: the resolver won't serve you or isn't reachable (firewall, wrong IP, down).

DNS inside companies

• Active Directory depends on DNS. Domain-joined PCs must use the company's DNS servers (usually domain controllers). Someone who sets 8.8.8.8 manually "to make the internet faster" breaks domain logon, Group Policy and file shares, because public DNS has never heard of corp.example.com.
• Split DNS / split-horizon: the same name resolves to an internal IP inside (or on VPN) and a public IP outside, or internal names exist only on internal servers.
• Search suffixes: typing just intranet works because the OS appends corp.example.com. Off VPN that suffix may be missing, so short names fail while full names work.
• Encrypted DNS: DNS over HTTPS (port 443) and DNS over TLS (853). A browser using its own DoH provider can bypass company DNS, so internal names fail only in that browser.

DNS and email deliverability

Three TXT-based records decide whether a company's email is trusted: SPF lists which servers may send for the domain, DKIM publishes a key to verify message signatures, and DMARC tells receivers what to do when those checks fail. A newly added marketing tool or scanner that sends "as" the company without being in SPF/DKIM is a typical reason messages land in spam or bounce.

Anatomy of a URL

https://portal.example.com:443/reports/q3?region=emea#totals
└─┬─┘   └───────┬────────┘ └┬┘ └────┬────┘ └────┬────┘ └──┬──┘
scheme        host        port    path       query    fragment

The port is implied (443 for https, 80 for http) unless written. The fragment after # never leaves the browser. It's used by the page itself.

A real request and response

GET /reports/q3?region=emea HTTP/1.1
Host: portal.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Cookie: session=7f3a...

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: private, max-age=0
Set-Cookie: session=7f3a...; Secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=31536000

<!doctype html> ...

A request is a method, a path, headers and sometimes a body. A response is a status code, headers and usually a body. The Host header lets one server/IP host many sites.

Methods and what they imply

• GET read something; HEAD same but headers only (what curl -I sends).
• POST submit/create (forms, logins, uploads).
• PUT / PATCH replace / partially update; DELETE remove. Common in APIs.
• OPTIONS used by browsers for CORS "preflight" checks before cross-site API calls.

Status codes: who is complaining?

Rule of thumb: 4xx = the request (who you are, what you asked for), 5xx = the server side. A 5xx is rarely fixed on the user's laptop.

Cookies, sessions and SSO

HTTP has no memory between requests. After you log in, the server sets a cookie (or the app stores a token) that the browser sends with every later request. Single sign-on (SAML, OpenID Connect) bounces the browser between the app and the identity provider with redirects, setting cookies on each domain.

That's why "clear cookies for this site" or "try a private window" fixes so many login loops: a stale or corrupt session cookie, or a browser setting that blocks the cookies the SSO flow needs. Clearing all browsing data is rarely necessary; target the affected sites.

Caching

Browsers, CDNs and proxies cache responses according to headers like Cache-Control, ETag and Age. After a site update, a user might keep getting old scripts. A hard reload (Ctrl+Shift+R, Cmd+Shift+R on Mac) bypasses the browser cache; a CDN cache needs the site owner to purge it.

HTTPS: TLS and certificates

HTTPS wraps HTTP in TLS, which provides encryption (no one on the path can read it), integrity (no one can alter it) and authentication (the server proves who it is with a certificate).

A certificate binds a public key to names (listed in the Subject Alternative Name field) and is signed by a certificate authority. The browser follows the chain: server certificate → intermediate → a root CA that's already in the device's trust store. It also checks the validity dates against the local clock.

• NET::ERR_CERT_DATE_INVALID: certificate expired, or the PC's clock/date is wrong.
• ERR_CERT_COMMON_NAME_INVALID: you went to a name the certificate doesn't list (e.g. by IP, or an old alias).
• ERR_CERT_AUTHORITY_INVALID: issuer not trusted: self-signed device page, missing intermediate, or a TLS-inspecting proxy whose root isn't installed.

Sites using HSTS don't allow clicking through the warning at all, which is deliberate.

HTTP versions

HTTP/1.1 handles one request at a time per connection, so browsers open several. HTTP/2 multiplexes many requests over one TLS connection. HTTP/3 runs over QUIC on UDP 443. Users don't choose; browsers negotiate. For support it matters mainly when a network blocks UDP 443 (HTTP/3 quietly falls back) or an old proxy mishandles HTTP/2.

TLS beyond the browser

TLS secures far more than websites: email (IMAPS 993, SMTP with STARTTLS on 587), LDAPS (636), VPNs, MQTT over TLS, RDP. Versions: TLS 1.2 and 1.3 are current; 1.0 and 1.1 are deprecated and disabled by modern clients, which is why very old devices (printers, scanners, legacy apps) suddenly "can't connect" after updates.

Mutual TLS (client certificates) is where the client also presents a certificate. It's used for 802.1X Wi-Fi, some VPNs and device-trust checks. An expired machine certificate shows up as "the laptop can't join Wi-Fi/VPN, but my phone can".

WebSocket: a connection that stays open

A WebSocket starts as an HTTP request carrying Upgrade: websocket. The server answers 101 Switching Protocols and the same TCP connection becomes a two-way message channel (ws://, or wss:// over TLS). Chat apps, live dashboards, trading screens, collaborative editors and notification systems use it.

What breaks it: proxies or firewalls that don't support the upgrade, or that cut "idle" connections after a timeout. The page loads fine (that part is normal HTTP) but nothing updates live. Server-Sent Events (a long-lived one-way HTTP response) is a simpler cousin with similar failure modes.

MQTT: publish/subscribe for devices

MQTT is a small protocol for IoT: sensors, building systems, industrial equipment. Devices keep a TCP connection to a broker. A publisher sends a message to a topic like site1/lab/temp; the broker forwards it to every client subscribed to that topic. Publishers and subscribers never talk directly.

• Ports: 1883 plain, 8883 TLS (sometimes WebSocket on 443).
• QoS levels 0 (at most once), 1 (at least once), 2 (exactly once) trade reliability for overhead.
• Retained messages give new subscribers the last known value; a last will message announces when a device disconnects unexpectedly.

"Device shows offline" often means its outbound 8883 is blocked on a new network, or its certificate expired.

QUIC and HTTP/3

QUIC runs over UDP 443 and builds in what TCP + TLS do separately: reliable streams, encryption and a faster handshake. One lost packet only stalls its own stream, and connections can survive a change of network (Wi-Fi to mobile). Browsers try HTTP/3 and fall back to TCP if UDP 443 is blocked, so it rarely causes outright failures; some firewalls deliberately block it so they can inspect traffic over TCP.

gRPC and APIs

Many internal services talk REST (JSON over HTTPS) or gRPC (binary messages over HTTP/2). They matter in support mostly through proxies: a proxy that downgrades to HTTP/1.1 breaks gRPC. Recognize the name, pass it to the right team.

Office infrastructure protocols

Forward proxy: speaking for the users

Companies route web traffic through a forward proxy (on-premises, or a cloud "secure web gateway") to:

• filter by category or reputation (block malware and phishing sites, sometimes social media);
• log who went where, for security investigations and compliance;
• control egress: only the proxy is allowed out to the internet, so malware on a PC can't connect directly;
• give the company one predictable exit IP, which partners and SaaS tenants can allowlist;
• historically, cache common content (much less useful now that almost everything is HTTPS).

An explicit proxy is configured on the device (browser/OS settings, PAC file, or environment variables). A transparent or intercepting proxy is placed in the network path and grabs traffic without any client setting. The user may not know it exists at all.

How an explicit proxy handles HTTP and HTTPS

For plain http://, the browser sends the full URL to the proxy and the proxy fetches it:

GET http://intranet-old.example.com/news HTTP/1.1
Host: intranet-old.example.com

For https://, the browser asks the proxy to open a raw tunnel, then runs TLS through it end to end:

CONNECT portal.example.com:443 HTTP/1.1
Host: portal.example.com:443

HTTP/1.1 200 Connection established
(TLS handshake and encrypted HTTP now pass through the tunnel)

Without inspection, the proxy only learns the hostname and port (from CONNECT, plus the SNI field in the TLS hello) and how many bytes moved, not the pages or contents. Common proxy ports are 8080, 3128 and 80, but it's whatever the company chose.

Proxy authentication and 407

A proxy that needs to know who you are replies 407 Proxy Authentication Required. On domain-joined Windows machines this is usually invisible: the browser answers with the user's Windows logon via Kerberos or NTLM ("integrated authentication"). Cloud gateways often use an agent on the laptop or SSO instead.

When it isn't invisible, users see repeated username/password pop-ups, or command-line tools fail with "407". Typical causes: the device isn't domain-joined, the user's password changed and a cached credential is stale, or the tool simply doesn't support integrated auth.

How devices learn about the proxy: manual, PAC, WPAD

• Manual: a host and port (proxy.corp.example.com:8080) plus a bypass list of addresses that should go direct.
• PAC file: a small JavaScript file at a URL (e.g. http://pac.corp.example.com/proxy.pac) that the browser runs for every request to decide which proxy, if any, to use.
• WPAD: automatic discovery of the PAC file via DHCP option 252 or the DNS name wpad.<your-domain>. Convenient, but if a network lets an attacker answer for wpad, they can redirect traffic, so many companies push an explicit PAC URL through policy instead.

A PAC file returns a string such as "PROXY proxy.corp.example.com:8080; DIRECT", a list tried in order. DIRECT means no proxy.

A PAC file, read line by line

function FindProxyForURL(url, host) {
  // 1. Plain host names (no dots) and internal domains go direct
  if (isPlainHostName(host) || dnsDomainIs(host, ".corp.example.com"))
    return "DIRECT";
  // 2. Private address ranges go direct
  if (isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))
    return "DIRECT";
  // 3. Real-time media should not be proxied
  if (shExpMatch(host, "*.media.example-meetings.com"))
    return "DIRECT";
  // 4. Everything else: proxy A, then proxy B, then give up
  return "PROXY proxy-a.corp.example.com:8080; PROXY proxy-b.corp.example.com:8080";
}

Two support lessons hide in there. First, if the PAC URL itself can't be downloaded (VPN down, DNS issue), browsers behave differently: some go direct, some fail. Second, a missing bypass rule sends an internal site to the proxy, which can't reach it, so the user sees a proxy error page for an internal URL. Note that isInNet() resolves names through DNS, so a slow DNS server makes every page load slow.

One machine, several proxy settings

It surprises people that "the proxy setting" isn't one setting:

• Windows has the user-level setting (Settings → Network → Proxy, a.k.a. WinINET) used by browsers and most apps, and a separate WinHTTP setting used by system services and some agents. A browser that works while Windows Update, an EDR agent or a sync service fails is a classic WinHTTP gap. netsh winhttp show proxy reveals it.
• macOS stores proxies per network service (Wi-Fi vs Ethernet can differ).
• Command-line tools (curl, git, pip, npm, Docker) usually read HTTPS_PROXY, HTTP_PROXY and NO_PROXY environment variables, or their own config files, and ignore the OS setting.
• Java, some Electron apps and older line-of-business apps have their own proxy fields.

Reverse proxy: speaking for the servers

A reverse proxy receives requests from the internet for www.example.com and passes them to backend servers that are never exposed directly. nginx, HAProxy, Apache httpd, IIS with ARR, cloud load balancers (AWS ALB, Azure Application Gateway) and CDNs such as Cloudflare all act as reverse proxies. They typically:

• terminate TLS: the public certificate lives here;
• route by host name or path (/api to the API servers, / to the web servers);
• load balance and health-check backends;
• cache, compress, rate-limit, and filter attacks (a WAF);
• add headers such as X-Forwarded-For so the backend knows the real client IP, since otherwise every request seems to come from the proxy.

When a user hits an error page, its look often tells you which layer produced it: a CDN-branded page, a plain "nginx" page, or the application's own styled error each point to a different team.

502, 503, 504: errors made by the middleman

These codes are usually generated by the proxy, describing its conversation with the server behind it:

• 502 Bad Gateway: the proxy couldn't get a valid response: backend refused the connection, crashed mid-response, returned garbage, or the TLS connection from proxy to backend failed.
• 504 Gateway Timeout: the backend accepted the request but didn't answer before the proxy's timer ran out (slow query, overloaded app, firewall silently dropping between proxy and backend).
• 503 Service Unavailable: the proxy or app deliberately refused: maintenance mode, overload protection, or no healthy backends left in the pool.

The user's laptop is almost never the cause. Useful facts for the escalation: exact URL, time with timezone, whether it's every request or intermittent, which error page/branding appeared, and any request ID shown on it.

TLS inspection (break and inspect)

Without inspection, a forward proxy can't see inside HTTPS. With TLS inspection it acts as a deliberate, authorized man-in-the-middle: it terminates the user's TLS session using a certificate it generates on the fly for portal.example.com, signed by the company's own inspection CA, then opens a second, genuine TLS session to the real site. It can now scan downloads and enforce data-loss rules.

This only works if the device trusts the company CA. Managed browsers do (the root is pushed by Group Policy or MDM). Things that keep their own trust store don't: Python (certifi), Java keystores, Node.js, git, some Electron apps, Docker. They fail with errors like unable to get local issuer certificate or PKIX path building failed. Apps that pin certificates refuse inspection entirely and need a bypass. Companies also commonly exempt categories such as banking and healthcare for privacy reasons.

How to spot it: view the certificate in the browser. If the issuer is something like "Corp Inspection CA" rather than a public CA, the traffic is being inspected.

Proxy, VPN, NAT, SOCKS: telling them apart

What a socket is

A socket is identified by protocol, local IP and local port. A TCP connection is the pair of both ends (the five-tuple from module 5). The server's single listening socket on :443 spawns a new connected socket for each client, which is how one web server handles thousands of clients on the same port.

Server lifecycle: socket → bind → listen → accept

1. socket(): ask the OS for an endpoint (TCP or UDP, IPv4 or IPv6).
2. bind(): claim a local address and port, e.g. 0.0.0.0:8443. Fails with "address already in use" if someone else has it.
3. listen(): start queuing incoming connection attempts.
4. accept(): take the next waiting connection and get a new socket for that client.

The client side is shorter: socket() then connect() to the server's IP and port. The OS picks an ephemeral source port automatically.

Where it listens matters: 127.0.0.1 vs 0.0.0.0

• 127.0.0.1:8080: only programs on the same machine can connect. Other PCs get "connection refused".
• 0.0.0.0:8080 (or [::]:8080 for IPv6): all interfaces; reachable from the network if the firewall allows.
• 10.40.2.15:8080: only via that one interface's address.

"It works on the server itself but not from my PC" is very often a service bound to localhost, or the host firewall (Windows Defender Firewall's "allow this app?" prompt answered "no").

Ports collide

Only one process can listen on a given IP + port + protocol. Two apps that both want 8080, or a crashed service that left a zombie process holding its port, produce "address already in use" / "port is already allocated". Find the owner (commands below), then decide which to stop or reconfigure.

TIME_WAIT, CLOSE_WAIT and running out of ports

After a TCP connection closes, the side that closed first keeps it in TIME_WAIT for a short period. That's normal. But a busy client opening and closing thousands of short connections per minute to the same server can run out of ephemeral ports ("port exhaustion"): new connections then fail intermittently, a pattern seen on middleware, proxies and badly written integrations.

A growing pile of CLOSE_WAIT on a server means the remote side closed but the application never closed its end: an application bug (leaked sockets), not a network issue.

Other kinds of socket

UDP sockets have no connection: the app just sends and receives datagrams on a port. Unix domain sockets (and Windows named pipes) let processes on one machine talk without the network, e.g. Docker's /var/run/docker.sock. TLS is a layer the application adds on top of a TCP socket.

A method, not a guess

A structured approach (similar to the methodology CompTIA teaches) keeps you from jumping around:

1. Identify the problem: exact symptom, who's affected, since when, what changed.
2. Theorize: list likely causes, simplest and most common first.
3. Test the theory with a command or swap; if wrong, go back to 2.
4. Plan and fix, considering impact (don't reboot a switch at 10:00 on a Monday).
5. Verify it works for the user, end to end, and prevent recurrence if you can.
6. Document what you found and did.

ping, and what it really tells you

ping sends ICMP echo requests. Read three things: whether replies arrive, the time (latency) and its variation, and the loss percentage at the end. Run it for longer than four packets when diagnosing intermittent problems (ping -t on Windows, plain ping elsewhere; stop with Ctrl+C). The ttl= in replies is the remaining hop count, not the latency.

traceroute, pathping and mtr

Traceroute sends probes with TTL 1, 2, 3… and lists who replies "time exceeded". Windows tracert uses ICMP; macOS/Linux traceroute uses UDP by default (-I for ICMP, -T on Linux for TCP). Use -d/-n to skip slow reverse lookups.

Read it like module 4's example: silent hops are fine if later hops answer; a latency increase only matters if it persists to the end. pathping (Windows) and mtr combine traceroute with sustained loss statistics per hop, much better evidence for an ISP ticket.

The rest of the everyday toolkit

• ipconfig / ifconfig / ip: addresses, gateway, DNS (module 2).
• nslookup / dig / Resolve-DnsName: DNS (module 6).
• arp -a / ip neigh: who's on the local segment (module 3).
• netstat / ss / Get-NetTCPConnection: connections and listeners (module 10).
• Test-NetConnection / nc: one TCP port (module 5).
• curl: HTTP(S), headers, TLS, proxies, timings (modules 7, 9, 13). Built into Windows 10+ as curl.exe.
• Built-in reports: netsh wlan show wlanreport (Windows Wi-Fi history), Wireless Diagnostics (macOS), Network Reset (Windows) as a last resort.

Packet capture: seeing the actual conversation

When commands disagree with the user's experience, capture the packets. Wireshark is the standard GUI; tcpdump works on macOS/Linux; Windows has the built-in pktmon. Capture on the affected machine, reproduce once, stop, then analyze.

Two kinds of filter: a capture filter limits what is recorded (BPF syntax: host 10.40.2.15 and port 443); a display filter hides what you don't want to look at afterwards (Wireshark syntax):

Reading common patterns

• SYN, SYN, SYN, nothing back: something drops the traffic (firewall, wrong IP). Matches "timed out".
• SYN then RST from server: port closed. Matches "refused".
• Handshake, Client Hello, then RST or alert: TLS problem (version, inspection, certificate).
• Many retransmissions and duplicate ACKs: loss on the path, often Wi-Fi.
• DNS query with no response, then retry to a second server: slow or dead first resolver, a hidden cause of "slow internet".

Right-click a packet → Follow → TCP Stream to see one conversation on its own.

Ethics and privacy

Only capture on devices and networks you're authorized to inspect, ideally with the user aware. Captures can contain passwords on legacy plain-text protocols, session cookies and personal data. Store them as sensitive and delete them when the ticket closes.

Five numbers, five meanings

Rough targets for good voice/video, commonly cited from ITU guidance and vendor docs: one-way latency under ~150 ms, jitter under ~30 ms, loss under ~1%.

Where latency comes from

Light in fiber travels about 200 km per millisecond. Los Angeles to London is roughly 8,800 km in a straight line, so even a perfect path costs ~45 ms each way, ~90 ms round trip, and real routes are longer. No bandwidth upgrade changes physics. On top of distance come queuing (waiting in busy router buffers), processing (firewalls, inspection proxies, VPN encryption) and the last link (Wi-Fi retries can add tens of milliseconds).

A VPN that sends a user in Istanbul through a concentrator in California before reaching a server in Frankfurt adds a huge detour. Split tunnelling or a nearer VPN gateway fixes that, not more bandwidth.

Why loss is worse than it sounds

TCP treats loss as a sign of congestion and slows down. A link with just 1–2% loss can cut a single download's throughput dramatically, and the further away the server, the worse the effect, because recovery takes round trips. That's why "fast speed test, but file copies to the other office crawl" is a real combination: the speed test uses many parallel connections to a nearby server.

Wi-Fi: the usual suspect

• Signal and distance: weaker signal → lower data rate → more airtime per packet.
• Shared airtime: Wi-Fi is a shared medium; one slow, distant client uses more air and slows everyone on that AP.
• Interference and channel overlap: neighboring networks, microwaves, Bluetooth on 2.4 GHz.
• Sticky clients: a laptop that stays associated to a far AP instead of roaming.

The single most useful test: run the same measurement wired. If wired is fine, it's the Wi-Fi.

Congestion, bufferbloat and QoS

When a link is full, routers queue packets. Oversized queues (bufferbloat) make latency soar whenever someone uploads a big file: calls stutter "every time Bob's backup runs". Test it with a latency measurement during a speed test (many speed tests now report "loaded latency"; macOS has networkQuality).

QoS marks and prioritizes traffic (voice is commonly marked DSCP EF / 46) so calls go first when the link is busy. It only helps where the network is configured to honor the markings, typically inside a company WAN, not across the public internet.

MTU and fragmentation

Ethernet's MTU is 1500 bytes. VPNs and some tunnels add headers, shrinking what fits. If a packet is too big and the "don't fragment" flag is set, a router should reply with ICMP "fragmentation needed". When firewalls block that, connections hang on large transfers while small requests work: the login page loads, the report download stalls. Test with the DF ping from module 4; fixes are on the network side (MSS clamping, allowing ICMP) or lowering the VPN adapter MTU.

Not the network at all

Plenty of "slow network" tickets are the endpoint or the server: a laptop pegged at 100% CPU by an update or scan, a full disk, an overloaded SaaS tenant, a slow DNS resolver adding a second to every new hostname, or a browser with dozens of extensions. A curl timing breakdown (module 13) shows whether time is spent in DNS, connecting, TLS, or waiting for the server.

Load balancers

A load balancer spreads requests across a pool of identical servers and continuously health-checks them, removing any that fail. Layer 4 balancers work on TCP/UDP connections; layer 7 balancers understand HTTP and can route by host or path (they're reverse proxies, module 9). Common algorithms: round robin, least connections, or hashing on the client.

Sticky sessions keep a user on the same server. When a sticky server is pulled out, those users may be logged out or lose a half-filled form, which explains "it kicked me out, then worked when I logged back in".

CDNs and caching at the edge

A content delivery network keeps copies of static content (images, scripts, video, software updates) at edge locations near users and forwards the rest to the origin. Benefits: speed, less load on the origin, and absorbing attacks. Side effects you'll see: users in different cities getting different versions until caches expire, and a CDN-branded error page when the origin behind it is down.

Response headers tell you what happened: Age, and vendor headers such as x-cache: HIT or cf-cache-status: HIT.

Getting users to the nearest place: GeoDNS and anycast

GeoDNS answers the same name with different IPs depending on where the request seems to come from (usually the resolver's location). Anycast announces the same IP address from many locations, and internet routing delivers you to the closest one. That's how 1.1.1.1 or a CDN IP is "everywhere". Consequence: a user whose DNS resolver is far away (e.g. corporate DNS in another country, or a VPN) may be sent to a distant edge and get slower service than colleagues.

Regions, zones and replication

Cloud providers group data centers into regions (geographic areas) and availability zones (separate facilities within a region). Services replicate data between them. Replication across distance takes time, so some systems are eventually consistent: a change saved in one place appears elsewhere a few seconds later. "I added the user but they can't see the shared folder yet" is often this, or a scheduled sync (e.g. directory sync running every 30 minutes).

Dependencies and cascading failures

Modern apps call many other services. If the identity provider (Entra ID, Okta, Google) has an outage, every SSO app fails at login while sessions already open keep working: the "nobody can log in, but people already in are fine" pattern. Internal services use timeouts, retries and circuit breakers; when retries pile up, a small slowdown can grow into a wide outage. Rate limiting (429) protects services from that.

Is it us or them?

1. Status pages: the vendor's official status page and the admin-center service health. Not always instant, but check first.
2. Change the network: try a phone hotspot. Works there → our network/proxy/ISP path; fails there too → likely the service or the account.
3. Change the user/device: another account on the same machine, same account on another machine.
4. Compare locations: other offices, VPN vs not, different DNS resolver (which may route to a different edge).

What to put in an escalation

Vendors and platform teams can't search "it's broken". They need: exact error text or screenshot; time with timezone; user, tenant or account; location and network (office, ISP, VPN); what you already ruled out; and any request / correlation / trace ID shown on the error page or in DevTools response headers. Those IDs let an engineer find the exact failed request in their logs.