最近把自己的计算机网络学习笔记重新整理了一遍从协议栈到抓包排查从理论到真实故障案例梳理成了一条从零基础到能独立排障的完整路径。这个系列笔记算是我这些年踩坑经历的沉淀现在公开出来希望能让正在啃计算机网络的人少走一些弯路。这个系列的内容不是教科书式的知识点罗列而是按“一条数据包从浏览器出发经历网卡、交换机、路由器最后到达服务器”的完整旅程来组织的。适合几类人一是刚接触网络、被各种协议名词劝退的新手二是写业务代码多年但对网络底层始终一知半解的后端工程师三是准备面试、需要系统梳理网络知识体系的求职者。只要你能熟练使用电脑愿意跟着做一些抓包实验这套笔记就能带你从“知道几个名词”走向“能定位网络问题”。1. 学网络前先想明白的三件事方向比努力重要很多人在网络学习上花了不少时间效果却很差问题通常不是不够努力而是方向没搞对。我在笔记的开头部分就写了自己当年踩过的坑后来总结成三个关键认知这里先分享出来。1.1 别急着啃协议先理解“为什么要分层”绝大多数人学网络是从背七层模型开始的但背完没多久就忘因为它们只是抽象的名词外壳。真正需要理解的是分层这件事本身的动机控制复杂度。我习惯用一个类比来解释一家公司分成销售部、研发部、人事部每个部门内部怎么运作不用其他部门管只要部门之间的接口约定好就行。网络分层也是同样的逻辑每一层只负责自己那一段工作只跟上下层打交道协议内部怎么实现是各层自己的事。比如HTTP只管“我要请求什么资源”它不关心数据怎么走TCP只管“保证数据可靠到达”它不关心目标服务器在哪IP负责“把数据从源地址送到目的地址”以太网负责“在同一个物理链路里把帧从一台机器送到下一台机器”。每一层干好自己的事又能通过标准接口配合起来整个网络才能由无数厂商的设备、软件组合而成。所以不要纠结七层还是四层心里有“五层模型”应用层、传输层、网络层、链路层、物理层就够了。关键是分清每一层解决什么问题以及数据从上层往下层走时每层做了什么手脚。1.2 学网络最常见的误区把“知道”当成“会用”我见过一个很典型的场景有人能把TCP三次握手的过程背得滚瓜烂熟但打开抓包软件看到SYN、SYN-ACK、ACK三个包时仍然对不上号。这属于“知道概念”和“会看现象”之间的断层。学计算机网络必须有一个验收标准能不能完整讲清楚一次网页访问里数据是怎么从浏览器到达服务器的。如果能对着一台陌生电脑讲清楚浏览器先查DNS拿到IP然后通过TCP三次握手建立连接再把HTTP请求封装成数据段加上IP头变成包加上以太网头变成帧最后通过网线发出去——每一层做了什么事、加了什么头、对面怎么拆封这才算真正入了门。这个系列笔记的核心主线就是抓住“一次完整的访问流程”所有的知识点都挂在主线上。你不需要先把所有协议都学完再开始连链路应该反过来从一次请求出发遇到什么协议就学什么协议这样知识是成体系的不是散点。1.3 给自己的学习定三个层次目标为了避免学着学着迷失方向我在笔记里给读者定了三个递进目标每达成一个就上一层台阶第一层能画图能解释。把五层模型画出来说出每层的核心协议、核心设备、数据单位。这一层一周左右就能做到。第二层能走通全链路。输入一个网址回车之后从DNS到HTTP到TCP到IP到以太网每一步发生了什么都能不看资料讲出来。这一层是面试考察的黄金标准。第三层能排障。网络不通时会用工具分层排查能判断问题出在DNS、连接、路由还是应用层能看懂抓包文件能找到关键证据。这一层要靠实验和真实故障来积累。我建议你把这三个目标写到便签上学每个知识点时问自己它属于哪一层对达到哪个目标有帮助。这样学起来就不会东一榔头西一棒子。2. 完整知识地图一条数据包的旅行记录这是整个笔记里篇幅最大、也最核心的一章。我们跟着一条数据包走一遍全程把DNS、HTTP、TCP、IP、ARP这些看似零散的协议串成一个故事。2.1 从浏览器输入地址开始DNS与HTTP假设你在浏览器地址栏输入了一个网址并按下回车第一步不是发HTTP请求而是先解析域名。因为TCP/IP协议栈只认IP地址不认域名所以必须先通过DNS把域名翻译成IP。DNS的查询过程有两种方式。一种是递归查询你的电脑把域名发给本地配置的DNS服务器由它替你去问根服务器、顶级域服务器、权威服务器最后把IP拿回来。另一种是迭代查询本地DNS服务器让客户端自己去问根、问顶级、问权威拿到结果逐级返回。日常使用中绝大多数是递归方式你只需要能区分这两个概念就行。这里有个容易被忽略的点DNS缓存。你的电脑、路由器、本地DNS服务器、浏览器都有各自层级的缓存。所以当你改了域名解析记录老是发现“没生效”往往就是某一层缓存没刷新。排查DNS问题时第一件事就是先确认查询的是哪台DNS服务器、拿到的是不是最新IP。解析出IP之后浏览器才会发起HTTP请求。HTTP本身是基于文本的协议请求行、请求头、请求体都是明文格式HTTPS则是在HTTP外面套了一层加密。关于HTTP入门阶段不需要背所有细节但有几个点必须烂熟于心请求方法GET用来获取资源POST用来提交数据PUT整体替换PATCH部分更新DELETE删除。面试常问GET和POST区别本质上GET是幂等且语义上不改变服务端状态POST不是。状态码2xx成功3xx重定向4xx客户端错误5xx服务端错误。特别是304未修改走缓存、403禁止访问、404不存在、502网关错误、504网关超时。Connection头HTTP/1.1默认Keep-Alive连接复用这是为什么一个网页几十个资源不需要每次都新建TCP连接。端口在这里起到了“房间号”的作用。一台服务器的IP是“楼栋地址”端口是“房间号”。HTTP默认80HTTPS默认443MySQL一般是3306Redis一般是6379。你连接不上服务时先确认端口对不对有没有被防火墙拦。2.2 TCP与UDP可靠性与效率的取舍浏览器拿到IP后就要和服务器建立TCP连接了。TCP最重要的设计目标是可靠传输——保证数据不丢、不乱序、不重复。它的手段听起来不复杂但组合起来很精妙三次握手客户端发SYN序号为x服务器回SYNACK确认x1同时带上自己的序号y客户端再回ACK确认y1。为什么不是两次因为两次握手无法确认双方的接收能力都正常也无法防止历史失效连接请求突然到达造成误开连接。我不建议死记“三次是为了可靠”你可以自己想想如果只有两次握手服务器怎么知道客户端已经收到了自己的SYN四次挥手因为TCP是全双工的每一方都要单独关闭自己的发送通道所以需要四次。实际抓包中经常看到三次挥手那是因为有一方把ACK和FIN合并了。序号与确认号这是TCP可靠传输的基础。发送方给每个字节编序号接收方回确认号表示“你发到这儿为止我都收到了”。如果发送方没收到确认就会超时重传。滑动窗口控制发送速度让接收方能处理得过来。窗口大小由接收方的缓存能力和网络状况共同决定。拥塞控制慢启动、拥塞避免、快重传、快恢复这些算法决定了TCP在丢包时的行为。你知道一个大概就行当网络拥塞丢包TCP会主动降低发送速率这就是为什么网络差时下载变慢——不是带宽不够是TCP在“自我限速”。UDP和TCP正相反它不建立连接不保证可靠头部只有8字节开销极低。所以视频通话、语音、实时游戏这类能容忍少量丢失、但对延迟极其敏感的应用更倾向于用UDP。近年的QUIC协议更进一步在UDP之上自己实现了可靠性和加密兼顾了效率和可控性。这里必须提一个和实际排障强相关的参数MTU与MSS。以太网的MTU通常是1500字节意味着一个IP包最大1500字节。TCP段经过IP层封装后不能超过这个数所以TCP的MSS最大分段大小一般是1500 - 20字节IP头 - 20字节TCP头 1460字节。如果应用层要发一个4KB的数据TCP会分成3段来发。一旦某个环节MTU变小比如PPPoE拨号是1492就容易出现大包被丢弃、小包正常表现为“网页加载不出来但ping能通”。这个故障很经典后面排查章节会再讲。2.3 IP层与链路层寻址、路由与封装TCP负责把数据可靠地从进程传到进程但它不管你人在哪、服务器在哪。这个“跨网络寻址”的事情由IP层来做。IP的核心是地址和路由。IP地址是逻辑地址目前主流是IPv432位通常写成四段十进制。早期按类别分A/B/C类现在用无类别域间路由CIDR来表示比如192.168.1.0/24表示前24位是网络号后8位是主机号。有几个私网地址段需要记住10.0.0.0/8、172.16.0.0/12、192.168.0.0/16这些地址只能在内部网络使用公网路由器不转发。你家里路由器给手机分配的一般就是192.168.x.x这也是为什么你在外面访问不了家里电脑直接暴露的IP——因为那是私网地址需要做端口映射或内网穿透。**NAT网络地址转换**是这个逻辑背后的关键机制。多台私网设备共用少量公网IP时路由器会把内部IP和端口映射到公网IP的不同端口维护一张映射表回来时再反向转换。理解NAT对排查“我能上网但别人访问不了我”这类问题很有帮助。路由表决定了IP包往哪个方向走。每台主机和路由器都有一张路由表匹配到目的网段后选择下一跳。默认路由0.0.0.0/0表示“匹配不到更精确的路由就走这里”这通常就是你的默认网关。traceroute命令能看到数据包经过的每一跳路由器排障时非常有用。到了链路层还有一个不得不提的协议ARP地址解析协议。它解决的是“我知道目标IP但物理链路上要靠MAC地址找目标”的问题。发送方会广播一个ARP请求“谁是192.168.1.1请把你的MAC地址告诉我。”拿到回复后就把IP和MAC的对应关系放进ARP缓存表。注意ARP只能工作在同一个网段内跨网段的数据要靠网关的MAC来接收再转发。以太网帧是链路层的封装单位结构很简单目标MAC6字节、源MAC6字节、类型2字节、数据、FCS校验。IP包进入链路层后会被包成以太网帧通过网络传输。2.4 把链路串起来一次请求的完整封装过程如果前面都是局部知识点那这一节就是把所有零件装成整机的地方。我会要求读者亲手画一张“数据包套娃图”这也是我整个笔记里最得意的一张图以太网帧头 | IP头 | TCP头 | HTTP数据 | 以太网帧尾从下往上的视角来看一次真实的访问流程是这样的应用层浏览器构造HTTP请求内容比如GET /index.html HTTP/1.1。传输层TCP把HTTP数据切成合适大小加上TCP头源端口、目的端口、序号、确认号形成数据段。网络层IP把TCP段加上IP头源IP、目的IP、TTL、协议号形成数据报或者说数据包。链路层以太网把IP包加上源MAC和目标MAC形成以太网帧。物理层把帧转成电信号/光信号从网卡发出去。接收方收到后做相反的事情从以太网帧里分出IP包从IP包里分出TCP段TCP校验数据完整性最后把HTTP请求交给服务器进程。这个封装过程最关键的理解点在于每一层只处理自己需要的那部分头部信息上层的数据内容对下层来说就是“一堆要搬运的货物”。这就是“分层”带来的巨大价值也是面试里常问的“HTTP数据在TCP/IP中如何传输”的完整答案。我这里有个笨办法帮助记忆把发送过程想象成往包裹里装货。你写了一封信HTTP装进一个信封写上收发人房间号TCP端口再把这个信封塞进一个大快递箱写上收发人门牌号IP地址最后在快递箱外贴上物流面单MAC地址和帧头。快递员物理层只认面单地址他不知道你信里写的是什么。这个类比虽然不完美但足够让新手建立整个流程的画面感。3. 动手实践从0搭一套看得见的网络环境学网络一定不能只看书必须配合抓包实践。因为很多机制是“看不见摸不着”的但一旦你能亲眼看到三次握手的三个包、亲眼看到DNS查询的流程、看到丢包时TCP的重传理解就会完全不同。3.1 工具准备清单与应用场景我并不建议一上来就折腾很多重型软件。手边有下面几个工具就足够完成90%的入门实验了。工具用途学习阶段ping测试基本连通性与RTT延迟入门必用traceroute / tracert查看数据包经过的路由路径入门必用nslookup / dig查询DNS解析结果排查域名问题入门必用telnet / nc测试指定IP和端口是否可达中级必用curl模拟HTTP请求查看请求响应细节中级必用Wireshark图形化抓包分析看协议细节核心工具tcpdump命令行抓包适合服务器端排查核心工具ss / netstat查看本机端口监听与连接状态常用工具Wireshark需要在有图形界面的电脑上使用适合做协议学习时的深度分析。tcpdump更适合在服务器上快速抓包分析往往排查真实问题靠的是tcpdump而不是Wireshark。安装方法不赘述了不同系统用对应的包管理器安装即可。需要注意抓包权限Wireshark在Linux上需要组权限macOS上可能要授权。命令行工具如果没权限加sudo。3.2 亲手抓一次TCP三次握手包这一节是必做实验做完之后你对三次握手的理解会超过看十篇文章。以Wireshark为例操作步骤如下打开Wireshark选择你上网用的网卡无线上网就选Wi-Fi网卡有线就选以太网网卡点击开始捕获。打开浏览器访问一个你自己可控或低访问压力的普通网站等页面加载完。回到Wireshark点击停止捕获。在过滤栏输入tcp.port 443如果访问的是HTTPS站点或http如果是HTTP站点按回车过滤。你会看到至少三个TCP包Flags标记依次是SYN、SYN, ACK、ACK。点开第一个SYN包在TCP层看Sequence Number比如0再看相对序号再点SYNACK包看Acknowledgment Number是不是第一个包的序号加1。对照一下你就能理解“确认号是在对方序号基础上加1”这句话的真实含义。做完这个实验我建议你再做一次“看关闭连接”的实验关闭浏览器之前开始抓包然后关闭标签页观察FIN包。你会发现挥手有时是三次有时是四次接着去查原因记忆会很深。做实验时有一个安全提醒只访问你熟悉、常规、确定安全合规的网站不要去接触任何非正常渠道提供的网络服务或工具。网络分析学习用的是公开的常规流量靠抓包能够观察到的协议行为在这些流量里已经足够完整。3.3 模拟延迟与丢包亲眼看到TCP重传真实网络里的丢包和延迟往往不可控但我们可以手动制造这些场景来观察TCP的反应。在Linux环境虚拟机或本机都可可以用tc命令做网络损伤模拟。比如给网卡模拟100毫秒延迟和10%丢包# 添加模拟规则 sudo tc qdisc add dev eth0 root netem delay 100ms loss 10% # 查看规则 sudo tc qdisc show dev eth0 # 删除规则 sudo tc qdisc del dev eth0 root模拟开启后在另一台机器或本机用ping验证延迟和丢包率再用tcpdump抓包观察要传送的数据你会发现TCP对没有收到确认的包进行了重传。这个实验最大的价值是让你直观理解“TCP的可靠性是靠重传机制实现的而不是网络本身不丢包”。现实中我遇到过很多工程师对“为什么网络会卡”没有概念总认为是服务器处理慢。亲手制造过丢包之后你会第一时间想到用tcpdump检查是否有重传。再补充一个实用技巧在你自己的业务代码里可以用curl的计时参数来分层判断耗时curl -o /dev/null -s -w DNS: %{time_namelookup}s\n连接: %{time_connect}s\nTLS: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总计: %{time_total}s\n https://example.com如果DNS耗时高说明解析有问题如果连接耗时高说明握手或路由有问题如果首字节到总计之间耗时高说明服务端处理慢。这个命令在面试项目里也是亮点。3.4 用本机环境练习端口与服务排查端口排查是网络日常运维里最常见的工作。假设你自己在本机启动了一个简单的HTTP服务想验证它是否正常工作直接用curl http://127.0.0.1:8080/测试就行。但如果访问不通怎么分层排查呢先用ss -lnt查看端口是否在监听ss -lnt输出里看LISTEN状态的地址有没有*:8080或0.0.0.0:8080。如果没有服务根本没起来如果有再用telnet 127.0.0.1 8080测试本机能不能连上。本机能连上而外部不能连那问题基本就在防火墙或云平台安全组。这种“从小到大、从近到远”的排查方法论和网络协议栈的分层思想是一模一样的。4. 工程师最常见的网络故障排查手册有了前面这些基础就已经具备进入排障实战的能力了。这一节我会分享一套分层排查思路和几个高频故障的排查手册都是用真金白银换来的经验。4.1 排查铁律从下往上逐层收敛遇到网络问题最怕的就是瞎猜。我的铁律非常简单先确认下层再查上层绝不跳层。标准顺序是先看物理层和链路层网线松没松、Wi-Fi信号、交换机端口灯、ARP表是否正常。再看网络层ping默认网关通不通ping公网通不通路由表对不对。再看传输层端口是否监听、连接状态是ESTABLISHED还是SYN_SENT、防火墙规则。最后看应用层DNS解析对不对、HTTP响应码是什么、证书是否过期。这个顺序对应着协议栈的层次每一层都依赖下层正常。如果物理链路都不通去查HTTP状态码是浪费时间。我经常看到有同事一上来就怀疑代码、怀疑Nginx配置结果查半天发现是网卡驱动挂了这就是没有分层思想的典型代价。4.2 高频问题速查表整理了我实际工作中遇到最多的几类问题方便你直接对照参考现象可能原因快速排查命令/操作解决思路浏览器打不开网页但ping外网IP通DNS解析失败或缓存异常nslookup 域名检查解析结果dig 域名看详细过程换DNS如223.5.5.5等常规公共DNS刷新DNS缓存检查hosts文件ping通但应用连接超时目标端口未监听/防火墙拦截/安全组未放行ss -lnt看监听telnet IP 端口测端口放行端口或启动服务注意云平台安全组和本机防火墙两层都要看内网访问慢丢包严重交换机环路/广播风暴/带宽跑满ping -f或连续ping观察丢包率数据查看端口流量检查环路查看端口错误计数做带宽限速能上微信但网页加载不出来MTU问题/HTTP被干扰/DNS污染ping -M do -s 1472测MTU大小调整MTU为1492或1400检查代理设置和DNS配置同一网段无法互访ARP表异常/防火墙隔离arp -a查看邻居表清ARP缓存检查设备隔离设置公网服务器登录卡顿、断连链路延迟/RTO设置/丢包mtr 目标IP查看每一跳延迟与丢包定位瓶颈跳考虑切换线路检查本地网络质量服务端有很多TIME_WAIT连接短连接大量建立ss -tan state time-wait开启Keep-Alive调整连接池复用TIME_WAIT是正常回收偶发超时现象复现困难TCP重传/负载过高/网卡软中断tcpdump -i eth0 tcp port 8080抓包观察重传与RST结合应用日志、系统负载、网络抓包综合定位这张表不需要背关键是理解每一类问题的排查入口。4.3 一个真实排障案例从超时到网卡队列的追查过程分享一个我实际处理过的案例过程很有代表性。当时某内部系统收到反馈说服务每隔几分钟就会出现一次连接超时持续几秒后自动恢复。第一次遇到时本能地怀疑是应用线程池满或者数据库慢查询但查了日志没有发现明显异常。我决定按分层思路做一次完整排查第一步从客户端到服务器逐跳ping。用mtr看每一跳的丢包率发现某个中间路由有少量丢包但丢包规则是突发性的不是持续丢包。第二步在服务器上用tcpdump抓TCP流量过滤出有几个 SYN 没收到对应SYNACK。这说明SYN包发出去了但服务器没回或者回包丢了。由于回包路径和请求路径一样排除了路由单点问题焦点转移到服务器自身的处理能力。第三步查看服务器网卡统计信息用ethtool -S eth0观察rx_dropped、rx_missed等计数发现每次超时发生前rx_missed都在涨。这个计数说明网卡有数据到了但驱动或环形缓冲区没来得及处理只能丢弃。原因锁定到了网卡队列中断分布不均或者中断被CPU迁移了。第四步把网卡多队列和中断绑定固定到特定CPU核心并适当调大环形缓冲区问题得到解决。这个案例给两个启发一是排查要有顺序不要上来就怀疑应用二是要会用工具拿到“证据”不能靠感觉。抓包文件和网卡计数器都是客观证据比任何推断都有说服力。4.4 几个独家避坑经验多年排障下来有几条经验是文档里不会写、但实际特别有用的先看现象再提假设最后验证。不要根据经验直接下结论。有一次所有证据指向DNS缓存清完缓存后问题还在结果发现是本地hosts文件里有一行过期记录。所以每一个结论都要有依据。很多“网络问题”其实是性能问题。连接建立慢、首字节慢未必是网络不通而是链路质量差或服务端处理慢。用curl的计时参数把耗时拆开能明确到底是哪一段慢。抓包要抓两端的包。一次连接失败单看客户端包只能看到“客户端发了SYN没等到回复”你不知道这台服务器的回包到底发没发出去。如果能在两端同时抓包立刻能定位是“服务器没回”还是“回包在路上丢了”。不要小看DNS缓存。很多时候改完解析记录觉得“没生效”其实是你电脑或路由器缓存了旧结果。用dig trace能看清从根服务器到权威服务器的完整查询链再配合看本地解析结果基本都能找到问题。5. 进阶路线与笔记方法怎么把知识变成自己的能力当你走通一条完整链路、会做基础排障之后计算机网络的大门才算真正打开。后面还有大量可以深入的方向我建议不要盲目铺开而是围绕自己实际工作的场景去延伸。5.1 几个值得深挖的方向如果你做后端开发接下来最相关的方向是HTTP演进与加密通信。HTTP/2的多路复用解决了队头阻塞HTTP/3基于UDP的QUIC把连接迁移和加密做得更顺滑TLS握手与证书链也是面试常客。学这些之前先把TCP和HTTP基础打牢否则很容易糊。如果你做运维或基础设施容器网络和云网络是你绕不开的。Docker的bridge网络、Kubernetes的Pod网络、Overlay隧道、VPC与安全组本质上都是IP、路由、端口的组合应用。理解了基础协议栈再学这些概念会很快。如果你对底层感兴趣图解TCP/IP、TCP/IP详解这类经典书籍可以继续啃。重点看TCP状态机、IP分片、路由协议OSPF/BGP的细节这些虽然日常用得少但决定了你能否解决深层问题。5.2 我的笔记整理方法我整理这个系列笔记时坚持了几个原则分享给你参考用自己的话重写。笔记不是抄书看到一段定义后合上书用自己的话写一遍。写不出来说明没懂重新看再合上再写。这样产出的笔记才是自己的。每章配一个案例。光写TCP重传原理记不住配一个用tc模拟丢包的场景记得特别牢。我在笔记里给每个协议都配了“实验观察”小节这才是笔记的价值所在。画图比写字重要。数据封装过程用套娃图画出来TCP状态机用状态图画出来路由过程用拓扑图画出来。一图胜千言回头看笔记时图的回忆效率远高于文字。定期回看并修正。我现在看以前写的笔记仍会发现一些理解不够准确、表达不够清晰的地方。每隔一段时间回头翻翻把过时的知识更新掉本身就是一种进步。可以用这种“发快递”的类比快速向人解释五层模型你写好一封信应用层HTTP封装进信封写房间号TCP端口写上门牌号IP地址贴上快递单链路层MAC和帧快递车物理层开始配送。对方按快递单、门牌号、房间号逐层拆封最终看到信的内容。把一个技术体系类比到日常生活场景是检验自己是否真懂的好方法——如果你能用大白话讲给一个完全不懂技术的人听说明你确实掌握了。5.3 学习节奏与自测清单如果你跟着这个系列学习我建议的节奏是每周一个主题每个主题配一个抓包实验学完后用自测问题清单检查自己。前几周建议这样安排第一周分层模型 ping/traceroute目标是能画出五层模型并说出各层职责。第二周DNS HTTP目标是用dig和curl完成域名解析和请求观察实验。第三周TCP握手与挥手目标是在Wireshark里找出对应的包并解释每个字段。第四周IP与路由目标是用traceroute观察跨网段路径用ip route理解路由表。第五周综合排障目标是把前面知识运用到速查表里的典型故障中。每一阶段结束后试着不看任何资料回答几个问题输入网址后发生了什么TCP为什么要三次握手一个数据包从你的电脑到服务器经过了哪些封装与解封装这五个问题如果都能答清楚你的网络基础就算过关了。我自己当年在梳理笔记的时候就是这么反复逼问自己才逐渐把零散的知识点变成了一张真正的知识网络。我个人在实际整理这套笔记时最大的体会是网络知识没有任何捷径唯一的“速成法”就是抓包和排障先建立全链路画面再填充细节。希望这份笔记能帮你少走一些弯路。