翻看以前的文章 ​​keepalive定时器​​    ​​ persist定时器​​

两者报文形式：

• 零窗口通知包：win=0
• keepalive包：seq=ack-1， len = 1或者len = 0

keepalive报文

SLE: Sequence Left Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp数据的左边界。

SRE: Sequence Right Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp数据的右边界。

SACK在数据丢包需要重传时起作用。比如，服务器已发送的数据为1~34454个包，但是，客户端只收到了“1~22774，28614~34454”这些序列的包，也就是说“22775~28613”这些包已经丢了。这个时候，客户端会向服务器请求发送回馈包，说我收到了seq为22774的包，同时也乱序收到了"SLE为28614，SRE为34454"的包。那么，服务器就知道，接着从seq=22775的包开始发送，发送到seq=28613的包的时候，就不用在发送seq=28614的包了，因为客户端已经收到了。

Zero Window

当出现零窗口的时候，服务端启动持续探测定时器，也叫Persist定时器。

当接收端 B 接收窗口为 0 时，发送端 A 此时不能再发送数据，发送端此时开启 Persist 定时器，超时后发送一个特殊的报文给接收端看对方窗口是否已经恢复，这个特殊的报文只有一个字节

第1~7包：包括了三次握手和正常通信数据包。

• 第8包：服务器端识别出客户端的接收窗口已经耗尽。
• 第9包：接收端回复的 ACK，携带了 win=0，wireshark 帮忙把这个包标记为了 TCP Zero window。
• 第10-25包：重传间隔是按照指数级退避，直到达到 120s 为止，一共重传尝试了16次（这个值由操作系统的参数决定)，只是这里被wireshark标记为[TCP Keep-Alive]。
• 
  

1、TCP Window Full 是站在发送端角度说的，表示此时发送端不能再发数据给对方，除非发送的数据包得到ACK。

2、TCP zero window 是站在接收端角度来说的，是接收端接收窗口满，自动告知对方不能再发送数据给自己。

3、TCP中的Window窗口：TCP的流量控制，窗口起始于确认序号字段指明的值，这个值是接收端正期望接收的字节数。

http代理服务器（3-4-7层代理）-网络事件库公共组件、内核kernel驱动 摄像头驱动 tcpip网络协议栈、netfilter、bridge 好像看过！！！！ 但行好事 莫问前程 --身高体重180的胖子

Redis利用内存发挥的高性能读写在很多场景下大有所为，但是Redis本身毕竟还是一个单机数据库，如果系统对其属于强依赖，那么还是必须做好必要的容灾，针对这个问题，有以下几种策略： 一、M/S切换 由于Redis是单机数据库，所以针对MySQL的一些容灾方案也能顺利适用，例如当Redis意外宕机，可以将请求马上切到备库，同时快速恢复数据。 二、AOF Redis有两种持久