计算机网络核心知识梳理：分层模型、IP计算与排障实战

很多刚接触计算机网络的人都有同感：协议名一堆，分层看了就忘，ping通了但网页还是打不开，抓包抓了也不懂看。这篇内容就是一次针对计算机网络核心知识体系的系统梳理，聚焦在网络到底怎么运转、IP和子网怎么算、TCP为什么要三次握手、日常排障用什么命令这些真正实用的问题上。无论你是准备面试的在校生、刚转行做运维或开发的新人，还是想补一补网络基础的产品、测试同学，这套从分层模型到实操排查的路径，能帮你少走不少弯路。

我最早啃网络的时候，也是先从背七层模型开始的，后来才发现，真正让我把网络从“概念”变成“工具”的，是亲手用命令行、抓包和子网计算把每个抽象层落到具体场景里。所以这篇内容也会按这个思路展开：先建立整体认知，再逐个拆解IP、传输层、应用层，最后进入用工具排查问题的实战环节。

1. 先从整体上搞清楚：计算机网络到底是怎么回事

1.1 网络的本质：端到端的“快递系统”

计算机网络听起来玄，本质就是一套把数据从一台设备搬到另一台设备的系统。你可以把整个网络想象成一个全国范围的快递网络：应用层是寄件人填写快递单，传输层是快递公司把包裹打包、编号，网络层是干线运输决定走哪条路，数据链路层是各个转运站内的小车搬运，物理层就是那条实实在在的高速公路。

数据在发送端是逐层“打包”的，每一层都会在上层数据前面加上自己的头部，这叫封装。到了接收端再逐层“拆包”，每层只处理自己关心的信息，然后交给上层。这个机制解释了很多初学者最迷惑的问题：为什么数据能准确找到目标？因为它每一层的头部都带着类似“收件地址”“端口号”“校验信息”这样的关键字段。

理解这个类比之后，你会发现一个核心事实：网络工程的大多数工作，本质上都是在管理“路径”、“地址”和“传输可靠性”这三件事。

1.2 为什么分层是绕不开的核心思路

分层不是为了考试，而是为了让网络系统具备可维护性。如果一个协议既管物理信号又管应用逻辑，那么任何一层改动都会导致整套系统重来。分层之后，每一层只需要对上提供服务、对下调用接口，替换物理介质不影响上层协议，替换应用协议也不影响底层传输。

这种设计带来的另一个好处是问题可定位。网页打不开时，你只要按层排查：物理链路通不通，网络层能不能路由，传输层有没有握手成功，应用层返回了什么状态码。分层的边界就是排查的边界，这也是为什么几乎所有网络工程师的排障流程，本质上都是“从底层往上层逐层确认”。

不过需要说明的是，实际生产环境中真正使用的并不是教科书上的OSI七层模型，而是TCP/IP四层模型。OSI更多是理论框架，TCP/IP才是互联网上实际跑的那套协议栈。搞清楚两者的对应关系，比单纯背诵七层名称有用得多。

2. 分层模型：OSI七层与TCP/IP四层，怎么对应才记得住

2.1 两个模型的关键对应关系

OSI七层从上到下是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。TCP/IP四层一般归纳为应用层、传输层、网络层、网络接口层。

实际使用中，TCP/IP的应用层把OSI的应用层、表示层、会话层合并了。为什么能合并？因为像HTTP这类协议，自己就处理了数据格式和会话状态，表示层和会话层在互联网体系里并没有独立的协议在跑，所以合并到应用层完全够用。网络接口层则合并了数据链路层和物理层，因为对上层而言，网卡、网线、Wi-Fi信号这些细节不应当影响IP和TCP的工作方式。

学习建议是：记住TCP/IP四层为主，OSI七层用来理解层与层之间的职责边界。面试时如果被问到“TCP三次握手发生在哪一层”，你要能立刻反应出来——传输层。被问到“MAC地址在哪一层”——数据链路层。这种“协议对应到层”的映射能力，才是真正的工作基础。

2.2 用一次网页访问串起每一层

把抽象模型落到一个具体操作上会清晰很多。假设你在浏览器输入一个网址，按下回车：

• 应用层：浏览器构造一个HTTP GET请求，里面包含请求路径、浏览器类型等信息。
• DNS解析也发生在应用层，系统会先向DNS服务器询问这个域名对应的IP地址。
• 传输层：操作系统把HTTP数据交给TCP，TCP会为这个连接分配源端口和目的端口（目的端口通常是443），并准备发起三次握手建立连接。
• 网络层：IP协议为数据包加上源IP和目的IP，并查询路由表决定把包交给哪台下一跳设备。
• 网络接口层：数据帧加上源MAC和目标MAC（目标是下一跳设备的MAC），通过网卡变成电信号发出。

接收端收到后，逐层解封装，最终Web服务器把响应数据沿原路返回，浏览器渲染出页面。整个过程发生在几百毫秒内，但每一层都在各司其职。你能看到，所谓“一个网页打开”，实际上是几十次协议交互的串行与并行结果。

3. IP寻址与子网规划：网工的基本功

3.1 先搞懂IP地址、子网掩码和CIDR

IPv4地址是32位二进制数，通常写成点分十进制，比如192.168.1.10。但IP地址本身必须配合子网掩码才能确定网络范围。子网掩码的作用是把IP地址切开：一部分是网络号，决定这台主机属于哪个网段；另一部分是主机号，决定它在网段内的编号。

CIDR（无类域间路由）是目前最通用的简写方式，直接用一个斜杠加数字表示网络前缀长度。比如192.168.1.10/24，表示前24位是网络号，后8位是主机号。这个网段可用地址范围就是192.168.1.1到192.168.1.254，其中192.168.1.0是网络号，192.168.1.255是广播地址，都不能分配给主机。

很多初学者会在可用主机数上算错。记住公式：每个子网的可用主机数是2^(32-前缀长度)减去2。比如/24可用的主机数是2^8 - 2 = 254。/30只有2个可用地址，常用于点对点互联链路。

3.2 子网划分实操：把一个C段切成四个子网

光看公式容易忘，我建议你拿一个真实场景练。假设公司拿到一个192.168.1.0/24的C段，要分给四个部门，每个部门约50台设备。你会怎么分？

如果按传统C段直接分，四个部门都需要独立网段，最自然的做法是把/24划分成四个/26子网。

每个子网有62个可用地址，足够50台设备使用，还留有余量。实际规划时关键技巧是：先确定每个子网需要的主机数，向上取到2的幂次，再反推前缀长度。需求是50台，2^6=64，减去网络号和广播地址就是62，所以前缀长度是32-6=26。这个“从需求反推前缀”的思路，比死记“/24分两个/25”要实用得多。

3.3 NAT与内网穿透：为什么家里一个公网IP能带几十台设备

IPv4公网地址数量有限，但家里的手机、电脑、电视、智能家居动辄十几台上网。这都靠NAT（网络地址转换）在撑。家用路由器默认采用NAPT模式：内网设备发起对外连接时，路由器会把内网IP+端口映射成自己的公网IP+一个新的外部端口，并记录一张映射表。外部响应的数据包到达路由器后，路由器根据端口号反查映射表，再把数据转发给内网对应设备。

这也解释了为什么从外网主动访问内网设备通常不行：外网并不知道内网设备的映射关系，除非在路由器上配置端口映射或使用内网穿透工具。我在实际维护某公司远程办公网络时，遇到过不少“外网访问不了内网监控”的情况，最终都是通过端口映射或者建立组网隧道解决的。

顺带一提，IPv6普及之后，每个设备理论上都可以有公网地址，NAT的需求会大幅减少。但IPv6的推广是一个漫长的过程，短时间内学好IPv4和NAT依然是基本功。

4. 传输层：TCP与UDP，连接到底是怎么建立的

4.1 三次握手和四次挥手，不只是画图

TCP三次握手大家都很熟：客户端发送SYN包，服务端回复SYN+ACK包，客户端再发ACK包。但很多人没想过，为什么一定要三次，而不是两次或四次。

关键在于双方都需要确认“我的发送能力”和“对方的接收能力”都是正常的。第一次SYN让服务端确认了客户端的发送能力，第二次SYN+ACK让客户端确认了自己的发送能力、接收能力以及服务端的发送能力，第三次ACK让服务端确认了客户端的接收能力。这样双方发送和接收能力都得到确认，连接才算建立。两次握手达不到这个效果，因为服务端无法确认客户端的接收能力；四次又多余，因为第三次和第四次的信息可以合并。

四次挥手的过程是：主动关闭方发FIN，被动方回ACK，然后被动方发FIN，主动方回ACK。之所以需要四次，是因为TCP是全双工的，每个方向的关闭都要单独确认。被动方收到FIN后可能还有数据要发，所以它先回ACK表示“我收到了”，等自己的数据发完再发FIN。

有一个很多新手忽略的细节：主动关闭方在收到被动方的FIN后，会进入TIME_WAIT状态，默认等待约两倍的MSL（报文最大生存时间）。这个等待不是浪费时间，而是为了确保最后一个ACK能被对方收到。如果ACK丢失，被动方会重发FIN，等待状态让主动方有机会重新回应。

4.2 TCP与UDP选型：该可靠就可靠，该快就快

UDP和TCP最大的区别是：UDP无连接、不保证送达、不保证顺序、没有拥塞控制。它不丢包重传，也不确认接收，所以头部开销小、延迟低，但应用层必须自己处理丢包和乱序。

选型对照表可以参考：

我见过不少人在开发即时通讯时，一上来就选UDP“追求速度”，结果发现丢包导致消息大量缺失，最后还得在应用层自己实现确认和重传。实际上，如果应用对消息完整性要求高，直接选TCP是更省事的选择；只有对实时性要求远高于完整性的场景，比如语音和视频通话，才适合UDP加应用层容错。

5. 应用层与实战工具：别只背协议，要学会自己查

5.1 DNS与HTTP/HTTPS的高频细节

应用层最常见的两个基础设施就是DNS和HTTP。

DNS的作用是把域名解析成IP。查询过程可以大致分为递归和迭代：操作系统先查本地缓存和hosts文件，再把请求递交给本地DNS服务器；本地DNS服务器一般会代表客户端进行迭代查询，逐级问根服务器、顶级域服务器、权威服务器，最终拿到结果并缓存下来。

实践中最常见的DNS问题是解析慢和缓存污染。排查时用dig命令可以看到解析耗时：

dig www.example.com

输出结果里有个“Query time”字段，如果这个值经常超过几百毫秒，就要考虑是不是DNS服务器距离太远或者配置了不合理的上游DNS。国内网络环境下，我建议优先配置延迟较低的公共DNS，同时保留运营商DNS做备用。

HTTP本身是明文传输，HTTPS则在HTTP和TCP之间加入了TLS加密层。理解TLS握手的关键在于：它先用非对称加密交换密钥，再用对称加密传输业务数据。现在HTTP/2和HTTP/3逐渐普及，但排查问题时，看响应状态码和缓存策略仍然是基本功。状态码不需要全背，但至少要熟悉：200正常、301/302重定向、403无权限、404不存在、500服务端异常、502网关错误、504超时。

5.2 四个命令行工具，比图形界面更靠谱

图形化网络工具很多，但排查问题最快的方式永远是命令行。

先看ping。ping用ICMP协议测试目标是否可达，它是判断链路连通性的第一工具。

ping -c 4 8.8.8.8

注意两点：第一，很多服务器禁用了ICMP，所以ping不通不代表服务不通；第二，ping的延迟是“网络往返时间”，如果延迟突然从10ms变成100ms，说明链路发生了拥塞或路由变化。

再看traceroute，Windows上叫tracert。它能看到从本机到目标之间经过的每一跳路由。排查问题时，重点不是看每一跳延迟，而是看“包到底卡在哪一跳”：

traceroute -n www.example.com

输出中如果有连续的星号，说明这一跳没有回应。但这不是绝对的，有些路由器故意不响应ICMP，所以要结合前后跳的变化判断。

然后是dig，查DNS记录的利器：

dig www.example.com A @114.114.114.114

加上@参数可以指定向哪台DNS服务器查询，用于对比不同DNS的解析结果。查解析劫持、查TTL时长、查CNAME记录，dig都是首选。

最后是curl。它能模拟HTTP请求并输出完整交互信息，调试接口时几乎必用：

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

-v参数会输出TLS握手细节、请求头、响应头。看状态码、看重定向地址、看证书信息、测接口超时，都可以直接用curl完成。

5.3 抓包入门：一次HTTP延迟的排查实录

命令行工具能定位到大概方向，但真想看清楚每一次协议交互，就得抓包。

我在某公司维护一个内部系统时遇到过一个问题：用户反馈网页加载偶尔要等三四秒，ping网关和DNS都正常，服务端CPU也不高。通过tcpdump抓包发现，TCP握手阶段出现了大量重传：

tcpdump -i eth0 host 10.10.1.5 and port 443 -w /tmp/https.pcap

把抓包文件导入Wireshark后，看到客户端发送SYN后，服务端要很久才回SYN+ACK，而且很多包里带有乱序标记。进一步定位发现，服务端所在的宿主机开启了TCP分段卸载功能，但网卡驱动版本过旧，导致TCP分段出错，频繁触发重传。关闭该功能后，延迟问题立刻消失。

这个案例说明两个道理：第一，应用层慢，根因不一定在应用层，要敢于往下层查；第二，抓包时不要只盯着应用层协议，TCP握手字段、重传标记、窗口大小往往才是问题关键。

6. 常见网络问题与排查速查

6.1 从“上不了网”到“网页卡顿”的分层排查法

我习惯把网络排查分成四步，每一步对应一层，可以大大减少盲目性：

步骤一，确认物理层和链路层。查看网卡状态，比如Linux下用ip link看接口是否UP，Windows下看网络适配器状态。接着用arp -a检查IP和MAC的映射是否正常。局域网内互相ping不通，多半问题出在这一层。

步骤二，确认网络层。检查本机IP配置是否正确，路由表是否正常，网关是否可通。用ping网关的方式判断本机到出口是否正常。如果网关ping不通，重点查网线、交换机端口和IP地址冲突。

步骤三，确认传输层。用telnet或nc测试目标端口是否开放：

nc -zv 10.10.1.5 443

如果IP能通但端口不通，通常是防火墙拦截或服务本身没有监听。这个排查步骤经常被人跳过，结果在应用层摸索半天，其实是端口没放通。

步骤四，确认应用层。检查域名解析是否正常，服务进程是否存在，业务日志有无报错。到这一步，才真正涉及代码和配置层面。

这套流程的价值在于：每一步都有一个明确的判断标准，很快就能把问题范围缩小。我用这套方法排查过大量“网络慢”“连不上”的工单，绝大多数情况下10分钟内就能确认是链路、防火墙还是应用的问题。

6.2 几个我踩过的坑，写出来给大家避雷

踩坑一：ping通不代表TCP通。有些服务器ICMP放行但业务端口没监听，或者防火墙放行了ICMP但拦截了TCP。所以排查“网页打不开”时，不要只依赖ping结果，一定要再做端口测试。

踩坑二：MTU设置过大导致“大包不通，小包正常”。现象很隐蔽：ping小包正常，ping大包超时，访问部分网页时卡住。原因是路径上某个设备支持的MTU比本机小，分片或分片丢弃导致大包无法到达。排查时可以用下面命令逐步缩小MTU值测试：

ping -M do -s 1472 -c 3 8.8.8.8

如果大包不通，把网关和本机MTU调整到一致就能解决。

踩坑三：DNS缓存导致的“间歇性访问异常”。某系统迁移后域名明明已解析到新IP，但部分用户仍然访问到旧地址。原因就是本地DNS缓存或路由器缓存未过期。排障时不要只看一次dig结果，先刷新缓存再对比多次解析结果。Windows用ipconfig /flushdns，Linux可以重启systemd-resolved或清空nscd缓存。

踩坑四：应用层协议版本不匹配。服务端强制要求TLS1.2，客户端默认只用TLS1.0，看起来就是“能连接但请求失败”。这类问题用curl -v看TLS握手信息能很快发现。

我的经验是，网络不是靠背出来的，是靠一次一次的真实问题喂出来的。这套分层模型、IP计算、TCP原理、命令工具和排障流程，就是把最常见的场景先覆盖到。你照着这套思路在自己环境里搭几个虚拟网段、做几次抓包分析、处理几个模拟故障，很快就会发现，原来网络那些看似复杂的概念，其实都是可以手动验证、亲手解决的具体问题。