1. 为什么还要回头聊“计算机网络基本概念”你可能觉得奇怪，都什么年代了，怎么还有人写计算机网络基本概念这种“大一第一课”的内容。我一开始也这么想，直到最近帮几个朋友排查问题，发现一个很普遍的现象：很多人能写代码、能调框架、能部署服务，但一旦遇到“为什么本地能跑、线上不行”“为什么换个网络环境就超时”“为什么抓包看到的和想象的不一样”这类问题，就完全靠猜。猜对了是运气，猜错了就反复重启、换端口、加超时，最后问题还在。计算机网络基本概念不是背八股，它是一套排查问题的坐标系。你脑子里有没有这张坐标系，决定了你遇到网络问题是“有方向地缩小范围”还是“瞎试”。这篇内容我想做的，就是把这张坐标系用从业者的视角重新讲一遍——不是教科书式的定义罗列，而是告诉你每个概念在实际工作里对应什么现象、能帮你排除什么、以及我踩过的那些坑。这篇文章适合三类人：一是刚入行、正在补网络基础的朋友；二是工作几年但网络知识比较零散、想系统梳理一遍的开发者；三是需要经常和运维、后端、测试协作，想听懂他们在说什么的同学。我会尽量用生活化的类比把抽象概念讲清楚，同时给出可以直接上手验证的命令和步骤。核心关键词会围绕OSI七层模型、TCP/IP协议栈、IP地址与子网、TCP与UDP、DNS解析、HTTP请求过程这些展开，但重点永远落在“这东西到底怎么用”。先说一个我自己的判断：网络知识最大的特点是分层。分层的好处是每一层只关心自己的事，坏处是出问题时你容易只盯着自己熟悉的那一层。真正高效的排查，是沿着分层从上到下或从下到上快速定位。下面我就按这个思路，把整个知识体系拆开讲。2. 先建立分层思维：OSI与TCP/IP到底怎么对应2.1 用一个寄快递的类比理解分层我特别喜欢用寄快递来解释网络分层。你写一封信（应用层数据），装进信封写上地址（传输层加端口），交给快递公司（网络层加IP），快递公司再装车走公路（数据链路层加MAC），最后物理运输（物理层）。收件方反过来一层层拆开。每一层只关心自己那部分信息，不需要知道上一层具体写了什么。OSI七层模型是理论上的标准分层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。而实际工程里用的是TCP/IP四层模型：网络接口层、网络层、传输层、应用层。两者的对应关系是很多人容易搞混的地方，我整理成表格更直观：OSI七层TCP/IP四层典型协议/设备实际关注点应用层/表示层/会话层应用层HTTP、DNS、SSH业务数据格式、请求响应传输层传输层TCP、UDP端口、可靠性、连接状态网络层网络层IP、ICMPIP地址、路由、可达性数据链路层/物理层网络接口层以太网、网卡MAC地址、物理连通提示：面试常问“OSI和TCP/IP的区别”，但工作中真正有用的是——你知道某个现象该去查哪一层。比如“连接被拒绝”通常是传输层端口问题，“ping不通”是网络层可达性问题，“域名解析失败”是应用层DNS问题。2.2 分层排查的实战价值我遇到过最典型的一个案例：某服务在本地开发机访问正常，部署到测试环境后调用另一个服务一直超时。团队里有人怀疑是代码问题，有人怀疑是对方服务挂了。我按分层思路走了一遍：先ping对方IP，通；再用telnet测对方端口，不通；最后确认是测试环境的防火墙策略没放行该端口。整个过程不到五分钟。如果只盯着应用层日志，可能查半天。这就是分层思维的价值：它把一个大问题切成若干可独立验证的小问题。每一层都有对应的工具：物理层看网线指示灯，链路层用arp，网络层用ping和traceroute，传输层用telnet和netstat，应用层用curl和dig。你不需要记住所有工具，但要知道遇到问题先确定“卡在哪一层”。2.3 数据封装与解封装：为什么抓包看到的东西不一样还有一个概念必须讲清楚：封装。数据从应用层往下走，每经过一层就加一个头部。应用层数据加TCP头变成段，加IP头变成包，加帧头变成帧。到了网线上传的是电信号。接收方反过来一层层剥掉头部。这解释了一个常见困惑：为什么用抓包工具看到的HTTP请求，和你在代码里写的请求长得不一样？因为抓包工具展示的是某一层的视角。你在传输层看到的是TCP段，在网络层看到的是IP包。理解封装，你才能看懂抓包结果，也才能理解为什么MTU（最大传输单元）会导致大包被分片。3. IP地址与子网：最容易含糊但最该搞懂的部分3.1 IP地址的本质与分类IP地址是网络层的核心标识。IPv4是32位，通常写成点分十进制，比如192.168.1.10。它由网络号和主机号两部分组成，靠子网掩码来划分。很多人对“子网掩码”的理解停留在“255.255.255.0”，但不知道为什么是这个值。我用一个生活类比：IP地址像门牌号，子网掩码像“哪部分是街道、哪部分是门牌”。255.255.255.0意味着前24位是街道（网络号），后8位是门牌（主机号）。同一个街道内的设备可以直接通信，跨街道就要经过路由器。IP地址分A、B、C类是老分类法，现在基本被CIDR（无类别域间路由）取代。CIDR用“/24”这种写法表示前多少位是网络号。比如192.168.1.0/24表示前24位固定，可用主机地址是192.168.1.1到192.168.1.254，共254个（去掉网络地址和广播地址）。CIDR表示子网掩码可用主机数常见场景/24255.255.255.0254小型局域网/16255.255.0.065534中型企业网/30255.255.255.2522点对点链路/32255.255.255.2551单主机路由3.2 私有地址与NAT：为什么你家路由器下的设备能上网这里有个很多人没想明白的问题：你家路由器下的手机、电脑用的都是192.168.x.x这种私有地址，为什么能访问公网？答案是NAT（网络地址转换）。路由器把私有地址转换成公网地址出去，回来时再转换回去。私有地址段有三个：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。这些地址在公网上不可路由，只在局域网内有效。NAT让大量设备共享少量公网IP，这是IPv4地址不够用的主要缓解手段。注意：NAT会破坏端到端连接，导致外部无法主动连接内部设备。这就是为什么家里想搭个服务给外网访问，需要做端口映射。也是为什么P2P应用经常需要打洞。3.3 子网划分的实操计算子网划分是网络基础里最“数学”的部分，但掌握方法后很简单。假设给你一个192.168.10.0/24，要划分成4个子网，每个子网至少50台主机。怎么算？第一步，确定需要几位主机号。2的n次方减2要大于等于50，n=6时是62，够用。所以主机号6位，网络号26位，即/26。第二步，每个子网大小是64（2的6次方），所以四个子网是：192.168.10.0/26、192.168.10.64/26、192.168.10.128/26、192.168.10.192/26。每个子网可用地址是去掉首尾后的62个。我建议你拿纸笔自己算两遍，比看十遍教程都管用。实际工作中虽然很少手工划子网，但云平台的VPC、安全组规则、路由表配置都依赖这个思维。4. TCP与UDP：可靠性到底是怎么实现的4.1 三次握手与四次挥手的生活化解释TCP是面向连接的可靠传输协议。所谓“面向连接”，就是通信前要先建立连接，这个建立过程就是三次握手。第一次：客户端发SYN，说“我想连你，我的序号是x”。第二次：服务端回SYN+ACK，说“收到，我也想连你，我的序号是y，确认收到你的x”。第三次：客户端回ACK，说“收到你的y，连接建立”。为什么是三次不是两次？因为要让双方都确认对方的收发能力正常。两次的话，服务端无法确认客户端能收到自己的包。这就像打电话：“喂能听到吗？”“能，你能听到我吗？”“能。”三句确认双方都通。四次挥手是断开连接：一方发FIN，另一方回ACK，等自己数据发完再发FIN，对方回ACK。为什么多一次？因为TCP是全双工的，两个方向要分别关闭。4.2 TCP可靠传输的四大机制很多人知道TCP可靠，但说不清怎么实现的。核心是四个机制：序号与确认：每个字节都有序号，接收方确认收到哪些。超时重传：发出去没收到确认，等一段时间重发。滑动窗口：不是发一个等一个，而是批量发，提高效率。流量控制与拥塞控制：根据接收方能力和网络状况调整发送速度。滑动窗口特别值得说。如果每发一个包就等确认，效率极低。滑动窗口允许发送方连续发多个包，接收方累积确认。窗口大小动态调整，这就是为什么TCP既能保证可靠又不会太慢。4.3 UDP的适用场景与常见误区UDP不建立连接、不保证可靠、不保证顺序，但快。很多人以为UDP“不可靠”就是“不好”，这是误区。UDP适合实时性要求高、能容忍少量丢包的场景：视频直播、语音通话、游戏、DNS查询。对比项TCPUDP连接面向连接无连接可靠性可靠，有重传不可靠，不重传顺序保证顺序不保证速度相对慢快头部大小20字节起8字节典型应用HTTP、SSH、文件传输DNS、视频、游戏提示：DNS默认用UDP，因为查询小、要求快。但如果响应太大超过512字节，会切换到TCP。这也是为什么有些DNS查询偶尔慢——它在等TCP重试。4.4 端口与连接状态排查端口是传输层的概念，用来区分同一台机器上的不同服务。0到1023是知名端口，1024到49151是注册端口，49152以上是动态端口。服务端监听固定端口，客户端用随机端口。排查连接问题常用netstat或ss命令。比如ss -tunlp能看到所有TCP/UDP监听和连接状态。状态里TIME_WAIT、CLOSE_WAIT是高频问题：TIME_WAIT是主动关闭方等待2MSL，正常；CLOSE_WAIT大量出现通常意味着代码没正确关闭连接。5. DNS与HTTP：从输入网址到页面显示发生了什么5.1 DNS解析的完整链路在浏览器输入一个域名，第一步是DNS解析。过程是：浏览器缓存→系统缓存→hosts文件→本地DNS服务器→根域名服务器→顶级域名服务器→权威域名服务器。最终拿到IP地址。这个过程通常几十毫秒，但出问题时很致命。常见现象是“域名解析失败”或“解析到错误IP”。排查用dig或nslookup。dig example.com能看到完整解析链路和TTL。注意：DNS有缓存，改了解析记录不会立即生效。TTL决定缓存多久。调试时可以用dig @8.8.8.8 example.com指定DNS服务器绕过本地缓存。5.2 HTTP请求的完整旅程拿到IP后，浏览器发起TCP连接（三次握手），然后发送HTTP请求。请求包含方法、路径、头部、可选的body。服务端处理后返回响应，包含状态码、头部、body。之后根据Connection头决定是否保持连接。HTTP/1.1默认keep-alive，复用连接。HTTP/2多路复用，一个连接并发多个请求。HTTP/3基于UDP的QUIC，进一步降低延迟。理解这些演进，你才能理解为什么有些优化手段有效。5.3 一次完整访问的分层拆解我把“输入网址到页面显示”按层拆一遍，这是检验你是否真懂的好方法：应用层：DNS解析域名，HTTP构造请求。传输层：TCP三次握手建立连接，分配端口。网络层：IP寻址和路由，可能经过多个路由器。链路层：每跳的MAC地址转发。物理层：电信号或光信号传输。任何一环出问题，现象都不同。DNS问题表现为“找不到服务器”，TCP问题表现为“连接超时”，IP问题表现为“无法到达”，HTTP问题表现为“状态码异常”。按这个映射去排查，效率会高很多。6. 常见问题与排查技巧实录6.1 网络问题速查表现象可能层级排查命令常见原因域名无法解析应用层dig、nslookupDNS配置错误、缓存连接被拒绝传输层telnet、nc端口未监听、防火墙连接超时网络层ping、traceroute路由不通、安全组丢包严重网络层/链路层ping -c 100、mtr网络拥塞、硬件故障大量CLOSE_WAIT传输层ss -tan代码未关闭连接页面加载慢应用层curl -w、浏览器面板资源大、DNS慢6.2 我踩过的几个坑第一个坑：以为ping通就代表服务可用。ping走的是ICMP，和TCP端口是两回事。ping通但端口不通太常见了，一定要用telnet或nc测端口。第二个坑：忽略MTU导致的大包问题。有一次某个接口小请求正常，大请求超时。最后发现是链路MTU小于默认1500，大包被丢弃且ICMP被屏蔽。用ping -M do -s 1472可以测MTU。第三个坑：TIME_WAIT过多以为是bug。其实高并发短连接下TIME_WAIT多是正常的，可以通过调整内核参数缓解，但根本解法是用连接池复用连接。6.3 抓包的正确姿势抓包不是抓得越多越好。我一般先用过滤器缩小范围，比如tcp port 80 and host 10.0.0.1。先看三次握手是否完成，再看请求响应是否正常，最后看是否有重传。Wireshark的“Follow TCP Stream”能直接看应用层数据，非常方便。提示：生产环境抓包要注意权限和性能影响，尽量在测试环境复现。抓包文件可能含敏感信息，注意脱敏。7. 给不同阶段读者的学习建议如果你是刚入行的朋友，我建议按“分层”顺序学：先搞懂IP和子网，再学TCP/UDP，然后DNS和HTTP。每学一个概念就用命令验证一遍，比如自己划个子网、用nc建个连接、用dig查个域名。动手一次胜过看十篇文章。如果你是有经验的开发者，重点补两块：一是抓包分析能力，二是云环境下的网络配置（VPC、安全组、负载均衡）。这两块是实际工作中最容易卡住的地方。最后分享一个我自己的习惯：每次遇到网络问题，先画一张分层图，标出数据流向，然后从最可能出问题的那层开始验证。这个习惯帮我省了大量时间。网络知识不难，难的是建立体系并坚持用体系去思考。希望这篇内容能帮你把这张坐标系建起来。
1. 为什么还要回头聊“计算机网络基本概念”你可能觉得奇怪，都什么年代了，怎么还有人写计算机网络基本概念这种“大一第一课”的内容。我一开始也这么想，直到最近帮几个朋友排查问题，发现一个很普遍的现象：很多人能写代码、能调框架、能部署服务，但一旦遇到“为什么本地能跑、线上不行”“为什么换个网络环境就超时”“为什么抓包看到的和想象的不一样”这类问题，就完全靠猜。猜对了是运气，猜错了就反复重启、换端口、加超时，最后问题还在。计算机网络基本概念不是背八股，它是一套排查问题的坐标系。你脑子里有没有这张坐标系，决定了你遇到网络问题是“有方向地缩小范围”还是“瞎试”。这篇内容我想做的，就是把这张坐标系用从业者的视角重新讲一遍——不是教科书式的定义罗列，而是告诉你每个概念在实际工作里对应什么现象、能帮你排除什么、以及我踩过的那些坑。这篇文章适合三类人：一是刚入行、正在补网络基础的朋友；二是工作几年但网络知识比较零散、想系统梳理一遍的开发者；三是需要经常和运维、后端、测试协作，想听懂他们在说什么的同学。我会尽量用生活化的类比把抽象概念讲清楚，同时给出可以直接上手验证的命令和步骤。核心关键词会围绕OSI七层模型、TCP/IP协议栈、IP地址与子网、TCP与UDP、DNS解析、HTTP请求过程这些展开，但重点永远落在“这东西到底怎么用”。先说一个我自己的判断：网络知识最大的特点是分层。分层的好处是每一层只关心自己的事，坏处是出问题时你容易只盯着自己熟悉的那一层。真正高效的排查，是沿着分层从上到下或从下到上快速定位。下面我就按这个思路，把整个知识体系拆开讲。2. 先建立分层思维：OSI与TCP/IP到底怎么对应2.1 用一个寄快递的类比理解分层我特别喜欢用寄快递来解释网络分层。你写一封信（应用层数据），装进信封写上地址（传输层加端口），交给快递公司（网络层加IP），快递公司再装车走公路（数据链路层加MAC），最后物理运输（物理层）。收件方反过来一层层拆开。每一层只关心自己那部分信息，不需要知道上一层具体写了什么。OSI七层模型是理论上的标准分层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。而实际工程里用的是TCP/IP四层模型：网络接口层、网络层、传输层、应用层。两者的对应关系是很多人容易搞混的地方，我整理成表格更直观：OSI七层TCP/IP四层典型协议/设备实际关注点应用层/表示层/会话层应用层HTTP、DNS、SSH业务数据格式、请求响应传输层传输层TCP、UDP端口、可靠性、连接状态网络层网络层IP、ICMPIP地址、路由、可达性数据链路层/物理层网络接口层以太网、网卡MAC地址、物理连通提示：面试常问“OSI和TCP/IP的区别”，但工作中真正有用的是——你知道某个现象该去查哪一层。比如“连接被拒绝”通常是传输层端口问题，“ping不通”是网络层可达性问题，“域名解析失败”是应用层DNS问题。2.2 分层排查的实战价值我遇到过最典型的一个案例：某服务在本地开发机访问正常，部署到测试环境后调用另一个服务一直超时。团队里有人怀疑是代码问题，有人怀疑是对方服务挂了。我按分层思路走了一遍：先ping对方IP，通；再用telnet测对方端口，不通；最后确认是测试环境的防火墙策略没放行该端口。整个过程不到五分钟。如果只盯着应用层日志，可能查半天。这就是分层思维的价值：它把一个大问题切成若干可独立验证的小问题。每一层都有对应的工具：物理层看网线指示灯，链路层用arp，网络层用ping和traceroute，传输层用telnet和netstat，应用层用curl和dig。你不需要记住所有工具，但要知道遇到问题先确定“卡在哪一层”。2.3 数据封装与解封装：为什么抓包看到的东西不一样还有一个概念必须讲清楚：封装。数据从应用层往下走，每经过一层就加一个头部。应用层数据加TCP头变成段，加IP头变成包，加帧头变成帧。到了网线上传的是电信号。接收方反过来一层层剥掉头部。这解释了一个常见困惑：为什么用抓包工具看到的HTTP请求，和你在代码里写的请求长得不一样？因为抓包工具展示的是某一层的视角。你在传输层看到的是TCP段，在网络层看到的是IP包。理解封装，你才能看懂抓包结果，也才能理解为什么MTU（最大传输单元）会导致大包被分片。3. IP地址与子网：最容易含糊但最该搞懂的部分3.1 IP地址的本质与分类IP地址是网络层的核心标识。IPv4是32位，通常写成点分十进制，比如192.168.1.10。它由网络号和主机号两部分组成，靠子网掩码来划分。很多人对“子网掩码”的理解停留在“255.255.255.0”，但不知道为什么是这个值。我用一个生活类比：IP地址像门牌号，子网掩码像“哪部分是街道、哪部分是门牌”。255.255.255.0意味着前24位是街道（网络号），后8位是门牌（主机号）。同一个街道内的设备可以直接通信，跨街道就要经过路由器。IP地址分A、B、C类是老分类法，现在基本被CIDR（无类别域间路由）取代。CIDR用“/24”这种写法表示前多少位是网络号。比如192.168.1.0/24表示前24位固定，可用主机地址是192.168.1.1到192.168.1.254，共254个（去掉网络地址和广播地址）。CIDR表示子网掩码可用主机数常见场景/24255.255.255.0254小型局域网/16255.255.0.065534中型企业网/30255.255.255.2522点对点链路/32255.255.255.2551单主机路由3.2 私有地址与NAT：为什么你家路由器下的设备能上网这里有个很多人没想明白的问题：你家路由器下的手机、电脑用的都是192.168.x.x这种私有地址，为什么能访问公网？答案是NAT（网络地址转换）。路由器把私有地址转换成公网地址出去，回来时再转换回去。私有地址段有三个：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。这些地址在公网上不可路由，只在局域网内有效。NAT让大量设备共享少量公网IP，这是IPv4地址不够用的主要缓解手段。注意：NAT会破坏端到端连接，导致外部无法主动连接内部设备。这就是为什么家里想搭个服务给外网访问，需要做端口映射。也是为什么P2P应用经常需要打洞。3.3 子网划分的实操计算子网划分是网络基础里最“数学”的部分，但掌握方法后很简单。假设给你一个192.168.10.0/24，要划分成4个子网，每个子网至少50台主机。怎么算？第一步，确定需要几位主机号。2的n次方减2要大于等于50，n=6时是62，够用。所以主机号6位，网络号26位，即/26。第二步，每个子网大小是64（2的6次方），所以四个子网是：192.168.10.0/26、192.168.10.64/26、192.168.10.128/26、192.168.10.192/26。每个子网可用地址是去掉首尾后的62个。我建议你拿纸笔自己算两遍，比看十遍教程都管用。实际工作中虽然很少手工划子网，但云平台的VPC、安全组规则、路由表配置都依赖这个思维。4. TCP与UDP：可靠性到底是怎么实现的4.1 三次握手与四次挥手的生活化解释TCP是面向连接的可靠传输协议。所谓“面向连接”，就是通信前要先建立连接，这个建立过程就是三次握手。第一次：客户端发SYN，说“我想连你，我的序号是x”。第二次：服务端回SYN+ACK，说“收到，我也想连你，我的序号是y，确认收到你的x”。第三次：客户端回ACK，说“收到你的y，连接建立”。为什么是三次不是两次？因为要让双方都确认对方的收发能力正常。两次的话，服务端无法确认客户端能收到自己的包。这就像打电话：“喂能听到吗？”“能，你能听到我吗？”“能。”三句确认双方都通。四次挥手是断开连接：一方发FIN，另一方回ACK，等自己数据发完再发FIN，对方回ACK。为什么多一次？因为TCP是全双工的，两个方向要分别关闭。4.2 TCP可靠传输的四大机制很多人知道TCP可靠，但说不清怎么实现的。核心是四个机制：序号与确认：每个字节都有序号，接收方确认收到哪些。超时重传：发出去没收到确认，等一段时间重发。滑动窗口：不是发一个等一个，而是批量发，提高效率。流量控制与拥塞控制：根据接收方能力和网络状况调整发送速度。滑动窗口特别值得说。如果每发一个包就等确认，效率极低。滑动窗口允许发送方连续发多个包，接收方累积确认。窗口大小动态调整，这就是为什么TCP既能保证可靠又不会太慢。4.3 UDP的适用场景与常见误区UDP不建立连接、不保证可靠、不保证顺序，但快。很多人以为UDP“不可靠”就是“不好”，这是误区。UDP适合实时性要求高、能容忍少量丢包的场景：视频直播、语音通话、游戏、DNS查询。对比项TCPUDP连接面向连接无连接可靠性可靠，有重传不可靠，不重传顺序保证顺序不保证速度相对慢快头部大小20字节起8字节典型应用HTTP、SSH、文件传输DNS、视频、游戏提示：DNS默认用UDP，因为查询小、要求快。但如果响应太大超过512字节，会切换到TCP。这也是为什么有些DNS查询偶尔慢——它在等TCP重试。4.4 端口与连接状态排查端口是传输层的概念，用来区分同一台机器上的不同服务。0到1023是知名端口，1024到49151是注册端口，49152以上是动态端口。服务端监听固定端口，客户端用随机端口。排查连接问题常用netstat或ss命令。比如ss -tunlp能看到所有TCP/UDP监听和连接状态。状态里TIME_WAIT、CLOSE_WAIT是高频问题：TIME_WAIT是主动关闭方等待2MSL，正常；CLOSE_WAIT大量出现通常意味着代码没正确关闭连接。5. DNS与HTTP：从输入网址到页面显示发生了什么5.1 DNS解析的完整链路在浏览器输入一个域名，第一步是DNS解析。过程是：浏览器缓存→系统缓存→hosts文件→本地DNS服务器→根域名服务器→顶级域名服务器→权威域名服务器。最终拿到IP地址。这个过程通常几十毫秒，但出问题时很致命。常见现象是“域名解析失败”或“解析到错误IP”。排查用dig或nslookup。dig example.com能看到完整解析链路和TTL。注意：DNS有缓存，改了解析记录不会立即生效。TTL决定缓存多久。调试时可以用dig @8.8.8.8 example.com指定DNS服务器绕过本地缓存。5.2 HTTP请求的完整旅程拿到IP后，浏览器发起TCP连接（三次握手），然后发送HTTP请求。请求包含方法、路径、头部、可选的body。服务端处理后返回响应，包含状态码、头部、body。之后根据Connection头决定是否保持连接。HTTP/1.1默认keep-alive，复用连接。HTTP/2多路复用，一个连接并发多个请求。HTTP/3基于UDP的QUIC，进一步降低延迟。理解这些演进，你才能理解为什么有些优化手段有效。5.3 一次完整访问的分层拆解我把“输入网址到页面显示”按层拆一遍，这是检验你是否真懂的好方法：应用层：DNS解析域名，HTTP构造请求。传输层：TCP三次握手建立连接，分配端口。网络层：IP寻址和路由，可能经过多个路由器。链路层：每跳的MAC地址转发。物理层：电信号或光信号传输。任何一环出问题，现象都不同。DNS问题表现为“找不到服务器”，TCP问题表现为“连接超时”，IP问题表现为“无法到达”，HTTP问题表现为“状态码异常”。按这个映射去排查，效率会高很多。6. 常见问题与排查技巧实录6.1 网络问题速查表现象可能层级排查命令常见原因域名无法解析应用层dig、nslookupDNS配置错误、缓存连接被拒绝传输层telnet、nc端口未监听、防火墙连接超时网络层ping、traceroute路由不通、安全组丢包严重网络层/链路层ping -c 100、mtr网络拥塞、硬件故障大量CLOSE_WAIT传输层ss -tan代码未关闭连接页面加载慢应用层curl -w、浏览器面板资源大、DNS慢6.2 我踩过的几个坑第一个坑：以为ping通就代表服务可用。ping走的是ICMP，和TCP端口是两回事。ping通但端口不通太常见了，一定要用telnet或nc测端口。第二个坑：忽略MTU导致的大包问题。有一次某个接口小请求正常，大请求超时。最后发现是链路MTU小于默认1500，大包被丢弃且ICMP被屏蔽。用ping -M do -s 1472可以测MTU。第三个坑：TIME_WAIT过多以为是bug。其实高并发短连接下TIME_WAIT多是正常的，可以通过调整内核参数缓解，但根本解法是用连接池复用连接。6.3 抓包的正确姿势抓包不是抓得越多越好。我一般先用过滤器缩小范围，比如tcp port 80 and host 10.0.0.1。先看三次握手是否完成，再看请求响应是否正常，最后看是否有重传。Wireshark的“Follow TCP Stream”能直接看应用层数据，非常方便。提示：生产环境抓包要注意权限和性能影响，尽量在测试环境复现。抓包文件可能含敏感信息，注意脱敏。7. 给不同阶段读者的学习建议如果你是刚入行的朋友，我建议按“分层”顺序学：先搞懂IP和子网，再学TCP/UDP，然后DNS和HTTP。每学一个概念就用命令验证一遍，比如自己划个子网、用nc建个连接、用dig查个域名。动手一次胜过看十篇文章。如果你是有经验的开发者，重点补两块：一是抓包分析能力，二是云环境下的网络配置（VPC、安全组、负载均衡）。这两块是实际工作中最容易卡住的地方。最后分享一个我自己的习惯：每次遇到网络问题，先画一张分层图，标出数据流向，然后从最可能出问题的那层开始验证。这个习惯帮我省了大量时间。网络知识不难，难的是建立体系并坚持用体系去思考。希望这篇内容能帮你把这张坐标系建起来。