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、ICMP | IP地址、路由、可达性 |
| 数据链路层/物理层 | 网络接口层 | 以太网、网卡 | 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表示 | 子网掩码 | 可用主机数 | 常见场景 |
|---|---|---|---|
| /24 | 255.255.255.0 | 254 | 小型局域网 |
| /16 | 255.255.0.0 | 65534 | 中型企业网 |
| /30 | 255.255.255.252 | 2 | 点对点链路 |
| /32 | 255.255.255.255 | 1 | 单主机路由 |
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查询。
| 对比项 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接 | 无连接 |
| 可靠性 | 可靠，有重传 | 不可靠，不重传 |
| 顺序 | 保证顺序 | 不保证 |
| 速度 | 相对慢 | 快 |
| 头部大小 | 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、nslookup | DNS配置错误、缓存 |
| 连接被拒绝 | 传输层 | 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、安全组、负载均衡）。这两块是实际工作中最容易卡住的地方。
最后分享一个我自己的习惯：每次遇到网络问题，先画一张分层图，标出数据流向，然后从最可能出问题的那层开始验证。这个习惯帮我省了大量时间。网络知识不难，难的是建立体系并坚持用体系去思考。希望这篇内容能帮你把这张坐标系建起来。
