Tianao

FortiGate 90G 或者 FortiGate 100F, 非常适合做多业务网关。

@solos #16 堆叠的可靠性和业务连续性能力不能满足数据中心需求是业界共识，就算不上全路由，vPC/M-LAG/MC-LAG + FHRP 也是基础，青云 2015 年因为 H3C 堆叠故障出过大事故。

@solos #14 青云……就是那个数据中心“汇聚层交换机”用堆叠的厂商。

看着成双成对的小情侣卿卿我我。

可以去中学门口的奶茶店，看着小情侣们，就回忆起自己的青春，当时候的我也是这样，

DisplayLink 和雷雳 4 扩展坞都不便宜，体验也未必有预期的那么好，不如再买个 C 口显示器。ThinkVision T 系列和 P 系列我都搭配过 MacBook, 连接性体验方面没有任何问题。

国内电话拨打 12308

如您的中国籍亲属在国外下落不 明，领事官员可以向您提供当地报警方式 及其他获取救助的渠道。所在国警方立案 的，可以敦促所在国警方及时妥善处理。
——中华人民共和国外交部领事保护中心《中国领事保护与协助指南》(2023 年 9 月)

性价比：肯德基 K 咖啡，咖啡包月卡 5 元/杯。

@CharonVIII #2 我测试下来，是 Windows 上的 nslookup 实现在通过 UDP 收到 Truncated 置位的应答、转而使用 TCP 并完成 TCP 的 3-way 握手后，会紧接着（也就是在这个 TCP 连接的第 4 个包）发送一个带有 PSH 置位的、仅有 2 bytes 的 TCP payload 的 TCP segment, 我不知道这个 2-byte 载荷的意义是什么（但猜测是用作一个什么出于性能或可用性目的的什么前导？），然后紧接着就收到了来自 223.5.5.5 的 TCP RST (我也不知道 223.5.5.5 为什么要 reset, 但是我猜测是 223.5.5.5 收到了这个不明所以的 TCP 分段，出于节省资源开销/防攻击的目的主动 reset 掉了这个 TCP 连接)，然而按照 Windows nslookup 的预期（这一「预期」我使用了其他使用 Windows nslookup 可以正常解析的 DNS 服务器进行了验证），这第 5 个包本应是来自服务端的正常 ACK, 然后 nslookup 再紧接着发送可以和第 4 个包进行 TCP segment reassemble 从而组成一个完整 DNS 请求的 TCP 分段，但是此时 TCP 连接已经被 223.5.5.5 给 reset 掉了。

目前的判断：Windows 的 nslookup 实现和 223.5.5.5 的某些策略性表现在 TCP 解析时存在兼容性问题。

目前的建议：在 Windows 上，在 PowerShell 中使用 Resolve-DnsName 能够获得比 nslookup 更接近 Windows DNS 客户端真实表现的测试结果。换言之，在 Windows 上，仅是 nslookup 失败不代表浏览器等真实用户访问行为调用的 DNS 解析也会失败。

「照理说 A 记录太多的网站肯定不止这一家...」
对于一般 web 服务的 GSLB, 国内一般都是地理+运营商分区解析，每个分区最终的 A/AAAA 记录真的远没这么多；对于国际化服务，虽然会使用 anycast, 但是 ADNS 会控制每次返回给 recursive DNS 的权威结果数量，也不会一次性返回好几十个 anycast 地址的 A 记录。