简介本资源是一份面向IT初学者与计算机基础课程学习者的系统性练习题集聚焦计算机组成原理、数制转换、存储单位、网络基础概念及典型应用如CAI/CAD/CAM等核心知识点助力夯实专业入门根基。文件为单页PDF格式共1个353KB的练习题文档内容结构清晰涵盖选择题、填空题与简析题三类题型覆盖冯·诺依曼体系、四代计算机电子元件演进、二进制运算规律、ASCII码与汉字编码规则、存储容量换算等高频考点并附带标准答案与关键解析提示便于自测、复习与教学辅助。目前已有53人学习下载题目编排由浅入深兼顾概念辨析与数值计算特别适合高校计算机导论课后巩固、软考初级备考或转行者构建知识框架使用。1. 这份 PDF 不是“刷题资料”而是你排查硬件卡顿、网络超时、DNS 解析失败时翻得最勤的那本“故障速查手册”很多人拿到《计算机基础知识和网络基础知识练习题.pdf》第一反应是“啊又是一堆选择题考前突击用的”——错。我把它放在工位抽屉最上层不是为了备考而是因为里面第 37 题问“TCP 三次握手过程中SYN 报文段是否携带数据”第 82 题画了 ARP 请求/响应帧结构图第 145 题列出了常见子网掩码与可用主机数对照表……这些不是考点是我在现场调试一台反复断连的工业网关、排查某台 Docker 容器无法解析内网域名、或者判断客户机 BIOS 启动顺序异常时真正掏出手机拍照、对着 PDF 逐字比对的原始依据。它不教你怎么写代码但教你在没有日志、没有 root 权限、只有 ping 和 ipconfig 的封闭环境里靠底层逻辑推断故障根因。适合刚转岗运维的开发、驻场支持工程师、嵌入式设备联调人员以及所有被“重启能解决 90% 问题”这句话坑过三次以上的人。别急着打印——先搞清它为什么比 Wireshark 抓包更先打开。2. 用真实故障场景反向拆解这份 PDF 里的每道题都对应一个可复现的底层验证动作这份 PDF 的价值不在“做对多少题”而在“把每道题变成一次最小化验证”。比如第 12 题“下列哪项不属于 OSI 模型的传输层协议”选项含 TCP、UDP、SCTP、ICMP。表面看是概念题实际是让你立刻打开终端执行# 在 Linux 主机上验证 ICMP 是否真在“网络层” ping -c 1 192.168.1.1 | head -n 2 # 输出示例 # PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. # 64 bytes from 192.168.1.1: icmp_seq1 ttl64 time0.823 ms注意icmp_seq和ttl字段直接暴露 ICMP 工作在网络层IP 层而time是应用层计时不是协议本身属性。这题若只背“ICMP 属于网络层”遇到客户说“ping 通但 telnet 不通”你就不会下意识去查防火墙是否放行了 TCP 23 端口——因为你知道 ICMP 和 TCP 根本不在同一层。再比如第 63 题“某主机 IP 地址为 192.168.5.128/26请计算其网络地址和广播地址。”这不是算术题是教你快速判断 DHCP 分配异常的起点# 用 ipcalc无图形界面时最稳验证 $ ipcalc 192.168.5.128/26 Address: 192.168.5.128 11000000.10101000.00000101.10 000000 Netmask: 255.255.255.192 26 11111111.11111111.11111111.11 000000 Network: 192.168.5.128/26 11000000.10101000.00000101.10 000000 HostMin: 192.168.5.129 11000000.10101000.00000101.10 000001 HostMax: 192.168.5.190 11000000.10101000.00000101.10 111110 Broadcast: 192.168.5.191 11000000.10101000.00000101.10 111111关键不是记住192.168.5.191而是看到HostMin是.129立刻意识到如果客户配置的静态 IP 是192.168.5.128网络地址本身设备根本无法通信——哪怕ip addr show显示配置成功arp -a也看不到网关 MAC。这就是 PDF 第 63 题的实战落点它逼你养成“看到 IP 就 mentally 执行 ipcalc”的肌肉记忆。第 118 题更典型“DNS 查询过程中若本地 DNS 服务器未缓存该域名将依次向哪些服务器发起查询”选项列了根服务器、顶级域服务器、权威服务器。这题必须配合dig实操# 关键加 trace 参数看真实递归路径不是 dig 8.8.8.8 的单跳 $ dig trace www.example.com ; DiG 9.16.1-Ubuntu trace www.example.com ;; global options: cmd . 505793 IN NS a.root-servers.net. # 第一步问根服务器 a.root-servers.net. 505793 IN A 198.41.0.4 ;; Received 286 bytes from 127.0.0.53#53(127.0.0.53) in 12 ms com. 172800 IN NS a.gtld-servers.net. # 第二步根返回 .com 顶级域服务器 a.gtld-servers.net. 172800 IN A 192.5.6.30 ;; Received 491 bytes from 198.41.0.4#53(198.41.0.4) in 21 ms example.com. 172800 IN NS a.iana-servers.net. # 第三步顶级域返回 example.com 权威服务器 a.iana-servers.net. 172800 IN A 192.0.32.1 ;; Received 242 bytes from 192.5.6.30#53(192.5.6.30) in 15 ms www.example.com. 3600 IN A 93.184.216.34 # 最终权威服务器返回 A 记录 ;; Received 60 bytes from 192.0.32.1#53(192.0.32.1) in 18 ms逻辑说明trace不是模拟是真实触发递归查询链。你看到的每一行Received ... from X#53就是一次真实的 UDP 53 端口通信。如果某一步卡住比如停在com.那行超过 5 秒说明你的本地 DNS 服务器到顶级域服务器之间的路由或防火墙有问题——而不是“DNS 服务器坏了”。这就是 PDF 第 118 题的血泪经验它训练你把抽象的“递归查询”映射到dig trace输出里每一行的时间戳和 IP 地址。3. 把 PDF 当成“故障树索引”用题目编号快速定位真实问题的排查路径这份 PDF 的题号不是随机编排而是按故障发生概率和排查优先级组织的。我把它当故障树Fault Tree用遇到问题直接翻题号不是找答案是找验证路径。例如故障现象对应题号验证动作关键参数/输出解读设备 ping 不通同网段其他机器第 24 题arp -a | grep 目标IP查看是否有对应 MAC若无执行arping -I eth0 192.168.1.100arping成功但arp -a无记录 → 本地 ARP 缓存未更新arping失败 → 物理链路或交换机端口问题SSH 连接超时但 ping 通第 76 题telnet 192.168.1.100 22或nc -zv 192.168.1.100 22Connection refused→ 目标 SSH 服务未运行Connection timed out→ 防火墙拦截或端口未开放浏览器打不开网页但 curl 可通第 132 题nslookup www.baidu.com对比dig www.baidu.comnslookup返回结果但dig超时 → 本地 DNS 解析器如 systemd-resolved配置异常两者均失败 → DNS 服务器不可达特别强调第 132 题它直指现代系统最玄学的故障点——DNS 解析器分层。很多工程师看到nslookup正常就认为 DNS 没问题却不知道curl默认走的是 glibc 的getaddrinfo()而nslookup直接走/etc/resolv.conf。验证必须双管齐下# 1. nslookup绕过系统解析器直连 resolv.conf 中的 DNS $ nslookup www.baidu.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.baidu.com Address: 180.101.49.12 # 2. dig同样直连但显示完整响应头 $ dig 8.8.8.8 www.baidu.com short 180.101.49.12 # 3. getent走系统解析器模拟 curl 行为 $ getent hosts www.baidu.com # 若此命令卡住或无输出但前两个正常 → 问题在 /etc/nsswitch.conf 或 systemd-resolved 配置参数说明8.8.8.8强制指定 DNS 服务器排除本地 DNS 缓存干扰short去掉冗余信息聚焦 A 记录getent hosts是验证系统级解析的黄金标准因为它调用的是 libc 的getaddrinfo()和绝大多数应用一致。再看第 24 题对应的 ARP 故障很多人以为ping不通就是网络不通但arping能精准切到数据链路层。arping的-I参数指定网卡至关重要——如果你有多个网卡如 eth0 和 docker0不指定-I可能发到错误网段# 错误没指定网卡arping 可能从 docker0 发出目标 IP 却在 eth0 网段 $ arping 192.168.1.100 ARPING 192.168.1.100 from 172.17.0.1 docker0 Timeout # 正确强制从 eth0 发送 $ arping -I eth0 192.168.1.100 ARPING 192.168.1.100 from 192.168.1.5 eth0 Unicast reply from 192.168.1.100 [AA:BB:CC:DD:EE:FF] 1.234msUnicast reply出现证明物理链路、交换机转发、目标设备 MAC 层响应全部正常——那问题一定出在 IP 层以上如目标防火墙丢弃 ICMP、或本机路由表错误。这就是 PDF 第 24 题的深层价值它用一道题教会你如何用arping把“网络不通”这个模糊描述精准切割到 OSI 第二层。4. 避坑PDF 里埋着 5 个高发“认知陷阱”踩中一个就多花 2 小时排查这份 PDF 的题目设计非常“诚实”——它不回避真实世界里的灰色地带反而把最容易让人翻车的细节藏在选项里。以下是我在客户现场被坑过、也见同事栽过的 5 个典型陷阱按出现频率排序4.1 现象第 41 题选“TCP 是面向连接的协议”被判错实际正确原因题目原文是“TCP 是面向连接的协议因此每次通信前必须建立连接”后半句是陷阱。TCP 确实面向连接但“必须建立连接”在特定场景不成立——比如 TCP Fast OpenTFO它允许在 SYN 包中携带数据绕过完整三次握手。Linux 内核 3.7 默认开启 TFO/proc/sys/net/ipv4/tcp_fastopen值为 3 时即启用。解决遇到“TCP 必须三次握手”类题目先查cat /proc/sys/net/ipv4/tcp_fastopen。值为 0 表示关闭传统模型值为 1/2/3 表示启用可发数据。生产环境若需严格遵循三次握手设为 0。4.2 现象第 95 题计算子网主机数用 2^6-262 得分但实际设备只分配 61 个原因题目假设“全 0 和全 1 主机位都不可用”这是 RFC 950 旧规范。现代 CIDRRFC 1878已废弃此限制ipcalc和ifconfig都允许使用全 0如 192.168.1.0/24作为主机地址。但某些老旧嵌入式设备如部分 PLC 固件仍硬编码校验拒绝接收全 0 主机位。解决排查工业设备联网问题时若 DHCP 分配了192.168.1.0立即换为192.168.1.1用ipcalc --noclass避免旧规范干扰。4.3 现象第 156 题说“HTTP 默认端口是 80”但抓包发现客户端连的是 8080原因题目没说“默认”但选项隐含“标准端口”。HTTP 协议本身不限定端口80只是 IANA 注册的默认端口。浏览器访问http://example.com时自动补:80但若 URL 显式写http://example.com:8080则完全合法。Wireshark 里看到目的端口 8080不代表协议不是 HTTP。解决抓包分析时不要只看端口要看 TCP payload 是否含GET / HTTP/1.1。用tshark -Y http.request -T fields -e http.host -e tcp.port提取真实 HTTP 请求。4.4 现象第 71 题“路由器工作在网络层”但客户 Cisco 路由器 ACL 却能过滤 TCP 端口原因题目描述的是“传统路由器”但现代三层交换机和企业级路由器如 Cisco ISR的 ACL 支持扩展匹配Extended ACL可检查 TCP/UDP 头部字段。这属于“网络层设备叠加传输层功能”不违背 OSI 分层原则只是实现复杂度提升。解决查设备文档确认 ACL 类型。access-list 101 permit tcp any any eq 22是扩展 ACL支持端口access-list 1 permit 192.168.1.0 0.0.0.255是标准 ACL仅 IP。混淆二者会导致策略失效。4.5 现象第 189 题“DNS 使用 UDP 传输”但dig返回MSG SIZE rcvd: 512原因DNS 确实默认用 UDP但 UDP 报文最大 512 字节不含 IP/UDP 头。当响应超过此大小DNS 服务器设TCTruncated标志位客户端必须重试 TCP。dig自动处理重试但nslookup不会——导致nslookup看似失败dig却成功。解决遇到 DNS 解析不稳定先dig tcp www.example.com强制走 TCP。若 TCP 成功而 UDP 失败检查中间防火墙是否拦截 UDP 53 或限制 UDP 包大小。5. 进阶技巧把 PDF 题目转化为自动化检测脚本让“知识”变成“生产力”把 PDF 当手册用效率上限是人工翻页。真正的生产力跃迁是把题目逻辑写成可批量执行的脚本。我用 Python subprocess 封装了 3 个高频场景的检测模块直接集成进巡检脚本5.1 “网络层连通性”一键验证对应 PDF 第 24、63、118 题#!/usr/bin/env python3 import subprocess import re import sys def check_network_connectivity(target_ip, dns_server8.8.8.8): 综合验证ARP - IP - DNS - HTTP print(f[] 验证目标 {target_ip}) # 1. ARP 层arping 检查数据链路 try: arping_out subprocess.run( [arping, -I, eth0, -c, 1, target_ip], capture_outputTrue, textTrue, timeout2 ) if Unicast reply in arping_out.stdout: print(✓ ARP 层通数据链路正常) else: print(✗ ARP 层不通检查物理连接或交换机) return False except Exception as e: print(f⚠ arping 执行失败: {e}) return False # 2. IP 层ping 检查网络层 ping_out subprocess.run( [ping, -c, 1, -W, 1, target_ip], capture_outputTrue, textTrue ) if ping_out.returncode 0: print(✓ IP 层通网络层正常) else: print(✗ IP 层不通检查路由或目标防火墙) return False # 3. DNS 层dig 检查解析 dig_out subprocess.run( [dig, f{dns_server}, target_ip, short], capture_outputTrue, textTrue ) if dig_out.returncode 0 and dig_out.stdout.strip(): print(✓ DNS 解析正常) else: print(f✗ DNS 解析失败检查 {dns_server} 是否可达) return False # 4. 应用层curl 检查 HTTP可选 try: curl_out subprocess.run( [curl, -s, -o, /dev/null, -w, %{http_code}, fhttp://{target_ip}], capture_outputTrue, textTrue, timeout3 ) if curl_out.stdout.strip() 200: print(✓ HTTP 服务正常) else: print(f⚠ HTTP 返回 {curl_out.stdout.strip()}服务可能未启动) except Exception: print(⚠ HTTP 检测超时跳过) return True if __name__ __main__: if len(sys.argv) 2: print(用法: python net_check.py 目标IP) sys.exit(1) check_network_connectivity(sys.argv[1])参数说明-W 1设置 ping 超时 1 秒避免卡死timeout2控制 arping 最长等待short精简 dig 输出。脚本按 OSI 层从下往上验证任一环节失败即终止符合“最小化定位”原则。5.2 “子网规划合规性”自动校验对应 PDF 第 63、95 题#!/bin/bash # subnet_check.sh —— 输入 IP/掩码输出合规警告 if [ $# -ne 1 ]; then echo 用法: $0 192.168.1.100/24 exit 1 fi INPUT$1 IP$(echo $INPUT | cut -d/ -f1) MASK$(echo $INPUT | cut -d/ -f2) # 用 ipcalc 获取网络地址 NETWORK$(ipcalc $INPUT | grep Network: | awk {print $2}) BROADCAST$(ipcalc $INPUT | grep Broadcast: | awk {print $2}) # 检查 IP 是否等于网络地址全0主机位 if [[ $IP $NETWORK ]]; then echo ⚠ 警告: IP $IP 是网络地址部分设备不支持 fi # 检查 IP 是否等于广播地址全1主机位 if [[ $IP $BROADCAST ]]; then echo ⚠ 警告: IP $IP 是广播地址非法主机地址 fi # 检查掩码是否为连续1防 /255.255.254.0 类非法掩码 if ! ipcalc -n $INPUT 2/dev/null | grep -q Valid; then echo ⚠ 警告: 掩码 $MASK 格式不标准请用 CIDR 表示如 /24 fi落地效果运维交接时把客户给的 IP 列表如192.168.1.0/24丢进脚本5 秒内标出所有潜在违规项。比人工查 PDF 表格快 10 倍且零遗漏。5.3 “DNS 解析链路”可视化追踪对应 PDF 第 118 题我放弃dig trace的原始输出用 Python 解析并生成层级图import re import subprocess def trace_dns(domain): result subprocess.run( [dig, trace, domain], capture_outputTrue, textTrue ) # 提取每层服务器和耗时 steps [] lines result.stdout.split(\n) for i, line in enumerate(lines): if Received in line and bytes from in line: # 提取服务器 IP 和耗时 match re.search(rReceived \d bytes from ([\d.])#\d in (\d) ms, line) if match: server, time_ms match.groups() # 上一行通常是查询的域名 query_line lines[i-1].strip() if i 0 else if query_line and IN in query_line: qname query_line.split()[0] steps.append((qname, server, int(time_ms))) print(fDNS 解析路径{domain}:) for i, (qname, server, time_ms) in enumerate(steps, 1): print(f{i}. 查询 {qname} → {server} ({time_ms}ms)) # 用法 trace_dns(www.github.com)输出示例DNS 解析路径www.github.com: 1. 查询 . → 198.41.0.4 (12ms) 2. 查询 com. → 192.5.6.30 (21ms) 3. 查询 github.com. → 192.30.252.153 (18ms)为什么有效dig trace输出是线性的但真实 DNS 是树状依赖。这个脚本把“Received from”提取为节点自动生成可读路径一眼看出哪一层延迟突增——比如第 2 步耗时 500ms基本锁定是本地 DNS 到顶级域服务器的链路问题。最后说句实在话我电脑里存着 7 个版本的这份 PDF最早是 2015 年扫描版最新是 2023 年社区修订版。不是因为它多完美而是它像一把钝刀——不炫技但每次划开故障表皮露出的都是最基础、最不容争辩的底层事实。那些花哨的 APM 工具、AI 运维平台在机房断电、网线被踩断、BIOS 设置被重置的瞬间唯一能救命的还是 PDF 里第 24 题的arping命令、第 118 题的dig trace输出、第 63 题的ipcalc结果。知识不是用来背的是用来在慌乱中伸手就能摸到的扳手。希望帮到你。本文还有配套的精品资源点击获取