TCP Fast Open
tuexen at freebsd.org
Fri Dec 6 19:27:24 UTC 2019
> On 6. Dec 2019, at 15:23, Jeremy Harris <jgh at wizmail.org> wrote:
> On 05/12/2019 20:31, Jeremy Harris wrote:
>> On 05/12/2019 20:17, Michael Tuexen wrote:
>>>> - tried TFO but the server didn't take it up
>>> I would expect on = 0.
>> Excellent; that's the most-useful one to know.
> Unfortunately, it seems not to be so; it appears
> to be recording the sending of a TFO option
> (of _either_ type; so a cookie-Request still
> gets it set). This means I can't use it to log
> "TFO was actually doing something useful for
> this connection".
> The TCPOPT_FAST_OPEN bit in TCP_INFO says the same
> (either pre-ESTABLISHED or post-).
OK, looking up some documentation in the code:
* For passively-created sockets, the TCP_FASTOPEN socket option can be
* queried to determine whether the connection was established using TFO.
* Note that connections that are established via a TFO SYN, but that fall
* back to using a non-TFO SYN|ACK will have the TCP_FASTOPEN socket option
So this fits with what you observe. However, I think this should be improved...
I can put that on my list or you can file an issue at bugs.freebsd.org.
> Another problem, this time server-side. I was hoping
> to get the initial server output piggybacked on
> the SYN,ACK, given the TFO design notes in
> - but so far I'm not getting that. Packet capture (on lo0):
> SYN -> (TFO=C)
> 0.000224 <- SYN,ACK (TFO=C same value)
> 0.000078 SYN,ACK ->
> 0.001421 <- server_data
> The 224us response time for the SYN,ACK looks immediate, not
> a delack time as I'd expect.
That sounds like a bug. Let me test this and I report back.
> freebsd-transport at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe at freebsd.org"
More information about the freebsd-transport