Computer Networking: TCP, HTTP, and Web Protocols

​

TCP Connection Management

​

Three-Way Handshake

• The first two packets cannot carry data; the third ACK and all subsequent packets can.
• Sequence numbers (seq) prevent duplicate or reordered packets from being misinterpreted.
• The exchange confirms a working bidirectional path before any application data is sent.

​

Why Two Handshakes Are Not Enough

1. Historical duplicates — a delayed SYN from a previous connection can arrive and cause the server to open a connection the client never intended. With three messages the client can send a RST when it receives a SYN-ACK for a connection it did not initiate.
2. Sequence number asymmetry — the client never gets to confirm that the server’s chosen sequence number was received, so reliable communication cannot be established.

​

Four-Way Teardown

​

TIME_WAIT: What It Is and Why It Matters

• Exhausted file descriptors — each socket occupies an fd; Linux enforces limits via /proc/sys/fs/file-max, /etc/security/limits.conf, and /proc/sys/fs/nr_open.
• Exhausted ephemeral ports — client-side ports in TIME_WAIT cannot be reused; the usable range is typically 32768–61000 (tunable via net.ipv4.ip_local_port_range).

​

HTTP Versions

​

HTTP/1.0

​

HTTP/1.1

• Persistent connections (Connection: keep-alive): one TCP connection can serve multiple requests, eliminating per-request handshake cost.
• Pipelining: the client can send multiple requests without waiting for each response, though responses must still arrive in order (head-of-line blocking at the HTTP layer).
• Remaining limitations: headers are sent uncompressed on every request; server can only respond in request order; no server push.

​

HTTP/2

​

HTTP/3

• No TCP head-of-line blocking — each QUIC stream is independent; a lost packet only stalls the stream it belongs to.
• 0-RTT reconnection — QUIC can resume a prior session without a full handshake, reducing latency for returning users.
• Built-in encryption — TLS 1.3 is mandatory and integrated into the QUIC handshake.
• Connection migration — connections are identified by a connection ID, not by the 4-tuple (src IP, src port, dst IP, dst port), so mobile clients survive network changes without reconnecting.

​

GET vs POST

​

WebSocket vs SSE

​

SSL/TLS

​

TLS Handshake (RSA-based)

1. ClientHello — client sends its TLS version, a random nonce (Client Random), and a list of supported cipher suites.
2. ServerHello — server responds with the chosen cipher suite, its own random nonce (Server Random), and its CA-signed digital certificate (which contains the server’s public key).
3. Client key exchange — after verifying the certificate, the client generates a third random value (pre-master key), encrypts it with the server’s public key, and sends it. The client also signals that it is switching to encrypted communication.
4. Server finished — the server decrypts pre-master key using its private key. Both sides now derive the same session key from the three randoms and switch to symmetric encryption.

​

Certificate Chain Verification

1. Compute a hash of the certificate contents (H1).
2. Use the CA’s public key (pre-installed in the OS or browser) to decrypt the certificate’s signature, obtaining H2.
3. If H1 == H2 the certificate is authentic; otherwise the browser shows a warning.

​

Common TLS Errors

​

Security

​

CSRF

1. CSRF token — embed a per-session random token in every form (hidden field) or request header. The server rejects any request where the token is absent or wrong. Because attackers cannot read the token from a cross-origin page, they cannot forge a valid request.
2. SameSite cookie attribute — set SameSite=Strict to block cookies on all cross-site requests, or SameSite=Lax to allow safe navigations (GET) but block cross-site POSTs.
3. Referer validation — check the Referer header to ensure requests originate from your own domain. This is weaker because the header can be suppressed.

// Backend: set token in an HttpOnly cookie
res.cookie('token', accessToken, {
  httpOnly: true,     // JS cannot access (prevents XSS theft)
  secure: true,       // HTTPS only
  sameSite: 'Strict', // blocks cross-site requests
  maxAge: 1000 * 60 * 60 * 24 * 7
})

​

JWT

header.payload.signature

• Header: algorithm and token type ({"alg":"HS256","typ":"JWT"}).
• Payload: claims such as user ID, roles, and expiry. Do not store sensitive data here—it is not encrypted, only signed.
• Signature: HMAC_SHA256(base64(header) + "." + base64(payload), secret). Prevents tampering.

​

CORS

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization