上面的三种方法 只是用了 调节队列的大小解决 和回复RST方式解决 但是未完全的解决大量sys报文的攻击
1 正常流程 不解释 自己理解
2 应用程序过慢 当accept过慢时候 ACCEPT队列 容易满 那么recv ACK就会不成功 （所以将socket 在accept时候设置为 noblocking的原因也是有的吧在这里 ）
3 当SYN队列满了之后 新的syn不再进入队列 启用cookie 在发送SYN+ACK时候加上cookie的方法 解决ACCEPT队列爆掉 （理解为 新来的syn不处理了 只处理服务器第二次握手 回复的syn+ack包中带有cookie这样的 ACK报文了 ） 这样性能会下降
Fast_open功能开启和未开启过程对比的图片 自己看图不解释了
1吞吐量优先 那么就要开启Nagle算法减少小包 小包合并一起发送 tcp_nodelay off
2低时延续优先 即发一个很小的包立刻需要回复例如Xshell终点类型的小包交互型应用就需要客户端快速响应提高用户体验 tcp_nodelay on（即不准时延）
Tcp keeplive 区别于http中的keeplive （注意两者是完全不同的意义）
Tcp keeplive在tcp中的作用是检测连接是否有效的一种机制 这样可以剔除无效的连接
上面的话需要理解整理下 从新叙述一遍 延迟关闭就是 Nginx实现优雅的关闭
为什么需要RST代替正常的四次握手来关闭呢
因为当 读或者写 超时时 通过发送RST立刻释放端口和内存资源