Why HTTP’s Short and Long Connections Matter: A Deep Dive into Protocol Features

This article first outlines HTTP’s characteristics and then details short‑ and long‑connection management, giving readers an in‑depth view of HTTP connections.

HTTP Characteristics

Flexible and Extensible

HTTP was designed as a simple, open protocol with a basic message format, allowing developers to add custom headers and bodies, which has enabled it to evolve and support various data types over three decades.

Reliable Transmission

Built on TCP, HTTP inherits TCP’s reliability, ensuring data is delivered as long as the network is functional, though it cannot guarantee 100% success under adverse conditions.

Application‑Layer Protocol

As an application‑layer protocol, HTTP can carry arbitrary headers and payloads, making it more versatile than specialized protocols like FTP or SMTP.

Request‑Response Model

HTTP follows a request‑response pattern where the client initiates communication and the server replies, aligning with traditional client/server architectures.

Statelessness

Each HTTP request is independent; the protocol does not retain session state, requiring clients to resend authentication or context with each request.

Other Characteristics

Additional features such as caching, compression, chunked transfer, authentication, and internationalization stem from HTTP’s extensibility.

Summary

HTTP is flexible and extensible, allowing custom headers and diverse payloads.

It provides reliable transmission by leveraging TCP.

As an application‑layer protocol, it supports a wide range of data types.

It uses a request‑response model, with the client initiating communication.

HTTP is fundamentally stateless, treating each request independently.

HTTP Connection Management

Connection management, especially short‑ and long‑connections, remains a core topic.

Short Connections

Early HTTP versions opened a new TCP connection for each request and closed it immediately after the response, incurring high overhead due to TCP’s three‑way handshake and four‑way teardown.

This overhead dramatically reduces efficiency, similar to repeatedly opening and closing a costly gate for each entry.

Long Connections

Persistent (keep‑alive) connections reuse a single TCP connection for multiple requests, amortizing the connection cost and improving throughput.

Servers indicate support with the “Connection: keep‑alive” header; clients can also request closure with “Connection: close”.

Head‑of‑Line Blocking

Because HTTP processes requests sequentially, a slow request at the front blocks subsequent ones, reducing overall performance.

Mitigations include opening multiple concurrent connections or using domain sharding to spread requests across several hostnames.

Performance Optimizations

Browsers may open several parallel connections (historically limited to 2, now often 6‑8). Additional techniques like domain sharding increase effective concurrency without overloading a single server.

Small Summary

This lecture covered short vs. long connections, default keep‑alive behavior in HTTP/1.1, header fields for connection control, and strategies to handle excessive persistent connections.

References

透视HTTP协议