@wwhc Intel 最高端的 Xeon Platinum 8180 这种 $10000+ 的 CPU 最高也就是 48 条 PCIe 3.0。就算全部用来插网卡，想跑到 10 Tbps 恐怕也有点困难吧。如果要跑 10 几个槽位，又牵扯到 CPU 之间的数据交换，故障率也增加了，而且成本不见得就比直接买硬路由要低。

容灾的话，我不知道 x86 能不能做到在一个 CPU 或者主板坏了的情况下继续正常服务。CPU 热插拔这种似乎也没见有多少软路由支持。

如果是家用网络，那软路由的确是足够了。只要规模稍微大一点，谁敢用软路由啊...

原来工作的地方用的是 ASR 9006，供 40000 多人同时上网，跑 Full BGP，多条 10Gbps 光纤接入然后用 100Gbps 的线卡连接内网：

1. 内存大存储大没什么用。路由做为转发设备，把包用最快的速度发出去才是王道，buffer 太大只是在增加转发延迟，内存的用处主要也就是存一存有限的路由表信息，不是越大越好。而 ASR 的包 buffer 用的是 SDRAM，虽然比较小但是速度要比 x86 的 DRAM 快了太多。另外 ASR 的路由查询是通过 TCAM 这种专门的内存进行的，只需要一个时钟周期就可以搜寻完整个路由表，试问 x86 有什么算法能做到这种效率？这也是为什么硬路由可以轻松做到小包线速，而 x86 就很难的原因。
2. CPU 给力同理，专用转发硬件基本上都是 ASIC 处理的转发，追求 CPU 性能意义不大。
3. 硬路由支持各种高级的防灾措施，比如带电带流量更换线卡，路由卡，电源等等。而硬件也都有冗余，就算一张卡坏了，另一张会自动顶上，用户甚至都不会察觉。x86 如果 CPU 坏了或者主板、网卡坏了就只能哭了。
4. 硬路由总线带宽大，ASR 9006 这种比较低端的型号吞吐都已经 12 Tbps 了，x86 还没有发布的 PCI Express 5.0 x16 也只有 63GB/s 的带宽，差不多 0.5Tbps。而 ASR 9922 这种顶尖型号已经能达到了 160Tbps。对这种用户来说，x86 根本就无法考虑。

当然软路由也不是没有意义。如果对成本比较敏感，流量没有到一定规模，偶尔宕机可以接受，那是完全可以考虑的。

有 ASN 跟 IP 多少没关系，更多的是为了能够部署高级的路由策略。

若干年前（> 5 年）去过一次 Genius Bar，他们是把电脑连到了一根特殊的网线上，然后系统通过那根网线 Netboot 到了一个特殊的硬件检查镜像里。很久没去了不知道现在是怎么做的。

当然可以。就算不重置密码也可以，用户不会知情。

https://developers.google.com/admin-sdk/email-audit/

@dbow 正解。

1、3 是冲突的。

想要稳定，可以考虑买 Juniper SRX300 这种，两年不重启都没事。再外挂个 AP 当 Wifi 即可。

这都是人家 90 年代玩剩下的技术：

https://en.wikipedia.org/wiki/Hashcash

Oracle 也是这样，按核心收费。

ssl_certificate 不支持变量解析，因为是在 config 阶段就读取了证书文件，没有运行时的动态行为。

据我所知，目前开源的项目里能达到你要的效果的只有 OpenResty 的 [ssl_certificate_by_lua_block]( https://github.com/openresty/lua-nginx-module#ssl_certificate_by_lua_block)，可以做到同一个 server 根据 SNI server_name 使用不同的证书。

@ryd994 然而并不是，Google Apps 的管理员最起码是可以在用户不知情的情况下访问用户邮件数据的，详见：

https://developers.google.com/admin-sdk/email-audit/

不仅是你当前 Inbox 的内容，甚至已经删除的 Draft 和 Inbox 都可以下载得到，而且用户不会得到任何的通知。

当然了，如果只用 GDrive 而且只存加密数据那也无所谓了，最大风险也就是某天突然无法访问了。

IBM 表示这都是人家 Mainframe 60 年代玩剩下的东西。

@flyingfz 正解，这么简单的需求用 OpenResty 几行 Lua 代码就搞定了，可以在握手前就断开连接，也不会发送证书。

https://github.com/openresty/lua-nginx-module#ssl_certificate_by_lua_block
https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ssl.md#raw_client_addr

对的。IPv6 使用 SLAAC 才会启用 Privacy Extensions，而 SLAAC 只有在 /64 或者更大的 block 上才可以使用。如果小于 /64 则只能走 DHCPv6，这种情况下 Privacy Extensions 不会（也没有必要）启用。

@s82kd92l 别的不知道，JunOS 早都支持 IPv6 Router Advertisement Guard 和 DHCPv6 Snooping 了所以就算 IPv6 环境下也可以防范类似攻击。

上企业级三层交换，将所有客户端的端口设为 DHCP untrusted。这种攻击对于三层交换机处理起来都是小菜一碟。不仅会过滤而且还会记录具体哪个端口发的包的日志。

比如 Juniper 对此的文档介绍：
https://www.juniper.net/documentation/en_US/junos/topics/example/port-security-protect-from-rogue-dhcp-servers.html

打开看一眼就知道了，就是用汇编实现的：

https://golang.org/src/runtime/asm_amd64.s#L2174

不太正常，有没有开 -j 选项？

你这么做，人家 D 还是成功的达到目的了。