叫个板,百兆的82559芯片不会有人比我的性能更高

platinum

原帖由 zjzf_1 于 2006-3-9 17:07 发表
原汁原味的在这里D. J. Bernstein

所谓的六次 应该是synproxy吧

client　与防火墙完成3次
防火墙与server完成3次
也就是说你要是写synproxy要考虑两个三次握手　　你说3+3=?

呵呵，syncookie 的原理可不是这样，你可以研究一下

zjzf_1

一个是synproxy 一个是syncookies

写都写过了   我不熟悉还有谁熟悉?

zjzf_1

我为什么经常把syncookies和synproxy混在一起讲


因为从技术上来讲 synproxy是 syncookies的一种延伸 而已

platinum

可否讲一下？ ^_^

zjzf_1

http://cr.yp.to/syncookies.html


中文的http://www-128.ibm.com/developer ... cn-newsletter-linux

[ 本帖最后由 zjzf_1 于 2006-3-9 17:33 编辑 ]

platinum

上面讲的是 syncookie
那为什么说“从技术上来讲 synproxy是 syncookies的一种延伸”呢？
能否讲一下 synproxy 与 syncookie 的不同之处，以及延伸的地方呢？

zjzf_1

我个人认为 syncookies  应该是在tcp_input 部分实现的 通过修改操作系统tcp协议栈实现的  可以参考下freebsd的 syn_cache
而 synproxy   是在tcp_input之前实现的  也就是说 不管在本机还是在网络中(比方说ethernet bridge 或者NAT) synproxy机制首先代替标准的tcp协议栈 与客户机完成tcp请求三次握手确立该连接的真实性 synproxy再代替客户给与tcp协议栈完成三次握手  并在今后的tcp通讯中 充当中转作用  这个中转主要是为了维护序列号


client      synproxy      server
      ---->
         <---
        ----->          ---->
                           <----
                          ------>

skipjack

原帖由 zjzf_1 于 2006-3-9 19:31 发表
我个人认为 syncookies  应该是在tcp_input 部分实现的 通过修改操作系统tcp协议栈实现的  可以参考下freebsd的 syn_cache
而 synproxy   是在tcp_input之前实现的  也就是说 不管在本机还是在网络中(比方说ethe ...

下午太忙了,没即时上来,呵呵;....发了不少回复啊,一个一个来吧,先从最后一个回起
呵呵....你的这个六次握手的功能,可能是大部分抗syn flood设备的思路,很传统,但很实用.我设计过一份在NP下的实践,也是这个思路.但NP下没有随时数发生器,所以随机数种子质量不是很好.
说是六次握手,其实你要处理的就是三个包,另外三个包是利用这三个包构造的,所以不是很费资源.
序号代理是这个实现的关键,实现过的人都知道,原向代理ack seq,反向代理seq.核心代码决不超过10行(一加,一减,一cheat_check足够了,细算的话6行代码,我说的有错吗?如果你实现过,你应该听的懂的.还有如果你把计算检验和的汇编算上是你写的,那可能会多一点)而己,呵呵...没有你说的那么神密,如果你喜欢,我可以把抗DoS的功能周未的时候加上,做个DOM去你那里测一下.我可以保存64字节60M的吐吞就是抗syn flood的性能,前题是你在北京.
但愿我们头儿没有看这个贴子,呵呵....

skipjack

原帖由 platinum 于 2006-3-9 17:39 发表
上面讲的是 syncookie
那为什么说“从技术上来讲 synproxy是 syncookies的一种延伸”呢？
能否讲一下 synproxy 与 syncookie 的不同之处，以及延伸的地方呢？

是这样的,与客户机的三次握手是用syncookie来实现的,与服务器的三次握手是用synproxy完成的.所以这两个技术一般在网关上都是在一起实现的,但如果在服务器终端一般就实现syncookie就可以了.

skipjack

写过也不一定就是最好的呀,必竟有很多人都实现过.
例如:你做syn proxy的时候,syn包中的tcp选项怎么处理?丢弃/自造/任选, 讲讲这个吧.