从一次网页打不开说起
早上上班，同事喊你帮忙看下为什么某个内部系统页面打不开。你打开浏览器刷新，转圈半天没反应。第一反应是网络问题？但Wi-Fi信号满格啊。这时候，懂点网络协议栈的人就会直接打开终端敲上ping命令，看是不是连IP层都通不过。
这其实就是网络协议栈在背后起作用。你想真正搞明白这类问题，不能只靠工具乱试，得有一条清晰的学习路径。
先搞清楚协议栈长什么样
别一上来就背TCP三次握手。先把整个协议栈的分层结构画出来：应用层、传输层、网络层、链路层。每一层负责什么，出问题会表现成啥样，心里要有数。
比如你在浏览器输入一个网址打不开，可能是DNS解析失败（应用层），也可能是TCP连接建立不了（传输层），或者是路由找不到目标IP（网络层）。不同的症状对应不同层级的问题。
动手抓包比死记硬背有用得多
装个Wireshark，或者用命令行tcpdump，抓一次访问百度的过程。你会看到一堆数据包来回飞，但关键是要能分辨出哪些是DNS查询，哪些是TCP握手，哪些是HTTP请求。
举个例子，你发现某个服务总是连接超时，抓包后看到只有SYN发出，没有收到SYN-ACK，那基本可以锁定是对方没响应或者中间网络拦截了。这时候再去查防火墙规则或者服务器状态，方向就对了。
tcpdump -i any host 192.168.1.100 and port 80 -nn这条命令抓指定主机和端口的流量，简单直接，适合定位具体问题。
理解封装与解封装过程
每个数据包都是层层打包的结果。应用层数据被传给TCP，加上TCP头；再交给IP层，加IP头；最后到以太网，再加MAC头。就像寄快递，一层套一层。
当接收方收到后，就一层层拆开。如果某一层格式不对，比如IP校验和错误，系统可能直接丢包不处理。你在抓包时看到“malformed packet”提示，就得往这个方向想。
从常见故障反推知识点
遇到DNS解析慢，就去学DNS协议细节，了解UDP和TCP什么时候用；遇到连接频繁断开，就去看TCP的RST和FIN机制；碰到跨网段不通，就得搞懂ARP和路由表怎么工作的。
有个运维曾经反馈说两台机器在同一局域网却ping不通。查了半天物理连接，最后发现是ARP缓存里映射错了MAC地址。这种问题，不了解链路层根本想不到。
写点小工具加深理解
用Python写个简单的TCP客户端，连一下远程服务，故意把端口写错，看看返回的RST包是什么样。或者用scapy构造一个自定义IP包，发出去观察结果。
from scapy.all import IP, TCP, sr1\n\npkt = IP(dst="192.168.1.1")/TCP(dport=80, flags="S")\nresponse = sr1(pkt, timeout=2)\nif response:\n print("Received:", response.summary())这种操作让你看到平时看不到的底层行为，比看书印象深多了。
结合操作系统看内核行为
Linux下/proc/net目录里能看到当前连接、路由表、ARP缓存。出问题时多看看netstat或ss输出，结合协议知识判断状态是否正常。
比如看到大量连接处于TIME_WAIT，不用慌，这是正常现象。但如果出现在客户端，可能说明程序没复用连接，资源浪费。
逐步构建自己的排查树
下次再遇到网络不通，脑子里自然跳出检查顺序：物理层→链路层（ARP）→网络层（ICMP、路由）→传输层（端口开放、防火墙）→应用层（服务是否启动、配置是否正确）。
每一步都有对应的命令验证：ping测通断，traceroute看路径，telnet或nc测端口，dig查DNS，一步步缩小范围。
这条路走熟了，别人还在重启路由器的时候，你已经定位到是运营商NAT会话表满了。