简体中文压缩数据只有6TB

Common Crawl中文数据提取出来了，做了去黄等处理，发现简体中文压缩数据只有6TB，解压后30TB左右，繁体压缩数据6TB。
中文数据到2019年冲到一个最大值，之后就回落了，不知道2020年具体发生了什么事情。。中文网页数据还是有点凋零。是不是有些网站不维护了？ ​​​

Tailscale 的 TLS 证书过期，网站挂了 90 分钟！ (qq.com)

尽管 Tailscale 因 TLS 证书过期导致了90分钟的服务中断，但这恰恰凸显了它的一大优势——多数用户几乎没有受到影响。Tailscale 的分布式架构使得用户端的连接不依赖于中心节点始终在线。这种弹性设计是 Tailscale 区别于传统 VPN 的关键所在。短暂的中心服务中断并不能否定 Tailscale 的价值，反而凸显了其良好的容错性。

事实上我也希望未来的智能家居能做成这样，不要云端宕机，家居也瘫痪。

如果你的 PPPoE 宽带访问部分因特网服务异常或缓慢 – V2EX

请检查 PPPoE 接口的 IPv6 TCP MSS adjust 是否正确。
对于 MTU 1492, IPv6 的 TCP MSS 应为 1432.

对于 RouterOS, PPP profile 中的 change-tcp-mss=yes 可能不会对 IPv6 正确生效。
对于 RouterOS, 可以使用如下命令对 IPv6 的 TCP MSS 做正确的 adjust.
/ipv6 firewall mangle add out-interface=pppoe-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1432 chain=forward tcp-mss=1433-65535

最好是在防火墙 mangle 表中对出网流量进行 MSS 钳制。这里作者提到，虽然邻居发现里面可以指定 MTU，但是会影响到内网设备（例如巨帧）。

RA 中宣告的 MTU 应当是 link / 三层口的 MTU, 而不是路由器所有接口 MTU 中最小的那个。直接向下联口宣告最保守的小 MTU 是对 IPv6 相关协议设计的错误理解和 RFC 的错误实现，不然如果我要用 ULA 地址跨三层访问内网 PMTU 9000 的 CIFS 存储，也用 1492 的 MTU 这显然不合理。

按 RFC, 针对中间路径 MTU 比源端小这个场景，应当依靠 PMTUD. 但是现网中大量对 RFC 的错误实现和比相关 RFC 更早出现的屎山，导致了 PMTUD 的可用性与可靠性问题。（其实这就是 ICMP 中 C 的用例之一，但是很多网络工程师乃至所谓架构师只看到了其中的 echo (ping)）

没有 IP 路由器高兴在数据面参与 TCP 的事情（ IPv6 路由器不参与 fragment 也是对这一“IP 路由尽可能纯粹化”的思想的推广和贯彻），TCP MSS adjust/clamp 的施加是作为 PMTUD 失效时的兜底，IPv4 尚有中间路由器帮忙 fragment 作为兜底，IPv6 的中间路由器就只能通过帮忙 adjust/clamp 照顾 TCP 了。

Automatically re-resolve DNS in Wireguard – Installing and Using OpenWrt / Network and Wireless Configuration – OpenWrt Forum
WireGuard 仅在启动时会解析 Peer Endpoint 域名，如果 IP 变化并且 DDNS 记录刷新后，已启动的接口不会自动刷新 IP 变化的 Peer Endpoint。在 Linux 上 wireguard-tools 提供了 reresolve-dns.sh 脚本来帮助解决这个问题，它会解析 DNS 并使用 wg 命令更新变化的 Endpoint。我们可以定时运行这个脚本，具体可以参考 WireGuard – ArchWiki (archlinux.org)。在 OpenWRT 上，则可以使用 /usr/bin/wireguard_watchdog 脚本，其检测不活动的 Peer 并进行刷新，具体参见 [OpenWrt Wiki] WireGuard extras。