HTTP is stateless and TLS is a handshake tax: the protocol stack as a constraint

A page load is a sequence of agreements with a protocol stack, and two of them shape what a designer can promise. HTTP is stateless by design, so any memory of who a person is must live somewhere other than the request. TLS charges a handshake of round trips before any useful byte can be sent. Neither cost can be wished away, because both are the price of properties that made the web work at scale. The designer's real choice is between paying those costs repeatedly and amortising them across reuse, resumption and newer transports. HTTP/2, QUIC and HTTP/3 are successive answers to one question. Who pays, when, and how often? The unit that follows asks who may reuse an answer the connection already paid for.

Statelessness was chosen, not inherited

Fielding and Taylor (2002) reconstructed the web's design rationale from the constraints a distributed hypermedia application must satisfy. Their REST style emphasises scalability of component interactions, generality of interfaces, independent deployment of components, and intermediaries that reduce interaction latency and enforce security. A stateless request is what makes those properties possible. Because each request carries what it needs, any server can answer it, and an intermediary can be inserted without either endpoint being told. Fielding, Nottingham and Reschke (2022) state the design plainly. They describe HTTP as a stateless application-level protocol, whose shared semantics and self-descriptive messages are held separate from how they are encoded on the wire.

The protocol remembers nothing, so every mechanism that does remember must live beside it: cookies for session identity, an authentication framework for identity, caches for answers already received.

The handshake is a toll collected in round trips

Dierks and Rescorla (2008) fixed TLS 1.2's two-round-trip handshake, requiring two exchanges before application data could flow, and they included session resumption as the way to avoid repeating it. Rescorla (2018) reduced it to a single round trip in TLS 1.3, or none where a prior session is resumed, and removed the legacy options that had accumulated. The specification is narrower than designers often assume: it is designed to prevent eavesdropping, tampering and message forgery, does not specify how a protocol adds security with it, and leaves initiating the handshake and interpreting certificates to the protocols that run on top.

Two round trips before the first byte is a price per connection, scaling with connections rather than page size: a site whose critical content sits on four origins pays the toll four times before showing anything. A fixed charge in round trips is a larger share of the wait on a slow link, so the toll falls hardest on the reader with the least bandwidth.

A worked instance fixes the size. On a path with a 50 millisecond round trip, the two-round-trip handshake of TLS 1.2 spends 100 milliseconds before the first application byte. The single round trip of TLS 1.3 spends 50. The revision therefore halves a fixed charge that does not shrink with a faster link, and a resumed session spends none. This is arithmetic on the specified round trips rather than a measurement, and it ignores the time the server spends computing keys.

One connection was made to do the work of many

Belshe and Peon (2015) added a binary framing layer to HTTP/2 that carries multiplexed streams over a single connection, with header compression and server push, removing the many-connection workarounds HTTP/1.1 had acquired. Iyengar and Thomson (2021) put the transport itself in the application's hands: QUIC builds reliability, congestion control and encryption over UDP, gives a connection an identifier that survives a change of network path, and completes its handshake in fewer round trips. Bishop (2022) mapped HTTP onto that transport in HTTP/3, so each stream is independent at the transport layer and TCP's head-of-line blocking on multiplexed streams disappears.

The deployed evidence is mixed, and the binding constraint was the trust setup

The deployed evidence is more mixed than the specifications imply, and that gap is the honest centre of the unit. Langley and colleagues (2017) reported that QUIC was deployed at Google on thousands of servers and estimated that 7 per cent of Internet traffic was then QUIC, with measured gains in connection establishment and search latency. Ruth and colleagues (2018) found concentration from the other direction: QUIC-capable addresses had more than tripled to over 617,590, but of roughly 161,000 domains on that infrastructure only about 15,000 presented valid certificates over QUIC, and Google pushed up to 42.1 per cent of its own traffic that way.

Varvello and colleagues (2016) had already shown that an advertised version is not a delivered one. Monitoring the Alexa top million for eleven months, they found 68,000 sites reporting HTTP/2 support, of which only about 10,000 served content with it. Trevisan and colleagues (2021) found HTTP/3 adoption substantial, but its gain over HTTP/2 depended on network conditions and was sometimes absent altogether.

The handshake is only part of the cost of encryption. Aas and colleagues (2019) described the automated certificate authority that removed the human step from issuance and renewal, reporting over 538 million certificates issued for 223 million domain names by January 2019. The binding constraint on universal encryption was not the handshake's cryptography but the operational cost of obtaining and replacing a certificate by hand.

Contested question: do the newer transports deliver the latency they promise?

The literature disagrees about whether the amortisation on offer is realised for users. One position takes the deployed evidence as proof: Langley and colleagues (2017) document QUIC at internet scale with measured gains, and the specifications are built to shorten setup and remove blocking, so the lever works and the remaining task is to pull it.

The opposing position holds the gains conditional and often unrealised. Varvello and colleagues (2016) found most sites advertising HTTP/2 did not serve over it, so the measured benefit reached a minority of the sites claiming it. Trevisan and colleagues (2021) found the HTTP/3 advantage depended on network conditions. Ruth and colleagues (2018) found the protocol concentrated in a few providers, so an aggregate gain describes their traffic rather than the web's.

The evidence that would settle it is a field experiment that verifies the version actually negotiated rather than the version advertised, holds the content constant, and reports the distribution of user-visible timing across diverse networks. Varvello and colleagues measured advertised against served support but did not control content. Trevisan and colleagues measured performance under particular conditions. Langley and colleagues measured one operator's traffic, so each supplies only part of the test.

The two positions rest on different kinds of evidence. The deployed position rests on one operator's measurements at internet scale (Langley et al., 2017); the conditional position on passive measurement across many sites (Varvello et al., 2016) and on adoption and performance measurement (Trevisan et al., 2021; Ruth et al., 2018). The designer checks the version actually negotiated rather than the version advertised and measures user-visible timing on the networks that matter. The strongest objection is that this unit's framing of a handshake tax assumes the toll is paid per connection, while the measured evidence it cites concerns adoption, and adoption is not the latency a user sees.

Where the argument is heading

The direction of travel is that the toll is about to rise, deliberately, and the answer is again amortisation. Google (2024) added a post-quantum key share to Chrome's TLS 1.3 and QUIC handshakes. The lattice algorithm behind it, standardised by NIST (2024) as ML-KEM and known while it circulated as CRYSTALS-Kyber, sends a key share of roughly 1 kilobyte where the classical exchange sent 32 bytes, an increase of over thirty times. The larger share split the first packet and added about 4 per cent to the median desktop handshake time. With HTTP/2 and HTTP/3 connection reuse the change was invisible in its desktop page metrics but noticeable on Android, where it therefore held the change back. Sikeridis and colleagues (2020) found handshake latency increases of 1 to 300 per cent for TLS depending on the algorithms, with a small increase in the initial transport window halving the slowdown. The forward claim is specific, not optimistic. The handshake tax is growing, reuse and transport tuning absorb it, and where reuse fails the cost reappears. The machinery to watch is resumption and reuse.

The sources this unit rests on

• Fielding, R. T. and Taylor, R. N. (2002). Principled design of the modern web architecture. ACM Transactions on Internet Technology 2(2), 115-150. doi:10.1145/514183.514185 Reconstructed the web's design rationale from the constraints a distributed hypermedia application must satisfy and introduced the REST style that guided the redesign of HTTP and URIs, emphasising scalability, generality of interfaces and independent deployment, which is why statelessness was chosen and why the unit treats the protocol as the contract.
• Fielding, R., Nottingham, M. and Reschke, J. (2022). HTTP semantics. RFC 9110. doi:10.17487/rfc9110 Consolidated the meaning of HTTP methods, status codes and header fields into one semantic layer shared by HTTP/1.1, HTTP/2 and HTTP/3, and stated the stateless core with the caching and authentication frameworks that sit on it. It is the current statement of what the protocol means, and the baseline every later version modifies.
• Belshe, M. and Peon, R. (2015). Hypertext Transfer Protocol version 2 (HTTP/2). RFC 7540. doi:10.17487/rfc7540 Added a binary framing layer with multiplexed streams over a single connection, header compression and server push, while leaving HTTP's semantics unchanged. The specification reports that multiplexing removed the many-connection workarounds HTTP/1.1 had acquired.
• Dierks, T. and Rescorla, E. (2008). The Transport Layer Security (TLS) protocol version 1.2. RFC 5246. doi:10.17487/rfc5246 Fixed TLS 1.2's two-round-trip handshake and its cipher-suite negotiation, and documented the session resumption that lets a client and server avoid repeating the exchange. It is the predecessor whose cost profile explains why the later revision was worth the disruption.
• Rescorla, E. (2018). The Transport Layer Security (TLS) protocol version 1.3. RFC 8446. doi:10.17487/rfc8446 Reduced the handshake to one round trip, or none on resumption, and removed the legacy cryptographic options that had accumulated. It states that the protocol is designed to prevent eavesdropping, tampering and message forgery, and that it does not specify how a protocol adds security with it, a narrower promise than designers assume.
• Iyengar, J. and Thomson, M. (2021). QUIC: a UDP-based multiplexed and secure transport. RFC 9000. doi:10.17487/rfc9000 Defined a transport that builds reliability, congestion control and encryption over UDP, with a connection identifier that survives a change of network path and a handshake completing in fewer round trips. It places the answer to the handshake tax, and to connection continuity, at the transport layer.
• Bishop, M. (2022). HTTP/3. RFC 9114. doi:10.17487/rfc9114 Mapped HTTP semantics onto QUIC so that each stream is independent at the transport layer and TCP's head-of-line blocking on multiplexed streams disappears. It keeps the meaning of HTTP/2 while replacing the transport, which is why a designer must now ask which version a client will negotiate.
• Langley, A., Riddoch, A., Wilk, A. and colleagues (2017). The QUIC transport protocol: design and internet-scale deployment. Proceedings of the Conference of the ACM Special Interest Group on Data Communication. doi:10.1145/3098822.3098842 Described QUIC and Google's deployment across thousands of servers and estimated that 7 per cent of Internet traffic was then QUIC, reporting measured gains in connection establishment and search latency. It is the deployed evidence that the round-trip reductions are measurable in production.
• Varvello, M., Schomp, K., Naylor, D., Blackburn, J., Finamore, A. and Papagiannaki, K. (2016). Is the web HTTP/2 yet? Passive and Active Measurement (PAM 2016), Lecture Notes in Computer Science. doi:10.1007/978-3-319-30505-9_17 Monitored the Alexa top million for eleven months and found 68,000 websites reporting HTTP/2 support of which only about 10,000 served content with it. An advertised version is not a delivered one.
• Trevisan, M., Giordano, D., Drago, I. and Khatouni, A. S. (2021). Measuring HTTP/3 adoption and performance. 2021 19th Mediterranean Communication and Computer Networking Conference (MedComNet). doi:10.1109/medcomnet52149.2021.9501274 Measured HTTP/3 support and performance across popular websites and found adoption substantial but the gain over HTTP/2 dependent on network conditions, sometimes with little benefit. It makes the newer transport's advantage conditional rather than universal.
• Ruth, J., Poese, I., Dietzel, C. and Hohlfeld, O. (2018). A first look at QUIC in the wild. Passive and Active Measurement (PAM 2018), Lecture Notes in Computer Science. doi:10.1007/978-3-319-76481-8_19 Scanned the IPv4 address space and much of the DNS namespace, finding QUIC-capable addresses more than tripled to over 617,590, with only about 15,000 of roughly 161,000 domains presenting valid certificates over QUIC, and 2.6 to 9.1 per cent of traffic in QUIC. The protocol is concentrated rather than spread.
• Aas, J., Barnes, R., Case, B. and colleagues (2019). Let's Encrypt: an automated certificate authority to encrypt the entire web. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. doi:10.1145/3319535.3363192 Described an automated certificate authority and the ACME protocol that removed the human step from issuance and renewal, and reported over 538 million certificates issued for 223 million domain names by January 2019. The binding constraint on universal encryption was the trust setup rather than the handshake.
• Google (2024). Advancing our amazing bet on asymmetric cryptography. Chromium Blog, 23 May 2024. https://blog.google/chromium/advancing-our-amazing-bet-on-asymmetric/ Reported enabling a post-quantum key share in Chrome's TLS 1.3 and QUIC handshakes, with a Kyber share of roughly 1 kilobyte against 32 bytes for the classical exchange, splitting the first packet and adding about 4 per cent to the median desktop handshake. It is the production case for spending handshake bytes on a threat that has not arrived.
• NIST (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard. Federal Information Processing Standards Publication 203. doi:10.6028/NIST.FIPS.203 Specifies ML-KEM, the lattice mechanism derived from CRYSTALS-Kyber, with three parameter sets. It is the standard behind the post-quantum key share the unit describes, turning a deployed experiment into a named algorithm.
• Sikeridis, D., Kampanakis, P. and Devetsikiotis, M. (2020). Assessing the overhead of post-quantum cryptography in TLS 1.3 and SSH. Proceedings of the 16th International Conference on Emerging Networking Experiments and Technologies (CoNEXT). doi:10.1145/3386367.3431305 Measured handshake performance when post-quantum key exchange and authentication are added to TLS and SSH, finding latency increases between 1 and 300 per cent for TLS depending on the algorithms, with a small increase in the initial transport window halving the slowdown. The penalty is set by message size and transport tuning, not computation alone.