Introduce Lingering Timeout

[rtribotte]

What does this PR do?

This PR introduces the respondingTimeouts.lingeringTimeout option for entry points, with a default value of 2s.

The lingering timeout defines the maximum duration between each TCP read operation.
As a layer 4 timeout, it applies during HTTP handling but respects the respondingTimeouts.readTimeout option configuration.

The default value is purposely narrowed and can close the connection too early.
This could be breaking for "server-first" protocols.
We suggest to adapt this value accordingly to your situation.

This PR also deprecates the respondingTimeouts.<timeout> options:

• <entryPoint>.transport.respondingTimeouts.readTimeout
• <entryPoint>.transport.respondingTimeouts.writeTimeout
• <entryPoint>.transport.respondingTimeouts.idleTimeout

They have been replaced by:

• <entryPoint>.transport.respondingTimeouts.http.readTimeout
• <entryPoint>.transport.respondingTimeouts.http.writeTimeout
• <entryPoint>.transport.respondingTimeouts.http.idleTimeout

Motivation

This change avoids Traefik instances with the default configuration hanging while waiting for bytes to be read on the connection.
This has been identified to be an issue with:

• HTTP/1.1 GET request specifying a Content-Length header with value >0.
• Any silent TCP client connection (notably "server-first" protocols" and proxy protocol enabled on the entry point (some TCP services with proxyProtocol.trustedIPs broken in 3.0.0-rc1 #10448).
• Any silent TCP client connection and no catch-all router to bypass the client-hello first bytes read.

Fixes #10448.
Superseeds #10531

More

• Added/updated tests
• Added/updated documentation

Additional Notes

Co-authored-by: Baptiste Mayelle baptiste.mayelle@traefik.io
Co-authored-by: Kevin Pollet pollet.kevin@gmail.com

[mmatur]

LGTM

[lbenguigui]

LGTM

[juliens]

LGTM

[ngbrown]

Can someone expand more on what is meant by "between each TCP read operation"? Is Traefik monitoring the TCP packet acks from the service? Or is it the delay between received packets from the client on the ingress port? Can more information be provided on how this is technically measured?

This change also seems breaks the AMQP TCP protocol, and AMQP over WebSockets. Setting the value to 0 cures the problems, but if I knew what the above phrase meant, I could try other values.

Edit: The documentation verbiage seems to be related to the go net package documentation for SetReadDeadline(). It's really not descriptive enough as to what is going on for a non-go programmer.

A better description would describe what is happening at a more physical level. Like: "this timeout is the maximum delay between received packets". Is this an accurate description? Does it affect both directions?

[yashgorana]

Can someone please help me understand why this new timeout is (1) introduced as a patch, (2) has such a small value of 2s knowing that it will break systems and more importantly (3) why it isn't an opt-in feature? This PR triggered a bunch of issues reported in #10596, #10595, #10589