Computer-Fundamentals/archive/networking.md

# Networking Interview Guide For Software Engineers

This guide is meant for interview preparation, not just memorization. The goal is to help you explain how traffic moves through systems, why protocols were designed the way they were, and what tradeoffs show up in production.

## How To Study Networking For Interviews

Treat networking as three linked layers of understanding:

1. Protocol model: what each layer is responsible for.
2. Request lifecycle: what happens from client to server and back.
3. Production systems: what breaks, what gets cached, what gets retried, and what gets secured.

If you can answer all three for a topic, you usually understand it well enough for interviews.

## Big Picture: What Happens When You Open A URL?

When a browser requests `https://api.example.com/users`, a lot happens under the hood:

1. The browser parses the URL and extracts the scheme, hostname, path, and port.
2. DNS resolves `api.example.com` to an IP address.
3. The client decides where to send the packet, usually to a default gateway if the server is outside the local subnet.
4. A TCP connection is established to the server, often on port `443`.
5. A TLS handshake happens to create an encrypted session.
6. The browser sends an HTTP request over that secure connection.
7. Load balancers, proxies, firewalls, and application servers may inspect or forward the request.
8. The server sends back an HTTP response.
9. The browser may cache content, reuse the connection, or make additional requests.

```mermaid
flowchart LR
	A[Browser or Client] --> B[DNS Resolver]
	B --> C[IP Address Returned]
	C --> D[TCP Handshake]
	D --> E[TLS Handshake]
	E --> F[Load Balancer or Reverse Proxy]
	F --> G[Application Service]
	G --> H[Database or Cache]
	H --> G
	G --> F
	F --> E
	E --> A
```

This single flow touches most of the topics interviewers care about.

## OSI 7-Layer Model

The OSI model is a conceptual framework. Real networks do not literally say "now we are in layer 5," but the model is useful because it separates responsibilities.

| Layer | Name | What It Does | Real Examples |
| --- | --- | --- | --- |
| 7 | Application | User-facing network services | HTTP, DNS, SMTP |
| 6 | Presentation | Data representation, encoding, encryption | TLS, JSON, JPEG |
| 5 | Session | Session establishment and management | RPC sessions, NetBIOS |
| 4 | Transport | End-to-end delivery between processes | TCP, UDP |
| 3 | Network | Routing between networks | IP, ICMP |
| 2 | Data Link | Delivery within the local network | Ethernet, MAC, ARP |
| 1 | Physical | Actual electrical, radio, or optical transmission | Cables, Wi-Fi radio |

### How To Explain Each Layer In Practice

#### Layer 7: Application

This is where application protocols live. If someone says "HTTP request," they are talking about an application-layer protocol. DNS also lives here because it provides a service used by applications.

Interview angle: if an API returns `404`, `500`, or malformed JSON, that is usually an application-layer issue, not a routing issue.

#### Layer 6: Presentation

This layer is about representation. Encryption, compression, and serialization belong here conceptually. In the real world, TLS is often described here because it transforms readable data into encrypted bytes.

Interview angle: when asked why HTTPS exists, explain that application data is wrapped in TLS before it is sent on the transport connection.

#### Layer 5: Session

The session layer is less visible in day-to-day backend work, but the idea still matters. It manages ongoing communication state: establishing sessions, keeping them alive, resuming them, and closing them.

In modern systems, session responsibilities are often spread across libraries and protocols rather than called out separately.

#### Layer 4: Transport

This is where TCP and UDP live. The transport layer gives process-to-process communication, meaning it is not just machine A to machine B, but application process on port X to process on port Y.

Interview angle: if packets arrive but the application still times out, transport details like retransmissions, congestion, socket backlog, or connection exhaustion might matter.

#### Layer 3: Network

This layer is responsible for logical addressing and routing. IP addresses live here. Routers examine layer 3 information to move packets across networks.

Interview angle: if two services are in different networks or subnets, layer 3 determines how traffic gets routed between them.

#### Layer 2: Data Link

This is communication on the local link. Devices here care about MAC addresses. Switches mainly operate here. ARP maps IP addresses to MAC addresses on IPv4 local networks.

Interview angle: when traffic stays inside a LAN, layer 2 behavior matters. When traffic leaves the LAN, a router is usually involved.

#### Layer 1: Physical

The physical layer is the raw transmission medium. It carries bits as electrical signals, light, or radio waves.

Interview angle: higher-level developers do not work here much, but it explains why distance, cable quality, radio interference, and bandwidth constraints are real.

### Encapsulation

As data moves down the stack, each layer adds its own header.

```mermaid
flowchart TD
	A[Application Data] --> B[Transport Segment: TCP or UDP Header + Data]
	B --> C[Network Packet: IP Header + Segment]
	C --> D[Data Link Frame: MAC Header + Packet]
	D --> E[Bits On Wire or Air]
```

Interview answer worth memorizing: each lower layer treats the entire payload from the layer above as data.

## TCP/IP Model

The TCP/IP model is more practical and maps better to the Internet.

| TCP/IP Layer | Rough OSI Mapping | Purpose |
| --- | --- | --- |
| Application | OSI 5, 6, 7 | User-visible protocols and data formats |
| Transport | OSI 4 | End-to-end process communication |
| Internet | OSI 3 | Routing with IP |
| Link or Network Access | OSI 1, 2 | Local network delivery |

```mermaid
flowchart LR
	A[OSI 7 Application] --> T1[TCP/IP Application]
	B[OSI 6 Presentation] --> T1
	C[OSI 5 Session] --> T1
	D[OSI 4 Transport] --> T2[TCP/IP Transport]
	E[OSI 3 Network] --> T3[TCP/IP Internet]
	F[OSI 2 Data Link] --> T4[TCP/IP Link]
	G[OSI 1 Physical] --> T4
```

### Why Interviewers Ask About Both Models

They want to know whether you can:

1. Use OSI for reasoning and categorization.
2. Use TCP/IP for real Internet systems.
3. Explain where a specific technology belongs.

If asked which model is more "real," say TCP/IP. If asked which model is more useful for teaching, say OSI is often better.

## TCP Vs UDP

This is one of the most common interview topics because it is about tradeoffs.

| Property | TCP | UDP |
| --- | --- | --- |
| Connection model | Connection-oriented | Connectionless |
| Reliability | Reliable delivery with retransmission | No built-in reliability |
| Ordering | Preserves order | No guaranteed order |
| Flow control | Yes | No |
| Congestion control | Yes | No built-in congestion control |
| Overhead | Higher | Lower |
| Typical use cases | Web, APIs, databases, SSH | DNS, streaming, gaming, VoIP |

### TCP

TCP provides a reliable byte stream. That means the application reads a stream of bytes, not individual packets. TCP handles:

1. Three-way handshake for connection setup.
2. Sequence numbers for ordering.
3. Acknowledgments for successful receipt.
4. Retransmission of lost segments.
5. Flow control so the receiver is not overwhelmed.
6. Congestion control so the network is not flooded.

Three-way handshake:

```mermaid
sequenceDiagram
	participant C as Client
	participant S as Server
	C->>S: SYN
	S->>C: SYN-ACK
	C->>S: ACK
```

Key point: TCP is reliable, but not magical. It can still time out, stall, or back off under congestion.

### UDP

UDP is a lightweight datagram protocol. It sends discrete messages with minimal built-in guarantees. That makes it faster in some cases, but the application must tolerate loss, duplication, or reordering.

Real-world point: many modern protocols use UDP because they want low latency and implement reliability selectively at the application layer. QUIC is the best modern example.

### Interview-Ready Tradeoff

If asked "Why not always use UDP because it is faster?" the right answer is that many applications need reliable ordered delivery, and reimplementing all of TCP behavior in every application would be complex and error-prone.

If asked "Why not always use TCP?" the answer is that strict ordering and retransmission can increase latency, which is a bad fit for real-time media or interactive gaming.

## Ports, Sockets, And Connections

### Ports

A port identifies a process or service on a host. The IP address identifies the machine, and the port identifies which application on that machine should receive the traffic.

Common well-known ports:

| Port | Protocol / Service |
| --- | --- |
| 20/21 | FTP |
| 22 | SSH |
| 25 | SMTP |
| 53 | DNS |
| 80 | HTTP |
| 123 | NTP |
| 143 | IMAP |
| 443 | HTTPS |
| 3306 | MySQL |
| 5432 | PostgreSQL |

### Sockets

A socket is an endpoint for communication. In practice, people often use the term to mean the OS abstraction used by programs to send and receive network data.

For a TCP connection, it is often identified by a 4-tuple:

1. Source IP
2. Source port
3. Destination IP
4. Destination port

That is how a server can support many simultaneous client connections on the same listening port.

### Connections

TCP has connections. UDP does not require a connected session in the same sense, even though programming APIs sometimes let you call `connect()` on a UDP socket for convenience.

Interview angle: if a server is "listening on port 443," that means it has a listening socket waiting for new connections. After accept, each client gets a separate established connection.

## IP Addressing

IP addresses identify network interfaces in an IP network. They are logical addresses, not hardware addresses.

### IPv4

IPv4 uses 32-bit addresses, usually written as four decimal octets, such as `192.168.1.10`.

Important private IPv4 ranges:

| Range | Purpose |
| --- | --- |
| 10.0.0.0/8 | Private network |
| 172.16.0.0/12 | Private network |
| 192.168.0.0/16 | Private network |
| 127.0.0.0/8 | Loopback |

Why private IPs matter: devices with private IPs are not directly routable on the public Internet. They usually reach the Internet through NAT.

### IPv6

IPv6 uses 128-bit addresses, written in hexadecimal, such as `2001:0db8:85a3:0000:0000:8a2e:0370:7334`.

Benefits of IPv6:

1. Vast address space.
2. Reduced need for NAT.
3. Cleaner support for auto-configuration and modern routing.
4. Better long-term scalability.

Compressed IPv6 notation removes leading zeros and can shorten one run of zeros with `::`.

Example:

`2001:0db8:0000:0000:0000:ff00:0042:8329`

can become:

`2001:db8::ff00:42:8329`

### Subnetting Basics

Subnetting divides a network into smaller networks. CIDR notation tells you how many bits belong to the network prefix.

Examples:

1. `/24` means 24 bits are network bits, leaving 8 bits for hosts.
2. `192.168.1.0/24` covers `192.168.1.0` through `192.168.1.255`.
3. A `/24` usually gives 256 total addresses, though usable host counts depend on context.

Quick mental model:

| CIDR | Total Addresses | Common Use |
| --- | --- | --- |
| /24 | 256 | Small subnet |
| /25 | 128 | Split a /24 into two |
| /26 | 64 | Smaller service segment |
| /32 | 1 | Single host route |

Real-world interview point: subnetting is about grouping addresses for routing and isolation, not just address counting.

### Default Gateway

If a host wants to reach an IP outside its local subnet, it sends traffic to the default gateway, which is usually a router.

This is a common practical question: "How does a machine know whether to send directly or to the router?" It compares the destination IP against its subnet mask.

## DNS

DNS maps human-friendly names to machine-usable records.

Common record types:

| Record | Purpose |
| --- | --- |
| A | Hostname to IPv4 |
| AAAA | Hostname to IPv6 |
| CNAME | Alias to another name |
| MX | Mail server |
| TXT | Arbitrary text, verification, SPF, DKIM |
| NS | Authoritative name server |

### DNS Resolution Flow

```mermaid
sequenceDiagram
	participant U as User Device
	participant R as Recursive Resolver
	participant Root as Root DNS
	participant TLD as TLD Server
	participant Auth as Authoritative DNS
	U->>R: Query api.example.com
	R->>Root: Where is .com?
	Root->>R: Ask .com TLD
	R->>TLD: Where is example.com?
	TLD->>R: Ask authoritative server
	R->>Auth: Where is api.example.com?
	Auth->>R: A or AAAA record
	R->>U: Cached answer returned
```

### Important Interview Points About DNS

1. DNS is hierarchical and distributed.
2. Resolvers cache answers for performance.
3. DNS is not just one server; it is a chain of delegated authority.
4. DNS can fail due to bad records, TTL delays, resolver issues, or propagation lag.

### TTL

TTL, or time to live, tells resolvers how long they may cache a record. A low TTL makes changes propagate faster but increases DNS lookup load. A high TTL reduces lookup traffic but slows rollout changes.

### Practical Scenario

If a service moves to a new IP and some users still hit the old server, DNS caching is one of the first suspects.

## HTTP Vs HTTPS

HTTP is an application protocol for request-response communication. HTTPS is HTTP carried over TLS, which provides encryption, integrity, and server authentication.

| Feature | HTTP | HTTPS |
| --- | --- | --- |
| Encryption | No | Yes, via TLS |
| Integrity | Weak, data can be modified in transit | Protected by TLS |
| Authentication | No built-in server identity | Certificates authenticate server identity |
| Default Port | 80 | 443 |

### Why HTTPS Matters

Without HTTPS, anyone on the path can potentially read or modify traffic. That includes credentials, tokens, cookies, and application data.

With HTTPS:

1. The client verifies the server certificate.
2. A secure session key is negotiated.
3. Data is encrypted in transit.
4. Tampering becomes detectable.

### Important Clarification

HTTPS does not hide everything. Observers may still see:

1. Destination IP address.
2. The fact that a TLS connection exists.
3. Timing and traffic volume.
4. In some cases, hostname metadata depending on protocol features and environment.

### HTTP Methods

Common methods and their intent:

| Method | Typical Meaning |
| --- | --- |
| GET | Read resource |
| POST | Create or trigger processing |
| PUT | Replace resource |
| PATCH | Partially update resource |
| DELETE | Remove resource |

### Status Codes Worth Knowing

| Range | Meaning |
| --- | --- |
| 1xx | Informational |
| 2xx | Success |
| 3xx | Redirection |
| 4xx | Client error |
| 5xx | Server error |

Commonly discussed codes: `200`, `201`, `204`, `301`, `302`, `304`, `400`, `401`, `403`, `404`, `409`, `429`, `500`, `502`, `503`, `504`.

### Keep-Alive And Connection Reuse

Opening a new TCP and TLS session for every request is expensive. Modern clients reuse connections when possible. This reduces handshake overhead and latency.

### HTTP/1.1, HTTP/2, And HTTP/3

You do not always need deep protocol internals for interviews, but these are worth knowing:

1. HTTP/1.1 commonly uses persistent connections but has more request multiplexing limitations.
2. HTTP/2 multiplexes streams over one TCP connection, reducing some head-of-line issues at the HTTP layer.
3. HTTP/3 runs over QUIC on UDP, improving connection setup and transport behavior.

## SSL/TLS Basics

Strictly speaking, SSL is old and obsolete; modern systems use TLS. In interviews, people still say "SSL certificate" informally, but the actual protocol is TLS.

### What TLS Provides

1. Confidentiality: traffic is encrypted.
2. Integrity: tampering is detectable.
3. Authentication: the client can verify the server's identity.

### Simplified TLS Handshake

```mermaid
sequenceDiagram
	participant C as Client
	participant S as Server
	C->>S: ClientHello
	S->>C: ServerHello + Certificate
	C->>S: Key Exchange Material
	Note over C,S: Shared session keys derived
	C->>S: Encrypted HTTP request
	S->>C: Encrypted HTTP response
```

### Certificates

A certificate binds a public key to a domain identity. Certificate authorities, or CAs, sign certificates so clients can trust them.

If a certificate is expired, signed by an untrusted CA, or does not match the hostname, clients will reject or warn about the connection.

### Interview Pitfall

TLS secures data in transit, not data at rest. Encrypting database traffic with TLS does not automatically encrypt the database files on disk.

## REST APIs

REST is an architectural style, not a wire protocol. It usually rides on HTTP, but the important idea is resource-oriented design and stateless client-server interaction.

### Core REST Ideas

1. Resources are identified by URLs.
2. Standard HTTP methods express intent.
3. Requests should be stateless, meaning the server should not rely on hidden per-client session state for each call.
4. Representations like JSON are sent over HTTP.
5. Caching can improve scalability.

### Good REST Thinking

Prefer resource-based endpoints like:

`GET /users/123`

instead of action-heavy endpoints like:

`POST /getUserById`

That said, real APIs often mix purity with practicality.

### Idempotency

This topic comes up often.

An operation is idempotent if doing it multiple times has the same effect as doing it once.

1. `GET` should be idempotent.
2. `PUT` is usually designed to be idempotent.
3. `DELETE` is usually considered idempotent if repeated deletes do not further change state.
4. `POST` is not usually idempotent.

Why it matters: retries are common in distributed systems. Idempotent operations are safer to retry.

### Authentication And Authorization In APIs

REST itself does not define auth. Real systems commonly use:

1. Bearer tokens
2. API keys
3. Session cookies
4. OAuth flows

Know the difference:

1. Authentication answers who you are.
2. Authorization answers what you are allowed to do.

## Load Balancers, Proxies, And Gateways

These terms are related but not interchangeable.

### Load Balancer

A load balancer distributes traffic across multiple backend servers.

Goals:

1. Higher availability.
2. Better scalability.
3. Health-based routing.
4. Sometimes TLS termination.

Two common types:

| Type | Operates Mainly At | Example Decisions |
| --- | --- | --- |
| Layer 4 LB | Transport | Route by IP and port |
| Layer 7 LB | Application | Route by host, path, headers |

Practical example: a layer 7 load balancer can send `/images/*` to one service and `/api/*` to another.

### Forward Proxy

A forward proxy sits between client and Internet. Clients intentionally send requests to it.

Uses:

1. Outbound filtering.
2. Privacy or identity masking.
3. Shared caching.
4. Corporate network control.

### Reverse Proxy

A reverse proxy sits in front of servers. Clients think they are talking to the server directly.

Uses:

1. TLS termination.
2. Load balancing.
3. Caching.
4. Compression.
5. Authentication integration.
6. Hiding internal services.

Nginx and Envoy are common examples.

### Gateway

A gateway is a boundary device or service that connects different networks or different protocol domains.

Two meanings show up often in interviews:

1. Network gateway: the next hop that lets a host reach destinations outside its local subnet. This is what "default gateway" usually means.
2. Application gateway: a service that sits at the edge of an application boundary and manages incoming traffic, translation, policy, or routing.

The common idea is controlled passage between one domain and another.

### API Gateway

An API gateway is a specialized reverse proxy for APIs. It can do routing, auth, rate limiting, request transformation, observability, and aggregation.

Interview distinction: not every reverse proxy is an API gateway, but most API gateways behave like advanced reverse proxies.

```mermaid
flowchart LR
	A[Clients] --> B[Load Balancer]
	B --> C[Reverse Proxy or API Gateway]
	C --> D[Service A]
	C --> E[Service B]
	C --> F[Service C]
```

## Firewalls And Security Basics

A firewall filters traffic according to rules.

### Types Of Firewalls

1. Packet-filtering or stateless firewalls inspect packets individually.
2. Stateful firewalls track connection state and make smarter decisions.
3. Web application firewalls, or WAFs, inspect HTTP traffic for application-layer attacks.

### Common Security Concepts

1. Least privilege: allow only what is needed.
2. Network segmentation: isolate systems by trust boundary.
3. Ingress rules: who can reach a service.
4. Egress rules: where a service can send traffic.
5. Rate limiting: reduce abuse and protect capacity.
6. DDoS mitigation: absorb or filter massive traffic floods.

### Examples Of Real Risks

1. Exposing a database port to the public Internet.
2. Allowing unrestricted outbound traffic from sensitive workloads.
3. Trusting internal traffic too much.
4. Forgetting to rotate certificates or credentials.

## CDN, Caching, And Latency

### CDN

A content delivery network caches content at edge locations closer to users.

Benefits:

1. Lower latency.
2. Reduced origin load.
3. Better global performance.
4. Improved resilience for static content.

Typical fit: images, videos, JS bundles, CSS, downloads, and cacheable API responses.

### Caching

Caching means storing a response closer to where it will be reused.

Common cache locations:

1. Browser cache.
2. CDN edge cache.
3. Reverse proxy cache.
4. Application cache like Redis.
5. Database page cache.

### Cache Concepts Worth Knowing

1. Cache hit: request served from cache.
2. Cache miss: request must go to origin.
3. TTL: how long data stays valid.
4. Eviction: removal policy such as LRU.
5. Staleness: cached data may be out of date.
6. Invalidation: explicitly removing outdated cache entries.

### HTTP Caching Headers

Useful headers to know:

1. `Cache-Control`
2. `ETag`
3. `Last-Modified`
4. `Expires`

Interview point: cache invalidation is hard because you are trading correctness, freshness, and performance.

### Latency Breakdown

Latency is not one thing. It is the sum of multiple delays:

1. DNS lookup time.
2. TCP handshake time.
3. TLS handshake time.
4. Network propagation time.
5. Queuing delay in devices.
6. Server processing time.
7. Response transfer time.

```mermaid
flowchart LR
	A[User Click] --> B[DNS]
	B --> C[TCP]
	C --> D[TLS]
	D --> E[Request Transit]
	E --> F[Server Processing]
	F --> G[Response Transit]
	G --> H[Rendering or Client Work]
```

### Throughput Vs Latency

Throughput is how much data or how many requests you can process over time. Latency is how long a single request takes. You can improve one without improving the other.

Example: batching work may improve throughput but worsen latency for individual requests.

## Practical Real-World Scenarios

### Scenario 1: A Website Feels Slow For Users Far From The Server

Possible causes:

1. High round-trip time because of geography.
2. Too many sequential requests.
3. No CDN for static assets.
4. Repeated TCP and TLS handshakes due to poor connection reuse.
5. Cache misses at multiple layers.

Good interview answer: discuss CDN, caching, compression, connection reuse, reducing chattiness, and serving content from closer regions.

### Scenario 2: Service Works By IP But Not By Domain Name

Likely DNS issue.

Check:

1. DNS record correctness.
2. TTL and propagation delay.
3. Resolver cache.
4. Split-horizon DNS or internal DNS differences.
5. Wrong CNAME chain or stale record.

### Scenario 3: HTTPS Certificate Errors After Deployment

Possible causes:

1. Expired certificate.
2. Hostname mismatch.
3. Missing intermediate certificate.
4. Clock skew on client or server.
5. TLS terminated at the wrong layer with the wrong cert.

### Scenario 4: Requests Time Out Intermittently

Possible causes:

1. Packet loss and TCP retransmissions.
2. Load balancer health check problems.
3. Connection pool exhaustion.
4. Slow downstream dependencies.
5. Firewall or security group rules dropping traffic.
6. DNS flapping between healthy and unhealthy endpoints.

### Scenario 5: API Returns `502 Bad Gateway`

This usually means a gateway or proxy could not get a valid response from the upstream server.

Good debugging path:

1. Check reverse proxy or load balancer logs.
2. Check upstream health.
3. Check timeouts and connection resets.
4. Check TLS settings between proxy and upstream.

## Common Interview Questions And Strong Answer Directions

### What Is The Difference Between OSI And TCP/IP?

Strong answer: OSI is a conceptual 7-layer model used for understanding network responsibilities. TCP/IP is the practical model used by the Internet. OSI is better for teaching, TCP/IP is closer to real implementation.

### Explain TCP Vs UDP

Strong answer: TCP is connection-oriented and provides reliable ordered delivery with retransmissions and congestion control. UDP is connectionless with lower overhead and no built-in reliability, which makes it useful for latency-sensitive workloads.

### Why Is HTTPS More Secure Than HTTP?

Strong answer: HTTPS is HTTP over TLS. TLS encrypts traffic, verifies server identity through certificates, and protects integrity so attackers cannot silently tamper with data in transit.

### What Happens When You Enter A URL In The Browser?

Strong answer should mention DNS lookup, routing, TCP handshake, TLS handshake for HTTPS, HTTP request/response, load balancers or proxies, server processing, and caching.

### What Is DNS And Why Is It Needed?

Strong answer: DNS is a distributed hierarchical naming system that maps domain names to resource records like IP addresses. It lets humans use names while systems use addresses.

### What Is A Socket?

Strong answer: a socket is an OS-level communication endpoint. For TCP connections, each connection can be identified by source IP, source port, destination IP, and destination port.

### What Is Subnetting?

Strong answer: subnetting divides an address space into smaller networks using a prefix length. It helps with routing, isolation, and efficient address management.

### What Is The Difference Between A Load Balancer And A Reverse Proxy?

Strong answer: a load balancer's primary job is distributing traffic across backends. A reverse proxy sits in front of servers and can also do caching, TLS termination, routing, or auth. In practice, one component can do both.

### Why Use A CDN?

Strong answer: CDNs reduce latency by serving cacheable content from locations closer to users, lower origin load, and improve scalability for global traffic.

### What Causes High Latency?

Strong answer: latency can come from DNS, handshakes, network distance, queuing, packet loss, retransmissions, server processing, and payload size. The right answer is usually a breakdown, not a single cause.

## High-Value Interview Nuances

These points often separate a solid answer from a shallow one:

1. TCP is a byte stream, not a message protocol.
2. HTTPS secures transport in transit, not application correctness.
3. DNS is cached heavily, so configuration changes are not always immediate.
4. Load balancers can work at different layers and may also terminate TLS.
5. A `401` and a `403` are not the same: unauthenticated versus authenticated but forbidden.
6. `502`, `503`, and `504` point to different upstream failure modes.
7. NAT helps conserve IPv4 addresses but changes how addressing works between internal and external networks.
8. Reliability, ordering, and latency are often tradeoffs, not free features.

## Quick Revision Sheet

If you need a short final-pass checklist before an interview, make sure you can explain:

1. OSI layers and what problems each layer solves.
2. TCP/IP model and how it maps to OSI.
3. TCP handshake, reliability, and congestion basics.
4. UDP tradeoffs and good use cases.
5. DNS resolution and common records.
6. IPv4, IPv6, CIDR, and subnet basics.
7. Difference between HTTP and HTTPS.
8. TLS purpose, certificates, and handshake basics.
9. REST principles and idempotency.
10. Ports, sockets, and connection reuse.
11. Load balancer, forward proxy, reverse proxy, and gateway differences.
12. Firewall basics, segmentation, and least privilege.
13. CDN and caching fundamentals.
14. How to reason about latency end to end.

## Final Interview Advice

For networking interviews, the strongest answers are usually not the most academic ones. They are the answers that connect protocol theory to production behavior.

A good pattern is:

1. Define the concept clearly.
2. Explain why it exists.
3. Describe the tradeoff.
4. Give a real example of where it matters.

If you can do that consistently, you will sound like an engineer who has worked with real systems rather than someone reciting flashcards.