🌐 Network Fundamentals
IP Addressing
Section titled “IP Addressing”- Every internet-connected host receives an IP address.
- IPv4 format:
a.b.c.d(0–255). Key ranges:127.0.0.1— loopback (localhost).192.168.0.0/16,10.0.0.0/8,172.16.0.0/12— private networks.
- IPv6 expands address space; design principles remain similar.
Ports & Sockets
Section titled “Ports & Sockets”- Ports (0–65,535) distinguish services on the same host.
- System ports
0–1023reserved for well-known protocols (SSH 22, DNS 53, HTTP 80, HTTPS 443). - Applications communicate via sockets:
(IP, port)pairs bound over TCP/UDP.
Transport Layer 🧳
Section titled “Transport Layer 🧳”- TCP: reliable, ordered byte stream; uses handshakes, retransmissions, congestion control.
- UDP: connectionless, best-effort delivery; lower overhead, suitable for realtime streaming.
- TLS sits above TCP to provide encryption/authentication.
IP Packets
Section titled “IP Packets”- Header: source/destination IPs, TTL, protocol, checksum.
- Payload: encapsulated TCP/UDP segment or other protocol data.
Application Communication Patterns
Section titled “Application Communication Patterns”| Pattern | Directionality | How It Works | Pros | Cons | Typical Use |
|---|---|---|---|---|---|
| HTTP request/response | Client → Server (per-request) | Open connection, send request, get response, close (or reuse via keep-alive) | Simple, ubiquitous | Stateless unless extended; polling for updates | REST APIs, static content |
| Ajax polling | Client → Server (periodic) | Client sends requests at intervals for updates | Easy to implement | Wastes bandwidth when no updates | Legacy dashboards, notifications |
| HTTP long-polling | Client ↔ Server (semi-push) | Server holds request open until data ready, then client immediately reissues | Lower latency than polling | Many open connections; still re-establishes | Chat, early realtime apps |
| WebSockets | Bidirectional | Single TCP connection upgraded; both sides push messages at will | True realtime, low overhead | Requires stateful gateway; keepalive overhead | Multiplayer gaming, trading, collaborative editing |
| Server-Sent Events (SSE) | Server → Client | Persistent HTTP stream of UTF-8 “events” | Simple one-way push, auto-reconnect | No client-to-server channel; limited browser support | Live dashboards, alerts |
Design Tips
Section titled “Design Tips”- Choose transport based on latency tolerance, reliability needs, and infrastructure support.
- Use connection pooling/keep-alive to avoid TCP handshake overhead.
- Monitor network metrics: latency (p95/p99), packet loss, retransmissions, throughput.
- Plan for NAT traversal and private networking when designing microservice connectivity.