对 UDP 流量，伪装成 QUIC 会有效果吗…

用 Anycast 的 IP 上网，有点颠覆我的认知… 还是别这么做了吧

贵司 IT 老大和管 IT 的 VP 估计已经收拾好东西准备被开了…

难道前海的接入网不是运营商建的？三大需要租前海的接入网才能开宽带，类似日本运营商租 NTT 线路或者台湾运营商租中华电信线路那样？

深圳电信也有了。一条在南山的宽带已经割接到了 vbras 上，按照返回的名称来看，应该是华为的 VNE9000 。发送一个 PPPoE Discovery 包，会有四个 MAC 地址响应。一个快一点三个慢一点，顺序不确定。在罗湖和宝安的两条宽带看起来还没有变，依旧是 M6000 和 NE40E 。

看来大家都学会了低价中标，后续高价卖 License 和维护的套路了蛤蛤

@yulihao 同意。PON 上线前会测距的，根据距离调整发送延迟。而且上行时间片的精度很高，远不是 NTP 能达到的精度。因为 NTP 没同步导致 PON 上行时间片没对齐绝对是 SoC 的严重 bug ，根本不可能上市。感觉还是光猫里什么奇奇怪怪的应用程序影响了数据平面的转发，而不是时间片没对齐。

「坛友是运营商是什么体验」

@oblivion 在 TCP 里发大包还是有点麻烦的，要旁路掉内核的 MSS 控制和网卡的 TSO ，得魔改内核和应用层，没法过 CDN 。估计只能用在 IoT 或者推送之类的应用上。不过检测 MTU 只能检测出 L2/L3 的 VPN ，遇到 Shadowsocks 这样的 L4 代理就没办法了。

对于 ICMP 响应，看来他们的逻辑是越符合 RFC 越有问题。这倒是也有道理。运营商 CGN 、一般的 NAT 网关很可能不会响应 ICMP ，而很多 Linux 服务器不太会屏蔽掉 ICMP 。我感觉以后默认的 iptables 得屏蔽掉太大的 ICMP Echo Request 。

@bibiisme 这不就是我说的在自己的盒子里做非标行为嘛。没看到具体的协议细节，但是看之前的描述，这个绝无进 RFC 的可能。也就 CTC 之类的大运营商能在设备商和客户两边强推。

现在的 IPoE 没有用户名 /密码之类的信息，仅靠物理设备的位置进行认证。这要求整个接入网络的管理要求非常严格准确，风险很大的。哪怕是 PON ，也会出现安装的时候实际可用的资源和系统记录的资源对不上这种情况，更别说以太网入户那种了。PPPoE 在接入时有用户名密码校验，位置和系统记录不匹配会被发现，IPoE 可能就没机会了。在中国这个对“落地查人”要求很高的场合，大量出现此类问题是不可接受的。这种情况下，运营商只能在自己的盒子里做非标行为来加强控制，不仅给后期维护带来了麻烦，用户的选择权也自然受到限制。
回过头看看历史，PON 上运营商很多都选择了与物理设备无关的 LOID 认证，机卡和一的手机最终还是被淘汰了。早期的小区宽带都是 IPoE 的，最后也转向了 PPPoE 。
所以我认为，IPoE 需要提供一种标准化的，与物理设备和位置无关的，包含用户标识和保密认证信息的认证方式，要不迟早被运营商玩坏。

@Siril 我倒是觉得基于延迟判断非常靠谱。延迟最低极限的，而旁路劫持的 RTT 一般很低，通过不断采样 RTT，发现 RTT 急剧减小基本就可以判定是出现劫持了。不过这样要写程序追踪每一个 tcp 流了……

曾经遇到过 ISP 劫持无响应的 http 链接（ nb 吧），后来抓包看，本机向一个不在线的 IP 连发 5 个 SYN 之后，居然有 ACK 回过来！！然后就被劫持了……

@fromdaytonight 教育网重大节点终于不是摆设了( _)

劫持的问题，我抓包找到了证据，写了个文档发给电信，扯了几天皮之后就再也没出现了。
当然，深圳电信一直没有正面回应过这个问题。

单IP限上行即可。下行没必要限，基本跑不满的。