Connection setup: TCP, TLS, and the HTTP versions

Objectives

By the end of the lesson, you can say what TCP provides and what TLS provides, you can describe the steps of connection setup, and you know the main differences between HTTP/1.1, HTTP/2, and HTTP/3.

Why is the IP address not enough?

Knowing the IP address does not mean that the browser can send an HTTP request. Two problems have to be solved. On one hand, the network forwards data in smaller pieces, which can be lost, delayed, or reordered, while the browser needs an ordered, complete stream of data. On the other hand, the traffic also passes through foreign machines, so something is needed to protect it and to ensure that we are really talking to the service we are looking for. The first task is solved by TCP, the second by TLS.

The steps in sequence

flowchart LR
    N[Host name and IP address] --> T[TCP connection]
    T --> L[TLS handshake]
    L --> H[HTTP messages]

The path of a traditional HTTPS connection: after name resolution the browser builds a TCP connection, performs a TLS handshake over it, and only then sends the HTTP request.

TCP: an ordered, reliable data stream

TCP (Transmission Control Protocol) provides, according to RFC 9293, a "reliable, in-order, byte-stream service" to applications. It establishes a connection between the two endpoints, notices missing data from sequence numbers, filters out faulty segments with a checksum, and makes up for them by retransmission. The port number identifies which service we turn to (see 2.1). This way the browser does not have to piece together the missing or swapped parts of the HTML itself.

TCP does not interpret the web path, the HTTP status code, or the HTML, it only handles the transport of data. Even with a successful TCP connection the TLS handshake or the application can fail. Separating the layers is therefore a diagnostic tool: "I cannot connect" is different from "I got a 404".

TLS: protected communication

TCP provides an ordered transfer, but it does not encrypt and does not authenticate the provider. TLS (see 1.1) provides three properties: confidentiality (an outsider cannot read it), integrity (a modification cannot go unnoticed), and authentication (the server proves it is who it says it is). The current description of TLS 1.3 is RFC 9846; this is a minor update that replaces the original RFC 8446 (2018) and describes the same protocol version.

The steps of the handshake in TLS 1.3 (based on the RFC):

1. The client sends an offer (ClientHello): what parameters it supports, and key-agreement data.
2. The server responds: it selects the parameters, sends its certificate and a signature with which it proves that it owns the private key belonging to the certificate.
3. The client checks the certificate and completes the handshake. After that the data flows encrypted.

The basic handshake needs one round trip (1-RTT, round trip time) before application data is sent. The RFC also describes a 0-RTT variant, in which the client can already send data in its first message based on an earlier connection, but at the price of security compromises.

The certificate binds the server's key to a domain name, and through a chain of trust can be traced back to a certificate authority known to the browser. The browser checks the validity and trustworthiness of the certificate, and whether it is for the name that was opened. The certificate identifies the server for the domain name, not the user (login is an application-level question, chapter 7).

The data of a real certificate (openssl output from the server of example.com, 11 October 2026):

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com
Protocol: TLSv1.3
Verify return code: 0 (ok)

You can see the name (example.com and the *.example.com wildcard pattern), the issuer, the validity period (about 90 days), and that the connection was established with TLS 1.3.

HTTP versions: the same meaning, different packaging

The concepts of HTTP (method, path, status code, headers, body) are common across versions (RFC 9110). The versions differ in how they carry the message on the network.

Version	Characteristics	Transport
HTTP/1.1	Text messages; persistent connections (several requests over one TCP connection); a slow response holds up those waiting behind it (head-of-line blocking), so browsers open several connections	TCP (+TLS)
HTTP/2	Binary framing; multiplexing (several requests in parallel over a single connection); header compression	TCP (+TLS)
HTTP/3	The same semantics, but over the QUIC protocol; a lost packet stops only the affected stream	QUIC, over UDP (TLS 1.3 is built in)

The disadvantage of HTTP/2 is that it runs over a single TCP connection: according to RFC 9114, a lost or reordered packet stalls all transactions in progress, even if the others are not affected. HTTP/3 avoids this because QUIC handles reliability per stream. QUIC (RFC 9000) travels in UDP datagrams, and uses the TLS 1.3 handshake for key agreement. (QUIC is the name of the protocol; we do not treat it as an abbreviation here.)

Can the client find out which version it can use? During the TLS handshake the client and the server negotiate the application protocol (ALPN, Application-Layer Protocol Negotiation). A real example from curl -v output:

* ALPN: curl offers h2,http/1.1
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* using HTTP/2
< HTTP/2 200
< alt-svc: h3=":443"; ma=86400

The client offered h2 and http/1.1, the server chose h2, that is HTTP/2. The alt-svc header advertises that the service is also available as h3 (HTTP/3) on the same port; the client can make use of this on the next connection. (In this version curl did not use HTTP/3; browsers switch according to their support.)

Cost and connection reuse

Name resolution, the TCP connection, and the TLS handshake take time, but they do not have to be started from scratch for every request. The connection can be reused for several requests. Running the same curl call with two requests:

request 1: connect=0.047  tls=0.065  ttfb=0.085  total=0.085  new_conn=1
request 2: connect=0.000  tls=0.000  ttfb=0.020  total=0.020  new_conn=0

The time of the first request includes the connection and the TLS handshake (the times are in seconds, counted from the start of the request). The second request used the same connection (new_conn=0), so only about 20 ms was needed until the first byte. The timescale in a browser may differ, but the principle is the same: an already established connection saves the handshakes.

It is also important that the teaching diagram is a simplification: not every page opening repeats the whole sequence (cache, reused connection), and not every HTTPS connection runs over TCP (HTTP/3).

Worked example: the connection of Kurzuspont

A student opens Kurzuspont from the library network. The browser gets the address from DNS, builds a TCP connection to port 443, performs a TLS handshake, checks whether the certificate is for the name kurzuspont.example (in the example, the certificate of a fictional service), and meanwhile negotiates the HTTP version. If this succeeded, it sends the GET /kurzusok request. If the certificate has expired, the browser warns, and not even an HTTP request is started: no status code, no page.

Where does it get stuck?	Symptom	What has not happened yet?
DNS	"The server cannot be found"	connection
TCP	timeout, refused connection	TLS, HTTP
TLS	certificate error	HTTP request
HTTP	status code (404, 500...)	– (the server responded)

Common misconceptions

Statement	Clarification
"TCP encrypts."	TCP provides reliable transport; TLS provides protection.
"After the DNS answer the page appears immediately."	A connection, an HTTP response, and browser processing are needed too.
"The certificate proves the user's login."	It serves the authentication of the server.
"Every HTTPS connection goes over TCP."	HTTP/3 uses QUIC, which runs over UDP.
"HTTP/2 means something different from HTTP/1.1."	It packages the same concepts differently.

In brief

• TCP provides a reliable, ordered byte stream; TLS provides confidentiality, integrity, and server authentication.
• During the handshake the server presents a certificate and proof of owning the key.
• HTTP/1.1, HTTP/2, and HTTP/3 carry the same meaning differently; HTTP/3 uses QUIC.
• The connection can be reused, so not every request pays for the full handshake.
• Separating the layers helps tell where the request got stuck.

Review questions

1. What is the difference between the tasks of TCP and TLS?
2. Why does the browser get no status code if the certificate has expired?
3. What is multiplexing, and what is the main disadvantage of HTTP/2 compared with HTTP/3?
4. How does the client know whether to use HTTP/2 or HTTP/1.1?

Learning resources

• Transmission Control Protocol, RFC 9293 — the official description of TCP; advanced reading.
• The Transport Layer Security (TLS) Protocol Version 1.3, RFC 9846 — the official description of TLS 1.3; advanced reading.
• Transport Layer Security (MDN) — what TLS provides.
• Evolution of HTTP (MDN) — the history of the HTTP versions.
• HTTP/3, RFC 9114 and QUIC, RFC 9000 — advanced reading.