03-TCP/IP 协议栈

1. 概述

这个总览把 TCP/IP 四层模型、封装过程和常见排障现象放到同一视角，后文会按这些层级展开。

上一篇《OSI 七层模型详解》用七层模型建立了网络通信的分析框架。本文继续向实际工程靠近，讲清楚今天互联网、企业内网、云网络和大多数应用系统真正运行的协议族：TCP/IP 协议栈。

TCP/IP 不是单个协议，而是一组围绕 IP、TCP、UDP、ICMP、ARP、DNS、HTTP 等协议组合起来的通信体系。日常运维里常见的现象，例如“能 ping 通但网页打不开”“DNS 解析正常但端口不通”“同网段能访问跨网段不通”“抓包看到 SYN 没有 SYN-ACK”，本质上都可以放回 TCP/IP 协议栈中定位。

学习目标：

• 理解 TCP/IP 四层模型与 OSI 七层模型的对应关系
• 掌握数据从应用发送到网卡时的封装与解封装过程
• 理解 IP、ICMP、ARP、TCP、UDP 在通信链路中的职责边界
• 学会使用 ip、ping、traceroute、ss、curl、tcpdump 等命令做分层验证
• 建立“按层定位问题”的网络排障思路

前置知识：

• 网络基础概念
• OSI 七层模型
• 基本 IP 地址、端口和网关概念

2. 理论基础

2.1 TCP/IP 四层模型

TCP/IP 模型通常分为四层：

可以把它理解成一次快递投递：

• 应用层决定“寄什么内容”，例如 HTTP 请求或 DNS 查询。
• 传输层决定“交给哪个应用进程”，例如 TCP 443 或 UDP 53。
• 网络层决定“送到哪台主机”，例如目的 IP 地址和下一跳网关。
• 网络接口层决定“这一跳发给哪个网卡”，例如目的 MAC 地址和以太网帧。

2.2 封装与解封装

发送数据时，每一层都会在上层数据外面增加自己的控制信息：

应用数据
  ↓ 传输层加 TCP/UDP 头
TCP Segment / UDP Datagram
  ↓ 网络层加 IP 头
IP Packet
  ↓ 网络接口层加 Ethernet 头和 FCS
Ethernet Frame
  ↓ 物理介质
比特流

接收端则反向处理：网卡收到帧，检查目的 MAC 和 FCS；操作系统解析 IP 包，确认目的 IP；传输层根据端口交给对应进程；应用程序再解析业务协议。

一个典型的 HTTPS 请求大致如下：

浏览器
  ↓ HTTP 请求 / TLS 加密数据
TCP 443
  ↓ 源端口 52344 → 目的端口 443
IP
  ↓ 源 IP 192.168.10.20 → 目的 IP 203.0.113.10
Ethernet
  ↓ 源 MAC 笔记本网卡 → 目的 MAC 默认网关
交换机 / 路由器 / 防火墙 / Internet

注意：目的 MAC 地址通常只代表下一跳，不一定是最终服务器。目的 IP 地址才代表端到端的目标主机。

2.3 各核心协议的职责边界

IP：负责寻址与路由

IP 协议负责把数据包从源主机送向目的主机。IPv4 使用 32 位地址，IPv6 使用 128 位地址。IP 层关注的是“目的 IP 在哪里、下一跳走哪里、数据包还能转发多少跳”。

IPv4 头部中的几个字段很常见：

IP 本身是“尽力而为”协议，不承诺数据一定到达、不承诺顺序、不负责重传。这些能力由 TCP 或应用层补足。

ICMP：负责控制消息与诊断

ICMP 常被误解为“ping 协议”。实际上 ICMP 是网络层控制消息协议，用于反馈网络不可达、TTL 超时、需要分片但不能分片等情况。

常见用途：

• ping 使用 ICMP Echo Request / Echo Reply 测试可达性。
• traceroute 通过 TTL 超时消息推断路径。
• 路由器可用 ICMP Destination Unreachable 提示不可达原因。
• 路径 MTU 发现依赖相关 ICMP 消息反馈。

生产环境中不应简单把所有 ICMP 都封掉。完全屏蔽 ICMP 可能让路径 MTU、链路诊断和故障定位变得困难。

ARP：负责 IPv4 同网段 IP 到 MAC 的解析

在 IPv4 局域网中，主机知道目的 IP 后，还需要知道下一跳 MAC 地址才能封装以太网帧。ARP 的职责就是把 IPv4 地址解析成 MAC 地址。

典型过程：

主机 A：谁是 192.168.10.1？请告诉 192.168.10.20
网关：192.168.10.1 在 00:11:22:33:44:55
主机 A：把目的 MAC 填为 00:11:22:33:44:55，发送以太网帧

如果访问同网段主机，ARP 解析的是对端主机的 MAC；如果访问跨网段地址，ARP 解析的是默认网关的 MAC。

TCP：负责可靠的字节流传输

TCP 是面向连接的可靠传输协议。它通过序号、确认、重传、窗口和拥塞控制，尽量保证数据按序、完整地交给应用。

TCP 常见特征：

• 通信前通过三次握手建立连接。
• 使用端口号标识应用进程。
• 使用序列号和确认号跟踪数据。
• 使用滑动窗口做流量控制。
• 使用拥塞控制避免把网络打满。
• 把应用数据视为连续字节流，不保留消息边界。

三次握手：

Client                              Server
  | -------- SYN --------------------> |
  | <---- SYN, ACK ------------------- |
  | -------- ACK --------------------> |
  | ======== Application Data =======> |

运维排障中，TCP 状态很重要：

UDP：负责轻量的数据报传输

UDP 是无连接协议。它提供端口号和校验和，但不提供连接建立、重传、排序和拥塞控制。应用需要自己接受“可能丢包、可能乱序、可能重复”的现实，或者在应用层实现补偿机制。

UDP 适合：

• DNS 查询
• DHCP
• NTP
• 语音、视频、实时游戏
• QUIC 这类在 UDP 之上自行实现可靠性和拥塞控制的协议

UDP 并不等于“低质量”，它只是把可靠性控制交给应用或上层协议。对实时业务而言，迟到的数据包可能比丢包更糟糕，因此 UDP 反而更适合。

2.4 TCP/IP 与 OSI 的工程关系

OSI 更适合教学和排障语言，TCP/IP 更贴近真实协议栈实现。实际工作中可以这样使用：

• 讲原理：使用 OSI 七层，层次更细。
• 看抓包：使用 TCP/IP 四层，更接近真实协议字段。
• 做排障：用 OSI 从下往上排，用 TCP/IP 对应命令验证。

OSI 七层                 TCP/IP 四层
应用层
表示层      ───────────>  应用层
会话层
传输层      ───────────>  传输层
网络层      ───────────>  网络层 / 网际层
数据链路层
物理层      ───────────>  网络接口层

3. 环境规划

本文验证命令以 Linux 主机为主，适用于 Ubuntu 22.04/24.04、Debian 12、Rocky Linux 9 等常见发行版。Windows 和 macOS 也有对应工具，但命令略有差异。

实验拓扑：

Client: 192.168.10.20/24
Gateway: 192.168.10.1
DNS: 192.168.10.1 或 223.5.5.5
Internet Server: example.com

建议工具：

权限说明：

• 查看地址、路由、端口通常不需要 root。
• 抓包、调整网络参数和修改路由通常需要 sudo。
• 生产环境抓包前应确认变更窗口、隐私合规和数据留存要求。

4. 实战操作

4.1 查看本机网络接口

先确认主机是否有有效 IP、掩码和网卡状态：

ip addr show

重点看：

• 网卡是否是 UP。
• 是否存在预期的 IPv4/IPv6 地址。
• 掩码长度是否正确，例如 /24。
• 地址是否配置在正确网卡上。

只看简洁结果：

ip -br addr

如果网卡没有地址，优先检查 DHCP、静态地址配置、NetworkManager 或 systemd-networkd 配置，而不是直接怀疑上层应用。

4.2 查看路由表

ip route show

常见路由表类似：

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20

含义：

• 192.168.10.0/24 dev eth0：同网段流量直接从 eth0 发出。
• default via 192.168.10.1：未知目的地址交给默认网关。
• src 192.168.10.20：访问该网段时使用的源地址。

查看访问某个目的地址会怎么走：

ip route get 8.8.8.8
ip route get 192.168.10.1

这比只看路由表更直观，因为它会展示系统实际选择的出口网卡、下一跳和源地址。

4.3 查看 ARP / 邻居表

Linux 使用邻居表统一展示 IPv4 ARP 和 IPv6 Neighbor Discovery：

ip neigh show

常见状态：

主动触发网关解析：

ping -c 2 192.168.10.1
ip neigh show 192.168.10.1

如果网关 IP 配置正确但邻居表一直 FAILED，优先检查二层连通性、VLAN、网线、交换机端口、无线接入和网关是否在线。

4.4 使用 ping 测试网络层可达性

按层递进测试：

# 1. 测试本机协议栈
ping -c 3 127.0.0.1

# 2. 测试本机 IP 是否可用
ping -c 3 192.168.10.20

# 3. 测试默认网关
ping -c 3 192.168.10.1

# 4. 测试公网 IP
ping -c 3 8.8.8.8

# 5. 测试域名
ping -c 3 example.com

判断逻辑：

• 127.0.0.1 不通：本机协议栈或系统异常。
• 本机 IP 不通：地址配置或网卡绑定异常。
• 网关不通：二层、VLAN、网关或本机地址配置问题。
• 公网 IP 不通但网关通：默认路由、上级网络、防火墙或出口问题。
• IP 通但域名不通：DNS 问题概率高。

4.5 使用 dig 验证 DNS 应用层解析

DNS 属于应用层，但通常使用 UDP 53 或 TCP 53 承载。

dig example.com
dig example.com +short
dig @223.5.5.5 example.com +short

排障重点：

• 系统 DNS 是否配置正确：resolvectl status 或查看 /etc/resolv.conf。
• 是否只有某个 DNS 服务器异常。
• UDP 53 是否被拦截。
• 大响应、区域传送或特殊场景是否需要 TCP 53。

如果 ping 8.8.8.8 通但 dig example.com 失败，问题通常不在 IP 路由层，而在 DNS 配置、DNS 服务器或防火墙策略。

4.6 使用 ss 验证传输层端口

查看本机监听端口：

ss -lntup

常用参数：

• -l：只看监听。
• -n：不解析名称，直接显示数字端口。
• -t：TCP。
• -u：UDP。
• -p：显示进程。

查看当前 TCP 连接状态：

ss -tan
ss -tan state established
ss -tan state syn-sent

如果客户端大量停留在 SYN-SENT，说明 SYN 发出后没有收到 SYN-ACK，可能是目标服务未监听、防火墙拦截、路由回程异常或中间设备丢包。

4.7 使用 curl 验证应用层

curl -I https://example.com
curl -v https://example.com

curl -v 能显示：

• DNS 解析结果
• TCP 连接过程
• TLS 握手
• HTTP 请求和响应头

如果 TCP 能建立但 HTTP 返回 404、403、500，说明网络层和传输层大概率已经通了，重点应转向应用配置、反向代理、证书、鉴权和后端服务。

4.8 使用 tcpdump 观察封装过程

抓取访问 example.com 的 DNS 与 TCP 过程：

sudo tcpdump -i eth0 -nn 'host example.com or port 53'

如果 DNS 解析后想抓指定 IP：

dig example.com +short
sudo tcpdump -i eth0 -nn 'host 93.184.216.34'

观察 TCP 三次握手：

sudo tcpdump -i eth0 -nn 'tcp port 443'

常见现象：

Client.52344 > Server.443: Flags [S]
Server.443 > Client.52344: Flags [S.]
Client.52344 > Server.443: Flags [.]

含义：

• [S]：SYN。
• [S.]：SYN + ACK。
• [.]：ACK。

如果只看到客户端反复发 [S]，没有 [S.] 回来，问题通常在服务端监听、防火墙、路由或回程路径。

5. 配置详解

这个配置视角把 TCP/IP 常见配置项放到一起：地址决定主机在哪，路由决定流量往哪走，MTU 影响单次传输边界，端口决定交给哪个进程。

5.1 IP 地址、掩码与网关的关系

主机发送数据前，会先判断目的 IP 是否与自己在同一个网段：

• 同网段：直接 ARP 解析目的主机 MAC。
• 不同网段：ARP 解析默认网关 MAC，把帧发给网关。

例如：

本机：192.168.10.20/24
网关：192.168.10.1
目的 A：192.168.10.30  → 同网段，直接找 192.168.10.30 的 MAC
目的 B：10.20.30.40    → 跨网段，找 192.168.10.1 的 MAC

所以“默认网关”不是所有通信都一定经过的设备。只有跨网段通信才需要它。

5.2 MTU 与分片

MTU 是网络接口一次能承载的最大三层数据包大小。常见以太网 MTU 是 1500 字节。超过 MTU 的数据包可能被分片，或者在设置 DF 位时被丢弃并返回 ICMP 提示。

查看接口 MTU：

ip link show eth0

测试路径 MTU 的常见方法：

# Linux：设置不分片并指定 payload 大小
ping -M do -s 1472 8.8.8.8

IPv4 下，1472 + 20 字节 IP 头 + 8 字节 ICMP 头 = 1500。如果 1472 不通而更小的值通，说明路径中存在更小 MTU，常见于 VPN、隧道、PPPoE、云网络封装等场景。

5.3 端口与进程

IP 地址标识主机，端口标识主机上的应用进程。一个典型连接由五元组唯一标识：

源 IP、源端口、目的 IP、目的端口、传输协议

例如：

192.168.10.20:52344 -> 203.0.113.10:443 TCP

服务端通常监听固定端口，客户端通常使用临时端口。排障时不要只看目的端口，也要注意源端口范围、NAT 设备会话表和防火墙是否允许回程流量。

5.4 TCP 与 UDP 的选择

工程选择不应简单理解为“TCP 可靠、UDP 不可靠”。更准确的说法是：TCP 把可靠性做在传输层，UDP 把控制权交给应用层。

6. 验证与测试

可以按下面顺序完成一轮 TCP/IP 协议栈验证：

# 1. 查看地址
ip -br addr

# 2. 查看路由
ip route show
ip route get 8.8.8.8

# 3. 验证网关
ping -c 3 192.168.10.1

# 4. 查看邻居表
ip neigh show

# 5. 验证公网 IP
ping -c 3 8.8.8.8

# 6. 验证 DNS
dig example.com +short

# 7. 验证 TCP/HTTPS
curl -I https://example.com

# 8. 查看连接状态
ss -tan

成功标准不是每个命令都必须返回某个固定输出，而是每一层都有合理证据：

• 本机有正确 IP 和掩码。
• 有正确默认路由。
• 网关可达或至少邻居解析正常。
• 外部 IP 可达。
• DNS 能解析。
• 目标端口可建立连接。
• 应用层能返回预期响应。

如果某一步失败，就停在对应层继续排查，不要直接跳到应用层重启服务。

7. 故障排查

这个决策路径把常见 TCP/IP 故障按现象拆开，下面的排查步骤会沿着这些分支展开。

7.1 本机没有 IP 地址

表现：

• ip -br addr 中目标网卡没有 IPv4 地址。
• DHCP 客户端日志有超时。
• 不能 ping 网关。

排查：

ip link show
sudo journalctl -u NetworkManager --since "30 min ago"
sudo journalctl -u systemd-networkd --since "30 min ago"

处理方向：

• 检查网线、交换机端口、无线连接。
• 检查 VLAN 是否正确。
• 检查 DHCP 服务是否正常。
• 静态地址场景检查地址、掩码、网关是否写错。

7.2 网关不通

表现：

• 本机有 IP，但 ping 网关 失败。
• ip neigh show 网关 为 FAILED。

排查方向：

• 本机 IP 和网关是否在同一网段。
• 交换机接入口 VLAN 是否正确。
• 网关接口是否在线。
• 是否存在端口安全、MAC 限制、无线隔离。

7.3 IP 通但域名不通

表现：

• ping 8.8.8.8 成功。
• dig example.com 或 ping example.com 失败。

排查：

resolvectl status
cat /etc/resolv.conf
dig @223.5.5.5 example.com +short
dig @8.8.8.8 example.com +short

处理方向：

• 修复 DNS 服务器配置。
• 检查 UDP/TCP 53 是否被拦截。
• 检查企业 DNS 转发器或递归解析器状态。

7.4 ping 通但端口不通

表现：

• ping 目标 IP 成功。
• curl -v 或业务连接超时。
• ss 看不到服务端端口监听，或客户端停留在 SYN-SENT。

排查：

ss -lntup
curl -v http://目标IP:端口
sudo tcpdump -i eth0 -nn 'host 目标IP and tcp'

处理方向：

• 服务未启动或监听地址不对。
• 主机防火墙未放行。
• 中间防火墙或安全组未放行。
• 回程路由错误。

7.5 TCP 能建立但应用异常

表现：

• TCP 连接 ESTABLISHED。
• HTTP 返回 403、404、500、502、504。
• TLS 握手失败或证书错误。

排查：

curl -vk https://example.com
openssl s_client -connect example.com:443 -servername example.com

处理方向：

• 检查反向代理路由。
• 检查证书链、SNI、主机名。
• 检查后端服务健康状态。
• 检查应用日志。

7.6 MTU 问题导致部分网站或 VPN 异常

表现：

• 小包 ping 通，大文件传输、HTTPS 或 VPN 访问异常。
• 某些站点正常，某些站点卡住。

排查：

ping -M do -s 1472 目标IP
ping -M do -s 1400 目标IP

处理方向：

• 检查 VPN、隧道、云网络封装带来的额外头部。
• 在隧道接口设置合适 MTU。
• 确保必要 ICMP 消息未被屏蔽。
• 对 TCP 场景可评估 MSS clamping。

7.7 ARP 冲突或网关 MAC 异常

表现：

• 同一 IP 对应多个 MAC。
• 网络时通时断。
• ip neigh 中网关 MAC 频繁变化。

排查：

ip neigh show
sudo tcpdump -i eth0 -nn arp

处理方向：

• 检查是否有重复 IP。
• 检查网关冗余协议是否正常，例如 VRRP/HSRP。
• 检查非法 DHCP、静态地址误配置或终端私接路由器。

8. 最佳实践

1. 排障按层推进

   • 先确认物理和链路，再看 IP、路由、端口，最后看应用。
   • 不要在网关都不通时先重启应用服务。

2. 保留基线

   • 记录正常时期的 ip addr、ip route、ip neigh、ss -lntup。
   • 网络变更前后对比基线，比临时猜测更可靠。

3. 抓包要有问题假设

   • 先写清楚要验证的是 DNS、TCP 握手、TLS 还是 HTTP。
   • 使用过滤条件缩小范围，避免抓到大量无关流量。

4. 防火墙策略写清楚方向

   • 明确源、目的、协议、端口和回程路径。
   • TCP 状态型防火墙通常自动允许回程，UDP 和 ICMP 策略需要单独确认。

5. 不要随意屏蔽 ICMP

   • ICMP 不只是 ping。
   • 路径 MTU、不可达反馈、TTL 超时诊断都依赖 ICMP。

6. 关注 IPv6

   • 现代系统常常默认启用 IPv6。
   • DNS 返回 AAAA 记录后，客户端可能优先尝试 IPv6。
   • IPv4 正常不代表 IPv6 路径也正常。

9. TCP/IP 的工程边界

TCP/IP 协议栈的学习重点不是把每个协议背下来，而是理解每个协议负责什么、不负责什么。边界清楚，排障时才不会把问题推给错误层级。

例如 IP 只负责尽力而为地把数据包送往目标，不承诺可靠到达；TCP 在 IP 之上补充可靠性，但也无法保证应用处理成功；DNS 能告诉客户端目标地址，却不能证明目标端口开放。把这些边界说清楚，是网络基础走向工程实践的关键。

10. TCP 连接生命周期

TCP 是排障中最常见的协议。理解连接生命周期，可以快速判断问题发生在客户端、路径、服务端还是应用。

建立连接

TCP 三次握手可以理解为：

客户端 -> 服务端：SYN
服务端 -> 客户端：SYN, ACK
客户端 -> 服务端：ACK

如果客户端只发出 SYN，没有收到 SYN/ACK，常见原因包括目标不可达、防火墙丢弃、服务未监听、回程路由错误、NAT 异常。若服务端返回 RST，通常说明目标可达但端口拒绝，可能是服务没监听或策略主动拒绝。

传输数据

连接建立后，TCP 通过序列号、确认号、窗口和重传机制保证字节流可靠。抓包时如果看到大量 Retransmission、Duplicate ACK、Zero Window，就说明传输层已经出现性能或可靠性问题。此时用户可能感知为网页慢、文件传输慢、接口偶发超时。

TCP 性能问题不一定是带宽不够。高延迟、丢包、窗口过小、中间设备限速、MTU/MSS 异常、服务器处理慢，都可能表现为传输慢。排查时要同时看网络指标和应用耗时。

关闭连接

TCP 连接关闭可能通过 FIN 正常关闭，也可能通过 RST 中断。FIN 表示一方不再发送数据，RST 通常表示异常中断或主动拒绝。大量 TIME_WAIT 不一定是故障，它是 TCP 正常关闭后的状态；但大量 CLOSE_WAIT 往往说明应用没有正确关闭连接，需要应用侧排查。

11. UDP 的正确使用场景

UDP 没有连接、没有重传、没有顺序保证，因此经常被误解为“不可靠所以不重要”。实际工程中，UDP 适合对实时性更敏感、能在应用层处理丢包或重传的场景，例如 DNS、DHCP、NTP、语音视频、部分游戏和监控遥测。

排查 UDP 时不能像 TCP 一样期待三次握手。nc -u 发出去没有响应，不一定说明端口关闭；要看应用是否有返回、服务端是否收到、网络设备是否允许 UDP、是否存在会话超时过短等问题。对于 DNS 这类协议，还要注意 UDP 53 和 TCP 53 都可能被使用，较大响应或区域传送可能走 TCP。

12. 抓包判断：从现象到协议字段

抓包时可以用下面的对应关系快速定位：

抓包要注意方向。如果只在客户端抓包，可能看不到服务端是否收到；如果只在服务端抓包，可能看不到中间设备是否丢弃。复杂问题最好在客户端、网关或防火墙、服务端三处取证，再对比时间线。

13. 案例：IP 通但域名不通

这是最常见的 TCP/IP 入门故障。现象是 ping 1.1.1.1 正常，但 ping example.com 或 curl https://example.com 失败。排查路径如下：

1. 查看本机 DNS 配置：resolvectl status 或 /etc/resolv.conf。
2. 指定 DNS 服务器查询：dig @1.1.1.1 example.com。
3. 检查 DNS 查询是否被防火墙拦截：UDP/TCP 53 是否允许。
4. 检查是否返回 IPv6 地址，而本机 IPv6 路径不可用。
5. 检查本地 hosts、浏览器 DoH、企业代理或安全客户端是否改写解析。

这个案例说明 DNS 虽然属于应用层，但它是大量网络访问的前置条件。排障记录中应区分“公网 IP 可达”和“域名解析可用”，不能把两者混为一谈。

14. 案例：小包正常，大包异常

另一个典型问题是 ping 小包正常，网页或 VPN 访问异常。这往往和 MTU、MSS、分片、ICMP 不可达被阻断有关。排查时可以从标准以太网 MTU 1500 推导：IPv4 ICMP 测试中，payload 1472 加上 IP 和 ICMP 头部 28 字节，正好接近 1500。

ping -M do -s 1472 <目标IP>
ping -M do -s 1400 <目标IP>

如果 1472 失败而 1400 成功，要继续检查路径中是否有 VPN、隧道、PPPoE、云专线、负载均衡或安全设备。解决方式可能是调整接口 MTU、配置 TCP MSS clamping，或允许必要的 ICMP 不可达消息，让路径 MTU 发现正常工作。

15. 生产环境中的 TCP/IP 基线

建议为关键服务器保留以下基线：

ip addr
ip route
ip neigh
ss -s
ss -lntup
sysctl net.ipv4.ip_forward
sysctl net.ipv4.tcp_congestion_control

基线不只是命令输出，还应记录采集时间、系统版本、网卡名称、默认网关、DNS、主要监听端口、是否启用 IPv6、是否存在策略路由和特殊 MTU。变更前后对比基线，可以快速发现“路由多了一条”“监听地址变了”“IPv6 优先级变化”“MTU 被改小”这类隐蔽问题。

16. TCP 状态与服务器侧排查

排查 TCP 服务时，ss 输出中的连接状态很有价值：

很多“端口不通”问题，服务端一条命令就能缩小范围：

ss -lntup | grep ':443'
ss -ant state syn-recv
ss -ant state close-wait

如果服务只监听 127.0.0.1:8080，外部访问必然失败；如果监听正常但防火墙没有会话，说明流量可能没到服务端；如果服务端已经收到连接但应用日志没有记录，请继续看代理、TLS 和应用入口。

17. NAT 与连接跟踪

NAT 是 TCP/IP 实践中最容易被忽略的部分。它会修改源地址、目的地址或端口，让多个内网主机共享出口，或把公网入口映射到内网服务。NAT 本身不是问题，但它会让排障变复杂：客户端看到的源地址、服务端看到的源地址、防火墙会话里的地址可能并不相同。

常见 NAT 类型包括：

• SNAT：修改源地址，常用于内网访问外网。
• DNAT：修改目的地址，常用于公网入口转发到内网服务。
• 端口映射：修改目的端口或源端口。
• 双向 NAT：同时处理源和目的，常见于地址重叠场景。

排查 NAT 时要问三个问题：转换前地址是什么，转换后地址是什么，回程是否能命中同一条会话。如果回程绕过了 NAT 设备，TCP 连接通常会失败。防火墙、负载均衡、云安全组和容器网络都可能引入 NAT，因此不要只看主机路由表。

18. IPv4 与 IPv6 双栈注意事项

现代系统经常同时启用 IPv4 和 IPv6。双栈环境中，应用访问一个域名时可能同时获得 A 记录和 AAAA 记录，客户端会根据系统策略选择优先尝试哪一个。如果 IPv6 地址可解析但路径不可用，用户可能感知为访问慢、偶发失败或首包延迟。

排查双栈问题时可以分别验证：

dig A example.com
dig AAAA example.com
ping -4 example.com
ping -6 example.com
curl -4 -I https://example.com
curl -6 -I https://example.com
ip -6 route

不要因为 IPv4 正常就断言网络正常。对于企业内网，若暂时没有完整 IPv6 规划，也要明确 DNS 是否返回 AAAA、终端是否启用 IPv6、代理和安全设备是否支持 IPv6 日志和策略。否则故障会以非常隐蔽的方式出现。

19. 协议栈学习自测

读完本篇后，可以用下面的问题检查理解是否到位：

1. 本机访问外网时，目的 IP 和目的 MAC 分别是谁？
2. 为什么 ARP 只解决同网段下一跳，不解决公网服务器 MAC？
3. TCP SYN 超时、RST、TLS 失败和 HTTP 500 分别说明什么层级的问题？
4. UDP 无响应时，为什么不能直接判断端口关闭？
5. DNS 返回 IPv6 地址但 IPv6 路径异常，会出现什么现象？
6. NAT 场景中，为什么必须确认回程路径？
7. MTU 问题为什么可能表现为“小包通、大包不通”？
8. CLOSE-WAIT 大量堆积时，为什么更像应用未关闭连接，而不是网络链路问题？

如果能用自己的实验或生产案例回答这些问题，说明已经不只是理解 TCP/IP 名词，而是具备了用协议栈分析真实问题的能力。

20. 防火墙和会话表怎么看

防火墙处理 TCP/IP 流量时，通常不只是看一条规则是否允许端口，还会维护会话状态。一次 TCP 连接需要去程和回程都能匹配同一条会话，才能稳定通信。若去程经过防火墙，回程绕开防火墙，状态型设备可能无法识别连接，表现为 SYN 重传、连接建立后立即中断或应用偶发超时。

排查防火墙时要记录：

这张表能避免“策略已经放行”这种不完整结论。策略放行只是条件之一，还要确认路由、NAT、会话和回程都正确。

21. 容器和虚拟化中的 TCP/IP

容器、虚拟机和云网络不会改变 TCP/IP 的基本规律，但会增加额外层次。容器可能通过 veth、bridge、iptables NAT、overlay 网络访问外部；虚拟机可能通过虚拟交换机、端口组、安全组和宿主机网桥转发；云主机可能同时受操作系统防火墙、安全组、路由表和负载均衡影响。

因此，排查容器网络时不能只看容器内：

ip netns list
docker network inspect <network>
ip link show type veth
iptables -t nat -L -n

要确认容器内地址、宿主机网桥、NAT 规则、宿主机路由、云安全组和目标服务是否一致。很多“容器无法访问外网”问题，根因不是应用，而是 IP 转发未开启、NAT 规则缺失、DNS 配置错误或宿主机防火墙拦截。

22. 最小排障记录模板

遇到 TCP/IP 问题时，可以使用下面模板：

现象：
源地址：
目的地址和端口：
DNS 解析结果：
本机地址和路由：
网关连通性：
ARP/邻居表：
TCP/UDP 测试结果：
抓包结论：
最近变更：
下一步责任人：

模板的作用是把主观描述变成协议证据。长期使用后，团队会逐渐形成自己的故障知识库：哪些问题常来自 DNS，哪些常来自 NAT，哪些常来自 MTU，哪些是应用连接泄漏。协议栈知识只有进入这种复盘记录，才算真正变成运维能力。

23. 如何判断问题已经离开网络层

网络排障也要知道何时停止。以下证据通常说明问题已经上移到应用或平台层：

• DNS 解析到预期地址。
• 客户端到目标 TCP 端口可以稳定建连。
• 抓包显示 TLS 握手完成。
• HTTP 请求到达反向代理或应用日志。
• 防火墙和负载均衡会话正常。
• 同一网络路径下其他接口正常，只有特定业务动作失败。

此时继续检查网线、网关、路由通常收益很低。更合理的下一步是查看应用错误码、认证系统、数据库连接、后端健康检查、缓存、队列和发布变更。网络团队可以把已经验证的 TCP/IP 证据交给应用团队，避免问题在团队之间循环。

反过来，如果应用团队只看到“请求没到日志”，也不能直接认定是网络故障。请求可能被反向代理拦截、TLS 终止失败、WAF 拒绝、负载均衡健康检查失败或域名解析到了错误入口。双方要围绕源、目的、端口、时间点和抓包证据对齐。

一个实用停止条件是：当你已经能证明数据包到达了应用入口，并且传输层没有重传、RST、超时或路径异常，就应该把主线交给应用、网关或认证系统继续分析。这样能避免网络排障无限扩大，也能保护现场处理节奏。交接时附上抓包摘要、连接测试和时间线，后续团队才能直接接力，减少重复验证和沟通成本，并形成清晰责任边界和复盘依据。后续复查时，团队能直接看到已验证证据、未验证假设、责任归属和关闭条件；如果同类故障再次出现，也能快速复用上一次的检查路径。

24. 总结

TCP/IP 协议栈是实际网络通信的工程基础。OSI 七层模型帮助我们建立概念框架，而 TCP/IP 四层模型帮助我们理解真实系统如何发送、路由、传输和交付数据。

本文的核心结论：

• IP 负责主机寻址和路由，不负责可靠传输。
• ARP 负责 IPv4 同网段下一跳 MAC 解析。
• ICMP 是网络控制和诊断协议，不只是 ping。
• TCP 提供可靠、有序的字节流，UDP 提供轻量的数据报。
• 端口用于标识进程，IP 用于标识主机，MAC 用于标识本地链路下一跳。
• 排障要从接口、路由、邻居表、DNS、端口、应用响应逐层验证。

下一篇《IP 地址与子网划分》会继续深入 IP 地址结构、CIDR、子网掩码、网段规划和地址计算，这是后续 VLAN、路由、ACL 和网络规划的基础。

参考资料

• RFC 9293 — Transmission Control Protocol (TCP)
• RFC 791 — Internet Protocol
• RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification
• RFC 768 — User Datagram Protocol
• RFC 1122 — Requirements for Internet Hosts
• RFC 1180 — TCP/IP Tutorial
• Linux iproute2 文档
• tcpdump 官方文档
• [验证环境：Ubuntu 24.04 / iproute2 6.x / tcpdump 4.99 / 2026-05-21]