GreedyAbyss1. 先聊聊那条烦人的弹窗：为什么网站会提示“网络中存在异常流量”
你有没有遇到过这种情况：正常刷新一个网页，突然跳出一句“我们的系统检测到您的计算机网络中存在异常流量，请稍后重新发送请求”，然后页面就卡在那里了。很多人的第一反应是“是不是我电脑中毒了”或者“这个网站是不是被攻击了”。我刷热搜时看到这个问题被顶上来，说明不少人被这句话吓到过。其实，这恰恰是计算机网络课里最值得拆解的一个真实场景。
这句话翻译成网络术语就是：服务端的某个防护机制认为你刚才的请求“不像人类正常操作”，于是把你暂时挡在门外。它不代表你的电脑真的在往外发垃圾流量，更多时候是请求频率、请求特征、IP段信誉度这几个维度上触发了规则。理解了这一点，你就同时理解了TCP连接、HTTP请求头、IP地址、Cookie这些基础概念在真实系统里是如何被串联使用的。
1.1 这条提示背后其实是一套风控机制
任何一个对外提供网页服务的站点，在正式请求进入业务逻辑之前，都会先经过一层或多层网关。这层网关可能是Nginx、云厂商的防护产品，或者是业务自己实现的风控模块。它的工作方式并不神秘：把每一个访问请求拆成若干特征，用规则引擎去打分。
打分时看的维度大致有这几类。
第一类是请求频率。同一IP在单位时间内发起的请求数超过阈值，比如每秒50次、每分钟2000次，就会被判定为异常。正常用户怎么点鼠标都达不到这个量级，能达到的基本是脚本或恶意扫描。
第二类是请求特征。浏览器发HTTP请求时会自带User-Agent、Accept、Referer、Cookie等请求头，这些字段的组合是有规律的。如果请求头缺失严重，或者User-Agent写着爬虫框架的名称，防护系统一眼就能认出来。
第三类是IP信誉度。数据中心IP、动态拨号IP、被大量投诉过的IP段，天然带有灰色标签。即便你的请求本身没问题，只要源头IP在服务端的黑名单或降权名单里，也会被重点观察。
第四类是行为轨迹。从点击页面到发起请求的时间间隔、访问页面的顺序、是否执行了浏览器端的JavaScript验证，这些都会被采集。所以你会发现，有些系统在提示异常流量后，会要求你拖一下滑块或者勾选验证框，本质是在确认“对面是一个能执行真实交互的浏览器”。
1.2 触发条件有哪些，怎么对号入座
很多人会问：“我明明就用浏览器正常访问，为什么也被拦了？”根据我排查类似问题的经验，最常见的触发原因其实就几种。
一种是你所在的局域网、校园网或公司出口IP被共享了。一个办公楼几百号人共用一个公网IP，只要其中某个人在跑高并发下载或爬虫，整个IP段都会被临时限制，其他正常人跟着遭殃。这种情况我在学校机房和宿舍网络里见过很多次。
另一种是浏览器插件或后台程序在偷偷发请求。你电脑里装了一些“全家桶”软件，每隔几秒就有后台心跳包往外发，或者是浏览器标签页里挂着自动刷新脚本。这些流量在服务端看来就是异常特征。
还有一种是你自己确实在跑自动化脚本。比如用Python写了个Requests脚本批量请求某个网站的接口，频率没控制好，或者没带完整的请求头，那被弹提示太正常了。这时候千万别想着怎么绕过风控，正确做法是降低频率、补全请求头、模拟真实用户的操作节奏，并且遵守目标站点的访问规则。
1.3 怎么做一个“遵纪守法”的请求方
如果你是在做数据采集、接口调试或者爬虫学习，我建议从一开始就养成几个好习惯。
第一，限速。每次请求之间至少间隔1到3秒，最好加随机抖动，不要像发牌一样匀速扫过去。第二，补全请求头。把浏览器开发者工具里看到的User-Agent、Accept、Accept-Language、Referer都带上，不要只带一个UA就冲。第三，会话保持。用Requests库时创建Session对象，让Cookie能持续维护，这能大幅减少被风控误判的概率。第四，重试退避。遇到429状态码或者“稍后重新发送请求”的提示，至少等待30秒到几分钟再试，不要立刻暴力重刷。
如果你遇到的是网页验证码，老老实实完成验证即可。如果持续被拦截，优先考虑是不是出口IP被连坐，换个时段或者用正规运营商网络一般就能解决。
理解这个弹窗的底层逻辑，其实就是在理解“客户端—服务端”之间的信任模型。后面学到的所有协议层知识，都会不断回应这个场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一章为什么从物理层开始：网线、信号和集线器的真相
很多教材第一章就讲物理层，学生觉得枯燥，考试也就考几个概念，比如“双绞线”“同轴电缆”“光纤”“集线器”。但物理层不只是一堆名词，它决定了网络“能不能通”的最基本前提。我在帮人修电脑网络的时候，发现大部分人遇到的上不了网，问题恰恰就出在这个最底层。
2.1 双绞线为什么是双绞的，8根线到底怎么用
先看网线。一根常规的Cat5e或Cat6网线里面有8根铜线，两两绞合在一起，所以叫“双绞线”。为什么要把线绞起来？因为电流通过导线时会产生电磁场，两根平行线之间的电磁干扰会叠加，绞合之后相邻线对产生的干扰可以相互抵消，这属于物理层处理信号完整性的一种经典手段。
虽然网线有8根线，但百兆以太网实际只用了其中4根：1、2发送数据，3、6接收数据。剩下4根在百兆模式下是闲置的。千兆以太网才把8根全部用上，4对线同时双向传输。所以你买网线的时候，如果看到商家标注“百兆线4芯”或者“千兆线8芯”，指的就是这个区别。
线序也是坑。两端都按T568B标准做线，叫直通线，用于电脑连交换机；一端T568A另一端T568B，叫交叉线，早期用于两台电脑直连。现在的网卡和交换机普遍支持自动翻转，交叉线的使用场景越来越少了，但实验课上还是会考。排错时最经典的现象是：网卡状态显示“已连接”，但网速始终只有100Mbps，检查一下就知道，往往是8根线里有一对没做好，或者水晶头接触不良，千兆协商失败后自动降级到了百兆。
2.2 集线器、交换机、路由器分别在哪一层干活
物理层的典型设备是集线器。它的工作方式特别原始：从一个端口收到电信号，直接放大后向所有其他端口广播。这意味着同一时刻只能有一台设备在发送数据，如果两台同时发，就会碰撞，所有设备都收不到有效数据，只能等待随机时间后重发。这就是“冲突域”的概念。
交换机工作在数据链路层，它不再无脑广播，而是会学习MAC地址并维护一张转发表。数据帧进来后，交换机根据目的MAC地址，只从对应端口发出去。对比集线器，交换机的每个端口都是一个独立的冲突域，所以同时通信的设备之间几乎不互相干扰。
路由器工作在更上层的网络层，它根据IP地址做跨网段的转发。你可以这么理解：集线器是村口的大喇叭，喊一声全村都能听到；交换机是物业传达室，知道每户住的是谁，按门牌送信；路由器是快递分拣中心，负责区分不同小区的邮件调度。
我遇到过不少初学者，分不清交换机配置和路由器配置，一进实验课就拿着网线乱插。记住一个简单判断方法：需要配置IP地址、路由表、NAT这种“跨网段”功能的，找路由器；只是在同一个网段内扩充接口数目的，用交换机。
2.3 实验课上一定要会用：Packet Tracer 和 Wireshark
说句实在话，如果只靠桌面上的理论课，物理层这章你很难建立起直观感受。我建议你立刻去装一个Cisco Packet Tracer，很多高校的计算机网络实验课（包括湖北汽车工业学院的课程安排里常见的那种）都是用它来搭拓扑、配设备。
Packet Tracer里有一项很实用的功能：实时模式切换。切到模拟模式后，发送一个ping包，你能看到数据包是怎么从主机A出来，经过交换机查询MAC表、经过路由器查询路由表，一步步变成帧、变成比特流，再从网线发出去的。这个动画过程比你看十遍文字描述都管用。
Wireshark则是用于抓包的利器。做实验时，在电脑上打开Wireshark，选好网卡接口，再ping一下网关，就能抓到完整的ARP请求、ICMP请求和响应。你可以直观看到每个帧头部的源MAC、目的MAC，以及IP层的源地址、目的地址。很多同学直到工作都用不明白Wireshark，就是因为在学校实验课上没有认真玩过它，实在可惜。
3. 数据链路层和网络层连起来看：MAC、IP与子网划分一次讲透
学完了物理层再看数据链路层和网络层，就容易串起来了。这两层被问的频率极高，期末考、面试、实际排错都绕不开。但很多人把它们拆开背，背完又会混。这里我建议你把它们当一条“寄快递”的链路来看。
3.1 为什么要有MAC地址和IP地址两套地址
MAC地址是设备的物理地址，它在出厂时就烧录在网卡里，通常是48位，写成类似00:1A:2B:3C:4D:5E的格式。它相当于是人的身份证号，全球唯一，但不能表示你当前住在哪里。IP地址则是逻辑地址，相当于你填的收货地址，它会随着网络环境变化而变化。
数据在局域网内传输时，依赖的是MAC地址。当帧到达交换机的某个端口，交换机查看帧头部的目的MAC，再查询自己的MAC地址表，决定该往哪个端口转发。如果MAC地址表里查不到，交换机就会把这个帧广播到所有端口，目标设备响应后，交换机记下它的端口和MAC映射，下一次就能精准转发了。
网络层关心的是IP地址。两台设备跨网段通信时，源设备必须先把数据包交给默认网关，由网关路由器根据目的IP查找路由表，选择下一跳。但路由器之间、路由器与设备之间的物理传输，最终还是要落到MAC地址上。所以真实过程是：IP决定“去哪里”，MAC决定“下一跳交给谁”。这就是为什么要ARP协议，在发送数据前先广播询问“这个IP对应的MAC地址是什么”。
3.2 子网掩码和子网划分：用“小区-楼栋-单元-房号”套进去
子网掩码是初学者的拦路虎，但它其实是个很生活化的概念。一个IPv4地址有32位，分成网络位和主机位。子网掩码的作用就是告诉设备：前多少位是网络号，后多少位是主机号。比如192.168.1.10/24，/24表示前24位是网络号，后8位是主机号，对应的子网掩码是255.255.255.0。
类比一下：整个互联网是一个城市，IP地址的“网络位”像小区名，“主机位”像房号。192.168.1.0/24这个网段，就是“192.168.1小区”，里面可以住256个号码，去掉网络地址192.168.1.0和广播地址192.168.1.255，实际能用254个主机地址。
划分子网的场景很常见。比如你拿到一个192.168.1.0/24的网段，需要分成两个独立子网，就把子网掩码从/24改成/25。24位变成25位，相当于从主机位借了一位，于是网络被一分为二：192.168.1.0~192.168.1.127和192.168.1.128~192.168.1.255，每个子网可用主机数是126个。实际工作中，可能还要考虑设备数量留出余量。比如一个房间只有20台设备，但为了以后扩容，用/27（32个地址）更稳妥。
这里有个常见错误：很多人把主机位全0、全1的两个地址也分配出去了，导致网络广播异常。记住结论：一个子网里，主机位全0是网络地址，全1是广播地址，都不能分配给设备。
3.3 一个ping不通的例子，完整走一遍排查顺序
网络排错最忌讳一上来就怀疑运营商、怀疑路由器，正确做法是从自己这端一层层往外ping。
第一步，ping 127.0.0.1。通，说明本机TCP/IP协议栈正常；不通，说明系统网络协议栈有问题，一般是驱动或配置损坏。
第二步，ping 本机IP。比如ping 192.168.1.10。通，说明网卡和IP配置基本正常；不通，说明IP配置冲突或网卡异常。
第三步，ping 网关，一般是192.168.1.1。通，说明本机到路由器之间的链路层和网络层都正常；不通，检查网线、交换机和子网掩码。
第四步，ping 公网IP，比如ping 223.5.5.5。通，说明出网路由和NAT没问题；不通，问题在路由器到运营商这一段。
最后，ping 域名，比如ping baidu.com。如果前面的公网IP通、域名不通，那就是DNS解析的问题。
我把这个排查顺序总结成一个表格：
| 排查目标 | 命令示例 | 正常说明 | 异常可能原因 |
|---|---|---|---|
| 本机协议栈 | ping 127.0.0.1 | 协议栈正常 | 系统网络组件损坏 |
| 本机网卡 | ping 本机IP | 网卡和IP配置正常 | IP冲突、网卡禁用 |
| 网关连通 | ping 网关IP | 内网链路正常 | 网线、交换机、VLAN配置 |
| 公网连通 | ping 公网IP | 路由和NAT正常 | 路由表缺失、运营商故障 |
| DNS解析 | ping 域名 | DNS正常 | DNS服务器配置或网络劫持 |
用这个表去排查百分之七八十的网络问题都能定位到具体层，后面再对症下药就快多了。
4. 传输层是期末大题重灾区：TCP的可靠性到底靠什么撑起来
每次期末复习，传输层都是大家最头疼的一块。TCP的可靠性不是一个简单开关，而是靠序号、确认应答、重传机制、滑动窗口、拥塞控制一整套组合拳撑起来的。面试和笔试还特别爱问三次握手为什么是三次、四次挥手为什么是四次。我想把这些背后的逻辑讲透。
4.1 为什么是三次握手，两次会出什么事
TCP建立连接的过程是：客户端先发送SYN报文，服务器收到后回复SYN+ACK，客户端再回复ACK，然后连接建立。这个过程叫三次握手。
为什么不能是两次？关键在于“确认对方是否具备收发能力”这件事需要双向验证。第一次握手，服务器收到了SYN，能确认客户端发送正常；第二次握手，客户端收到SYN+ACK，能确认服务器收发都正常，同时确认自己发送正常；但服务器还不知道客户端是否收到了自己发的报文，所以必须有第三次握手，客户端回一个ACK告诉服务器“你的SYN+ACK我收到了”。
如果只握两次手，会有一个隐患：网络上可能滞留了一个历史遗留的失效连接请求。比如客户端第一次发的SYN因为网络拥堵迟迟没到，客户端超时后重发了一个新的SYN，旧的SYN这时才到达服务器。服务器只凭这个旧SYN就建立了连接，会浪费资源，而客户端根本不知道这回事。第三次握手的作用就包含了对这种历史报文的校正。
我在面试里经常把这个问题换成生活场景：两个人隔着窗户喊话，A喊“你能听到我吗”，B回答“我能听到你，你能听到我吗”，A再回答“我能听到你”。这三句话缺了第三句，B就没法确定对话真的建立。
4.2 四次挥手为什么比握手多一次，TIME_WAIT的坑
TCP关闭连接需要四次挥手，原因是TCP连接是双向的，每个方向的关闭都要单独确认。当客户端发送FIN表示“我要发送的数据发完了”，服务器收到后回复ACK表示“我收到了”，但服务器可能还有数据要发，所以它不会立刻关闭。等服务器把剩余数据发完，再发一个FIN给客户端，客户端回复ACK，整个连接才关闭。
这个场景下，第二次和第三次被拆分成了两个独立步骤，所以挥手比握手多一次。
四次挥手里有一个特别容易被忽视的状态——TIME_WAIT。主动关闭连接的一方，在收到被动方的FIN并回复ACK后，不会立刻进入关闭状态，而是进入TIME_WAIT并持续2倍报文最大生存时间（2MSL）。之所以要等这么久，是为了确保最后一个ACK能被对方收到。如果这个ACK丢了，对方会重发FIN，而TIME_WAIT状态能保证主动方还在监听、还能回应。
在高并发的服务端，如果大量连接由服务器主动关闭，就可能出现大量TIME_WAIT连接堆积。每个连接占用一个端口和系统资源，端口被占满后，新连接就无法建立。用netstat -an看到几千个TIME_WAIT，别慌，先检查是不是连接复用的配置没开，或者业务代码里频繁创建短连接。解决方向是开启TCP时间戳、调整tcp_tw_reuse参数（在内核层面），但更根本的方案是改造业务逻辑，减少不必要的短连接，或者在设计时就考虑连接池复用。
4.3 滑动窗口和拥塞控制，别靠背，靠推
TCP要保证可靠传输，但它同时希望效率越高越好。于是有了滑动窗口：发送方允许一次向网络中发送多个未被确认的数据包，而不必发一个等一个。窗口大小决定了在途数据量。
如果网络出现拥塞，TCP必须放慢发送速度。拥塞控制有四个经典算法：慢开始、拥塞避免、快重传、快恢复。
慢开始：拥塞窗口（cwnd）从小到大指数增长，比如1、2、4、8，直到达到阈值ssthresh。之后进入拥塞避免阶段，cwnd线性增长，也就是每次往返时间只增加一个报文段。如果发生超时，说明网络可能严重拥塞，TCP会把ssthresh降到当前cwnd的一半，cwnd重置为1，重新慢开始。如果是收到3个重复ACK触发的快重传，则执行快恢复，ssthresh降为当前cwnd的一半，cwnd从新阈值开始，而不是回到1。
期末计算题往往就考这个变化过程。给你初始ssthresh和最大窗口，然后告诉你第几轮超时，让你画cwnd变化曲线。这种题不要死记硬背，拿一张纸，按“指数增长—线性增长—超时/快重传后变化”的规则推一遍，就能得分。
流量控制和拥塞控制也经常被一起考。一句话区分：流量控制是接收方告诉发送方“你慢点，我处理不过来了”，基于接收窗口；拥塞控制是发送方根据网络状况自己调整速度，基于拥塞窗口。实际发送速度取这两个窗口的较小值。
5. 应用层最常被面试官拿来开刀：HTTP、DNS和状态码不得不说的细节
应用层的知识点最贴近日常工作，无论是开发、测试还是运维，每天都要和HTTP协议打交道。可很多人只是知道GET、POST这种皮毛，一被深问就露馅。下面我把应用层复习时最值得注意的部分串一遍。
5.1 从输入网址到页面显示，一次完整的HTTP旅程
我特别喜欢让测试岗的朋友在白板上画一遍“从输入网址到页面显示”的过程。别看它简单，这一条链路能把DNS、TCP、HTTP、浏览器渲染全部串起来。
第一步是DNS解析。浏览器先查本地缓存，查不到就去问配置的DNS服务器，把域名换算成IP地址。如果DNS服务器也没有缓存，它会代表客户端继续向上级DNS服务器询问，直到找到负责该域名的权威服务器。
第二步是TCP连接。拿到IP后，浏览器发起TCP三次握手建立连接。如果协议是HTTPS，还要额外进行TLS握手，协商加密套件、交换证书、生成会话密钥。
第三步是发送HTTP请求。浏览器向服务器发送请求行、请求头、请求体。服务器收到后，经过反向代理、业务逻辑处理、数据库查询，最终返回HTTP响应。
第四步是浏览器渲染。浏览器解析HTML、CSS、JavaScript，同时根据HTML里的引用又发起子资源请求，比如图片、CSS文件、JS文件，每个子资源都有可能重新走一遍连接流程，所以现代HTTP协议才想办法做连接复用。
这一整套流程里，任何一个环节出问题，表现出的症状都不一样。DNS解析失败会报“找不到服务器”；TCP超时会一直转圈；服务器返回500说明代码或配置出问题；返回404则是路径写错。作为测试人员，拿到一个页面打不开的Bug，先判断是哪一个环节出的问题，能少走很多弯路。
5.2 状态码不只是背下来，要能结合场景判断后端问题
HTTP状态码是有规律的。1xx是信息响应，2xx代表成功，3xx代表重定向，4xx是客户端错误，5xx是服务端错误。但真正考验功底的，是在实际场景里区分相近状态码。
301和302经常被混淆。301是永久重定向，搜索引擎会把权重迁移到新地址；302是临时重定向，浏览器下次访问还是走原地址。如果网站从HTTP切到HTTPS，应该用301，这样浏览器和搜索引擎都能长期记住新地址。如果只是一个活动页面暂时跳转，用302。
403和404也容易被搞混。403是服务器理解请求但拒绝执行，通常是权限不够；404是资源根本不存在。碰到403，先去检查是否带登录状态、是否有白名单限制。碰到404，先看URL路径是否正确、是否大小写写错、是否需要URL编码。
5xx状态码里，500泛指服务器内部错误，502是网关收到上游服务器的无效响应，503是服务暂时不可用（比如正在重启、限流），504是网关等待上游响应超时。我见过一个特别经典的排查：页面加载失败，接口响应码是504，开发第一反应查代码，查了半天没结果，后来运维一看，是上游数据库执行了一条慢查询，超过了网关超时时间，最终改SQL才解决。所以状态码只能缩小范围，真正定位还得结合服务端日志和调用链。
官方状态码含义和排查方向，我整理成了下面这个表，复习时可以直接对着记。
| 状态码 | 名称 | 含义 | 排查方向 |
|---|---|---|---|
| 301 | Moved Permanently | 永久重定向 | 检查重定向配置、HTTPS跳转 |
| 302 | Found | 临时重定向 | 检查会话状态、登录跳转 |
| 403 | Forbidden | 无权限访问 | 检查权限、IP白名单、登录Cookie |
| 404 | Not Found | 资源不存在 | 检查URL路径、路由配置 |
| 500 | Internal Server Error | 服务器内部错误 | 查看应用日志和异常堆栈 |
| 502 | Bad Gateway | 网关收到的上游响应无效 | 检查后端服务是否存活 |
| 503 | Service Unavailable | 服务不可用 | 检查部署状态、限流、重启 |
| 504 | Gateway Timeout | 网关超时 | 检查上游慢查询、超时配置、网络带宽 |
5.3 软件测试岗常考的网络知识点清单
我在给测试朋友做面试辅导时，经常收到“软件测试需掌握哪些计算机网络知识”的提问。结合招聘要求和实际笔试面经，这份清单比较稳。
基础概念部分：OSI七层模型和TCP/IP五层模型，每一层的主要协议和典型设备；GET和POST的区别（包括浏览器回退、请求体位置、幂等性）；HTTP与HTTPS的区别，TLS握手大致流程；Cookie和Session的区别，以及Token方案的适用场景。
抓包与分析部分：Fiddler、Charles或Wireshark的抓包操作，如何查看HTTP请求头、响应头；如何从抓包数据中断言接口是否正常返回；如何使用断点修改请求参数做异常场景测试。
网络异常用例设计部分：弱网、断网、切换Wi-Fi与4G/5G、高延迟、DNS异常、服务端超时、响应慢、证书过期等各种场景下，客户端是否给出合理提示，是否会发生数据丢失或重复提交。
接口测试部分：HTTP方法、常用请求头字段（Content-Type、Authorization、Referer、Origin）、响应头（Set-Cookie、Cache-Control）、状态码覆盖、接口鉴权方式、幂等性。做接口测试时，要重点验证参数校验、异常入参、权限越权、超时处理这些点。
6. 期末复习和学习资源：湖科大教书匠能不能喂饱408
“计算机网络”的期末复习，以及考研408中的计算机网络部分，很多同学都关心同一个问题：B站上的湖科大教书匠课件到底够用吗？我刷过一遍，也带着学生用过，说说我的真实看法。
6.1 核心教材与视频课怎么搭配
湖科大教书匠的课程特点是动画做得好，把抽象的分层模型、停等协议、滑动窗口、TCP拥塞控制这些难点用动画拆开演示，非常适合第一遍入门理解。尤其是物理层、数据链路层、链路层校验这部分，单独啃书本容易走神，看动画就清楚多了。
但如果你备考的是408，光看视频不够。408的出题风格更偏向综合与计算，并且喜欢把好几层知识融合在一道题里考。比如给你一个网络拓扑，要求结合子网划分、路由表、数据帧封装来推断某个主机能否收到数据。湖科大的视频能帮你把知识结构搭起来，但题目训练还得落到王道或历年真题上。
我的搭配建议是三轮走：
- 第一轮，以教材（谢希仁《计算机网络》或学校指定教材）为主线，配合湖科大教书匠的视频理解概念，周期约两周。
- 第二轮，用王道考研的对应章节刷选择题，把错题对应的知识点回翻教材，重点整理易混点，比如各层设备、各层协议、端口号、默认网关的作用。
- 第三轮，只刷真题和模拟卷，限时做，考完对答案后把错题涉及的知识点重新推演一遍。
这套流程对期末复习也适用，只是把真题换成学校的往年试卷。
6.2 计算题题型清单与常用公式
期末卷子里的计算题，来源比较固定，我把高频踩点的公式和套路列一下。
时延计算是必考的。发送时延等于数据帧长度除以信道带宽，传播时延等于信道长度除以电磁波在介质中的传播速率。总时延不一定是两者相加，可能还要考虑处理时延和排队时延。题目常把链路长度、数据长度、带宽同时给你，让你算从发送到接收的完整耗时，注意单位换算，Kbps、Mbps、KB、Kb别搞混。
比特率和波特率：比特率等于波特率乘以单个码元携带的比特数。如果一个码元有4种状态，那每个码元携带2比特。
CRC循环冗余校验：给出生成多项式G(x)，在原始数据后面补若干个0，补零的位数等于多项式最高次数，然后用多项式对应的二进制除数做模2除法，取余数作为校验码。这类题会算模2异或就行。
子网划分：给你一个地址段和主机数量要求，算出子网掩码、网络地址、广播地址和可用IP范围。公式是可用主机数等于2的主机位次方减2。
停止等待协议的效率：发送周期等于发送时延加上传播时延乘以2，再算有效利用率。
拥塞控制和滑动窗口：按前面说过的规则画曲线图或算平均吞吐量。
考前把这些题型各练5道，期末计算题基本就稳了。
6.3 实验考试和高频操作题怎么突击
实验课和上机考试在很多学校是独立学分的。以湖北汽车工业学院的计算机网络实验为例，通常涉及VLAN划分、静态路由配置、ACL访问控制列表、子网规划这类Packet Tracer操作。
突击实验考试，要把这几个操作练到形成肌肉记忆。
第一，VLAN划分。在交换机上建VLAN，把端口划分到对应VLAN，配置Trunk口，让相同VLAN跨交换机通信。命令大致是vlan 10、interface f0/1、switchport access vlan 10。
第二，静态路由。在三台路由器组成的拓扑里，给每个接口配置IP，然后用ip route 目标网段 子网掩码 下一跳地址把路由表补全。容易错的是漏配反向路由，导致数据包只能去不能回。
第三，ACL。在路由器上配置访问控制列表，限制某个网段不能访问特定服务器。注意ACL默认最后有一条隐式拒绝，所以规则顺序很重要。
第四，连通性验证。全部配完后，用ping和tracert验证路径。如果ping不通，按第3章的排查顺序逐层检查。
上机考试一定要养成先保存配置的习惯，很多Packet Tracer模拟器考试一断电，白搭。
7. 软件测试视角的计算机网络：抓包、弱网和接口异常定位
前面的内容偏理论，最后这部分写给已经进入测试岗位或者正在准备转测试的朋友。日常工作里，计算机网络知识不是用来考试的，而是用来快速定位问题、设计更全面的测试用例的。
7.1 抓包工具的选用与基本操作
Windows环境我常用Fiddler，macOS上常用Charles，二者都可以做HTTP/HTTPS请求的抓取与断点修改。Wireshark则更底层，能抓TCP、UDP、DNS、TLS等所有协议包，适合分析网络层和传输层问题。
用Fiddler抓HTTPS包时，记得安装并信任它的根证书，否则只能看到加密后的乱码。抓包时还要留意是不是把其他应用的流量也抓进来了，我会在过滤器里按域名或进程过滤，减少干扰。
Wireshark的过滤语法很值得记几条。只看某台主机的流量：ip.addr == 192.168.1.10；只看某个端口的TCP流量：tcp.port == 443；只看HTTP请求：http.request。有一次接口测试老是超时，我在Wireshark里按tcp.analysis.retransmission过滤，发现大量TCP重传包，再一看是测试环境所在网络丢包严重，问题根本不在应用代码，而在基础网络。
7.2 弱网测试怎么模拟
弱网测试是移动互联网测试的重点，开发经常说“我本地没问题”，但用户在地铁、电梯、隧道里就会出问题。模拟弱网的方法很多。
Chrome DevTools的Network面板里有Throttling选项，可以模拟Slow 3G、Fast 3G、离线等场景。如果你想自定义网络参数，可以选择Add，然后设置上行/下行带宽和延迟值。
移动端弱网工具，iOS可以用系统自带的Network Link Conditioner，Android可以通过设置里的开发者选项开启“模拟网络延迟”或者用第三方工具。对于必须真实模拟高丢包率的场景，我建议在路由器层面控制或者使用专门的弱网测试仪表。
设计弱网用例时，重点观察三个点：一是超时时间是否符合预期，能否在设定时间内给出错误提示；二是失败后的重试机制是否正确，会不会导致重复下单、重复支付；三是从弱网恢复到正常网络后，页面数据能否自动刷新，不会一直卡在加载中。
7.3 一个接口超时Bug从出现到定位的完整过程
最后分享一次典型的接口超时定位过程，把前面讲的知识串起来用。
现象：APP首页点开要转圈十几秒，最后报“网络异常，请稍后重试”。
第一步，我先用抓包工具看请求状态。发现HTTP请求确实发出去了，但迟迟没有收到响应，最后客户端主动超时断开。这说明问题大概率在服务端或中间链路，而不是客户端代码逻辑。
第二步，查看服务端网关日志。发现该接口对应请求已经到达Nginx，但上游响应耗时达到12秒，超过网关设置的超时时间10秒，于是网关返回504。范围缩小到业务服务或数据库。
第三步，看业务服务日志和调用链监控。定位到该接口内部调用了一个订单查询逻辑，其中有一段SQL查询条件没有走索引，拖慢了整个接口。
第四步，在测试环境复现并用数据库慢查询日志确认，确实是SQL扫描行数过大导致接口性能瓶颈。
这个Case里，网络层、HTTP层、应用层的知识全部用上了。如果没有抓包工具先定位到“请求没回来”这个事实，开发可能一开始就去改SQL或者加机器，思路就偏了。
我在实际工作中养成了一个习惯：遇到任何“用户反馈页面打不开”或“接口报错”的问题，不急着看代码，先抓包，先看请求链路在哪一跳断掉。这个习惯帮我省下了大量排查时间。计算机网络的知识不是考完试就扔的东西，它会在你做测试分析、写用例、定位线上问题的时候不断回来找你。如果你能把这套分层思维真正建立起来，再复杂的网络问题也能被一步步拆成可以下手的环节。