我以前自认“会写接口、会用数据库”，直到第一次在生产环境排查“接口偶尔超时”这个问题时，整个人是懵的。业务代码翻了三遍没发现异常，数据库也没有慢查询，最后是某位资深同事在终端敲了几条命令，抓了几分钟的包，看到客户端和服务端之间的TCP重传次数明显偏高，才定位到是某个网络设备在特定流量下丢包。那一刻我才真正意识到：做后端开发，计算机网络不是选修课，而是必修的底层能力。
这个系列就是我重新从零系统过一遍计算机网络的笔记合集。我不会按教科书顺序从头念名词，而是按“从零到一真正搞懂”的目标来组织：先建一张知识地图，再逐个拆解IP、TCP、HTTP这些核心机制，最后落到一套能直接用于排查故障的方法论。这篇开篇先把分层模型讲透，因为它决定了后续每个知识点的归属位置，也决定了你遇到问题时的思考顺序。适合刚入行的开发者、转岗运维的同学，以及那些面试能背出答案、但一到真实现场就无从下手的工程师。
1. 先建立坐标系：分层模型不是背的，是拿来定位问题的
1.1 我为什么一定要先讲分层
很多人的计算机网络是这么学的：先背OSI七层，物理层、数据链路层、网络层、传输层、会话层、表示层、应用层，背完默写一遍就算过关。但真有网页打不开、接口突然超时的时候，能下意识判断“先看哪一层证据”的人少之又少。原因在于，分层如果只当名词背，它对你解决实际问题没有任何帮助；它真正的价值是一套故障定位的坐标系。
我自己重新学的时候，核心的思维转换是：每一层解决一类特定问题，每一层的故障有对应的典型表现。网线松了、Wi-Fi信号弱是物理层的事；交换机MAC地址学习错误、广播风暴是数据链路层的事；IP配置错、路由不通是网络层的事；端口不通、丢包重传是传输层的事；HTTP 404、DNS解析失败是应用层的事。
这样一分，问题就能被快速切割。比如你在浏览器里输入域名打开网页，如果页面打不开，你至少知道该先查DNS解析、再查TCP连接、再查HTTP响应，而不是漫无目的地一遍遍刷新。
1.2 四层模型和七层模型的映射关系
实际工程里几乎不会按七层逐一排查，日常开发更常用TCP/IP四层模型。两者的映射大致如下：
- 应用层：对应OSI的应用层、表示层、会话层，HTTP、DNS、FTP这些协议都在这层
- 传输层：对应OSI的传输层，TCP和UDP
- 网络层：对应OSI的网络层，IP、ICMP、ARP在这里
- 网络接口层：对应OSI的数据链路层和物理层，以太网、Wi-Fi属于这层
我建议初学者直接用四层模型建立主干，把七层模型作为补充知识。尤其是OSI把应用层拆成三层这件事，是早期协议设计理念分化的产物，现代网络实践中不需要过度纠结，知道有这么个说法就行。
提示：分层的真正价值不是会背每一层叫什么，而是出了问题能第一时间判断该看哪一层的证据。判断依据就是故障表现。
1.3 封装与解封装：数据在网络中的“套娃”过程
我理解数据流动时，觉得最有用的是一个类比：寄快递。应用层的数据相当于你写好的信件；传输层负责给信件套一个信封，写上用什么协议、目标端口是多少；网络层再套一个大袋子，写上寄件地址和收件地址，也就是IP地址；数据链路层最后贴上物流单，对应MAC地址，交给物理线路运输。
收件时逐层拆开，最终把信件交到应用手里。这个过程在计算机网络里就叫封装与解封装。记住这个“套娃”流程，后面理解TCP握手、HTTP报文结构、Wireshark抓包里的每个字段归属哪一层，都会变得非常自然。
2. 网络层：IP地址、子网掩码与路由，网络真正的“地图系统”
2.1 IP地址：主机在网络中的门牌号
IPv4地址一共32位，通常写成四段点分十进制，比如192.168.1.10。它的核心作用就是让数据包在网络上找得到目的地，所有联网设备至少要有一个IP地址，这是网络层通信的前提。
实际操作中还要区分公网IP和私网IP。公网IP全球唯一，由运营商分配；私网IP在局域网内使用，常见的有10.0.0.0/8、172.16.0.0/12、192.168.0.0/16三段，不同局域网之间可以重复使用，只有经过NAT转换后才能访问公网。
这个区分我特别看重，因为很多人排查问题时，看到机器的IP是192.168.x.x就直接开始怀疑内网配置，却忽略了出口NAT这条链路也可能出问题。
2.2 子网掩码与CIDR：判断两台主机是否“同网”
有了门牌号，还要知道哪些主机在同一个院子里。子网掩码就是用来划院墙的。IP地址和子网掩码按位做AND运算，得到的结果就是网络地址。如果两台主机的网络地址相同，它们就在同网段，可以直接二层通信，不需要经过路由器；否则就要交给默认网关处理。
举一个我常用的计算例子。假设IP是192.168.1.130，掩码是255.255.255.128，也就是/25：
- IP二进制：11000000.10101000.00000001.10000010
- 掩码二进制：11111111.11111111.11111111.10000000
- AND运算结果：11000000.10101000.00000001.10000000，即192.168.1.128
所以这个地址所在网络是192.168.1.128/25，可用主机地址范围是192.168.1.129到192.168.1.254。这个例子我经常让同事做，发现大家平时用192.168.1.0/24用习惯了，一旦掩码变成/25或/26，特别容易把边界算错，要么分配出冲突IP，要么写错路由规则。
2.3 默认网关和路由表：数据包走向哪里的决策依据
主机要发给非本网段的包，会先交给默认网关，也就是路由器。路由器查路由表决定下一跳往哪走。路由表可以静态配置，也可以由动态路由协议生成。
实操层面，掌握两件事就行。第一，用ip route能看到当前机器的路由表；第二，默认路由通常指向0.0.0.0/0，意思是除了直连网段里的目标，其余都走这里。有一次线上机器突然访问不了外网，我一上来怀疑DNS，后来用ping测某个公网IP是通的，去ping域名却失败，才定位到是DNS配置问题而不是网络断开。这个案例说明，排错时先用IP连通性判断网络层是否正常，再回头查应用层解析。
2.4 ARP：IP地址如何变成MAC地址
ARP存在的意义很直接：IP地址是逻辑地址，但真正在局域网里传输数据帧靠的是MAC地址，所以发送方需要知道“这个IP对应的MAC地址是什么”。ARP会广播一个请求，拥有该IP的机器回一个应答，发送方把映射缓存下来。
这解释了一个非常常见的现象：第一次ping某台局域网机器时要等一小会儿，第二次就很快，因为ARP缓存已经生效了。我踩过的坑是，在跨网段通信时，如果目标机器不在同网段，ARP请求的目标其实是默认网关的MAC地址，而不是最终主机的MAC。不少新人会在这里抓狂，用Wireshark看到ARP问的不是目标IP就以为出了问题。
另外ARP本身没有认证机制，所以局域网里存在ARP欺骗风险。排错时发现“IP明明是通的，流量却去了奇怪的地方”，值得怀疑ARP表被篡改，可以在交换机上配置动态ARP检测这类防护。
2.5 NAT：让私网地址走到公网的关键转换
NAT的作用是把内网私有IP的报文转换成公网IP发出，再把回来的报文反解到内网主机。家庭路由器、企业出口网关都在做这件事。
原理简化成一句话：内网主机访问公网时，路由器把源IP和源端口替换成公网IP和新的端口，同时记录一张映射表；回包到达后，根据映射表反解回内网主机。好处是节省公网IPv4地址，也天然形成了一层隔离。
对开发排错的意义在于两点。第一，如果内网服务需要被外部主动访问，必须配置端口映射，把公网端口映射到内网IP的端口，否则外部永远连不进来；第二，当你从内网访问公网服务时遇到连接被重置或超时，除了检查服务端，还可以怀疑NAT设备的会话表是否出现异常，毕竟家用或小型办公设备在这种场景下出问题的概率不算低。
3. 传输层：TCP的三次握手、可靠传输与那些棘手的“粘包”
3.1 TCP和UDP的本质差异：可靠不是免费的
传输层有两个核心协议：TCP和UDP。TCP提供面向连接的、可靠的字节流传输；UDP是无连接的、尽力而为的报文传输。简单说，TCP像快递里的保价件，有回执、有追踪、丢件会补发；UDP像普通平信，寄出去就不管了，但胜在快。
这个差异直接决定了选型：文件传输、网页访问、数据库连接这类不能丢数据的场景选TCP；直播、语音通话、游戏同步这类可以容忍少量丢包但要求低延迟的场景选UDP。我自己做过一个多人对战小游戏，角色位置同步用的就是UDP加自定义重传逻辑，如果全量走TCP，延迟一高，体验立刻劣化。
3.2 三次握手：为什么不是两次
TCP建连的三次握手是SYN、SYN-ACK、ACK，核心目的有两个：让双方确认“我的发送能力、接收能力都正常”，同时各自初始化序列号，为后续有序传输打好基础。
为什么必须是三次而不是两次？关键在于防止历史重复连接请求干扰。设想网络里有一份延迟了很久的SYN报文，如果只要两次握手，服务端收到这个旧SYN就会建立连接并分配资源，白白产生一条错误连接。三次握手让服务端等客户端的最后一次ACK确认“客户端确实收到了我的SYN-ACK”，从而判断这条连接是否新鲜。理解到这个层面，比单纯背“SYN, SYN-ACK, ACK”要扎实很多。
实际开发里，三次握手对性能的影响也值得关注。高并发短连接服务会出现大量握手开销，所以HTTP层才会有Keep-Alive、连接复用等优化，本质都是尽量少做TCP握手。
3.3 四次挥手与TIME_WAIT：容易被忽略的“连接尾巴”
TCP断开连接需要四次挥手：主动方发FIN，被动方回ACK，被动方再发FIN，主动方最后回ACK。很多人不理解为什么挥手要四次，其实原因很朴素：TCP允许半关闭，被动方收到FIN后可能还有数据要发，所以ACK和FIN被拆成两次。
这里最值得工程关注的是TIME_WAIT状态。主动关闭连接的一方在发出最后一个ACK后，要进入TIME_WAIT，等待2MSL后才完全关闭。原因有两个：一是确保最后的ACK能到达对方，如果丢了可以重发；二是让旧连接中的延迟报文在网络中消失，避免干扰复用同一四元组的新连接。
我在某次压测时看到大量TIME_WAIT，第一反应是调小系统参数，后来才明白TIME_WAIT是TCP的安全机制，盲目调小可能引发数据混乱。真正该做的是调整业务层的连接复用策略，而不是在系统参数上硬切。
3.4 粘包、半包：应用层必须解决的消息边界问题
TCP是流式协议，没有消息边界。发送方调用两次send，接收方不一定分两次recv收到，可能一次收到两段数据（粘包），也可能一段数据被拆成两次接收（半包）。这是开发网络协议栈时绕不开的经典问题。
我常用的处理方式有三种：
- 固定长度：每个消息固定N字节，不够填充，简单但浪费空间
- 分隔符：每个消息末尾加特殊标记，比如按行解析时用换行符分隔，但要保证内容里不会出现这个分隔符
- 长度前缀：每个消息开头用固定字节数记录消息体长度，这是最通用的做法
以长度前缀为例，读数据时先读4字节得到长度L，再等缓冲区攒够L个字节再切出一条完整消息。实现了这套逻辑，大部分“粘包半包”问题就迎刃而解了。跨语言对接时，还要约定长度字段的字节序，用大端还是小端，否则又是一场排错灾难。
3.5 TCP的拥塞控制：可靠之外的“网络友好”
TCP不仅要保证可靠，还要避免把网络灌爆。拥塞控制是一套动态调节发送速率的机制，核心算法包括慢启动、拥塞避免、快重传和快恢复。
- 慢启动：连接刚建立时拥塞窗口从很小开始，每收到一个ACK窗口翻倍增长，直到达到慢启动阈值，避免一开始就把网络打满
- 拥塞避免：超过阈值后，每个往返时间只增加一个MSS，线性增长
- 快重传：收到三个重复ACK就认为包丢了，不等待超时立刻重传
实操中，如果你发现大文件传输性能不理想，可以先确认是不是拥塞控制限速，比如在内网高速传输时，调整初始窗口或关闭Nagle算法往往能明显改善吞吐。不过这类调优项都要放在可控环境里验证，线上盲目改参数风险很大。
4. 应用层：HTTP、HTTPS与DNS，日常开发天天打交道的部分
4.1 HTTP协议的基本结构：请求行、头、消息体
HTTP是应用层使用最广泛的协议之一。一个请求由请求行（方法、URL、版本）、请求头、空行、请求体四部分组成，响应则对应状态行、响应头、空行、响应体。
日常开发里，最值得记的是状态码分类：2xx表示成功，3xx表示重定向，4xx表示客户端错误，5xx表示服务端错误。遇到问题先看状态码，基本就能定位到责任方。有次我的同事对接第三方接口，接口一直返回401，查了半天才发现是请求头里的Authorization字段格式写错了。这类问题如果先看状态码含义，会少走很多弯路。
4.2 从HTTP到HTTPS：TLS握手发生了什么
HTTPS不是新协议，而是HTTP跑在TLS之上。TLS握手的关键步骤可以压缩成三部分：协商加密套件和版本、验证服务端证书、交换密钥材料生成会话密钥。
对非安全背景的开发者的建议是，不需要背每个TLS扩展的细节，但一定要理解“证书是验证对方身份的，密钥交换是为了让双方拥有同一把只有彼此知道的对称密钥”。有一次外网接口HTTPS握手失败，我用curl -v看到证书链不完整，服务端漏发了中间证书，客户端无法验证证书链路，问题就出在这里。这个定位思路比反复翻日志高效得多。
4.3 DNS解析：上网背后的“电话簿”机制
DNS把域名解析成IP。整个查询过程包含递归和迭代：客户端向本地DNS服务器发起递归查询，本地服务器再向根、顶级域、权威服务器逐级迭代查询，得到结果后缓存一段时间，也就是TTL。
DNS问题有个典型特征：域名不通但IP能通，或者换个网络环境就正常了。常见原因包括本地缓存了错误记录、hosts文件被改、某些情况下公共DNS返回了不一致的结果等。我排这种问题时，会先用dig或nslookup查一下域名解析结果，再用curl直接访问返回的IP来区分到底是解析问题还是网络连通问题。清理本地DNS缓存也是常用操作，比如在Windows上用ipconfig /flushdns，在macOS上用dscacheutil -flushcache。
4.4 HTTP连接优化：从Keep-Alive到HTTP/2多路复用
一次HTTP请求如果每次都要新建TCP连接，代价太高了。HTTP/1.1推出Keep-Alive，让多个请求复用同一条TCP连接；HTTP/2更进一步，在一条物理连接上用流ID实现多路复用，多个请求并行传输，互不阻塞。
这个演进背后其实是对TCP握手成本和队头阻塞问题的持续优化。做接口性能优化时，如果把压测从HTTP/1.1换成HTTP/2，同样网络条件下延迟和吞吐会明显改善，因为省去了大量握手过程。这也是新服务可以优先考虑开启HTTP/2的原因。
5. 排错时我走的固定流程：分层定位、逐层排除、看证据说话
5.1 分层定位法：先确定故障在哪一层
排查网络故障最怕东摸一下西摸一下。我自己的固定流程是从应用层往下逐层验证：
- 先用浏览器或curl访问目标服务，看HTTP状态码和响应时间
- 域名访问异常时，用dig/nslookup确认DNS能否解析
- 用ping目标IP确认网络层连通性，注意ping不通不一定代表服务不可用，可能只是对方禁了ICMP
- 用telnet或nc探测目标端口是否开放，确认传输层是否正常
- 必要时抓包查看TCP握手和实际报文，定位数据链路层以下的问题
这套流程相当于把知识地图变成操作手册。很多“莫名其妙”的问题，走一遍就能定位到具体层。
5.2 一个真实排查案例：网页访问“卡顿”到底是谁的锅
有次有同事反馈内网系统访问很慢。我按流程来：先看请求瀑布图，发现静态资源加载耗时极高；然后ping静态资源服务器IP，发现延迟不高但丢包率有波动；再用traceroute检查路径，发现某一跳的延迟和丢包明显异常；最后确认是某个网络节点拥塞。整个过程没有拍脑袋，完全依据不同层的证据逐步收窄范围。
这里有个容易被忽略的细节：ping测的是ICMP包，和实际业务的TCP包可能走不同路径，或者被某些设备的QoS策略区别对待。所以ping通、ping快，不代表业务流量就一定快。必要时直接抓业务端口的包，看TCP重传率，这个指标往往比ping值更能说明问题。
5.3 常用网络命令工具箱
我把日常用的命令整理成一张表，方便检索：
| 目的 | 命令 | 输出关注点 |
|---|---|---|
| 查看IP和路由配置 | ip addr / ip route | IP、掩码、网关是否正确 |
| 测试连通性 | ping | 丢包率、RTT是否波动 |
| 路径追踪 | traceroute（Linux）/ tracert（Windows） | 每一跳的延迟和丢包，定位瓶颈节点 |
| 查看端口监听 | ss -lntp / netstat -an | 监听状态、连接队列 |
| 测端口连通 | telnet IP 端口 / nc -vz IP 端口 | 能否建立TCP连接 |
| DNS解析 | dig / nslookup | A记录、CNAME、TTL |
| HTTP调试 | curl -v | TLS握手、DNS解析、状态码、响应头 |
| 抓包分析 | tcpdump / Wireshark | TCP重传、握手时间、可疑报文 |
5.4 抓包时要注意的边界意识
抓包能解决很多疑难杂症，但也要有边界意识。第一，最好在可控的测试环境复现问题，避免在线上直接大规模抓包，涉及敏感数据时必须脱敏或避开业务高峰；第二，如果抓到的流量是加密的，就只能看握手和连接状态，看不到应用层内容，不要因此误判“服务端没响应”；第三，抓包文件别随意转发，里面可能包含IP、域名、端口等信息，按最小权限原则保存和处理。
6. 如果只记住一点——协议都是为解决工程问题而生的
6.1 用“问题-方案”的思路学协议
如果这篇笔记能让大家记住一件事，我希望是：计算机网络不是一堆需要死记硬背的协议名词，而是一套用“分层”思想解释的现实系统。每个协议的出现都对应具体的工程问题：IP解决寻址，TCP解决不可靠网络上的可靠传输，DNS解决人记不住IP的问题，HTTP解决应用交互格式的问题。顺着“问题-方案”这条线去学，比按章节背名词高效得多。
6.2 后续系列我会接着写什么
下几篇我打算按这个路径继续：IP的NAT与私网穿透细节、TCP拥塞控制参数的实际调优、HTTP/3与QUIC的设计思路，以及一些更偏实操的抓包案例分析。如果你手头正好有网络疑难杂症，建议先按这篇的排查流程走一遍，至少能帮你把问题范围从“整个网络”缩小到某一层，后面再深入也更有方向感。
