SYN Cookie在Linux内核中的实现，没太读懂

dlcat

原贴：
http://www-900.ibm.com/developerworks/cn/linux/l-syncookie/index.shtml#rating

dlcat

原帖由 "dlcat" 发表：

sseq := ntohl(skb->;h.th->;seq) 这里的skb是携带TCP SYN的那个skb
count1 := jiffies/(HZ*60) 当前时间的分钟值
data1 := msstab
从前往后最后一个小于skb中携带的MSS值的值的索引（值得注意的是两个密钥在第一次被初始化后，就不会再有改动，直到系统重新启动。因此可以认为它是一个常值。）

有了上面的定义我们可以得到cookie等于



        isn := A+sseq + (count1<<COOKIEBITS) + (B+data1)&COOKIEMASK
        


这个isn被赋予返回的TCP SYN+ACK包中，作为其中的ISN值。这就是cookie 的产生过程。在这个过程中，没有在本地为这个连接请求分配任何存储空间。

在TCP服务器收到TCP ACK包时，相应的要进行SYN Cookie的检查。这个检查过程在函数tcp_v4_hnd_req中的cookie_v4_check函数开始。cookie_v4_check调用cookie_check函数，cookie_check函数调用check_tcp_syn_cookie函数。

check_tcp_syn_cookie函数在random.c中定义，是与前面介绍的
secure_tcp_syn_cookie函数对应的函数，检查从TCP ACK中提取出的ISN值。

在check_tcp_syn_cookie中假定ISN的值如下



        isn := A+sseq + (count2<<COOKIEBITS) + (B+data2)&COOKIEMASK
        


这里的A、B都是根据当前这个skb中的地址信息和syncookie_secret算出来的；sseq是根据这个skb中的seq值算出的。


有了上面这些值，TCP服务器就可以反算出count2和data2。理论上来说，只要这个isn是原来那个isn，应该有



count2 == count1  
data2 == data1



但是这种结论仅仅是一个理论情况。因为在TCP服务器端并没有保存原来的count1和data1，因此不能直接进行比较。TCP服务器采取的方法是：

1）计算出当前的分钟值
count3 := jiffies/(HZ*60)
用count3与count2比较，如果差值超过COUNTER_TRIES（4）分钟，则认为这 个ACK包不合法。
2）看data2是不是一个合法的msstab的索引，也就是说是不是小于NUM_MSS， 即(sizeof(msstab)/sizeof(msstab[0]) - 1)。如果小于，则认为这个ACK 合法，否则认为非法

这段看不懂了
是否这样理解有三个验证
1：sseq的验证
2：响应时间大于4分钟的就去除
3：data的验证，不是很理解
谁能解释一下是不是看这三个验证。