网络知识与接口对接

*、在一次项目中要和其他公司对接一个接口，由于本人并不负责硬件设施的搭建，所以一直认为本公司的内部网络环境没有问题，然而在一点点的摸索和监测后发现了个乌龙事件，也算是自己学艺不精吧，不过能一点点发现其中的猫腻，还是很有成就感的，下面记录一下自己的对接思路：

 

*、首先根据对方给定的接口文档和demo，首先进行网络状态的判断

正常逻辑：对方给定的demo在开通权限的网络环境中应该可以直接运行才对，但是发现未能成功，于是便开始查找原因，首先使用telnet命令查看接口对应端口是否能够成功连接，telnet确实提示已连接，然而事实证明是有问题的，问题在于若用tracert去跟踪接口IP会发现一些猫腻，比如路由回环[2018年8月30日15:31:02：此处可以考虑是否需要代理IP]，但是之前并没有想到这一层，而是在经历了在线POST工具测试接口，发现一直提示接口地址不可用的弯路后，无奈之下，使用postman工具却能正常获取[此处猜想：postman能自动检索系统开启的监听端口作为代理IP]，此时就更郁闷了

 

*、郁闷并不能解决问题，于是利用很神奇的抓包手段

在一系列的抓包工具wireshark的安装，各种查询资料的情况下，完成了对目标IP的过滤，从而拿到了目标数据，此时更郁闷了：httpclient可以抓到包，但postman却死活抓不到包，这对能力有限的我真的感觉好神奇，言归正传，包只有两个第一个是TCP的第一次握手(理论上应该是完整的三次握手)，然后便是其中的一个路由节点传回的信息Time-to-line exceeded(理论上应该是目标端发回的数据结果等信息),在查询资料后确认了tracert中的路由回环是关键。接下来就是对路由节点的处理，待续，2018年8月24日20:37:23新增，路由环路是因为在正常流程下只能到达这个路由节点，发现postman可以访问，应该联想到是不是有特殊路由如代理IP等实现了对外地址的访问，更专业的解释留待后续

 

*、关于httpclient出现timeout却可以抓包，postman不能抓包却能正常获取数据的思考

postman对于路由回环有一定的忽略或处理能力
httpclient无法处理路由回环造成的问题
期待更专业的解释~
正确与否有待指正，ヾ(o′▽`o)ノ°°谢谢
2018年8月24日20:35:56
猜测：postman自动检测系统中的监听地址作为代理IP所以可以访问

 

*、结果

目前:编码增加代理后可运行，但是又遇到一次超时问题，即服务器上安装的代理服务有超时限制，哎，又是折腾了一周才算是勉强解决问题，超时不能为空，也就意味着总要有一个限制。