发的是40B的握手包, 是无法贴近宣传的"实际上网体验". loss检测看着比较合理, 但是延迟是理想化的 (当然可能这就是你想要的结果. 但这不是贴近"实际") 很多vps线路有小包优化, 实际接近MTU的包可能不一样 你的延迟 = 30个中成功的单发SYN取平均 (btw你备注写的60...), 实际上网TCP丢包了会重传, 结果就是那一下的延迟会变高(这也是大部分tcp探针会有尖刺,但是loss依然为0)
@nsgba #164 回应下老哥的几个问题 40B是nexttrace的tcp包默认值，虽然我没采用nexttrace（有频率限制），但借鉴成熟项目的默认参数应该没问题。所谓大小包优化，尤其是大家之前喷过的netlab，实际上并没有明确的证据。当然后续改成1200B去探测也没问题。 tcp理论上不存在丢包（有重传机制）但一旦没收到ACK，就会重新发送包建立TCP连接，这样你体验上就是tcp建立过程变慢了，网页/视频首次加载速度慢。（这个探测方式跟komari的tcp探针类似，但实现方式不同）。 而且我认为第2点是非常有必要的，例如昨晚v.ps sjc电信回程劣化，通过这样的方式就能探测出来。如果考虑tcp重传，只计算tcp建立连接失败的次数，那么v.ps目前还是良好的线路，这显然与用户的实际感受不同。实际上DMIT的LAX我提交了相关的检测结果，不会有误判的“毛刺”的。或者说，有“毛刺”本身就是线路不够稳定。 30/60是调整过一次，因为部分aws cpu性能较弱，后续会更新readme和使用说明。
@k2think #165 那就是我猜的的:这是你想要的方式 你的线路质量体现在丢包上,然后你通过关闭tcp内核重转来获得这个丢包率. --> 所以我说loss检测合理 如果考虑重转的话, 那线路质量主要是看rtt的jitter以及最大等(即毛刺). 本质上是两种不同的方式, 你选的是前者. 但对于实际体验来说(因为这是你提到的), 毛刺的最大值能直观反映到用户体验(比如一个1.2s的毛刺即反应用户可能某次打开页面需要1.2s). loss是无法体现的 (举个极端点的例子,假设每个tcp都会丢第一个包,且只丢第一个,那你的结果会显示loss100. 但实际用户体验是双倍延迟,没有断连) 还是那句话, 测试方式很多种, 没有好坏之分, 也没银弹
@nsgba #166 老哥的理解完全正确 确实特意设计成这样的 这个脚本的初衷就是为了检测“精品回程”线路的毛刺 实际上用speedtest的cli也会报告jitter，或者说毛刺。但重传往往随着速度的提升而增加，而这类测速工具往往会尽可能占满带宽。但用户实际上网中，占满带宽的情况非常少见。 我主观上感受，用户上网中受到“首次加载延迟”的体感，要比单线程能跑多少/多线程能跑多少更重要。而且后者可以通过调优的tcp参数（例如魔改版的bbr），或者直接暴力发包的udp协议改善。但tcp首次建立连接的速度是用户每打开一个网页都会遇到的。 更客观的讲，如果用户购买的是亚太的优化线路机器，那么即使有一两次重传，也只是从50ms跳到100ms，但如果是物美价廉的美西，那么就是从160ms跳到320ms（这里简单化问题，不包含VPS代理访问的延迟），这时用户的体感就非常明显了。这也是脚本重点关注的地方。 当然老哥提到的“用户体验是双倍延迟,没有断连”，这个点肯定是脚本探测方式的固有问题，但目前确实没有太好的方法去兼顾。我考虑后续将“丢包率”修改成“重传率”或许更不容易让用户误解。
CORONA，广东移动
非常好的项目，顶一下让更多人看到
@Archimides #161
感谢使用，corona还是很强啊，电信走9929好稳
发的是40B的握手包, 是无法贴近宣传的"实际上网体验".
loss检测看着比较合理, 但是延迟是理想化的 (当然可能这就是你想要的结果. 但这不是贴近"实际")
@nsgba #164
回应下老哥的几个问题
而且我认为第2点是非常有必要的，例如昨晚v.ps sjc电信回程劣化，通过这样的方式就能探测出来。如果考虑tcp重传，只计算tcp建立连接失败的次数，那么v.ps目前还是良好的线路，这显然与用户的实际感受不同。实际上DMIT的LAX我提交了相关的检测结果，不会有误判的“毛刺”的。或者说，有“毛刺”本身就是线路不够稳定。
30/60是调整过一次，因为部分aws cpu性能较弱，后续会更新readme和使用说明。
@k2think #165
那就是我猜的的:这是你想要的方式
你的线路质量体现在丢包上,然后你通过关闭tcp内核重转来获得这个丢包率. --> 所以我说loss检测合理
如果考虑重转的话, 那线路质量主要是看rtt的jitter以及最大等(即毛刺). 本质上是两种不同的方式, 你选的是前者. 但对于实际体验来说(因为这是你提到的), 毛刺的最大值能直观反映到用户体验(比如一个1.2s的毛刺即反应用户可能某次打开页面需要1.2s). loss是无法体现的 (举个极端点的例子,假设每个tcp都会丢第一个包,且只丢第一个,那你的结果会显示loss100. 但实际用户体验是双倍延迟,没有断连)
还是那句话, 测试方式很多种, 没有好坏之分, 也没银弹
@nsgba #166
老哥的理解完全正确 确实特意设计成这样的
这个脚本的初衷就是为了检测“精品回程”线路的毛刺
实际上用speedtest的cli也会报告jitter，或者说毛刺。但重传往往随着速度的提升而增加，而这类测速工具往往会尽可能占满带宽。但用户实际上网中，占满带宽的情况非常少见。
我主观上感受，用户上网中受到“首次加载延迟”的体感，要比单线程能跑多少/多线程能跑多少更重要。而且后者可以通过调优的tcp参数（例如魔改版的bbr），或者直接暴力发包的udp协议改善。但tcp首次建立连接的速度是用户每打开一个网页都会遇到的。
更客观的讲，如果用户购买的是亚太的优化线路机器，那么即使有一两次重传，也只是从50ms跳到100ms，但如果是物美价廉的美西，那么就是从160ms跳到320ms（这里简单化问题，不包含VPS代理访问的延迟），这时用户的体感就非常明显了。这也是脚本重点关注的地方。
当然老哥提到的“用户体验是双倍延迟,没有断连”，这个点肯定是脚本探测方式的固有问题，但目前确实没有太好的方法去兼顾。我考虑后续将“丢包率”修改成“重传率”或许更不容易让用户误解。
新版本支持回程路由探测，但目前处于前期开发阶段，有任何bug可以回帖或者私信
插眼
这么高质，顶一个