Network Fundamentals - Learning Module

Loading content...

0/228

Communication Model

How Computers Communicate

When you send a message, browse a website, or stream a video, a remarkable process unfolds—your computer must communicate with another computer, potentially on the other side of the world, and receive a coherent response. How does this happen? What's the underlying model that makes such communication possible?

The communication model describes the fundamental process by which data moves from source to destination across a network. It addresses questions that might seem obvious but have profound implications: How is data formatted? How do devices find each other? How does data navigate through the network? How do we ensure it arrives correctly?

Learning Objectives

By the end of this page, you will:

• Understand the fundamental elements of the communication model • Explain how data is formatted, addressed, transmitted, and received • Describe the source-destination paradigm and data flow • Analyze the roles of protocols, addressing, and routing in communication • Apply the communication model to trace data through a network

The Five Elements of Communication

All network communication—whether a simple ping or a complex video stream—involves five fundamental elements. Understanding these elements provides a framework for analyzing any communication scenario.

Fundamental Elements of Network Communication
Element	Description	Network Example	Failure Mode
Sender (Source)	The entity initiating communication	Client computer requesting a web page	Sender crashes, misconfigured, no network access
Receiver (Destination)	The entity receiving communication	Web server responding to request	Server down, unreachable, overloaded
Message (Data)	The information being communicated	HTTP request, file contents, video frames	Corrupted, too large, malformed
Medium (Channel)	The physical path carrying signals	Ethernet cables, WiFi, fiber optics	Cable cut, interference, congestion
Protocol (Rules)	Agreed format and procedures	TCP/IP, HTTP, Ethernet	Incompatible versions, misconfiguration

An Analogy: Postal Mail

The communication model parallels postal mail:

Postal System	Network System
Writer	Sending application
Reader	Receiving application
Letter content	Data/message
Postal transportation	Transmission media + intermediate systems
Addressing format, postage rules	Protocols
Envelope with addresses	Packet with headers
Postal sorting facilities	Routers
Local mail carrier	Last-mile network devices

The analogy holds in important ways:

Letters can be lost, delayed, or damaged
Multiple routes may exist between two locations
The writer doesn't need to know the exact route
Standard formats (addresses, stamps) enable interoperation

The analogy breaks down in others:

Network communication can be instantaneous (vs. days for mail)
The same 'letter' can be received by millions simultaneously (multicast/broadcast)
Digital data can be perfectly copied (unlike physical letters)

The Protocol's Central Role

Among the five elements, protocols are unique—they're the only element that's purely informational, not physical. Yet protocols determine everything: how data is formatted, how addresses are structured, how errors are handled, how communication is secured. Two devices can be physically connected but unable to communicate if they don't share protocols. The protocol is the common language.

Data Flow Through the Network

Understanding how data flows from source to destination is fundamental to network comprehension. The process involves multiple stages, each adding value and complexity.

The Data Flow Journey

•Application Data Creation — An application (browser, email client) creates data to send. This might be an HTTP request, email message, or file contents.
•Data Segmentation — Large data is divided into smaller segments (if using TCP) or datagrams (if using UDP). Each segment is manageable for the network.
•Protocol Headers Added — Each network layer adds its headers: transport (TCP/UDP with ports), network (IP with addresses), data link (Ethernet with MAC addresses).
•Physical Transmission — The lowest layer converts digital data to physical signals (electrical, optical, radio) and sends across the medium.
•Intermediate Forwarding — Routers and switches receive signals, decode to frames/packets, make forwarding decisions, and retransmit.
•Destination Reception — The destination NIC receives signals, decodes to frames, checks for errors.
•Header Removal (Decapsulation) — Each layer strips its headers, passing data upward until the application receives the original message.

Encapsulation: The Envelope Model

As data passes down through protocol layers, each layer adds its own header (and sometimes trailer), encapsulating the layer above:

Application creates:
  [HTTP Request Data]

Transport layer adds:
  [TCP Header | HTTP Request Data]
  (Segment)

Network layer adds:
  [IP Header | TCP Header | HTTP Request Data]
  (Packet)

Data Link layer adds:
  [Ethernet Header | IP Header | TCP Header | HTTP Request Data | Ethernet Trailer]
  (Frame)

Physical layer converts to:
  [Electrical signals representing the frame bits]

At the destination, the reverse occurs (decapsulation)—each layer removes its header and passes the remaining data upward.

Key Insight: Each layer only 'sees' its own headers. A router processes IP headers but doesn't examine TCP or HTTP contents (unless specifically doing deep packet inspection). This modularity is the power of layered architecture.

Protocol Data Units (PDUs)

Each layer's encapsulated unit has a name:

• Application Layer: Message or Data • Transport Layer: Segment (TCP) or Datagram (UDP) • Network Layer: Packet • Data Link Layer: Frame • Physical Layer: Bits

Using correct terminology signals expertise and ensures clear communication among network professionals.

Addressing: Finding the Destination

For data to reach its destination, there must be a way to identify that destination uniquely. Network addressing provides this identification at multiple levels, each serving different purposes.

Address Types in Network Communication
Address Type	Layer	Format	Scope	Purpose
MAC Address	Data Link	48-bit hex (00:1A:2B:3C:4D:5E)	Local network segment	Identify device on local network
IP Address (IPv4)	Network	32-bit dotted decimal (192.168.1.100)	Global (with NAT caveats)	Route packets across networks
IP Address (IPv6)	Network	128-bit hex (2001:db8::1)	Global	Route packets, larger address space
Port Number	Transport	16-bit integer (0-65535)	Per-device	Identify application/service
Domain Name	Application	Hierarchical text (www.example.com)	Global	Human-readable addressing

The Address Hierarchy:

Addresses form a hierarchy for practical resolution:

Domain Name (www.example.com)
- Human-readable, memorable
- Resolved to IP address via DNS
- Multiple domains can point to same IP; one domain can resolve to multiple IPs
IP Address (93.184.216.34)
- Globally routable (for public IPs)
- Used by routers to forward packets toward destination
- Hierarchical: Network prefix + Host identifier
Port Number (443 for HTTPS)
- Identifies specific service on a host
- Well-known ports (0-1023) for standard services
- Combined with IP to form 'socket': 93.184.216.34:443
MAC Address (00:1A:2B:3C:4D:5E)
- Used for local delivery on the same network segment
- Resolved from IP address via ARP (Address Resolution Protocol)
- Routers change source/destination MAC at each hop; IP addresses remain constant

Complete Socket Address: A full communication endpoint is identified by: Protocol + IP Address + Port

Example: TCP connection to 93.184.216.34:443 identifies:

Protocol: TCP
Network: 93.184.216.34
Application: Port 443 (HTTPS)

address-resolution
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import socket
 
# Example: Resolving addresses in Python
 
# 1. Domain Name to IP (DNS resolution)
domain = "www.example.com"
ip_address = socket.gethostbyname(domain)
print(f"Domain {domain} resolves to IP: {ip_address}")
# Output: Domain www.example.com resolves to IP: 93.184.216.34
 
# 2. Service name to port
service = "https"
port = socket.getservbyname(service)
print(f"Service {service} uses port: {port}")
# Output: Service https uses port: 443
 
# 3. Complete socket address
socket_address = (ip_address, port)
print(f"Complete socket address: {socket_address}")
# Output: Complete socket address: ('93.184.216.34', 443)
 
# 4. Get all address info (may include IPv6)
addr_info = socket.getaddrinfo(domain, "https", proto=socket.IPPROTO_TCP)
for info in addr_info:
    family, type_, proto, canonname, sockaddr = info
    print(f"  {sockaddr} (IPv{'6' if family == socket.AF_INET6 else '4'})")

Why Multiple Address Types?

Each address type serves a specific purpose:

• MAC addresses are hardware-based, used for local switching • IP addresses provide hierarchical, routable identification globally • Ports distinguish between services on the same host • Domain names provide human usability

This separation enables each layer to evolve independently and provides flexibility (e.g., IP addresses can change while domains remain constant for users).

Routing: Navigating the Network

When source and destination aren't directly connected (almost always the case), data must navigate through intermediate devices. Routing is the process of determining the path data takes through the network.

The Routing Problem:

Consider sending data from your laptop to a server in another country:

Your laptop connects to your home router
Your router connects to your ISP
Your ISP connects to other ISPs and backbone networks
Eventually, the path leads to the destination server's network

At each step, a routing decision must be made: Which output interface leads toward the destination?

Routing Tables:

Every router maintains a routing table—a database mapping destination network prefixes to output interfaces (next hops). When a packet arrives:

Router extracts destination IP from packet header
Look up destination in routing table
Find matching entry with longest prefix match
Forward packet to indicated next hop
If no match, send to default route (or drop)

Example Routing Table (Simplified):

Destination	Prefix Length	Next Hop	Interface
10.0.0.0	/8	Local	eth0
192.168.1.0	/24	10.0.0.254	eth0
0.0.0.0	/0 (default)	10.0.0.1	eth0

Routing Methods

•Static Routing — Administrator manually configures routes. Simple, predictable, but doesn't adapt to failures. Suitable for small, stable networks.
•Dynamic Routing — Routers exchange information using routing protocols (OSPF, BGP, EIGRP). Automatically discovers paths and adapts to changes. Essential for large networks.
•Distance-Vector Routing — Routers share their entire routing tables with neighbors. Simplistic but slow to converge. Example: RIP.
•Link-State Routing — Routers share link status information; each builds complete network map. Faster convergence, more complex. Example: OSPF.
•Path-Vector Routing — Used between autonomous systems. Carries full path to prevent loops, enables policy decisions. Example: BGP.

The Internet's Routing: BGP

The Border Gateway Protocol (BGP) routes traffic between autonomous systems (networks under single administrative control—ISPs, large enterprises). BGP is critical but fragile:

• Route leaks and misconfigurations have caused global outages • BGP was designed without security; hijacking attacks are possible • BGP convergence can take minutes after major changes

Despite its age and limitations, BGP holds the Internet together. Understanding BGP is essential for anyone working with Internet-scale networks.

End-to-End Path Determination:

The full path from source to destination emerges from many independent routing decisions:

Source host consults its routing table, sends to default gateway (home router)
Home router routes toward ISP router
ISP routers (potentially many) route toward destination network's ISP
Destination ISP routers route toward destination network
Destination network routers deliver to final switch
Final switch delivers to destination host

Each router independently decides the next hop based only on destination address. No single device knows the entire path. This distributed decision-making is both the Internet's genius and its vulnerability.

Connection-Oriented vs. Connectionless Communication

Network communication follows two fundamentally different paradigms, each with distinct characteristics, advantages, and use cases.

Connection-Oriented (TCP)

•Establishes connection before data transfer (three-way handshake)
•Reliable delivery — guarantees data arrives correctly, in order
•Flow control — prevents sender overwhelming receiver
•Congestion control — adapts to network conditions
•Overhead — connection setup, acknowledgments, retransmissions
•Use cases: Web, email, file transfer, database queries
•Analogy: Phone call (establish connection, talk, hang up)

Connectionless (UDP)

•No connection setup — just send datagrams
•Unreliable — no guarantee of delivery, order, or uniqueness
•No flow/congestion control — application responsible
•Low latency — no handshake, no waiting for acknowledgments
•Low overhead — minimal header, no state maintained
•Use cases: Video streaming, gaming, VoIP, DNS
•Analogy: Postal mail (just send, no confirmation of receipt)

The TCP Three-Way Handshake:

Connection-oriented communication (TCP) establishes a connection before data transfer:

Client                                  Server
   |                                       |
   |------- SYN (seq=x) -------------------->|  Step 1: Client initiates
   |                                       |
   |<------ SYN-ACK (seq=y, ack=x+1) -------|  Step 2: Server acknowledges, initiates
   |                                       |
   |------- ACK (seq=x+1, ack=y+1) -------->|  Step 3: Client acknowledges
   |                                       |
   |       Connection Established          |
   |                                       |
   |<======== Data Transfer ================|  Bidirectional data flow
   |                                       |
   |------- FIN -------------------------->|  Connection termination begins
   |<------ ACK ---------------------------|  
   |<------ FIN ---------------------------|  
   |------- ACK -------------------------->|  
   |                                       |
   |       Connection Terminated           |

Why Three Steps? The handshake:

Establishes both parties are active
Exchanges initial sequence numbers (for ordering)
Prevents old/duplicate connection attempts from being accepted

TCP vs UDP Comparison
Characteristic	TCP	UDP
Connection Setup	Required (3-way handshake)	None
Reliability	Guaranteed delivery	Best-effort only
Ordering	Preserved	Not guaranteed
Flow Control	Yes (sliding window)	No
Congestion Control	Yes (multiple algorithms)	No
Header Size	20-60 bytes	8 bytes
Speed	Slower (due to overhead)	Faster
State	Both endpoints maintain state	Stateless
Message Boundaries	Byte stream (no boundaries)	Preserved (datagrams)

Choosing TCP vs UDP

Use TCP when: • Data must arrive completely and correctly (files, web pages, email) • Order matters (database transactions, command sequences) • Application doesn't need to handle reliability itself

Use UDP when: • Speed matters more than reliability (live video, gaming) • Application handles reliability (QUIC, some games implement their own) • Broadcast/multicast is needed (UDP supports, TCP doesn't) • Simple request-response (DNS uses UDP for speed)

Error Detection and Handling

Networks are imperfect—signals degrade, interference occurs, devices fail. The communication model must account for errors at every level.

Types of Transmission Errors

•Bit Errors — Individual bits flipped by noise or interference. Detected by checksums/CRCs.
•Packet Loss — Entire packets lost due to congestion, routing failures, or buffer overflow. Detected by missing sequence numbers, timeouts.
•Packet Reordering — Packets arrive out of order due to different paths or delays. Detected by sequence numbers.
•Packet Duplication — Same packet received multiple times. Detected by sequence numbers.
•Corruption — Packet contents altered in transit. Detected by checksums, CRCs.
•Jitter — Variable delay between packets. Causes playback issues for real-time media. Compensated by buffering.

Error Detection Mechanisms:

Checksums:

Mathematical sum of data bytes
Appended to transmission
Receiver recalculates and compares
IP header checksum, UDP/TCP checksums
Detects most random errors, but not all

Cyclic Redundancy Check (CRC):

Polynomial division-based check
More powerful than simple checksums
Used in Ethernet frames (CRC-32)
Detects burst errors effectively

Error Correction:

Forward Error Correction (FEC):

Redundant information added to data
Receiver can correct some errors without retransmission
Used where retransmission is impractical (satellite, real-time media)
Trade-off: Additional bandwidth for redundancy

Automatic Repeat Request (ARQ):

Receiver acknowledges received data
Sender retransmits if no acknowledgment (timeout)
TCP's primary reliability mechanism
Adds latency but ensures correctness

checksum-example
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
def calculate_internet_checksum(data: bytes) -> int:
    """
    Calculate Internet checksum (RFC 1071)
    Used in IP, TCP, UDP headers
    """
    # If odd length, pad with zero byte
    if len(data) % 2:
        data += b'\x00'
    
    checksum = 0
    
    # Sum all 16-bit words
    for i in range(0, len(data), 2):
        word = (data[i] << 8) + data[i + 1]
        checksum += word
    
    # Fold 32-bit sum to 16 bits (add carry)
    while checksum >> 16:
        checksum = (checksum & 0xFFFF) + (checksum >> 16)
    
    # One's complement
    return ~checksum & 0xFFFF
 
# Example usage
message = b"Hello, Network!"
checksum = calculate_internet_checksum(message)
print(f"Message: {message}")
print(f"Checksum: 0x{checksum:04X}")
 
# Verify: checksum of data + checksum should be 0xFFFF
data_with_checksum = message + checksum.to_bytes(2, 'big')
verification = calculate_internet_checksum(data_with_checksum)
print(f"Verification (should be 0xFFFF): 0x{verification:04X}")
 
# Simulate corruption
corrupted = bytearray(message)
corrupted[0] ^= 0x01  # Flip one bit
corrupted_checksum = calculate_internet_checksum(bytes(corrupted))
print(f"Corrupted checksum: 0x{corrupted_checksum:04X} (different!)")

Checksums Are Not Security

Checksums detect accidental errors, not malicious modification. An attacker can modify data AND recalculate the checksum, making changes undetectable. For security, cryptographic mechanisms (MACs, digital signatures, authenticated encryption) are required. This is why HTTPS uses TLS—it provides both integrity and authentication.

Communication Patterns

Network communication follows several patterns, each suited to different scenarios and application requirements.

Network Communication Patterns
Pattern	Description	Example Use Case	Network Mechanism
Unicast	One sender to one receiver	Web browsing, email, file transfer	Standard IP addressing
Broadcast	One sender to all receivers on network	ARP, DHCP discovery, service announcements	Special broadcast address (255.255.255.255)
Multicast	One sender to specific group of receivers	Video streaming to subscribers, stock tickers	Multicast group addresses (224.0.0.0/4)
Anycast	One sender to nearest receiver in group	DNS root servers, CDN edge servers	Same IP on multiple locations; routing chooses closest

Request-Response Pattern:

The most common application-level pattern:

Client                          Server
   |                               |
   |--- Request (GET /page.html) ->|
   |                               |
   |<-- Response (200 OK + data) --|
   |                               |

Characteristics:

Synchronous: Client waits for response
Temporary: Connection may close after exchange
Client-initiated: Server passively waits
Examples: HTTP, DNS, database queries

Publish-Subscribe Pattern:

Decouples producers and consumers:

Publisher                Broker               Subscriber(s)
    |                       |                       |
    |-- Publish (topic A) ->|                       |
    |                       |-- Notify (topic A) -->|
    |                       |-- Notify (topic A) -->|
    |                       |                       |

Characteristics:

Asynchronous: Publishers don't wait for subscribers
Topic-based: Subscribers choose what to receive
Scalable: Adding subscribers doesn't impact publishers
Examples: MQTT for IoT, Kafka for data streams, message queues

Streaming Pattern:

Continuous data flow, often unidirectional:

Sender                                        Receiver
  |                                              |
  |--- Data chunk 1 -----------------------------|
  |--- Data chunk 2 -----------------------------|
  |--- Data chunk 3 -----------------------------|
  |  ...continuous flow...                       |

Characteristics:

Long-lived connection
Often real-time (video, audio)
Unidirectional or bidirectional
May use UDP for lower latency
Examples: Netflix streaming, live broadcasts, sensor telemetry

Bidirectional Streaming (WebSocket, gRPC):

Client                                          Server
  |                                                |
  |<============ Two-way channel ==================|
  |--- Message A ----------------------------------->|
  |<---------- Message B --------------------------->|
  |--- Message C ----------------------------------->|
  |<---------- Message D --------------------------->|

Characteristics:

Full-duplex: Either side can send anytime
Persistent connection
Real-time: No request-response latency
Examples: Chat applications, collaborative editing, live dashboards

Choosing the Right Pattern

Pattern choice significantly impacts architecture:

• Request-Response suits simple, one-off exchanges • Publish-Subscribe suits event-driven, many-to-many scenarios • Streaming suits continuous data, real-time updates • Bidirectional suits interactive, collaborative applications

Many applications combine patterns—initial request-response for authentication, then bidirectional for real-time updates.

Summary: Communication Model

The communication model describes the fundamental process by which data moves across networks. Understanding this model is essential for designing applications, troubleshooting issues, and reasoning about network behavior.

Key Takeaways

•Five Elements — All communication involves sender, receiver, message, medium, and protocol. The protocol is the common language enabling understanding.
•Data Flow — Data travels through layers (encapsulation), across media and devices, then back up layers (decapsulation) at the destination.
•Addressing — Multiple address types serve different purposes: MAC for local delivery, IP for global routing, ports for application identification, domains for human usability.
•Routing — Routers make independent forwarding decisions based on destination addresses and routing tables, collectively determining paths through the network.
•Connection Types — Connection-oriented (TCP) guarantees reliability; connectionless (UDP) provides speed. Choose based on application requirements.
•Error Handling — Networks use checksums, CRCs, acknowledgments, and retransmissions to detect and recover from errors.
•Communication Patterns — Unicast, broadcast, multicast, anycast; request-response, publish-subscribe, streaming each serve different needs.

What's Next:

With the communication model understood, we'll explore network resources—the computational, storage, and bandwidth resources that networks provide and how they're shared among users. We'll examine concepts of capacity, sharing, quality of service, and resource allocation.

Page Complete

You now understand how network communication works—from the basic elements through addressing, routing, connection types, error handling, and communication patterns. This conceptual model underlies everything from web requests to video calls to IoT sensor data.

Communication Model

How Computers Communicate

Learning Objectives

By the end of this page, you will:

The Five Elements of Communication

Fundamental Elements of Network Communication
Element	Description	Network Example	Failure Mode
Sender (Source)	The entity initiating communication	Client computer requesting a web page	Sender crashes, misconfigured, no network access
Receiver (Destination)	The entity receiving communication	Web server responding to request	Server down, unreachable, overloaded
Message (Data)	The information being communicated	HTTP request, file contents, video frames	Corrupted, too large, malformed
Medium (Channel)	The physical path carrying signals	Ethernet cables, WiFi, fiber optics	Cable cut, interference, congestion
Protocol (Rules)	Agreed format and procedures	TCP/IP, HTTP, Ethernet	Incompatible versions, misconfiguration

An Analogy: Postal Mail

The communication model parallels postal mail:

Postal System	Network System
Writer	Sending application
Reader	Receiving application
Letter content	Data/message
Postal transportation	Transmission media + intermediate systems
Addressing format, postage rules	Protocols
Envelope with addresses	Packet with headers
Postal sorting facilities	Routers
Local mail carrier	Last-mile network devices

The analogy holds in important ways:

Letters can be lost, delayed, or damaged
Multiple routes may exist between two locations
The writer doesn't need to know the exact route
Standard formats (addresses, stamps) enable interoperation

The analogy breaks down in others:

Network communication can be instantaneous (vs. days for mail)
The same 'letter' can be received by millions simultaneously (multicast/broadcast)
Digital data can be perfectly copied (unlike physical letters)

The Protocol's Central Role

Data Flow Through the Network

Understanding how data flows from source to destination is fundamental to network comprehension. The process involves multiple stages, each adding value and complexity.

The Data Flow Journey

•Application Data Creation — An application (browser, email client) creates data to send. This might be an HTTP request, email message, or file contents.
•Data Segmentation — Large data is divided into smaller segments (if using TCP) or datagrams (if using UDP). Each segment is manageable for the network.
•Protocol Headers Added — Each network layer adds its headers: transport (TCP/UDP with ports), network (IP with addresses), data link (Ethernet with MAC addresses).
•Physical Transmission — The lowest layer converts digital data to physical signals (electrical, optical, radio) and sends across the medium.
•Intermediate Forwarding — Routers and switches receive signals, decode to frames/packets, make forwarding decisions, and retransmit.
•Destination Reception — The destination NIC receives signals, decodes to frames, checks for errors.
•Header Removal (Decapsulation) — Each layer strips its headers, passing data upward until the application receives the original message.

Encapsulation: The Envelope Model

As data passes down through protocol layers, each layer adds its own header (and sometimes trailer), encapsulating the layer above:

Application creates:
  [HTTP Request Data]

Transport layer adds:
  [TCP Header | HTTP Request Data]
  (Segment)

Network layer adds:
  [IP Header | TCP Header | HTTP Request Data]
  (Packet)

Data Link layer adds:
  [Ethernet Header | IP Header | TCP Header | HTTP Request Data | Ethernet Trailer]
  (Frame)

Physical layer converts to:
  [Electrical signals representing the frame bits]

At the destination, the reverse occurs (decapsulation)—each layer removes its header and passes the remaining data upward.

Protocol Data Units (PDUs)

Each layer's encapsulated unit has a name:

• Application Layer: Message or Data • Transport Layer: Segment (TCP) or Datagram (UDP) • Network Layer: Packet • Data Link Layer: Frame • Physical Layer: Bits

Using correct terminology signals expertise and ensures clear communication among network professionals.

Addressing: Finding the Destination

For data to reach its destination, there must be a way to identify that destination uniquely. Network addressing provides this identification at multiple levels, each serving different purposes.

Address Types in Network Communication
Address Type	Layer	Format	Scope	Purpose
MAC Address	Data Link	48-bit hex (00:1A:2B:3C:4D:5E)	Local network segment	Identify device on local network
IP Address (IPv4)	Network	32-bit dotted decimal (192.168.1.100)	Global (with NAT caveats)	Route packets across networks
IP Address (IPv6)	Network	128-bit hex (2001:db8::1)	Global	Route packets, larger address space
Port Number	Transport	16-bit integer (0-65535)	Per-device	Identify application/service
Domain Name	Application	Hierarchical text (www.example.com)	Global	Human-readable addressing

The Address Hierarchy:

Addresses form a hierarchy for practical resolution:

Domain Name (www.example.com)
- Human-readable, memorable
- Resolved to IP address via DNS
- Multiple domains can point to same IP; one domain can resolve to multiple IPs
IP Address (93.184.216.34)
- Globally routable (for public IPs)
- Used by routers to forward packets toward destination
- Hierarchical: Network prefix + Host identifier
Port Number (443 for HTTPS)
- Identifies specific service on a host
- Well-known ports (0-1023) for standard services
- Combined with IP to form 'socket': 93.184.216.34:443
MAC Address (00:1A:2B:3C:4D:5E)
- Used for local delivery on the same network segment
- Resolved from IP address via ARP (Address Resolution Protocol)
- Routers change source/destination MAC at each hop; IP addresses remain constant

Complete Socket Address: A full communication endpoint is identified by: Protocol + IP Address + Port

Example: TCP connection to 93.184.216.34:443 identifies:

Protocol: TCP
Network: 93.184.216.34
Application: Port 443 (HTTPS)

address-resolution
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import socket
 
# Example: Resolving addresses in Python
 
# 1. Domain Name to IP (DNS resolution)
domain = "www.example.com"
ip_address = socket.gethostbyname(domain)
print(f"Domain {domain} resolves to IP: {ip_address}")
# Output: Domain www.example.com resolves to IP: 93.184.216.34
 
# 2. Service name to port
service = "https"
port = socket.getservbyname(service)
print(f"Service {service} uses port: {port}")
# Output: Service https uses port: 443
 
# 3. Complete socket address
socket_address = (ip_address, port)
print(f"Complete socket address: {socket_address}")
# Output: Complete socket address: ('93.184.216.34', 443)
 
# 4. Get all address info (may include IPv6)
addr_info = socket.getaddrinfo(domain, "https", proto=socket.IPPROTO_TCP)
for info in addr_info:
    family, type_, proto, canonname, sockaddr = info
    print(f"  {sockaddr} (IPv{'6' if family == socket.AF_INET6 else '4'})")

Why Multiple Address Types?

Each address type serves a specific purpose:

This separation enables each layer to evolve independently and provides flexibility (e.g., IP addresses can change while domains remain constant for users).

Routing: Navigating the Network

The Routing Problem:

Consider sending data from your laptop to a server in another country:

Your laptop connects to your home router
Your router connects to your ISP
Your ISP connects to other ISPs and backbone networks
Eventually, the path leads to the destination server's network

At each step, a routing decision must be made: Which output interface leads toward the destination?

Routing Tables:

Every router maintains a routing table—a database mapping destination network prefixes to output interfaces (next hops). When a packet arrives:

Router extracts destination IP from packet header
Look up destination in routing table
Find matching entry with longest prefix match
Forward packet to indicated next hop
If no match, send to default route (or drop)

Example Routing Table (Simplified):

Destination	Prefix Length	Next Hop	Interface
10.0.0.0	/8	Local	eth0
192.168.1.0	/24	10.0.0.254	eth0
0.0.0.0	/0 (default)	10.0.0.1	eth0

Routing Methods

•Static Routing — Administrator manually configures routes. Simple, predictable, but doesn't adapt to failures. Suitable for small, stable networks.
•Dynamic Routing — Routers exchange information using routing protocols (OSPF, BGP, EIGRP). Automatically discovers paths and adapts to changes. Essential for large networks.
•Distance-Vector Routing — Routers share their entire routing tables with neighbors. Simplistic but slow to converge. Example: RIP.
•Link-State Routing — Routers share link status information; each builds complete network map. Faster convergence, more complex. Example: OSPF.
•Path-Vector Routing — Used between autonomous systems. Carries full path to prevent loops, enables policy decisions. Example: BGP.

The Internet's Routing: BGP

The Border Gateway Protocol (BGP) routes traffic between autonomous systems (networks under single administrative control—ISPs, large enterprises). BGP is critical but fragile:

• Route leaks and misconfigurations have caused global outages • BGP was designed without security; hijacking attacks are possible • BGP convergence can take minutes after major changes

Despite its age and limitations, BGP holds the Internet together. Understanding BGP is essential for anyone working with Internet-scale networks.

End-to-End Path Determination:

The full path from source to destination emerges from many independent routing decisions:

Source host consults its routing table, sends to default gateway (home router)
Home router routes toward ISP router
ISP routers (potentially many) route toward destination network's ISP
Destination ISP routers route toward destination network
Destination network routers deliver to final switch
Final switch delivers to destination host

Connection-Oriented vs. Connectionless Communication

Network communication follows two fundamentally different paradigms, each with distinct characteristics, advantages, and use cases.

Connection-Oriented (TCP)

•Establishes connection before data transfer (three-way handshake)
•Reliable delivery — guarantees data arrives correctly, in order
•Flow control — prevents sender overwhelming receiver
•Congestion control — adapts to network conditions
•Overhead — connection setup, acknowledgments, retransmissions
•Use cases: Web, email, file transfer, database queries
•Analogy: Phone call (establish connection, talk, hang up)

Connectionless (UDP)

•No connection setup — just send datagrams
•Unreliable — no guarantee of delivery, order, or uniqueness
•No flow/congestion control — application responsible
•Low latency — no handshake, no waiting for acknowledgments
•Low overhead — minimal header, no state maintained
•Use cases: Video streaming, gaming, VoIP, DNS
•Analogy: Postal mail (just send, no confirmation of receipt)

The TCP Three-Way Handshake:

Connection-oriented communication (TCP) establishes a connection before data transfer:

Client                                  Server
   |                                       |
   |------- SYN (seq=x) -------------------->|  Step 1: Client initiates
   |                                       |
   |<------ SYN-ACK (seq=y, ack=x+1) -------|  Step 2: Server acknowledges, initiates
   |                                       |
   |------- ACK (seq=x+1, ack=y+1) -------->|  Step 3: Client acknowledges
   |                                       |
   |       Connection Established          |
   |                                       |
   |<======== Data Transfer ================|  Bidirectional data flow
   |                                       |
   |------- FIN -------------------------->|  Connection termination begins
   |<------ ACK ---------------------------|  
   |<------ FIN ---------------------------|  
   |------- ACK -------------------------->|  
   |                                       |
   |       Connection Terminated           |

Why Three Steps? The handshake:

Establishes both parties are active
Exchanges initial sequence numbers (for ordering)
Prevents old/duplicate connection attempts from being accepted

TCP vs UDP Comparison
Characteristic	TCP	UDP
Connection Setup	Required (3-way handshake)	None
Reliability	Guaranteed delivery	Best-effort only
Ordering	Preserved	Not guaranteed
Flow Control	Yes (sliding window)	No
Congestion Control	Yes (multiple algorithms)	No
Header Size	20-60 bytes	8 bytes
Speed	Slower (due to overhead)	Faster
State	Both endpoints maintain state	Stateless
Message Boundaries	Byte stream (no boundaries)	Preserved (datagrams)

Choosing TCP vs UDP

Error Detection and Handling

Networks are imperfect—signals degrade, interference occurs, devices fail. The communication model must account for errors at every level.

Types of Transmission Errors

•Bit Errors — Individual bits flipped by noise or interference. Detected by checksums/CRCs.
•Packet Loss — Entire packets lost due to congestion, routing failures, or buffer overflow. Detected by missing sequence numbers, timeouts.
•Packet Reordering — Packets arrive out of order due to different paths or delays. Detected by sequence numbers.
•Packet Duplication — Same packet received multiple times. Detected by sequence numbers.
•Corruption — Packet contents altered in transit. Detected by checksums, CRCs.
•Jitter — Variable delay between packets. Causes playback issues for real-time media. Compensated by buffering.

Error Detection Mechanisms:

Checksums:

Mathematical sum of data bytes
Appended to transmission
Receiver recalculates and compares
IP header checksum, UDP/TCP checksums
Detects most random errors, but not all

Cyclic Redundancy Check (CRC):

Polynomial division-based check
More powerful than simple checksums
Used in Ethernet frames (CRC-32)
Detects burst errors effectively

Error Correction:

Forward Error Correction (FEC):

Redundant information added to data
Receiver can correct some errors without retransmission
Used where retransmission is impractical (satellite, real-time media)
Trade-off: Additional bandwidth for redundancy

Automatic Repeat Request (ARQ):

Receiver acknowledges received data
Sender retransmits if no acknowledgment (timeout)
TCP's primary reliability mechanism
Adds latency but ensures correctness

checksum-example
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
def calculate_internet_checksum(data: bytes) -> int:
    """
    Calculate Internet checksum (RFC 1071)
    Used in IP, TCP, UDP headers
    """
    # If odd length, pad with zero byte
    if len(data) % 2:
        data += b'\x00'
    
    checksum = 0
    
    # Sum all 16-bit words
    for i in range(0, len(data), 2):
        word = (data[i] << 8) + data[i + 1]
        checksum += word
    
    # Fold 32-bit sum to 16 bits (add carry)
    while checksum >> 16:
        checksum = (checksum & 0xFFFF) + (checksum >> 16)
    
    # One's complement
    return ~checksum & 0xFFFF
 
# Example usage
message = b"Hello, Network!"
checksum = calculate_internet_checksum(message)
print(f"Message: {message}")
print(f"Checksum: 0x{checksum:04X}")
 
# Verify: checksum of data + checksum should be 0xFFFF
data_with_checksum = message + checksum.to_bytes(2, 'big')
verification = calculate_internet_checksum(data_with_checksum)
print(f"Verification (should be 0xFFFF): 0x{verification:04X}")
 
# Simulate corruption
corrupted = bytearray(message)
corrupted[0] ^= 0x01  # Flip one bit
corrupted_checksum = calculate_internet_checksum(bytes(corrupted))
print(f"Corrupted checksum: 0x{corrupted_checksum:04X} (different!)")

Checksums Are Not Security

Communication Patterns

Network communication follows several patterns, each suited to different scenarios and application requirements.

Network Communication Patterns
Pattern	Description	Example Use Case	Network Mechanism
Unicast	One sender to one receiver	Web browsing, email, file transfer	Standard IP addressing
Broadcast	One sender to all receivers on network	ARP, DHCP discovery, service announcements	Special broadcast address (255.255.255.255)
Multicast	One sender to specific group of receivers	Video streaming to subscribers, stock tickers	Multicast group addresses (224.0.0.0/4)
Anycast	One sender to nearest receiver in group	DNS root servers, CDN edge servers	Same IP on multiple locations; routing chooses closest

Request-Response Pattern:

The most common application-level pattern:

Client                          Server
   |                               |
   |--- Request (GET /page.html) ->|
   |                               |
   |<-- Response (200 OK + data) --|
   |                               |

Characteristics:

Synchronous: Client waits for response
Temporary: Connection may close after exchange
Client-initiated: Server passively waits
Examples: HTTP, DNS, database queries

Publish-Subscribe Pattern:

Decouples producers and consumers:

Publisher                Broker               Subscriber(s)
    |                       |                       |
    |-- Publish (topic A) ->|                       |
    |                       |-- Notify (topic A) -->|
    |                       |-- Notify (topic A) -->|
    |                       |                       |

Characteristics:

Asynchronous: Publishers don't wait for subscribers
Topic-based: Subscribers choose what to receive
Scalable: Adding subscribers doesn't impact publishers
Examples: MQTT for IoT, Kafka for data streams, message queues

Streaming Pattern:

Continuous data flow, often unidirectional:

Sender                                        Receiver
  |                                              |
  |--- Data chunk 1 -----------------------------|
  |--- Data chunk 2 -----------------------------|
  |--- Data chunk 3 -----------------------------|
  |  ...continuous flow...                       |

Characteristics:

Long-lived connection
Often real-time (video, audio)
Unidirectional or bidirectional
May use UDP for lower latency
Examples: Netflix streaming, live broadcasts, sensor telemetry

Bidirectional Streaming (WebSocket, gRPC):

Client                                          Server
  |                                                |
  |<============ Two-way channel ==================|
  |--- Message A ----------------------------------->|
  |<---------- Message B --------------------------->|
  |--- Message C ----------------------------------->|
  |<---------- Message D --------------------------->|

Characteristics:

Full-duplex: Either side can send anytime
Persistent connection
Real-time: No request-response latency
Examples: Chat applications, collaborative editing, live dashboards

Choosing the Right Pattern

Pattern choice significantly impacts architecture:

Many applications combine patterns—initial request-response for authentication, then bidirectional for real-time updates.

Summary: Communication Model

Key Takeaways

•Five Elements — All communication involves sender, receiver, message, medium, and protocol. The protocol is the common language enabling understanding.
•Data Flow — Data travels through layers (encapsulation), across media and devices, then back up layers (decapsulation) at the destination.
•Addressing — Multiple address types serve different purposes: MAC for local delivery, IP for global routing, ports for application identification, domains for human usability.
•Routing — Routers make independent forwarding decisions based on destination addresses and routing tables, collectively determining paths through the network.
•Connection Types — Connection-oriented (TCP) guarantees reliability; connectionless (UDP) provides speed. Choose based on application requirements.
•Error Handling — Networks use checksums, CRCs, acknowledgments, and retransmissions to detect and recover from errors.
•Communication Patterns — Unicast, broadcast, multicast, anycast; request-response, publish-subscribe, streaming each serve different needs.

What's Next:

Page Complete