从一次 curl 超时说起:DNS、TCP 与 TLS 到底谁慢了
一个 20 秒的 curl 超时,可能卡在 DNS、TCP 握手、TLS 协商,也可能是 IPv6 在悄悄拖后腿。这篇文章给你一套五分钟内定位链路瓶颈的方法。
4 分钟阅读↗
输入关键词开始搜索
试试「Docker」「RAG」「死锁」Computing · 08 POSTS
从 CPU 到网络,把系统运行的底层逻辑讲清楚。
一个 20 秒的 curl 超时,可能卡在 DNS、TCP 握手、TLS 协商,也可能是 IPv6 在悄悄拖后腿。这篇文章给你一套五分钟内定位链路瓶颈的方法。
CPU 100% 不一定是故障,load 很高也不一定是 CPU 不够。从 /proc/stat 到 cgroup 限流,拆开看内核到底在忙什么。
free 显示的剩余内存少,往往不是内存不够。把虚拟内存、页缓存、overcommit 和 OOM Killer 的选择逻辑拆开,才知道该加内存还是改参数。
容器里时间差 8 小时,多半不是时钟漂移,而是时区数据缺失。从 /etc/localtime 到 JVM 的时区缓存,逐层排查并给出可复现的修法。
rm 之后 df 还是满的,多半是进程还握着文件描述符。从 inode 引用计数讲到 df -i,把「删了没释放」的几种情况一次说清。
地址栏回车之后,浏览器做了十几件事。用 Navigation Timing 把 DNS、TLS、TTFB 和渲染拆开,白屏三秒才能定位到具体哪一段。
0.1 + 0.2 得到 0.30000000000000004,不是语言有 bug,而是二进制浮点的必然结果。讲清表示误差、舍入规则和金额的正确存法。
git cat-file -p HEAD 打印的到底是什么?从 blob、tree、commit 的字节结构讲起,手工造一个 commit,理解哈希链和引用。