Computer Networking Fundamentals

Table of Contents

• OSI 7 Layers vs TCP/IP Model
• TCP vs UDP
• TCP 3-Way Handshake & 4-Way Teardown
  • 3-Way Handshake (Connection Establishment)
  • 4-Way Teardown (Connection Termination)
  • The TIME_WAIT State
• HTTP Evolution: HTTP/1.1 vs HTTP/2 vs HTTP/3
• HTTPS & SSL/TLS Handshake
• What Happens When You Type a URL in Your Browser?
• API Protocols: REST vs gRPC vs WebSockets
• Load Balancing: Layer 4 vs Layer 7

OSI 7 Layers vs TCP/IP Model

TCP vs UDP

TCP 3-Way Handshake & 4-Way Teardown

3-Way Handshake

Establishes a reliable TCP connection between Client and Server:

Client                                  Server
  |                                       |
  | -------- 1. SYN (seq=x) ------------> |  (Client sends SYN, state -> SYN_SENT)
  |                                       |  (Server receives SYN, state -> SYN_RCVD)
  | <------- 2. SYN-ACK (seq=y, ack=x+1) -|  (Server replies with SYN + ACK)
  |                                       |  (Client receives SYN-ACK, state -> ESTABLISHED)
  | -------- 3. ACK (ack=y+1) ----------> |  (Client confirms ACK)
  |                                       |  (Server receives ACK, state -> ESTABLISHED)

• SYN Flood Attack: Attacker sends massive SYN requests without replying to SYN-ACK, exhausting the server’s backlog queue.
  • Mitigation: Enable SYN Cookies (net.ipv4.tcp_syncookies = 1), rate limiting, firewalls.

4-Way Teardown

Gracefully closes a TCP connection:

Client                                  Server
  |                                       |
  | -------- 1. FIN (seq=u) ------------> |  (Client initiates close, state -> FIN_WAIT_1)
  | <------- 2. ACK (ack=u+1) ----------- |  (Server acknowledges FIN, state -> CLOSE_WAIT)
  |                                       |  (Client receives ACK, state -> FIN_WAIT_2)
  |                                       |  [Server finishes pending data transmission]
  | <------- 3. FIN (seq=w) ------------- |  (Server sends FIN, state -> LAST_ACK)
  | -------- 4. ACK (ack=w+1) ----------> |  (Client sends ACK, state -> TIME_WAIT)
  |                                       |  (Server closes immediately)
  |  [Waits 2 * MSL (typically 60s)]      |
  v  State -> CLOSED                      |

The TIME_WAIT State

• Why is TIME_WAIT necessary?
  1. To ensure the final ACK reached the other end. If the ACK was lost, the server retransmits its FIN, and the client in TIME_WAIT can resend the ACK.
  2. To allow lingering duplicate packets from this connection to expire in the network before a new connection reuses the same port/IP tuple.
• Problem: In high-throughput microservices, thousands of short-lived connections can exhaust ephemeral ports due to sockets lingering in TIME_WAIT.
• Solution: Use HTTP Connection Keep-Alive / connection pooling; reuse sockets (net.ipv4.tcp_tw_reuse = 1).

HTTP Evolution

HTTPS & SSL/TLS Handshake

HTTPS encrypts HTTP traffic by wrapping it inside TLS (Transport Layer Security):

Client                                                Server
  |                                                     |
  | --- 1. ClientHello (TLS version, Ciphers, Nonce) -> |
  |                                                     |
  | <-- 2. ServerHello (Selected Cipher, Server Nonce)- |
  | <-- 3. Certificate (Signed by CA with Public Key) - |
  | <-- 4. ServerKeyExchange (Diffie-Hellman params) -- |
  | <-- 5. ServerHelloDone ---------------------------- |
  |                                                     |
  |  [Client validates Certificate chain against Root CAs]
  | --- 6. ClientKeyExchange (DH params or Pre-Master) ->|
  | --- 7. ChangeCipherSpec & Finished (Encrypted) ----> |
  |                                                     |
  | <-- 8. ChangeCipherSpec & Finished (Encrypted) ---- |
  |                                                     |
  | <======== Application Data Encrypted with =========>|
  | <======== Symmetric Session Key (AES-GCM) ========> |

• Asymmetric Encryption: Used during handshake to authenticate server identity and securely negotiate symmetric session keys.
• Symmetric Encryption: Used for subsequent data transfer because it is significantly faster than asymmetric encryption.

What Happens When You Type a URL in Your Browser?

1. DNS Lookup:
   • Check Browser Cache -> OS Cache (/etc/hosts) -> Local Router Cache -> ISP Resolver (Recursive DNS).
   • If not found: Root Server (.) -> TLD Server (.com) -> Authoritative Name Server (example.com).
2. TCP Handshake: Client initiates 3-way handshake with target IP address on port 443 (HTTPS) or port 80.
3. TLS Handshake: Negotiates encryption keys, validates SSL certificate.
4. HTTP Request: Browser sends GET / HTTP/2 request with headers (Host, User-Agent, Accept).
5. Server Processing: Reverse proxy (Nginx) terminates TLS, forwards request to application microservice, queries database/cache, returns HTML payload.
6. Browser Rendering: Browser receives HTTP response, parses HTML to build DOM Tree, parses CSS to build CSSOM Tree, combines into Render Tree, computes Layout, Paints pixels to screen, and executes JavaScript.

API Protocols: REST vs gRPC vs WebSockets

Load Balancing: Layer 4 vs Layer 7

Layer 4 Load Balancing (Transport Layer)

• Operates at TCP/UDP level.
• Routes traffic based on IP address and port without inspecting message content or headers.
• Pros: Blazing fast, minimal CPU overhead.
• Cons: Cannot inspect HTTP headers, cookies, or URL paths.
• Examples: AWS NLB (Network Load Balancer), Linux IPVS, HAProxy (mode tcp).

Layer 7 Load Balancing (Application Layer)

• Operates at HTTP/HTTPS level.
• Inspects path (/api/v1/orders), headers (Authorization, Host), cookies, query strings.
• Pros: Intelligent routing, SSL/TLS termination, rate limiting, path-based routing.
• Cons: Higher CPU and latency overhead due to decrypting and buffering payloads.
• Examples: AWS ALB (Application Load Balancer), Nginx, Traefik, Envoy Proxy.

Web Security & Authentication: OAuth 2.0 & Tokens

OAuth 2.0 Authorization Code Grant Flow

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to an HTTP service on behalf of a resource owner.

+----------+
| Resource |
|   Owner  |
|  (User)  |
+----------+
     ^
     |
    (1) User logs in and approves consent
     |
     v
+----------+          (2) Authorization Code          +---------------+
|  Client  | ---------------------------------------> | Authorization |
| App (SPA |                                          |    Server     |
|  / BE)   | <--------------------------------------- | (Auth0/Google)|
+----------+          (3) Access Token + Refresh      +---------------+
     |
    (4) API Request with Bearer Token
     v
+---------------+
|   Resource    |
|  Server (API) |
+---------------+

Steps in the Authorization Code Flow:

1. User Authorization: User clicks “Login with Google/GitHub”, is redirected to the Auth Server, enters credentials, and consents to permissions.
2. Authorization Code: The Auth Server redirects the user back to the application’s redirect URI with a temporary Authorization Code (single-use, short TTL).
3. Token Exchange: The application backend securely exchanges the authorization code + client secret for an Access Token and an optional Refresh Token.
4. Resource Access: The application queries protected APIs by including Authorization: Bearer <access_token> in HTTP headers.

Access Token vs Refresh Token

• Access Token:
  • Short-lived credential (e.g. 15 to 60 minutes).
  • Used to authorize API calls against resource servers.
  • Commonly structured as a JWT (JSON Web Token): Header.Payload.Signature.
  • Stateless verification: API gateways verify the token’s cryptographic signature without querying the Auth database on every request.
• Refresh Token:
  • Long-lived credential (e.g. 7 days to months) stored securely (e.g. HTTP-only secure cookie).
  • Used strictly against the Auth Server to obtain a fresh access token without forcing the user to re-authenticate when the access token expires.
  • Refresh Token Rotation: Each time a refresh token is used, a new refresh token is issued, invalidating the old one to prevent replay attacks if compromised.

Common Web Security Vulnerabilities & Mitigations

1. Cross-Site Scripting (XSS)

Occurs when an application includes untrusted data in a web page without proper validation or escaping, allowing attackers to execute malicious JavaScript in the victim’s browser (stealing cookies, session tokens, or performing unauthorized actions).

Types of XSS:

• Stored XSS: Malicious script is permanently stored on the server (e.g. database comment, user bio) and served to all users viewing the page.
• Reflected XSS: Script is reflected off a web server via query parameters or form inputs (e.g. search query in URL).
• DOM-based XSS: Vulnerability exists purely in client-side JavaScript modifying the DOM without validation (e.g. element.innerHTML = location.hash).

Mitigations:

• Context-aware Output Encoding: Escape HTML, attributes, and JavaScript (e.g. DOMPurify for user HTML).
• Content Security Policy (CSP): Restrict trusted script origins.
• HttpOnly Cookies: Prevent JavaScript from accessing session tokens via document.cookie.

2. Cross-Site Request Forgery (CSRF)

Tricks an authenticated user into executing unwanted actions on a web application in which they are currently logged in.

Mitigations:

• Anti-CSRF Tokens: Cryptographic, non-guessable tokens checked on state-changing requests (POST, PUT, DELETE).
• SameSite Cookie Attribute: Set SameSite=Strict or SameSite=Lax to prevent cookies from being sent in cross-site requests.
• Re-authentication: Require password or MFA re-entry for sensitive actions (e.g. changing password or email).

3. Clickjacking (UI Redressing)

Attackers trick users into clicking hidden buttons or iframes overlaid transparently on top of benign UI elements.

Mitigations:

• Content Security Policy: frame-ancestors 'none' or frame-ancestors 'self'.
• HTTP Header: X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN.

4. Man-in-the-Middle (MitM)

Attackers intercept network communication between client and server to eavesdrop or tamper with data.

Mitigations:

• HTTPS & TLS 1.3: Encrypt all traffic end-to-end.
• HSTS (HTTP Strict Transport Security): Strict-Transport-Security: max-age=31536000; includeSubDomains; preload forces browsers to only connect over HTTPS.

5. Content Security Policy (CSP)

HTTP response header specifying allowed content sources:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com; img-src 'self' data:; report-uri /csp-report-endpoint;

• Report-Only Mode: Content-Security-Policy-Report-Only allows testing policies without breaking live application features.