Syncookie源码解析（linux-2.6.30.10）（1）

    当syn包到来时，会调用net/ipv4/tcp_ipv4.c中的函数tcp_v4_conn_request，此函数用来处理syn包并创建requst_sock存储在半连接队列里，然后发送synack包完成第二次握手。半连接的更新比较关键的是在第三次握手收到ack包时会查找半连接队列，并将符合的requst_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。

   正常情况下，三次握手都能很快完成，半连接队列也不会被填满。但遭受syn攻击时，由于syn包的源ip可能是大量的伪造的ip，主机回的synack包不可能有ack包的回应，如果攻击速度快，会导致半连接队列被填满，后续的连接请求syn就会被无情的丢弃了。如果开起来syncookie，情况将有所变化。下图是函数tcp_v4_conn_request中的片段：

    if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
#ifdef CONFIG_SYN_COOKIES
        if (sysctl_tcp_syncookies) {
            want_cookie = 1;
        } else
#endif
        goto drop;
    }

inet_csk_reqsk_queue_is_full(sk)用来判断半连接队列是否被填满，我们可以看到，当开启了syncookie（sysctl_tcp_syncookies=1）并没有丢弃syn包，而是进行了其他的处理。接着看代码：

    if (want_cookie) {
#ifdef CONFIG_SYN_COOKIES
        syn_flood_warning(skb);
        req->cookie_ts = tmp_opt.tstamp_ok;
#endif
        isn = cookie_v4_init_sequence(sk, skb, &req->mss);
    }

syn_flood_waring是用来输出possible SYN flooding消息（每分钟一次），接下去我们可以看到程序计算了了一个isn（cookie_v4_init_sequence），这个isn是如何计算得到的呢，我们以后再说。接着看代码：

    tcp_rsk(req)->snt_isn = isn;

    if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)
        goto drop_and_free;

isn赋值给了tcp_request_sock结构体的snt_isn成员，为什么这样做，我们也以后再说。接下来我们可以看到，虽然半连接队列满了，却仍然发送了synack包。那么此synack包有什么特别之处呢，我们还以后再说。