@evanchicken 没有变更终端设备

@evanchicken 我原来是 169 的，改成了 229 ，叠加-60 的优惠

如果我对连接池的理解没有错的话，我觉得传统的 pool 模式连接池之于 single 模式（大体上类似于 http2 那种利用的形式，或者说 pipeline ？），类似于线程池之于协程，这两样事物的思想上有共通之处。单独地谈线程与协程的关系没有太大意义，因为协程某种意义是作为一种通用的形式出现，来解决线程池所存在的问题的。协程的某些实现也不是脱离线程池存在的，它更多的是改变了线程池里的工作线程的底层逻辑。

池模式是用来解决资源分配问题的。首先就是资源有限，不管连接（毕竟由内核管理）也好，线程（和 CPU 核心挂钩，一般计算密集的会和某个核心进行绑定）。而这个资源受限不仅体现在内存占用上，还体现在创建和销毁以及切换和使用上，换言之，如果连接（特别是短连接，会引发 TIMEWAIT 之类的问题）以及线程的创建和销毁代价都和复用一样，那连接池和线程池就不会有存在的意义了，因为我可以无限地开连接和线程，无需额外管理，一切都交给系统来完成就行，但实际上这样做的负面代价较高
第二个问题则是，资源的独占。
我所理解的连接池，当某个线程使用了传统的 socket ，这个 socket 在得到对端的返回之前便是独占的，独占意味着这条连接不会在返回结果之前回归连接池。
类比一下线程池里的线程，线程池的一个经典使用模式就是消费阻塞队列里的任务，当一个线程在消费队列里的任务时，其它任务是无法抢夺这个线程的使用权的，对于计算密集的任务而言，这其实没有什么不好的，但对于 IO 密集的任务而言，事实上线程在等待 IO 返回的时候处于闲置的状态，这一段闲置状态由于没能主动释放资源，其它任务也得不到消费，产生了资源浪费。这时候我们一个可能的做法是对于 IO 密集类的任务开一个大一些的线程池，由操作系统来切换处于阻塞状态的线程。
所以，对于连接池来说，使用 singel 模式进行替代，使得一条连接可以被多个调用者直接复用，连接除了少数状态之外都处于共享可用的状态，调用者不需要因为连接池无可用连接而被阻塞，或者是去开一个临时的短连接。调用者在等待对端回复消息的同时，其它的连接也可以向这条连接写入消息，并等待对应的回复报文。
对于协程而言，其消费的对象并没有发生本质的改变，改变的只是线程的逻辑。在这里，协程的概念更类似于其消费的对象（或称之为任务）的一个完整生命周期，一个协程可以由 A 线程处理，也可以由 B 线程处理，也可以先由 A 线程再由 B 线程处理，即协程不与线程绑定（某些实现是这么做的，但也有实现是与线程绑定的）。
一个协程在遇到 IO 等待的时候，会主动让出线程的使用，把自己塞入等待队列（或者由继任者将其塞入等待队列，或者无继任者时由默认逻辑的空转逻辑将其塞入等待队列），直到 IO 等待结束（可能是定时器超时，或者得到了对端的返回），由对应的对象将等待队列的协程中加入到就绪队列中等待业务线程的调度。总而言之，就是线程的业务逻辑在操作协程，只不过通常的线程池业务逻辑是直接消费任务，而这里的线程是在处理协程的流转。
因为协程有状态，有上下文，所以某些实现方法就将这一上下文存放在栈空间上，通过切换堆上的存放的栈空间来实现协程任务的切换（比如说恢复寄存器变量来实现这一目的）。
通常协程框架的实现方法我见过两种，一种是真的去 hoook socket 族的函数了，于是你调用 C socket 族函数时，实际上调用的是被 hook 的函数。另一种是实现了一套完整的生态，对 socket 、锁、定时器之类的逻辑做了封装，如果要正确地使用这一种框架，就必须使用这些封装后的类库，而不是原生的系统调用。
以上关于协程的解释只是其中一种实现方法，不同的库可能有不同的实现。

golang 的一个优点其实是它的协程不像某些协程框架那样，是主动切换的。它有类似于时间片的概率，会在协程时间片到期后切换协程，从而更具实时性。另外它实现了一个通用的阻塞队列，也就是 channel ，当然 channel 的灵活程度是比阻塞队列要高一些的。因为它解决了这两个问题，所以使用一些多线程的业务的使用门槛变得低了很多。

是的，持续大半个月以上了，丢包丢到不太能用的水平

广州电信前几天打电话推销了
合同 229 一个月，老用户叠加-60 优惠，合同标记的宽带是 300M ，实际开的端口是 1000 下 /100 上宽带，比我想的好一些

dnsmasq-china-list 里指定的 server 为正常的 DNS 上游，而 dnsmasq 的全局默认上游指定为优先解析 v4 地址的 DNS 地址
能实现后者的比如 v6dns （一个 nodejs 项目，但其实用起来有时候会出点问题）以及 dnsforwarder

未指明的行为（ unspecified behavior ）——程序的行为随实现而变动，且遵从标准的实现不需要为每个行为的效果提供文档。例如求值顺序，等同的字符串字面量是否为不同的对象，数组分配的开销，等等。每个未指明行为均产生合法结果集合中的一个结果。
https://zh.cppreference.com/w/cpp/language/eval_order

@joshu 两个 MAN 的自治域大概都是在这个月 13 号（根据我自己的 ping 监测大概可能是在 23 号左右）缩减的

举个广州的例子。之前有段时间（大概半年以上），广州的游戏宽带，拨出来的地址（游戏宽带对应出口地址）都是由 AS134773 公告出去的，后果就是 IIJ 回程的时候是插的上海联通，NTT 回程则是正常地走 HK NTT
然后我观察了一段时间的 kagoya ，它直接 peer 了 NTT ，它还 peer 了 AS17511 和 AS2519 ，这两个 AS peer 了 IIJ
于是我测试了一下游戏宽带的出口 IP 的 /24 网段里的回程路由，发现在同一时段内，大体上是随机走的（大概就像奇数走 NTT ，偶数经 AS2519 走 IIJ 这种感觉）
同样的观察去程路由的话，多次拨号出来的去程也是不太一样的，有的直接走 59.43 ，有的只走 202.97 ，有些则是绕 202 之后走 59 。多数情况下绕 202 的话质量就不会太好。和最近的阿里云 HK 网络质量有些变差感觉有些关系
最后则是，我观察了下 AS136200 （佛山的城域网），最近公告出去的网段比之前大量减少，应该是有些网段回归 AS4134 公告出去了，我不知道这是否有联系。至少之前广州 163 和 CN2 宽带网段都是 AS134773 城域网公告出去的，最近都回归了 AS4134 和 AS4809 ，有些国际路由有劣化但另外一些也有优化。

话说有哪家日系机器稳定走 ntt 线路物吗，而且不绕新加坡的？

@kandm kagoya 是回程 ntt 和 iij 反复跳。。。不像 sakura 那样就只走 iij

@AlphaTauriHonda 但到 4134 可以绕美国的，有时候低但不是一直低

@bclerdx 准确来说是到广州电信的时候，入口是上海联通->北京联通?->电信

@joshu 日本节点到国内经 SK*

可以了，至少日本节点到 SK 还是比较稳的，除了上限好像突破不了 130Mbps 之外，可惜了 aws 那几百兆的外网宽带
你看看 IIJ 绕上海联通恶心你

不建议在 ubnt 上维护区分国内国外 IP 的 ipset，因为很麻烦，而且不够准确，我现在的做法是固定的 ipset+域名动态添加到 ipset，这件事比较适合弄个软路由来完成

@Chingim 预算够拉两条(

@locoz
@linxijun
我理解深圳游戏宽带已经不走 cn2 了吧
广州是走的我知道而且我正在用

@helllkz 那深圳这会应该也没有在一般人可接受价格范围内的 cn2 线路了吧