Hypertext Transfer Protocol (HTTP) outlines several ways by which two networked devices can transfer information. Persistent vs. Non-Persistent HTTP connections are among two of the most differentiating aspects of HTTP protocol.
Comparing the advantages and disadvantages of each can help determine the best protocol to use given an application’s demand and/or goals. Before diving in, let’s also consider a brief history of HTTP protocol and how connection persistence has evolved to meet the demands of modern applications and services.
Overview
- HTTP/1.0 Didn’t account for non-persistent connections
- HTTP/1.1 recognized the need for non-persistence in network communications
- Non-Persistent HTTP connections require a TCP/IP 3-way handshake for every requested object
- Persistent HTTP connections allow the transfer of multiple objects without re-establishing connections via 3-way handshakes
- Both persistent and non-persistent HTTP protocols have advantages but persistent wins out in most modern applications like Google Chrome and Firefox
Introduction
Many internet applications are designed to communicate over an extended period of time. Take services like Netflix for example—the downloading of many data packets over a period of hours. On the other hand, downloading a single file may not benefit explicitly from keeping a connection alive.
Initial HTTP Protocol
RFC 1945 outlined the HTTP 1.0 protocol that described how a client and server would interact during network communications (R). At this period of time (1994ish) there was no consideration made for persistent connections. So, somewhat by default, the early days of HTTP protocol were built on a backbone of non-persistent connections.
Dawn of Persistence
As the popularity of the Internet grew, and thus TCP communications, the need for more efficient connection options matched pace. In 1999, RFC 2616 outlined the need for persistent connections in the initial HTTP 1.1 proposal (R). It noted the following:
HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical
proxies, caching, the need for persistent connections, or virtual hosts.
Future Implementations
We’re now approaching the adoption of HTTP 3.0, but there have been dozens of expansions, updates, and field-inspired amendments along the lifecycle of HTTP protocol. Future implementations seek to implement persistence during tough network conditions like ensuring HTTPS between a phone and remote server when local connections shift abruptly from WiFi to 4G or 5G networks. For now, let’s just focus on the basics of HTTP persistence.
HTTP/1.0 Protocol Basics
The HTTP 1.0 protocol outlined the basic framework of the modern web. Concepts such as headers, character encodings, character sets, and request methods were detailed extensively.
At the time, in the infancy of what we know as the Internet today, there was little need for persistent connections. As such; a non-persistent connection was the default in HTTP protocol.
Round Trip Time (RTT)
In TCP/IP network communication, efficiency can be measured, in part, by a metric known as Round Trip Time (RTT). RTT describes the time it takes for a request to travel from one machine to another and back again. For example, if a client makes a request to a server and the server responds; that’s 1 x RTT.
TCP 3-Way Handshake
HTTP/1.0 is an application-level protocol and, as such, sits on top of TCP/IP protocols. TCP connections are established through something referred to as the TCP 3-Way Handshake. This involves a client sends an initial synchronization (SYN) request, the server responds with a synchronization acknowledgment (SYN/ACK), then the client responds with another ACK and a request for data.
In TCP/IP protocol, only after the initial 3-way handshake does the server begin transmitting data back to the client. This requires a total of 2RTT. Keep that in mind; it’s important in differentiating persistent vs. non-persistent HTTP connections.
For non-persistent connections; the 3-way handshake has to be completed for every object being requested. That level of network traffic starts to add up fast and can result in timeouts, dropped packets, and even server crashes.
In persistent HTTP connections, the socket between client and server remains open and subsequent requests don’t require the 3-way handshake.
Non-Persistent Connections
Non-persistent HTTP connections were the defacto means of communication in early HTTP implementations. It’s not that this method was chosen over persistent connection protocols—rather, persistent protocols didn’t exist yet.
Modern web browsers like Chrome, Firefox, and Opera use persistent HTTP connections by default. As such, non-persistent connections are very widely used in modern network applications. However, there are still some advantages.
Advantages
- Unused resources are freed immediately after use
Disadvantages
- 2 RTT’s per object requested
- Greater CPU overhead
Persistent Connections
Persistent HTTP connections are designed to allow multiple request/response exchanges without establishing new connections for each. In TCP, this can considerably reduce network congestion and resource use by eliminating the need for the TCP 3-way handshake for each request. One “introduction” between client and server is all that’s needed.
Advantages
- Lower CPU and memory usage
- Allows for HTTP Pipelining
- Reduced network congestion
- Reduced latency for subsequent requests
- Errors can be reported without TCP connection termination
Disadvantages
- Resources may be unaccessible even when unused
Review
Understanding the benefits of persistent HTTP protocols can help realize the path to better network applications by reducing congestion, freeing up resources, and parallelizing high-demand use cases. While HTTP has evolved considerably since HTTP/1.0, its reliance on TCP/IP transport protocols still results in many of the same application concerns.
