此举受影响比较大的应该是 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 版

@ZRS 到货了不妨评测一下，想看看你的结果确认我有没有买到假的

@leafleave 图片搜索 ETC 门架，ETC 每过一次门架要扣一次费的

走 AS4134 明显不是 CN2，这个是广州办出来的吗。难道新版又改了

前不久才有人推荐过 iptables tutorial。下载下来看了全本，还不错。
至少来龙去脉弄清楚了

append 很多情况下是对对内存进行 malloc, memcpy, free。这些操作未完成之前是不会返回的。所以你会看到各种锁。在有锁的状态下，其它的 goroutine 实际上是在等待。

unknown 就是地址没解析成功导致的。直接 SOF 高分答案，写的很好。
https://stackoverflow.com/questions/8938689/unknown-mysql-server-host

别光用 echo 啊， 直接打错误原因。

```
try {
$dbh = new PDO($dsn, $user, $password);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e->getMessage();
}
```

要我说，创业公司只要挣钱就能不死， 不挣钱的后来都死掉了

很强大，文档也做的很好看。

视频网站的并发都是按 T 算的，一路码率为 4Mbps 的码流，传送过程中要占掉 4M 多，你这撑满了也就 10 个人看

正确的做法是 OSS+CDN，或者是找一级 CDN 给提供对应的服务，你光出钱就好了