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