[欢迎进入讨论] 关于syn-proxy的一些问题

Godbach

很多小的技巧性的东东——例如：处理“当完成客户端三次握手，再去同服务器三次握手时，客户端的请求可能会提前到来。”的问题，都是向他请教的哈。

不知道syn-proxy设计的过程中还有那些小地方需要考虑？

效率上还是有改进，我在一个533MHz上，处理接近30Wpps的虚假syn包，好像还可以对付哈。就是处理ack 反弹上不太理想，做了些工作，但是还是有待改进呀。

ack反弹是哪里来的啊？

济南鸿泰

有点看不懂啊，不过还要看看

Godbach

原帖由 济南鸿泰 于 2009-3-18 10:45 发表
有点看不懂啊，不过还要看看

可以提问题。。:wink:

独孤九贱

原帖由 Godbach 于 2009-3-18 09:44 发表

不知道syn-proxy设计的过程中还有那些小地方需要考虑？

ack反弹是哪里来的啊？

呵呵，小细节每个人的实现不同而不同，要遇到再讨论了。
ACK反弹是因为，收到一个syn请求，就要回应一个带cookie的ack，如果syn 请求有20Wpps，那回应的ack也是同样量的。

Godbach

原帖由 独孤九贱 于 2009-3-18 19:34 发表


呵呵，小细节每个人的实现不同而不同，要遇到再讨论了。
ACK反弹是因为，收到一个syn请求，就要回应一个带cookie的ack，如果syn 请求有20Wpps，那回应的ack也是同样量的。

九贱兄指的这个ACK反弹实际是SYN+ACK包吧。我说怎么会有ACK反弹的。原来没有理解透彻

specific

fw回复给server的syn和ack包如果丢失了还是比较麻烦的，syn proxy的实现一般不会放到tcp协议栈之上，由协议栈handle重传不太现实

specific

tcp选项的支持需要仔细考虑，还有就是conn_track的超时回收等

Godbach

多谢LS的指点。

如果说可能存在fw给server的报文有丢失，那么理论上讲client发到server的也是有可能丢失的吧。

specific

原帖由 Godbach 于 2009-3-23 10:47 发表
多谢LS的指点。

如果说可能存在fw给server的报文有丢失，那么理论上讲client发到server的也是有可能丢失的吧。

client给server的丢失可以依赖于client端的tcp协议栈，fw的超时重传机制一般需要在syn proxy里实现

Godbach

原帖由 specific 于 2009-3-23 13:12 发表


client给server的丢失可以依赖于client端的tcp协议栈，fw的超时重传机制一般需要在syn proxy里实现

如果这个地方简化一下，如果fw代发的SYN丢失了，就让它丢失，让client重传。