Nextgen Blog
HomeLearnAIQuantumRoboticsSecuritySpaceAbout
Nextgen Blog

By Anubhav — full stack engineer, IIT Mandi CSE. Deep dives into AI, software engineering, and the technologies shaping the next generation of tech.

Navigate

  • Home
  • Learn
  • Blog
  • Archive
  • About

Topics

  • Artificial Intelligence
  • Quantum Computing
  • Robotics
  • Cybersecurity
  • Space Tech

Connect

Built with ❤️ & By - Anubhav

© 2026 Nextgen Blog by Anubhav. All rights reserved.

Privacy PolicyTerms of Service
Phase 01 · Foundations & Web ArchitectureChapter 4 of 33
03.
Phase 01Read time ~24 minDifficulty advanced

Networking Fundamentals

In this chapter
  • 01Why Networking Matters in System Design
  • 02The Network Mental Model
  • 03What Is a Network?
  • 04What Is an IP Address?
  • 05IPv4
  • 06IPv6
  • 07Public vs Private IP Addresses
  • 08What Is a Port?
  • 09Socket
  • 10Packets
  • 11Encapsulation
  • 12TCP
  • 13TCP Three-Way Handshake
  • 14TCP Reliability
  • 15TCP Ordering
  • 16Flow Control
  • 17Congestion Control
  • 18UDP
  • 19TCP vs UDP
  • 20QUIC and HTTP/3
  • 21Routing
  • 22Router
  • 23LAN
  • 24WAN
  • 25MAC Address
  • 26ARP
  • 27NAT
  • 28Why NAT Exists
  • 29Bandwidth
  • 30Latency
  • 31Propagation Delay
  • 32Round-Trip Time
  • 33Why Network Latency Matters
  • 34Throughput vs Latency
  • 35Latency
  • 36Throughput
  • 37Packet Loss
  • 38Jitter
  • 39Network Congestion
  • 40Connection Pooling
  • 41Keep-Alive
  • 42Timeouts
  • 43Retries
  • 44Exponential Backoff
  • 45Network Failure Scenarios
  • 46Scenario 1 — Connection refused
  • 47Scenario 2 — Timeout
  • 48Scenario 3 — Connection reset
  • 49Scenario 4 — Packet loss
  • 50Scenario 5 — DNS failure
  • 51Scenario 6 — Partial network failure
  • 52Partial Failure
  • 53Example: Three Services
  • 54Network Bound vs CPU Bound
  • 55CPU-bound
  • 56Network-bound
  • 57I/O-bound
  • 58Network Bottlenecks
  • 59Head-of-Line Blocking
  • 60Network Security Boundaries
  • 61Example: Web Request Across the Network
  • 62Common Misconceptions
  • 63Misconception 1 — "IP address identifies the application"
  • 64Misconception 2 — "TCP guarantees zero packet loss"
  • 65Misconception 3 — "UDP is always faster"
  • 66Misconception 4 — "More bandwidth always means lower latency"
  • 67Misconception 5 — "Retries always improve reliability"
  • 68Misconception 6 — "A timeout means the server failed"
  • 69Interview Questions
  • 70Q1. What is the difference between TCP and UDP?
  • 71Q2. What is an IP address?
  • 72Q3. What is a port?
  • 73Q4. What is NAT?
  • 74Q5. What is latency?
  • 75Q6. What is bandwidth?
  • 76Q7. What is RTT?
  • 77Q8. What is packet loss?
  • 78Q9. Why are timeouts important?
  • 79Q10. Why can retries be dangerous?
  • 80Practice Exercises
  • 81Beginner
  • 82Intermediate
  • 83Advanced
  • 84Exercise 1
  • 85Exercise 2
  • 86Exercise 3
  • 87Mini Project — Network Request Simulator
  • 88System Design Connection
  • 89Key Takeaways
  • 90Chapter Summary
  • 91Next Chapter
  • 92Chapter 03 — DNS Deep Dive
In this chapter (92 sections)
01Why Networking Matters in System Design02The Network Mental Model03What Is a Network?04What Is an IP Address?05IPv406IPv607Public vs Private IP Addresses08What Is a Port?09Socket10Packets11Encapsulation12TCP13TCP Three-Way Handshake14TCP Reliability15TCP Ordering16Flow Control17Congestion Control18UDP19TCP vs UDP20QUIC and HTTP/321Routing22Router23LAN24WAN25MAC Address26ARP27NAT28Why NAT Exists29Bandwidth30Latency31Propagation Delay32Round-Trip Time33Why Network Latency Matters34Throughput vs Latency35Latency36Throughput37Packet Loss38Jitter39Network Congestion40Connection Pooling41Keep-Alive42Timeouts43Retries44Exponential Backoff45Network Failure Scenarios46Scenario 1 — Connection refused47Scenario 2 — Timeout48Scenario 3 — Connection reset49Scenario 4 — Packet loss50Scenario 5 — DNS failure51Scenario 6 — Partial network failure52Partial Failure53Example: Three Services54Network Bound vs CPU Bound55CPU-bound56Network-bound57I/O-bound58Network Bottlenecks59Head-of-Line Blocking60Network Security Boundaries61Example: Web Request Across the Network62Common Misconceptions63Misconception 1 — "IP address identifies the application"64Misconception 2 — "TCP guarantees zero packet loss"65Misconception 3 — "UDP is always faster"66Misconception 4 — "More bandwidth always means lower latency"67Misconception 5 — "Retries always improve reliability"68Misconception 6 — "A timeout means the server failed"69Interview Questions70Q1. What is the difference between TCP and UDP?71Q2. What is an IP address?72Q3. What is a port?73Q4. What is NAT?74Q5. What is latency?75Q6. What is bandwidth?76Q7. What is RTT?77Q8. What is packet loss?78Q9. Why are timeouts important?79Q10. Why can retries be dangerous?80Practice Exercises81Beginner82Intermediate83Advanced84Exercise 185Exercise 286Exercise 387Mini Project — Network Request Simulator88System Design Connection89Key Takeaways90Chapter Summary91Next Chapter92Chapter 03 — DNS Deep Dive

1. Why Networking Matters in System Design#

Distributed systems are fundamentally communication systems.

Whenever two components are running on different machines, they need a network:

Application A
     |
     | Network
     v
Application B

A modern system may contain:

Browser
   ↓
CDN
   ↓
Load Balancer
   ↓
API Server
   ↓
Cache
   ↓
Database
   ↓
Message Broker
   ↓
Worker

Many of these components communicate over a network.

Therefore, if you understand networking, you can reason about:

  • latency
  • throughput
  • connection limits
  • failures
  • retries
  • timeouts
  • load balancing
  • service-to-service communication
  • distributed systems
  • geographic distribution

A large part of System Design is understanding what happens between two machines.


2. The Network Mental Model#

Start with the simplest possible model:

Computer A
    |
    | Network
    |
    v
Computer B

Computer A wants to send:

"Hello"

to Computer B.

The operating system and network stack break this communication into layers.

A simplified model:

+-------------------------+
| Application             |
| HTTP, DNS, SSH, etc.    |
+-------------------------+
| Transport               |
| TCP, UDP                |
+-------------------------+
| Internet                |
| IP                      |
+-------------------------+
| Link                    |
| Ethernet, Wi-Fi         |
+-------------------------+
| Physical                |
| Cable, radio, fiber     |
+-------------------------+

Each layer solves a different problem.


3. What Is a Network?#

A network is a collection of connected devices that can exchange data.

Examples:

  • home Wi-Fi
  • office network
  • mobile network
  • cloud network
  • the public Internet

A very small network:

Laptop
   |
 Wi-Fi
   |
Router

A larger network:

Laptop
   |
Router
   |
ISP
   |
Internet
   |
Cloud
   |
Server

The Internet is essentially a huge network of interconnected networks.


4. What Is an IP Address?#

An IP address identifies a network interface/address used for communication.

Two major versions are:

IPv4
IPv6

IPv4#

IPv4 uses 32 bits.

Example:

192.168.1.10

It contains four decimal numbers called octets.

Each octet ranges from:

0 → 255

because each octet contains 8 bits.

8 bits + 8 bits + 8 bits + 8 bits
= 32 bits

IPv6#

IPv6 uses 128 bits.

Example:

2001:db8:85a3::8a2e:370:7334

IPv6 provides a vastly larger address space.

For System Design, the important distinction is:

IPv4 → 32-bit addresses
IPv6 → 128-bit addresses

5. Public vs Private IP Addresses#

Not every IP address is directly reachable from the public Internet.

Private IPv4 address ranges include:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Example:

Laptop
192.168.1.20

may communicate through a home router that has a public Internet address.

Conceptually:

Laptop
192.168.1.20
      |
      v
   Router
      |
      v
Public Internet

This leads to an important networking concept:

NAT — Network Address Translation

We will cover it later in this chapter.


6. What Is a Port?#

An IP address identifies the network destination.

A port identifies a service endpoint on that host.

Think:

IP address = Building
Port       = Apartment/office

For example:

192.168.1.10:443

means:

Host = 192.168.1.10
Port = 443

Common ports include:

Port Typical use
22 SSH
53 DNS
80 HTTP
443 HTTPS
25 SMTP
3306 MySQL
5432 PostgreSQL
6379 Redis
27017 MongoDB

The actual service configuration can vary, so port numbers are conventions rather than guarantees.


7. Socket#

A socket is an operating-system abstraction used by applications for network communication.

A simplified view:

Application
    |
    v
 Socket
    |
    v
Network stack

For TCP, a connection can be identified by a combination involving:

Source IP
Source Port
Destination IP
Destination Port
Protocol

Example:

Client:
192.168.1.20:52314
 
Server:
203.0.113.10:443
 
Protocol:
TCP

This allows one machine to maintain many simultaneous connections to the same server.


8. Packets#

Applications don't generally send an arbitrarily large message as one giant physical transmission.

Data is processed through networking layers and transmitted in units such as packets.

Simplified:

Large message
     |
     v
+----+----+----+----+
| P1 | P2 | P3 | P4 |
+----+----+----+----+

Each packet carries information needed to move the data through the network.

Packets can experience:

  • delay
  • loss
  • duplication
  • reordering

Reliable protocols such as TCP handle many of these issues at the transport layer.


9. Encapsulation#

One of the most important networking concepts is encapsulation.

Suppose an application sends:

Hello

The data moves down the protocol stack.

Conceptually:

Application data
       ↓
+------------------+
| TCP header       |
| Application data |
+------------------+
       ↓
+------------------+
| IP header        |
| TCP segment      |
+------------------+
       ↓
+------------------+
| Link header      |
| IP packet        |
+------------------+

Each layer adds information required by that layer.

At the destination, the reverse process happens.

Link
  ↓
IP
  ↓
TCP
  ↓
Application

This is called decapsulation.


10. TCP#

TCP stands for:

Transmission Control Protocol

TCP provides a reliable, ordered byte stream between endpoints.

It provides mechanisms for:

  • connection establishment
  • reliable delivery
  • ordering
  • retransmission
  • flow control
  • congestion control

Mental model:

Application
    ↓
TCP
    ↓
Reliable ordered communication

TCP is commonly used by applications such as:

  • HTTPS over TCP
  • SSH
  • many database connections

Note that modern protocols such as HTTP/3 use QUIC over UDP instead of TCP. We will discuss this later.


11. TCP Three-Way Handshake#

Before normal TCP data exchange, endpoints establish a connection.

Simplified:

Client                       Server
 
  SYN ------------------------>
 
      <------------------- SYN-ACK
 
  ACK ------------------------>

Then application data can flow.

Why does this matter in System Design?

Because creating connections has cost.

If an application repeatedly creates new connections, it can introduce:

  • additional latency
  • CPU overhead
  • connection-management overhead

This is one reason connection reuse / keep-alive matters.


12. TCP Reliability#

Suppose packets are lost:

Packet 1 → received
Packet 2 → LOST
Packet 3 → received

TCP can detect missing data and retransmit it.

Conceptually:

Sender
  |
  | P1
  | P2  X
  | P3
  |
  v
Receiver
 
Receiver indicates missing data
          |
          v
Sender retransmits

This makes TCP useful when reliable ordered delivery is important.


13. TCP Ordering#

Suppose packets arrive in a different order:

Sent:
 
P1 → P2 → P3
 
Received:
 
P1 → P3 → P2

TCP can reorder the byte stream so the application sees the correct order.

The application normally does not have to implement packet ordering itself.


14. Flow Control#

A sender can potentially produce data faster than the receiver can consume it.

Example:

Sender
10 GB/s
   |
   v
Network
   |
   v
Receiver
1 GB/s

If the sender continuously sends at 10 GB/s, the receiver can become overwhelmed.

TCP uses flow-control mechanisms to prevent a fast sender from overwhelming a receiver.

Mental model:

Fast sender
     |
     | controlled rate
     v
Receiver capacity

15. Congestion Control#

Flow control protects the receiver.

Congestion control deals with the network itself.

Imagine:

Server A
   \
Server B ----> Shared network ----> Destination
   /
Server C

If everyone sends huge amounts of traffic simultaneously, network links can become congested.

TCP uses congestion-control algorithms to adjust sending behavior based on network conditions.

This distinction is important:

Flow control
→ Protect receiver
 
Congestion control
→ React to network congestion

16. UDP#

UDP stands for:

User Datagram Protocol

UDP is connectionless and provides a simpler datagram transport.

Compared with TCP, UDP does not provide TCP's built-in guarantees for:

  • ordered delivery
  • retransmission
  • reliable byte-stream delivery

Mental model:

Application
    ↓
UDP datagrams
    ↓
Network

UDP can be useful when:

  • low overhead matters
  • the application can tolerate loss
  • the application implements its own reliability
  • latency-sensitive communication is important

Examples include certain real-time and streaming protocols.


17. TCP vs UDP#

Feature TCP UDP
Connection-oriented Yes No
Reliable delivery built in Yes No
Ordered byte stream Yes No
Retransmission Yes No
Flow control Yes No TCP-style mechanism
Congestion control Yes Application/protocol dependent
Overhead Higher Lower
Typical use Web, databases, SSH DNS, real-time protocols, QUIC transport

Important:

"UDP is faster than TCP" is an oversimplification.

Actual performance depends on the protocol, network, workload and application behavior.

Modern protocols can build sophisticated reliability and congestion-control mechanisms on top of UDP.


18. QUIC and HTTP/3#

Modern web systems also use:

HTTP/3
   ↓
QUIC
   ↓
UDP

Instead of:

HTTP/1.1 or HTTP/2
   ↓
TCP

QUIC implements transport functionality over UDP, including:

  • reliable delivery
  • encryption integration
  • congestion control
  • multiplexed streams

You do not need to master QUIC yet.

For now, remember:

Traditional HTTPS:
HTTP → TLS → TCP → IP
 
HTTP/3:
HTTP/3 → QUIC → UDP → IP

This will become relevant when discussing modern web performance.


19. Routing#

Suppose your computer wants to communicate with a server thousands of kilometers away.

The packet doesn't travel directly from your computer to the server.

It passes through network devices.

Simplified:

Laptop
  ↓
Home Router
  ↓
ISP
  ↓
Internet Router
  ↓
Internet Router
  ↓
Cloud Network
  ↓
Server

Routers make forwarding decisions based on destination network information.


20. Router#

A router connects networks and forwards packets between them.

Example:

Network A
   |
 Router
   |
Network B

A home router may connect:

Home LAN
    |
 Router
    |
Internet / ISP

Cloud networks also use routing extensively.


21. LAN#

LAN stands for:

Local Area Network

Examples:

  • home network
  • office network
  • data-center network

Example:

Laptop
   |
   +--- Phone
   |
   +--- Printer
   |
   +--- Server

All may communicate within the local network.


22. WAN#

WAN stands for:

Wide Area Network

It connects geographically separated networks.

Example:

Delhi Data Center
       |
       |
    Internet
       |
       |
Mumbai Data Center

WAN communication generally introduces more latency than local communication because of:

  • physical distance
  • routing
  • network equipment
  • congestion

23. MAC Address#

At the local network/link layer, devices use hardware/network-interface identifiers such as MAC addresses.

Example:

3C:52:82:AB:12:EF

The important distinction:

MAC address
→ Link/local network identity
 
IP address
→ Network-layer addressing

You do not normally design application architecture around MAC addresses, but understanding the distinction helps explain networking layers.


24. ARP#

In IPv4 local networks, a host may need to discover the MAC address associated with a local IP address.

ARP stands for:

Address Resolution Protocol

Simplified:

Who has 192.168.1.1?
 
        ↓
 
Router:
"I have it."
 
        ↓
 
MAC address returned

ARP is mainly a local-network concept.

IPv6 uses Neighbor Discovery rather than ARP.


25. NAT#

NAT stands for:

Network Address Translation

A common home-network scenario:

Laptop
192.168.1.20
      |
      v
Home Router
Public IP
      |
      v
Internet

Private addresses are not globally unique.

The router can translate private network traffic to a public address.

Conceptually:

192.168.1.20:52314
        ↓
NAT
        ↓
203.0.113.5:41001

The external server sees the public-side address.


26. Why NAT Exists#

One major reason is IPv4 address conservation.

Private networks can reuse addresses such as:

192.168.1.10

in many different locations.

For example:

Home A → 192.168.1.10
Home B → 192.168.1.10
Office C → 192.168.1.10

NAT allows these private networks to communicate through shared public IPv4 addresses.


27. Bandwidth#

Bandwidth is the maximum data-transfer capacity of a network link under specified conditions.

Example:

1 Gbps

means approximately one billion bits per second of link capacity.

Important distinction:

Bandwidth ≠ Latency

A network can have:

High bandwidth
High latency

or:

Low bandwidth
Low latency

These are different characteristics.


28. Latency#

Latency is the time required for data or a request to travel through a system.

Network latency can be influenced by:

  • physical distance
  • routing
  • congestion
  • processing
  • queueing
  • protocol behavior

Example:

Client
  |
  | 80 ms
  v
Server

A request may experience multiple network segments:

Client
  ↓ 10 ms
Router
  ↓ 15 ms
ISP
  ↓ 20 ms
Cloud
  ↓ 15 ms
Server

Total network contribution is affected by the complete path.


29. Propagation Delay#

Signals take physical time to travel.

A packet cannot travel from India to the United States instantaneously.

The physical medium matters:

  • fiber
  • copper
  • wireless
  • satellite

Therefore, geographic distribution has unavoidable physical latency.

This is one reason global systems deploy services closer to users.


30. Round-Trip Time#

RTT means:

Round-Trip Time

It measures the time for communication to go from one endpoint to another and back.

Conceptually:

Client
  |
  | ------>
  |
 Server
  |
  | <------
  |
Client

If:

Request = 50 ms
Response path = 50 ms

RTT is approximately:

100 ms

Real measurements depend on the network and protocol.

RTT is extremely important in distributed systems.


31. Why Network Latency Matters#

Suppose a request performs five sequential remote calls:

Client
  ↓
Service A
  ↓
Service B
  ↓
Service C
  ↓
Service D
  ↓
Database

If each remote interaction adds significant latency, total response time can grow rapidly.

This is one reason system designers try to:

  • reduce unnecessary network calls
  • batch operations
  • cache data
  • colocate related services
  • parallelize independent operations
  • use asynchronous processing where appropriate

32. Throughput vs Latency#

These are often confused.

Latency#

How long does one operation take?

Request → 100 ms

Throughput#

How much work can the system process?

100,000 requests/second

A system can have:

High throughput + high latency

or:

Low latency + low throughput

They are separate dimensions.


33. Packet Loss#

Packets can be lost due to:

  • congestion
  • network failures
  • faulty hardware
  • wireless interference
  • routing problems

Example:

P1 → received
P2 → LOST
P3 → received

For TCP, loss can trigger retransmission.

For protocols that do not automatically retransmit, the application/protocol may decide what to do.


34. Jitter#

Jitter is variation in packet delay.

Suppose packets arrive with delays:

20 ms
22 ms
21 ms
80 ms
25 ms

The variation is significant.

Jitter matters particularly for real-time applications such as:

  • voice
  • video calls
  • gaming
  • real-time media

35. Network Congestion#

Imagine a road:

Few cars
→ smooth traffic
 
Too many cars
→ traffic jam

Networking can behave similarly.

When traffic exceeds available capacity:

Packets
   ↓
Queue
   ↓
Delay increases
   ↓
Potential packet loss

Congestion can therefore increase both:

  • latency
  • packet loss

36. Connection Pooling#

Opening a new connection for every request can be expensive.

Instead:

Application
   |
   +--- Connection 1
   +--- Connection 2
   +--- Connection 3
   +--- Connection 4

The application maintains a pool of reusable connections.

This is common with:

  • databases
  • HTTP clients
  • service-to-service communication

Benefits:

  • reduces connection setup overhead
  • controls concurrency
  • improves efficiency

But too many connections can also overwhelm a service.


37. Keep-Alive#

Instead of:

Request 1
→ open connection
→ close
 
Request 2
→ open connection
→ close
 
Request 3
→ open connection
→ close

connections can be reused:

Open connection
     |
     +--> Request 1
     |
     +--> Request 2
     |
     +--> Request 3
     |
     +--> Request 4

Connection reuse reduces repeated setup overhead.

HTTP versions and transport protocols implement connection management differently, but the general optimization idea is important.


38. Timeouts#

Every network request can potentially wait indefinitely if there is no timeout.

Example:

Service A
   |
   | Request
   v
Service B
   |
   X No response

Without a timeout:

Service A waits...
Service A waits...
Service A waits...

With a timeout:

Request
   |
   | wait
   |
   X timeout
   |
   v
Fallback / retry / error

Timeouts are essential in distributed systems.


39. Retries#

If a request fails temporarily, a client may retry.

Example:

Request
   |
   X failure
   |
 Retry
   |
   X failure
   |
 Retry
   |
 Success

But retries can be dangerous.

Suppose:

100 requests

all retry simultaneously.

The overloaded service can receive:

100 original requests
+
100 retries
+
100 second retries

This can amplify the outage.

This is why production systems often use:

  • limited retries
  • exponential backoff
  • jitter
  • timeouts
  • circuit breakers

We will study these in the reliability section.


40. Exponential Backoff#

Instead of retrying immediately:

Retry 1 → 100 ms
Retry 2 → 200 ms
Retry 3 → 400 ms
Retry 4 → 800 ms

The delay increases.

Random jitter can prevent many clients from retrying at exactly the same time.

Conceptually:

Failure
  ↓
Wait
  ↓
Retry
  ↓
Failure
  ↓
Wait longer
  ↓
Retry

41. Network Failure Scenarios#

In distributed systems, assume networks can fail.

Examples:

Scenario 1 — Connection refused#

The destination may not be accepting connections.

Scenario 2 — Timeout#

The destination doesn't respond within the configured period.

Scenario 3 — Connection reset#

An established connection is unexpectedly terminated.

Scenario 4 — Packet loss#

Some packets fail to arrive.

Scenario 5 — DNS failure#

The application cannot resolve the destination.

Scenario 6 — Partial network failure#

One service can reach another, but a third service cannot.

Partial failure is particularly important in distributed systems.


42. Partial Failure#

In a single-machine application:

Server crashes
→ Application stops

In a distributed system:

Service A
   |
   X
Service B
   |
   v
Service C

Service A may still be healthy while communication with B fails.

This is called a partial failure.

Distributed systems are difficult partly because:

You cannot always tell whether the remote service is slow, dead, disconnected, or merely unreachable.

This idea becomes central later.


43. Example: Three Services#

Suppose:

API
 |
 +--> User Service
 |
 +--> Product Service
 |
 +--> Recommendation Service

Recommendation Service becomes slow.

If API waits indefinitely:

API
 |
 | waits
 v
Recommendation Service

Then API requests may pile up.

A better architecture may use:

API
 |
 +--> User Service
 |
 +--> Product Service
 |
 +--> Recommendation Service
             |
             X timeout
             |
             v
          fallback

The system can still return the core product response without waiting forever for recommendations.

This is graceful degradation.


44. Network Bound vs CPU Bound#

A service may be slow because it is:

CPU-bound#

CPU usage = 100%

or:

Network-bound#

Waiting for remote service

or:

I/O-bound#

Waiting for disk/database

These require different optimization strategies.

System design requires identifying the actual bottleneck instead of guessing.


45. Network Bottlenecks#

Possible bottlenecks include:

Client
  ↓
Network bandwidth
  ↓
Load balancer
  ↓
Application
  ↓
Database connection pool
  ↓
Database

For each layer, ask:

What happens when demand exceeds capacity?

Example:

Application capacity = 50,000 RPS
Database capacity    = 10,000 QPS

The database may become the bottleneck.

Adding more application servers won't necessarily solve the problem.


46. Head-of-Line Blocking#

A simplified example:

Request A → very slow
Request B → fast
Request C → fast

If the transport or application architecture forces B and C to wait behind A, overall latency can increase.

Modern protocols such as HTTP/2 and HTTP/3 provide mechanisms for multiplexing multiple streams, although each has different transport-level behavior.

This is an advanced topic, but remember:

How requests share connections can affect latency.


47. Network Security Boundaries#

A system should not expose every component directly to the Internet.

A typical architecture might be:

Internet
   |
   v
Public Load Balancer
   |
   v
Private Application Network
   |
   +--> Cache
   |
   +--> Database

The database may not have a public IP or public inbound access.

This reduces the attack surface.

Security architecture will be covered in detail later.


48. Example: Web Request Across the Network#

Suppose:

Browser
   |
   | HTTPS
   v
api.example.com

A simplified journey:

1. Browser resolves DNS
2. Browser obtains destination information
3. Network connection is established
4. TLS security is established
5. HTTP request is sent
6. Routers forward packets
7. Load balancer receives traffic
8. Backend server processes request
9. Response returns
10. Browser processes response

At every stage there can be:

  • latency
  • failure
  • resource limits
  • security requirements

This is why networking is foundational to System Design.


49. Common Misconceptions#

Misconception 1 — "IP address identifies the application"#

Not exactly.

An IP address identifies a network endpoint/address.

A host can run multiple services using different ports.

IP: 10.0.0.10
 
10.0.0.10:80
10.0.0.10:443
10.0.0.10:5432

Misconception 2 — "TCP guarantees zero packet loss"#

TCP can detect and retransmit missing data, but the underlying network can still lose packets.

TCP provides a reliable abstraction to the application.


Misconception 3 — "UDP is always faster"#

Not universally.

UDP has lower protocol overhead, but application behavior, congestion, retransmission, network conditions and protocol design all matter.


Misconception 4 — "More bandwidth always means lower latency"#

No.

Bandwidth and latency are different.

Bandwidth → how much data can move
Latency    → how long communication takes

Misconception 5 — "Retries always improve reliability"#

Retries can improve recovery from transient failures, but excessive retries can make an outage worse.


Misconception 6 — "A timeout means the server failed"#

Not necessarily.

A timeout means the caller did not receive an acceptable response within its configured time.

The server could be:

  • slow
  • overloaded
  • processing successfully but too slowly
  • unreachable
  • responding through a broken network path

This uncertainty is fundamental to distributed systems.


50. Interview Questions#

Q1. What is the difference between TCP and UDP?#

TCP provides a reliable, ordered byte-stream abstraction with connection management, flow control and congestion control.

UDP provides connectionless datagrams without TCP's built-in reliable ordered delivery.


Q2. What is an IP address?#

An address used by the network layer to identify a network destination/interface.


Q3. What is a port?#

A logical endpoint used to identify a service/application endpoint on a host.


Q4. What is NAT?#

Network Address Translation translates addresses between network contexts, commonly allowing private IPv4 hosts to communicate through a public IPv4 address.


Q5. What is latency?#

The time required for an operation or communication to complete.


Q6. What is bandwidth?#

The capacity of a communication link to transfer data over time.


Q7. What is RTT?#

Round-Trip Time: the time for communication to travel from one endpoint to another and back.


Q8. What is packet loss?#

A condition where transmitted packets do not successfully reach their intended destination.


Q9. Why are timeouts important?#

They prevent a caller from waiting indefinitely for a remote operation.


Q10. Why can retries be dangerous?#

Because many clients retrying simultaneously can amplify load and make an outage worse.


51. Practice Exercises#

Beginner#

  1. What is an IP address?
  2. What is a port?
  3. What is the difference between IPv4 and IPv6?
  4. What is TCP?
  5. What is UDP?
  6. What is DNS's role?
  7. What is NAT?
  8. What is latency?
  9. What is bandwidth?
  10. What is RTT?

Intermediate#

  1. Explain the TCP three-way handshake.
  2. Explain the difference between flow control and congestion control.
  3. Why does geographic distance affect latency?
  4. Why can packet loss increase application latency?
  5. Why are connection pools useful?
  6. Why are timeouts important?
  7. Why can aggressive retries cause an outage to become worse?
  8. Explain partial network failure.

Advanced#

Exercise 1#

Your service makes:

5 sequential API calls

Each call has an average network latency of:

40 ms

What is the approximate network contribution if all five calls are strictly sequential?

Then consider what changes if the calls are independent and can execute concurrently.


Exercise 2#

A service can process:

20,000 requests/second

but its database can process only:

5,000 queries/second

Where is the bottleneck?

Would adding more application servers necessarily solve it?

Explain why.


Exercise 3#

Design a service that must communicate with another service that occasionally takes 10 seconds to respond.

Discuss:

  • timeout
  • retry
  • backoff
  • fallback
  • circuit breaker
  • user experience

52. Mini Project — Network Request Simulator#

Create a simple conceptual simulator that models:

Client
  ↓
Router
  ↓
Server

Add configurable:

  • latency
  • packet loss
  • timeout
  • retry count

For example:

Latency: 100 ms
Packet loss: 5%
Timeout: 500 ms
Retries: 2

Then reason about how these settings affect user-visible behavior.

The purpose is not to implement a real network stack.

The purpose is to understand network behavior.


53. System Design Connection#

We can now connect networking to architecture.

Suppose:

100,000 users
        |
        v
Load Balancer
        |
        +----> App Server A
        |
        +----> App Server B
        |
        +----> App Server C

Each request involves network communication.

Now suppose each application server communicates with:

Redis
Database
User Service
Payment Service
Notification Service

One request may cause many network interactions.

Therefore:

More distributed components
          ↓
More network communication
          ↓
More latency + more failure modes

This is one of the central trade-offs of distributed architecture.


54. Key Takeaways#

Remember these relationships:

IP
 ↓
Identifies network destination
 
Port
 ↓
Identifies service endpoint
 
TCP
 ↓
Reliable ordered byte stream
 
UDP
 ↓
Connectionless datagrams
 
Router
 ↓
Forwards packets between networks
 
NAT
 ↓
Translates network addresses
 
Bandwidth
 ↓
Data-transfer capacity
 
Latency
 ↓
Time required
 
RTT
 ↓
Time there + back
 
Packet loss
 ↓
Data fails to arrive
 
Timeout
 ↓
Stop waiting after a limit
 
Retry
 ↓
Try again, carefully

The most important idea is:

Networks are not free, instantaneous or perfectly reliable.

A good system designer accounts for:

  • latency
  • bandwidth
  • connection limits
  • packet loss
  • congestion
  • timeouts
  • retries
  • partial failures

55. Chapter Summary#

We covered:

  • network fundamentals
  • IP addresses
  • IPv4
  • IPv6
  • public/private IP
  • ports
  • sockets
  • packets
  • encapsulation
  • TCP
  • TCP handshake
  • TCP reliability
  • flow control
  • congestion control
  • UDP
  • TCP vs UDP
  • QUIC
  • HTTP/3
  • routing
  • routers
  • LAN
  • WAN
  • MAC addresses
  • ARP
  • NAT
  • bandwidth
  • latency
  • propagation delay
  • RTT
  • throughput
  • packet loss
  • jitter
  • congestion
  • connection pooling
  • keep-alive
  • timeouts
  • retries
  • exponential backoff
  • partial failures
  • network bottlenecks
  • security boundaries

These concepts form the networking foundation for the rest of the course.


56. Next Chapter#

Chapter 03 — DNS Deep Dive#

We will go much deeper into DNS:

Domain Name
     ↓
DNS Resolver
     ↓
Root Server
     ↓
TLD Server
     ↓
Authoritative Server
     ↓
IP Address

We will study:

  • DNS hierarchy
  • recursive resolvers
  • authoritative DNS
  • DNS records
  • A / AAAA
  • CNAME
  • MX
  • TXT
  • NS
  • TTL
  • DNS caching
  • DNS propagation
  • DNS load balancing
  • health checks
  • failover
  • DNS-based architectures
  • common DNS interview questions

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 01 — How a Web Application WorksNext ChapterChapter 03 — DNS Deep Dive
PrevNext