URI Structure and Encoding

A Uniform Resource Identifier (URI) serves as a compact string representation for resources on the internet. While often conflated with URLs, URIs actually encompass both URLs (Uniform Resource Locators) and URNs (Uniform Resource Names). The generic syntax follows this pattern:

scheme://[user:password@]host[:port]/path[?query][#fragment]

The scheme component identifies the protocol (http, https, ftp, etc.), followed by a colon and double slash. The authority section optionally contains authentication credentials, a host identifier, and port number. The path delineates the resource location, while query parameters (key-value pairs separated by ampersands) provide additional context. The fragment identifier points to a secondary resource within the primary resource.

URI encoding ensures safe transmission across networks by converting non-ASCII characters and reserved delimiters into hexadecimal byte values prefixed with percent signs:

// Encoding special characters
const original = "https://example.com/search?q=hello world";
const encoded = encodeURI(original);
// Result: https://example.com/search?q=hello%20world

// Component-specific encoding handles delimiters differently
const param = "key=value&other=test";
const componentEncoded = encodeURIComponent(param);
// Result: key%3Dvalue%26other%3Dtest

HTTP Protocol Fundamentals

HyperText Transfer Protocol operates as an application-layer protocol facilitating distributed, collaborative information systems. Deconstructing its name reveals three core aspects:

Protocol: Establishes standardized computer-to-computer communication rules, defining message formats and error handling procedures for multi-party interactions.

Transfer: Implements bidirectional data movement between endpoints (client-server or server-server). The protocol permits intermediate proxies and gateways to relay messages, enabling complex routing topologies like Client ↔ Proxy ↔ Origin Server while maintaining semantic integrity.

HyperText: Transcends plain text by encapsulating multimedia content (images, audio, video) with navigational links. HTML represents the canonical hypertext format, using markup tags to embed references to external resources that browsers render into interactive documents.

HTTP Characteristics Analysis

Architectural Strengths

Flexibility and Extensibility: HTTP maintains loose syntax constraints beyond basic formatting rules (space-delimited tokens, newline-separated fields). This permissiveness enables support for arbitrary data types through MIME-type declarations and protocol version negotiation.

Reliability: Inheriting TCP's delivery guarantees, HTTP ensures ordered, error-checked data transmission without packet loss or duplication.

Request-Response Model: Enforces strict unidirectional transaction pairing—every client request triggers exactly one server response, though intermediary nodes may act as both client and server in proxy chains.

Statelessness: Each transaction operates independently without server-side retention of previous interaction context. While this eliminates memory overhead for simple retrieval operations, it necessitates authentication tokens or session identifiers for stateful applications.

Architectural Limitations

Stateless Overhead: Applications requiring persistent context (shopping carts, login sessions) must implement explicit state management through cookies or local storage, increasing payload size and complexity.

Plaintext Vulnerability: Unencrypted HTTP headers expose sensitive metadata to network sniffers, enabling session hijacking and man-in-the-middle attacks via malicious hotspots.

Head-of-Line Blocking: Over persistent connections (HTTP/1.1), sequential request processing means a slow response blocks subsequent requests. While pipelining allows request batching, responses must still return in order, creating latency bottlenecks.

HTTP Message Architecture

Messages consist of a start-line, header fields, empty line (CRLF), and optional body:

Request Start-Line: METHOD /resource/path HTTP/version (e.g., GET /api/data HTTP/1.1)

Response Start-Line (Status-Line): HTTP/version STATUS_CODE REASON_PHRASE (e.g., HTTP/1.1 200 OK)

Headers: Case-insensitive field names followed by colons and values. Prohibited characters include whitespace and underscores in field names.

Body: Entity payload for methods like POST/PUT or response payloads containing representations.

HTTP Methods

Standardized request semantics include:

• GET: Retrieve resource representations
• HEAD: Fetch metadata without body content
• POST: Submit entity to be processed (create operations)
• PUT: Replace target resource representation (update operations)
• DELETE: Remove specified resources
• CONNECT: Establish tunnel connections for proxy traversal
• OPTIONS: Query supported methods (CORS preflight checks)
• TRACE: Diagnostic loopback testing

Content Negotiation and Transfer

Fixed-Length Transmission

The Content-Length header specifies entity body size in bytes:

const http = require('http');
const app = http.createServer();

app.on('request', (req, res) => {
  if (req.url === '/fixed') {
    const payload = "Stream Data";
    res.setHeader('Content-Type', 'text/plain');
    res.setHeader('Content-Length', Buffer.byteLength(payload));
    res.end(payload);
  }
});

app.listen(9001);

Mismatched length declarations cause truncation (undersized) or connection hangs (oversized).

Chunked Transfer Encoding

For dynamically generated content where total size remains unknown during transmission initiation:

const http = require('http');
const streamApp = http.createServer();

streamApp.on('request', (request, response) => {
  if (request.url === '/chunks') {
    response.setHeader('Content-Type', 'text/html');
    response.setHeader('Transfer-Encoding', 'chunked');
    
    response.write("<p>Initialization</p>");
    
    setTimeout(() => {
      response.write("First Segment<br/>");
    }, 500);
    
    setTimeout(() => {
      response.write("Final Segment");
      response.end();
    }, 1500);
  }
});

streamApp.listen(9002);

Format consists of hexadecimal chunk size, CRLF, chunk data, CRLF, terminating with zero-length chunk.

Range Requests for Partial Content

Large media files utilize byte-range requests to enable resumable downloads and adaptive streaming:

Client Request: Range: bytes=0-1023 (first kilobyte) or bytes=-100 (final 100 bytes)

Server Response: 206 Partial Content with Content-Range: bytes 0-1023/10000

Multiple ranges generate multipart responses with boundary delimiters:

Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5

--3d6b6a416f9b5
Content-Type: text/plain
Content-Range: bytes 0-50/100

[First 51 bytes]
--3d6b6a416f9b5
Content-Type: text/plain
Content-Range: bytes 100-150/100

[Next 51 bytes]
--3d6b6a416f9b5--

Form Data Encoding Strategies

application/x-www-form-urlencoded: Serializes key-value pairs with ampersand separators and percent-encoding for special characters:

field1=value1&field2=hello%20world

multipart/form-data: Separates fields using boundary strings, preserving binary integrity for file uploads:

Content-Type: multipart/form-data; boundary=----Boundary123

------Boundary123
Content-Disposition: form-data; name="username"

john_doe
------Boundary123
Content-Disposition: form-data; name="avatar"; filename="pic.jpg"
Content-Type: image/jpeg

[Binary data]
------Boundary123--

HTTP Proxy Mechainsms

Intermediary servers provide:

Load Distribution: Distributing traffic across backend pools using algorithms (round-robin, least-connections, consistent hashing)

Security Filtering: Traffic inspection, IP blacklisting, and DDoS mitigation

Caching Layers: Storing representations to reduce origin server load

Diagnostic Headers:

• Via: Tracks proxy hops (e.g., Via: 1.1 proxy1.example.com, 1.1 proxy2.example.com)
• X-Forwarded-For: Preserves original client IP through proxy chains
• X-Real-IP: Identifies originating client address

Proxy Protocol (v1) circumvents header modification limitations in TLS by prepending connection metadata:

PROXY TCP4 192.168.1.1 10.0.0.1 44322 443

Protocol Evolution: HTTP/1 to HTTP/3

HTTP/1.1 Improvements

• Persistent connections (Connection: keep-alive) eliminating per-request TCP handshake overhead
• Request pipelining (though limited by head-of-line blocking)
• Chunked transfer encoding
• Host header virtualization

HTTP/2 Enhancements

• Binary Framing: Splitting messages into frames for efficient parsing
• Multiplexing: Concurrent streams over single TCP connection (eliminating head-of-line blocking at application layer)
• Header Compression: HPACK algorithm utilizing static/dynamic tables and Huffman encoding
• Server Push: Proactive resource delivery (e.g., sending CSS/JS alongside HTML)
• Stream Prioritization: Weighted dependencies for resource scheduling

HTTP/3 and QUIC

• Transport Migration: Replacing TCP with QUIC over UDP to eliminate transport-layer head-of-line blocking
• Integrated Security: Combining transport and cryptographic handshakes (0-RTT or 1-RTT connections)
• Connection Resilience: Connection ID persistence across network changes (Wi-Fi to cellular handoffs)
• Independent Streams: Per-stream flow control preventing single packet loss from blocking all transfers

HTTP vs HTTPS Security Model

HTTPS layers HTTP over TLS/SSL, providing:

Encryption: Symmetric session keys established via asymmetric handshake protect payload confidentiality

Integrity: Cryptographic checksums (HMAC) detect tampering attempts

Authentication: X.509 certificates chain to trusted Certificate Authorities, preventing server impersonation

Port Distinction: HTTP defaults to 80, HTTPS to 443

TLS Handshake Process

1. ClientHello: Supported TLS versions, cipher suites, random nonce (Client Random)
2. ServerHello: Selected parameters, server certificate, Server Random
3. Key Exchange: Client encrypts Pre-Master Secret with server's public key; both parties derive session keys from Client Random + Server Random + Pre-Master Secret
4. Finished: Encrypted handshake completion messages verify key agreement

Subsequent communication uses symmetric AES/ChaCha20 encryption with shared session keys.

Transport Layer Fundamentals

TCP vs UDP

TCP:

• Connection-oriented with state management
• Ordered, reliable delivery with retransmission
• Flow control (sliding windows) and congestion avoidance
• Higher latency, overhead suitable for web, email, file transfer

UDP:

• Connectionless datagram service
• Unordered, best-effort delivery without acknowledgments
• Minimal overhead, low latency suitable for streaming, gaming, DNS
• QUIC builds reliability atop UDP while retaining its performance characteristics

Connection Lifecycle

Three-Way Handshake (Establishment):

1. SYN: Client sends synchronization packet with initial sequence number (ISN)
2. SYN-ACK: Server acknowledges (ISN+1) and provides its own ISN
3. ACK: Client confirms server ISN+1, enabling bidirectional data flow

Four-Way Termination (Teardown):

1. FIN: Initiator signals intent to close
2. ACK: Receiver acknowledges FIN
3. FIN: Receiver signals its own closure readiness
4. ACK: Initiator confirms, entering TIME_WAIT state to handle delayed packets

Managing Stateless Protocols

HTTP's statelessness requires explicit session mechanisms:

Cookies: Server-generated tokens stored client-side, transmitted via Cookie header on subsequent requests. Attributes include:

• HttpOnly: JavaScript inaccessibility (XSS protection)
• Secure: HTTPS-only transmission
• SameSite: Cross-origin request restrictions
• Max-Age/Expires: Validity duration

Sessions: Server-side state storage indexed by session ID (typically cookie-delivered). Data persists in memory, databases, or distributed caches (Redis).

JWT (JSON Web Tokens): Self-contained claims encoded and signed (HMAC/RSA), enabling stateless authentication across distributed systems without centralized session stores.

Network Architecture Layers

TCP/IP Model

Application Layer: Protocols defining application-process communication (HTTP, SMTP, DNS, FTP)

Transport Layer: Host-to-host channel services (TCP for reliability, UDP for speed)

Internet Layer: Addressing, routing, and packet fragmentation (IP, ICMP, ARP)

Network Interface: Physical addressing and media access (Ethernet, Wi-Fi)

OSI Model Extension

Additional granularity includes:

• Presentation: Data translation, encryption, compression
• Session: Session establishment, management, termination
• Data Link: Framing, error detection, MAC addressing
• Physical: Bit transmission over physical media

TCP Reliability Mechanisms

Sequence Numbers: Tagging octet streams for reordering and duplication detection

Acknowledgments: Cumulative ACKs confirm receipt up to specific sequence numbers

Retransmission: Timeout-based (RTO) and duplicate-ACK-triggered (Fast Retransmit) packet resending

Error Detection: Checksum verification of headers and payloads

Flow Control: Receiver-advertised window sizes preventing buffer overflow

Congestion Control: Dynamic transmission rate adjustment via:

• Slow Start: Exponential window growth until threshold
• Congestion Avoidance: Linear growth post-threshold
• Fast Recovery: Maintaining throughput after loss detection via triple duplicate ACKs

Web Request Lifecycle

1. URL Parsing: Browser extracts protocol, host, path, parameters
2. DNS Resolution: Recursive queries resolving hostname to IP (cached → hosts file → DNS servers)
3. TCP Connection: Three-way handshake establishing transport channel
4. TLS Negotiation: Certificate validation and key exchange (HTTPS)
5. HTTP Transaction: Request dispatch and response retrieval
6. Rendering: HTML parsing, DOM construction, CSSOM application, JavaScript execution
7. Persistent Connections: TCP reuse for subsequent resource requests (images, scripts, stylesheets)