HTTPS持久连接失效求助：TLS/SSL REST服务重复创建连接

Let’s break down why your Keep-Alive headers aren’t translating to reused connections—this is super common with TLS-enabled services, and it usually boils down to server-side misconfigs, client-side oversights, or middlewares interfering. Here’s what to check step by step:

1. Verify Server-Side Keep-Alive Configuration is Actually Enabled #

Even if you’re not sending Connection: Close, many servers require explicit settings to enable persistent connections, especially with TLS. Let’s cover common server stacks:

• Spring Boot (Tomcat/Jetty/Undertow):
  For Tomcat, ensure these properties are set in application.properties to enforce connection reuse:

  server.tomcat.keep-alive-timeout=60000 # Keep connections alive for 60 seconds
  server.tomcat.max-keep-alive-requests=100 # Allow up to 100 requests per connection
  server.connection-timeout=60000 # Match idle timeout to keep-alive setting
  

  Double-check you’re not overriding these with custom Connector configurations in code.
• Nginx (as reverse proxy):
  Confirm these directives in your server block—critical if you’re proxying traffic to your REST service:

  http {
    keepalive_timeout 60s;
    keepalive_requests 100;
    # Must use HTTP/1.1 for proxying; HTTP/1.0 breaks persistent connections
    proxy_http_version 1.1;
    proxy_set_header Connection ""; # Let Nginx handle Keep-Alive headers between proxy and backend
  }
  

  Skipping proxy_http_version 1.1 will force HTTP/1.0, which doesn’t support Keep-Alive by default.

2. Fix Client-Side Connection Reuse (The #1 Gotcha) #

If your client creates a new HTTP client instance for every request, it can’t reuse connections—no amount of header settings will help. Here’s how to fix common client libraries:

• Java (OkHttp): Reuse a single OkHttpClient instance (it manages its own connection pool):

  // Correct: Reuse this instance across all requests
  private static final OkHttpClient client = new OkHttpClient.Builder()
    .connectionPool(new ConnectionPool(5, 60, TimeUnit.SECONDS))
    .build();
  
  // Wrong: Creates a new client (and pool) every time
  public void makeBadRequest() {
    OkHttpClient badClient = new OkHttpClient();
    badClient.newCall(request).execute();
  }
  

• Python (requests): Use a Session object to persist connections:

  # Correct
  session = requests.Session()
  for _ in range(10):
    session.get("https://your-service.com/api")
  
  # Wrong: New connection for every request
  for _ in range(10):
    requests.get("https://your-service.com/api")
  

• C# (HttpClient): Reuse the same HttpClient instance (it’s thread-safe!) instead of disposing it after each request.

3. Enable TLS Session Reuse (Fallback for Connection Issues) #

While fixing connection reuse is priority, enabling TLS session reuse can drastically cut handshake latency even if connections aren’t reused:

• Server-side: For Nginx, add these directives to your SSL config:

  ssl_session_cache shared:SSL:10m; # Cache TLS sessions
  ssl_session_timeout 10m; # Reuse sessions for 10 minutes
  

  Spring Boot’s Tomcat enables this by default, but confirm custom SSL configs aren’t overriding it.
• Client-side: Most modern libraries support session resumption, but double-check older clients aren’t disabling it.

4. Rule Out Middleware/Load Balancer Interference #

If you have a load balancer, API gateway, or proxy between client and server, it might be terminating connections early:

• Load Balancers: Compare the load balancer’s idle timeout to your server’s Keep-Alive setting. If the load balancer times out after 30s but your server allows 60s, connections will be closed prematurely.
• Proxy Servers: Ensure the proxy isn’t stripping or modifying Connection headers. For Nginx, proxy_set_header Connection "" lets it manage backend connections correctly.

5. Debug with Packet Captures #

If all else fails, use tcpdump or Wireshark to capture traffic:

• Look for FIN or RST packets right after a response—this tells you who’s closing the connection (client, server, or middleware).
• Confirm the server responds with Connection: Keep-Alive (even if you didn’t see Connection: Close, explicit confirmation helps).
• Check if the client reuses the same TCP port for subsequent requests (a clear sign of persistent connection reuse).

内容的提问来源于stack exchange，提问作者user2707250