# 调试客户网络，Kurose 和 Ross 这本书读三章就够

> 八章不必全读，第 2、3、8 章加上免费的 Wireshark 实验，足以拆解一条出故障的连接。

原文: https://fdetimes.net/zh/books-courses/kurose-ross-chapters-fde-network-debugging/

设想一个在客户办公室度过的下午。客户说每次 API 调用都要好几秒，而你的服务器日志显示处理只花了几十毫秒。时间差就藏在链路的某一段，而要准确指出在哪一段的人，正是你。

对前线部署工程师（FDE）来说，这种场面并不陌生。你身处别人的网络，面对的是他们的代理、他们的证书、他们的 Wi-Fi，旁边也没有基础设施团队替你分担。很多习惯在应用层工作的工程师，可能也是第一次需要逐个查看数据包。

James F. Kurose（UMass Amherst）和 Keith Ross（NYU Abu Dhabi）合著的 *Computer Networking: A Top-Down Approach* 并不是为 FDE 写的。但只要挑对章节，再配合作者向教师、学生和读者免费提供的 Wireshark 实验，它恰好能给你那个下午所需要的一切。

## 自顶向下，正是客户投诉的顺序

第 9 版于 2025 年夏季面世，Pearson 标注的发布日期为 2025 年 6 月 20 日。读者可以在线阅读、租用，也可以购买纸质版。全书八章，从“计算机网络和因特网”讲到“计算机网络中的安全”，Pearson 对这种写法的描述是：自顶向下地呈现这一复杂主题。

这本书适合 FDE，原因就在自顶向下。客户从不按网络分层报告故障，他们报告的是自己看到的现象：页面打不开、请求卡住、浏览器弹出红色的证书警告。从应用层出发逐层向下，正是优秀的调试者提问的顺序。

## 多数事故从第 2、3 章开始

本版第 2 章（应用层）针对 HTTP/3 和 QUIC 做了更新，调试客户的 Web 或 API 流量之前，读的正是这些内容。第 3 章（传输层）更新了拥塞控制，并补全了第 2 章开头的 QUIC 内容，所以两章应该连起来读。

在“API 慢”的案例里，消失的那几秒几乎都能在这两章里找到去处：域名解析、连接建立、传输途中丢弃的数据包。用好它们最有效的办法，是直接拿到抓包里去用。

## 在 Wireshark 里追查“API 慢”

先征得客户同意，然后在出问题的机器上抓包，同时复现一次 API 调用。不要试图一次看完整个抓包文件，而要按书中讲解的顺序逐层过滤。下面的数字只是示意异常结果可能的样子，并非标准阈值。

第一步，输入过滤条件 `dns`，对比每条查询与对应响应的时间。

假设一次正常查询约 20 毫秒就能得到响应，而客户的抓包显示查询重发了两次，1.5 秒后才收到响应：大部分延迟在 HTTP 开始之前就已发生，这属于第 2 章的范畴。

第二步，过滤 `tcp.analysis.retransmission`，让 Wireshark 只显示重传的报文段。假设一次调用有 400 个报文段，其中 40 个被重传，即 10%：数据包在传输途中丢失，第 3 章能给你足够的术语，解释连接吞吐量为何因此受到抑制。

如果只看到零星一两行，问题多半出在别处。如果过滤 `tcp` 几乎什么都看不到，就试试 `quic`，因为连接可能跑在 HTTP/3 上。

第三步，过滤 `tls.handshake`，看握手进行到哪一步。比如客户端发出第一条 hello 后等了好几秒都没有回应，或者握手以错误告警结束，断点就找到了。只有三步都没有问题时，才去测量从发出请求到收到响应第一个字节的时间。

到这一步，你和客户说的话就完全不同了。原来只能说“我查一下”，现在可以说“你们的连接在请求到达服务器之前反复重传数据包”。前一句只是拖延时间，后一句直接指向修复方向。

这里容易犯三个错误：

- 在自己的笔记本上抓包，而不是在客户的真实链路上抓，结果你的抓包一切正常，客户那边依旧很慢。
- 只凭一次抓包下结论，而问题可能只在高峰期出现。
- 还没检查 DNS 就归咎于“网络”，而 DNS 恰恰是排除成本最低的一环。

## 握手出问题时读第 8 章

第 9 版第 8 章（安全）新增了 TLS 1.3 和 WPA3，客户环境中证书或握手失败时，需要的正是这些内容。先读懂一次正确的握手如何进行，再去找它在哪里断开。

**要点:** 只有知道健康的连接是什么样子，才能发现出故障的连接。

另有两章值得了解，但可以往后放。第 5 章（网络层：控制平面）新增了 SDN 内容，并以 Google 的 Orion 网络控制系统为案例，需要处理客户的路由或云网络时会用得上。

第 7 章（无线网络和移动网络）是本版改写幅度最大的一章，涵盖 Wi-Fi 6 和 5G。问题出在客户办公室的 Wi-Fi 或移动网络时，再翻开它。

## Wireshark 实验让阅读变成动手

作者的实验页面写道，观察协议实体之间交换报文的基本工具是分组嗅探器。这些实验教的正是这项技能，覆盖 HTTP、DNS、TCP、UDP、IP、NAT、DHCP、ICMP、Ethernet 和 ARP、802.11 Wi-Fi、5G 以及 TLS。

这些实验不是为了应付考试。Wireshark 官方文档提到，网络管理员用它排查网络问题，所以你在家练的技能，就是你在客户机器上要打开的工具。

对 FDE 来说，合理的顺序是：读第 2 章，做 HTTP 和 DNS 实验；读第 3 章，做 TCP 实验；然后跳到第 8 章，做 TLS 实验。第 1 章快速浏览，了解整体框架即可，其余章节等项目需要时再读。

## 记住三个思路，并写进简历

合上书之后，有三个思路值得带到现场。一是自顶向下调试，从客户能看到的现象入手。二是这本书在应用层和传输层两章都讲了 QUIC，所以排查 QUIC 故障不要只盯着一处。三是先用分组嗅探器观察，再做推测，顺序不能反。

至于职业发展，简历上写一句“熟悉网络”说服不了任何人。从个人项目里抓一次真实的 API 调用，按上面三个过滤条件逐一分析，写一页说明讲清每一步花了多少时间，再把它放进作品集。

看 FDE 招聘启事时，留意那些提到客户网络环境、VPC 或企业代理的岗位：在这些岗位上，这样一份分析最能让你脱颖而出。

下次客户再说“API 很慢”，你不必再靠猜。打开抓包，指给他们看时间都花在了哪里。

**本周动手试试:**

- 下载 Wireshark，在自己的机器上完成 Kurose 和 Ross 的 HTTP 与 TCP 实验
- 从当前项目中抓取一次 API 调用，依次过滤 dns、tcp.analysis.retransmission 和 tls.handshake，记下每一步耗时多久
- 阅读第 8 章的 TLS 1.3 小节，然后在 TLS 实验的抓包中找出握手报文

## 信源

- [Computer Networking: a Top Down Approach (Kurose & Ross companion site)](https://gaia.cs.umass.edu/kurose_ross/index.php)

- [Computer Networking: A Top-Down Approach, 9th edition (Pearson)](https://www.pearson.com/en-us/subject-catalog/p/computer-networking/P200000013385)

- [What's new in the 9th edition?](https://gaia.cs.umass.edu/kurose_ross/ninth.php)

- [Wireshark Labs (Kurose & Ross)](https://gaia.cs.umass.edu/kurose_ross/wireshark.php)

- [Wireshark User's Guide: Introduction](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html)