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

你好,我是杨胜辉,欢迎和我一起开启这场网络排查之旅。

为什么在这个时代,网络排查能力变得越来越重要了?

先和你简单介绍一下我自己,我目前是eBay中国卓越技术中心基础架构部门的运维经理,主要负责eBay全球的流量管理业务,推动Kubernetes在eBay流量管理场景中的落地。

我算是一个基础架构的老兵了,在18年的工作经历中,我实实在在地遇到过太多技术方面的疑难杂症。尤其是最近几年,随着微服务和云计算的不断普及,越来越多的系统从本地的单体服务,变成跨网络的分布式的微服务。那么随之而来,就是数不清的跟网络相关的问题。比如:

  • 为什么我的应用在单体应用的时候很正常,拆分成微服务以后却时常超时、报错呢?
  • 为什么我的带宽是足够的,但数据传输速度却很慢?
  • 为什么我的应用偶尔会卡住,但又不是每次都这样?
  • 为什么……

面对这么多问题,我们经常束手无策。有些同学自嘲是优秀的“SRE”(Server Restart Engineer),遇到问题先上“重启大法”,也许也能搞定不少问题。但是呢,根因依然是未知,即使问题暂时消失了,但不知道什么时候,它又会再次到来,然后再次重启……

所有这一切,都让我深深地感到:我们的工程师,太需要网络排查方面的能力了。

无论你是运维还是开发,无论是产品还是测试,都没法彻底回避网络问题。但是,因为大部分同学并不是网络出身,对于跟网络相关的问题,经常无从下手,或者事倍功半。在这方面,常见的困难就有:

  1. 对于网络知识点好像是懂的,但一遇到实际的网络故障,就又不懂了,更不知道排查工作如何做起;
  2. 网络知识是懂的,也能做一些排查,但是遇到艰深一点的问题时,就“卡壳”了,无法把排查工作进一步推动下去;
  3. 对于网络排查有一些经验,比如前面说的“重启大法”,比如知道修改某个配置可能有用,但是因为不知道其原理,在三板斧不见效的时候,就别无他法;
  4. 本身负责应用开发,也有兴趣自己来排查网络问题,但苦于没有这方面的背景和积累,排查工作很容易“熄火”,令人沮丧。

如果你符合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:你可以每节课后在留言区进行提问和交流,我也会及时回复你,哪怕只是打个卡,等两个月后你学完全部课程,一定会有很大的收获。

最后的最后,我想说:

二十多讲的课程,就是我们有二十多次的相遇,而随着课程的推进,我们或许还会有更多的交集。我要感谢你决定花这么多时间,来学习这门课程。同时我也建议你,感谢下你自己,因为你愿意花时间来这个课程学习,因为你想做更好的自己。只要坚持下去,你一定可以做到!

精选留言

  • 分清云淡

    2022-01-13 17:09:59

    https://plantegg.github.io/categories/network/ 看完这些网络排查案例相信对大家学习这门课程很有热情的 ,雷锋,不用谢
    作者回复

    嗯 也是实际案例,做案例真的是成长最快的方式之一

    2022-01-13 22:58:06

  • 01

    2022-01-12 22:16:21

    老师你好,我们今天线上遇到一个http 503 的issue,提示service unviable的问题,请求过程是这样的,内网机器通过proxy代理服务器去call另外的内网机器,大概有可能是哪里的问题呢?

    proxy server和另外的内网机器我们都没权限查看。。。
    作者回复

    嗯,这也是典型问题场景:应用层有报错,但我们并不知道网络上具体发生了什么,更无法知道这些网络行为对应的技术原理和对策是什么。这也是我在刚结束的直播课里,给大家提到的网络排查的两大核心难点之一:应用症状和网络现象之间的鸿沟。另外一个核心难点,是wireshark等工具提示跟技术原理之间的鸿沟。只有跨过了这两道鸿沟,我们才真正能把网络排查这门技术给做起来。
    所以如果要彻底查清楚,是需要抓包后做分析的,过程不是一两句能说清楚,我在课程里会重点讨论这方面的思路和方法,你可以期待一下:)
    关于http报错代码,也可以从协议规范出发,初步判断问题在哪里。比如这个503,意思是service unavailable,也就是这个proxy想要找后端的机器,但是没有找到。这个原因也有多种,比如proxy到后端机器在网络上就不可达,或者健康检查发现没有可用的机器,等等。
    你可以让有权限的同事帮你到proxy server上抓取网络报文,要想办法在抓取期间,重现503问题。然后你就可以借助我后面课程里的方法,进行分析了。

    2022-01-13 00:22:41

  •  x

    2022-01-12 18:45:55

    我一般是本机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 22:05:43

  • GAC·DU

    2022-01-12 18:04:44

    一个线上服务出现网络故障,SRE需要一分钟,而排查需要时间未知,如何选择?
    作者回复

    一般对于明确的故障,特别是影响到业务可用性的故障,首先是做恢复,而不是排查。先通过切换到健康集群或者其他数据中心的方式,把业务尽快恢复。之后再做排查,或者两者同时做。但不应该把恢复放在后面哦

    2022-01-12 22:07:03

  • 晴天

    2022-01-12 22:33:30

    工作中遇到connect timeout和read timeout,总有一种无助感,希望学完课程能突破
    作者回复

    好的,这两个timeout也都是常见的timeout。一个是连接超时,一个是读取(等待数据)超时。我在TCP实战篇里都会讲到的:)

    2022-01-13 00:23:19

  • 啊树

    2022-01-15 22:35:57

    程序猿一枚 请问学习该课程需要先阅读那些书籍来做辅助?
    作者回复

    不是一定要提前阅读参考书籍的。你可以先把预习篇的两课仔细看一下,有什么问题可以在那边的留言区提问,我一定会回复你。
    书籍方面,我推荐Richard Stevens的《TCP/IP详解》第一卷。这个也是大部头,第一遍只能看懂一小部分是很正常的,可以从我的课程里学习实际案例,再结合书中的内容来理解。
    或者等学习完整个排查课后,再去看书也可以的,因为到课程学完后,哪怕不是每个细节都理解了,但至少对应用和网络之间的关系,以及问题可能属于哪个知识点的问题,你就有正确的理解,也知道应该去看书里的具体那一部分内容了。

    2022-01-16 14:59:09

  • Geek_fde833

    2022-01-28 15:09:38

    因为看了这篇,才开的会员,加油💪
    作者回复

    加油!有问题也可以在留言区提问,我会尽量解答。顺祝新春快乐!

    2022-01-28 19:51:49

  • Horizon_carry

    2022-01-12 23:04:08

    打卡学习,大哥,跨境限制抓包看他三次握手里面ttl时间与64的大小,跨境在这里限制了,可以这样理解吗
    作者回复

    你是指great wall吗 简单回答你,是的

    2022-01-13 00:24:53

  • 姜姜

    2022-01-12 22:16:12

    课程有没有对容器网络问题排查的讲解?
    作者回复

    嗯 直播课的时候有同学提到了,我后续会做加餐,安排这方面的案例介绍

    2022-01-13 20:40:26

  • Ricky was a young boy

    2022-03-18 20:33:43

    打卡第一天,刚开的会员
    作者回复

    加油加油💪

    2022-03-20 10:50:05

  • JianXu

    2022-03-12 07:26:15

    看来大V 早就知道刻意练习了。
  • 流水

    2022-02-01 09:45:25


    老师,您好。
    在实际的生产环境排查过程中,往往需要等待问题复现,尝试部署抓包工具进行守株待兔,这里又可能对环境造成额外负担或可能引发次生故障,同时因对问题没有清晰的特征判断,也不能在测试环境进行准确复现,请问有没有什么好思路或实践?
    作者回复

    您好,您提到的问题很常见。不过一般来说,如果抓包过滤条件比较精确,比如限定到某个ip某个端口,那对系统的额外压力并不大,建议还是要做抓包。这是第一个问题。
    第二个是关于“守株待兔”,兔子什么时候会出现的问题。我们的实践是,如果有相应的日志监控,比如你提到的问题可以被监控抓到,那么就可以一遍抓包,一边观察监控,等监控上出现我们期待的问题的时候,去停止抓包。然后分析抓包文件。在这里,首先要解决“如何知道兔子来了”这个矛盾,方法有不少,比如刚才说的应用日志,比如可以设置一些脚本在遇到报错时候给你提醒比如发邮件,还可以人工观察。总之大的思路就是边抓包边等重现。

    2022-02-02 16:00:39

  • 蝴蝶

    2023-01-21 13:25:45

    那什么,22年除夕打卡
    作者回复

    新年快乐!

    2023-01-26 09:30:20

  • Bradly

    2022-04-17 17:36:19

    希望学了这门课程后可以解决工作中遇到的奇奇怪怪的网络问题,摆脱SRE的困境。
    作者回复

    赞!SRE是非常棒的职位,挑战也很大,对人有全方位的要求,所以打好计算机基础特别重要:)

    2022-04-20 23:17:27

  • lmzf

    2022-04-15 00:03:04

    老师,最近我们公司的工位台式机经常偶尔不能上网,一会又恢复,上次找个人协助,说是因为有人使用了某个品牌苹果转接头的原因,但是禁掉转接头的话还是会出现偶尔断网的情况,请问有什么排查思路吗?感谢
    作者回复

    你好,这个问题比较宽泛,不太好给出针对性的意见,不过我建议你了解具体背后的原因,不满足于别人告诉你的“苹果转接头”这个说法。这个本身也还是现象,我们最好了解到根本的原因,这个“转接头”引起了网络通信中的什么问题呢?每次遇到问题,把它不仅解决,而且搞透,方能不断精进。

    2022-04-17 01:18:14

  • 0ck0

    2022-03-08 19:29:59

    老师博客地址是啥?
    作者回复

    微信搜索“大v小站”:)

    2022-03-19 13:54:38

  • 高恒亮

    2022-01-27 08:11:07

    立个flag,2022做到每日打卡,每日复盘,加油!
    作者回复

    加油:)

    2022-01-28 19:44:08

  • 花一个无所

    2022-01-17 08:44:46

    终于有一门这样的课了
    作者回复

    一起进步!

    2022-01-18 01:58:03

  • 记事本

    2022-01-14 10:25:08

    排查问题与解决问题,也是体现价值的时候呀
    作者回复

    嗯 怕的不是正常,怕的是不正常:)日常调试、问题处理,都离不开排查能力。

    2022-01-14 23:26:55

  • includestdio.h

    2022-01-12 17:37:07

    打卡,按时学习,按时吃饭~
    作者回复

    我也打卡,按时回复留言:)

    2022-01-12 22:07:18