很多刚接触计算机网络的人都有同感协议名一堆分层看了就忘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数据交给TCPTCP会为这个连接分配源端口和目的端口目的端口通常是443并准备发起三次握手建立连接。网络层IP协议为数据包加上源IP和目的IP并查询路由表决定把包交给哪台下一跳设备。网络接口层数据帧加上源MAC和目标MAC目标是下一跳设备的MAC通过网卡变成电信号发出。接收端收到后逐层解封装最终Web服务器把响应数据沿原路返回浏览器渲染出页面。整个过程发生在几百毫秒内但每一层都在各司其职。你能看到所谓“一个网页打开”实际上是几十次协议交互的串行与并行结果。3. IP寻址与子网规划网工的基本功3.1 先搞懂IP地址、子网掩码和CIDRIPv4地址是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子网。子网网络号可用IP范围广播地址可用主机数子网A192.168.1.0/26192.168.1.1 - 192.168.1.62192.168.1.6362子网B192.168.1.64/26192.168.1.65 - 192.168.1.126192.168.1.12762子网C192.168.1.128/26192.168.1.129 - 192.168.1.190192.168.1.19162子网D192.168.1.192/26192.168.1.193 - 192.168.1.254192.168.1.25562每个子网有62个可用地址足够50台设备使用还留有余量。实际规划时关键技巧是先确定每个子网需要的主机数向上取到2的幂次再反推前缀长度。需求是50台2^664减去网络号和广播地址就是62所以前缀长度是32-626。这个“从需求反推前缀”的思路比死记“/24分两个/25”要实用得多。3.3 NAT与内网穿透为什么家里一个公网IP能带几十台设备IPv4公网地址数量有限但家里的手机、电脑、电视、智能家居动辄十几台上网。这都靠NAT网络地址转换在撑。家用路由器默认采用NAPT模式内网设备发起对外连接时路由器会把内网IP端口映射成自己的公网IP一个新的外部端口并记录一张映射表。外部响应的数据包到达路由器后路由器根据端口号反查映射表再把数据转发给内网对应设备。这也解释了为什么从外网主动访问内网设备通常不行外网并不知道内网设备的映射关系除非在路由器上配置端口映射或使用内网穿透工具。我在实际维护某公司远程办公网络时遇到过不少“外网访问不了内网监控”的情况最终都是通过端口映射或者建立组网隧道解决的。顺带一提IPv6普及之后每个设备理论上都可以有公网地址NAT的需求会大幅减少。但IPv6的推广是一个漫长的过程短时间内学好IPv4和NAT依然是基本功。4. 传输层TCP与UDP连接到底是怎么建立的4.1 三次握手和四次挥手不只是画图TCP三次握手大家都很熟客户端发送SYN包服务端回复SYNACK包客户端再发ACK包。但很多人没想过为什么一定要三次而不是两次或四次。关键在于双方都需要确认“我的发送能力”和“对方的接收能力”都是正常的。第一次SYN让服务端确认了客户端的发送能力第二次SYNACK让客户端确认了自己的发送能力、接收能力以及服务端的发送能力第三次ACK让服务端确认了客户端的接收能力。这样双方发送和接收能力都得到确认连接才算建立。两次握手达不到这个效果因为服务端无法确认客户端的接收能力四次又多余因为第三次和第四次的信息可以合并。四次挥手的过程是主动关闭方发FIN被动方回ACK然后被动方发FIN主动方回ACK。之所以需要四次是因为TCP是全双工的每个方向的关闭都要单独确认。被动方收到FIN后可能还有数据要发所以它先回ACK表示“我收到了”等自己的数据发完再发FIN。有一个很多新手忽略的细节主动关闭方在收到被动方的FIN后会进入TIME_WAIT状态默认等待约两倍的MSL报文最大生存时间。这个等待不是浪费时间而是为了确保最后一个ACK能被对方收到。如果ACK丢失被动方会重发FIN等待状态让主动方有机会重新回应。4.2 TCP与UDP选型该可靠就可靠该快就快UDP和TCP最大的区别是UDP无连接、不保证送达、不保证顺序、没有拥塞控制。它不丢包重传也不确认接收所以头部开销小、延迟低但应用层必须自己处理丢包和乱序。选型对照表可以参考对比维度TCPUDP连接状态面向连接无连接可靠性可靠传输自动重传不保证必达顺序性保证字节序不保证顺序速度有握手和拥塞控制相对慢开销小延迟低适用场景网页、文件传输、数据库连接实时音视频、DNS查询、游戏同步我见过不少人在开发即时通讯时一上来就选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说明链路发生了拥塞或路由变化。再看tracerouteWindows上叫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后服务端要很久才回SYNACK而且很多包里带有乱序标记。进一步定位发现服务端所在的宿主机开启了TCP分段卸载功能但网卡驱动版本过旧导致TCP分段出错频繁触发重传。关闭该功能后延迟问题立刻消失。这个案例说明两个道理第一应用层慢根因不一定在应用层要敢于往下层查第二抓包时不要只盯着应用层协议TCP握手字段、重传标记、窗口大小往往才是问题关键。6. 常见网络问题与排查速查6.1 从“上不了网”到“网页卡顿”的分层排查法我习惯把网络排查分成四步每一步对应一层可以大大减少盲目性步骤一确认物理层和链路层。查看网卡状态比如Linux下用ip link看接口是否UPWindows下看网络适配器状态。接着用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 /flushdnsLinux可以重启systemd-resolved或清空nscd缓存。踩坑四应用层协议版本不匹配。服务端强制要求TLS1.2客户端默认只用TLS1.0看起来就是“能连接但请求失败”。这类问题用curl -v看TLS握手信息能很快发现。我的经验是网络不是靠背出来的是靠一次一次的真实问题喂出来的。这套分层模型、IP计算、TCP原理、命令工具和排障流程就是把最常见的场景先覆盖到。你照着这套思路在自己环境里搭几个虚拟网段、做几次抓包分析、处理几个模拟故障很快就会发现原来网络那些看似复杂的概念其实都是可以手动验证、亲手解决的具体问题。