Connections: TCP, Ports, and TLS

Table of Contents

1. From an Address to a Conversation
2. Packets Get Lost
3. TCP: A Reliable Connection
4. Ports on Both Ends
5. Why Plain HTTP Isn't Safe
6. TLS: The S in HTTPS
7. Certificates and the Padlock
8. Every Connection Costs Time
9. Try It Yourself

1. From an Address to a Conversation

After chapter 3, the browser knows the server's IP address. Now it needs to actually talk to it — and HTTP needs something better than loose packets to talk over. It needs a connection: a two-way channel where whatever one side sends arrives at the other side, complete and in order.

Building that takes two layers, stacked like this:

 ┌──────────────────────────────┐
 │ HTTP     the actual request  │  Chapters 5–6
 ├──────────────────────────────┤
 │ TLS      encryption          │  This chapter
 ├──────────────────────────────┤
 │ TCP      reliable delivery   │  This chapter
 ├──────────────────────────────┤
 │ IP       packets + addresses │  Chapter 3
 └──────────────────────────────┘

Each layer only worries about its own job and trusts the layer below. HTTP doesn't care how the bytes get there; IP doesn't care what they mean.

2. Packets Get Lost

IP on its own makes no promises. When your data is split into packets and sent across fifteen routers:

• Some packets may get lost — a busy router drops them, or Wi-Fi interference corrupts them.
• Some may arrive out of order, because they took different routes.
• Some may arrive twice.

For a video call, a lost packet is a tiny glitch, and that's fine. For a web page, it's not fine at all. If one packet in the middle of an HTML file goes missing, the page is broken.

3. TCP: A Reliable Connection

TCP — the Transmission Control Protocol — fixes this. It's the layer on top of IP that turns unreliable packets into a reliable stream of bytes:

• It numbers every piece of data, so the receiver can put them back in order.
• The receiver sends back acknowledgements: "I got everything up to number 5,000."
• Anything not acknowledged in time is sent again.
• Duplicates are thrown away.

Before any data is sent, the two sides set up the connection with a quick exchange called the three-way handshake:

 Client                         Server
   │ ── SYN ──────────────────▶   │   "Can we talk?"
   │ ◀────────────── SYN-ACK ──   │   "Yes, can you hear me?"
   │ ── ACK ──────────────────▶   │   "Yes. Let's go."
   │                              │
   │ ══ data flows both ways ══   │

To your program, all of this is invisible. Just like the Input/Output chapter of How Computers Work said, a network connection looks like a file: you write bytes in one end and read them out the other. TCP does the hard work underneath.

(TCP has a sibling called UDP that skips all the reliability work for speed — used for things like video calls, games, and DNS lookups. Networking for Developers compares the two properly.)

4. Ports on Both Ends

In chapter 2 you met the port: the number that picks which program on the server you want. https uses 443; http uses 80.

But a connection has a port on both ends. Your browser also gets a port — a random, temporary one picked by your operating system, like 52814. So a single connection is really identified by four things:

 your IP : your port   ⇄   server IP : server port
 192.168.1.23:52814    ⇄   185.199.108.153:443

That's how one browser can have dozens of connections open to the same server at once, and how your computer knows which tab each reply belongs to: every connection has a different port on your side.

On the server, the web server process asks the operating system to listen on port 443. When a connection arrives for that port, the OS hands it to that process. Only one process can listen on a port at a time — which is why you get an error like EADDRINUSE or "port is already allocated" when you start a second dev server on port 3000.

5. Why Plain HTTP Isn't Safe

HTTP sends everything as plain text. Remember from chapter 3 that your packets pass through many routers you don't control: your café's Wi-Fi, your internet provider, networks in other countries. With plain HTTP, any of them can:

• Read everything: the pages you visit, the forms you submit, your password, your cookies.
• Change things: inject ads, swap a download for malware, alter the page you see.
• Pretend to be the site, and you'd have no way to tell.

On public Wi-Fi, the first one takes almost no skill. That's why the web moved to HTTPS, and why browsers now mark plain HTTP pages as Not secure.

6. TLS: The S in HTTPS

HTTPS is simply HTTP sent inside a TLS connection. TLS — Transport Layer Security (you'll still hear its old name, SSL) — sits between TCP and HTTP and gives you three guarantees:

Right after the TCP handshake, the browser and server do a TLS handshake. In short:

1. The browser says hello and lists the encryption methods it supports.
2. The server replies with its choice and its certificate — its ID card (next section).
3. The browser checks the certificate.
4. Both sides use some clever maths to agree on a secret key that only they know — even though everyone in the middle saw the whole exchange.
5. From then on, everything — including the HTTP request — is encrypted with that key.

What stays visible to people in the middle? The IP addresses, the domain name you're connecting to, and roughly how much data moves and when. What's hidden: the path, the query string, the headers (including cookies), and the body. So someone on your café Wi-Fi can see you visited github.com, but not which repository or what you typed.

7. Certificates and the Padlock

A certificate is a small file that says, in effect:

"This public key belongs to *.github.io. Valid until next March. Signed, a certificate authority."

A certificate authority (CA) is an organisation that checks you really control a domain before signing a certificate for it. Your operating system and browser come with a built-in list of CAs they trust. When a server presents a certificate, the browser checks:

• Is it signed by a CA I trust?
• Does the name on it match the domain I asked for?
• Has it expired?

If any check fails, you get a full-page warning like "Your connection is not private". Take those seriously — on a site you don't control, don't click past them.

Certificates used to cost money. Today, Let's Encrypt gives them away for free and automatically, and hosts like GitHub Pages, Vercel, and Cloudflare handle them for you. There's no reason for any site to use plain HTTP anymore.

One important limit: the padlock means the connection is private, not that the site is honest. A scam site at paypa1-login.com can have a perfectly valid certificate for paypa1-login.com. The padlock tells you who you're talking to. It's still your job to check that it's who you meant.

8. Every Connection Costs Time

Count the round trips — messages that have to go to the server and come back — before the first byte of your page arrives:

 DNS lookup           ~1 round trip   (if not cached)
 TCP handshake         1 round trip
 TLS handshake         1 round trip   (TLS 1.3; older versions took 2)
 HTTP request          1 round trip

If the server is in Singapore and each round trip from Phnom Penh takes 40 milliseconds, that's about 160 ms before anything shows up. If the server is in the United States, at 250 ms per round trip, it's a whole second.

This is why browsers work hard to reuse connections. Once a connection to a server is open, the browser keeps it alive and sends the next requests over it, skipping DNS, TCP, and TLS entirely. Newer versions of HTTP push this further: HTTP/2 sends many requests at once over one connection, and HTTP/3 combines the TCP and TLS handshakes into one. You'll see h2 or h3 in DevTools; the requests and responses inside are the same as the ones in the next two chapters.

9. Try It Yourself

1. Watch a connection open. Run:

   curl -v -o /dev/null https://dara-sok.github.io/my-site/
   

   Copy

   -v (verbose) shows what curl is doing, and -o /dev/null throws away the page itself so it doesn't fill your screen — the same /dev/null from Command Line Basics. Near the top you'll find lines like these (trimmed — yours will differ):

   *   Trying 185.199.108.153:443...
   * Connected to dara-sok.github.io (185.199.108.153) port 443
   * TLSv1.3 (OUT), TLS handshake, Client hello (1):
   * TLSv1.3 (IN), TLS handshake, Server hello (2):
   * Server certificate:
   *  subject: CN=*.github.io
   *  expire date: …
   *  subjectAltName: host "dara-sok.github.io" matched cert's "*.github.io"
   *  SSL certificate verify ok.
   

   Copy

   Match each line to this chapter: the IP from DNS, TCP connecting to port 443, the TLS handshake, and the browser-style certificate checks.

2. Inspect a certificate in the browser. Click the icon to the left of the address bar on any HTTPS site, then look for the certificate details. Who issued it? When does it expire?

3. See the timing. In DevTools → Network, click the first request on a page you haven't visited today, then open the Timing tab. Find DNS Lookup, Initial connection, and SSL. Reload the page and look again — they should mostly disappear, because the connection was reused.

4. Spot the warning. Visit http://neverssl.com (a site that stays on plain HTTP on purpose). What does your browser show in the address bar?

The connection is open and encrypted. In the next chapter, the browser finally sends its request.