简介面向面试突击与日常复习的计算机网络基础知识 PDF适合开发者、网络工程师及计算机专业学生。内容以网络模型为主线从 OSI 七层参考模型讲到 TCP/IP 四层模型并对比两套模型的差异随后系统梳理 TCP/IP 协议族涵盖 TCP 三次握手、四次挥手、TCP 状态机、TIME_WAIT 状态、端口号、超时重传与快速重传、TCP Header 结构、可靠传输、流量控制和拥塞控制同时覆盖 UDP、SCTP 及 IPv4、IPv6、ICMP、ARP、RARP、IGMP 等网络层协议。重点提示以问答形式呈现覆盖 OSI 与 TCP/IP 区别、TCP 与 UDP 区别等高频考点。资源共 1 个 PDF 文件压缩包约 2.08MB分节目录便于直接定位薄弱点。目前已有 969 人学习适合作为面试前的高频考点速查、课程复习提纲以及日常网络排错的参考索引能够帮助读者快速建立层次清晰的网络知识框架。1. 计算机网络基础知识先看你卡在哪一层经常有人问计算机网络能拿什么做比喻我一般说像快递IP 是门牌号MAC 是收件人签名路由器是分拣中心TCP 是带签收单的运输协议。比喻能让人记住概念但排障时推演不了。“连不上”可能是物理线缆坏了可能是 IP 配错也可能是 DNS 解析失败——三种原因的命令完全不同。真正能用来推演的是分层模型、子网计算、握手状态这些精确到字段的东西。这篇文章把计算机网络基础知识从“听懂了”压到“能动手”看完能解释一次网页访问的全过程也能在两分钟内说清“连不上”到底该查哪层。对刚入行的开发和运维、准备计算机网络期末或 408 复习的人都适用。2. 计算机网络基础知识的模型与数据链路分层、封装和网桥转发表2.1 为什么先分七层工作却按四层协议栈来OSI 七层模型是教学骨架TCP/IP 四层模型是实际跑路的协议栈。两者不冲突但必须知道差异在哪。OSI 把网络拆成物理、数据链路、网络、传输、会话、表示、应用七层每一层只干一件事TCP/IP 体系则合并了会话和表示把上层统一叫应用层底层就叫网络接口层。实际抓包时你只能看到四层以太网帧是链路层IP 包是网络层TCP/UDP 是传输层再往上全是应用层的字节流。分层价值的核心是“每层只按自己的规则理解数据”。链路层不关心上层是 IPv4 还是 IPv6IP 层不关心上层是 TCP 还是 UDP传输层不关心应用层是 HTTP 还是 SMTP。这种解耦带来的是独立演进IPv6 替换 IPv4 时TCP 几乎没改HTTP/3 把传输层从 TCP 换到 UDP 上的 QUIC但 IP 层动都没动。你查问题时也要按这个逻辑隔离先看链路通没通再看 IP 通没通最后才轮到端口和应用。2.2 一次访问的封装HTTP 报文怎么变成比特流数据从发送方应用出发每经过一层就被加一个头部这个过程叫封装。以浏览器访问一个网页为例应用层把数据交给传输层TCP 加上源端口、目标端口和序号网络层加上源 IP、目标 IP 和协议号链路层再加上源 MAC、目标 MAC 和帧校验。接收方按相反顺序一层层剥掉头部叫解封装。注意链路层封装的不是 IP 包本身而叫数据帧MTU 就定义在这一层——标准以太网帧最多承载 1500 字节的 IP 包超过就要分片。封装模型对应的排查意义ping只验证网络层通不通telnet ip port才验证传输层。很多新手在链路层都不通的时候去抓 HTTP 的报文方向就错了。物理层的检查手段是ethtool链路层的状态看ip link网络层看ip address传输层看ss和netstat应用层才轮得到curl和dig。2.3 网桥和交换机的转发表泛洪、转发和源地址学习网桥现在主要在交换机里是数据链路层的转发设备核心数据结构是转发表FDBForwarding Database记录 MAC 地址和端口的对应关系。转发表不是配置出来的是学出来的三条规则就能覆盖所有转发表题目收到帧时先把源 MAC 地址和入端口记进转发表这叫源地址学习。查目的 MAC 地址表里有对应端口就单播转发没有就向除入端口外的所有端口泛洪。广播帧和组播帧不查表一律泛洪。用一个典型题目验证交换机有 1、2、3 三个端口PC_A 接端口 1PC_B 接端口 2。PC_A 先发送帧给 PC_B。此刻转发表是空的交换机学不到目的地址所以泛洪到端口 2 和 3PC_B 收到并回帧。回帧到达时交换机已经在刚才收到了 PC_A 的 MAC 对应端口 1 的表项于是只向端口 1 转发不再泛洪。这个学习过程是有老化时间的默认 300 秒左右过期后表项被清掉再次通信又要先泛洪。所以“第一次 ping 慢、第二次快”常常不是网络不稳定而是 FDB 在重新学习。在 Linux 上查看二层表项用网桥工具集注意要区分二三层ip link show eth0 bridge fdb show dev eth0 ethtool eth0 | grep -E Speed|Link detected第一行看网卡物理状态和 MAC第二行看本机作为网桥时学到的 MAC 转发表第三行确认链路速度和对端是否识别。bridge fdb show输出里master br0表示该 MAC 是从网桥 br0 学到的self表示网卡自己维护的表项。如果Link detected: no后面所有排查都白费先查网线、光模块和交换机端口。3. IP 地址结构与子网划分从分类编制到手工计算3.1 IPv4 地址的构成和那三段私有网段IPv4 地址是 32 位二进制日常写成点分十进制。为了可读性早期按前几位划分了 A、B、C 类地址A 类前 8 位是网络号B 类前 16 位C 类前 24 位。分类编制的缺点是粒度太粗申请一个 B 类等于拿到 65534 个可用地址多数用不完。所以 1993 年后改用 CIDR无类别域间路由不再按类分配而是用前缀长度表示网络位个数例如192.168.1.0/24表示前 24 位是网络号。私有地址段必须背下来因为绝大多数公司内网都跑在下面三段地址段CIDR可用主机数10.0.0.0 ~ 10.255.255.25510.0.0.0/8约 1677 万172.16.0.0 ~ 172.31.255.255172.16.0.0/12约 104 万192.168.0.0 ~ 192.168.255.255192.168.0.0/1665534除了这三段还要认识 169.254.0.0/16。这是 APIPA 地址段DHCP 失败时系统自动分配的看到本机地址是 169.254.x.x 基本可以断定没拿到 DHCP 地址先查 DHCP 服务或交换机端口。环回地址 127.0.0.1/8 永远只指向本机。3.2 子网掩码计算两种方法一个快一个稳子网掩码决定一个 IP 里哪些位是网络号。掩码的二进制形式下网络位全 1主机位全 0。比如/26对应掩码255.255.255.192二进制最后 8 位是11000000前两位是子网位后 6 位是主机位每个子网有 64 个地址可用的主机地址是 62 个去掉网络地址和广播地址。快速算法256 - 掩码最后一个非 255 的十进制数 每个子网的地址块大小。掩码255.255.255.192最后一个非 255 段是 192256 - 192 64所以块大小是 64。给定192.168.1.137/26按 64 为块划分0-63、64-127、128-191、192-255137 落在 128-191 块网络地址就是 128广播地址是 191可用主机是 129 到 190。这个方法快但只对非 255 段在最后一个位置的掩码有效。稳妥的办法是转二进制做与运算。把 IP 和掩码都写成二进制逐位做 AND得到的 32 位结果就是网络地址把网络地址的主机位全部置 1 就是广播地址。我一般建议熟练后用 Python 校验避免心算出错import ipaddress net ipaddress.ip_network(192.168.1.128/26, strictFalse) print(network:, net.network_address) print(broadcast:, net.broadcast_address) print(usable:, list(net.hosts())[0], ~, list(net.hosts())[-1]) for sub in ipaddress.ip_network(192.168.1.0/24).subnets(new_prefix26): print(sub)strictFalse允许传入主机地址而不报错自动取网络地址subnets(new_prefix26)把一个大网段切成恰好 4 个 /26 子网。写脚本排查分配冲突时这个模块比手背掩码表可靠。3.3 路由决策与 ARP同子网和跨子网只差一个判断一台主机要发包先要做一次本地路由决策目标 IP 跟自己的掩码做与运算如果结果等于自己的网络地址说明目标在同子网直接查 ARP 拿目标 MAC如果不等就把包交给默认网关目标是网关的 MAC。这里的核心误区是跨子网通信时IP 包的目标地址始终是最终目的地址但帧的目标 MAC 一直是网关的 MAC。抓包看到源 IP 是你的、目的 IP 是远程的但 MAC 是网关的这不是错误是正常的。ARP 缓存用ip neigh show查看条目状态为REACHABLE表示近期通信过STALE表示超时待确认。排障时如果看到网关 ARP 条目是FAILED说明二层就找不到网关查网线和交换机端口如果网关能 ping 通但外网不通问题多半在网关的上联或 NAT。默认网关的配置在哪看一条命令解决ip route show ip route add default via 192.168.1.1 dev eth0ip route第一行是默认路由指明目标不在路由表时交给谁add default via是临时添加默认网关重启失效。注意 Linux 下ping不通外网但ping通网关时优先怀疑两条网关没配 NAT或者防火墙拦了转发。这和路由器策略有关如果公司网络由别人管理直接把“二层通三层半通”的现象反馈给网络组比反复 ping 更高效。4. TCP 与 UDP 的握手、重传和时间等待状态4.1 TCP 和 UDP 各管哪摊事TCP 是面向连接的提供序号确认、重传、流量控制和拥塞控制UDP 是无连接的只负责把数据报扔出去不保证顺序和到达。需要可靠传输的场景用 TCP比如 HTTP、SMTP、MySQL实时性和低延迟优先的场景用 UDP比如 DNS 查询、VoIP、游戏帧同步。近年来 QUICHTTP/3把传输层搬到了 UDP 上可靠性在应用层实现这说明协议的边界不是死的需求变了协议可以改。抓包时识别 TCP 和 UDP 最直观TCP 有 Flags 字段和 32 位序号UDP 头只有 8 字节。两张协议一张表对比更清楚特性TCPUDP连接状态有连接无连接可靠性序号ACK重传不保证头部大小20-60 字节8 字节典型场景HTTP、MySQL、SSHDNS、RTP、QUIC4.2 三次握手seq、ack 与 SYN 报文建立 TCP 连接要交换三个报文。客户端先发 SYN携带初始序号 seqx服务端回 SYNACK携带自己的初始序号 seqy同时确认号 ackx1客户端再发 ACK确认号 acky1。这里最关键的是序号和确认号的关系确认号永远表示“我期望收到的下一个字节序号”所以服务端会回 ackx1表示已经收到了 x 序号的数据期望下一个是 x1。用 tcpdump 看最干净的方式是只抓带 SYN 标志的包tcpdump -i eth0 -nn tcp[tcpflags] (tcp-syn) ! 0 -c 10-nn不解析域名和服务名输出纯 IP 和端口tcp[tcpflags]是 BPF 过滤器语法从 TCP 头的 flags 字段取值做掩码判断。-c 10收到 10 个包自动停。抓到三段分别是S、S.、.S是 SYNS.是 SYNACK.是普通 ACK。如果只有 SYN 发出而永远不见 SYNACK检查目标端口是否监听、防火墙是否丢弃。测试端口是否监听推荐直接用ssss -ltn | grep :8080-l只看监听端口-t只看 TCP-n不解析服务名。输出为空说明没有进程监听 8080这就是最常见的“端口不通”真相——根本没有服务在等。4.3 四次挥手与 TIME_WAIT端口用完的真凶TCP 关闭连接是四次交互主动关闭方发 FIN被动方回 ACK被动方再发自己的 FIN主动方最后回 ACK。主动关闭方发完最后一个 ACK 后不会立刻释放连接而是进入 TIME_WAIT 状态默认等待 2 个 MSL最长报文段寿命Linux 里约 60 秒。TIME_WAIT 存在的理由有两个确保最后的 ACK 能送到对方以及让旧连接的重复报文在网络上消失避免干扰新连接。高并发服务器上 TIME_WAIT 堆积是最常见的问题。大量短连接请求后ss -tan会看到几十万个 TIME_WAIT 条目新连接因为端口用尽而被拒绝。生产环境我一般先查分布再调参ss -tan state time-wait | wc -l ss -tan state established | wc -l常用调优参数是启用端口复用和减小 FIN 等待周期sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_fin_timeout15tcp_tw_reuse允许客户端在安全条件下复用 TIME_WAIT 状态的连接这里的“安全条件”是保证旧连接的包已经过期tcp_fin_timeout把 TIME_WAIT 的保持时间缩短到 15 秒。改之前先确认升级方案纯靠调参数压 TIME_WAIT 是治标HTTP 长连接和连接池才是治本。4.4 拥塞控制与重传什么时候是网络真丢了TCP 的可靠性依赖确认与重传常用的拥塞控制算法有 CUBICLinux 默认、BBR 等核心都是维护一个拥塞窗口 cwnd决定不用等 ACK 就能连续发多少数据。当网络上出现丢包TCP 会检测到重传然后降低窗口表现为吞吐突然掉一半。tcpdump 里看到下面这行就说明发生了重传tcpdump -i eth0 -nn tcp[13] 4 ! 0 -c 5过滤器tcp[13] 4 ! 0提取的是 TCP flags 的第 13 字节掩码 4 对应 RST 标志。实际排障中我常用ss -s看整体统计如果retrans比例超过 1%先查链路的丢包率而不是查应用性能。区分“网络丢包”和“应用慢”的一个经典手段同一时刻 ping 网关和 ping 对端服务器如果网关 RTT 正常而对端丢包问题在中间链路或对端限速如果网关都丢包先换跳线再说。你调什么应用参数都没用。5. DNS 与 HTTP 的应用层排错输入域名到页面渲染的完整链路5.1 DNS 解析链路与缓存时效先把解析链看清DNS 是电话簿把域名翻译成 IP。完整解析过程是浏览器查本地缓存没有再查系统解析器缓存还没有就交给/etc/resolv.conf里配置的递归解析器。递归解析器替你去根服务器、顶级域服务器如.com、权威服务器逐级查询最终拿到结果。你平时感觉“DNS 解析一下就完成”其实背后可能跑了二三十个包。排查 DNS 最常用的是dig。这里要区分两个查询对象一个是查公共 DNS 服务器一个是查权威解析链路dig 223.5.5.5 www.example.com A short dig trace www.example.com | head -40第一个命令指定用公共递归 DNS223.5.5.5查询排除本机 DNS 配置问题short只输出结果。第二个命令trace从根服务器开始逐级追踪能看到每一步返回哪个服务器。如果第一个能返回 IP、用系统默认 DNS 不能就是/etc/resolv.conf配置的问题如果trace在漫游到权威服务器时超时是域名服务商侧的问题和你本机无关。缓存对排障的影响经常被忽视。DNS 记录有 TTL递归解析器会在 TTL 内缓存结果。域名解析变更后全世界生效不一致是正常现象因为 TTL 还没过期。排障时如果新解析指到新 IP 但本机还连旧 IP用resolvectl flush-caches清缓存不要责怪网络。5.2 HTTP 请求与状态码分类从报文结构到返回判断HTTP 请求由请求行、请求头、空行、请求体组成响应由状态行、响应头、空行、响应体组成。排障时最直接的信息是状态码五类要背清楚状态码含义常见场景2xx成功200 正常206 断点续传3xx重定向301 永久跳转302 临时跳转304 缓存未修改4xx客户端错误401 未认证403 无权限404 不存在5xx服务端错误502 网关拿不到响应503 过载504 网关超时504 和 502 在排 CDN/网关环境时最容易误判504 是网关等上游超时408 才是请求方超时。要确认哪一层出的问题必须看实际响应而不是看客户端报什么错。下面这条命令把 HTTP 的完整交互过程打到标准错误输出curl -v -o /dev/null -I --max-time 10 https://www.example.com/ 21 | head -40-v打印 TLS 握手和请求头的全过程-o /dev/null丢弃响应体-I发送 HEAD 请求只取响应头--max-time 10限制总时长超过 10 秒退出。输出里能看到Connected to证明 TCP 建连成功SSL connection using TLS到协议版本信息HTTP/1.1 200 OK是服务端的最终响应。如果卡在对Trying那一行之后没有Connected说明 TCP 层都过不去这时候回去查第 4 章的ss命令。5.3 用 dig 和 curl 组合定位分层故障一个网页打不开的排查顺序应该是ping网关验证链路dig确认域名解析curl验证整个 HTTP 链路。三者都通过才能把锅丢给浏览器。我遇到的一个高频伪故障是服务器明明活着但业务监控里显示大量 5xx剥掉curl -v看到响应头里Via:字段是缓存节点真实后端在另一个机房——这是网关层转发导致的不是服务端自身问题。排查状态码永远要抓一次原始响应不能只看监控聚合。curl 这里最大的价值是能控制连接细节。--resolve参数可以绕过 DNS 强制指定域名解析到某 IP这在灰度发布时特别有用新服务还没切换 DNS先手动指过去验证。比如线上域名 a.example.com 没有解析到测试机但测试机就是这个域名的真实后端可以先加一条本机 hosts 或业务上用—resolve精确定位问题在 DNS 层还是业务层。6. 一份能直接跑的联动检查脚本把网络基础知识串成操作动作6.1 脚本模板与输出解释前面讲的都是孤立命令实战里更希望一键拿到全链路状态。下面这段脚本是我平时定位“连不上”类问题时的简化版#!/usr/bin/env bash set -u GW$(ip route | awk /default/ {print $3; exit}) echo [1] link; ip -br link show | grep -v DOWN echo [2] ip; ip -4 -br addr show | grep -v ^lo echo [3] route; ip route echo [4] gateway; ping -c 2 -W 1 $GW echo [5] dns; dig 223.5.5.5 short A www.example.com echo [6] http; curl -sS -o /dev/null -w %{http_code} %{time_total}s\n http://www.example.com/输出第一行确认网卡 UP第二行确认拿到合法 IP出现 169.254 段直接报警第三行看默认网关第四行ping网关验证二层到三层第五行走公共 DNS 验证解析链路第六行用-w自定义输出把 HTTP 状态码和总耗时打出来。-W 1把 ping 超时压到 1 秒避免脚本卡死set -u让未定义变量直接报错退出防止GW为空时执行一个奇怪的命令。6.2 三个我见过最容易误判的检查位置第一容易误判的是“IP 能 ping 通就认为网络没问题”。ping 只验证 ICMP 和路由不验证端口。服务端防火墙往往放行 ICMP 但拦截特定 TCP 端口这时候要改用nc -zv或curl。第二个误判点是不看 MTU。网络基本配置全部正常但大包传输失败而小包正常多半是 MTU 不一致用ping -M do -s 1472测试。第三个误判点是只查一方。TCP 连接是双向的服务器回包路径不通你从客户端看就是连接超时但抓包全在客户端永远看不到问题。正确做法是客户端和服务端同时 tcpdump两边各抓一份才能判断丢在哪一段。回到最开头的比喻快递说“派送中”不代表签收了网络也一样。客户端发出 SYN 只是故事的一半另一半在回程路径上。本文还有配套的精品资源点击获取
简介面向面试突击与日常复习的计算机网络基础知识 PDF适合开发者、网络工程师及计算机专业学生。内容以网络模型为主线从 OSI 七层参考模型讲到 TCP/IP 四层模型并对比两套模型的差异随后系统梳理 TCP/IP 协议族涵盖 TCP 三次握手、四次挥手、TCP 状态机、TIME_WAIT 状态、端口号、超时重传与快速重传、TCP Header 结构、可靠传输、流量控制和拥塞控制同时覆盖 UDP、SCTP 及 IPv4、IPv6、ICMP、ARP、RARP、IGMP 等网络层协议。重点提示以问答形式呈现覆盖 OSI 与 TCP/IP 区别、TCP 与 UDP 区别等高频考点。资源共 1 个 PDF 文件压缩包约 2.08MB分节目录便于直接定位薄弱点。目前已有 969 人学习适合作为面试前的高频考点速查、课程复习提纲以及日常网络排错的参考索引能够帮助读者快速建立层次清晰的网络知识框架。1. 计算机网络基础知识先看你卡在哪一层经常有人问计算机网络能拿什么做比喻我一般说像快递IP 是门牌号MAC 是收件人签名路由器是分拣中心TCP 是带签收单的运输协议。比喻能让人记住概念但排障时推演不了。“连不上”可能是物理线缆坏了可能是 IP 配错也可能是 DNS 解析失败——三种原因的命令完全不同。真正能用来推演的是分层模型、子网计算、握手状态这些精确到字段的东西。这篇文章把计算机网络基础知识从“听懂了”压到“能动手”看完能解释一次网页访问的全过程也能在两分钟内说清“连不上”到底该查哪层。对刚入行的开发和运维、准备计算机网络期末或 408 复习的人都适用。2. 计算机网络基础知识的模型与数据链路分层、封装和网桥转发表2.1 为什么先分七层工作却按四层协议栈来OSI 七层模型是教学骨架TCP/IP 四层模型是实际跑路的协议栈。两者不冲突但必须知道差异在哪。OSI 把网络拆成物理、数据链路、网络、传输、会话、表示、应用七层每一层只干一件事TCP/IP 体系则合并了会话和表示把上层统一叫应用层底层就叫网络接口层。实际抓包时你只能看到四层以太网帧是链路层IP 包是网络层TCP/UDP 是传输层再往上全是应用层的字节流。分层价值的核心是“每层只按自己的规则理解数据”。链路层不关心上层是 IPv4 还是 IPv6IP 层不关心上层是 TCP 还是 UDP传输层不关心应用层是 HTTP 还是 SMTP。这种解耦带来的是独立演进IPv6 替换 IPv4 时TCP 几乎没改HTTP/3 把传输层从 TCP 换到 UDP 上的 QUIC但 IP 层动都没动。你查问题时也要按这个逻辑隔离先看链路通没通再看 IP 通没通最后才轮到端口和应用。2.2 一次访问的封装HTTP 报文怎么变成比特流数据从发送方应用出发每经过一层就被加一个头部这个过程叫封装。以浏览器访问一个网页为例应用层把数据交给传输层TCP 加上源端口、目标端口和序号网络层加上源 IP、目标 IP 和协议号链路层再加上源 MAC、目标 MAC 和帧校验。接收方按相反顺序一层层剥掉头部叫解封装。注意链路层封装的不是 IP 包本身而叫数据帧MTU 就定义在这一层——标准以太网帧最多承载 1500 字节的 IP 包超过就要分片。封装模型对应的排查意义ping只验证网络层通不通telnet ip port才验证传输层。很多新手在链路层都不通的时候去抓 HTTP 的报文方向就错了。物理层的检查手段是ethtool链路层的状态看ip link网络层看ip address传输层看ss和netstat应用层才轮得到curl和dig。2.3 网桥和交换机的转发表泛洪、转发和源地址学习网桥现在主要在交换机里是数据链路层的转发设备核心数据结构是转发表FDBForwarding Database记录 MAC 地址和端口的对应关系。转发表不是配置出来的是学出来的三条规则就能覆盖所有转发表题目收到帧时先把源 MAC 地址和入端口记进转发表这叫源地址学习。查目的 MAC 地址表里有对应端口就单播转发没有就向除入端口外的所有端口泛洪。广播帧和组播帧不查表一律泛洪。用一个典型题目验证交换机有 1、2、3 三个端口PC_A 接端口 1PC_B 接端口 2。PC_A 先发送帧给 PC_B。此刻转发表是空的交换机学不到目的地址所以泛洪到端口 2 和 3PC_B 收到并回帧。回帧到达时交换机已经在刚才收到了 PC_A 的 MAC 对应端口 1 的表项于是只向端口 1 转发不再泛洪。这个学习过程是有老化时间的默认 300 秒左右过期后表项被清掉再次通信又要先泛洪。所以“第一次 ping 慢、第二次快”常常不是网络不稳定而是 FDB 在重新学习。在 Linux 上查看二层表项用网桥工具集注意要区分二三层ip link show eth0 bridge fdb show dev eth0 ethtool eth0 | grep -E Speed|Link detected第一行看网卡物理状态和 MAC第二行看本机作为网桥时学到的 MAC 转发表第三行确认链路速度和对端是否识别。bridge fdb show输出里master br0表示该 MAC 是从网桥 br0 学到的self表示网卡自己维护的表项。如果Link detected: no后面所有排查都白费先查网线、光模块和交换机端口。3. IP 地址结构与子网划分从分类编制到手工计算3.1 IPv4 地址的构成和那三段私有网段IPv4 地址是 32 位二进制日常写成点分十进制。为了可读性早期按前几位划分了 A、B、C 类地址A 类前 8 位是网络号B 类前 16 位C 类前 24 位。分类编制的缺点是粒度太粗申请一个 B 类等于拿到 65534 个可用地址多数用不完。所以 1993 年后改用 CIDR无类别域间路由不再按类分配而是用前缀长度表示网络位个数例如192.168.1.0/24表示前 24 位是网络号。私有地址段必须背下来因为绝大多数公司内网都跑在下面三段地址段CIDR可用主机数10.0.0.0 ~ 10.255.255.25510.0.0.0/8约 1677 万172.16.0.0 ~ 172.31.255.255172.16.0.0/12约 104 万192.168.0.0 ~ 192.168.255.255192.168.0.0/1665534除了这三段还要认识 169.254.0.0/16。这是 APIPA 地址段DHCP 失败时系统自动分配的看到本机地址是 169.254.x.x 基本可以断定没拿到 DHCP 地址先查 DHCP 服务或交换机端口。环回地址 127.0.0.1/8 永远只指向本机。3.2 子网掩码计算两种方法一个快一个稳子网掩码决定一个 IP 里哪些位是网络号。掩码的二进制形式下网络位全 1主机位全 0。比如/26对应掩码255.255.255.192二进制最后 8 位是11000000前两位是子网位后 6 位是主机位每个子网有 64 个地址可用的主机地址是 62 个去掉网络地址和广播地址。快速算法256 - 掩码最后一个非 255 的十进制数 每个子网的地址块大小。掩码255.255.255.192最后一个非 255 段是 192256 - 192 64所以块大小是 64。给定192.168.1.137/26按 64 为块划分0-63、64-127、128-191、192-255137 落在 128-191 块网络地址就是 128广播地址是 191可用主机是 129 到 190。这个方法快但只对非 255 段在最后一个位置的掩码有效。稳妥的办法是转二进制做与运算。把 IP 和掩码都写成二进制逐位做 AND得到的 32 位结果就是网络地址把网络地址的主机位全部置 1 就是广播地址。我一般建议熟练后用 Python 校验避免心算出错import ipaddress net ipaddress.ip_network(192.168.1.128/26, strictFalse) print(network:, net.network_address) print(broadcast:, net.broadcast_address) print(usable:, list(net.hosts())[0], ~, list(net.hosts())[-1]) for sub in ipaddress.ip_network(192.168.1.0/24).subnets(new_prefix26): print(sub)strictFalse允许传入主机地址而不报错自动取网络地址subnets(new_prefix26)把一个大网段切成恰好 4 个 /26 子网。写脚本排查分配冲突时这个模块比手背掩码表可靠。3.3 路由决策与 ARP同子网和跨子网只差一个判断一台主机要发包先要做一次本地路由决策目标 IP 跟自己的掩码做与运算如果结果等于自己的网络地址说明目标在同子网直接查 ARP 拿目标 MAC如果不等就把包交给默认网关目标是网关的 MAC。这里的核心误区是跨子网通信时IP 包的目标地址始终是最终目的地址但帧的目标 MAC 一直是网关的 MAC。抓包看到源 IP 是你的、目的 IP 是远程的但 MAC 是网关的这不是错误是正常的。ARP 缓存用ip neigh show查看条目状态为REACHABLE表示近期通信过STALE表示超时待确认。排障时如果看到网关 ARP 条目是FAILED说明二层就找不到网关查网线和交换机端口如果网关能 ping 通但外网不通问题多半在网关的上联或 NAT。默认网关的配置在哪看一条命令解决ip route show ip route add default via 192.168.1.1 dev eth0ip route第一行是默认路由指明目标不在路由表时交给谁add default via是临时添加默认网关重启失效。注意 Linux 下ping不通外网但ping通网关时优先怀疑两条网关没配 NAT或者防火墙拦了转发。这和路由器策略有关如果公司网络由别人管理直接把“二层通三层半通”的现象反馈给网络组比反复 ping 更高效。4. TCP 与 UDP 的握手、重传和时间等待状态4.1 TCP 和 UDP 各管哪摊事TCP 是面向连接的提供序号确认、重传、流量控制和拥塞控制UDP 是无连接的只负责把数据报扔出去不保证顺序和到达。需要可靠传输的场景用 TCP比如 HTTP、SMTP、MySQL实时性和低延迟优先的场景用 UDP比如 DNS 查询、VoIP、游戏帧同步。近年来 QUICHTTP/3把传输层搬到了 UDP 上可靠性在应用层实现这说明协议的边界不是死的需求变了协议可以改。抓包时识别 TCP 和 UDP 最直观TCP 有 Flags 字段和 32 位序号UDP 头只有 8 字节。两张协议一张表对比更清楚特性TCPUDP连接状态有连接无连接可靠性序号ACK重传不保证头部大小20-60 字节8 字节典型场景HTTP、MySQL、SSHDNS、RTP、QUIC4.2 三次握手seq、ack 与 SYN 报文建立 TCP 连接要交换三个报文。客户端先发 SYN携带初始序号 seqx服务端回 SYNACK携带自己的初始序号 seqy同时确认号 ackx1客户端再发 ACK确认号 acky1。这里最关键的是序号和确认号的关系确认号永远表示“我期望收到的下一个字节序号”所以服务端会回 ackx1表示已经收到了 x 序号的数据期望下一个是 x1。用 tcpdump 看最干净的方式是只抓带 SYN 标志的包tcpdump -i eth0 -nn tcp[tcpflags] (tcp-syn) ! 0 -c 10-nn不解析域名和服务名输出纯 IP 和端口tcp[tcpflags]是 BPF 过滤器语法从 TCP 头的 flags 字段取值做掩码判断。-c 10收到 10 个包自动停。抓到三段分别是S、S.、.S是 SYNS.是 SYNACK.是普通 ACK。如果只有 SYN 发出而永远不见 SYNACK检查目标端口是否监听、防火墙是否丢弃。测试端口是否监听推荐直接用ssss -ltn | grep :8080-l只看监听端口-t只看 TCP-n不解析服务名。输出为空说明没有进程监听 8080这就是最常见的“端口不通”真相——根本没有服务在等。4.3 四次挥手与 TIME_WAIT端口用完的真凶TCP 关闭连接是四次交互主动关闭方发 FIN被动方回 ACK被动方再发自己的 FIN主动方最后回 ACK。主动关闭方发完最后一个 ACK 后不会立刻释放连接而是进入 TIME_WAIT 状态默认等待 2 个 MSL最长报文段寿命Linux 里约 60 秒。TIME_WAIT 存在的理由有两个确保最后的 ACK 能送到对方以及让旧连接的重复报文在网络上消失避免干扰新连接。高并发服务器上 TIME_WAIT 堆积是最常见的问题。大量短连接请求后ss -tan会看到几十万个 TIME_WAIT 条目新连接因为端口用尽而被拒绝。生产环境我一般先查分布再调参ss -tan state time-wait | wc -l ss -tan state established | wc -l常用调优参数是启用端口复用和减小 FIN 等待周期sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_fin_timeout15tcp_tw_reuse允许客户端在安全条件下复用 TIME_WAIT 状态的连接这里的“安全条件”是保证旧连接的包已经过期tcp_fin_timeout把 TIME_WAIT 的保持时间缩短到 15 秒。改之前先确认升级方案纯靠调参数压 TIME_WAIT 是治标HTTP 长连接和连接池才是治本。4.4 拥塞控制与重传什么时候是网络真丢了TCP 的可靠性依赖确认与重传常用的拥塞控制算法有 CUBICLinux 默认、BBR 等核心都是维护一个拥塞窗口 cwnd决定不用等 ACK 就能连续发多少数据。当网络上出现丢包TCP 会检测到重传然后降低窗口表现为吞吐突然掉一半。tcpdump 里看到下面这行就说明发生了重传tcpdump -i eth0 -nn tcp[13] 4 ! 0 -c 5过滤器tcp[13] 4 ! 0提取的是 TCP flags 的第 13 字节掩码 4 对应 RST 标志。实际排障中我常用ss -s看整体统计如果retrans比例超过 1%先查链路的丢包率而不是查应用性能。区分“网络丢包”和“应用慢”的一个经典手段同一时刻 ping 网关和 ping 对端服务器如果网关 RTT 正常而对端丢包问题在中间链路或对端限速如果网关都丢包先换跳线再说。你调什么应用参数都没用。5. DNS 与 HTTP 的应用层排错输入域名到页面渲染的完整链路5.1 DNS 解析链路与缓存时效先把解析链看清DNS 是电话簿把域名翻译成 IP。完整解析过程是浏览器查本地缓存没有再查系统解析器缓存还没有就交给/etc/resolv.conf里配置的递归解析器。递归解析器替你去根服务器、顶级域服务器如.com、权威服务器逐级查询最终拿到结果。你平时感觉“DNS 解析一下就完成”其实背后可能跑了二三十个包。排查 DNS 最常用的是dig。这里要区分两个查询对象一个是查公共 DNS 服务器一个是查权威解析链路dig 223.5.5.5 www.example.com A short dig trace www.example.com | head -40第一个命令指定用公共递归 DNS223.5.5.5查询排除本机 DNS 配置问题short只输出结果。第二个命令trace从根服务器开始逐级追踪能看到每一步返回哪个服务器。如果第一个能返回 IP、用系统默认 DNS 不能就是/etc/resolv.conf配置的问题如果trace在漫游到权威服务器时超时是域名服务商侧的问题和你本机无关。缓存对排障的影响经常被忽视。DNS 记录有 TTL递归解析器会在 TTL 内缓存结果。域名解析变更后全世界生效不一致是正常现象因为 TTL 还没过期。排障时如果新解析指到新 IP 但本机还连旧 IP用resolvectl flush-caches清缓存不要责怪网络。5.2 HTTP 请求与状态码分类从报文结构到返回判断HTTP 请求由请求行、请求头、空行、请求体组成响应由状态行、响应头、空行、响应体组成。排障时最直接的信息是状态码五类要背清楚状态码含义常见场景2xx成功200 正常206 断点续传3xx重定向301 永久跳转302 临时跳转304 缓存未修改4xx客户端错误401 未认证403 无权限404 不存在5xx服务端错误502 网关拿不到响应503 过载504 网关超时504 和 502 在排 CDN/网关环境时最容易误判504 是网关等上游超时408 才是请求方超时。要确认哪一层出的问题必须看实际响应而不是看客户端报什么错。下面这条命令把 HTTP 的完整交互过程打到标准错误输出curl -v -o /dev/null -I --max-time 10 https://www.example.com/ 21 | head -40-v打印 TLS 握手和请求头的全过程-o /dev/null丢弃响应体-I发送 HEAD 请求只取响应头--max-time 10限制总时长超过 10 秒退出。输出里能看到Connected to证明 TCP 建连成功SSL connection using TLS到协议版本信息HTTP/1.1 200 OK是服务端的最终响应。如果卡在对Trying那一行之后没有Connected说明 TCP 层都过不去这时候回去查第 4 章的ss命令。5.3 用 dig 和 curl 组合定位分层故障一个网页打不开的排查顺序应该是ping网关验证链路dig确认域名解析curl验证整个 HTTP 链路。三者都通过才能把锅丢给浏览器。我遇到的一个高频伪故障是服务器明明活着但业务监控里显示大量 5xx剥掉curl -v看到响应头里Via:字段是缓存节点真实后端在另一个机房——这是网关层转发导致的不是服务端自身问题。排查状态码永远要抓一次原始响应不能只看监控聚合。curl 这里最大的价值是能控制连接细节。--resolve参数可以绕过 DNS 强制指定域名解析到某 IP这在灰度发布时特别有用新服务还没切换 DNS先手动指过去验证。比如线上域名 a.example.com 没有解析到测试机但测试机就是这个域名的真实后端可以先加一条本机 hosts 或业务上用—resolve精确定位问题在 DNS 层还是业务层。6. 一份能直接跑的联动检查脚本把网络基础知识串成操作动作6.1 脚本模板与输出解释前面讲的都是孤立命令实战里更希望一键拿到全链路状态。下面这段脚本是我平时定位“连不上”类问题时的简化版#!/usr/bin/env bash set -u GW$(ip route | awk /default/ {print $3; exit}) echo [1] link; ip -br link show | grep -v DOWN echo [2] ip; ip -4 -br addr show | grep -v ^lo echo [3] route; ip route echo [4] gateway; ping -c 2 -W 1 $GW echo [5] dns; dig 223.5.5.5 short A www.example.com echo [6] http; curl -sS -o /dev/null -w %{http_code} %{time_total}s\n http://www.example.com/输出第一行确认网卡 UP第二行确认拿到合法 IP出现 169.254 段直接报警第三行看默认网关第四行ping网关验证二层到三层第五行走公共 DNS 验证解析链路第六行用-w自定义输出把 HTTP 状态码和总耗时打出来。-W 1把 ping 超时压到 1 秒避免脚本卡死set -u让未定义变量直接报错退出防止GW为空时执行一个奇怪的命令。6.2 三个我见过最容易误判的检查位置第一容易误判的是“IP 能 ping 通就认为网络没问题”。ping 只验证 ICMP 和路由不验证端口。服务端防火墙往往放行 ICMP 但拦截特定 TCP 端口这时候要改用nc -zv或curl。第二个误判点是不看 MTU。网络基本配置全部正常但大包传输失败而小包正常多半是 MTU 不一致用ping -M do -s 1472测试。第三个误判点是只查一方。TCP 连接是双向的服务器回包路径不通你从客户端看就是连接超时但抓包全在客户端永远看不到问题。正确做法是客户端和服务端同时 tcpdump两边各抓一份才能判断丢在哪一段。回到最开头的比喻快递说“派送中”不代表签收了网络也一样。客户端发出 SYN 只是故事的一半另一半在回程路径上。本文还有配套的精品资源点击获取
