EDI通信中常用的网络排查方法

在知行之桥EDI系统运维工作中不可避免会碰到各种网络问题，本文将分享一些我们运维同事常用的一些网络问题排查定位方法，帮助大家快速的定位原因，解决通信问题。

1.Ping：
作用：ping用于确定本地主机是否能与另一台主机成功交换数据包，再根据返回的信息，可以判断TCP/IP参数是否设置正确，以及运行是否正常，网络是否通畅。
命令：ping IP/域名
以访问百度为例，以下ping结果表示连接百度网站正常，网络通畅。

2.Telnet
作用：远程登录目的主机，这里主要用来确认交易伙伴服务器开放的端口我们是否可以访问。
命令：telnet IP/域名 端口
（1）Windows服务器
执行telnet命令，按下回车键后，结果如下图表示连接成功：

（2）Linux服务器
执行telnet命令，按下回车键后，结果如下图表示连接成功：

退出telnet方式：ctrl+]，输入quit退出

3.直接访问交易伙伴的URL
如果使用的是AS2协议，可以直接在浏览器中访问下对方的URL，示例：交易伙伴的URL是https://192.168.0.117:8081/pub/Receive.rsb
（1）Windows服务器：
直接在浏览器中进行访问，以下页面表示访问知行之桥接收地址成功，具体的反馈信息根据交易伙伴的服务器端的设置为准，比如直接显示Success.

（2）Linux服务器
执行命令：wget url

注意：如果交易伙伴使用的是https，可以加上–no-check-certificate跳过对SSL证书的验证，即wget --no-check-certificate url

4.Tracert
作用：路由跟踪，一般用来确定IP数据包访问目标时所选择的路径，它主要检查网络连接是否可达，以及分析网络什么地方发生了故障。
命令：
（1）Windows服务器
tracert IP/域名

（2）Linux服务器
traceroute IP/域名

5.抓包
抓包主要通过抓取网络数据包，然后最大限度分析出网络数据包的详细的资料，从而分析网络中的丢包情况，进行网络故障分析。以下是运维团队常用的抓包方法：
（1）Windows服务器
Windows服务器可以使用常见的wireshark工具进行抓包并进行结果分析

（2）Linux服务器
tcpdump命令：tcpdump -i 网卡 port 端口号 -w 保存文件目录及文件名
其中：网卡为指定网卡，any表示监听所有网卡；文件名后缀为.pcap，抓包的结果可以用wireshark来进行分析。

常见的网络问题原因：

1.端口未开放
2.防火墙限制
3.有一些特殊的安全策略、路由设置
4.网络运营商更改了网路设置，导致通信失败
5.云服务器升级或者更新调整，导致配置更改，通信失败

案例分享：

1.前段时间，运维团队有处理过一个这样的网络问题：
问题： 客户A、客户B、客户C都与交易伙伴D进行AS2直连，客户A可以正常给交易伙伴D发送数据，客户B、客户C项目开始时都可以正常给D发送数据，但是某一天突然发送数据失败，发送数据时报错：SendFile Failed: Remote host disconnected during SSL negotiation.或者Timeout.

排查过程： 首先，报错信息明显显示是连接D服务器失败，B和C在EDI服务器上执行telnet、tracert命令失败，应该是D这边做了限制，但是联系D后，D反馈他们没有做任何限制，所有客户都可以连接，并让B和C排查自己的网络；
之后，B和C经过技术人员的排查，他们网络都是没有问题。
针对相同的问题，我们运维团队将B和C使用的服务器、服务器IP归属区域、网络运营商等信息进行了对比，发现他们都使用的阿里云服务器，于是在本地申请了阿里云、华为云、Azure云服务器进行测试telnet、tracert、使用postman发起post请求等测试，发现阿里云服务器连接D失败，华为云和Azure云服务器则没有问题，此时便基本可以确定是阿里云服务器的问题，和阿里云客服确认后推测应该是D对阿里云服务器的IP段进行了限制，之后和D确认确实如此，将B和C的IP提供给D后，D取消限制后便解决了问题。

2.EDI通信中最常见的是双方网络连接是正常的，但是在文件传输中会偶尔出现文件传输失败的情况，这种常常是因为网络不稳定造成的，遇到这种情况知行之桥会自动重发失败的数据，不需要在EDI中修改任何操作，常见的一些网络不稳定的报错如下：
Connection failed: 由于目标计算机积极拒绝，无法连接。 XXX.XXX.XXX.XXX:XXXX
Remote host disconnected during SSL negotiation.
无法打开连接：Timeout.
Error during handshake: 为验证提供的消息或签名已被更改 (0x8009030F)
Cannot send response: 企图在不存在的网络连接上进行操作。

如果网络不稳定比较频繁您可以优化您的网络，或者您可以租用与交易伙伴同一时区的云服务器来改善，或者可以设置网络代理来避免。