Hello,

On Mon, 8 Feb 2021 at 18:14, Максим Куприянов
<maxim.kupriya...@gmail.com> wrote:
>
> Hi!
>
> I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over 
> Graphite's component receiving metrics from clients and clients who are 
> connecting just to send one or two Graphite-metrics and disconnecting right 
> after.
>
> It looks like this
> 1. Client connects to haproxy (SYN/SYN-ACK/ACK)
> 2. Client sends one line of metric
> 3. Haproxy acknowledges receiving this line (ACK to client)
> 4. Client disconnects (FIN, FIN-ACK)
> 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even trying to 
> connect to a backend and send client's data to it.
> 6. Metric is lost :(
>
> If the client is slow enough between steps 1 and 2 or it sends a bunch of 
> metrics so haproxy has time to connect to a backend – everything works like a 
> charm.

The issue though is the client disconnect. If we delay the client
disconnect, it could work. Try playing with tc by delaying the
incoming FIN packets for a few hundred milliseconds (make sure you
only apply this to this particular traffic, for example this
particular destination port).

> Example. First column is a time delta in seconds between packets

It would be useful to have both front and backend tcp connections in
the same output (and absolute time stamps - delta from the first
packet, not the previous).


You may also want to accelerate the server connect with options like:

option tcp-smart-connect
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4-option%20tcp-smart-connect

tfo (needs server support)
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#tfo%20%28Server%20and%20default-server%20options%29



> How can I deal with these send-and-forget clients?

In TCP mode, we need to propagate the close from one side to the
other, as we are not aware of the protocol. Not sure if it is possible
(or a good idea) to keep sending buffer contents to the backend server
when the client is already gone. "[no] option abortonclose" only
affects HTTP, according to the docs.

Maybe Willy can confirm/deny this.


Lukas

Reply via email to