language: en kae3g ← back to index
(unlisted) — This essay is not shown on the main index but remains accessible via direct link

kae3g 9592: Networking Basics - Sockets and Protocols

Phase 1: Foundations & Philosophy | Week 4 | Reading Time: 17 minutes

What You'll Learn

Prerequisites

Networks: Rivers Between Gardens

Filesystem (Essay 9590): Organize data within one machine.

Networking: Connect across machines.

Plant lens: "Networks are irrigation channels—water (data) flows between gardens (computers), nourishing the entire valley (internet)."

Key insight: The internet is just processes on different machines talking to each other.

The TCP/IP Stack

Internet uses layers (each handles different concern):

Application Layer (HTTP, SSH, DNS)
    ↓ "What to send"
Transport Layer (TCP, UDP)
    ↓ "How to send reliably"
Internet Layer (IP)
    ↓ "Where to send"
Link Layer (Ethernet, WiFi)
    ↓ "Physical transmission"

Each layer talks to its peer on the other machine:

Your Computer                  Remote Computer
    App (HTTP)  ←→ HTTP ←→        App (HTTP)
    TCP         ←→ TCP  ←→        TCP
    IP          ←→ IP   ←→        IP
    Ethernet    ←→ ...  ←→        Ethernet

This is composition (Essay 9510 - Unix philosophy). Each layer does one thing well.

IP Addresses: Finding Machines

Every machine on the internet has an IP address:

IPv4 (old, but still dominant):

192.168.1.100  (4 numbers, 0-255 each)

Private ranges (not routable on internet):
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

Public: Everything else (globally unique)

IPv6 (new, larger address space):

2001:0db8:85a3:0000:0000:8a2e:0370:7334

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

Why IPv6? IPv4 has ~4 billion addresses (running out!). IPv6 has 340 undecillion (enough for every grain of sand on Earth).

Check your IP:

# Local network IP
ip addr show  # Linux
ifconfig      # macOS

# Public IP
curl ifconfig.me

Ports: Finding Processes

IP address finds the machine. Port finds the process.

Port numbers:

0-1023:    Well-known (HTTP=80, HTTPS=443, SSH=22)
1024-49151: Registered (apps can request)
49152-65535: Dynamic (OS assigns temporarily)

Example:

http://example.com:80/
│                  └─ Port 80 (HTTP)
└─ Domain name (becomes IP via DNS)

ssh user@192.168.1.100:22
         │              └─ Port 22 (SSH)
         └─ IP address

One machine can run multiple services (different ports):

Server:
  - Web server: port 80 (HTTP)
  - SSH daemon: port 22 (SSH)
  - Database: port 5432 (PostgreSQL)
  - API server: port 3000 (custom)

Plant lens: "IP address is the garden's location, port is the specific plot within that garden."

DNS: Names to Numbers

Humans prefer names (google.com) over numbers (142.250.185.46).

DNS (Domain Name System) translates:

# Query DNS
nslookup google.com

# Output:
# Server: 8.8.8.8
# Address: 8.8.8.8#53
# 
# Name: google.com
# Address: 142.250.185.46

How it works:

1. You type "google.com" in browser
2. Browser asks DNS server: "What's the IP for google.com?"
3. DNS server responds: "142.250.185.46"
4. Browser connects to that IP

DNS hierarchy:

.                  (root)
├── .com           (top-level domain)
│   └── google.com (second-level)
│       └── www.google.com (subdomain)
└── .org
    └── wikipedia.org

Like filesystem (Essay 9590), but for domain names!

TCP vs UDP

TCP (Transmission Control Protocol)

Reliable:

Use cases:

Cost: Overhead (connection setup, acknowledgments).

UDP (User Datagram Protocol)

Unreliable (but fast):

Use cases:

Benefit: Lower latency (no connection overhead).

Trade-off: Reliability vs speed.

Sockets: Programming Interface

A socket is an endpoint for communication:

# Server (listens)
import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('0.0.0.0', 8080))  # Listen on port 8080
server.listen()

while True:
    client, addr = server.accept()  # Wait for connection
    client.send(b"Hello, client!")
    client.close()

# Client (connects)
import socket

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('localhost', 8080))  # Connect to server
data = client.recv(1024)
print(data)  # Output: b"Hello, client!"
client.close()

This is how all internet communication happens (web servers, SSH, databases, etc.).

Client-Server vs Peer-to-Peer

Client-Server

One server, many clients:

Server (always running)
    ↑
    ├── Client 1 (connects when needed)
    ├── Client 2
    └── Client 3

Examples: Web (browser → server), email, databases.

Pros: Centralized, easy to manage
Cons: Single point of failure, server must scale

Peer-to-Peer (P2P)

All nodes equal (each is both client and server):

Peer 1 ←→ Peer 2
  ↕         ↕
Peer 3 ←→ Peer 4

Examples: BitTorrent, IPFS, Urbit (Essay 9503 - Nock), Bitcoin.

Pros: Decentralized, resilient, scales naturally
Cons: Complex (discovery, NAT traversal)

Sovereignty perspective (from 9503, 9960): P2P = no central authority (digital sovereignty!).

The OSI Model (Historical)

OSI (Open Systems Interconnection) defined 7 layers:

7. Application  (HTTP, FTP, SSH)
6. Presentation (SSL, compression)
5. Session      (connections, dialogs)
4. Transport    (TCP, UDP)
3. Network      (IP, routing)
2. Data Link    (Ethernet, WiFi)
1. Physical     (cables, radio waves)

TCP/IP simplified to 4 layers:

Application (combines OSI 5-7)
Transport   (OSI 4)
Internet    (OSI 3)
Link        (combines OSI 1-2)

Why simplify? OSI was designed (committee, spec-first). TCP/IP was evolved (implemented, working code first).

Result: TCP/IP won (simpler, proven in practice).

Plant lens: "OSI = ornamental garden (beautiful design). TCP/IP = working farm (produces food)."

Practical Networking

Check Connections

# Active connections
netstat -an  # All connections, numeric

# Or (modern):
ss -tuln  # TCP, UDP, listening, numeric

# Who's connected?
netstat -tn  # TCP, no DNS lookup

Test Connectivity

# Ping (ICMP echo)
ping google.com
# See if host is reachable

# Trace route
traceroute google.com
# See path packets take

# DNS lookup
nslookup google.com
# Or:
dig google.com

Listen on Port

# Simple HTTP server (Python)
python3 -m http.server 8000
# Serves current directory on http://localhost:8000

# Test with curl
curl http://localhost:8000

Try This

Exercise 1: Explore Network Stack

# What's listening?
sudo lsof -i -P -n | grep LISTEN

# Example output:
# sshd   1000 root   3u  IPv4  TCP *:22 (LISTEN)
# nginx  2000 www    6u  IPv4  TCP *:80 (LISTEN)

Observe: Process, port, protocol.

Exercise 2: HTTP from Scratch

# Connect to web server manually
telnet example.com 80

# Type (then press Enter twice):
GET / HTTP/1.1
Host: example.com

# Server responds with HTML!
# (HTTP is just text over TCP)

Insight: "High-level" protocols (HTTP) are just text (Essay 9560!).

Exercise 3: DNS Investigation

# DNS lookup
dig google.com

# Output shows:
# - Query (what you asked)
# - Answer (IP address)
# - Authority (which DNS server answered)
# - TTL (how long to cache)

# Reverse lookup (IP → name)
dig -x 8.8.8.8
# Answer: dns.google.

Going Deeper

Related Essays

External Resources

Reflection Questions

  1. Why TCP for web, UDP for video? (Reliability vs latency trade-off)
  2. Is DNS a single point of failure? (Centralized naming - what if it goes down?)
  3. Why did P2P lose to client-server? (BitTorrent, Napster shut down - but why?)
  4. Can networking be more secure by default? (Current internet: trust all traffic - bad assumption)
  5. What would Nock-based networking look like? (All messages as nouns, provably correct protocols?)

Summary

Networking Fundamentals:

TCP/IP Stack:

Key Concepts:

Protocols:

Architectures:

Key Insights:

In the Valley:

Plant lens: "Networks are irrigation channels—data flows like water between gardens (machines), nourishing the entire valley (internet ecosystem)."

Next: We'll explore concurrency—how to do multiple things simultaneously, threads vs processes, and the coordination challenges that arise!

Navigation:
← Previous: 9592 (permissions who can do what) | Phase 1 Index | Next: 9594 (concurrency threads parallelism)

Metadata:

Copyright © 2025 kae3g | Dual-licensed under Apache-2.0 / MIT
Competitive technology in service of clarity and beauty

← back to index