未整理的笔记

 

 

上面的三种方法  只是用了  调节队列的大小解决 和回复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立刻释放端口和内存资源