开篇词 | 网络排查是工程师的必备能力

杨胜辉



讲述：杨胜辉大小：16.16M时长：17:41



该思维导图由 AI 生成，仅供参考

你好，我是杨胜辉，欢迎和我一起开启这场网络排查之旅。
为什么在这个时代，网络排查能力变得越来越重要了？先和你简单介绍一下我自己，我目前是 eBay 中国卓越技术中心基础架构部门的运维经理，主要负责 eBay 全球的流量管理业务，推动 Kubernetes 在 eBay 流量管理场景中的落地。
我算是一个基础架构的老兵了，在 18 年的工作经历中，我实实在在地遇到过太多技术方面的疑难杂症。尤其是最近几年，随着微服务和云计算的不断普及，越来越多的系统从本地的单体服务，变成跨网络的分布式的微服务。那么随之而来，就是数不清的跟网络相关的问题。比如：
为什么我的应用在单体应用的时候很正常，拆分成微服务以后却时常超时、报错呢？
为什么我的带宽是足够的，但数据传输速度却很慢？
为什么我的应用偶尔会卡住，但又不是每次都这样？
为什么……
面对这么多问题，我们经常束手无策。有些同学自嘲是优秀的“SRE”（Server Restart Engineer），遇到问题先上“重启大法”，也许也能搞定不少问题。但是呢，根因依然是未知，即使问题暂时消失了，但不知道什么时候，它又会再次到来，然后再次重启……
所有这一切，都让我深深地感到：我们的工程师，太需要网络排查方面的能力了。
无论你是运维还是开发，无论是产品还是测试，都没法彻底回避网络问题。但是，因为大部分同学并不是网络出身，对于跟网络相关的问题，经常无从下手，或者事倍功半。在这方面，常见的困难就有：
对于网络知识点好像是懂的，但一遇到实际的网络故障，就又不懂了，更不知道排查工作如何做起；
网络知识是懂的，也能做一些排查，但是遇到艰深一点的问题时，就“卡壳”了，无法把排查工作进一步推动下去；
对于网络排查有一些经验，比如前面说的“重启大法”，比如知道修改某个配置可能有用，但是因为不知道其原理，在三板斧不见效的时候，就别无他法；
本身负责应用开发，也有兴趣自己来排查网络问题，但苦于没有这方面的背景和积累，排查工作很容易“熄火”，令人沮丧。
如果你符合 1，那么请不要失去信心，只要你踏实打好网络知识的基础，网络排查并没有那么艰难和神秘，通过学习，你也一样能掌握网络排查的能力。
如果你符合 2，那么请多一些坚持，因为你还需要继续打磨对网络关键知识点的深刻理解。同时，也需要强化自己在一些高级技巧，比如抓包分析上的能力。因为只有这样，你才能突破瓶颈，真正把问题搞透。
如果你符合 3，那么请多一些耐心，先不要过于依赖你过往的经验，而是沉下心来，剖析你的经验之所以有效的底层原理。这样，你既有经验也有理论，你的排查能力将又提升一个层级。
如果你符合 4，那么请不要气馁，你能成为应用方面的高手，那么一样有潜能成为网络排查方面的高手。事实上，要成为应用开发方面的大牛，网络也是极为重要的一关，搞不定网络，你的应用依然是跛脚的，无法达到最优的状态。
我的网络排查能力是如何成长起来的？不过，虽然我现在能给很多人讲解网络排查的技巧，其实我以前也是一枚小白。
刚工作时，我在一家央企中国远洋集团工作，主要维护公司的几百台 Windows 服务器、邮件系统等，不太接触网络。但是有一件跟网络相关的事情，给我留下了很深的印象。
当时欧洲分公司的 Exchange 邮件系统遇到故障，我们从 Exchange 系统本身来排查，却怎么也找不到问题所在。团队奋战数天后，最终在网络组的协助下，才发现是网络层问题导致的。假如时光可以倒流，我带着现在的网络排查能力回到过去，是不是可以把几天变成几小时甚至几分钟呢？我忍不住会这样遐想。
也是从那次开始，我深刻地体会到：无论是不是专职的网络工程师，我们都应该掌握好网络，只有这样才能把本职工作做到更好。
后来我来到了 eBay，开始负责起 eBay 的整体的 Web 流量。我们知道，网络和应用的关系是十分错综复杂的，而正是因为要处理 eBay 这种海量级的访问场景，多年来，我在这方面就积累了很多经验和理解，逐步形成了对于“网络排查”这个宏大主题的一些自己的实操经验和方法论。
在 eBay 做了几年后，因为被云计算的丰富的技术性所吸引，我加入了一家公有云初创企业 UCloud，负责起售后技术服务。
如我所愿，由于客户和云平台的多样性，大部分网络场景和协议我都能遇到，也帮助我积累了鲜活的案例，以及接地气的排查经验，我也很享受这个过程，不断地丰富和打磨我的网络排查体系。我有一个习惯是每处理一个问题就开一个文件夹，里面放上相关的日志、抓包文件等，当时记录有 500 个文件夹之多。这几年有一个新流行的说法叫“刻意练习”，而那段日子，也是印证了这个说法，我也确实从中收获良多。
就比如说，我们负责的一个客户是做健康硬件的，就是一个硬件的体重计，配合他们的手机 App，帮助消费者做身材管理。有一段时间，他们的 Nginx 上有大量的 499 报错。起初他们怀疑问题在我们云平台网络这里。为了“自证清白”，同时也是为了寻求真相，我花了好几天研究这个案子，最终证明这并不是云平台的问题，并且找到了根本性的解决办法。
有意思的是，在合作过程中，我跟另一家大厂的工程师建立了网络上的友谊。这也让我体会到：技术本身就是技术人之间的共同语言，也是连接我们的桥梁。
也是从那时候开始，我会在博客上分享自己的排查经验，包括从云计算公司回 eBay 后也一直在坚持，并逐渐得到了一些朋友的关注。能给身边的人以帮助，同时还发挥了自己的长处，这让我非常开心。我也特别想把这份收获，通过极客时间这么好的平台，分享给更多在这个技术行业里的其他同学。
也许你也对这个领域有兴趣，但苦于找不到合适的老师；也许你在实际工作中面临着类似的技术问题，但找不到好的方法，那我的这门课程可能对你会比较有帮助。倘若你通过学习我的课程，把很多知识点搞明白了，或者在实际工作中，确实能把网络问题给解决了，那我就再高兴不过了。
这门课程能给你带来什么？那么现在你可能会问了，跟着我学习这门实战案例课程，都会有怎么样的收获呢？具体来说，有这么几点。
更扎实的对网络各层知识的理解我举个例子，技术面试的时候，一个常见的问题就是：请介绍一下 TCP 握手的过程。这也算是面试八股文了，很多人背一下也能过，不过是否真的理解就难说了。那么在这门课程里面，我会把握手、挥手等各种细节都带到，而且会结合真实案例来讲解这些知识点，使你不仅知其然，而且知其所以然。下次回答这个问题的时候，恐怕面试官都要对你刮目相看了。
更广阔的排查视野一般来说，网络问题用网络方面的工具排查，系统的问题用系统方面的工具排查，应用层也是如此。不过现实情况是，很多问题在一开始，并不能明确地归属到网络，还是系统，还是应用代码。所以作为排查者，我们不应该在一个预设的立场下展开排查工作，因为那样很容易就偏离了真相。
而在这门课里，很多案例也都是“看起来是 A，查着是 B，最后定位出来是 C”的情况，这其实也是最真实的现实了。有了更广阔的排查视野，你就不会因为不熟悉另外一个领域，就不得不放弃，或者“硬扛”了；有了更广阔的排查视野，你就不会局限在原有的一亩三分地里面，而是真正地把问题搞清楚，你的价值也不用说，会得到更大的认可。
更熟练的排查技术很多同学其实也用过 tcpdump 和 Wireshark，包括我做面试的时候，不少候选人也都能就 tcpdump 和 Wireshark 侃侃而谈，但是追问细节的时候就语焉不详了。以 Wireshark 为例，它确实提供了相当多的信息提示，比如丢包和重传都会用不同的颜色跟正常的数据包区分开。
不过，为什么重传、为什么丢包，这些问题的答案，Wireshark 会告诉你吗？不会。是 Wireshark 不够强吗？也不是。
因为每个组织、每个应用的情况都相差极大，只有靠你自己平时积累的经验，以及结合具体的网络和应用环境，才能获得最符合你这个特定案例的答案。而这门课里就有很多这样的例子，特别是我做公有云服务的时候的多样化的案例经验，都是我个人的独家经验，我也相信一定能给你很多启发。
更完善的知识体系如果你是做开发的，现在各种软件库和框架都极大地提升了我们的开发效率，但同时也屏蔽了很多底层细节。举个例子，应用层的“connection reset by peer”的报错，又如何跟底层网络的实际情况结合起来呢？应用层本身并不能回答这个问题。
那么通过这门课程，我们将解开很多的技术点的层层包裹，端详它们本来的模样，真正地理解这些技术设计者的初心。这也会帮助我们更好地理解这些技术的来龙去脉，反过来也能帮助我们更好地完成上层业务。
如果你是做运维的，那么这个作用会更加明显。对底层原理的掌握，将会极大地提升运维工作的质量，无论是平时工作时候的“气定神闲”，还是故障危机时候的“英勇相救”，都将是你通过这门课程获得的能力。
所以呢，这次我的网络排查课，形式会跟其他课程有所不同。不是单纯地讲理论或者讲工具，而是围绕案例这个核心，展开我们的排查过程，并会聚焦到工具的使用，以及深入到关键技术点的分析上。
这门课程是怎么安排的？那么，课程具体是怎么设置的呢？我把这门课分成了五大模块，分别是：
预习篇
在这个部分，我会从网络分层模型出发，来带你了解、学习并掌握整个网络世界的大体层次，和每层的相关工具。然后带你进入抓包分析这个技术殿堂，了解它的历史和现在，以及初步的使用方法。通过对分层模型和每层工具的理解，以及对抓包分析技术的认识，你就能打下网络排查的底层基础，为后续的学习铺平道路。
实战一：TCP 真实案例揭秘篇
接下来，我们就要进入真正的实战了。
在这个模块里，我会从各种跟 TCP 相关的实际案例出发，来带你了解、学习并掌握 TCP 这个精密仪器的核心技术，包括传输性能的关键点、TCP 重传的原因和对策、拥塞的优化策略、TCP 保活机制等。我会通过一个个真实的案例，帮助你达成对这些核心知识点的真正理解，最后能够融会贯通，再也不怵 TCP 相关的难题。
实战二：应用层真实案例揭秘篇
在理解了 TCP 这部重要篇章之后，网络排查的核心知识，你就掌握了快一半了。不过，还有另外一个同等重量级的篇章等待你去学习，它就是应用层网络排查。其中，我们还需要补齐一个重大的短板：应用和网络之间的桥梁。
那么在这个模块里，我会从一个个典型的应用层网络排查案例出发，来带你了解、学习并掌握如何排查应用层的网络问题，让你通过对抓包分析这个核心技术在应用层的运用，搭建起应用和网络之间的“桥梁”。学完这个部分后，你在应对应用层的网络问题时就会成竹在胸了。
实战三：不用抓包就能做的网络排查篇
最后，我们还需要学习抓包分析之外的其他网络排查方法，因为掌握抓包分析相当于掌握了网络排查的主干，但还需要补充枝叶，这样我们的网络排查技能树才足够完整。所以在这个模块里，依然是从实际案例出发，来带你了解、学习并掌握这些工具的背后原理、使用场景、个人总结，让你能够通过对原理和实践经验的理解，达成融会贯通的目的。
总结篇
在学完前四个模块的具体技术之后，现在我们应该来一次总结了。所以在最后，我想再带你整体沉淀升华一下，一起把前面学习过的网络知识、抓包分析技术、所有其他的网络工具的技巧复习一遍，把它们打碎后，再次拼接在一起，形成你自己的技术体系。这样，你不仅可以学习到我的经验，还能够转化为你自己的理解，从而实现真正突破网络排查瓶颈的最终目标。
最后，我还想说的是，网络问题的排查过程，其实就像读一本侦探小说一样，充满了神秘感和吸引力。当你掌握了网络排查技术之后，你在遇到问题的那一刻，就不会再像过去那样想要逃避，反而会像猎人遇到猎物一样兴奋，很想一试身手，最终把案件调查彻底，水落石出。对于这样一个美妙的状态，你是不是很期待呢？
从这个角度上说，你甚至可以把课程当故事来看，不过你一样可以收获到知识，经历我曾经历过的起伏，从一个胡同到一个旮旯，兜兜转转，找到灯火阑珊处。我也许做不到让你“衣带渐宽”，但我愿你“终不悔”。共勉。
在这里，我想跟你一起立一个 flag：你可以每节课后在留言区进行提问和交流，我也会及时回复你，哪怕只是打个卡，等两个月后你学完全部课程，一定会有很大的收获。
最后的最后，我想说：
二十多讲的课程，就是我们有二十多次的相遇，而随着课程的推进，我们或许还会有更多的交集。我要感谢你决定花这么多时间，来学习这门课程。同时我也建议你，感谢下你自己，因为你愿意花时间来这个课程学习，因为你想做更好的自己。只要坚持下去，你一定可以做到！

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

网络排查能力对于工程师来说变得越来越重要。文章作者杨胜辉强调了网络排查能力的重要性，并分享了自己在这方面的成长经历和对读者的帮助。随着微服务和云计算的普及，网络问题变得更加复杂，而工程师们往往束手无策。杨胜辉指出，拥有更广阔的排查视野、更熟练的排查技术和更完善的知识体系是解决网络问题的关键。他提出了针对不同类型工程师的建议，并分享了自己的成长经历，从最初的小白到如今能够分享实战案例课程的高级技术人员。文章还介绍了杨胜辉的网络排查课程的设置，包括预习篇、实战一至三、以及总结篇，强调了通过学习课程可以获得更扎实的网络知识理解，并能够在实际工作中解决网络问题。整篇文章强调了网络排查能力的重要性，并分享了作者的成长经历和对读者的帮助。

2022-01-12119人觉得很赞给文章提建议

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《网络排查案例课》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(69)

最新
精选

分清云淡
https://plantegg.github.io/categories/network/ 看完这些网络排查案例相信对大家学习这门课程很有热情的，雷锋，不用谢
作者回复: 嗯也是实际案例，做案例真的是成长最快的方式之一
2022-01-13
4
66
01
老师你好，我们今天线上遇到一个http 503 的issue，提示service unviable的问题，请求过程是这样的，内网机器通过proxy代理服务器去call另外的内网机器，大概有可能是哪里的问题呢？ proxy server和另外的内网机器我们都没权限查看。。。
作者回复: 嗯，这也是典型问题场景：应用层有报错，但我们并不知道网络上具体发生了什么，更无法知道这些网络行为对应的技术原理和对策是什么。这也是我在刚结束的直播课里，给大家提到的网络排查的两大核心难点之一：应用症状和网络现象之间的鸿沟。另外一个核心难点，是wireshark等工具提示跟技术原理之间的鸿沟。只有跨过了这两道鸿沟，我们才真正能把网络排查这门技术给做起来。所以如果要彻底查清楚，是需要抓包后做分析的，过程不是一两句能说清楚，我在课程里会重点讨论这方面的思路和方法，你可以期待一下：）关于http报错代码，也可以从协议规范出发，初步判断问题在哪里。比如这个503，意思是service unavailable，也就是这个proxy想要找后端的机器，但是没有找到。这个原因也有多种，比如proxy到后端机器在网络上就不可达，或者健康检查发现没有可用的机器，等等。你可以让有权限的同事帮你到proxy server上抓取网络报文，要想办法在抓取期间，重现503问题。然后你就可以借助我后面课程里的方法，进行分析了。
2022-01-12

12
GAC·DU
一个线上服务出现网络故障，SRE需要一分钟，而排查需要时间未知，如何选择？
作者回复: 一般对于明确的故障，特别是影响到业务可用性的故障，首先是做恢复，而不是排查。先通过切换到健康集群或者其他数据中心的方式，把业务尽快恢复。之后再做排查，或者两者同时做。但不应该把恢复放在后面哦
2022-01-12
3
6
　x
我一般是本机telnet 0.0.0.0 端口和telnet 127.0.0.1 端口. 然后外面 telnet ip 端口, 这样排查问题, 看通不通
作者回复: 嗯多数情况下可以这么做，不过有个前提：监听这个端口的程序，申请的socket地址是统配地址，也就是0.0.0.0。如果程序显式的声明其监听地址为某个特定ip，那么这个telnet 127.0.0.0 port的做法就会失败，但不表面这个端口没在监听。其实你可以用netstat -ant | grep 端口号，看看这个端口的状态是不是LISTEN，以及监听的地址是0.0.0.0还是什么。或者lsof -i:端口号，也可以看到。不过要注意下，netstat不需要用sudo权限，但lsof -i需要sudo。
2022-01-12
2
5
啊树
程序猿一枚请问学习该课程需要先阅读那些书籍来做辅助？
作者回复: 不是一定要提前阅读参考书籍的。你可以先把预习篇的两课仔细看一下，有什么问题可以在那边的留言区提问，我一定会回复你。书籍方面，我推荐Richard Stevens的《TCP/IP详解》第一卷。这个也是大部头，第一遍只能看懂一小部分是很正常的，可以从我的课程里学习实际案例，再结合书中的内容来理解。或者等学习完整个排查课后，再去看书也可以的，因为到课程学完后，哪怕不是每个细节都理解了，但至少对应用和网络之间的关系，以及问题可能属于哪个知识点的问题，你就有正确的理解，也知道应该去看书里的具体那一部分内容了。
2022-01-15
5
4
晴天
工作中遇到connect timeout和read timeout，总有一种无助感，希望学完课程能突破
作者回复: 好的，这两个timeout也都是常见的timeout。一个是连接超时，一个是读取（等待数据）超时。我在TCP实战篇里都会讲到的：）
2022-01-12
2
4
Horizon_carry
打卡学习，大哥，跨境限制抓包看他三次握手里面ttl时间与64的大小，跨境在这里限制了，可以这样理解吗
作者回复: 你是指great wall吗简单回答你，是的
2022-01-12
3
3
姜姜
课程有没有对容器网络问题排查的讲解？
作者回复: 嗯直播课的时候有同学提到了，我后续会做加餐，安排这方面的案例介绍
2022-01-12
2
3
Ricky was a young boy
打卡第一天，刚开的会员
编辑回复: 加油加油💪
2022-03-18

2
流水
老师，您好。在实际的生产环境排查过程中，往往需要等待问题复现，尝试部署抓包工具进行守株待兔，这里又可能对环境造成额外负担或可能引发次生故障，同时因对问题没有清晰的特征判断，也不能在测试环境进行准确复现，请问有没有什么好思路或实践？
作者回复: 您好，您提到的问题很常见。不过一般来说，如果抓包过滤条件比较精确，比如限定到某个ip某个端口，那对系统的额外压力并不大，建议还是要做抓包。这是第一个问题。第二个是关于“守株待兔”，兔子什么时候会出现的问题。我们的实践是，如果有相应的日志监控，比如你提到的问题可以被监控抓到，那么就可以一遍抓包，一边观察监控，等监控上出现我们期待的问题的时候，去停止抓包。然后分析抓包文件。在这里，首先要解决“如何知道兔子来了”这个矛盾，方法有不少，比如刚才说的应用日志，比如可以设置一些脚本在遇到报错时候给你提醒比如发邮件，还可以人工观察。总之大的思路就是边抓包边等重现。
2022-02-01

2

收起评论