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要大于等于50n6时是62够用。所以主机号6位网络号26位即/26。第二步每个子网大小是642的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”。第二次服务端回SYNACK说“收到我也想连你我的序号是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、安全组、负载均衡。这两块是实际工作中最容易卡住的地方。最后分享一个我自己的习惯每次遇到网络问题先画一张分层图标出数据流向然后从最可能出问题的那层开始验证。这个习惯帮我省了大量时间。网络知识不难难的是建立体系并坚持用体系去思考。希望这篇内容能帮你把这张坐标系建起来。
