Networking Essentials

OSI model

• L3: IP: Routing. Deliver packets from a source host to a destination host, based on IP addresses.
  • the protocol that routes packets across networks using IP addresses.
• L4 (Transport Layer): TCP/UDP → provides reliable delivery (HTTP runs over TCP, port 80/443).
  • TCP - Connection-oriented, reliable delivery, guaranteed ordering, higher latency
  • UDP - machine gun. Connection less, no delivery guarantee, no ordering, lower latency. Fire & forget. Video games, video confs.
  • Browsers don’t support UDP natively. no raw UDP APIs in browsers, but browsers leverage UDP in controlled, secure protocols (WebRTC, QUIC).

    • Why browsers don’t support raw UDP

      1. Security → UDP is connectionless and easily spoofed. Letting JS open arbitrary UDP sockets would make DDoS attacks trivial.
      2. Firewall/NAT issues → UDP is harder to traverse than TCP (no built-in session like TCP handshakes).
      3. No reliability → Browsers need ordered, reliable delivery for most web content (TCP/HTTP fits better).

    • But browsers do use UDP under the hood:

      • WebRTC (RTCDataChannel, media streams) → built on UDP + DTLS + SCTP (for encryption, reliability).
      • QUIC/HTTP/3 → modern browsers use UDP internally for transport, but it’s abstracted away (apps see just HTTP/3, not raw UDP).
• L7 (Application Layer): HTTP → specifies semantics (GET / POST, headers, cookies, etc.).

Here’s a quick comparison table ✅

Feature	gRPC	REST
Protocol	HTTP/2, binary (Protobuf)	HTTP/1.1/2, text (JSON/XML)
Performance	Faster, smaller payloads	Slower, larger payloads
Streaming	Built-in bidirectional streaming	Limited (mostly request/response, SSE, WebSockets)
Typing	Strongly typed (IDL: .proto)	Weakly typed (JSON schema optional)
Tooling	Auto codegen for many languages	Widely supported, simple tools (curl, Postman)
Interoperability	Harder for browsers (needs gRPC-Web)	Native to browsers (JSON/HTTP)
Ease of use	More setup (protos, stubs)	Easier (just HTTP + JSON)
Best for	High-performance, microservices, internal APIs	Public APIs, wide client compatibility

---

👉 In short: gRPC = fast & efficient for internal microservices, REST = simpler & universal for external APIs.

---

In Server-Sent Events (SSE), the server uses plain HTTP response headers to establish and maintain the stream.

Required headers

• Content-Type: text/event-stream → tells the client this is an SSE stream.
• Cache-Control: no-cache → prevents proxies/browsers from caching the stream.
• Connection: keep-alive → keeps the HTTP connection open.

Optional / Recommended headers

• Transfer-Encoding: chunked → if server streams without knowing total length.
• Access-Control-Allow-Origin: * → for cross-origin SSE.
• X-Accel-Buffering: no (NGINX) → disables proxy buffering.
• Keep-Alive: timeout=... → may be added by server for persistent connection.

---

WebSocket is built on top of TCP.

How it works:

1. Starts as HTTP (over TCP) → The client sends an HTTP/1.1 request with Upgrade: websocket.
2. Handshake → If the server agrees, it upgrades the connection from HTTP to WebSocket.
3. Persistent TCP channel → After that, both client and server can send messages anytime (full-duplex, low latency).

---

Key points

• Transport layer: TCP (reliable, ordered, connection-oriented).
• Protocol: WebSocket (sits above TCP, after the upgrade).
• Ports: Usually 80 (ws://) or 443 (wss://, encrypted).

---

👉 In short: WebSocket = an application protocol that uses a persistent TCP connection after an HTTP handshake.

Do you want me to also compare WebSocket vs SSE vs HTTP/2 streams in a quick table?