一 实验三：TCP 第三次握手 ACK 丢包
第三次握手丢失了,会发生什么?
注意: ACK 报文是'不会有重传'的,当 ACK '丢失'了,就由'对方重传'对应的报文① 实验环境
② 模拟方式
1、 服务端配置'防火墙'
iptables -t filter -I INPUT -s 172.25.2.157 -p tcp --tcp-flag ACK ACK -j DROP
备注： 'DROP'策略就是'不响应'
iptables -t nat -D INPUT [$Num] --> "记得还原"
注意：'$Num' 指的是需要删除的num,删除规则后,下方的'其他规则'会'补位',num会发生变更
+++++++++++++++++ "分割线" +++++++++++++++++
2、 客户端执行'tcpdump'命令抓包
tcpdump -nni ens3 tcp and host 172.25.2.100 and port 80 -w tcp_third_ack.pcap③ 客户端发起请求
1、客户端向'服务端'发起 telnet,因为 telnet 命令是会'发起 TCP 连接',所以用此命令做测试
2、此时由于服务端'收不到第三次握手' 客户端的 ACK 包,所以一直处于 'SYN_RECV' 状态 
3、而客户端是'已完成 TCP 连接'建立,处于 'ESTABLISHED' 状态：
4、继续过了 '1' 分钟后,观察发现'服务端'的 'TCP 连接'不见了
5、过了 '20' 分钟,'客户端'依然还是处于 'ESTABLISHED' 状态
6、接着,在刚才'客户端建立的 telnet 会话',输入 '123456' 字符,进行'发送'
7、持续 '好长'一段时间,客户端的 telnet 才'断开'连接
备注： 等待的时间'太长'
④ 疑惑点
⑤ 分析
我们把'刚抓'的数据包,用 'Wireshark' 打开分析,显示的'时序图'如下：
+++++++++++++ 上图的流程'文字'分析 +++++++++++++
关注点： '服务端'的 TCP 连接'主动'中止了,所以刚才处于'SYN_RECV 状态'的 TCP 连接'断开'了
⑥ 思考1
1、TCP 第'一次'握手的 SYN 包超时重传最大次数是由 'tcp_syn_retries' 指定
2、TCP 第'二'次握手的 SYN、ACK 包超时重传最大次数是由 'tcp_synack_retries' 指定
3、思考1： 那 TCP 建立连接后的'数据包最大超时重传次数'是由'什么参数'指定呢?
tcp_retries2 设置了 15 次,并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接
疑问： 那 TCP 的'数据报文'具体'重传'几次呢?
每一轮的 RTO '增长'关系'如下'表格：
⑦ 思考2
思考： 那如果客户端'不发送'数据,什么时候才会断开处于 'ESTABLISHED' 状态的连接?
备注： 这个时间是'有点长'的,所以如果我'抓包足够久','或许'能抓到'探测'报文TCP 保活机制
⑧ 小结
