本文共 1811 字，大约阅读时间需要 6 分钟。

       在本文中， 我们首先来复习一下telnet命令， 然后聊聊我碰到过的tcp“三次握手”失败经历。

       在windows上利用wireshark启动抓包， 然后在cmd中执行telnet www.baidu.com 80， 去访问百度的80端口, 抓包结果如下：

        我们看到， 前面两个包是dns请求和回应， 其中101.226.4.6是360推荐给我的dns服务器， 现在， 我的pc 192.168.1.101向dns服务器101.226.4.6发起请求， 让dns服务器告诉我www.baidu.com的ip是多少， 结果dns服务器说， www.baidu.com的ip地址是180.97.33.107.（注意： 实际上， www.baidu.com对应的ip地址是经常变化的）

        现在， telnet www.baidu.com 80实际上就相当于telent 180.97.33.107 80， 也就是向180.97.33.107的80端口发起tcp连接， 后面的三个包就是tcp"三次握手"的数据包。 然后， 我们看不到更多的包包了。 也就是说：telent 180.97.33.107 80的作用仅仅是tcp“三次握手”试探。从这一点上，我们也可以看到， telnet是基于tcp协议的。

       好了， 今后要探测某服务端是否监听某端口， 可以考虑用telnet.  当然啦， 如果你能直接登录服务端， 那么用netstat命令就更好了。下面， 我来说说我经历过的tcp“三次握手”失败。

       为了便于叙述， 我假设我pc的ip是192.168.1.101,  另外一个设备E的ip地址是192.168.1.102, 现在， 我要探测设备E上是否在监听8888端口， 且假设没法进入设备E的shell命令行， 没法执行netstat命令， 那么我们就可以考虑在pc上用telnet命令， 直接执行telnet 192.168.1.102 8888. 下面， 我们来分析一下telnet 192.168.1.102 8888  （也就是“三次握手”）可能失败的原因。

       1.  网络不好， 典型症状是： ping不通。ping不通基本就能说明网络不好， 这个时候， 要检查一下网络， 如果是有线， 那要看看是不是网线松动了。 另外， 如果设置E在nat之后， 那telnet 192.168.1.102 8888 也自然失败。（当然， 在少数情况下， ping不通， 并不影响tcp“三次握手”， 我前面已经说过了这种情况）。  这些情况我亲自都碰到过。

       2. 网络是好的， 但是设备E并没有真正开启8888端口的监听。 这种情况我也亲自碰到过。

       3. 网络是好的， 也开启了8888端口的监听， 但是设置E端的防火墙并不允许外接来连接8888端口。我前几天写ftp主动模式的模式的时候就碰到过这种情况， 被折磨了近半个小时才怀疑到防火墙原因。

       4. pc和E之间的网络网络设置有防火墙， 把8888端口给屏蔽了。 这种情况， 我听说了好几次， 但是没有亲自碰到过。

       5. pc端的防火墙屏蔽了外出的8888断后， 典型症状是， 在本pc上telnet 192.168.1.102 8888会失败， 但是， 在其他的pc上，telnet 192.168.1.102 8888会成功。 只有放开自己pc的外出8888端口后， 才能成功“三次握手”。 这种情况， 某四个人都碰到，最后我都顺利定位并解决。

       除了上面的场景之外， 补充一个我遇到的真实场景， 简直又是一朵奇葩： 客户端连接不上服务端， 但去探测服务端(telnet 192.168.1.102 8888), 发现是服务端正在监听8888。那就奇怪了啊， 网络也是好的， 也没有什么防火墙和端口屏蔽， 不存在上述介绍的几种场景， 那怎么还连接不上呢？ 原来： 客户端连接服务端的时候， 要么是网络根本还没有起来，要么是服务端还没有来得及监听， 后来， 当我去探测服务端是否监听8888端口时， 是所以可通， 是因为时候网络刚好起来或者服务端刚刚完成监听。 清楚了吧， 就是个时序问题而已， 我也相信， 死啃书本， 肯定想不到还有这样的奇葩场景。

       好吧， 暂时遇到这么多， 想到这么多， 以后如果有新情况， 再补充。 总之，出了问题， 要多想方法， 多想可能， 大胆假设， 小心求证。