网络显形计（实战TCP三次握手）

　　摘要网络显形准备 实战TCP三次握手问题 网络显形准备
　　tcpdump命令
　　选项
　　示例
　　描述
　　-i
　　tcpdump -i eth0
　　指定网络接口，any表示所有接口
　　-nn
　　tcpdump -nn
　　不解析IP地址和端口号的名称
　　-c
　　tcpdump -c 5
　　限制要抓取的网络包的个数
　　-w
　　tcpdump -w file.pcap
　　将抓取的包保存到文件中
　　tcpdump -nn过滤
　　选项
　　示例
　　描述
　　host、src host、dst host
　　tcpdump -nn host 192.168.1.100
　　主机过滤
　　port、src port、dst port
　　tcpdump -nn port 80
　　端口过滤
　　ip、ip6、arp、tcp、udp、icmp
　　tcpdump -nn tcp
　　协议过滤
　　and、or、not
　　tcpdump -nn host 192.168.1.100 and port 80
　　逻辑表达式
　　tcp[tcpflags]
　　tcpdump -nn ＂tcp[tcpflags] & tcp-syn != 0＂
　　特定状态的TCP包
　　服务器环境准备
　　使用docker拉起两台容器，容器分别为： ubuntu client：用来当做客户端 nginx server：用来当做Server # 拉取Ubuntu Client docker run --privileged --name ubuntu_client -itd ubuntu  # 拉取Nginx Server docker run --privileged --name nginx -d nginx  # 查看容器信息 docker inspect ubuntu_client docker inspect nginx
　　容器名称    IP
　　ubuntu_client 172.17.0.3
　　nginx 172.17.0.2
　　在Nginx Server端抓取来自ubuntu client的ICMP包 在ubuntu_client容器中执行以下命令 # 进入容器 docker exec -it ubuntu_client /bin/bash # Ping Nginx Server ping 172.17.0.2 Nginx容器中执行以下命令 # 进入容器 docker exec -it nginx /bin/bash  # 执行抓包命令   tcpdump -i eth0 -nn icmp and host 172.17.0.3
　　在Nginx Server上执行抓包命令以后可以看到以下输出：
　　上述表述的信息还是比较少的，我们 在linux服务器上抓取的包一般会保存为pcap文件，然后导出到本地利用WireShark工具进行分析。 # 执行抓包并写入文件 tcpdump -i eth0 -nn icmp and host 172.17.0.3 -w icmp.pcap  # 在宿主机上执行，将容器内文件拷贝到本地  docker cp nginx:imcp.pcap ~/Downloads/
　　使用WireShark可以看出每一层的详细信息，如下图：
　　实战TCP三次握手问题
　　TCP三次握手流程我们已经详细讲述过，但现实往往不是圆满的，总会有这样那样的问题，在TCP握手的过程中每一个环节都有可能出现问题： TCP的第一次握手SYN包丢失 TCP的第二次握手SYN+ACK包丢失 TCP的第三次握手ACK包丢失
　　当然，TCP可以保证丢包重传，但是重传几次，经过多长时间重传、重传次数可不可以设置之前我们也没有太过说明，今天我们通过抓包来看一下上述问题。
　　TCP的第一次握手SYN包丢失
　　这里我们在Nginx Server上对防火墙进行一些修改，如下： # 拒绝所有来自ubuntu_client的数据包 iptables -I INPUT -s 172.17.0.3 -j DROP
　　在ubuntu_client执行以下命令，如下： # 执行抓包并写入文件 tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w http.pcap  # 另开一个窗口，执行curl请求nginx date;curl http://172.17.0.2;date
　　从上图中可以看出，在经过两分多钟以后，curl返回了超时错误。
　　再通过我们对抓的包进行分析： 客户端一共进行了6次重传 每次RTO的时间是不一样的，每次RTO几乎是翻倍上涨。
　　Linux第一次握手的重传次数由谁决定？ cat /proc/sys/net/ipv4/tcp_syn_retries
　　由内核参数tcp_syn_retries决定，从上图可以看出，我们这里的默认值是6。
　　读者可以将上述参数改为2，然后你会发现很快就会超时。
　　通过以上可以得出关于第一次握手的结论： 客户端在RTO时间内没有收到就会重传SYN包 每次重传RTO的时间翻倍增长 重传的最大次数由内核参数tcp_syn_retries指定
　　TCP的第二次握手SYN+ACK包丢失
　　在服务器上还原我们上边添加的拒绝规则，保证服务端可以正常的接收到客户端的数据。 # 删除 INPUT的第一条规则 iptables -D INPUT 1
　　在客户端上配置防火墙规则，拒绝掉Nginx Server的包，如下： # 拒绝来自Nginx Server的所有数据包 iptables -I INPUT -s 172.17.0.2 -j DROP  # 执行抓包并写入文件 tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w http.pcap  # 另开一个窗口，执行curl请求nginx date;curl http://172.17.0.2;date
　　从上图可以看出，SYN+ACK包的丢失会引起以下操作： 客户端未收到SYN+ACK包，超时重传SYN包 服务端未收到SYN+ACK包的ACK包，也会超时重传SYN+ACK包
　　为什么我们设置了防火墙依旧可以在客户端抓取包？
　　这个主要取决于iptables的限制条件： 如果添加的是INPUT规则，可以抓取包 如果添加的是OUTPUT规则，则无法抓包
　　原因是： 网络包进入主机后的顺序为：Wire -> NIC -> tcpdump -> netfilter/iptables 网络包从主机出去的顺序为：iptables -> tcpdump -> NIC -> Wire
　　二次握手的包最大重传次数由谁决定？
　　该最大重传次数由内核参数tcp_synack_retries决定。 # 默认值是5 cat /proc/sys/net/ipv4/tcp_synack_retries
　　下面我们分别对客户端和服务端做如下修改，： # 在Nginx Server上执行该命令将重传次数修改为2 echo 2 > /proc/sys/net/ipv4/tcp_synack_retries  # 在Ubuntu Client上执行该命令将SYN重传次数修改为1 echo 1 > /proc/sys/net/ipv4/tcp_syn_retries
　　通过上图可以看出，客户端的SYN包只重传了1次，服务端的SYN+ACK超时重传了2次。
　　TCP第三次握手ACK丢包
　　在开启实验前，大家记得还原一下客户端和服务端的iptables，然后在服务端对iptables做以下修改： # 屏蔽ubuntu客户端TCP报文中的标志位ACK的数据包 iptables -I INPUT -s 172.17.0.3 -p tcp --tcp-flag ACK ACK -j DROP
　　在客户端执行以下命令进行抓包： tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w telnet.pcap  # 然后另开启一个窗口，执行telnet指令 telnet 172.17.0.2 80
　　在客户端和服务端执行以下命令查看TCP连接建立情况： netstat -lantp
　　通过上图可以看出，客户端这边的TCP连接建立完成，TCP连接状态处于ESTABLISHED。但服务端由于收不到第三次握手的ACK包，因此一直处于SYN_RECV状态，如下图：
　　但是Nginx Server端的连接会在一定时间后消失。
　　我们过一段时间后在telnet窗口再输入123456字符，然后再抓一会包，如下图所示：
　　从上图中可以看出，由于NginxServer上的tcp_synack_retries参数被设置为2次，上图中我们可以看出SYN+ACK包超时重传了2次，2次以后不再重传，此时服务端的TCP连接就主动中止了，所以处于SYN_RECV状态的连接就消失了。
　　由于客户端的连接还没中断，我们输入123456发送给服务端，但是服务端已经断开连接，客户端的数据一直在不停的重传(PUSH+ACK报文)，那么客户端建立连接后重传的最大次数是由啥控制呢？
　　由内核参数tcp_retries2控制。 # 执行以下命令，可以看出默认值是15 cat /proc/sys/net/ipv4/tcp_retries2
　　当你将客户端的tcp_retries2参数修改为2以后，当你再次输入123456字符，你会发现很快telnet客户端就断开，如下图：
　　假设客户端一直不发送数据，那么连接什么时候断开？
　　此时需要借助TCP的保活机制，关于保活机制我们已经讲过了，可以私信我获取原文，不清楚的可以再回顾一下。