文件传输时的网络情况排查

ctorrent p2p 文件传输

前言

linux 下的p2p传输软件ctorrent在互联网上传输文件时，有时会遇到网络的问题，导致无法传输，表现在链接不断地中断，无法传输。

绝大部分的网络都是正常的，只有个别的网络有问题。
根据这2年的实际情况，观察到 电信通网络对p2p支持不友好，不稳定。 中国移动的网络会分区域、分时间端地不稳定。

传输正常的网络实例

时间：2018年及2019年年初。

阿里云的服务器所连接的网络没有出现过这种现象。
腾讯的服务器所连接的网络没有出现过这种现象。
国外的日本，美国的主机也没有出现过这种现象。
具体到网络运营商：
从北京联通发送，到北京联通，上海电信，常州电信 都是正常接收的。

传输异常的网络实例

目前发现：电信通的网络无法传输。具体实例和现象如下。

网络排查方法

1. 首先排查下防火墙的问题，确保不是因为p2p协议，6969, 2706,2705等端口被封导致的无法传输。
2. 启动 ctorrent进行网络文件传输。
   如果能正常地发送和正常地接收完整的文件，即表示网络正常。
3. 运行网络数据报监控软件nethogs查看连接与传输速率情况.
   正常只有一个传输进程，以每秒 XXX K/s 或 M/s 的速率传输。 有很多进程起起伏伏的，都是传输速率为0的情况，那么说明网络有问题，数据包被截断了。

如果正常：nethogs查看的网络连接很稳定，没有无效链接不断出现。
如果异常：nethogs不断出现新的链接速率为0的连接，如下图：

ctorrent 发送时网络问题监控情况排查历史实例

因为有些网络服务商可能因为自己网络的问题，会造成ctorrent无法正常运行，就需要提供相应情况供他们排查。
另外如果运行不正常，也可能是因为网管封了p2p的传输。需要根据具体情况排查。

以下的几次测试全部都是 电信通的网络下作的测试情况，时间是2018年年中。
中间曾经修复过，可以传输了，但是传输速率很低，还是异常。

第一次测试

nethogs

可以看到不断地产生新的ctorrent 连接到 另外一个服务器的 2704端口(ctorrent的服务端口)

另一台服务器的2704处于监听状态

用nethogs看有一些流量产生，
再去看
实际接收的文件百分比：

ctorrent -c file13M.dat.torrent 

其路由情况：

rbk@rbk-OptiPlex-7010:~$ traceroute 140.143.197.160
traceroute to 140.143.197.160 (140.143.197.160), 30 hops max, 60 byte packets
 1  192.168.80.1 (192.168.80.1)  0.799 ms  0.785 ms  0.770 ms
 2  218.249.57.1 (218.249.57.1)  54.155 ms  54.754 ms  55.753 ms
 3  10.255.37.133 (10.255.37.133)  23.469 ms  22.871 ms  23.155 ms
 4  218.241.253.85 (218.241.253.85)  22.849 ms  23.116 ms  23.088 ms
 5  * 14.197.178.49 (14.197.178.49)  23.072 ms  23.053 ms
 6  14.197.252.49 (14.197.252.49)  23.043 ms 14.197.219.201 (14.197.219.201)  24.327 ms *
 7  * 14.197.213.62 (14.197.213.62)  17.790 ms  17.754 ms
 8  14.197.215.154 (14.197.215.154)  17.752 ms 14.197.149.246 (14.197.149.246)  20.502 ms 14.197.215.150 (14.197.215.150)  20.484 ms
 9  10.200.5.73 (10.200.5.73)  20.465 ms  19.114 ms  20.427 ms
10  10.200.150.190 (10.200.150.190)  35.698 ms 10.200.150.222 (10.200.150.222)  38.072 ms 10.200.150.190 (10.200.150.190)  34.952 ms
11  10.200.150.222 (10.200.150.222)  37.013 ms  38.321 ms 10.200.150.190 (10.200.150.190)  22.003 ms
12  100.120.215.229 (100.120.215.229)  23.786 ms  23.760 ms 100.120.219.229 (100.120.219.229)  29.385 ms
13  140.143.197.160 (140.143.197.160)  26.324 ms  24.136 ms  25.620 ms

到另外一台服务器的路由

rbk@rbk-OptiPlex-7010:~$ traceroute 124.193.192.168
traceroute to 124.193.192.168 (124.193.192.168), 30 hops max, 60 byte packets
 1  192.168.80.1 (192.168.80.1)  0.895 ms  0.883 ms  0.868 ms
 2  218.249.57.1 (218.249.57.1)  8.759 ms  10.092 ms  10.625 ms
 3  124.193.192.168 (124.193.192.168)  21.170 ms  21.167 ms  21.153 ms

都同时经过了
218.249.57.1 这台网关或路由器
可能是这台机器的对特定的tcp包做了过滤策略处理，无意中中断了 ctorrent的链接，导致无法传输数据。

解决方案：A. 联系网络运营商， B. 修改tcp包的特征，例如修改包头特征。

第二次测试

2018.6.28

拓扑图

将 ctserver 从机房的防火墙下面搬出来到光猫的下面，配置了一个公网ip
124.193.192.162
然后尝试发送文件到 tencent1, vultr4 仍然是失败，有数据发出，但是接收端收不到。

但是过了几分钟，接收端开始都收到了。

再尝试发送88M的文件
tencent1 收到了，但是vultr4没收到。

root@ctserver:~/test# traceroute 140.143.197.160
traceroute to 140.143.197.160 (140.143.197.160), 30 hops max, 60 byte packets
 1  gateway (124.193.192.161)  7.382 ms  8.337 ms  9.236 ms
 2  10.255.37.133 (10.255.37.133)  3.020 ms  3.366 ms  3.110 ms
 3  218.241.253.85 (218.241.253.85)  2.228 ms  2.230 ms  2.221 ms
 4  14.197.210.209 (14.197.210.209)  1.207 ms  1.279 ms *
 5  14.197.252.53 (14.197.252.53)  2.548 ms 14.197.219.201 (14.197.219.201)  3.445 ms 14.197.219.205 (14.197.219.205)  2.924 ms
 6  14.197.213.86 (14.197.213.86)  2.278 ms 14.197.196.26 (14.197.196.26)  3.855 ms 14.197.196.22 (14.197.196.22)  4.036 ms
 7  14.197.245.2 (14.197.245.2)  2.846 ms 14.197.215.142 (14.197.215.142)  3.157 ms 14.197.215.154 (14.197.215.154)  3.814 ms
 8  10.200.5.69 (10.200.5.69)  3.578 ms  4.912 ms  5.165 ms
 9  10.200.150.174 (10.200.150.174)  18.322 ms  18.810 ms 10.200.150.206 (10.200.150.206)  18.984 ms
10  10.200.150.206 (10.200.150.206)  18.313 ms  16.860 ms *
11  100.120.215.229 (100.120.215.229)  11.573 ms 100.120.219.229 (100.120.219.229)  13.147 ms 100.120.215.229 (100.120.215.229)  10.980 ms
12  140.143.197.160 (140.143.197.160)  3.914 ms  3.335 ms  3.263 ms

root@ctserver:~/test# traceroute 149.28.75.117
traceroute to 149.28.75.117 (149.28.75.117), 30 hops max, 60 byte packets
 1  gateway (124.193.192.161)  5.645 ms  6.665 ms  7.543 ms
 2  10.255.37.133 (10.255.37.133)  3.143 ms  7.572 ms  7.742 ms
 3  124.205.98.201 (124.205.98.201)  3.203 ms  3.177 ms  3.158 ms
 4  124.205.98.253 (124.205.98.253)  3.907 ms  3.559 ms *
 5  218.241.244.9 (218.241.244.9)  3.023 ms 218.241.244.17 (218.241.244.17)  3.013 ms 218.241.244.21 (218.241.244.21)  4.256 ms
 6  218.241.244.69 (218.241.244.69)  4.198 ms  3.676 ms  3.666 ms
 7  * 106.120.192.5 (106.120.192.5)  6.945 ms  6.982 ms
 8  106.120.234.141 (106.120.234.141)  3.286 ms  2.925 ms  2.962 ms
 9  * * *
10  202.97.48.218 (202.97.48.218)  6.304 ms 202.97.94.206 (202.97.94.206)  8.053 ms 202.97.53.114 (202.97.53.114)  7.463 ms
11  202.97.53.62 (202.97.53.62)  9.411 ms  9.374 ms 202.97.81.170 (202.97.81.170)  8.075 ms
12  202.97.52.86 (202.97.52.86)  167.216 ms  167.219 ms 202.97.52.190 (202.97.52.190)  228.261 ms
13  202.97.90.118 (202.97.90.118)  179.838 ms * 202.97.86.177 (202.97.86.177)  164.823 ms
14  218.30.53.70 (218.30.53.70)  193.710 ms te-0-3-0-8-pe03.11greatoaks.ca.ibone.comcast.net (66.208.216.41)  155.565 ms 218.30.53.70 (218.30.53.70)  193.100 ms
15  hu-0-3-0-7-cr01.9greatoaks.ca.ibone.comcast.net (68.86.83.137)  156.501 ms hu-0-3-0-5-cr01.9greatoaks.ca.ibone.comcast.net (68.86.83.129)  156.280 ms hu-0-4-0-4-cr01.9greatoaks.ca.ibone.comcast.net (68.86.88.189)  146.537 ms
16  be-11025-cr02.sunnyvale.ca.ibone.comcast.net (68.86.87.157)  150.045 ms * *
17  * * be-11015-cr02.losangeles.ca.ibone.comcast.net (68.86.86.98)  278.433 ms
18  149.28.75.117.vultr.com (149.28.75.117)  184.056 ms be-11599-pe01.losangeles.ca.ibone.comcast.net (68.86.84.194)  172.469 ms  172.483 ms

对比正常的阿里云发送

从 阿里云 发送
区别1： nethogs查看的网络连接很稳定，没有无效链接不断出现。
区别2： 接收端tencent1, vultr4 马上开始接收数据。

第三次测试

经客服反映，说做过调整了，让我再测试一遍。
结果还是刚开始时接收端收不到，发送端不断地出现连接客户端端口的情形
正常是一开始就能收到，没有创建这么多的TCP链接。

如图，本机不断连接 腾讯tencent1的 2703端口，（正常应该不会出现这么多连接，只一次就够了)

过了一会，接收端都开始接收了，这是之前所没有的。所以问题只解决了一半。

第四次测试

从218.249.57.8 （ 内网ip： 192.168.80.33 ) 往外发送文件。仍然一样的现象。一开始发送，通过网络监控工具nethogs看到有不断的出现断开的网络连接，然后ctorrent就不断尝试再建立新连接。
接收端 149.28.75.117 接收很慢； 140.143.197.160 接收很慢。