TCP/IP(二十一)TCP 实战抓包分析(五)TCP 第三次握手 ACK 丢包

一  实验三：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 保活机制 

⑧   小结