先坦白一个事情：这篇“基础（网络知识 三）——网络系统各层协议分析总结”对我来说其实不是一篇知识科普，更像是一份给自己交差的总结笔记。前两篇写了网络基础概念和常见设备，这一篇必须把 TCP/IP、UDP、HTTP 这些协议按层撸一遍。但写着写着我就发现，真正让我把协议记住的，不是背报文格式，而是无数次排查“网页打不开”“视频卡顿”“内网不通”时，被迫把数据包从头到尾剥一遍的过程。所以这篇我会换个讲法：不直接丢协议字段表，而是先讲清楚每一层到底解决什么问题，层与层之间怎么配合，然后再落到具体协议的行为逻辑和实测验证上。如果你正在复习计算机网络、准备面试，或者工作中经常跟网络打交道但总觉得隔着一层纱，这篇应该能帮你把零散知识点串成一条线。

1. 从一次“网页打不开”说起：协议分层到底解决了什么问题

1.1 一个真实到不能再真实的排查场景

有一次某位同事跑过来跟我说：“网断了。”我到现场一看，WiFi 信号满格，微信消息能正常收发，但浏览器里访问网页一直转圈，偶尔能打开一个页面，图片却加载不出来。

这个现象很有意思。如果不懂协议分层，很容易陷入两种极端：一种是觉得网速慢，于是去重启路由器；另一种是怀疑电脑中毒，赶紧杀毒重装。实际上，微信能用说明网络层和传输层大概率是通的，而网页加载异常，问题多半出在更高层——比如 DNS 解析、HTTP 请求的某个中间环节、或者是 MTU（最大传输单元）设置不合适导致的传输层数据分片问题。

我当时的排查顺序是：先ping网关确认链路层和网络层，再nslookup一个域名看 DNS 是否正常，然后curl -I一个网页看 HTTP 响应头是否返回，最后用tcpdump抓包看数据包是否有大量重传。整个链路走下来，发现是某台中间转发设备的 MTU 和路由器不一致，导致 TCP 分段后丢包重传，表现就是“网页经常转圈，但 IM 这种小包应用不受影响”。

这个案例暴露出一个核心问题：没有分层思维的人，看到的是“网坏了”；有分层思维的人，看到的是“从应用层到链路层，哪一段出了问题”。分层的价值从来不是让理论更复杂，而是让问题定位有明确的边界。

1.2 一次完整访问的旅程：每个环节对应哪一层

为了把分层这件事讲清楚，我们跟着一个最简单的操作走一遍：在浏览器地址栏输入一个网址，按回车，到页面显示出来，中间发生了什么。

第一步，浏览器先查本地缓存、系统 hosts 文件，如果没有结果，就发起 DNS 查询。这个动作属于应用层行为，但 DNS 协议本身又依赖 UDP（大多数情况下）把查询请求发出去。UDP 是传输层协议，它负责封装源端口和目标端口，把数据交给网络层。

第二步，网络层拿到目标 IP 之后，要决定这个 IP 该怎么走。如果目标 IP 和自己不在同一个网段，就需要交给默认网关；网关继续查路由表决定下一跳。这里用的是 IP 协议，以及配合它的路由协议。数据包每经过一跳，链路层都会重新封装一次源 MAC 和目标 MAC。

第三步，到达服务器之前，数据要过 TCP 三次握手。握手是传输层的事，它确保双方都有能力收发数据，并同步初始序号。握手完成后，浏览器在已经建立好的 TCP 连接上发送 HTTP GET 请求。

第四步，服务器返回 HTTP 响应，浏览器解析 HTML、加载 CSS、JavaScript、图片等资源。每个资源请求在 HTTP/1.1 下可能复用同一个 TCP 连接，在 HTTP/2 下甚至可以在一个连接上并行传输多个资源。

你会发现，一次访问从头到尾没有哪个协议是单独工作的：DNS 依赖 UDP，UDP 依赖 IP，IP 依赖链路层的 MAC 寻址，HTTP 依赖 TCP 的可靠传输。每一层只解决自己那一段的问题，然后通过“封装”把控制权交给下一层。

2. 协议栈分工：TCP/IP 四层模型到底在分什么

2.1 为什么分层不是教科书上的老古董

很多初学者觉得 OSI 七层模型和 TCP/IP 四层模型很抽象，背了又忘。我换个角度讲：分层就是“拆解责任”。

用寄包裹来类比。你写好一封信，这是应用层的内容。你要寄出去，得先装进信封，写上收件人姓名和地址，这是传输层的“端口”概念——端口就是同一台主机上的不同应用，相当于大楼里的房间号。然后你把信投进邮局，邮局根据城市、街道来规划路线，这是网络层的“IP 地址”——它只关心怎么跨网络送达。最后，快递员在本地小区里靠门牌号把信送到你手上，这是链路层的“MAC 地址”——它负责在同一段物理链路内寻址。

每一层都只跟自己的“对等层”通信，不需要关心上下层的实现细节。这就是协议栈设计的精髓：链路层不需要知道 HTTP 是什么，TCP 不需要知道数据是网页还是视频，应用层也不需要了解 Wi-Fi 还是光纤。

TCP/IP 四层模型在实际生产环境中就是事实标准，它把 OSI 的会话层和表示层合并进了应用层，把数据链路层和物理层合并成了网络接口层。原因很简单：在现实的网络世界里，会话管理和数据格式转换往往由应用程序自己处理，或者由 HTTP、TLS 这类协议承担，单独拆成两层显得多余。

2.2 四层模型与七层模型的对照关系

为了照顾很多教材的习惯，我把两个模型的对应关系列一张表：

这张表考试很有用，但真正工作里你只需要记住一个判断标准：某个字段或者某个动作发生在哪个层级，取决于它处理的数据要不要跨网络转发。IP 地址跨网络有效，所以 IP 在网络层；MAC 地址只在同一广播域内有效，所以它在链路层；端口号标识同一台主机上的不同进程，所以它在传输层；URI、状态码、头部字段是应用自己定义的语义，所以它们在应用层。

2.3 数据封装：每一层都往信封上贴一张新面单

分层协作的具体表现是数据封装和解封装。发送方从上往下，每经过一层就追加一个头部；接收方从下往上，每经过一层就剥掉一个头部。

简单画一下这个过程：浏览器生成一个 HTTP 请求报文，这是应用层数据。TCP 层给这段数据加一个 TCP 头，里面包含源端口、目标端口、序号、确认号等，形成 TCP 报文段。IP 层再加一个 IP 头，里面包含源 IP、目标 IP、TTL、协议号，形成 IP 数据报。链路层再加一个以太网头，里面包含源 MAC、目标 MAC、类型字段（0x0800 表示 IPv4），最后加上帧尾校验，形成以太网帧。

接收方做完全相反的操作：网卡收到帧，剥掉以太网头和尾，把 IP 数据报交给 IP 层；IP 层剥掉 IP 头，根据协议字段判断上层是 TCP 还是 UDP，把数据交给对应的传输层协议；TCP 再剥掉自己的头，根据端口号把数据交给对应的应用进程。

这个机制解释了为什么抓包工具里看到的数据包是“一层套一层”的。每次抓包看到的完整结构都是：最外层的 Ethernet II，里面是 Internet Protocol Version 4，再里面是 Transmission Control Protocol，最里面才是 HTTP 的文本内容。每一层做好自己的事，然后不加评判地把数据传给上一层，这就是协议栈的协作方式。

3. 网络层与链路层：IP 怎么选址，MAC 怎么寻址

3.1 IP 地址与子网掩码：从分类编址到 CIDR

IP 协议的核心使命是提供“逻辑地址”，让数据包可以跨越不同的物理网络到达目的地。IPv4 地址是 32 位的，习惯写成点分十进制，比如 192.168.1.10。但这个数字本身如果不配合子网掩码，你是无法判断网络规模和地址范围的。

早期采用分类编址：A 类地址前 8 位是网络位，B 类前 16 位，C 类前 24 位。这么大的块分配给实际使用时会出现严重浪费——一个 C 类只有 254 个可用地址，一个 B 类却有两万多个，但大多数单位用不完。

所以现在普遍使用 CIDR（无类别域间路由），用“IP/前缀长度”的写法来明确网络位和主机位的边界。192.168.1.0/24 表示前 24 位是网络位，后 8 位是主机位，可用地址从 192.168.1.1 到 192.168.1.254（网络地址和广播地址不能用）。

子网掩码的作用就是用来做“与运算”的。把 IP 地址和掩码按位与，得到的是网络地址，例如 192.168.1.10 与 255.255.255.0 相与，结果是 192.168.1.0。两台设备通信时，先把对方的 IP 和自己的掩码做与运算：如果结果和自己的网络地址一致，说明在同一网段，直接走链路层；如果不一致，说明在不同网段，必须把包发给默认网关。

3.2 路由决策：数据包到了路由器之后怎么走

路由器的工作是每收到一个 IP 数据报，就查自己的路由表，决定从哪个接口转发出去。路由表里的每一行都包含目标网段、下一跳地址、出接口和优先级。路由器在查表时做的是“最长前缀匹配”：把数据报的目标 IP 和路由表项逐一比较，匹配到前缀最长的那条。

举个例子：路由表里有 192.168.1.0/24 和 0.0.0.0/0 两条路由。目标 IP 是 192.168.1.50，它会优先匹配 192.168.1.0/24，因为前缀长度 24 大于 0；如果目标 IP 是 8.8.8.8，匹配不上任何具体网段，只能走默认路由 0.0.0.0/0，也就是所谓的“兜底路由”。

关于路由表是怎么来的，常见有三种：直连路由，设备自动发现自己接口上的网段；静态路由，管理员手动配置，适合拓扑简单、路径明确的环境；动态路由，路由器之间通过协议自动交换信息，适合大型网络。

实际排查网络不通问题时，经常用到traceroute（Windows 下是tracert）。这个命令的原理是利用 IP 头里的 TTL 字段：第一个包 TTL=1，经过第一跳路由器后 TTL 减为 0，路由器丢弃该包并返回 ICMP 超时消息，这样就能拿到第一跳的地址；然后 TTL=2，拿到第二跳；依此类推，就能看到数据包走的完整路径。

3.3 ARP：在局域网里怎么把 IP 变成 MAC

IP 地址能帮数据包到达目标网段，但真正让数据在一根网线或一段 Wi-Fi 上传输的，还是 MAC 地址。问题是：我明明知道对方的 IP，怎么知道它的 MAC？答案是 ARP（地址解析协议）。

ARP 的流程很直接：如果主机 A 要给主机 B 发数据，A 先查自己的 ARP 缓存表；没有 B 的 IP 对应的 MAC，就在本地广播域内发送一个 ARP 请求“谁的 IP 是 192.168.1.10，告诉我你的 MAC”。这个广播包会被网段内的所有设备收到，但只有 IP 匹配的那台设备会回复一个 ARP 应答，把自己的 MAC 地址告诉 A。A 收到后把映射写进缓存，后续通信就直接用缓存了，不用重复广播。

这里有个容易忽略的坑：ARP 只在同一广播域内有效。主机 A 和服务器 B 如果不在同一个网段，A 根本不会发 ARP 找 B，而是直接把包发给默认网关——也就是说，A 的 ARP 请求是问“网关的 MAC 是多少”，而不是远端服务器的 MAC。网关路由器再把数据包转发给下一跳。

理解这一点之后，你再看一个公司网络拓扑就能明白：三层交换机负责不同网段之间的路由，二层交换机只做 MAC 地址和端口之间的映射，网关接口的 MAC 才是每个网段内主机要解析的最终目标。排错时，如果ping自己写的 IP 通、ping 网关不通，十有八九是 ARP 解析失败，比如 VLAN 配置不对、交换机端口隔离、或者网线和物理链路的问题。

4. 传输层的两个典型：TCP 的可靠和 UDP 的洒脱

4.1 TCP 三次握手：为什么不是两次也不是五次

TCP 最出名的就是三次握手建立连接。客户端发一个 SYN 报文，服务器回一个 SYN+ACK，客户端再回一个 ACK，连接建立。这个过程的本质是双方确认四件事：我能发、我能收、你能发、你能收。

第一个包 SYN=1，表示客户端请求建立连接；第二个包 SYN=1 且 ACK=1，表示服务器同意连接并确认收到第一个包；第三个包 ACK=1，表示客户端确认收到服务器的响应。只有到第三步，客户端才知道“服务器既能收也能发”，服务器也才确认“客户端收到了我的响应”。三次握手的核心价值在于同步初始序列号——TCP 是字节流协议，每个字节都有编号，双方必须知道从哪个编号开始计数，才能正确重组数据和检测丢包。

为什么两次不行？假设只做两次握手，服务器在收到 SYN 后就认为连接建立，但客户端如果因为网络延迟还没来得及确认，服务器就开始发数据，一旦这个 SYN 是滞后重发的旧报文，就会造成服务器资源被白白占用。为什么四次多余？因为第三步客户端回 ACK 时已经可以携带应用层数据了，没有必要再单独多来一次往返。实际抓包里，第三个 ACK 经常紧跟着第一个 HTTP 请求一起出现。

再说一下断开连接的“四次挥手”。数据传完了，客户端发 FIN 断开请求，服务器回 ACK，表示“我收到你断开的消息了”，但这个时候服务器可能还有数据没发完，所以过一阵再发自己的 FIN，客户端再回最后一个 ACK。按照惯例，客户端收到 FIN 之后进入 TIME_WAIT 状态，等待 2 个 MSL 后才真正关闭。这个设计是为了让迟到的包能在网络中消散，同时也是为了防止新连接收到旧连接的残留数据。

4.2 TCP 可靠传输的机制：序号、确认、重传

TCP 的可靠传输不是靠“下功夫让链路不变差”，而是靠一整套“收到就确认，没收到就重传”的机制。

发送方把应用层数据拆成一个个字节流，每个字节编一个序号。TCP 头里的“序号”字段表示当前报文段携带的第一个字节的序号；接收方收到后，通过“确认号”告诉发送方“你发到第 n 号字节之前的我都收到了，下一个我要 n+1”。这个机制直接解决了丢包检测的问题。

如果某个报文段在网络上丢失了，接收方会一直发送重复的 ACK，要求发送方补上缺失的那段。发送方有两种重传策略：一是超时重传，每发一个报文段启动一个计时器，到期没收到确认就重传；二是快速重传，连续收到 3 个重复 ACK 就立刻重传，不用等计时器到期，这样能把恢复等待的时间从毫秒级缩短到微秒级。

实际网络排错中最常见的现象是“大量 TCP 重传”（tcpdump 里可以看到同一序号反复出现）。这时候不要先怀疑应用服务器，而是要看链路上是否有丢包、路由器缓冲区是否溢出、或者 MTU 设置是否导致 IP 分片后被丢弃。

4.3 滑动窗口、流量控制、拥塞控制：TCP 的自我调节

TCP 除了保证不丢，还要保证不乱、不快到把对方或把网络压垮。它靠的是三个窗口机制。

滑动窗口解决的是“流水线发送”问题。如果不控制，发送方每发一个包就要等确认，网络利用率极低；滑动窗口允许发送方在未收到确认的情况下连续发送多个报文段，窗口大小决定了“未确认但已发出”的数据上限。这个机制让 TCP 实现了同时收发多个数据段，而不需要像停等协议那样一个一个来。

流量控制解决的是“接收方处理不过来”的问题。接收方把可用缓冲区大小写进 ACK 的“窗口字段”，告诉发送方“你一次最多发这些，多了我会丢”。这就像嘴里还在嚼着饭，先跟服务员说“先别上菜了”。

拥塞控制解决的是“网络中间节点承受不了”的问题。发送方自己维护一个拥塞窗口，初始时小而快速增长（慢启动），到达阈值后转为线性增长（拥塞避免），一旦出现丢包或超时，立刻把窗口降下来。整个过程是发送方对网络状况的探测，有点像开车试探车速，路况好就慢慢加速，一颠簸就赶紧减速。

初学者经常搞混流量控制和拥塞控制的区别：流量控制是端到端的，由接收方告诉发送方“我能收多少”；拥塞控制是全局的，是发送方自己推断“这条路上涨不涨”。两者都通过调整发送窗口的大小来实现，但信息来源完全不同。

4.4 UDP：没有连接不代表没有价值

UDP 的头部只有 8 个字节：源端口、目标端口、长度、校验和。它不保证可靠交付，不负责重传，也不维持连接状态。很多人误以为“不可靠=不好用”，这个观念在实时互联网应用里早就被推翻了。

UDP 的特点恰恰是它的优势：低延迟，因为省掉了三次握手和连接维护的开销；无状态，适合大量短小报文；不受拥塞控制的限制，可以持续以固定速率发送。所以音视频通话、直播、在线游戏、IoT 设备上报，这类“丢一两帧没关系，但延迟必须低”的场景首选就是 UDP。

更值得一提的是，HTTP/3 的本质就是在 UDP 之上实现可靠传输。它把 TCP 里的可靠机制、TLS 的加密机制都搬到了用户态，通过 QUIC 协议实现了 0-RTT 握手、连接迁移和多路复用，解决了 TCP 握手延迟和队头阻塞问题。你会发现，UDP 不是不如 TCP，而是把可靠性问题交给了上层自己去解决，反而获得了更多的灵活性。

5. 应用层协议集中营：HTTP、DNS、DHCP

5.1 HTTP 协议演进：从 1.0 到 3.0，每一版解决什么问题

HTTP 是 Web 世界使用最频繁的应用层协议。理解它的演进，基本上就能理解整个互联网基础设施这些年是怎么“打补丁”的。

HTTP/1.0 时代，每次请求都要建立一个新的 TCP 连接，请求完就断开。一个网页如果有 10 张图片，就得建 10 次连接，光握手消耗就非常可观。

HTTP/1.1 做了三个重要改进：一是长连接，多个请求复用同一个 TCP 连接；二是管道化，允许客户端连续发请求而不用等响应；三是增加了 Host 头，让一台服务器可以用同一个 IP 托管多个域名。但管道化有一个明显缺点：服务器必须按顺序返回响应，如果第一个请求处理得慢，后面的响应全被堵住，这就是队头阻塞。

HTTP/2 针对队头阻塞引入了二进制分帧和真正的多路复用。它把请求和响应拆成一个个流和帧，在同一个 TCP 连接上交错传输，彻底解决了“前一个不响完，后一个不能响”的问题。同时它还做了头部压缩，减少重复头部字段的传输量。

HTTP/3 换了个底层玩家。因为 TCP 本身还有队头阻塞——某一段数据丢了，即使后面几段都到了，接收方也不能交给上层。所以 HTTP/3 改用 QUIC（基于 UDP），把可靠性、加密、流量控制都自己做了，再加上多路复用和连接迁移，移动网络切换基站时也能保持连接不掉。从 1.0 到 3.0，你会发现核心追求没变：传输更快、连接更稳、资源利用率更高。

关于 HTTPS，它就是 HTTP 加了一层加密协议。HTTP 明文传输的痛点在于窃听、篡改和伪装，TLS 握手阶段用证书验证服务器身份，通过密钥协商生成会话密钥，之后所有 HTTP 内容都加密传输。现在如果哪个网站还在裸奔 HTTP，基本可以直接列入不信任名单。

5.2 DNS：域名到 IP 的翻译过程

DNS 是把人类可读的域名翻译成机器可读 IP 地址的系统。这个过程看似简单，但背后的查询机制和缓存策略，对网页加载速度的影响非常大。

当你输入一个域名，操作系统先查本地 hosts 文件和 DNS 缓存；没有命中，就向本地配置的 DNS 服务器发送查询请求。这里的查询方式分两种：一种是递归查询，本地 DNS 服务器替你跑腿，直到拿到最终结果；一种是迭代查询，本地 DNS 服务器让你去找根服务器、顶级域服务器、权威服务器，一层层自己问。

具体到域名解析的过程：本地 DNS 服务器先问根服务器“你知道 www.example.com 的 IP 吗”，根服务器说“我不知道，但 .com 顶级域服务器的地址你去找它”；本地 DNS 服务器再问 .com 顶级域服务器，它说“example.com 这个域名的授权服务器是那台”；本地 DNS 服务器再去问授权服务器，这次终于拿到具体的 IP。

这里最关键的两个知识点：第一，TTL 决定了 DNS 查询结果可以在缓存里存多久。改域名解析记录之后，不要问“为什么还没生效”，先看看 TTL。第二，DNS 不仅提供 A 记录（IPv4）、AAAA 记录（IPv6），还有 CNAME（别名）、MX（邮件交换）、TXT（文本校验）等很多类型。排错时用dig命令比nslookup更详细，能看到查询走的是哪个 DNS 服务器、返回了哪些记录、TTL 是多少。

5.3 DHCP：新设备接入网络的第一步

新设备插上网线或者连上 WiFi 时，IP 地址从哪来？大部分情况下是 DHCP 分配的。DHCP 是应用层协议，底层用 UDP，服务端监听 67 端口，客户端发送到 68 端口。

整个过程分四步：客户端先发送 DHCP Discover 广播，寻找网络里的 DHCP 服务器；服务器回应 DHCP Offer，提供一个候选 IP 地址和一些网络配置参数（子网掩码、网关、DNS 服务器地址）；客户端收到后发送 DHCP Request，表示“我要用这个地址”；服务器最后回应 DHCP ACK，确认租约生效。

这四步里有一个容易忽略的细节：DHCP 分配的地址是有租期的，默认可能是 24 小时或更长，续租会在租期过半时自动发起。如果你在排查“IP 突然变了导致服务访问异常”的问题，先查 DHCP 租约时间和设备是否重新申请了地址。

另外，DHCP 是广播协议，它只能在自己所在的广播域内工作。如果需要给多个网段自动分配 IP，就得在交换机或路由器上配置 DHCP 中继，让 DHCP 请求跨网段转发到中心的 DHCP 服务器。

6. 实测验证：用抓包和命令行亲手看协议行为

6.1 一套最常用的排查命令组合

了解协议之后，最重要的就是把知识变成肌肉记忆。我自己排查网络问题有一套固定组合：

• ip addr：查看本机 IP 地址、子网掩码、MAC 地址；
• ip route：查看路由表，确认默认网关；
• ping 网关：确认链路层和网络层基本通；
• nslookup 域名或dig 域名：确认 DNS 解析是否正常；
• curl -v http://域名：确认 HTTP 是否通，能看到连接建立和响应状态码；
• tcpdump -i eth0 host 目标IP：抓包看实际网络行为。

这套组合从下往上逐层验证，哪个环节断了，马上就能定位。不要上来就抓包，先把简单的命令过一遍，能省掉大量时间。

另外补充一个重要前提：ping通不等于 HTTP 通。ping走的是 ICMP 协议，很多防火墙只放行 ICMP 却不放行 TCP 80/443，或者反过来。所以排错时一定要根据实际业务流量来验证，不能只看ping的结果就下结论。

6.2 抓包观察三次握手和 HTTP 请求

为了能更直观地展示一层一层的关系，写一条 tcpdump 命令：

tcpdump -i eth0 -nn 'tcp port 80' -w http.pcap

然后另开一个终端访问某个 HTTP 网站。抓完包用 Wireshark 打开过滤http，你能看到每个 TCP 流的完整过程。

先说三次握手：第一个包是 SYN，Flags 字段为 [S]，序列号是一个随机数；第二个包是 SYN+ACK，Flags 为 [S.]，确认号等于第一个包的序列号加一；第三个包是 ACK，Flags 为 [.]，这时连接建立。紧接着就能看到 GET / HTTP/1.1 请求，这就是应用层数据被 TCP 封装之后的样子。

然后看响应的数据包：服务器返回 HTTP/1.1 200 OK，后面跟着一堆头字段，再往下就是被 TCP 分段传输的 HTML 正文。Wireshark 里能直接看到每个包的 Ethernet 层、IP 层、TCP 层和 HTTP 层信息，这就是协议分层的实物对照。

还有一个很好用的观察点：抓包过滤器里只过滤tcp.flags.syn == 1，可以只看握手包。你可能会发现有些请求只看到 SYN，没有后面的 SYN+ACK，说明对方根本没有响应——这是典型的被防火墙丢弃或者目标端口没监听。如果看到 ACK 但一直重传，说明链路质量有问题。

6.3 一个典型问题的完整排查链路

为了把前面所有知识串起来，我模拟一个日常场景：A 同学说“某台业务服务器网页能打开，但登录接口一直超时”。

第一步，验证基础连通性。ping服务器 IP，发现延迟正常，说明链路层和网络层没问题。

第二步，验证端口。用nc -vz 服务器IP 443检查 443 端口是否开放。这里如果直接失败，大概率是防火墙拦截了 TCP 到 443 的流量。

第三步，抓包看握手。如果端口探测成功但业务超时，用tcpdump抓 TCP 443 的包，看握手是否完成。正常应该是三次握手结束后马上有 TLS 流量；如果看到 SYN 发出后没有响应，说明中间设备拦截；如果握手完成但后续请求一直重传，说明链路丢包严重。

第四步，看应用层。如果 TCP 层一切正常，再用curl -X POST构造一个真实登录请求，观察响应时间分布：TCP 连接建立耗时、TLS 握手耗时、首字节响应时间分别占据多少。这一步能区分是网络问题还是应用处理慢。

这个排查链路表面上是在用命令，本质上就是沿着 TCP/IP 四层模型一层层往上走。脑子里有分层模型，手里有对应工具，排错就是条件反射。

很多年后我回头看，发现网络协议栈其实是我所有技术知识里最“稳定”的一块——它不会像框架一样一年换好几个版本，也不会因为某种编程语言流行而变得过时。把 TCP/IP 和 HTTP 这些基础搞透，后面无论是学 Kubernetes 的网络插件、云上 VPC 规划、还是写高性能网关，你都有一张底图可以对照。这篇写的是总结，但更适合作为一份自查清单：看到三次握手能说出为什么，看到 TIME_WAIT 知道它存在的理由，看到 HTTP/3 能讲清它把哪个老问题解决了——这些都能想明白，网络这层地基就算真的打牢了。

最后再分享一个小技巧：我每次学一个新协议，都会刻意去写一条抓包命令，然后用 Wireshark 把协议报文从头到尾点开看一遍，再看三篇别人写的实战排错文章。这事看起来慢，但积累多了之后，你在面对“间歇性网络超时”这类玄学问题时会比大多数人少走很多弯路。网络不是靠看会的，是把每个包都拆一遍拆会的。