你有没有遇到过这种情况：路由器明明信号满格，网页却半天打不开；或者用iperf测速跑不满带宽，一查发现丢包率忽高忽低？别急着换设备，先低头看看数据是怎么一层层“爬”过网络的——协议栈不是黑盒子，它是有骨架的。
五层还是七层？先看实际干活的是哪几层
教科书爱讲OSI七层模型，但真正在Linux或家用路由器里跑的，基本是TCP/IP四层（或五层）精简版：链路层、网络层、传输层、应用层，中间加个可选的会话/表示层（日常调优几乎不碰）。我们盯紧前四层就行。
举个刷抖音的例子：
你点开一个视频，手机先通过Wi-Fi把请求打包成帧（链路层），贴上MAC地址发给路由器；路由器拆开帧，看IP地址决定往哪儿转（网络层）；目标服务器收到后，靠端口号找到对应App（传输层）；最后App把字节流还原成画面和声音（应用层）。每层只管自己那一摊，出问题也得一层层扒。
路由调优，关键在第二层和第三层之间
很多人一调优就猛改QoS、开硬件加速、调MTU，结果越调越卡。其实瓶颈常卡在链路层和网络层的衔接处。比如：
- Wi-Fi 6路由器连着千兆光猫，但网线用的是超五类（Cat5e），理论最大吞吐只有1Gbps，且抗干扰弱——链路层物理介质拖了后腿；
- 家庭组网习惯全用192.168.1.x网段，结果IoT设备一多，ARP请求泛滥，路由器CPU狂飙——这是链路层广播风暴撞上了网络层地址解析；
- 某些国产路由器默认禁用ICMP重定向，导致跨子网访问时走次优路径，明明该直连却绕一圈——网络层转发策略没对齐实际拓扑。
动手查一查：你的协议栈正在怎么干活
Linux系统（包括OpenWrt类路由器）可以直接看内核协议栈状态：
cat /proc/net/dev # 查看各接口收发帧统计，突增的drop或error说明链路层可能出问题ip route show # 看当前路由表，注意是否有重复、黑洞或metric值异常的条目ss -s # 快速统计socket连接数，如果established少但time-wait巨多，可能是传输层TIME_WAIT堆积影响新连接Windows用户可以用 netsh interface ipv4 show subinterfaces 查MTU和接收发送缓冲区，很多“网页加载慢”其实是MTU设大了，分片失败又不重传，卡在网络层。
几个接地气的调优动作
1. 链路层别省线：千兆以上带宽，网线至少Cat6，长度别超50米；Wi-Fi环境下，2.4GHz信道尽量避开邻居的同频干扰（用Wi-Fi分析仪APP扫一眼就知道）。
2. 网络层别堆NAT：家里有光猫+主路由+子路由？关掉光猫的路由功能，让它纯桥接——多一层NAT就多一次IP头解析和校验，延迟肉眼可见。
3. 传输层留点余量：游戏或远程桌面卡顿时，在路由器后台把TCP窗口缩放（Window Scaling）打开，并适当调高接收缓冲区（如从128KB提到256KB），尤其对高延迟链路（比如跨国访问）效果明显。
协议栈不是玄学，它像一栋老式居民楼：水管（链路）、楼层号（IP）、门牌号（端口）、住户（应用），哪一级标错了，快递就送不到。调路由，本质就是让每一层都认得清、转得顺、不堵车。