Linux 网络诊断测验
最后更新：2026 年 9 月 14 日
以下 12 道题用于解读本地 HTTP、套接字、路由和 MTU 实验。题目中的数值仅作示例，并非实际测量结果。
选择题
- Shell 选择了一个远程 Docker context，但你想运行路由辅助程序。哪种准备方式符合它的约定？
- A) 辅助程序会自动使用当前选定的远程 daemon
- B) 在
/var/run/docker.sock上的本地 Linux Engine 中准备指定版本的镜像，并通过子网冲突预检 - C) 启用特权容器并发布路由器端口
- D) 同时启动多个副本，因为它们的子网范围是随机的
显示答案
答案：B) 在 /var/run/docker.sock 上的本地 Linux Engine 中准备指定版本的镜像，并通过子网冲突预检
解释： 该辅助程序固定使用本地 Unix socket，并忽略远程 host / context 环境变量。它使用固定的文档子网，因此不同运行之间不得重叠。运行前必须已有相应镜像。专用 bridge 禁用 masquerading；只有三个归自己管理的容器会失去 IPv4 默认路由。Docker 仍会创建主机 bridge 并管理网络规则。
- GET
/lesson返回正文b"hello\n"。正确的 Content-Length 是多少？- A) 5，因为只计算可见字母
- B) 7，因为正文中的每个换行符都必须是 CRLF
- C) 6，因为五个 ASCII 字母和结尾的 LF 共六个字节
- D) 响应标头加上正文的总长度
显示答案
答案：C) 6，因为五个 ASCII 字母和结尾的 LF 共六个字节
解释： 正文的十六进制内容是 68 65 6c 6c 6f 0a。HTTP/1.1 标头行的 CRLF 规则不会把正文中的 LF 转换为 CRLF。Content-Length 计算正文内容的字节数，不包括起始行、标头和分隔符。echo 辅助程序也会保留通过 --data-binary 传入的字节。
curl --http1.1 -I从/lesson收到Content-Length: 6，但没有显示正文。发生了什么？- A) curl 发送了 HEAD；响应没有正文，该长度描述对应 GET 表示的内容长度
- B) curl 发送了 GET，并在收到后丢弃六个正文字节
- C) 服务器没有发送要求的六个字节，违反了消息定界规则
- D) HEAD 响应的 Content-Length 必须始终为零
显示答案
答案：A) curl 发送了 HEAD；响应没有正文，该长度描述对应 GET 表示的内容长度
解释：-I 会选择 HEAD。即使包含允许出现的表示长度，HEAD 响应也不带消息正文。这与 -i 不同，后者会在正常输出中包含响应标头。如果把 HEAD 元数据误当成正文定界信息，客户端可能会错误解析持久连接上的下一个响应。
- HTTPS 请求的 curl 跟踪输出中出现了可读的 HTTP 标头。这能证明什么？
- A) 标头在网络上传输时没有加密
- B) 每一行跟踪输出都对应一个 TCP 数据包
- C) HTTP/2 和 HTTP/3 在网络上使用 HTTP/1.1 文本行
- D) 客户端可以显示自己处理的 HTTP 数据；这不是被动数据包捕获
显示答案
答案：D) 客户端可以显示自己处理的 HTTP 数据；这不是被动数据包捕获
解释： Curl 调试输出由客户端生成，因此可以显示网络上受 TLS 保护的数据。输出中的标注不是线路编码，也不表示分段边界。HTTP/2 和 HTTP/3 同样使用二进制分帧。抓包可见内容取决于观测点和是否有可用的会话密钥。
- 一次示例
ss快照显示 LISTENRecv-Q=3、Send-Q=128，以及 ESTABLISHEDRecv-Q=6。哪种解释正确？- A) 监听器在 128 字节的发送缓冲区中保存了三个正文负载字节
- B) 监听器有三个未完成的 SYN，而已建立套接字有六个排队连接
- C) 监听器有三个等待 accept 的连接，最大 backlog 为 128；已建立套接字有六个尚未读取的有序字节
- D) 这三个数值都是拥塞窗口大小
显示答案
答案：C) 监听器有三个等待 accept 的连接，最大 backlog 为 128；已建立套接字有六个尚未读取的有序字节
解释： 队列列的单位取决于套接字状态。LISTEN 列描述 accept 队列，而不是尚未完成的 SYN 队列。ESTABLISHED 列描述流字节；套接字的 Send-Q 包括尚未确认的字节。应针对测试端口进行过滤，并区分客户端和服务器端点。
- 持久客户端请求成功，两个流队列常常都显示为零，而
skmem仍有非零内存值。应该得出什么结论？- A) 连接已损坏，因为队列为空时套接字内存必须为零
- B) 内存记账和额度不同于流占用量；少量工作负载可以在两次观测之间排空
- C) 增加所有 TCP 缓冲区 sysctl，直到流队列始终非零
- D)
rb是通告给对端的精确接收窗口
显示答案
答案：B) 内存记账和额度不同于流占用量；少量工作负载可以在两次观测之间排空
解释： 客户端会在下次请求前读取每个六字节响应。这是观测练习，不是强行填满缓冲区的测试。skmem 包括内核记账和预算；接收窗口和拥塞窗口是不同的量。仅读取策略值并进行重复观测，并不足以证明应采用某个通用调优设置。
- 客户端为
192.0.2.2/29，到198.51.100.3的路由使用网关192.0.2.3。预期的 ARP 结果是什么？- A) 查询
192.0.2.3对应的 MAC；客户端不需要为198.51.100.3创建邻居项 - B) 在客户端左侧网络中直接建立远程服务器的 MAC 映射
- C) ARP 会将 IP 目标地址改为
192.0.2.3 - D) DNS 会提供以太网目标地址，因此不需要 ARP
- A) 查询
显示答案
答案：A) 查询 192.0.2.3 对应的 MAC；客户端不需要为 198.51.100.3 创建邻居项
解释： 路由查找会先选出链路上的下一跳，再执行邻居解析。以太网帧的目标是路由器的 MAC，而 IP 目标仍然是服务器。在右侧网络上，路由器会自行查找路由并解析邻居。服务器也需要配置显式的返回路由。
- TTL 为 1 的 ping 以失败状态退出，而路由器抓包中包含引用了该探测包的 ICMP Type 11 Code 0。实验应如何解读？
- A) 目标完成了一次 HTTP 请求
- B) 路由器报告了 TCP MSS 不匹配
- C) 所有后续应用数据包都会在同一路由器处失败
- D) 刻意设置的较小 TTL 在路由器处耗尽，产生了预期的诊断响应
显示答案
答案：D) 刻意设置的较小 TTL 在路由器处耗尽，产生了预期的诊断响应
解释： 发出的 Echo Request 和返回的 Time Exceeded 是不同消息。将捕获到的错误与探测包关联起来，才能证明出现了预期事件。单独的超时不能证明这一点；过滤、响应限速或返回路径丢包也可能导致没有回复。此辅助程序使用路由器网络命名空间内的实际抓包进行检查。
- 路由器出口 MTU 为 1280。一次 IPv4 DF ping 的数据部分为 1372 字节，另一次为 1200 字节。加上 IPv4 和 ICMP 基本标头后，预期结果是什么？
- A) 两者都能通过，因为 MTU 只计算 ICMP 数据
- B) 第一个在 IP 层为 1372 字节，第二个为 1200 字节
- C) 1400 字节的 IP 数据包会触发 Fragmentation Needed；1228 字节的数据包可以通过
- D) 较大的探测包会将 TCP MSS 协商降至 1200
显示答案
答案：C) 1400 字节的 IP 数据包会触发 Fragmentation Needed；1228 字节的数据包可以通过
解释： 加上 20 字节 IPv4 标头和 8 字节 ICMP 标头。DF 阻止路由器分片，因此第一次发送失败时应伴随 ICMP Type 3 Code 4；较小的探测包则会成功。PMTU 反馈缓存后，后续超大数据包可能在本地失败，而不是再次触发路由器抓包。
- 在 loopback HTTP 连接上执行
ss -i，显示的 MSS 大于 1460。可以据此得出什么结论？
- A) 辅助程序肯定在物理接口上启用了巨型以太网帧
- B) 1460 的计算假设以太网 MTU 为 1500，并使用 IPv4 / TCP 基本标头；loopback 条件不同
- C) ICMP 探测数据大小就是实际 TCP MSS
- D) 所有大于 1500 的捕获单元都能证明物理线路 MTU 配置错误
显示答案
答案：B) 1460 的计算假设以太网 MTU 为 1500，并使用 IPv4 / TCP 基本标头；loopback 条件不同
解释： MSS 表示 TCP 数据长度，不是 ICMP 数据或整个帧的长度。接口 MTU、选项和路径行为都会产生影响。TSO / GSO / GRO 也可能导致主机侧观测结果不同于物理链路上的数据包。loopback 练习无法证明物理以太网 MTU 的情况。
- Docker DNS 能正确解析路由器名称，但客户端到服务器的普通 ping 失败。已经确认了什么？
- A) 名称解析正常；仍需检查路由选择、转发和返回路径
- B) 服务器应用处于健康状态
- C) 两个专用 bridge 提供了可用的互联网 NAT
- D) 主机上的 loopback HTTP 服务器一定能通过
127.0.0.1从每个容器访问
显示答案
答案：A) 名称解析正常；仍需检查路由选择、转发和返回路径
解释： DNS 和转发测试的是不同机制。此实验环境使用专用 bridge 之间的显式路由，并禁用了 masquerading；它不是互联网 NAT 基准测试。每个网络命名空间都有自己的 loopback；主机的 loopback 服务器不是容器内服务。应在每个查找实际发生的命名空间中关联观测结果。
- 路由 JSON 中有部分观测成功，但整体状态为失败或清理未完成。正确的处理结果是什么？
- A) 因为路由查找成功，就将整次运行计为通过
- B) 如果镜像仍缓存在本地，就忽略清理
- C) 执行范围广泛的 Docker prune，以保证主机干净
- D) 保持运行结果为失败，检查失败阶段，并仅识别需要清理的已创建 ID
显示答案
答案：D) 保持运行结果为失败，检查失败阶段，并仅识别需要清理的已创建 ID
解释： 一次成功运行要求执行顺利完成、八项检查全部为 true，且报告已完成清理，其中包括三个容器的 IPv4 默认路由列表都为空。辅助程序会追踪创建的 ID，而不会删除无关的命名资源。意外终止可能导致清理无法完成。保留证据，之后重新运行时使用新的输出路径；不要绕过共享网络控制来强行获得通过结果。