HTTP Long Connections ≠ Permanent Connections! The Truth About Keep-Alive

Follow us, bookmark us, and meet every day at 7:30 for daily Java content sharing

HTTP Long Connections ≠ Permanent Connections! The Truth About Keep-Alive

Step 1: Technical Analysis

Core Difference: TCP Connection Reuse

The essence of HTTP long connections is TCP connection reuse.

Feature HTTP/1.0 (Short Connection) HTTP/1.1 (Long Connection)
Default State <span>Connection: close</span> <span>Connection: keep-alive</span>
Connection Count A new TCP connection is required for each request (three-way handshake) Multiple requests reuse the same TCP connection
Performance Bottleneck Severe latency (RTT), high CPU consumption Head-of-Line Blocking (HOL Blocking)
Applicable Scenarios Few simple requests Most modern web applications

Why Can Long Connections Improve Performance?

The answer lies in the cost of TCP connections:

  1. 1. Three-Way Handshake (Latency Cost): Establishing a TCP connection requires a three-way handshake, which consumes at least one round-trip time (RTT), increasing latency.
  2. 2. Slow Start (Throughput Cost): TCP has a “slow start” mechanism, where the data transmission rate is limited at the beginning of the connection. Short connections mean starting from a slow rate for each transmission.
  3. 3. Four-Way Handshake (CPU/Resource Cost): Closing a connection requires a four-way handshake, consuming CPU resources on both the server and client.

Long connections reduce these high costs by spreading them across multiple HTTP requests, resulting in significant performance improvements.

How to Implement?

  • Client: The browser automatically adds <span>Connection: keep-alive</span> in the header when sending requests.
  • Server: The server also adds <span>Connection: keep-alive</span> in the header when returning responses.
  • Disconnection Mechanism: Long connections are not permanent. If no new data is transmitted within a preset timeout period (usually 60 seconds), the TCP connection will automatically disconnect.

Story Scenario: Toll Fees on a Highway

  • You (Browser): A courier who needs to deliver many small packages (requests for CSS, JS, images) from the city (server).
  • Highway (TCP Connection): The road for transporting packages.
  • Toll Booth (TCP Handshake): The high toll fee paid for each passage.

Era One: HTTP/1.0 — “Pay Per Use, No Change” (Short Connection)

  • Rules of Passage:
  1. 1. You have a small package to deliver. You queue to pay (three-way handshake).
  2. 2. You drive through the highway and deliver the package.
  3. 3. You return to the toll booth, collect the money, and the toll booth closes (four-way handshake).
  4. 4. You have a second package to deliver. You must queue again and pay again (re-handshake).
  • Efficiency:If you deliver 100 small packages, you have to queue 100 times and pay 100 times. Although each trip is quick, your time is wasted on **waiting in line (RTT)** and **repeated payments (TCP handshake)**.
  • Era Two: HTTP/1.1 — “Monthly Subscription, Reusable Channel” (Long Connection)

    • Rules of Passage:The courier company has upgraded. After your first payment, the toll collector gives you a **“Keep-Alive” pass**.
    1. 1. You pay once (one handshake).
    2. 2. After delivering a package, the toll collector sees you have another package and says: “Keep the lane open, no need to queue, just go!” (connection not closed).
    3. 3. You deliver 100 packages, only needing to pay once.
  • Efficiency:You only need to pay once and successfully deliver 100 packages. This greatly reduces the time wasted in queuing, paying, and waiting at the toll booth.
  • Drawback:Although costs are saved, the highway itself has only one lane. You must queue in order for both the first and the hundredth package. This is the source of head-of-line blocking (HOL Blocking), which HTTP/2.0 aims to solve.
  • Story Summary:

    Concept Short Connection (1.0) Long Connection (1.1) Essence
    Core Operation Repeated Handshake TCP Reuse Cost Savings
    Toll Booth Queue and pay each time Pay once, multiple passages Reduce RTT
    Efficiency Low High Spread Connection Overhead

    Conclusion:HTTP long connections greatly enhance the performance of web applications by allowing multiple requests to be sent over a single TCP connection, forming the foundation for improving response speed in all modern web applications.

    Recommended Reading Click the title to jump

    50 Java Code Examples: Master Lambda Expressions and Stream API

    16 Java Code “Pain Points” Major Overhaul: “General Writing” VS “Advanced Writing” Ultimate Showdown, Watch Code Quality Soar!

    Why Senior Java Developers Love Using the Strategy Pattern

    Selected Java Code Snippets: Better Writing for 10 Common Programming Scenarios

    Enhancing Java Code Reliability: 5 Best Practices for Exception Handling

    Why You Rarely See if-else in the Code of Experts, Because They All Use This…

    Still Injecting Other Services Madly in Service? You Should Have Used Spring’s Event Mechanism Long Ago

    Did you gain something from this article? Please share it with more people

    Follow ‘Java Content’ and bookmark to enhance your Java skills

    HTTP Long Connections ≠ Permanent Connections! The Truth About Keep-Alive

    ❤️ Give a 'Recommendation', it's the biggest support ❤️
    
    
    

    Leave a Comment