Roadmap › Networking & Hosting — How a Website Works, End to End › Module: Network Foundations
Lessons in this course (12)
4. TCP vs UDP and the TLS handshake (HTTPS)
Intermediate★ Must knowLesson 4 of 12
| TCP | UDP | |
|---|---|---|
| Connection | Yes — three-way handshake | No — just send datagrams |
| Reliability | Acknowledgements, retransmission, ordering | None — packets may be lost/reordered |
| Flow/congestion control | Yes | No (app decides) |
| Overhead / latency | Higher | Lower |
| Used by | HTTP/1.1, HTTP/2, SQL Server (TDS), SMTP, SSH | DNS, video calls, gaming, streaming, QUIC (HTTP/3) |
TCP three-way handshake: client SYN → server SYN-ACK → client ACK (one round trip before any data). Closing: FIN/ACK exchange; the closing side keeps TIME_WAIT for a while — why creating a new HttpClient per request can exhaust ports.
TLS 1.3 handshake (simplified, one round trip):
- Client Hello — supported ciphers, key share, SNI (which hostname it wants).
- Server Hello — chosen cipher, its key share, certificate, signature.
- Client verifies the certificate: issued by a trusted CA (chain to a root in the OS/browser store), not expired, hostname matches, not revoked.
- Both derive the same session keys (Diffie-Hellman) → encrypted HTTP flows.
HTTPS gives confidentiality (encryption), integrity (no tampering) and authentication (you're talking to the real shop.com). It does not make the application itself secure.
Certificates: DV (domain validated — Let's Encrypt, free, 90 days), OV/EV (organisation checks). Wildcard *.shop.com; SAN certificates list several names. Private key must stay secret on the server/Key Vault.