TCP vs UDP
- TCP — connection-oriented, reliable, ordered, congestion-controlled. The default for web traffic; pays a handshake + retransmission cost.
- UDP — connectionless, no delivery/order guarantees, low overhead. For real-time where late data is useless (live video/audio, games, DNS).
What happens when you load a URL
- DNS resolves the hostname → IP (recursive resolver → root → TLD → authoritative, cached at each layer with a TTL).
- TCP handshake (SYN/SYN-ACK/ACK) opens a connection.
- TLS handshake negotiates keys and authenticates the server's certificate (asymmetric crypto to exchange a symmetric session key) → everything after is encrypted + integrity-protected.
- HTTP request/response over that secure channel.
HTTP versions (one line each)
- HTTP/1.1 — one request at a time per connection (head-of-line blocking; browsers open several connections).
- HTTP/2 — multiplexed streams over one TCP connection, header compression.
- HTTP/3 — over QUIC (UDP), removing TCP head-of-line blocking.
Real-time: polling vs SSE vs WebSocket
| Approach | Direction | Use |
|---|---|---|
| Short polling | client pulls repeatedly | simple, wasteful, laggy |
| Long polling | server holds the request | okay fallback |
| SSE | server → client (one-way) | live feeds, notifications |
| WebSocket | full-duplex | chat, live trading, collaborative |
StockVision/StockStump push live prices over WebSocket rather than polling — the client doesn't hammer the server, and updates arrive the instant the price moves.
Pick the lightest tool that meets the need
If updates are one-way (a price ticker, a feed), SSE is simpler than WebSocket (plain HTTP, auto-reconnect). Reach for WebSocket when you need bidirectional low-latency messaging. Polling is fine for infrequent updates and is the most robust fallback.