很多做开发的同事一听到 TCP 就下意识觉得“这是个可靠协议”，仿佛只要用了 TCP，数据就一定能毫发无损地从 A 端到达 B 端。我刚转岗到网络组那阵子也这么想，直到有一天在现网抓包时被老工程师问了一句：“你把这个 TCP 包发出去，到了路由器上，路由器真的会转发它吗？” 我才意识到，传输层的可靠性从来都是“有条件”的——这个条件，恰恰是网络层的可达性。
TCP 之所以被当成可靠协议，无非是序号、确认号、重传、滑动窗口、拥塞控制这一整套机制在撑场面。但这些机制的设计前提是：IP 层能找到一个路径，把数据包送到目的主机。如果 IP 层到不了，TCP 哪怕把确认、重传、窗口玩出花来，也无济于事。这就是标题里那句话的由来——“可达”方能“可靠”。无论你是写业务代码的开发，还是负责保障链路的运维，搞懂网络层怎么影响 TCP，都是职业基本功。
这篇文章不打算把协议规范抄一遍，而是想结合我自己在现网里踩过的坑，把网络层在 TCP 通信里扮演的“基石”角色讲透：网络层怎么寻址、怎么路由、怎么分片，以及当它掉链子的时候，TCP 的“可靠”如何被层层架空。
1. 先搞清楚一件事：TCP的“可靠”到底建立在什么之上
1.1 责任边界：IP只管“送到”，TCP才管“无损地送到”
IP 协议在设计上非常“实在”：它只负责尽力转发，不保证不丢失、不保证有序、不保证不重复。路由器发现没有路由、TTL 超时、缓存满了，直接丢包，连个“对不起”都不一定给你——最多通过 ICMP 回个错误报文，而 ICMP 报文本身也可能丢（我在 4.2 还会讲这种“哑巴网络”有多恶心）。正是这种“不承诺”的设计，才让 IP 网络能在全球范围内自由扩展，因为中间节点只需要做最少的决策，不需要维护任何端到端状态。
TCP 的可靠性，说明白了就是几个机制的配合：序号标识字节顺序，确认号通知对端“我收到哪了”，重传补发丢失的数据，滑动窗口控制发送速率，拥塞控制根据网络状況动态调整发送量。这些机制全部是“端到端”的，即它们只在通信的两个端点之间生效。中间的路由器和交换机既不关心 TCP 序号，也不参与 TCP 重传决策，它们只认 IP 头和以太网帧头。所以 TCP 的可靠是一个“闭环”，但这个闭环的底层，是 IP 网络“逐跳接力”的通路。
打个比方，TCP 是快递公司总部，IP 是公路运输系统。总部能追踪每个包裹、丢了就补发、乱了就排序，但前提是公路上有路可走，货车真能把包裹从一个城市拉到另一个城市。如果桥断了路塌了，总部再能追踪重发也没用，包裹根本出不了城。
如果网络层本身是稳定可达的，TCP 会表现得非常“可靠”，你几乎感觉不到它的存在；可一旦网络层出现分段丢包、路由黑洞、MTU 分片丢失这类问题，TCP 的可靠机制就会显得特别无力——它只能一遍遍地重试，却不知道重试也不会有结果。这就是为什么专业排障第一步永远不是看应用日志，而是先把传输路径上的“可达性”验证清楚。
1.2 “不可靠”的 IP，凭什么敢当底层基座
有人可能会问：既然 IP 这么不靠谱，为什么偏偏是它做了整个互联网的基座？答案恰恰在于它的“不靠承诺”换来了“极简可扩展”。中间节点不需要记录每个 TCP 连接的状态，不需要缓存整个会话，只需要根据路由表做一跳一跳的转发。这种无状态设计让路由器堆叠成全世界最大的分布式转发系统，也让 TCP 的可靠机制可以在端到端之间独立演进。
但也正因为 IP 无状态，TCP 实际上是在一个“什么都不能保证”的底层之上自己造了一套可靠性。于是问题就来了：IP 层任何一点细微的不稳定，都会被 TCP 的“可靠性机制”以重传、超时、窗口缩小的形式放大。TCP 很努力地工作，但努力的方向是“补偿”，而不是“修复”。
所以研究网络层，研究的不是“可靠性”，而是“可达性”——路径存不存在、路由转不转发、分片能不能拼回去、拥塞会不会把报文憋死。这几件事做不好，TCP 的可靠性就只是纸面文章。
2. 寻址与路由——从“找到主机”到“找到路径”
2.1 IP地址、MAC地址和端口：三个人各管一摊
这里先澄清一个经典混淆：网络层要解决“数据包去哪”，靠的是 IP 地址；但真正在一条链路上把帧从一个接口搬到下一个接口的，是数据链路层的 MAC 地址。IP 地址是“逻辑目标地址”，MAC 地址是“下一跳物理接口的地址”——就像你寄快递写的是“某市某街道某号”，但每个快递站点实际要看的，可能是离它最近的一个中转仓的进港编号。
TCP 则在 IP 之上增加了“端口”维度。IP 解决的是“到哪台主机”，端口解决的是“给这台主机上的哪个进程”。三层配合下来才是一句完整的话：数据要送到 IP 为 10.1.20.5 的主机，交给上层 443 端口对应的服务。
很多人排障抓瞎，就是因为把这三个层次混在一起来看：明明 ARP 在数据链路层解析不到 MAC，却说 TCP 握手失败；明明端口没监听，却怀疑是 IP 路由不通。问题到底出在哪一层，影响的是完全不同的排查路径。
2.2 路由表的本质：每个路由器只做“下一跳决策”
路由器不需要知道从源到目的的全部路径，它只需要查自己的路由表，决定“下一步往哪个接口扔”。路由表由直连路由、静态路由和动态路由协议（比如 OSPF、BGP）共同构建，每一条路由的本质是“前缀 + 下一跳 + 出接口”的映射。正因为这种逐跳决策机制，网络层才能在没有全局知识的前提下，把报文一级一级转发出去。
不过“逐跳决策”也带来一个隐患：某一个中间节点如果路由配置错误，或者路由协议收敛不到位，报文可能被扔进一个再也出不来的方向，形成路由黑洞。TCP 发送方完全感知不到黑洞的存在——它只知道“数据发出去了，等确认”，等不到就一直重传，直到重传超时上限触发连接重置。
实际运维中，我最怕的不是“路由完全丢了”，而是“路由静默出错”：比如某台核心设备上被人加了一条更精确的路由，把本来要去对端网段的流量引到了一个黑洞接口。这种问题链路状态看不出异常，设备 CPU 也不高，但 TCP 连接就是建立不起来，或者建起来了数据不动。
2.3 TTL超时：可到达路径上的“里程表”
IP 头里有个 TTL 字段，每经过一个路由器减 1，减到 0 就丢弃，并向源地址回一个 ICMP Time Exceeded。为什么要设计这个字段？因为如果路由表出现环路，报文就会在两个路由器之间无限兜圈，最终把链路带宽耗尽。TTL 相当于给报文设了一个“最多只能跳多少步”的里程表，超了就直接报废。
实战里 TTL 有两个用途：一是 traceroute 工具通过逐包递增 TTL 把路径上的每一跳都摸出来，二是快速判断网络故障的“远近”。比如下面这个命令，可以很快看到源到目的经过了哪些跳：
traceroute -n 10.1.20.5我曾经遇到一个场景，某跨机房的 TCP 长连接经常掉线。ping 网关的 TTL 稳定为 64，ping 对端却始终是 60。表面看只是差 4 跳，但中间每一跳都是潜在的丢包点。把 traceroute 跑出来后，果然有一跳正好是两家机房互联的边界设备，响应时间忽高忽低。这种“看着能通，实际不稳”的情况，最需要用 TTL 跳数和每跳时延来定位是长距离链路的末端问题。
3. 分片与重组：数据在途中的“物理考验”
3.1 MTU是路宽，分片是拆货
网络接口所能承载的最大数据帧长度叫 MTU，以太网最常见的值是 1500 字节。IP 报文如果在某个中间链路长度超过这条链路的 MTU，IP 层就会把报文拆成多个分片，每个分片都带自己的 IP 头，以便在目标主机上重组。这个概念跟“大件货物过不了限高，只好拆成几箱，到了目的地再拼起来”是一个道理。
分片在 IP 层是透明完成的，但 TCP 非常讨厌它。因为每个分片都要独立转发，只要丢了一个分片，整个原始报文在目标主机上就重组不出来，TCP 只能把整个报文段视为丢失并触发重传。结果就是：别人只丢一个分片，你却要把一整块大报文再发一遍，效率成倍下降。更糟的是，某些带安全检测功能的中间网关，出于性能考虑会直接丢弃非首分片，导致 TCP 连接在特定大小的报文上反复失败，而且失败得很“随机”。
所以在设计传输路径时，尽量让 TCP 报文段小于路径最小 MTU，是比任何调优参数都更基础的一条原则。
3.2 实际场景里的MTU不一致：怎么排查
有一次我在某个电商项目的现网排查问题：应用层反馈，上传文件超过一定大小就失败，小文件一切正常。初看像应用层超时，抓包却发现 TCP 一直处于一个非常诡异的状态——发送方发出大包，对端不回 ACK，发送方重传，还是没响应。后来抓到 ICMP Fragmentation Needed 报文才发现，中间某个设备的 MTU 设成了 1400，而发送端还在按 1500 的 MTU 发送，大包过不去，又得不到正确的 ICMP 提示（因为那个 ICMP 被中间设备过滤掉了），于是报文只能反复“沉默”，TCP 超时重传连环发。
排查这类问题有一个非常实用的手法：用 ping 带不同 payload 大小去测，逐步确认能通过的最大包长。Linux 下可以用-s指定 payload，用-M do禁止分片，这样才能准确验证“扣掉各种头之后，整包能不能通过”：
# ICMP payload 1472 + IP头20 + ICMP头8 = 1500字节，正好压线 ping -s 1472 -M do 10.1.20.5 # 如果1500整包失败，再把payload降到1372，对应1400字节总长 ping -s 1372 -M do 10.1.20.5 # 多测几档，就能判断中间链路的MTU到底卡在哪个值 ping -s 1272 -M do 10.1.20.5注意这里的计算：ping 的-s是 ICMP 的 payload 大小，实际网络包长还要加上 20 字节 IP 头和 8 字节 ICMP 头。如果 1472 通、再往上加就不通，说明路径 MTU 大概率就是 1500 且分片受限；如果 1372 通而 1472 不通，说明中间有链路 MTU 在 1400 左右。靠这招，我至少在三四个项目里快速锁定了 MTU 问题。
3.3 MSS、PMTUD与TCP的自我保护
TCP 为了尽量避开 IP 分片，在握手时就会通过 MSS（最大报文段长度）协商“我这边能接受的 TCP 数据区大小”，通常取本端 MTU 减去 40 字节（20 字节 IP 头 + 20 字节 TCP 头），所以最常见的 MSS 是 1460。
但 MSS 协商只能解决“两端接口 MTU 已知”的情况，解决不了中间链路 MTU 更小的隐性瓶颈。这时候就需要 PMTUD（路径 MTU 发现）机制：发送端把 IP 包的 DF（Don't Fragment）位置 1，中间路由器发现包太大时，会回一个 ICMP Fragmentation Needed 报文，发送端据此减小报文长度。可惜这个 ICMP 经常被安全策略过滤，导致 PMTUD 失灵。因此现代 TCP 栈开始采用基于包探测的 PLPMTUD，用真实发包代替对 ICMP 的依赖——这也是为什么网络层和传输层的边界，在实际工程里并没有协议规范画得那么泾渭分明。
4. 当网络层故障时，TCP的可靠性如何被架空
4.1 队列溢出与拥塞陷阱
数据和确认报文在链路上往返时，如果网络层出现缓存占满、队列溢出，报文会被直接丢弃。TCP 拥塞控制发现“确认迟迟不来”，会缩小拥塞窗口，降低发送速率。这本是好事，但网络层如果持续处于“高水位”状态——比如某台核心交换机的单端口缓冲始终打满——TCP 就会反复进入拥塞避免状态，吞吐率上不去。
这会带来一个很反直觉的现象：TCP 几乎没有报错，重传也很少，连接一直在，但业务吞吐就是上不去。很多人盯着应用层看，以为代码有性能问题，其实“线”早就在网络层的出口队列里堵死了。TCP 在这里扮演的不是“报信人”，反而是“缓冲垫”——它把所有网络抖动都转化成了延迟和吞吐下降，表面上看起来一切正常。
要识别这种问题，光看 TCP 层统计是不够的，必须盯住网络设备的接口丢弃计数（比如 dis card）、队列深度和端口利用率。很多时候，转发面的丢弃计数一对比，问题就浮出水面了。
4.2 路由黑洞：重传多少次都没用
比丢包更棘手的是黑洞。丢包至少意味着“报文可能还有机会被送达”，而黑洞往往是特定路由前缀被错误宣告，或者某台设备的路由表里根本没有回程路由，报文发出去就再无音讯。
我见过一个跨机房案例：应用端 TCP 连接能建立，握手包能通，但数据包一进特定网段就全部消失，发送方疯狂重传，接收方却一无所获。抓包后发现一个耐人寻味的细节：TCP 三次握手中的 ACK 是通的，但随后的数据段没有回包——因为路径上某设备只配了到对端网段的“去程”路由，没配“回程”，报文从源到目的可以走，从目的回源就找不到路了。确认报文发不出去，TCP 的重传机制自然兜不住这种“半程可达”的故障。
这类问题的定位手法是双向抓包和路径方向对比：分别在源端、目的端抓流量，看报文的去向和回向是否一致，再用 traceroute 对比去程和回程路径。一旦发现“去通回不通”，多半就锁定了缺少回程路由或路由被错误汇总的节点。不要被 TCP 层的重传数量迷惑，重传只是表象，路径不对称才是内核。
4.3 路径收敛与传输层的“感知延迟”
还有一种情况是网络层路径发生了切换，比如动态路由协议收敛，数据短暂中断，随后又自动恢复。TCP 在短暂中断期间不一定能立即发现异常，直到确认超时或收到重复 ACK 才会触发重传。如果链路切换频繁，TCP 就会不断经历超时重传、快速重传，表现为主机之间短暂“卡顿”和大量重传。
这种间歇性故障最难排查，因为故障窗口往往只有几秒甚至几百毫秒，等你赶到现场抓包，它已经恢复正常了。应对办法是把监控粒度做到“历史可回溯”：不仅记录平均时延，还要记录每跳 RTT 的分布、每分钟的丢包率、路由协议的收敛事件，甚至保存抓包文件样本。没有历史数据，这类网络层抖动就只能靠运气撞了。
5. 一个真实排查案例：应用层卡顿背后，是网络层在“说谎”
5.1 现象：TCP重传正常，业务却大量超时
有一个项目持续了将近一周的诡异现象：两个机房之间跑的是长连接数据同步，应用层日志里大量出现 read timeout，但 TCP 层统计显示重传率并不高。更奇怪的是，ping 对端 IP 可以通，延迟稳定在 3ms 左右。按常规思路，网络应该没问题。
但业务确实在超时，而且只出现在数据量大的时段。我把 Linux 的 TCP 状态看了一遍，发现重传数量不多，但发送缓冲区一直很高，Send-Q 高企不下，也就是数据一直在堆积，对端应用读取缓慢。乍一看是应用层消费能力的问题，可为什么数据量一大就消费不过来？这让我把视线转向“数据是不是根本没到对端应用”这一层。
5.2 排查链路：从ping、traceroute到抓包定位
我先在源端持续发 ping，把 ICMP 报文大小从 64 字节一路加到 1400 字节。64 字节一直通，1400 字节开始出现偶发丢包。这个现象本身就很有指向性：小包没事，大包丢，最常见的原因就是中间某段链路对大数据包处理不过来，或者 MTU 不匹配导致分片失败。
接着我在路径两端同时起抓包。对比两边的报文序列后发现，源端一直在以同一个序列号重传某个数据段，而目的端从头到尾都没收到过这个序列号——数据包在中间某一段“凭空消失”了。再用 traceroute 去打每一跳，发现其中一个节点的响应时间忽高忽低，明显存在排队。
随后查了这个节点的接口状态，真相大白：它有两条上行链路，一条带宽充足，一条带宽较小，动态路由协议一直把流量往小带宽链路上塞。流量超过这条链路容量后，队列溢出，数据包被随机丢弃。TCP 当然会重传，但由于重传后的包还是被路由到同一条拥塞链路，重传也照丢不误。于是重传率看起来“不算高”，业务却一塌糊涂。
5.3 根因与修复：网络层一改，应用层立刻恢复
修复方案并不复杂：在这台交换机上配置等价多路径（ECMP）的负载均衡策略，或者调整路由度量，把大部分数据流量引到带宽充足的那条链路。改完之后，同一个业务接口的 read timeout 几乎立刻消失，TCP 重传率也跟着降到接近 0。
这个案例给我的最大教训是：TCP 层指标“看着正常”，不代表网络层就正常。应用的延迟曲线往往就是网络层链路质量的曲线，只是中间隔了一层 TCP 的缓冲和超时，把原始信号“美化”了。很多团队排查到应用层就停了，因为应用层日志里全是超时；但如果再往下一层看，网络层可能早就发出了求救信号。
6. 给开发和运维的几条网络层“保命”建议
6.1 部署监控时别只盯着TCP层指标
很多团队的监控面板上全是 TCP 重传率、连接数、握手时延。这些指标固然重要，但它们就像“体温计”，只能告诉你发烧了，不能告诉你哪个器官发炎。真正要在网络层补的指标至少包括：ICMP 丢包率（分不同包长）、每一跳的 RTT 和抖动、接口出入方向的丢弃计数、路由表的收敛时间。
把这些指标按链路维度、路径维度存下来，才能做到“网络层出问题后，快速锁定是哪一段”。推荐的做法是：在源端、汇聚层、对端这三个点同时部署探针，每小时生成一份路径分段的质量曲线。以后性能一波动，先把三段曲线拉出来对比，谁丢包谁背锅，一分钟都不浪费。
有个开发同学跟我抱怨过，说他们监控里 TCP 重传率已经飙到 8%，却不知道是哪条链路导致的。后来我在他们监控系统里加了一张“路径分段”的折线图，把源网关、汇聚设备、对端网关三个点的 ICMP 丢包率放在一起对比，问题一眼就出来了——永远是中间那一段在丢，链路质量差得离谱。
6.2 设计网络拓扑时留一手“逃生通道”
单一路径的故障在 TCP 面前其实还算“直观”，要么通要么断。但多条路径如果配置不合理，反而会造成更隐蔽的问题：比如两条上行链路负载不均衡，流量总往一条跑，另一条闲着，你去看 TCP 重传率可能不高，但业务延迟已经明显恶化。
所以网络拓扑设计不能只追求“有冗余”，要确保冗余链路真正能承接故障转移。动态路由协议的 metric 要认真设计，定期做“断链演练”——直接拔掉一条链路，看流量切换得是否及时，业务中断窗口能不能接受。别等到真出故障的时候，才发现备用链路早就被历史遗留配置“掐死”了，那叫假装冗余，不叫高可用。
6.3 TCP调优的边界：网络层不改，传输层再调也白搭
最后一条，也是我最想说的一条。不少人一遇到 TCP 性能差，第一反应就是调内核参数：增大缓冲区、缩短重传时间、换拥塞控制算法。这些手段确实有效，但前提是网络层本身的问题已经被排除了。如果你的网络存在路由黑洞，调再大窗口也没用，报文还是到不了对端；如果中间链路 MTU 不一致，你把 MSS 调得再大也只是让分片丢得更频繁。
有一次在一个性能压测项目里，开发同学调了一整天拥塞控制参数，RTT 还是高得吓人。后来抓包发现中间节点有 2% 的随机丢包，拥塞控制算法理论上是能应对丢包的，但实际效果被链路本身的质量上限牢牢卡死。所以正确的顺序永远是：先保证网络层“可达且稳定”，再谈传输层的“可靠且高效”——这既是排障的顺序，也是架构设计的基本顺序。
在真实操作中，我自己的习惯是先把“网络层能不能到、通不通、稳不稳”这个前提放到最前面，再去看 TCP 层的各项指标。TCP 的可靠性真的很有迷惑性——它重传了，你以为它在努力修复；但如果连是网络层哪一段让它重传的都不知道，那修复动作就永远慢半拍。把上面这些网络层检查点做成自己的排查清单，很多看似玄学的“应用卡顿”问题，往往一个下午就能交代清楚。
