Improved TCP syncookie implementation
andre at freebsd.org
Wed Sep 13 13:31:46 PDT 2006
Igor Sysoev wrote:
> On Wed, 13 Sep 2006, Andre Oppermann wrote:
>> Igor Sysoev wrote:
>>> On Sun, 3 Sep 2006, Andre Oppermann wrote:
>>>> I've pretty much rewritten our implementation of TCP syncookies to get
>>>> rid of some locking in TCP syncache and to improve their functionality.
>>>> The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK
>>>> optional feature information. This means that a FreeBSD host may run
>>>> with syncookies only and not degrade TCP connections made through it.
>>>> All important TCP connection setup negotiated options are preserved
>>>> (send/receive window scaling, SACK, MSS) without storing any state on
>>>> the host during the SYN-SYN/ACK phase. As a nice side effect the
>>>> timestamps we respond with are randomized instead of directly using
>>>> ticks (which reveals out uptime).
>>> As I understand syncache is used to retransmit SYN/ACK.
>>> What would be if
>>> 1) a client sent SYN,
>>> 2) we sent SYN/ACK with cookie,
>>> 3) the client sent ACK, but the ACK was lost
>> If the client sent ACK it will retry again after the normal retransmit
> Well, suppose protocol similar to SSH or SMTP:
> 1) the client calls connect(), it sends SYN;
> 2) the server receives SYN and sends SYN/ACK with cookie;
> 3) the client receives SYN/ACK and sends ACK;
> 4) the client returns successfully from connect() and calls read();
> 5) the ACK is lost;
> 6) the server does not about this connection, so application can not
> accept() it, and it can not send() HELO message.
> 7) the client gets ETIMEDOUT from read().
> Where in this sequence client may retransmit its ACK ?
Never. You're correct. There is no data that would cause a retransmit
if the application is waiting for a server prompt first. I shouldn't
write wrong explanations when I'm tired, hungry and in between two tasks. ;)
This problem is the reason why we don't switch entirely to syncookies
and still keep syncache as is.
>> If our SYN-ACK back to client is lost we won't resend it with syncookies.
>> The client then has to try again which is does after the syn retransmit
More information about the freebsd-net