1. 学计网最大的坑:把名词背下来,却不知道数据包的一生
1.1 一次考前串讲让我意识到的问题
去年帮一个准备期末考的朋友做考前串讲,他翻开笔记本,里面记得相当认真:TCP 报文首部 20 字节、ACK 标志位、IP 首部有 TTL 字段、UDP 首部只有 8 字节、MAC 地址 48 位,甚至每个字段的顺序都画得清清楚楚。我随手问了他一个问题:现在用手机打开一个小程序,服务器上那段数据是怎么变成屏幕上的内容的?中间经过哪些环节?每个环节对应你背过的哪个概念?结果他沉默了半分钟,最后只挤出来一句“HTTP 请求,然后 TCP 连接?”——后面全乱了。
这就是很多人学计算机网络基础概念时的真实状态:懂名词,不懂系统;会背定义,不会串链路。计算机网络这门课难,不是因为单个概念难,而是所有概念都长在同一棵树上。物理层的信号、数据链路层的帧、网络层的数据报、传输层的段、应用层的报文,层层封装又层层拆解。如果脑子里没有一条“数据包的一生”主线,你背的每一个概念都是悬浮的碎片。
这篇文章我想换一个讲法。不打算从一个标准名词表开始,而是沿着一条主线走:一个数据包从发送方到接收方,到底经历了什么。顺路把分值最高、面试最爱问、期末最容易考的那些基础概念全部挂上去。适合几类人:一是马上期末复习、考研 408 需要系统性过一遍的朋友;二是刷“八股文”刷到怀疑人生、想真正理解协议为什么这样设计的同学;三是工作中遇到网络问题不知道怎么排查,想补一课的非科班开发者。
1.2 一次请求就是一张最好的概念地图
我们完整走一遍。假设你在浏览器地址栏输入 www.example.com 并按回车,后续发生的事情比你想象中多得多。
浏览器先查本地有没有这个域名的 DNS 缓存,没有就发起一次域名解析,把 www.example.com 换成对应 IP。拿到 IP 后,操作系统会和目标服务器建立一个 TCP 连接,这中间会用到三次握手、序列号、确认号。连接建好,浏览器生成一个 HTTP 请求报文,交给传输层,传输层给这段数据加上 TCP 首部,此时的数据单位叫“段”。网络层再给段加上 IP 首部,形成“数据报”,同时查路由表决定下一跳往哪走。真正从网卡出去前,数据链路层会把 IP 数据报包装成“帧”,在里面写上源 MAC 和目的 MAC。最后物理层把帧里的 0 和 1 变成电信号、光信号或者无线信号送上传送介质。
对方收到以后,做的是完全相反的动作:物理层收信号,数据链路层检查 MAC 地址并校验帧,网络层取出 IP 包并查路由表决定要不要转发到别的网络,传输层按端口号找到对应进程,应用层把 HTTP 报文交还给服务器程序。这个“包装—传输—拆包”的过程就是封装与解封装,整个计算机网络基础概念的地基就在这里。
你可以把整个过程想象成寄快递。应用层是你在购物网站填下的需求;传输层是快递公司给你分配了一个专属客服,这个客服确保货物完整到达;网络层是物流中心的路线规划系统,负责决定走哪条干线;数据链路层是快递员在同一个小区里按门牌号送件;物理层是那条真实的公路、铁轨和运货卡车。每一层只关心自己的环节,又通过统一接口为上一层服务,出问题时各层之间还能互相定位。
有了这条主线,所有高频考点都有了坐标:DNS 是第一步寻址,TCP 是传输可靠性,IP 是跨网路由,交换机工作在第二层,路由器工作在第三层。后面每个章节我都会回到这条主线,帮你把概念放回它真正出现的位置。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分层模型不是背七层:看职责边界才能学会排查
2.1 为什么会有 OSI 七层和 TCP/IP 四层两套模型
提到分层,几乎所有教材都会让你背 OSI 七层:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层,而且是从下往上背。很多人的痛苦在于:背了七层,却发现抓包工具里根本看不到“会话层协议”和“表示层协议”,为什么?
因为 OSI 七层是国际标准化组织画出的一套理想蓝图,它希望把复杂的网络通信拆成相对独立的模块,让不同厂商的设备和软件按统一框架各做各的。但现实世界里,互联网并不是从这套蓝图里长出来的,而是 TCP/IP 先跑遍了全球,然后教科书再回来补理论解释。TCP/IP 模型更务实,把应用层、表示层、会话层的很多事合并进应用层:加密可以放在 TLS,格式转换可以由应用自己处理,会话状态可以由 HTTP 的 Cookie 和 Token 维护,所以不需要每层都独立出来。
做题和面试时,你最好记住两个口径:理论题问“OSI 有哪七层”,按标准七层答;理解题问“实际互联网用什么模型”,按 TCP/IP 四层答。更保险的答法是先把两套模型对应上,然后补一句:OSI 是法律参考,TCP/IP 才是民间实际执行的规则。
2.2 每一层到底解决什么问题
分层模型的价值不在于“有几层”,而在于每一层都有清晰的职责边界。你只要理解不同层解决的是不同尺度的问题,就能记住大部分结论。
应用层解决的是“用户想要什么”。用户要的是一个网页、一封邮件、一个文件,而不是一串带时序号的数据段,所以 HTTP、DNS、SMTP 这些协议都直接面向用户需求。传输层解决的是“应用进程之间的通信问题”。同一台电脑上可能同时挂着微信和浏览器,数据来了以后给谁?靠端口号。传输层决定这段数据是采用握手的可靠传输,还是无连接的尽力发送。网络层解决的是“主机到主机”的路由问题。你家电脑在北京,服务器在杭州,中间穿过几十个路由器,网络层负责找到一条可行的路。数据链路层解决的是“相邻节点之间的传输”,也就是同一根网线、同一个交换机范围内,怎么把一个帧正确送到相邻设备的网卡。物理层解决的是最原始的问题:01 比特怎么变成能够在线缆或空气中传播的信号。
这里有一个非常实用的推论:排查网络故障时,不要一上来就怀疑路由器,而要先界定问题范围。如果只是小程序页面卡,先看应用层的请求是否超时、DNS 是否解析缓慢;再看传输层 TCP 有没有大量重传;最后检查本网段内链路是否丢包。如果整个网站完全打不开,用 ping 测网关、测公网 IP,逐层缩小范围。脑子里没有层,看到“网络异常,请稍后再试”这种提示,就只能懵着抓瞎。
2.3 一张表把 OSI、TCP/IP、协议和设备串起来
复习时这类映射表几乎是必背项,但更建议你带着“解决什么问题”去理解每一项。
| OSI 层级 | TCP/IP 对应 | 数据单位 | 代表性协议/技术 | 常见设备 |
|---|---|---|---|---|
| 物理层 | 网络接口层 | bit(比特) | 以太网物理层、Wi-Fi 的调制方式 | 中继器、集线器、网卡 PHY 芯片 |
| 数据链路层 | 网络接口层 | frame(帧) | 以太网、Wi-Fi、CRC 校验 | 交换机、网桥 |
| 网络层 | 网络层 | packet(数据报) | IP、ICMP、路由协议 | 路由器、三层交换机 |
| 传输层 | 传输层 | segment(段) | TCP、UDP | 常由操作系统内核承担 |
| 会话层/表示层/应用层 | 应用层 | message(报文) | HTTP、DNS、FTP、SMTP | 大量应用软件 |
注意一个容易被人抬杠的点:ARP 协议在很多教材里算网络层,但它干的活是查“同一个局域网内 IP 对应哪个 MAC 地址”,所以也有人把它归到数据链路层附近。考试按主流教材答,面试时可以补充一句“ARP 是 IP 和 MAC 之间的桥梁,实际工作时在局域网内广播”,这比死记归属更能体现理解。
3. 从网线到数据帧:物理层与数据链路层到底在“传”什么
3.1 物理层不是“网线”,而是信号与编码规则
期末复习时,有人觉得物理层最简单,不就是网线、光纤、Wi-Fi 信号么?其实物理层真正的考点是“同一个比特信号如何在介质上表达、用什么速率传输、受多大噪声影响”。
计算机内部用的是方波电平表示二进制,但网线上传的是经过编码后的信号。最典型的例子是曼彻斯特编码,它利用电压跳变来区分 0 和 1:从高电平跳到低电平代表 1,从低电平跳到高电平代表 0。这样做的好处是接收方可以从跳变中提取时钟信号,不需要单独传一根时钟线;代价是波特率不变时,比特率会下降。这能解释为什么早期以太网速率上不去,也能解释为什么后来又发展出多种更高效的编码。
物理层的计算公式同样是高频考点。无噪声理想信道下,奈奎斯特准则给出了极限数据率:C = 2W log2(V),其中 W 是信道带宽,V 是信号状态数量。比如带宽 3000Hz 的信道,用 4 种不同电平表示码元,极限速率就是 2 × 3000 × log2(4) = 12000bps。有噪声的真实信道则用香农公式:C = W log2(1 + S/N),其中 S/N 是信噪比。这两个公式常被混在一起出题,做题时要先判断题干有没有提“噪声”,再决定用哪个公式。
实际排查中物理层问题的症状也很典型:网卡指示灯不亮、Wi-Fi 信号忽强忽弱、双绞线用错直通线/交叉线导致交换机端口不识别、网线水晶头压线顺序不对造成百兆降级。绝大多数“网速突然变慢”的初级问题,最后都出在物理层,而不是 DNS。
3.2 数据链路层靠 MAC 地址和帧格式完成“同链路交付”
数据链路层要解决的,是数据帧从一台设备送到同一网络里的另一台设备。以太网帧的基本结构包括:目的 MAC 地址、源 MAC 地址、类型/长度字段、数据部分,以及用于校验的帧校验序列 FCS。交换机收到帧后做的事情可以用三句话概括。
第一,记录源地址:从哪个端口收到帧,就把帧里的源 MAC 和端口对应关系写进 MAC 地址表。第二,查找目的地址:查表找到目的 MAC 对应哪个端口,就从那个端口单播转发出去;查不到目的 MAC,就向除接收端口外的所有端口泛洪,让目标机器的网卡自己认领。第三,处理广播帧:目标 MAC 是全 F 的广播帧会被交换机转发到所有端口,这也是 ARP 等协议能工作的重要前提。
数据链路层还有个常和网络层混淆的知识点:IP 地址是“端到端”的,源 IP 和目的 IP 在通信过程中一般不改变;但 MAC 地址是“逐跳”的,数据每经过一个路由器,源 MAC 和目的 MAC 都会重新封装成下一段的链路地址。你可以把 IP 地址理解成“最终地址”,MAC 地址理解成“下一站地址”。考试里有个出烂了的题目:A 发给跨网段的 B,问经过路由器后帧里的源 IP、目的 IP、源 MAC、目的 MAC 分别是什么。记住逐跳封装思想,答案自然不会错。
数据链路层的另一个重点工作是差错控制。以太网用的办法是在帧尾加循环冗余校验码 CRC。发送方按多项式计算出一个冗余码附在后面,接收方用同样多项式再算一遍,结果不为零就判断帧出错并丢弃。CRC 不是纠错,是检错,它只能发现错误不能定位错误。这个细节在选择题里反复出现。
3.3 一个常见误区:交换机为什么不能替代路由器
你也许听过交换机“好像也能把多台电脑连起来上网”,但这和路由器是两回事。交换机工作在数据链路层,转发依据是 MAC 地址表;它处理的是同一广播域内部的数据帧。如果两个不同网段要通信,交换机不知道该把数据包送到哪条“路”上,必须有路由器参与。
路由器的每个接口都配了不同网段的 IP,它收到一个数据报后,剥掉二层帧头,读取 IP 目的地址,再查路由表决定从哪个接口转发出去,然后重新封装新的二层帧。用一个生活类比:交换机像一个小区物业,知道每户门牌号,负责在同小区内送快递;路由器像一个物流分拣中心,按城市、省份分拨包裹,把包裹送到正确的干线。家里组网时,路由器承担了“接入公网 + 分配内网 IP + 路由转发”的重任,而交换机只负责扩展同一网段内的网口数量。
4. 网络层的关键不只 IP:路由、ARP 和默认网关串起跨网通信
4.1 IP 地址、子网掩码与 CIDR 的本质是“两级定位”
我们现在说的 IP 地址仍然以 IPv4 为主,32 位二进制,写成点分十进制。一个常用地址如 192.168.1.100,本质上由两部分组成:网络号 + 主机号。网络号负责定位到哪个网段,主机号负责定位网段内哪台设备。子网掩码就是用来划出这两部分的尺子。掩码 255.255.255.0 写成二进制是前 24 位全 1、后 8 位全 0,表示 IP 前 24 位是网络号,后 8 位是主机号。
现代网络更常用 CIDR 写法,把掩码长度直接写在地址后面,比如 192.168.1.0/24。理解子网划分要会做几类计算:一个 /24 网段有多少可用主机地址?32 位地址,网络位占 24 位,主机位 8 位,理论上 2 的 8 次方等于 256 个地址,去掉主机号全 0 的网络地址和全 1 的广播地址,可分配给主机的就是 254 个。如果给的是 172.16.10.5/20,网络位是 20,主机位是 12,可用主机数是 2 的 12 次方减 2 等于 4094。这类题不能靠背,你得能熟练换算二进制。
传统 A、B、C 类地址已经过时了,但很多教材仍会提:A 类默认掩码 /8,B 类 /16,C 类 /24。考试如果给你一个 IP,让你判断属于哪类,你需要看第一个字节范围。更重要的是记住私有地址段:10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。私有地址只能在局域网内使用,访问公网时通常由路由器上的网络地址转换 NAT 机制把它映射成一个公网地址,这是 IPv4 地址短缺下的重要过渡手段。
4.2 路由表与“下一跳”:数据包不是一下飞到对方
很多人想象中,数据包从北京到杭州是“嗖”的一下直线飞过去的。实际上它是从一个路由器跳到下一个路由器,每跳只负责把包送到自己管辖范围内离终点更近的下一站。这个思想在路由表里表达得非常清楚。
路由表的典型条目包括目的网络、掩码、下一跳地址和出接口。路由器查表时,先把目的 IP 和表中每条掩码做“与”运算,找到匹配的目的网段,再按下一跳地址转发。假如匹配不到任何精确路由,还有一条默认路由 0.0.0.0/0 兜底,通常指向 ISP 侧的上联路由器。你电脑里的“默认网关”就是这台帮你把包送出局域网的设备。
在一个局域网内部,想跨网通信时,主机是怎么把包交给默认网关的?这里就要 ARP 出场了。主机知道网关 IP,但不知道网关 MAC,所以先在自己的 ARP 缓存里找;找不到就发一个广播帧问“谁是这个 IP,请把 MAC 告诉我”。目标设备单播回复后,发起方把 IP 和 MAC 的对应关系写入缓存,以后一段时间内不再广播。所以你可以看到 ARP 在通信链路中的位置:IP 负责远端定位,ARP 负责把远端 IP 翻译成“直连链路里能用的地址”。
4.3 路由协议层次和排查命令
路由协议的学习不需要一上来就把 OSPF、BGP 的实现细节都背下来,但要理解它们是被分成了不同尺度的。自治系统内部用 RIP、OSPF、IS-IS 等内部网关协议,自治系统之间用 BGP。RIP 早年用跳数作度量,最大 15 跳;OSPF 用 Dijkstra 最短路径算法,收敛更快,更适合中大型网络;BGP 则要考虑策略而不仅仅是“最短路径”,它决定的是互联网大动脉怎么走。
实践层面,ICMP 是网络层最常用的调试协议。ping 命令发送 ICMP 回显请求,收到回显应答说明本机到目标主机的 IP 层链路基本是通的。Windows 下的 tracert 和 Linux 下的 traceroute 则利用 IP 报文 TTL 字段逐步递增的特性,让沿途路由器返回“超时”的 ICMP 报文,从而打印出每一跳的 IP,这在排查“去哪个方向丢包”时非常好用。
我自己排查网络问题的固定顺序是:先 ping 127.0.0.1 验证本机协议栈能不能跑;再 ping 局域网内的另一个 IP 验证二层链路;接着 ping 默认网关验证能不能出本机网段;最后 ping 一个公网地址验证外部链路。哪一步断,问题就在哪一层。很多所谓的“上不了网”,走到默认网关那一步就暴露了——要么网线物理故障,要么网关设备死机。
5. 传输层是取舍的艺术:TCP 三次握手、滑动窗口和 UDP 的适用区
5.1 端口号到底在区分什么
传输层往下看,它要服务网络层;往上,它要支撑无数个应用进程。一台服务器的 80 端口可能跑着 Web 服务,443 端口跑着 HTTPS,而客户端这边没有固定端口,系统会临时分配一个高位端口。这就有了一组面试里很常见的概念:一个 TCP 连接由四元组标识,即源 IP、源端口、目的 IP、目的端口。所以即使你和别人访问同一个网站,浏览器临时端口不同,服务器也能把它们区分开。
TCP 和 UDP 是传输层两种完全不同的哲学。TCP 像签了合同的专线物流,保证货物尽量完整有序地送达;UDP 像同城闪送,把包裹丢给你就不管了,可能丢件也可能乱序。它们没有绝对好坏,关键看业务能不能接受丢包或乱序。
5.2 三次握手为什么必须是三次
TCP 建立连接时,如果 A 是主动方,B 是被动方,三次握手的过程是:A 发一个 SYN 报文,初始序列号设为 x;B 收到后回复 SYN+ACK,确认号是 x+1,同时告诉 A 自己的初始序列号 y;A 再回一个 ACK,确认号是 y+1。建立完成后,双方都知道了对方的初始序列号,后续每个字节都能按顺序编号、确认和重传。
为什么不能只握两次?因为第二次握手的 ACK 只能让 A 确认“B 收到了我的 SYN”,不能确定 A 是否收到了 B 的 SYN。换句话说,第二次报文到达 A 后,A 知道 B 的序号;但 B 还不知道自己的 SYN+ACK 有没有被 A 收到,所以 B 无法判断这条连接是否真的建立。第三次握手本质上就是 A 通知 B“我收到了你的序号,咱们正式开始”。三次握手还有一个重要作用:防止历史失效连接请求干扰。比如 A 的旧 SYN 因为网络延迟后到达 B,如果没有第三次,B 会误认为 A 想建立连接并消耗资源;有了第三次,A 发现这不是自己正在发起的连接,可以回复 RST 让 B 撤销。
TCP 挥手为什么需要四次?因为 TCP 连接是全双工的,两个方向的数据通道是独立的。A 发 FIN 表示“我这边的数据发完了”,B 回 ACK 只是确认收到关闭请求;B 可能还有数据要继续发给 A,所以等 B 的数据也发完后,B 再单独发 FIN,A 回 ACK,连接才会真正关闭。四次挥手不是冗余,而是“两个方向各自关闭”的必然结果。
5.3 可靠传输:确认、重传、滑动窗口和拥塞控制
TCP 的可靠传输不是靠单一机制,而是一套组合拳。
发送方每发一段数据,都希望得到接收方的确认。如果超时没收到 ACK,就重传这段数据。但为了提高效率,TCP 不会发一个等一个,而是引入滑动窗口:窗口里的数据可以连续发出去,不用每发一个包就停下来等 ACK。接收方根据自己的缓冲区大小,通过窗口字段告诉发送方“我还能收多少”,这叫流量控制,目的是避免发送方太快把接收方缓冲区冲垮。
流量控制只照顾接收方的能力,但网络路径中间的路由器也可能拥堵,所以 TCP 还要做拥塞控制。经典机制是慢启动、拥塞避免、快速重传和快速恢复。慢启动阶段,拥塞窗口从一个很小的值开始,每收到一个 ACK,窗口翻倍,指数增长;当收到三次重复 ACK 或发生超时,就认为网络已经开始丢包,窗口降下来并进入拥塞避免阶段,改用线性增长缓慢探路。你可以把拥塞控制理解成在高速公路上试探着深踩油门:路况好时逐渐提速,一旦遇到抖动就减速,而不是仗着车好一脚踩死。
期末和面试里经常问“TCP 如何保证可靠”,你最好答出一个组合:序列号保证有序,确认号告诉对方收到哪,超时重传纠正丢包,校验和检测错误,流量控制防止接收方过载,拥塞控制防止网络过载。这几个点串成一句,比零散背诵管用得多。
5.4 UDP 简单到只有 8 字节首部
UDP 首部只有 8 字节:源端口、目的端口、长度、校验和。它没有连接管理,没有确认机制,没有重传逻辑,没有滑动窗口。发送方把数据报扔给网卡,剩下的就不管了。但也正因如此,UDP 有低时延、少开销、支持组播广播等优点。
需要低时延实时传输的场景往往选 UDP:视频会议一两秒的延迟你受不了,但偶尔丢一帧画面影响不大;语音通话里少量数据丢失也只是产生一个短暂杂音。DNS 查询默认也走 UDP 53 端口,因为一次请求用一个报文就能完成,系统负担小。近年来很多新协议进一步把可靠性“上移”到应用层,同时保留 UDP 的灵活性,比如音视频传输场景里常见的 WebRTC 就是在 UDP 之上自己做丢包重传与抖动缓冲,这也说明“TCP 一定比 UDP 好”是不成立的。
表格可以帮助你快速对比:
| 对比项 | TCP | UDP |
|---|---|---|
| 连接状态 | 面向连接 | 无连接 |
| 可靠性 | 确认、重传、可靠传输 | 尽力而为,可能丢包 |
| 数据有序性 | 按序交付 | 不保证有序 |
| 首部开销 | 至少 20 字节 | 8 字节 |
| 传输效率 | 较低,机制多 | 高 |
| 典型应用 | HTTP、FTP、SSH | DNS 查询、视频直播、语音通话 |
6. 应用层很日常,但 DNS 与 HTTP 中的细节最值得抓包验证
6.1 DNS 不是“一个中心”,是一棵分布式树
DNS 是网络里最容易忽略的基础设施。你访问一个域名时,系统并不是找一台万能服务器去问“全世界所有网页的 IP 是什么”,而是按层查询。根 DNS 服务器先指引你找顶级域名服务器,顶级域名服务器再指引你找权威域名服务器,权威服务器才真正给出最终 IP。
一次完整 DNS 解析大体是:浏览器缓存里没有,就去查操作系统缓存;操作系统缓存里没有读取 hosts 文件;再没有就把请求交给本地 DNS 服务器。本地服务器如果也没有缓存,会代替你向根服务器发起迭代查询:根服务器说“.com 的服务器去找谁”,.com 服务器说“example.com 的权威服务器是谁”,最后权威服务器才返回 93.184.216.34 这样的 A 记录。这个过程涉及递归查询和迭代查询两组概念:客户机和本地 DNS 之间一般是递归,本地 DNS 与上级服务器之间是迭代。
学习 DNS 时用一条命令就能看到过程。Windows 下执行 nslookup www.example.com,返回值里能看到服务器地址和解析结果。想看更细的流程,可以抓包观察 DNS 查询报文和响应报文,你会发现响应里除了 IP,还有 TTL 字段,告诉你能缓存多久。DNS 基础不牢,很多 HTTP 层“打不开网页”的怪问题会被误判成服务器故障,其实只是 local DNS 污染或缓存过期。
6.2 HTTP:无状态协议和缓存、重定向是如何配合的
HTTP 是应用层最重要也最高频的协议。一个 HTTP 请求由请求行、请求头、空行和请求体组成,响应由状态行、响应头、空行和响应体组成。方法里 GET 用来获取资源,POST 通常带 body 创建或提交数据,PUT、DELETE、PATCH 分别对应更新和删除。虽然“RESTful”设计成了面试必背,但基础概念仍然是:HTTP 是高层的语义协议,和底层传输无关。
很多人记状态码用“2 开头成功、3 开头重定向、4 开头客户端错、5 开头服务端错”就够了。再细一点,301 是永久重定向,302 是临时重定向;401 是未认证,需要登录;403 是服务器理解请求但拒绝执行。常见面试题“301 和 302 的区别”不只是状态码本身,而是二者会影响浏览器缓存策略和 SEO,爬虫遇到 301 会更新记录,遇到 302 通常不替换旧地址。
HTTP 的核心设计是“无状态”:服务器默认不记得上一次请求是谁发出的。但真实业务又需要状态,于是客户端用 Cookie 保存会话标识,服务器用 Session 记录状态。后来前端通过 localStorage 等方式自行保存部分状态。这套“无状态协议 + 有状态辅助机制”的组合,也是计网络基础里最容易和 Web 开发知识衔接的地方。
现代 HTTP 版本之间的差异也值得梳理:HTTP/1.0 每请求一个资源都要建立新连接,HTTP/1.1 默认支持持久连接,同一个 TCP 连接上可以连续发送多个请求,但存在队头阻塞问题。HTTP/2 引入多路复用,把多个请求交错放在同一条连接上,并做头部压缩,但仍依赖 TCP。HTTP/3 改用 QUIC,QUIC 跑在 UDP 上,进一步减少连接建立时延。考试一般只要求记住“版本演进解决什么问题”,你不需要把 RFC 细节背下来。
6.3 用 Wireshark 看一次完整请求
有一类朋友学计网很努力,但从来不抓包,这相当于只看菜谱,从没进过厨房。想真正把 TCP 三次握手和 HTTP 请求关系弄清楚,可以这样做。
在你本机起一个简单的 HTTP 服务,比如进入一个空目录后执行:
bash复制python3 -m http.server 8080
然后打开 Wireshark,选择回环接口,设置抓包过滤条件为:
text复制tcp.port == 8080
打开浏览器访问 http://127.0.0.1:8080,抓包里会依次出现 TCP SYN、SYN+ACK、ACK 三条报文,这就是三次握手。紧接着能看到一行 HTTP GET 请求报文,服务端返回 HTTP 200 OK 和两个 ACK。请求结束后,还会出现 FIN、ACK、FIN、ACK 的挥手过程。
把抓包数据和教材里的报文格式对照一次以后,你会突然明白为什么头部字段是那样排列,为什么会有 seq 和 ack 两个序号,为什么三次握手的第三次只有一个 ACK 而没有数据。我个人带新人的经验是:如果一个人能把 Wireshark 里一次完整 HTTP 请求的报文逐条讲清楚,那么计网基础基本算过关了。
7. 期末考、408 和面试八股:如何把“基础概念”变成解题力
7.1 自顶向下和自底向上,不要只选一种
选教材时,常看到有人纠结《计算机网络:自顶向下方法》和传统教材哪个好。自顶向下从 HTTP、DNS 这些看得见摸得着的应用讲起,初学更容易建立兴趣;很多学校按物理层到应用层的顺序讲,则是从底层基础设施往上游,逻辑完整但开头比较枯燥。
我的建议是看阶段。如果你是完全没接触过编程和 Web 的新手,先选自顶向下入门,至少知道“浏览器敲一个网址后发生了什么”,再回头看底层会更有动力。如果已经在准备期末考试或 408,传统教材和老师课程里的体系更接近考纲,应该以学校课件、考试重点、考研辅导书为主线。有人问湖科大教书匠的计网课适不适合考 408,我的看法是:打基础阶段非常合适,图解清晰、逻辑直白;到后期反复刷真题、做综合题阶段,还是得回归王道单科书这类明显按考点组织的资料。
教材上,谢希仁《计算机网络》第八版是国内高校和考研使用最广的一本,适合体系化复习;高军等编著的《深入浅出计算机网络》对概念解释得比较有耐心,配合图解学习体验更好;想读英文原版或译本,就选《计算机网络:自顶向下方法》,重点看应用层、传输层部分,不要只看一章换一本。
7.2 用“四问卡”整理协议,而不是抄名词
复习时最没效率的动作是抄概念:把“ARP 是什么、IP 是什么”抄一遍,抄完合上本子还是记不住。我自己给学生常用的方法是给每个协议做一张“四问卡”。
问第一层:这个协议属于哪一层?它替代或弥补了什么?问第二层:它解决的核心问题是什么?不解决会怎么样?问第三层:它报文里最关键的 2 到 3 个字段是什么?为什么需要这些字段?问第四层:它在工作时最典型的交互过程是什么?过程中有没有隐藏的失败情况?
拿 TCP 举例。答:属于传输层,解决应用进程之间的可靠传输问题;不解决的话数据可能丢、可能乱。报文关键字段是序列号、确认号、窗口、标志位;没有序列号就不能重组数据,没有窗口就不能流量控制。典型交互是三次握手和四次挥手;失败情况包括 SYN 丢失、连接队列满、半开连接等。这样一答,实际上把期末简答题和面试常见追问通通覆盖了。
把 DNS、ARP、IP、TCP、UDP、HTTP 六个协议按这个模板过一遍,基础框架基本就牢固了。不用贪多,计网考试真正反复考的重要协议数量有限,重要的是你看到一个题目能想到它是哪一层在什么场景下产生的问题。
7.3 408 题型和“八股文”背后的共同套路
考研 408 的计算机网络部分通常只占 25 分左右,分值不算高,但拿分相对容易。选择题喜欢考概念辨析:CRC 是检错还是纠错,ICMP 工作在哪一层,TCP/IP 模型中哪层对应 OSI 哪层,子网掩码计算可用 IP 数,TCP 滑动窗口和拥塞窗口的区别。大题则集中在 IP 地址规划/路由聚合、TCP 状态时序或者 CSMA/CD 的冲突计算。你要做的不是把书从头背到尾,而是把往年真题按题型拆开,归纳出“最常考的几个计算模型”。
面试里的“八股文”和考试不同,面试官更希望听到你的判断而不是背诵。比如问 TCP 为什么可靠,你背五个词可能得不了高分,但如果你说“TCP 通过序列号实现有序,通过 ACK 触发重传,通过滑动窗口控制收发速率,慢启动防止网络拥塞,每一层机制解决一个问题”,听起来就是真正理解过的表达。所以我的建议是:先把“是什么”背熟,再用自己的话讲一遍,最后动手抓包验证一遍。这三遍做完,你的计网基础比很多只刷题的人扎实得多。
如果只留一个印象,我希望是:所有计算机网络基础概念都围绕着让数据更快、更稳、更安全地从一端到另一端,它们是一套协作系统。你看到一个新协议时,先找它出现的“层”,再想它解决的问题,最后看它设计的字段和流程,就不会被名词吓住。
