Cloudflare 突发全球网络故障,X、ChatGPT 等知名网站瘫痪,盘前股价受挫
本站点主域名走了 github pages,blog 备用子域名走了的 vercel 加速,cloudflare 部署过,后台管理页面看着太老旧,劝退了。本来还在安静的水稿子,博客圈的群里消息不断,这点一般是很安静的,打开瞅瞅,cf 挂了,好多博友的网站无法打开。
作为互联网的基础设施,故障持续这么长时间,不应该;股价没有大跌,是我想不到的。
本站点主域名走了 github pages,blog 备用子域名走了的 vercel 加速,cloudflare 部署过,后台管理页面看着太老旧,劝退了。本来还在安静的水稿子,博客圈的群里消息不断,这点一般是很安静的,打开瞅瞅,cf 挂了,好多博友的网站无法打开。
作为互联网的基础设施,故障持续这么长时间,不应该;股价没有大跌,是我想不到的。
今天早上七八点,家里的网络悄无声息地“罢工”了。部署在电脑上的对外服务精准地记录下了它掉线的时间点,一切都发生得毫无征兆。
组内现有通讯协议使用 steady_clock 作为时间戳,计算单个节点的耗时,某个特殊场景,用到了消息包自带的时间戳,自带的时间戳来自于其他机器,导致计算出来的耗时异常。
题话外:Gemini2.5 Pro 有希望彻底超越 GPT-4
隔段时间就会清理手机上的资料,相册、微信聊天记录都会备份到电脑,手机上仅保留部分需要的聊天记录。
以前都好好地,能轻松识别到手机和台式机在同一局域网内,直接备份聊天记录到电脑上,今天是各种失败。
紧接上文,今天继续聊聊局域网的 IP 地址。上次为了同步代码,服务器配置了代理,服务器和家里的台式机打通了网络,在一个局域网里面,代理程序部署在台式机上,服务器通过代理访问外网。同步代码很慢,扔那边就没管了,隔了半个月,到服务器验证代码,发现Git代码同步失败,网络错误,也没太过脑子,细看报错信息。
业务模型:后台服务借助 TCP 与集团的行情网关建立连接。每次连接时,需先行发送一个授权请求,随后持续发送心跳包以维持连接状态。 然而,某一天,收到了服务断开连接的告警信息。通过仔细排查日志后发现,后台服务一直在持续发送心跳包,但对方却毫无回应,可连接却始终未断开。
台式机硬件三连发,前文我们提到了固态硬盘 PCIE 转接器,老的固态哪里去了呢?当然没有浪费,有没有坏掉,拆下来安装到了新买的机械师创物者Mini-3765H上(一年前)。
新机器,硬件规格还是给力的,2.5G 双网口、PCIE4.0、WiFi6。
最近搬家了房间没有单独的路由器组网,机器都是走无线网络连接,华硕主板台式机的无线网卡性能不太行,也可能是路由器无线接入,局域网之间上传速度不行,导致机器之间的网速不太行。新购买 2.5G 网卡,安装到台式机上。
至此,主板的插槽用完了:显卡、无线网卡、2.5G 网卡、固态硬盘 PCIE 转接器。
行政通知,办公位变动,从原本的二楼,迁移到十五楼,普普通通的一次工位迁移