学习了。现在这样子的dddos都有软件可以防御了。
作者：新一
↧
↧
作者：freeeyes
引用：
假设服务端上有一个大文件，攻击者连接服务端发起请求，但是却不接收数据，于是乎就造成一种现象：客户端接收队列满，导致服务端不得不通过「zero window probes」来循环检测客户端是否有可用空间，以至于 tcp_orphan_retries 也没有用，因为服务端活活被憋死了，发不出 FIN 来，从而永远卡在 FIN_WAIT1
问题：
如果在这样的情况下，客户端不recv服务器的数据，服务器send会造成EAGAIN错误返回给调用层，这里只需要有逻辑处理EAGAIN等待次数。如果在一定次数下对方还是窗口为0，服务器代码可以主动清理这个socket fd。
这样的话，就不会有过多的死链的问题。
不知道我的描述是否正确，请教博主是否可以这样理解？
↧
作者：西山
你的想法可以实践一下，首先每次send 是发送到本地tcp 栈里面，所以开始你是成功的。 到了最后本地队列满了，epoll 就不会主动通知你可写了。 最关键是关闭socket, 正常情况的close 没办法避免这个问题，但是可以用丢弃数据的办法来关闭socket 避免fin_wait_1 情况，这个在群里讨论的时候，我已经说过了。
↧
作者：小金
有个问题：前面说“客户端连接进入 FIN_WAIT1 状态”，后面又说“如果你的服务器负载较重，有很多 FIN_WAIT1”，是不是矛盾了。
按博主实验中的情况，是客户端主动断开连接进入了 FIN_WAIT1 状态，并不是服务端。此时客户端等待服务端发送ack，由于服务端通过 iptables 拦截了发送给客户端的响应，此时会导致客户端一直停留在 FIN_WAIT1 状态吧？为何又说“服务器负载较重，有很多 FIN_WAIT1”呢？不是很明白这其中的逻辑。
↧
作者：老王
我的行文好像不太一致，导致你迷惑了，FIN_WAIT1 即可能出现在服务端，也可能出现在客户端，关键看哪一端主动关闭连接。常见的如 Nginx 服务器，如果使用的是短连接，那么服务端会主动关闭连接，如果使用的是长连接，那么可能就是客户端主动关闭连接了。
↧
↧
作者：echo
请问有没有tcp/ip选项用来设置这个fin_wait1的超时时间的?
↧
作者：xiaoqing
“常见的如 Nginx 服务器，如果使用的是短连接，那么服务端会主动关闭连接，如果使用的是长连接，“
我nginx打开keepalive_timeout 60;长连接，也是服务器端主动关闭。
还有一个”可以用丢弃数据的办法来关闭socket 避免fin_wait_1 情况”
这个丢弃是超过一定次数直接丢弃发送的fin么
↧
作者：xiaoqing
除了使用内核的tcp_max_orphans来解决ddos问题，其他是不是按照你说的在应用层丢弃来解决问题
↧
作者：浅谈CLOSE_WAIT |火丁笔记
[…] TIME_WAIT 和 FIN_WAIT1，最近时不时听人提起 […]
↧
↧
作者：lebee
我是在网络的差的情况下碰到这事的，服务程序开了几十个线程来处理并发。由于网络差，所有线程都堵塞在close()上，多数是fin_wait_1，这种情况该怎么办呢？
↧
作者：lebee
我是在网络的差的情况下碰到这事的，服务程序开了几十个线程来处理并发。由于网络差，所有线程都堵塞在close()上，多数是fin_wait_1，这种情况该怎么办呢？
↧
作者：zwb
请问TCPCopy社区的链接是多少？
↧
作者：木堇
您好，我想我问一下，我的服务器接收到不明客户端的消息，导致服务器陷入死循环得过程应该怎么解决，我做的是java得Tcp编程
↧
↧
作者：linux环境下如何切断指定的tcp连接 –此方，彼方
[…] 关于FIN_WAIT1 […]
↧
作者：切断tcp连接，在linux环境下 - 此方，彼方
[…] 关于FIN_WAIT1 […]
↧
More Pages to Explore .....
