本帖最后由 兰博 于 2018-6-22 09:47 编辑
有很多情况导致连接无法建立。 本文我们分析 2 种情况,分别是针对 Windows 和 Linux 进行讨论,它们是有区别的。 - 第一种情况是连接的主机不在网络中
- 第二种情况是主机在网络中,但是对应的服务未开启
不同版本的 Linux 内核也是有区别的。这里我使用的是 Ubuntu 14.04 LTS 版本。 1. 相关网络地址对应关系在这里牵扯的 ip 地址有点多,可能会让你乱。我解释一下: - 我的宿主机有两个 ip 地址,一个是本地网卡的地址:192.168.166.107,另一个是虚拟网卡 192.168.80.2
- 虚拟机中的 Linux 用的也是虚拟网卡,ip 地址是 192.168.80.130
关于第 2 节的修正:之前的实验有点问题,目标主机虽然没有 ping 通,但是却返回了 RST。不过当时的环境已经没有了,这里我的主机更换成了 10.154.0.45。 2. 主机不在网络中实验中,Linux 主机的地址是 10.154.0.45,我们去连接一个不存在的主机 10.154.1.45. 2.1 Linux 上的测试在 Linux 上使用 tcpdump 命令进行抓包。cli 程序的路径是 unp/protocol/tools/tcpclient/cli.c. $ sudo tcpdump port 5000- 再开一个终端连接一个不存在的主机,注意这个 ip 地址不要和你的 Linux 在同一个网段,我的 Linux 主机 ip 是 10.154.0.45,是 0 网段,要连接的是 1 网段。
$ ./cli 10.154.1.45 5000ip 地址为 10.154.1.45 这个主机是不存在的,但是客户端并不清楚此主机是否在网络中。
图1 客户端超时
图2 tcpdump 抓包
我们可以分析出以下结果: - 客户端发送了 SYN 请求后,因为超时没有 ack 返回,重传了 6 次 SYN;最终 connect 超时。
- 每次超时时间都是上一次的 2 倍(指数退避算法)
2.2 Window 7 上的测试首先在 Windows 7 上打开 OmniPeek,网卡选你上网的那个,不要选虚拟机网卡。 接下来使用 tcp_client 去连接 192.168.165.2 主机。我的 Window 7 ip 地址是 192.168.166.107. 同样的,不要让目标 ip 地址和连接的主机在同一个网段。 - 打开 OmniPeek 开始抓包
- 打开 cmd,连接目标主机
F:\tools> tcp_client 192.168.165.2 5000在 Win7 上进行了三次实验,结果如图 3.
图 3 Windows 上的三次测试
从图 3 中可以看到,Windows 第一次发送完 SYN 段后,没有等到对端 ACK,进行了 2 次重传。也就是一共发送了 3 次 SYN 段,如果第 3 次发送的 SYN 还没有收到 ACK,超时后 connect 函数就直接返回错误。 另外,我们发现,第一次的超时时间约为 3 秒,第二次约为 6 秒。 3. 主机在网络中,但是服务未启动3.1 Linux 上的测试这里只进行了一次测试。实验和前面的区别就是要连接的主机就是我的 Windows. ./cli 192.168.166.107 5000
图4 连接 Windows 主机
从图 4 的结果来看,Linux 发送 SYN 段给目标主机后,对端直接丢了个 RST 段过来^_^,然后 connect 函数直接返回错误啦。。。。 3.2 在 Windows 上的测试在 Windows 上使用 tcp_client 去连接 Linux。 tcp_client.ext 192.168.80.130 5000
图5 Windows 上的测试
可以看到,Windows 脸皮是比较厚的,对方丢了个 RST 段过来,仍然不放弃,又发两次 SYN 段。 4. 总结- 知道 TCP 对于连接建立异常如何处理的
- 知道 Windows 和 Linux 是有区别的
|