1. 网络基础知识回顾：TCP/IP协议栈与数据包传输
好，咱们正式开篇。很多人觉得TCP/IP是基础，早就烂熟于心。但说实话，每次排查丢包问题，最终根因往往就出在这些“基础”细节上。我个人习惯，不管多资深的工程师，每过半年都得回头翻翻协议栈——因为那些看似简单的封装与解封装过程，才是丢包的真正战场。
1.1 协议栈的分层结构
TCP/IP四层模型，从上到下依次是：应用层、传输层、网络层、网络接口层。每一层负责不同的任务，数据在发送端一层层向下“打包”，在接收端一层层向上“拆包”。
你想想看，数据从浏览器发出请求，到在远端服务器收到，中间经历了多少次“套娃”？我当年在数据中心调一个跨机房丢包问题，折腾了两天，最后发现是网络接口层的MTU设置不一致——数据包被强行分片，然后重组失败。所以，理解每一层的职责和交互，不是纸上谈兵。
| 层级 | 核心协议/技术 | 主要功能 | 丢包常见原因举例 |
|---|---|---|---|
| 应用层 | HTTP、DNS、FTP | 提供用户服务与数据表示 | 应用层超时、缓冲区不足 |
| 传输层 | TCP、UDP | 端到端可靠传输（或尽力而为） | TCP重传超时、窗口满、校验和错误 |
| 网络层 | IP、ICMP | 路由选择、寻址、分片 | TTL耗尽、路由黑洞、MTU不匹配 |
| 网络接口层 | 以太网、Wi-Fi | 物理寻址、帧封装、介质访问 | CRC错误、冲突、信号衰减 |
这个表格值得你存下来。我记得有次客户反馈游戏掉线严重，我们抓包发现大量TCP重传，但网络层路由完全正常。后来一查，是客户端的网卡驱动有bug，导致链路层FCS校验频繁失败——这就是传输层以上统统正常，但网络接口层在悄悄丢包。
1.2 数据包的“一生”：封装与解封装
数据包在协议栈里是怎么旅行的？我给你画个图，看完就明白。
这个图我画得比较简练。你注意看，发送端是逐步增加头部信息，接收端是逐步剥离。每一层都只关心自己的“信封”：传输层看端口，网络层看IP地址，网络接口层看MAC。之所以强调这个，是因为很多丢包场景，恰恰是某层“认错信封”导致的。
1.3 TCP vs UDP：可靠与不可靠的博弈
在传输层，两大主角就是TCP和UDP。它们的设计哲学完全不同，丢包表现也天差地别。
- TCP：面向连接，可靠传输。它用序列号、确认应答、超时重传、滑动窗口来保证数据完整到达。一旦丢包，TCP会主动重传，同时可能触发拥塞控制——也就是说，丢包会带来延迟放大效应。
- UDP：无连接，尽力而为。发出去就不管了，丢包全靠应用层自己处理。实时音视频常用UDP，因为宁可掉几帧也不愿等重传。
我见过一个典型案例：某在线教育平台直播卡顿，技术团队在TCP上疯狂优化，收效甚微。后来才发现，直播用的其实是UDP——他们一直在错误的那一层折腾。所以，排查丢包前，先确认你面对的是TCP还是UDP，这能省掉一半的弯路。
避坑指南：我曾经在分析一个“间歇性超时”问题时，一直盯着TCP重传统计。后来发现，应用层用了UDP socket但代码里写了重传逻辑，导致网络层丢包被应用层“静默重试”，而我的抓包工具只过滤了TCP——白瞎了两天。建议一开始就明确传输层协议，再选抓包过滤条件。
1.4 关键网络设备与丢包“原罪”
数据包在网络上会经过交换机、路由器、防火墙、负载均衡器等设备。每个设备都可能成为丢包的元凶。
| 设备 | 工作层级 | 常见丢包原因 | 我的真实踩坑 |
|---|---|---|---|
| 交换机 | 网络接口层（L2） | MAC表满、端口风暴抑制、CRC错误 | 某次核心交换机端口下联大量虚拟机，MAC表溢出，新流量被直接丢弃 |
| 路由器 | 网络层（L3） | 路由表不全、TTL超时、队列满、MTU问题 | 一个跨区域专线丢包，最后发现路由器上的ACL误封了ICMP，导致PMTUD失效 |
| 防火墙 | 网络层-应用层 | 会话表满、策略误拦、深度包检测超时 | 有一次线上服务连续丢包，查了一天发现防火墙的“会话老化时间”设置太短，长连接被强行中断后重新建连 |
| 负载均衡器 | 传输层-应用层 | 后端健康检查误判、连接队列满、SSL卸载错误 | 大促期间LB的并发连接数暴涨，连接队列溢出，部分请求直接被丢 |
特别注意：很多丢包不是“网络坏了”，而是设备按照设计规则“主动丢弃”。比如交换机的端口限速、路由器的QoS策略、防火墙的会话数上限——这些“合规丢弃”在排查时最难发现。我建议你排查前先收集所有网络设备的配置和日志，而不是直接怀疑链路质量。
1.5 从抓包视角看丢包
学会抓包，是理解协议栈丢包最直接的手段。我个人崇尚“抓包说话”——不要猜，看现场。
这里我给出一个最基础的tcpdump过滤示例，适用于初判阶段：
# 抓取目标端口80的TCP流量，不解析DNS，只保留头部
tcpdump -i eth0 -nn -s 0 -w capture.pcap host 10.0.0.1 and port 80这个命令的关键参数解释：
-i eth0：指定网卡，别搞错接口-nn：不把数字转成域名和端口名，免得DNS干扰-s 0：抓完整包，否则只抓头部，可能看不到应用层数据-w：写文件，方便后续用Wireshark分析
抓到的包怎么看出丢包？我教你三招：
- 看TCP重传：Wireshark里过滤
tcp.analysis.retransmission，出现即丢包。 - 看TCP重复ACK：过滤
tcp.analysis.duplicate_ack，接收端催你重传，也是丢包信号。 - 看ICMP不可达：过滤
icmp.type == 3，可能是路由、端口或协议不可达。
别忘了，抓包点要选对。我曾经在客户端抓包，看到一堆重传，以为是服务器或网络问题。后来到服务器端一抓，发现服务器早就发出响应了，是客户端到服务器中间的一段交换机在丢包。所以，有条件的话，在两端同时抓包，对比时间戳，定位才准。
1.6 检查清单：你清楚这些基础吗？
收尾前，我列几个自测题，帮你夯实这章内容：
- 你知道数据包从应用层到物理层，每层增加了多少字节的头部吗？（以太网帧头14字节，IP头20字节，TCP头20字节——最小情况）
- 你能说出TCP三次握手中，哪一步最容易丢包？（其实是SYN和SYN-ACK，如果服务器半连接队列满了，SYN可能被直接丢弃）
- 你明白为什么MTU不匹配会导致大量丢包吗？（IP分片后，只要一片丢失，整个报文都要重传）