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
- Security → UDP is connectionless and easily spoofed. Letting JS open arbitrary UDP sockets would make DDoS attacks trivial.
- Firewall/NAT issues → UDP is harder to traverse than TCP (no built-in session like TCP handshakes).
- 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:
- Starts as HTTP (over TCP) → The client sends an HTTP/1.1 request with
Upgrade: websocket. - Handshake → If the server agrees, it upgrades the connection from HTTP to WebSocket.
- 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?