Conversations and trust
Two handshakes happen before a single byte of your page arrives: one to agree the conversation, one to agree that the far end is who it claims.
- You can explain what the three packets of a TCP handshake establish, and why a connection can be refused instantly but hang forever.
- You can name the three things a certificate proves, and the two clock conditions that make a valid one fail.
A page load looks instant. Underneath, before any content arrives, there are two round trips of negotiation and a third to fetch the document — and on a 150 ms connection, that is half a second of pure setup.
7.1TCP: agreeing to talk
IP delivers packets. It does not promise they arrive, arrive once, or arrive in order. TCP adds those promises by keeping state at both ends.
TCP also recovers from loss. Every byte is numbered; the receiver acknowledges what it has; anything unacknowledged is sent again after a timeout. That is why a connection can survive a lost packet without you noticing — and why a lossy link turns into latency rather than errors.
The client picks a random starting sequence number and a source port, and asks to open a connection to port 443. Nothing is established yet; the server has to decide whether to allocate state.
The server acknowledges the client's sequence number and sends its own. Both sides now have a shared notion of where the byte stream starts. This is the moment a firewall must allow the return path — a stateless rule that permits only outbound SYNs will drop the rest.
The connection is open. The client can send data. One round trip has elapsed, and on a 150 ms path that is 150 ms before the first byte of anything, including the TLS handshake.
TLS starts: supported versions, cipher suites, a key share, and — in cleartext — the hostname (SNI). That hostname is how one IP address serves thousands of sites with different certificates.
The server returns its certificate chain and proves it holds the private key. The client checks the chain, the name, the validity dates, and whether the certificate has been revoked. Then both derive session keys from the key exchange.
The first HTTP request goes out encrypted. From here nothing on the path can read the URL, the headers or the body — only the addresses, the ports, the timing and the size of the response.
7.2Refused, timeout, and what each proves
| Result | What happened | Where to look |
|---|---|---|
| Connection refused | Something answered with a reset — the machine is reachable, the port is not open | The service, its bind address, its process |
| Timeout | Nothing came back at all — the packet was dropped | Firewall, route, NAT, or the host is down |
| Reset mid-session | State was lost after the connection opened | A middlebox, a timeout, or the service died |
That distinction is worth more than any single command. "Refused" means the network works and the application does not. "Timeout" means the network did not deliver the question.
7.3Certificates: what the padlock promises
A certificate is a signed statement that a particular key belongs to a particular name, valid between two dates, issued by someone your machine already trusts. It proves three things: the server holds the private key, the name matches what you asked for, and a certificate authority vouched for the binding at some point.
It does not prove the site is honest, safe, or well run. It proves you are talking to the domain you typed, over a channel nobody can read.
The most common real outage in this course is an expiry. The second most common is a clock problem: a machine five minutes behind rejects a perfectly valid certificate with "not yet valid". Both look like the site is broken and neither is a network fault. Check the dates (openssl s_client | openssl x509 -dates) and the clock (timedatectl) before anything else.
7.4HTTP/2, HTTP/3, and why the version matters
HTTP/1.1 opened a connection per request, or reused one and queued behind it. HTTP/2 multiplexes many requests over one connection, so a page with eighty assets no longer needs eighty connections — but a single lost packet still stalls every stream, because TCP delivers in order.
HTTP/3 runs over QUIC, which is built on UDP and recovers each stream independently. It also survives a change of address: your phone switching from Wi-Fi to mobile data keeps the same connection. The catch is that UDP 443 is blocked in more networks than TCP 443 is, so clients fall back — quickly, silently, and usually without anyone noticing that the optimization never applied.
A browser reports "certificate is not yet valid" for a site that works for everyone else. What is the most likely cause?
60-second recap
- TCP is state at both ends. Sequence numbers, acknowledgements and retransmission turn IP into a stream.
- Refused and timeout are different faults. One is the application, the other is the path.
- TLS proves identity, not honesty. Expiry and clock skew are the two failures that look like outages.