8670 是 4T4R 的，你需要一个 4T4R 的网卡才能达到最佳速度。

深圳电信，之前试过不行。用户名非 0755 开头

@wunonglin 游戏宽带应该内网 IP 是 100.127 开头，外网是 119.121 开头。119.121.24 是走 CN2 的，119.121.152 是走 163 的。

你是找电信要了公网 IP 吗，有公网 IP 就没有上面这些事了。

@wunonglin 访问 www.ipip.net 显示的 IP 是哪个段的

深圳访问本地 IDC 好像都是走 AS4816 直接到，不需要过广州。但非本地的数据是都要从广州转

说到点子上的人不多。除了 auta，外面的 s.len 没变，但是 s[4]的内容实际是有了，只是 length 仍然是 3.
具体可以看看 playground: https://play.golang.org/p/JjP8z4xQ1Qa

大的 BDP 会对网速提升有帮助。

不知道是不是我信息不灵通，深圳已经很久没有 CN2 的游戏宽带了

@wen10603654852 以前一直可以，翻过年以后就不行了。换深圳移动的测速点就能到 500 以上

越来越差，完全没有变好的迹象。深圳电信往广州电信的测速点现在都只能跑到 100 多 Mbps 了， 全是个城域网。我 500mbps 的网

建议使用 ipset，只知道效率很低，具体有多低不知道。基本上相当于 O(n)?

此举受影响比较大的应该是 IDC 吧

虽然楼主的图画的很帅，给的链接也不错。但还是成功的误导了我，我以为 NAS 通过两种方式下载文件会得到不同的结果。之前打了很长一段，又删了。也不想全部再敲一遍， 直接说结论吧：

这个问题很显然就是丢包率+长距离造成的 TCP 浪费。根据部分数学模型得到的模糊结构大概如下：TCP 的速率与延迟成反比，与丢包率的平方根成反比（因为丢包率总是小于 1，所以平方根会大于丢包率自身），当然，还有总带宽等其它因素。

你这个 Chrome 到代理的丢包率依然很高，但是由于距离短，可以跑到速度很快。比方说延迟<1ms 的情况下，丢包率 10%也是可以把带宽跑到差不多的，因为重传会很快。

而直连的情况下， 由于其中一段的丢包率在 10%，那整段路的丢包率实际上会超过 10%，然后再配合长距离传输，得到惨不忍睹的情况也非常正常。

TCP 对于当前的网络来说是一个低效但是公平的协议。

你从 NAS 上弄文件是 Web 下载的方式吗， 要不然是如何通过 Chrome 的

有客户端的情况下不要尝试播 HLS，直播的 HLS 延迟会让人想吐。没有客户端的情况下，考虑微信小程序中的 RTMP 播放能力

@kidcats 好吧，刚发现以上结论都是错误的，不太清楚为啥深圳连到广州的电信服务器测速上不去，换了个移动的测速点能测到 300M。7650 做的拨号。但奇怪的是接有线的情况下，相同的测速点是可以测到 300 的

300Mbps 的话，已经非常不错了。

@EvanQu 看来我可能买到了假的。不做 Mesh 的情况我也是跑不到百兆以上的
配合 6300 是怎么用的，7650 上再做一级 NAT 还是关掉 DHCP 和 WAN 功能，与 R6300 一个内网？

@kidcats 刚入 7650，我家 500M 宽带，wifi 下 speedtest 测速从来没超过 100，不管是在 2.4G 下还是在 5G 下。这个是正常的么？有线倒是可以测到 300M，但不及我的网件 R7000。准确的说是差的远。R7000 就是覆盖差了点，有个房间没信号。
无线 Mesh 的条件下，从另一个 7650 上连上网线测速，也不超 100Mbps，两个 7650 之间距离不超过 5 米，直线可视。

稳定性倒是还可以，日常使用几天也没遇到问题。

不是带独立 PA 和 LNA 的那种 Turbo 版