Hi Willy
Did some more investigation on the case where the application request is too
large to
fit within the initial SYN.
Here is my test setup:
Web clients ——> haproxy ——> long-thin-pipe —> haproxy --—> web
servers
TFO Client
TFO Server
Client sends an HTTP request larger than MSS, the client side haproxy uses TFO
and puts as much data
as possible within the initial SYN. When SYN ACK is returned, the remaining
request data is sent.
On closer inspection although the correct number of octets are sent, the octets
in the continuation packet are all NUL.
E.g. Debug shows 1500 octets in the call to sendto() and a return value of
1500.
Wireshark shows TFO sending 1420 octets in the SYN. After SYN ACK comes back,
80 octets are sent in the next packet,
but these 80 octets are all NUL.
Looks like something broken in the TFO client, but would be good to see if
others can duplicate my results.
I’m testing using VMware which I think emulates TCP offload by default,
wondering whether that could be the cause?
********************
Regarding default values for the TFO backlog - I was concerned that if this is
maxconn then is
there a DoS vulnerability? Eg if a TFO client streams SYNs with random data at
you, each of these ties up
an haproxy connection for a while, starving other clients?
ATB
-David
