网络问题排查的隐性知识
网络知识之所以难以传授，是因为它的核心不在于记住 TCP 三次握手的流程，而在于面对一个「网络不通」的问题时，你脑子里能快速构建出从应用层到物理层的完整排查路径。这种能力是经验驱动的，很难通过阅读文档获得。
我曾经花了两个小时帮一位同事排查一个诡异的超时问题，最终发现是 MTU 设置不当导致的 TCP 分片重组失败。这个问题的症状是「请求偶尔超时」，如果没有网络层的直觉，你可能会在应用层和框架层反复排查却一无所获。
TCP/IP 的实践理解
教科书上的 TCP/IP 和生产环境中的 TCP/IP 是两个东西。你需要理解的不只是协议规范，还有操作系统的实现细节：TIME_WAIT 状态为什么会导致端口耗尽、tcp_tw_reuse 参数的适用场景、Nagle 算法和延迟确认的交互为什么会导致 40ms 的额外延迟。
在容器化环境下，网络栈又多了一层复杂度。veth pair、网桥、iptables 规则、Service 的 kube-proxy 转发——每一层都可能成为问题的藏身之处。能够在这个复杂的网络栈中快速定位问题，是高级工程师的标志性技能之一。
DNS 的坑
如果要评选「看起来简单但实际坑最多」的网络组件，DNS 一定名列前茅。DNS 缓存导致的「已经改了解析但还是访问旧地址」是最常见的问题。但更隐蔽的坑包括：search domain 配置不当导致的域名解析膨胀、ndots 参数在 Kubernetes 中对解析性能的影响、以及 DNS over TCP 回退导致的延迟。
我们在 Kubernetes 集群中遇到过一个有趣的案例：Pod 内的 DNS 解析延迟异常高。排查后发现 CoreDNS 的连接数达到了上限，根因是某个服务在热循环中频繁做 DNS 查询而没有任何缓存。修复很简单，但找到根因的过程依赖对 DNS 解析链路的完整认知。
网络知识的学习路径
我的建议是从实践出发而非从理论出发。先学会使用 tcpdump、wireshark、ss、dig 这些工具，然后带着具体问题去理解协议。每排查一次网络问题，就把涉及的知识点串联起来，逐步构建出自己的网络认知地图。理论知识会在解决真实问题的过程中自然沉淀，而不是反过来。
相关文章