请问下,用PING的方式测试丢包率可行吗?

[JBlazingSun]

VPS是美国的辣鸡线路, 本地是虚拟机作为client, 按照教程默认参数执行后, 在虚拟机上PING 10.22.22.1 64 bytes from 10.22.22.1: icmp_seq=1 ttl=64 time=764 ms 64 bytes from 10.22.22.1: icmp_seq=2 ttl=64 time=690 ms 64 bytes from 10.22.22.1: icmp_seq=3 ttl=64 time=580 ms 64 bytes from 10.22.22.1: icmp_seq=4 ttl=64 time=996 ms no answer yet for icmp_seq=5 no answer yet for icmp_seq=6 64 bytes from 10.22.22.1: icmp_seq=6 ttl=64 time=1212 ms 64 bytes from 10.22.22.1: icmp_seq=7 ttl=64 time=794 ms 64 bytes from 10.22.22.1: icmp_seq=8 ttl=64 time=965 ms 64 bytes from 10.22.22.1: icmp_seq=9 ttl=64 time=988 ms 64 bytes from 10.22.22.1: icmp_seq=10 ttl=64 time=868 ms no answer yet for icmp_seq=11 64 bytes from 10.22.22.1: icmp_seq=11 ttl=64 time=1049 ms no answer yet for icmp_seq=12 no answer yet for icmp_seq=13 64 bytes from 10.22.22.1: icmp_seq=14 ttl=64 time=966 ms 64 bytes from 10.22.22.1: icmp_seq=15 ttl=64 time=787 ms 64 bytes from 10.22.22.1: icmp_seq=16 ttl=64 time=772 ms 64 bytes from 10.22.22.1: icmp_seq=17 ttl=64 time=762 ms 64 bytes from 10.22.22.1: icmp_seq=18 ttl=64 time=912 ms no answer yet for icmp_seq=19 64 bytes from 10.22.22.1: icmp_seq=19 ttl=64 time=1057 ms 64 bytes from 10.22.22.1: icmp_seq=20 ttl=64 time=934 ms 64 bytes from 10.22.22.1: icmp_seq=21 ttl=64 time=976 ms 64 bytes from 10.22.22.1: icmp_seq=22 ttl=64 time=999 ms no answer yet for icmp_seq=23 64 bytes from 10.22.22.1: icmp_seq=23 ttl=64 time=1181 ms no answer yet for icmp_seq=24 64 bytes from 10.22.22.1: icmp_seq=24 ttl=64 time=1112 ms 64 bytes from 10.22.22.1: icmp_seq=25 ttl=64 time=780 ms no answer yet for icmp_seq=26 64 bytes from 10.22.22.1: icmp_seq=26 ttl=64 time=1239 ms

--- 10.22.22.1 ping statistics --- 52 packets transmitted, 49 received, 5% packet loss, time 51061ms rtt min/avg/max/mdev = 394.264/913.136/1414.598/254.678 ms, pipe 2

请问下这样的丢包情况, 是我测试方法的问题还是设置问题呢? 有些连续丢2个的包没有重发 谢谢

[wangyu-]

有可能是网络本身的丢包很高，默认的参数冗余度不够，自己根据readme调一下参数。

[JBlazingSun]

命令改成 ./tinyvpn -s -l0.0.0.0:4096 -f1:10 -k "passwd" --sub-net 10.22.22.0

1:10 就是10倍发包了吧? 在PING测试的时候还是会丢包, 而且后来一直PING不通了, 估计是被运营商掐断了

一般是1:3玩游戏比较好吗?

[wangyu-]

一般是1:3玩游戏比较好吗?

根据网络本身的丢包率、丢包特性，自己调整参数。

1:10 就是10倍发包了吧? 在PING测试的时候还是会丢包，而且后来一直PING不通了, 估计是被运营商掐断了

有可能是你的网络本身非常差。也有可能你的运营商对UDP有限速或者屏蔽；可以套上udp2raw试试情况有没有好转。你提供的信息太少了，没办法确定。

请问下这样的丢包情况, 是我测试方法的问题还是设置问题呢?

信息太少，无法确定。你应该至少提供一下网络本身的丢包数据。

[wangyu-]

https://github.com/wangyu-/tinyFecVPN/wiki/使用经验#如何测试网络本身的丢包率

[JBlazingSun]

[2017-11-13 07:56:35][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:56:46][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:56:56][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:06][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:16][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:27][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:37][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:48][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:57:58][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte) server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte) [2017-11-13 07:58:01][INFO]connection accepted by server [2017-11-13 07:58:08][INFO][report]client-->server:(original:24 pkt;1600 byte) (fec:274 pkt,7808 byte) server-->client:(original:21 pkt;20174 byte) (fec:211 pkt;39471 byte) [2017-11-13 07:58:19][INFO][report]client-->server:(original:73 pkt;5355 byte) (fec:998 pkt,26743 byte) server-->client:(original:67 pkt;66990 byte) (fec:1079 pkt;154644 byte) [2017-11-13 07:58:29][INFO][report]client-->server:(original:98 pkt;6971 byte) (fec:1318 pkt,35347 byte) server-->client:(original:89 pkt;86320 byte) (fec:1342 pkt;196423 byte) [2017-11-13 07:58:40][INFO][report]client-->server:(original:98 pkt;6971 byte) (fec:1318 pkt,35347 byte) server-->client:(original:89 pkt;86320 byte) (fec:1342 pkt;196423 byte) [2017-11-13 07:58:50][INFO][report]client-->server:(original:131 pkt;9807 byte) (fec:1809 pkt,48123 byte) server-->client:(original:118 pkt;106544 byte) (fec:1652 pkt;234996 byte) [2017-11-13 07:59:00][INFO][report]client-->server:(original:326 pkt;34314 byte) (fec:6728 pkt,178066 byte) server-->client:(original:160 pkt;133938 byte) (fec:2228 pkt;291349 byte) [2017-11-13 07:59:11][INFO][report]client-->server:(original:555 pkt;63488 byte) (fec:12949 pkt,337431 byte) server-->client:(original:172 pkt;139000 byte) (fec:2460 pkt;304548 byte) [2017-11-13 07:59:21][INFO][report]client-->server:(original:605 pkt;69781 byte) (fec:14141 pkt,368935 byte) server-->client:(original:195 pkt;158637 byte) (fec:2640 pkt;332982 byte) [2017-11-13 07:59:32][INFO][report]client-->server:(original:606 pkt;69868 byte) (fec:14167 pkt,369559 byte) server-->client:(original:196 pkt;158740 byte) (fec:2652 pkt;333306 byte) [2017-11-13 07:59:42][INFO][report]client-->server:(original:606 pkt;69868 byte) (fec:14167 pkt,369559 byte) server-->client:(original:196 pkt;158740 byte) (fec:2652 pkt;333306 byte)

请问加上 --report 10 以后, 这样的返回值是正常的吗, 这是客户端的, 服务端没有返回

[JBlazingSun]

能不能提个需求, 就是readme教程里面增加输入命令后正常的返回值的示例.

[wangyu-]

正常结果是这样的。

root@raspberrypi:/home/pi# ./tinyvpn_arm -c -r 127.0.0.1:8855 --sub-net 10.222.2.0 --tun-dev tun100 --log-level 4 --mtu 1000 --mode 0 --keep-reconnect  --disable-obscure --report 10
[2017-11-13 07:57:56][INFO]argc=18 ./tinyvpn_arm -c -r 127.0.0.1:8855 --sub-net 10.222.2.0 --tun-dev tun100 --log-level 4 --mtu 1000 --mode 0 --keep-reconnect --disable-obscure --report 10
[2017-11-13 07:57:56][INFO]sub_net 10.222.2.0
[2017-11-13 07:57:56][INFO]tun_dev=tun100
[2017-11-13 07:57:56][INFO]running at tun-dev mode
[2017-11-13 07:57:56][INFO]keep_reconnect enabled
[2017-11-13 07:57:56][INFO]obscure disabled
[2017-11-13 07:57:56][INFO]jitter_min=0 jitter_max=0 output_interval_min=0 output_interval_max=0 fec_timeout=8 fec_data_num=20 fec_redundant_num=10 fec_mtu=1000 fec_queue_len=200 fec_mode=0
[2017-11-13 07:57:56][INFO]using interface tun100
[2017-11-13 07:57:56][INFO][report]client-->server:(original:0 pkt;0 byte) (fec:0 pkt,0 byte)  server-->client:(original:0 pkt;0 byte) (fec:0 pkt;0 byte)
[2017-11-13 07:57:57][INFO]connection accepted by server
[2017-11-13 07:58:06][INFO][report]client-->server:(original:71 pkt;14785 byte) (fec:878 pkt,37565 byte)  server-->client:(original:69 pkt;18082 byte) (fec:775 pkt;40483 byte)
[2017-11-13 07:58:17][INFO][report]client-->server:(original:135 pkt;23416 byte) (fec:1489 pkt,60651 byte)  server-->client:(original:126 pkt;43849 byte) (fec:1505 pkt;90214 byte)
[2017-11-13 07:58:27][INFO][report]client-->server:(original:2688 pkt;184603 byte) (fec:8038 pkt,415504 byte)  server-->client:(original:4897 pkt;4670372 byte) (fec:12543 pkt;7141275 byte)
[2017-11-13 07:58:37][INFO][report]client-->server:(original:3596 pkt;237750 byte) (fec:11418 pkt,558603 byte)  server-->client:(original:7661 pkt;7375656 byte) (fec:19150 pkt;11265335 byte)

$ ./tinyvpn_amd64 -s -l 127.0.0.1:8855 --sub-net 10.222.2.0 --tun-dev tun100 --log-level 4 --mtu 1000 --mode 0  --disable-obscure --report 10
[2017-11-13 07:57:52][INFO]argc=17 ./tinyvpn_amd64 -s -l 127.0.0.1:8855 --sub-net 10.222.2.0 --tun-dev tun100 --log-level 4 --mtu 1000 --mode 0 --disable-obscure --report 10
[2017-11-13 07:57:52][INFO]sub_net 10.222.2.0
[2017-11-13 07:57:52][INFO]tun_dev=tun100
[2017-11-13 07:57:52][INFO]running at tun-dev mode
[2017-11-13 07:57:52][INFO]obscure disabled
[2017-11-13 07:57:52][INFO]jitter_min=0 jitter_max=0 output_interval_min=0 output_interval_max=0 fec_timeout=8 fec_data_num=20 fec_redundant_num=10 fec_mtu=1000 fec_queue_len=200 fec_mode=0
[2017-11-13 07:57:52][INFO]using interface tun100
[2017-11-13 07:57:57][INFO]new connection from 127.0.0.1:36774
[2017-11-13 07:57:57][INFO][report][127.0.0.1:36774]client-->server:(original:5 pkt;979 byte) (fec:70 pkt;2668 byte)  server-->client:(original:5 pkt;466 byte) (fec:62 pkt;1851 byte)
[2017-11-13 07:58:07][INFO][report][127.0.0.1:36774]client-->server:(original:72 pkt;14845 byte) (fec:892 pkt;37915 byte)  server-->client:(original:71 pkt;18194 byte) (fec:803 pkt;41155 byte)
[2017-11-13 07:58:18][INFO][report][127.0.0.1:36774]client-->server:(original:489 pkt;48272 byte) (fec:2558 pkt;116817 byte)  server-->client:(original:838 pkt;737445 byte) (fec:3709 pkt;1151784 byte)

能不能提个需求, 就是readme教程里面增加输入命令后正常的返回值的示例.

都写在readme里太乱了，就贴在这里吧。

[wangyu-]

请问加上 --report 10 以后, 这样的返回值是正常的吗, 这是客户端的, 服务端没有返回

你必须要用这条VPN连接收发数据，这里才会有统计结果。

[JBlazingSun]

有结果了, 但如何从这个结果看丢包率呢

[wangyu-]

client端的 “client-->server:(original......)(fec:xxx pkt:yyy byte)”，里面的xxx表示从client到server发送了xxx个数据包。 server端的 “client-->server:(original......)(fec:aaa pkt:bbb byte)”，里面的aaa表示server收到了client发来的aaa个数据包。

对比一下xxx和aaa，就可以算出client-->server方向的丢包率。 server-->client方向的数据同理。

==update 11.14== 之前说错了，已更正。应该看的是fec那一列的数据，不是original那一列。

[JBlazingSun]

懂了, 但感觉还是不够直观

[wangyu-]

那你就关掉FEC，直接PING吧。一般结果也是准确的，不能看到单向的丢包率，只能看到双向总的丢包率。